<rlb>ArneBab: sadly I can't read the German, but interesting. <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
***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
***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. <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>spk121: that fix appears applied in 3.0.1 <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>happy to answer any questions you may have <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. ***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 :) ) ***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> ;;; 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>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>(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! <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.