<lispmacs[work]>branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile <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 <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]>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. <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>So all of '(), #nil, and #f are falsy in Guile Elisp. <jcowan>There is a Scheme predicate nil? as well. <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>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 <jcowan>Doing .L elisp replaces the evaluator of the REPL, but not the reader or the printer. <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' <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. <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. <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>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>(preliminary patch filed at bug-guile) ***spk121_ is now known as spk121
<civodul>OrangeShark: congrats on the Guile-Git release! <civodul>looks like my (git proxy) addition arrived one day too late <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_>"Generic instructions for configuring and compiling Guile can be found <lloda>you have to run ./autogen.sh <lloda>the README could be improved I think <brandelune_>configure.ac:706: warning: macro 'AM_GNU_GETTEXT' not found in library <brandelune_>autoreconf: running: /usr/local/Cellar/autoconf/2.69/bin/autoconf --force <brandelune_>configure.ac:706: error: possibly undefined macro: AM_GNU_GETTEXT <brandelune_> If this token and others are legitimate, please use m4_pattern_allow. <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>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_>When I have the thing working, I can send a patch for that. <lloda>you can fix that in your patch ;-) <brandelune_>I will. I just subscribed to guile-devel. I'll continue the conversation there. <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 *jonsger makes good progress on bringing 3.0 to Tumbleweed. Even use it as default Guile :) <brandelune>configure.ac:706: warning: macro 'AM_GNU_GETTEXT' not found in library <brandelune>autoreconf: running: /usr/local/Cellar/autoconf/2.69/bin/autoconf --force <brandelune>configure.ac:706: error: possibly undefined macro: AM_GNU_GETTEXT <brandelune> If this token and others are legitimate, please use m4_pattern_allow. <brandelune>autoreconf: /usr/local/Cellar/autoconf/2.69/bin/autoconf failed with exit status: 1 <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. <lloda>maybe automake doesn't know where the gettext macros are <lloda>if you installed that differently <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. <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 <brandelune>I'm eyeing cheap 2nd hand laptops just for the fun (and I want to run picolisp natively too) <brandelune>ok, so trying to got he git way is a waste of time ? :) <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 <lloda>I'm not an autotools expert :-| <brandelune>/usr/local/Cellar/automake/1.16.1_1/share/aclocal <brandelune>so I guess just maybe adding the gettext aclocal path would do...!?!?!?! <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>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>guile is at 150% cpu use, slowly moving through the BOOTSTRAP GUILEC things... <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 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>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>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>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)) <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 <jonsger>brandelune: not really, pastebin.com 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 <brandelune>So maybe the README should have that readline is required ? <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 <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, 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... ***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. <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 <brandelune>Ok, no idea what's going on and way past bedtime... <brandelune>configure: error: Package requirements (libffi) were not met: <brandelune>Consider adjusting the PKG_CONFIG_PATH environment variable if you <brandelune>Alternatively, you may set the environment variables LIBFFI_CFLAGS <brandelune>and LIBFFI_LIBS to avoid the need to call pkg-config. <brandelune>For compilers to find libffi you may need to set: <brandelune>For pkg-config to find libffi you may need to set: <brandelune> export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig" <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" <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>export PKG_CONFIG_PATH="/usr/local/opt/libffi/lib/pkgconfig" <lloda>does the --exists etc line work outside configure? <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. <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 <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. <brandelune>For compilers to find readline you may need to set: <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" <dsmith-work>Yes, I never submitted it. I'm sure the GNU folks would rather encourage the use of GNU readline. <lloda>the libreadline paths should be set with --with-libreadline-prefix= <brandelune> /usr/bin/install -c -m 644 libguile-2.2-gdb.scm /usr/local/lib/libguile-3.0.a-gdb.scm <brandelune> sed [-Ealn] [-e command] [-f command_file] [-i extension] [file ...] <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 <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 <dustyweb>I don't remember running into this before in geiser <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 :-) <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>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>(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 <brandelune>lloda including the thing with readline that should be caught in configure, I think <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>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>thank you lloda civodul dsmith-work and the other who helped. <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 bug-guile@gnu.org ? <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>yay! guile-log runs under guile-3.0 <stis>That was a bit difficult <enderby>does (string-replace-substring "a ring of strings" "ring" "rut") work for anyone? <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 ;) <dsmith-work>scheme@(guile-user)> (string-replace-substring "a ring of strings" "ring" "rut") <zig>then use: guix install guile-next <dsmith-work>When does guile-next become not-next? Is there a guile-after-next? <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.