IRC channel logs


back to list of logs

***dale` is now known as dale-2
<dale-2>Anyone know what the status of gtk/guile is? Has the project been abandonned?
<jackhill>dale-2: g-golf and guile-gi are two projects working in that area. Both make use of use GObject introspection. Perhaps daviid can say moreā€¦
<dale-2>Thanks, I'll look them up... never heard of them until now!
<jackhill>you're welcome :)
<dale-2>Interesting, they're both available in Guix... looks like guile-gi is furthest ahead at the moment.
<daviid>dale-2: fwiw, someone asked a similar question recently, here is what I answered
<dale-2>Okay, just read that, thanks.
<RhodiumToad>having used guile-gnome, it's possible to do usable stuff with it, as long as you don't use idle callbacks a lot
<RhodiumToad>(those will crash)
<dale-2>Difficult to know which one to go for. Probably I like the sound of the message-passing idiom better.
<dale-2>I think for a new project, going with guile-gnome would be harmful in the long run. Also I'd like to be using guile-3.x.
<RhodiumToad>yeah, choice between old dead project and new unstable projects is a pain
<manumanumanu>Did anyone see Aleix's message to guile-user? I found it fascinating: (for-each fun-stuff (string->list str)) was a lot faster than (string-for-each fun-stuff str) where fun-stuff is a procedure in the same module.
<leoprikler>I think there's a logical explanation for that to be found in caches.
<leoprikler>If you do string->list, you already have a complete list, whereas string-for-each probably works by accessing all elements of the string once and then calling the function as if you'd do your own string-ref loop
<RhodiumToad>I doubt it's anything to do with caches
<manumanumanu>leoprikler: i think the data is too large to be in a cache, and if anything strings should have better cache locality
<RhodiumToad>more likely string-for-each is not being expanded inline, so there's an actual call to fun-stuff, whereas with the for-each from the same module it can all be inlined
<manumanumanu>RhodiumToad: I thought so as well, but I couldn't make anything meaningful out of the assembly
*RhodiumToad hasn't looked at the message
<manumanumanu>But the difference is something like 2s - 18s
<manumanumanu>oh yes. for a simpler case that seems to be the case
<manumanumanu>I was just confused that the disassembly for the original code was something like 260 lines
<manumanumanu>RhodiumToad: I am still not sure. I got the disassembling wrong. I will continue to investigate.
<manumanumanu>a named let is still faster...
<leoprikler>that's called manual inlining ;)
<chrislck>aleix benchmarks probably use a large json string :)
<chrislck>what about the fact string->list accesses narrow chars if possible whereas string-for-each doesn't?
***guix-vits is now known as gwroalyf
<manumanumanu>chrislck: well, you are iterating over a list, which should give you worse cache locality.
<manumanumanu>chrislck: and does guile type-infer narrow chars? I suspect that RhodiumToad (and myself, in the earlier reply to Aleix) are correct in that there is some inline magic going on. I just need to learn how to read the assembly to understand what :D
<leoprikler>I'm still not convinced, that locality matters too much here or is even impacted that heavily.
<leoprikler>But yeah, inlining will have probably have a greater effect.