IRC channel logs


back to list of logs

<lispmacs[work]>branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile
<lispmacs[work]>ideally, also able to run Elisp code as well as Guile code
<lispmacs[work]>I'm actually trying to build it right now through Guix package manager
<lispmacs[work]>It is really Guile able to runnign Elisp, rather than the other way around
<dsmith>Was funded by a few Google Summer of Code's iirc
<mwette>lispmacs[work]: thanks
<lispmacs[work]>mwette: latest repository commit for the emacs part of the project was May 12 2015. I'm going to check on the guile side of it
<lispmacs[work]>out of curiousity
<lispmacs[work]>mwette: may 10 2015
<lispmacs[work]>there was a blistering talk at emacsconf this year arguing that we needed to switched over to Guile or something else, for Emacs to survive. Not sure if that got anybody motivated enough to keep working on it
<dsmith>iirc, current Guile does have some elisp support. There is some magic for handling how #f, '(), and nil are either the same or different depending on Scheme or Elisp.
<dsmith>For example.
<jcowan>Actually they are the same on both sides of the fence. A list created with Guile ends in () and one created with Elisp ends in #nil.
<mwette>Has the performance parameters (or fluids) improved over the last several years?
<jcowan>The trick is that both Scheme #f and #nil are falsy, and that both () and #nil return true to null? (or Elisp null).
<jcowan>So if you do un-Schemey tests like (eq? x #f) or (eq? x '()) you will get the wrong answers on Elisp data.
<dsmith>But isn't '() also falsy in elisp? (Or did I misunderstand you?)
<jcowan>Yes, correct.
<jcowan>So all of '(), #nil, and #f are falsy in Guile Elisp.
<jcowan>There is a Scheme predicate nil? as well.
<dsmith>But in Guile Scheme?
<dsmith>#f is false. #nil ?
<mwette>(null? #nil) => #t in guile 2.2
<jcowan>Yes, #nil is a unique object that is both falsy and an empty list, but distinct in the sense of eq? from either #f or '()
<dsmith>Ok. Cool. Thanks for the clarifications.
<jcowan>On the Elisp side, you will fail if you write (eq x 'nil), because the symbol nil is not falsy.
<jcowan>sorry, I meant (eq nil 'nil)
<jcowan>I'm assuming that #nil is also a symbol at least on elisp, but perhaps not.
<mwette>in guile elisp, nil is printed as #nil
<mwette>but the character sequence `#nil' generates a read error
<mwette>(this is in guile 2.2, after ,L elisp)
<lispmacs[work]>hi, I'm in the guile reference manual, but having trouble figuring out how to call an external program from within guile
<lispmacs[work]>wait, there is the POSIX section
<jcowan>Doing .L elisp replaces the evaluator of the REPL, but not the reader or the printer.
<mwette>(system "ls")
<lispmacs[work]>`system' call should be what I need
<jcowan>or maybe it's just the printer that's no replaced
<jcowan>at any rate I remember some inconsistencies.
<mwette>the printer, it seems; the reader is `read-elisp'
<jcowan>How did you find that out?
<mwette>look at language/elisp/spec.scm
<dsmith>lispmacs[work]: Do you need to talk stdin or stdout to the program?
<jcowan>I remember typing '(a b c) or something like that and it printed (a b c), not (a b c . #nil), though
<jcowan>But perhaps the printer just uses null? to check
<jcowan>and there really is a #nil in the tail.
<lispmacs[work]>dsmith: not in this case I think, thanks
<mwette>jcowan: in scheme, '(a b c . #nil) => (a b c), so the scheme printer is #nil0aware
<jcowan>Or nil-unaware, depending on how you look at it.
<mwette>ha ha -- yes
<rlb>the impression I'd gotten a while back was that guile's elisp was mostly "complete" -- the main work remaining (and quite nontrivial) was the *other* bits in emacs that are in say C like, in particular, the buffer/text handling.
<rlb>s/in particular/for example/
<rlb>at least that's one of the bits I think was mentioned back then.
<rlb>3.0.0 printing \u2026 on a terminal rather than ... doesn't seem ideal...
<rlb>(in backtraces)
<rlb>what in the world...
<rlb>I think I found the 00-repl-server.test issue -- it was actually that root was blocking any further attempts to run the test as non root, because (I think) the test just hard-codes /tmp/repl-serer (and doesn't always clean it up). Perhaps we should use a real temp file?
*rlb investigates...
<rlb>(preliminary patch filed at bug-guile)
***spk121_ is now known as spk121
<civodul>OrangeShark: congrats on the Guile-Git release!
<civodul>somehow i had overlooked it
<civodul>looks like my (git proxy) addition arrived one day too late
<civodul>next time!
<jonsger>catched the guile-git 0.3.0 release :)
<brandelune_>Hello, I just git-cloned the savannah repository but could not find an INSTALL file at the root of the project.
<brandelune_>Am I missing something ?
<lloda>read HACKING brandelune_
<brandelune_>Thank you.
<brandelune_>But the README file has:
<brandelune_>"Generic instructions for configuring and compiling Guile can be found
<brandelune_>in the INSTALL file."
<lloda>that's for the package
<lloda>you have to run ./
<lloda>that will create INSTALL
<brandelune_>Ok, thank you.
<brandelune_>But fails on my mac.
<lloda>the README could be improved I think
<lloda>how does it fail
<brandelune_>So I was looking for info in how to build on macos
<brandelune_>glibtoolize: copying file 'm4/lt~obsolete.m4'
<brandelune_> warning: macro 'AM_GNU_GETTEXT' not found in library
<brandelune_>autoreconf: running: /usr/local/Cellar/autoconf/2.69/bin/autoconf --force
<brandelune_> error: possibly undefined macro: AM_GNU_GETTEXT
<brandelune_> If this token and others are legitimate, please use m4_pattern_allow.
<brandelune_> See the Autoconf documentation.
<brandelune_>autoreconf: /usr/local/Cellar/autoconf/2.69/bin/autoconf failed with exit status: 1
<lloda>I'm not on my mac atm, but you probably need to have autoconf, automake, gettext, gsed, some other stuff installed
<lloda>I use MacPorts
<lloda>the versions that come with Mac OS are too old
<brandelune_>Hence the need to have an INSTALL file that gives that info before hand ;-)
<lloda>you aren't wrong, but INSTALL is supposed to come with ./configure so you don't need to run autogen in that case
<brandelune_>I was surprised to see that brew only has 2.2.6 at the moment.
<brandelune_>Ok, so maybe add a few lines to README ?
<brandelune_>When I have the thing working, I can send a patch for that.
<brandelune_>Oh and the README has:
<brandelune_>"This is a prerelease of version 3.0 of Guile,"
<brandelune_>I thought 3.0 was officially released ?
<lloda>you can fix that in your patch ;-)
<brandelune_>I will. I just subscribed to guile-devel. I'll continue the conversation there.
<brandelune_>Thank you for the hints.
<lloda>but really README should say that if you don't have a configure, you have to look at HACKING, and HACKING could also be improved
<brandelune>indeed I seem to have an old flex. 2.5.37 is recommended but Apple only provides 2.5.35
<brandelune>updating now :)
*jonsger makes good progress on bringing 3.0 to Tumbleweed. Even use it as default Guile :)
<brandelune>ok, it seems to not only be a flex problem...
<brandelune> warning: macro 'AM_GNU_GETTEXT' not found in library
<brandelune>autoreconf: running: /usr/local/Cellar/autoconf/2.69/bin/autoconf --force
<brandelune> error: possibly undefined macro: AM_GNU_GETTEXT
<brandelune> If this token and others are legitimate, please use m4_pattern_allow.
<brandelune> See the Autoconf documentation.
<brandelune>autoreconf: /usr/local/Cellar/autoconf/2.69/bin/autoconf failed with exit status: 1
<brandelune>autoconf (GNU Autoconf) 2.69
<brandelune>automake (GNU automake) 1.16.1
<brandelune>glibtoolize (GNU libtool) 2.4.6
<brandelune>GNU M4 1.4.6
<brandelune>flex 2.6.4
<dsmith>brandelune: Hmm, that's about what I have on my Debian box. Except m4 is 1.4.18
<lloda>I think that's just gettext missing brandelune
<dsmith>Also, watch out for readline. macos provides something that's almost close, but not quite there.
<brandelune>lloda I have macport gettext I think
<brandelune>which gettext
<brandelune>gettext -V
<brandelune>gettext (GNU gettext-runtime) 0.20.1
<lloda>then I dunno
<lloda>maybe automake doesn't know where the gettext macros are
<lloda>if you installed that differently
<brandelune>looks like
<brandelune>ok, checking again, I'll be back when I have something :)
<brandelune>weird, brew has gettext properly installed... :(
<manumanumanu>brandelune: compiling guile on mac os x is configure file voodoo.
<manumanumanu>I just gave up when trying to submit a patch, and compiled it on my rock pi 4. it took a lot longer to compile, but had I gone with that path before deciding to try to do it on a mac I would still be up something like 5 hours.
<brandelune>it looks like the #machomebrew is not super active so I'm not sure what the issue is with gettext, but right now they're the only one able to help I guess...
<manumanumanu>so now I am building a small linux machine with an amd 3200g to 1. replace all my SBCs and my NAS and 2. do all my development on.
<manumanumanu>emacs makes that nice enough
<brandelune>yes, well, I'm kind of stuck with my mac for the moment... :(
<manumanumanu>you can copy the formula from the git PR and use that to build from master
<manumanumanu>(or download 3.0)
<brandelune>I'm eyeing cheap 2nd hand laptops just for the fun (and I want to run picolisp natively too)
<manumanumanu>that just works.
<brandelune>ok, so trying to got he git way is a waste of time ? :)
<brandelune>#machomebrew is *very* silent...
<lloda>brandelune: if you know where the gettext macros are installed you can try setting ACLOCAL_PATH I think
<brandelune>also, I just read the guile 3.0 PR for the brew package. Not making much sense to me but it looks blocked:
<brandelune>lloda, I just wish I had not to resort to that kind of magic :(
<lloda>macports works for me. That said version fences like those on the ticket in your link pretty much require that things be updated in several places by human hands
<brandelune>ok, my macros are here:
<brandelune>so I just set ACLOCAL_PATH with an export ?
<lloda>I'm not an autotools expert :-|
<brandelune>right now I have:
<brandelune>aclocal --print-ac-dir
<brandelune>Oh ! There is a dirlist there
<brandelune>with /usr/local/share/aclocal
<brandelune>so I guess just maybe adding the gettext aclocal path would do...!?!?!?!
<brandelune>Yeeeeeeees !!!!!!
<lloda>nice :)
<brandelune>Ok, so maybe there is an issue with the gettext install not properly adding a path to that file, maybe because I installed them in the wrong order...
<brandelune>Now I can see the INSTALL file :)
<brandelune>did the guile team create the file ?
<brandelune>ok, I had an issue with libffi but just exporting LDFLAGS and PKG_CONFIG_PATH was enough...
<brandelune>now configure exited properly, and I'm trying a make !
<lloda>maybe we should have --with-libffi-prefix like with the other deps
<peanutbutterandc>Okay, so I just poked around with `guile -l foo.scm --language=ecmascript` (guile 2.x) and I could call (foo 1) as foo(1);
<peanutbutterandc>Can someone please tell me the limitations to that? Because it seems to me that if emacs were to have guile instead of elisp, the users could do all that is being done with emacs, with ecmascript
<peanutbutterandc>I heard that python support was something in the works. I wonder: could one `guile --language=python` and then `import python_modules_here`, too?
<brandelune>lloda: please :)
<brandelune>guile is at 150% cpu use, slowly moving through the BOOTSTRAP GUILEC things...
<lloda> ya that takes a while
<brandelune>how many are there ?
<brandelune>makeinfo on the doc seems to have issues
<brandelune> makeinfo --html --no-split --css-ref=./r5rs.css guile.texi
<brandelune>guile.texi:10: @include: could not find version.texi
<brandelune>guile.texi:11: @include: could not find effective-version.texi
<brandelune>maybe I need to do something before...
<brandelune>maybe make has not reached the point where it works on the docs...
<mwette>the first make has to complete before you can build the documentation
<brandelune>thank you mwette
<brandelune>lloda: big issue with
<brandelune>Making all in guile-readline
<brandelune> SNARF readline.x
<brandelune> CC readline.lo
<brandelune>readline.c:432:7: warning: implicitly declaring library function 'strncmp' with type 'int (const char *, const char *, unsigned long)' [-Wimplicit-function-declaration]
<brandelune> if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
<brandelune> ^
<brandelune>readline.c:432:7: note: include the header <string.h> or explicitly provide a declaration for 'strncmp'
<brandelune>readline.c:432:16: warning: implicit declaration of function 'rl_get_keymap_name' is invalid in C99 [-Wimplicit-function-declaration]
<brandelune> if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
<brandelune> ^
<brandelune>readline.c:432:16: warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'const char *' [-Wint-conversion]
<brandelune> if (strncmp (rl_get_keymap_name (rl_get_keymap ()), "vi", 2))
<brandelune> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<brandelune>3 warnings generated.
<brandelune> CCLD
<brandelune>Undefined symbols for architecture x86_64:
<brandelune> "_rl_get_keymap_name", referenced from:
<brandelune> _scm_init_readline in readline.o
<brandelune>ld: symbol(s) not found for architecture x86_64
<lloda>did you pass libreadline to configure
<brandelune>clang: error: linker command failed with exit code 1 (use -v to see invocation)
<lloda>there is --with-libreadline-prefix= for that
<brandelune>the README says "It will also use the libreadline library if it is available."
<jonsger>brandelune: please use a paste service for such long logs :P
<brandelune>so I was not expecting make to choke on that, especially after autogen and configure worked
<brandelune>jonsger: apologies, would you mind clarifying ?
<brandelune>are there preferred paste services ?
<jonsger>brandelune: not really, is not good for TOR users.
<brandelune>I doubt tor users are interested in my super beginner level inquiries :)
<lloda>maybe configure should detect that
<lloda>but readline in mac os is probably outdated
<lloda>I know I do need to pass my macports path to libreadliine when I build Guile
<lloda>brandelune: you can use
<brandelune>yes, configure should definitely detect that :)
<brandelune>So maybe the README should have that readline is required ?
<brandelune>thank you for the paste service
<brandelune>(I'm updating my local copy of the README as I work through the build process :)
<lloda>I think there should still be some way not to use readline with Guile, b/c of license issues
<lloda> so if you didn't have any libreadline in the system then maybe make would have completed, just you wouldn't have readline
<lloda>but I'm not entirely sure
<brandelune>I had readline but from Brew and the various paths were not exported, so it was not visible to the build process
<brandelune>weird, now I doing configure again and this time it won't recognise libffi
<brandelune>already midnight here, maybe it's time to call it a day... :(
<brandelune>ok, back to make...
<brandelune>ok, I'm giving up. whatever I do to set the path to libffi it won't recognize it during make but configure won't say a thing about that...
<dsmith-work>Tuesday Greetings, Guilers
***ng0_ is now known as ng0
<dsmith-work>brandelune: The above readline errors sound like macos readline was found instead of gnu readline.
<brandelune>thank you. I think I had that fixed by setting correct paths to brew readline, and now that I'm starting again I have issues that I thought were fixed with libffi...
<chrislck>ok i'm 2.5 years into guile, not exactly green nor gray. do you guys think, for is a well-written algorithm in guile potentially faster than a well-written python?
<dsmith-work>Sure. I think the only way Python code becomes performant it by using external compiled libs.
<chrislck>nice :)
<dsmith-work>chrislck: As wingo mentioned in the release announcement, the current Scheme evaluator is about par with the old C evaluator. Beccause of JIT.
<chrislck>my work in gnucash is continuing. now there are very few unreasonable set! left in internal code. I think this is an achievement :)
<chrislck>and the reports have had numerous upgrades
<chrislck>all hail the mighty '()
<jonsger>chrislck: congrats :)
<brandelune>Ok, no idea what's going on and way past bedtime...
<brandelune>configure says:
<brandelune>checking for libffi... no
<brandelune>configure: error: Package requirements (libffi) were not met:
<brandelune>No package 'libffi' found
<brandelune>Consider adjusting the PKG_CONFIG_PATH environment variable if you
<brandelune>installed software in a non-standard prefix.
<brandelune>Alternatively, you may set the environment variables LIBFFI_CFLAGS
<brandelune>and LIBFFI_LIBS to avoid the need to call pkg-config.
<brandelune>but then brew says:
<brandelune>For compilers to find libffi you may need to set:
<brandelune> export LDFLAGS="-L/usr/local/opt/libffi/lib"
<brandelune>For pkg-config to find libffi you may need to set:
<brandelune> export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig"
<brandelune>which is what I did.
<brandelune>and I sourced the .zshrc file, etc.
<brandelune>I have a few mods to the README (even if I failed to build), I'll be sending them to the dev list.
<lloda>you can look in config.log to see why configure failed to find libffi
<lloda>in mine (linux) it says configure:47309: $PKG_CONFIG --exists --print-errors "libffi"
<lloda>configure:47312: $? = 0
<lloda>so that worked
<brandelune>configure:50612: checking for libffi
<brandelune>configure:50619: $PKG_CONFIG --exists --print-errors "libffi"
<brandelune>Package libffi was not found in the pkg-config search path.
<brandelune>Perhaps you should add the directory containing `libffi.pc'
<brandelune>No package 'libffi' found
<brandelune>export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig"
<lloda>does the --exists etc line work outside configure?
<brandelune>let me check
<brandelune>I've cleaned up a bit my shell init files... maybe there were conflicts there, I don't know.
<brandelune>ok, I had silly mistakes in my export commands. Shame on me.
<brandelune>Now I'm back to normal autogen exit, normal configure exit, and make seemingly munching through all the stuff that it did earlier before hitting the readline wall.
<brandelune>too bad I can only check that tomorrow morning :)
<brandelune>but I'm definitely back to smiley mode, plus I fixed my environment.
<dsmith-work>brandelune: yey
<brandelune>yey indeed :)
<brandelune>oh cool.
<brandelune>all the bootstrap stuff having been done earlier I'm now jumping through those hoops and I got real quickly to the readline error
<brandelune>Now, "Making all in guile-readline"
<brandelune>is what breaks the thing.
<brandelune>and I'm back clearly to the early error.
<dsmith-work>At one time I had a patch that lets it use macos readline. There are some symbols that ./configure is specifically looking for that are not in the macos implementaiton. But those symbols are not actually used.
<dsmith-work>But that was a while ago.
<brandelune>but I'm supposed to be using brew readline
<brandelune>stable 8.0.1
<brandelune>and they suggest:
<brandelune>For compilers to find readline you may need to set:
<brandelune> export LDFLAGS="-L/usr/local/opt/readline/lib"
<brandelune> export CPPFLAGS="-I/usr/local/opt/readline/include"
<brandelune>For pkg-config to find readline you may need to set:
<brandelune> export PKG_CONFIG_PATH="/usr/local/opt/readline/lib/pkgconfig"
<brandelune>which I put in my .zshrc
<dsmith-work>Yes, I never submitted it. I'm sure the GNU folks would rather encourage the use of GNU readline.
<brandelune>the error is:
<brandelune>Undefined symbols for architecture x86_64:
<brandelune> "_rl_get_keymap_name", referenced from:
<brandelune> _scm_init_readline in readline.o
<brandelune>ld: symbol(s) not found for architecture x86_64
<brandelune>does that make sense to you ? :)
<lloda>the libreadline paths should be set with --with-libreadline-prefix=
<brandelune>lloda: where should I set that ?
<lloda>./configure --help
<brandelune>:) lloda :) make succeeded
<brandelune>make install fails though...?
<brandelune> /usr/bin/install -c -m 644 libguile-2.2-gdb.scm /usr/local/lib/libguile-3.0.a-gdb.scm
<brandelune>sed: -e: No such file or directory
<civodul>brandelune: oops, that's a mistake
*civodul looks
<dsmith-work>Sounds like some @VALUE@ wasn't updated properly?
<brandelune>if you say so... :)
<dsmith-work>Or is that because macos sed doesn't know '-e' ?
<brandelune>possible too
<brandelune> sed [-Ealn] command [file ...]
<brandelune> sed [-Ealn] [-e command] [-f command_file] [-i extension] [file ...]
<brandelune>looks like it should work
<brandelune>what is the purpose of -e in non-macos sed ?
<civodul>brandelune: commit 491cc23f93f622e067e120f875424ed76d73cf8f fixes it
<RhodiumToad>-e in any standard sed just means "the following argument is an edit command"
<RhodiumToad>a common porting mistake is to forget the "options before positional parameters" rule
<brandelune>thank you RhodiumToad
<dsmith-work>RhodiumToad: Ahh!
<RhodiumToad>GNU software ignores this long-standing rule, which only leads to further confusion in the cases where it really matters
<brandelune>civodul: after a git pull a redoing everything just to make sure, I have another instance of that error:
<brandelune> /usr/bin/install -c -m 644 libguile-3.0-gdb.scm /usr/local/lib/libguile-3.0.a-gdb.scm
<brandelune>sed: -e: No such file or directory
<dustyweb>I don't remember running into this before in geiser
<dustyweb>C-c C-k in a module and then
<dustyweb>ERROR: In procedure scm-error:
<dustyweb>failed to create path for auto-compiled file "/home/cwebber/sandbox/foo.scm"
<civodul>brandelune: hmm that must be something else then
<civodul>could you check what libguile/Makefile looks like there?
<civodul>well i did fix something, but not the same thing :-)
<brandelune>Where is libguile ?
<brandelune>you mean guile/lib ?
<dsmith-work>brandelune: Guile is really a library. The "guile" executable is really just a thin layer over it. The bulk of the C code is infact in the "libguile" dir.
<brandelune>sure but in my savannah clone, I don't have a libguile directory
<brandelune>oh yes I do :)
<brandelune>civodul, what am I supposed to check in that Makefile ?
<civodul>brandelune: i'd look for the faulty sed invocation
<lloda>I get around that by installing gsed brandelune iirc
<lloda>I think configure will check if gsed exists before trying sed
<brandelune>ok, installing...
<brandelune>(which means I have to reconfigure and remake everything... :( )
<lloda>I mentioned gsed on my 1st reply ;-)
<lloda>I think that's a bug somewhere, b/c autoconf is supposed to cover that sort of incompatibility
<lloda>I would think
<brandelune>lloda including the thing with readline that should be caught in configure, I think
<brandelune>and sorry for the gsed reference I missed...
<lloda>I wasn't very specific :-(
<brandelune>ok gsed installed and recognised as sed... restarting the whole thing...
<jcowan>Just reported two elisp bugs: there is no proper elisp printer, and nil is not a symbol.
<brandelune>➜ guile git:(master) ✗ guile -v
<brandelune>guile (GNU Guile)
<brandelune>ok, so as far as I'm concerned there are 2 configuration "bugs"
<brandelune>1) configure should figure out that I'm not using the right readline
<brandelune>2) configure should figure out that I'm not using the right sed
<brandelune>it took about 10h to fix all that :)
<brandelune>3am, definitely time to go to bed.
<brandelune>thank you lloda civodul dsmith-work and the other who helped.
<dsmith-work>A lot of effort, but well worth it!
<lloda>cheers & gn
<lloda>hopefully it will help others as well
<brandelune>I'm sending a README patch to the dev list, there maybe things you wan to edit.
<lloda>I'm subbed, will check it for sure
<brandelune>re. the configure "bugs", should I send 2 separate mails to ?
<lloda>I would send two
<roelj>I have this piece: (build-response #:code 405 #:headers `((Allow . ,allowed-methods))), where "allowed-methods" is '(GET), and the error thrown is "bad-response: (Bad value for header ~a: ~s (Allow (GET)))". In what way should I put the method(s) in? `((Allow . ((GET))))? And why?
<rotty>roelj: being ignorant about the actual implementation, I would dare to bet that the header values must be string-like
<rotty>for the "why", I would assume that this restriction is due to there being no sensible serialization of arbitrary values that works in all cases
<rotty>(i.e. the implementation probably carries no knowlege for specific header fields and how to map their values to bytes sent on the wire)
<roelj>rotty: You are right. :) A string works.
<roelj>So, I should just deal with building a string for multiple methods
<rotty>yup, that's what I would do, at least
<roelj>This saved me quite some debugging time. :)
***drakonis1 is now known as drakonis
<stis>Hej guilers!
<stis>yay! guile-log runs under guile-3.0
<stis>That was a bit difficult
<dsmith-work>stis: Congrats
<enderby>does (string-replace-substring "a ring of strings" "ring" "rut") work for anyone?
<enderby> says it should, but i get unbound variable
<jcowan>What library did you require or import?
<enderby>(use-modules (ice-9 string-fun)) as it says
<zig>enderby: what is the output of guile --version?
<zig>first two lines are enough.
<zig>enderby: that is too old ;)
<enderby>oh what version do i need?
<dsmith-work>guile 3.0:
<dsmith-work>scheme@(guile-user)> (string-replace-substring "a ring of strings" "ring" "rut")
<dsmith-work>$1 = "a rut of struts"
<zig>you need guile 300, preferably installed via guix, follow the instructions in red at
<enderby>thanks, i do use guix
<zig>then use: guix install guile-next
<enderby>will do
<enderby>thank you
<zig>after: guix pull.
<dsmith-work>When does guile-next become not-next? Is there a guile-after-next?
<dsmith-work>Yeah, being a little snarky, but I *am* curious.
<dsmith-work>Not a guix user, btw. Not yet. Soon maybe.
<jackhill>dsmith-work: "Guile 3 migration plan" may be of interest
<dsmith-work>jackhill: Thanks!
<enderby>is there really not a built-in for rounding a number to a fixed amount of decimal places
<dsmith-work>Someone somewhere (Hacker News?) was asking what the "killer Guile app" is. I'm thinking guix
<dsmith-work>enderby: Not that I know of. But look into format. I imagine that could do what you need. Assuming you are talking about string.