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 <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>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 <civodul>to whom it may concern: Guile cross-built for x86_64-linux-gnux32 segfaults <daviwil>For whom the x86_64-linux-gnux32 tolls