IRC channel logs

2025-06-02.log

back to list of logs

<sneek>Welcome back chrislck!
<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?
<ebrasca>How to debug bulding guix packages?
<wingo>sneek: seen lloda
<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?
<lloda>hi wingo
<lloda>how can i help
<old>anybody want to fix this? https://lists.gnu.org/archive/html/bug-guile/2022-07/msg00008.html
<old>very frustating to hit a segfault in a managed language for parsing arguments
<wingo>hey lloda !
<wingo>i am poking at gc things. i got to arrays. i would like to move some c things to scheme
<wingo>how do you feel about that
<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>
<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?
<daviid>wingo: here I think https://github.com/lloda/guile-newra/
<wingo>daviid: tx!
<lechner>mwette / Hi, is there an easier way to write to a byte vector in a CDATA struct? https://bpa.st/5WRA
<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)?