IRC channel logs
2025-06-02.log
back to list of logs
<lechner>Hi, is there something shorter than (filter identity lst) to remove all elements that are #f? <lechner>Hi, is it a bug that Guile's SRFI-37 creates the option "--#f" when passed #f as part of NAMES? <sneek>I think I remember lloda in #guile one month and 15 days ago, saying: # is a special character. <ebrasca>I am getting "File CMakeLists.txt is read-only; trying to patch anyway" can you make files writables? <ebrasca>I used this line to patch (patches (search-patches "config/modules/aux-files/stable-diffusion-cpp/vulkan-support.patch")) <wingo>ebrasca: probably a question for #guix <wingo>gosh, the arrays c code is distressing <ekaitz>wingo: do we have a ETA for the new gc? i'm excited <ekaitz>also the JIT support for RISC-V would land in that potential release? <old>very frustating to hit a segfault in a managed language for parsing arguments <wingo>i am poking at gc things. i got to arrays. i would like to move some c things to scheme <wingo>ekaitz: jit ETA, I do not know. current status is that with the fully conservative collector, things are a bit slower than bdw. but i expect the version that is precise for intra-heap links will be better. thing is, that requires precise tracing on guile's side, which involves some more guile work <wingo>so, things are still experimental. i would be happy if we could show a significant improvement by the end of the summer <wingo>but, there are unknowns still <wingo>lloda: e.g. array-slice-for-each. it is easy to write a simple scheme version that works. i expect that simple version is slower but with some work can be faster, and is more easily improved, and is easier to move forward from the gc side <lloda>yes. i've actually written that in scheme a couple times. One before the C version and another after. The version after is in newra but it doesn't use the existing array system, instead everything is in scheme. That version is faster than the C <lloda>the version before was a lot slower, because the C array object is opaque. So every iteration, from scheme, you need to create a new array view, which is extremely slow. On C you can mostly bump a pointer (not quite, but almost). On the full-scheme version, you can actually just bump a pointer <lloda>so to drop the current C version, first it must be possible to update an array view from Scheme by bumping a pointer <gabber>what's the easiest way to interact with HID devices from guile? FFI to HIDAPI? <lloda>the reason even in C you can't just bump a pointer is that someone might grab the current view and keep it, so we can't bump that one, and there is no way currently in scheme to get a copy of the view, you have to make a new one and the only way is make-shared-array, which is the whole reason why my first scheme version was so horribly slow. So the C has to make a new view in case someone grabs it, but at least that can be done fast, in <lloda>C. In the newra version, you can plain copy views, so i don't bother creating a new view in each iteration. I just bump a pointer and if you want that view you can copy it yourself <lloda>at some point it seemed simpler to not bother with C anymore, so i started writing newra <lloda>but to just move array-slice-for-each to scheme and keep the rest of the system as is, then it must be possible to 1) copy views in scheme and 2) bump views in scheme <rlb>old: I just tested with current (trixie) debian amd64 guile, and it doesn't appear to segfault with that version. <rlb>(same with current main) <wingo>sneek: later tell lloda where is the newra work? <lechner>Hi, byte vectors can be interpreted as integers, but is there also an existing way to read a sixteen-byte integer, for example from (inet-pton AF_INET6 ...) as a byte vector (for utmp)?