IRC channel logs


back to list of logs

<ArneBab>rlb, manumanumanu: what I built from the basic tools we talked about:
<rlb>ArneBab: sadly I can't read the German, but interesting.
<mwette>lloda: There is an old bug on this: #21076, so I posted my patch there. Also, bug report on this to libtool, submitted by wingo 8+ years ago :
<seepel>Hi there Guilers! I'm wondering how usable Guile 3 is in Guix System. It seems like a lot of libraries have added support for Guile 3, but it seems like most of the guix packages are still at 2.2. Is this correct, or is there something else I'm missing?
<rlb>By the way -- I'm trying to finally push guile-2.0 out of debian and while I haven't done any detailed testing yet, both the make and mcron packages build just fine with no more than changing the autoconf macros from 2.0 to 3.0. And that's without any newer upstream versions (i.e. whatever's in debian/sid).
***wxie1 is now known as wxie
***wxie1 is now known as wxie
***wxie1 is now known as wxie
***wxie1 is now known as wxie
***wxie1 is now known as wxie
<narispo> 🤔
***wxie1 is now known as wxie
<lloda>mwette: thx for the patch (and the context). I hope wingo or civodul will ok it, it certainly lgtm.
***apteryx_ is now known as apteryx
<chrislck>o/ (<---1.5m--->)
***wxie1 is now known as wxie
***wxie1 is now known as wxie
***dddddd_ is now known as dddddd
<rlb>Finally got 3.0.1 and 2.2.7 built on all the release architectures in debian so they'll be able to propagate to testing now.
<mwette>rlb: awesome!
<rlb>I'll probably try removing the --enable-jit=no in 3.0.1 for a few archs to see if we can relax that after it propagates. I can't recall for sure whether I tried that with 3.0.1 vs 3.0.0. For now we specify it for arm* and x32 iirc.
<mwette>civodul: I have a patch for #40075, guile 3.0 does not build if --without-threads
<mwette>civodul: posted to
<spk121>mwette: on 2.2, you also needed . don't know if that is still true
<mwette>spk121: that fix appears applied in 3.0.1
<civodul>mwette: awesome, pushed!
<civodul>will reply by mail
<mwette>civodul: got it
<civodul>BTW, consider assigning copyright to the FSF for Guile if you haven't done it yet
<civodul>we can discuss the details if you want
<mwette>civodul: whatever helps, let me know via mail
<civodul>mwette: actually the procedure is simply to fill out and send
<civodul>happy to answer any questions you may have
<mwette>civodul: got it
<rlb>civodul: if there's not a way to tell guile to refuse to use "older" compiled files, I'd like to add one if it's not something we'd be opposed to. I almost never want guile to just use whatever version it can find if there's something wrong with the first version in the path.
<rlb>That's bitten me more than once (not noticing guile just decided to run the wrong code).
<rlb>I suppose one possibility would be a new GUILE_AUTO_COMPILE option.
<rlb>say GUILE_AUTO_COMPILE=pedantic|halt-on-error or something.
<rlb>"strict", dunno
***drakonis1 is now known as drakonis
<civodul>rlb: Guile does reject incompatible .go files, with a warning
<civodul>or did you mean something different?
<civodul>overall, given that this is a core mechanism, i don't think we can change it during a stable series
<rlb>I don't want a warning, I want guile to just exit with non-zero status
<rlb>And sure - I'd imagine it'd have to go into a Y release.
<rlb>Right now guile just proceeds, and uses a foo.go that doesn't match the newest foo.scm. That's what I want to prevent (for me).
<lloda>i thought it would just recompile if that happened :-/
<rlb>it will try the next time you run guile
<rlb>...but it'll use the old .go for the current run, I think.
<rlb>Perhaps that's what most people want by default, but it's not what I want.
<rlb>(at least I think it's not what I want :) )
<mwette>civodul: I have a patch for #29001, allow --disable-tmpnam as configure option. And tmpnam is marked deprecated; not sure you want that. I posted to
***jonsger1 is now known as jonsger
<rlb>hmm, define-syntax-rule's expansion fails in a #:pure module -- guessing it's because it needs some additional #:selections from (guile), but the error message doesn't really say anything meaningful. If I get time, I'll try to isolate it and file a bug, but basically (define-syntax-rule (foo x ...) (list x ...)) crashes expanding (foo) if you define it in a #:pure module, even if you've selected list and define-syntax-rule.
<rlb>(if it actually is a bug and not expected behavior)
<rlb>for now I can just avoid it -- define-syntax/syntax-case works fine.
<rlb>Oh, hah, now I remember. I think I figured this out a while back and forgot. You must also #:select ..., but the error doesn't actually tell you that.
<rlb>ok, that allows syntax-rules and syntax-case to work, but not define-syntax-rule.
<rlb>For that we get:
<rlb> ;;; Syntax error:
<rlb> ;;; unknown location: ...: bad use of '...' syntactic keyword in subform ... of ...
<mwette>For the purpose of providing patches to guile which git branch should I be working on?
<rlb>...offhand I'd imagine stable-2.2 if it's something that might should go into both 2.2 and 3.0, otherwise master.
*rlb gueses
<rlb>I don't believe there's a stable-3.0 yet.
<seepel>Hopefully quick question: Is there a way to put the guile repl with readline into vi mode?
<seepel>My muscle memory is proving to be a hinderence to me
<rlb>I suspect you can do it via ~/.inputrc
<rlb> occurs impressively often, archlinux wiki to the rescue?
<rlb>(I've never used arch, but have found their wiki invaluable on any number of occasions.)
<seepel>rlb: That worked! Thank you for the link!
<rlb>Do we already have anything like "walk" (or even just postwalk), i.e. something like this, even if just for nested proper lists?
<rlb>built in I mean
<mwette>seepel: try adding "set mode vi" to ~/.inputrc
<mwette>Oh, see someone got it: set editing-mode vi
<seepel>mwette: Yup, I had originally tried to do "set mode vi" myself
<lloda>imo there's no excuse for dynamic-link not finding the exact filename you gave it. If it's necessary to try adding exts first for compat reasons, then maybe the exact filename can be tried last. Dunno.