***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! <dale-2>Interesting, they're both available in Guix... looks like guile-gi is furthest ahead at the moment. <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 <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 <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>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. <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.