00:01 librasteve joined
Voldenet apogee_ntv: it doesn't seem so github.com/lizmat/IRC-Client/blob/...kumod#L546 (there would be something about AUTHENTICATE if sasl was supported) 00:05
00:07 librasteve left
Voldenet practical solution would be a plugin implementing method irc-n376 that'd send `NickServ identify` 00:11
00:11 jjido left 00:22 librasteve_ left 00:28 inspork left 00:34 librasteve joined 00:38 inspork joined 00:41 librasteve left
[Coke] Xliff: I think there was a discussion about that, but I did not participate 00:41
01:07 librasteve joined 01:12 librasteve left 01:15 xinming left 01:23 hulk joined 01:24 xinming joined, kylese left 01:26 librasteve joined 01:31 librasteve left 01:33 guifa joined 01:43 librasteve joined 01:48 librasteve left
guifa so working with my forthcoming Canvas::Simple module 01:52
I'm thinking about changing my approach
right now on the mac I've got it successfully opening up a window with a WebKit view in it, and managed to get full two way communication between Raku and JavaScript in it 01:53
my goal was just to allow a simple graphics pad where one can display images or do some simple pixel adjusts / lines
but thinking now it might be better to do two modules: one that might be, I dunno, UI::Web and then have some image module that depends on it and loads in the page I've designed for image stuff 01:55
02:00 librasteve joined 02:04 librasteve left 02:15 hulk left, kylese joined
jdv guifa: nice talk 02:26
guifa ugh they posted it? Absolutely not my best =/ I got moved so wasn't able to do a dry run and double check some perl details with peregrin and others 02:27
jdv i watched the video. i already knew most of it but it was a nice side by side piece. 02:28
thanks for doing it 02:31
guifa next year I'll have something much better 02:32
so many projects brewing just need to finish some of them
02:33 librasteve joined 02:38 librasteve left 03:05 librasteve joined 03:14 librasteve left 03:27 librasteve joined 03:29 Aedil joined 03:35 librasteve left 03:45 kylese left 03:47 kylese joined 03:48 librasteve joined
patrickb Xliff: re varargs. Yes, I know how to proceed now. Still need to continue with the actual implementation. 03:49
03:53 librasteve left 04:00 dg left 04:04 librasteve joined 04:05 dg joined 04:23 dg is now known as op 04:27 op left, op joined, op is now known as dg 04:32 dg left, dg joined 05:08 librasteve left 05:22 librasteve joined 05:27 librasteve left 05:32 librasteve joined 05:36 librasteve left
Xliff patrickb: That's awesome. Can you give me a quick overview or hint as to how you plan on proceeding? 05:37
jdv: Ack! Where is that? I would love to look at it. 05:39
patrickb Xliff: Basically this: github.com/Raku/problem-solving/is...2954082152 06:00
06:00 librasteve joined 06:03 Sgeo left 06:16 librasteve left 06:18 apac joined 06:30 librasteve joined 06:37 librasteve left 06:46 apac left 06:51 librasteve joined 07:06 apac joined 07:07 jjido joined 07:53 librasteve left 08:05 apac left 08:10 librasteve joined 08:12 dakkar joined 08:15 librasteve left 08:38 librasteve joined 08:49 jjido left
Xliff OK, so would then C be responsible for detecting the type? Would the varadic part simply be a list of pointers? 08:56
08:57 apogee_ntv left
Xliff patrickb ^^ 08:57
timo yeah it's always like that with C variadic arg functions
the types have to be signalled "out of band", for example see how printf and scanf do it
patrickb Yes, there already is a mapping table in Moar. I'll just reuse that, and fail for all types not in that list. It's up to the user to cast to a type moar knows how to marshal. 08:58
Xliff I'm not sure, but wouldn't the format spec determine what that arg is cast to?
timo yeah if there's a "%f" in the format string and you pass an integer, you're probably in for a surprise 08:59
but that's for the user "one step above" nativecall, or at least the nativecall ops that moar offers
patrickb In plain C that format spec has no influence on how some variadic arg is actually passed. That solely depends on the type of the variable itself. The format spec is there to tell the calling code what types it should expect. 09:01
s/calling code/called code/
Xliff Exactly. 09:02
OK, well if help is wanted, I'm around. I've been working around varaidics for bloody 7 years now...
timo now the only thing remaining that i could think of is passing (and maybe returning) structs by value rather than by reference. there was one library i was interested in many years ago that used that :D 09:03
patrickb It'll be some time before I'll tackle this again. Still have to get PTY support on Windows implemented first.
Xliff timo: LOL! 09:04
timo: Raylib?
timo i think it might have been SDL_GPU?
something was taking an RGB triplet as a struct
Xliff timo: I had to work around that with notcurses just last week!
timo when you're already forced to build a wrapper library in C anyway it's not too too bad 09:05
Xliff Yeah. Much of notcurses was static inline, so that was a requirement.
timo yeah
i find it funny that "not" is also a prefix in german for something like "emergency" or "of neccessity"
like in "emergency rations" could be translated to Notnahrung (but actually the right term seems to be Überlebensration, i.e. survival ration) 09:07
Notsignal -> Distress Signal
Notausgang -> Emergenly Exit 09:08
09:57 apogee_ntv joined 10:00 librasteve left 10:30 librasteve joined 10:35 librasteve left 10:43 librasteve joined
apogee_ntv If anyone on Windows/Linux could do a zef install Tokenizers btw, I will love you long time. 11:13
I have no way to test my Makefile on Windows especially.
lizmat ===> Building: Tokenizers:ver<0.1.3>:auth<zef:apogee> 11:14
[Tokenizers] ❌ Required tool 'cargo' not found in PATH. Please install it.
apogee_ntv Oh yeah, I forgot to mention it needs cargo and a C compiler.
(cargo is Rust compiler -- the wrapped library is Rust) 11:15
lizmat after a apt-get cargo I get 11:16
[Tokenizers] error: failed to parse manifest at `/home/liz/.zef/store/a8ebdbbdc71c1c5edd562c1fa0362d254c9db757.tar.gz/dist/vendor/tokenizers-ffi/Cargo.toml`
[Tokenizers] Caused by:
[Tokenizers] failed to parse the `edition` key
[Tokenizers] Caused by:
[Tokenizers] supported edition values are `2015` or `2018`, but `2021` is unknown
apogee_ntv Oof, hm 11:17
lizmat could by that the Linux dist of that machine is pretty old
apogee_ntv Yeah possibly
lizmat but that's the only Linux box I have direct access
to
lizmat returns to her regularly scheduled programming 11:18
apogee_ntv Yeah that's fair enough, Rust ecosystem is a pain, Tokenizers has so many dependencies it's hard to say if they need 2021 or not lol
Tokenizers the wrapped Rust lib I mean, not my wrapper.
lizmat yeah, gotcha 11:28
11:30 jjido joined 11:41 jjido left
tbrowder having ChatGPT is like having lizmat near by 11:43
and doesn't waste her time 11:44
jdv Xliff: what? 11:46
www.youtube.com/watch?v=IqHUB3J0w3w ? 11:48
12:04 librasteve left 12:08 librasteve joined
tbrowder thnx for the link, is all on youtube now? was Damian there? 12:11
12:14 librasteve left 12:20 librasteve joined
Xliff jdv: Thankee! 12:21
12:24 librasteve left 12:25 librasteve joined
disbot3 <librasteve> apogee: i haven’t touched the code in a while, but my Dan::Polars module integrates raku Data ANalytics to rust Polars library … the Build.pm pretty much auto builds all the dunkin’s 12:26
<librasteve> s / dunkin’s / dynlibs / 12:28
12:29 jjido joined
disbot3 <librasteve> github.com/librasteve/raku-Dan-Pol...n/Build.pm 12:29
<librasteve> main frustration with Rust ffi is lack of a Rust ABI so have to run everything as a proxy object (happy to learn a better way) 12:33
12:33 librasteve left 12:34 jmcgnh left 12:35 librasteve joined 12:39 librasteve left
lizmat nice link, wrong tag :( 12:45
12:46 jjido left 12:47 jmcgnh joined 12:53 librasteve joined
apogee_ntv librasteve: DBIish PR to add SQLCipher support - github.com/raku-community-modules/...h/pull/244 12:55
12:59 librasteve left
apogee_ntv If anyone with community access wants to take a look, please do. 13:01
lizmat I'm too DBIish noob to be able to judge 13:05
apogee_ntv Fair, it is largely a duplicate of SQLite if that helps. Just 4 new functions at low level and 2 new ones at high level 13:06
I can expose the v2 key functions if desired but in practice I've never seen them used. 13:07
Because people don't usually do multi-schema sqlite files, they just do 2 files. 13:09
disbot3: My Build.pm also builds all the dylibs, it just needs cargo to pull all the dependencies for HF Tokenizers 13:10
It pulls like 40 crates. 13:12
13:25 tejr left 13:29 librasteve joined 13:35 librasteve left 13:44 librasteve joined 13:49 librasteve left 13:56 librasteve joined
disbot3 <librasteve> yes but if you use Build.rakumod to move your toml in from resources then that helps 13:56
SmokeMachine lizmat: did you thought about the suggestion on adding block code as substring of $?SOURCE? Would that make sense? 13:58
lizmat yes, in RakuAST I guess we could add that, but how to access that then? and would it only to subs / methods ? or any block ? 13:59
SmokeMachine I think that would make sense to be for all block… but idk how would that be accessible… :( 14:00
14:02 tejr joined, librasteve left 14:04 librasteve joined
SmokeMachine Could Block just have a method for that? 14:04
lizmat sure it could, but where to store the actual source, or pointers to it 14:12
also: if you'd only require this in a stacktrace, the line-number could be used to index into $?SOURCE 14:13
14:13 jjido joined
SmokeMachine usercontent.irccloud-cdn.com/file/.../image.png 14:14
14:16 tejr left, tejr_ joined, tejr_ is now known as tejr
SmokeMachine lizmat: I would like to use that for more than stacktrace... If I have that, I do not need to create a new custom pass when using Red... Red's map/grep/first could just get the code from the block, and (using .AST) ght the ast and convert it to Red::AST... 14:16
lizmat are you doing this at compile time, or at runtime ? 14:17
SmokeMachine (but it would probably perform better with the custom pass... because it would be translated at compile time...)
my original plan was to do a custom pass on compilation to transform ALL .map(block) (same for grep and first), into .map(block, :red-ast(translated block))... then all maps that are not from Red would just ignore the new parameter and Red would use it... but on my recent tries, I've seen that's harder that it seems... because what the block does depends a lot on the parameter passed to it... and I only know that at run time... 14:21
lizmat: ☝️ 14:22
14:37 merp left 14:39 jjido left 15:07 librasteve left 15:11 librasteve joined 15:23 apac joined 15:51 apac left 16:13 apac joined 16:16 librasteve left 16:29 librasteve joined
apogee_ntv librasteve: Not sure if you saw my message earlier, I pushed that DBIish PR for SQLCipher. 16:32
16:33 librasteve left
apogee_ntv Oh it pings on Discord too, good to know. 16:33
16:34 apac left 16:38 librasteve joined
apogee_ntv Would adding reading/metadata rw to Image::PNG::Portable be desirable or should I just make a new lib? 16:41
16:42 dakkar left
apogee_ntv Probably a q for lizmat 16:46
I'd rather build on the existing ecosystem where possible but don't want to add a bunch of stuff that's out of scope. 16:47
disbot3 <librasteve> apogee_ntv: I have reviewed and approved your DBIish PR, 17:04
lizmat librasteve I'm looking at a 52 Bad Gateway :-) 17:05
*502
apogee_ntv If you feel affinity with the Image::Png::Portable module, why not take it over ? 17:06
but a PR for reading / writing metadata is also cool :-)
disbot3 <librasteve> lizmat: would you be OK for me to merge and release this PR (bear in mind I also am not a SQLlite expert so I can't really cover low level things) - or maybe (since DBIish is quite central module) we should ask a 2nd review (SmokeMachine?)
<librasteve> lizmat: darn ... was just updating
lizmat if SmokeMachine thinks he can judge it, I would wait for their judgement 17:07
disbot3 <librasteve> please gimme 10 mins
17:11 jjido joined
SmokeMachine I’m not a specialist either, but looking at it on my cell phone… could the cypher classes just extend the SQLite ones? Or aren’t they as similar as them seems to be while I’m not able to look both at the same time? 17:23
librasteve: 👆 17:24
tonyo . 17:29
disbot3 <librasteve> lizmat: server should be fixed ...? 17:30
lizmat it is.. :-)
disbot3 <librasteve> phew 17:31
<librasteve> weekly: harcstack.org/ now upgraded to use Hilite module
<librasteve> weekly: and the Markdown component (that uses Text::Markdown) 17:32
<librasteve> SmokeMachine: good point, I tend to lean to a once is happenstance, twice is coincidence and three times needs refactoring pov ... in planer english that means repeating yourself a couple of times is often OK vs. adjusting classes to have eg. role Blah::Common {} and then have two consuming classes ... when you are copying the same code (with tweaks three or more times, then I 100% agree to refactor 17:36
<librasteve> anyway just because my review was approval, doesn't mean you have to follow suit ... suggest you run a review on a bigger screen and feel free to do it your way 17:37
18:05 librasteve left
apogee_ntv lizmat: I'd be happy to take it over if that's an option, I don't really know how the community modules work. :D 18:10
lizmat they're there for someone to take care of them
apogee_ntv librasteve I can't merge it, no write permissions :D
lizmat sometimes that's just an occasional PR
you mean the DBIish on? 18:11
*one
disbot3 <librasteve> i think you need to be added to the gh org
apogee_ntv Yes the DBIish one
disbot3 <librasteve> for important stuff, i think we should try to avoid merging own PRs … don’t know if there’s a setting for that 18:12
<librasteve> eh cro, dbi, etc that s used widely
<librasteve> then i guess you need to have raku community auth to release via fez 18:13
18:15 kylese left 18:16 kylese joined
lizmat I've merged the PR 18:17
and uploaded to zef 18:19
apogee_ntv Thanks lizmat! 18:20
lizmat no, thank you! :-)
apogee_ntv I'll try to get that Image::PNG::Portable change in tomorrow, it will be able to read pixels to a matrix of RGBA values and read/write tExt metadata (and others if I can figure them out). 18:21
lizmat you can start by making a fork 18:22
(on Github)
18:28 librasteve joined 18:36 librasteve left 18:49 jjido left, guifa left 18:52 guifa joined
lizmat librasteve that concludes my issuing :-) 18:54
18:58 guifa left 19:04 librasteve joined 19:08 librasteve left 19:19 Xliff left
disbot3 <librasteve> thanks! ? 19:20
19:22 apac joined 19:36 librasteve joined 19:44 librasteve left 19:45 librasteve joined 19:49 librasteve left 19:54 librasteve joined 19:57 Xliff joined
tbrowder does raku .e version have a .is-odd method on an Int? 20:15
20:20 librasteve left 20:42 Aedil left 20:49 jjido joined 20:50 apac left
SmokeMachine m: say 42.is-odd 20:51
camelia No such method 'is-odd' for invocant of type 'Int'
in block <unit> at <tmp> line 1
SmokeMachine m: use v6.e.PREVIEW; say 42.is-odd 20:52
camelia No such method 'is-odd' for invocant of type 'Int'
in block <unit> at <tmp> line 1
21:00 librasteve joined 21:04 librasteve left 21:14 apac joined
disbot3 <nahita3882> !%%2 21:30
21:32 librasteve joined 21:35 guifa joined 21:36 librasteve left
guifa hmmm 21:42
let's say I wanted to have a trait
class Foo { method bar is external { ... } }
like actually literally putting in stub (or leaving ti blank) 21:43
to then insert a different method entirely?
m: multi sub trait_mod:<is> (Method \m, :$external) { m.package.^add_method: m.name, anon method :: { 42 } }; class Foo { method bar is external { ; } } 21:45
camelia ===SORRY!=== Error while compiling <tmp>
Package 'Foo' already has a method 'bar' (did you mean to declare a multi method?)
at <tmp>:1
21:49 Guest7 joined, Guest7 left 21:54 Sgeo joined 21:56 apac left
Xliff guifa: Why not use .wrap instead? 22:10
guifa I thought about that, assumed it carries a bit of a performance penalty but maybe not?
Xliff And the MOP doesn't? :) 22:11
guifa ha MOP would be a one time at compile lol
Xliff Ehh... true.
guifa I'm working to create an HTML Window class 22:12
Xliff It's also a PITA.
guifa goal would be to let people just subclass it and be able to say
method foo is javascript { ... } and just like nativecall, it'd handle some conversions for you
which admittedly, is probably more overhead than the wrap would incur 22:13
so I'm probably just being perfectionist
Xliff Right, but then you'd have to add in whole dynamic naming convention routines because you'd need to add a method with a different name.
And if you're doing that, you'd need to worry about name collisions, too.
.wrap would eliminate that. And it too would be compile time since its a trait. 22:14
Depends on how you would actually want to replace the stub with actual code, though. 22:15
22:15 jjido left
Xliff BTW - Brilliant talk. Watched it before I passed out this morning. 22:15
guifa anyways, the JS method bit is just icing on cake. I'm just happy I now successfully figured out a decent async-y way to avoid a double JS call that seems to crash WebKit 22:18
Xliff guifa: Are you using the JS backend in WebKit? 22:21
guifa Yeah. At least on the MacOS side. 22:22
Xliff Nice! 22:23
guifa Basically all I'm doing is popping open a window, and then using stdin/stdout to communication between the macOS native process and Raku
Xliff How's the pefromance?
guifa Raku -> macOS -> JS was happening fast enough that for an ultra simple Canvas draw command 22:24
i'd extremely quickly end up sending two JS commands before the first one ended (and then crash)
for 99% of things, I think that's probably far, far faster than we ever need to worry about :) 22:28
I'm thinking of this potentially as an alternative to native GUIs -- much as I like them, sometimes, a quick and dirty HTML page can be enough
I don't yet the two way communication from the webpage. I'll need to figure out a way to insert a Raku object that can call back to macOS world 22:30
Xliff Huh. 22:31
So more like Raku (moar) -> macOS -> WebKit (js) ? 22:32
22:33 librasteve joined
guifa yeah, basically, macOS as intermediary 22:33
goal being that it should be mostly simple to repeat this on *nix and Windows
Xliff So you want to get an object from one side to the other? 22:34
guifa Yeah. It's straightforward to do as long as I force the communication to be stringy
and I'm very okay with that as a restriction 22:35
At least initially
Xliff RakuAST string rep across the wire, maybe?
guifa I'm honestly not sure how much I can do -- it seems like with WebKit absent doing some much deeper digging I can only do text-based calls 22:36
basically the equivalent of typing in something in the debug console of a webpage
22:38 librasteve left
guifa I'll see if I can get it to an ultra basic simple but useable state.this week. Sadly got lots of homework to do (anyone huge into quantum wanna help? lol) 22:42
SmokeMachine guita, you could override ClassHOW’s add_method to add your method instead of the method the user added… 22:58
On your trait you mark the method with a role and you add a add_method candidate that receives that role… 23:00
23:09 librasteve joined
guifa ooh 23:09
that latter one might be the most efficient
I did want to play with ClassHOW at some point too so it'd be
window Foo { ... } instead of class Foo { ... }
23:12 vasko4 left 23:13 vasko4 joined, librasteve left
SmokeMachine 👍 23:14
23:27 librasteve joined 23:32 librasteve left
SmokeMachine guifa: glot.io/snippets/h8tnx81clw 23:33
guifa !!! 23:40
SmokeMachine++
SmokeMachine guifa: and I agree with Xliff , brilliant talk… and thanks for mentioning Red! :) 23:45
Good night everyone 23:47

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!