IRC channel logs

2024-04-17.log

back to list of logs

<mwette>I guess so that in the repl they don't return results. No harm in deleting, I think.
<mwette>I didn't realize anyone was using it.
<haugh>I just read it because I think the concept is important, especially for guix
<haugh>Seems like a solid implementation of heredocs to me
<mwette> thanks
<haugh>I have one with more parameterization of indentation and variable substitution, but it's a big mess both in scope and implementation
<rlb>wingo: would it be plausible to add a #:supers argument (or similar) to make-foreign-object* (passed on to the make-class)? I needed that in lokke so that the persistent vector class could start off as a <sequential>.
<wingo>rlb: sure :) also did we ever fix that thing where subtypes of a foreign object lose their finalizers?
<rlb>wingo: I'll have to review/remember that one -- been looking back through bits I'd copied-into/adapted-for lokke, but just started.
<rlb>(if that was me that reported it...)
<cbaines>the latest guile-next update in Guix seems to have problems compiling the build coordinator: internal error: unexpected kwarg syms
<cbaines>the full log is here: https://bordeaux.guix.gnu.org/build/27964af7-07b9-4dc8-9686-d3e9da20cff3/log
<cbaines>wingo, I can see the new debugging output you added at least
<dthompson>cbaines: interesting, we saw this error in hoot but wingo fixed it. wonder what's causing that in your case.
<cbaines>the #:level and #:buffer-size and the mentions of lzip and gzip suggests it's connected to the guile-lzlib/guile-zlib code potentially
<dthompson>wingo added an optimization that removes dispatch for keyword arguments when the keywords are known at compile time
<dthompson>cbaines: I'd be curious if different levels of parallelism in the build might affect the results here. that could be a workaround for the time being. I first encountered a similar error in hoot but wingo couldn't reproduce it because I built with 'make -j6' and he built with 'make -j32' which affect cross-module inlining
<dthompson>avoiding cross-module inlining might prevent the buggy scenario from occuring if this is a call across modules.
<cbaines>-j/--cores seems not to have much of an effect
<cbaines>reducing the parallelism produces clearer output though
<cbaines>it looks like call-with-lzip-output-port with the #:level keyword argument in agent.scm is probably related
<cbaines>and in this case the other module is (lzlib), so maybe that's why increasing the paralleism isn't avoiding the cross-module inlining
<dthompson>ah, well it was worth a shot.
<civodul>to whom it may concern: Guile cross-built for x86_64-linux-gnux32 segfaults
<daviwil>For whom the x86_64-linux-gnux32 tolls