IRC channel logs
2024-11-13.log
back to list of logs
<daviid>fwiw, i pushed a series of patches to the g-golf devel branch, so now the animations page example is (visible again and) fully working (it needed quite a few updates compared to the upstream demo, because in C, they can set a custom-manger, in language bindings, we must define and 'attach' a <gtk-layout-manager> derived class ...) - also, while at this, i fixed an (very) important bug (that revealed itself working on this), in the <makx>daviid: hooray for g-golf (though i fail to get it to work on guix) <daviid>makx: thank you - on guix, it works fine as well, though the current guix g-golf version id a little 'behind', but you need to somehow setup the 'environment' that is somehow compatibe with guix - some guix users ddi write how to do so, i'll try to find the guile-user emauil that refers to this, but maybe you can ask in guix and hopefully some advanced guix users may point you to the 'recipe <daviid>makx: and i am not a guix user, please ask for (further) help in #guix <makx>daviid: thanks for the help; please accept my apologies for implying that you'd provide guix support; I just wanted to express excitement about g-golf :) <daviid>makx: no problem, i hope you find appropriate help in #guix <makx>daviid: I got it to work <3 one more step done trying to convert from racket to guile <ekaitz>wingo: I located the `call` error, when the `get_callee_vcode` function is called, there's something weird going on with the return value <ekaitz>and when we try to `get_ip_relative_addr` it fails to do it properly <dsmith>ekaitz, Sounds like you are getting close! <makx>whatś this? risc-v jit backend for guile? <ekaitz>i wrote it years ago but i never tried it in guile <ekaitz>i just passed all the tests of the lib <ekaitz>which happened not to be enough btw <makx>i fiddled around a bit trying to make something like loko but on risc-v <makx>not that i wsa massively successful (yet?) <dsmith>ekaitz, Sound like there needs to be another test... <makx>anyone aware of something like racket's slideshow in guile? <rlb>by all means :) Though if I can't find/fix the 32-bit issue... <rlb>I also have to swap all that back in -- it was a good bit, and it's been a good while :) <rlb>I'm tentatively back to poking at the 32-bit failure now, but not sure if I'll really focus on it yet. <mwette>rlb: I was thinking about mutation of strings. I like to live a life where strigs are immutable, but if it's necessary to have them, what about having a separate internal type for mutable strings that is an array of the triple (stringbuf,offset,length). If you mutate the middle you get a 3-vector of the triples. <dthompson>in hoot we chose to build "mutable" strings on top of immutable ones. string-set! creates a whole new string under the hood. <dthompson>hopefully that will discourage string mutation ;) <rlb>mwette: did you mean you'd prefer *mutable* or immutable? <rlb>...and wrt triples, not sure which 3 bits you meant. <mwette>I always use w/ immutable strings. But if you *need* the in Guile that may be one way to do it. <rlb>I *think* the current plan is to just not provide O(1) mutation anymore, if we take this path. <mwette>triple would be (ref to immutable string, offset into that string, length of string) <rlb>And we still do sharing, and I can (can't recall if I *did* in the current version) allow O(1) mutable *ascii* strings, but just those. <mwette>performance of mututable strings should bear no weight on implementation trade <rlb>i.e. I had one version that kept in-place mutation of ascii-only strings, but I don't recall if that's what the current branch does offhand (I think maybe not). <mwette>The raw copy idea is probably simpler. (Make the mutators suffer!) <dthompson>hoot has the advantage of not having many users yet to upset :) <rlb>We do keep a sparse index (inline) in non-ascii strings, so char offset lookups are still O(1)-ish. <mwette>that seems like a sound design to me <rlb>I think it worked out "ok" -- one result is that all of the data for a stringbuf is "inline", and so hopefully cache friendly, i.e. all packed together (length, data, index, etc.). I tried to compress a bit (and iirc maybe could do one more level if we wanted to go further -- not sure). <rlb>We still end up with "layers" due to shared strings, etc. <daviid>mwette: wrt use ~c with v parameter in (ice-9 format), fwiw, you don't need apply, (format #f "~65c" '()) will do <daviid>i mean to ask, out of curiousity, why you prefer (apply format #f "~65c" '()) <mwette>daviid: but (format #f "~65c ~d" '() 3) does not work <mwette>while (format #f "~65c ~d" 3 '()) does, so you have to pad the arg list <mwette>using apply seems cleaner (until the bug is fixed) <daviid>but (apply format #f "~65c ~d" '() 3) won't work either? <daviid>anyway, no big deal, i was just curious, tx <makx>do I understand correctly that (for example) srfi-19 does not export the record definiton of "date" and hence I can't pattern match on "date"? <daviid>mwette: do you still have a link to your gtk2 canvas example using ffi? <daviid>*using nyacc/ffi-helper ... i lost it, wanted to try using g-golf <daviid>you posted here an example to write a tcl/tk 'model' using nyacc/ffi, but i didn't take a copy ...