IRC channel logs
2026-01-05.log
back to list of logs
<jj>tips for debugging "source expression failed to match any pattern in form <entire define-syntax block>"? <jj>oh, once again, as soon as i post it. different question: are there restrictions on ... in syntax-rules appearing beside each other? guile is not happy w/ (pre ... _ post ...) clause ...) <jj>is there any way to make something like the following work? in absence of consecutive ... i think i have to introspect over a syntax object directly (filter (lambda (x) (free-identifier=? x #'_)) #'(1 2 _)) <jj>(ended up mucking about with syntax->datum and datum->syntax successfully!) <helibom>Hello, Guile (Scheme) newbie here with question. What is the typical way one might go about listing what public bindings a Guile module exports without actually jumping to the source? <helibom>Is it evaluating the import and running the meta command ,binding in the REPL before and after? Or is there some utility in Emacs? I'm using Neovim with Conjure, so atm no Emacs ready. <identity>helibom: there are some (i think undocumented) module interface utilities <helibom>Oh, alright. The following meta commands in the REPL seems to be for this purpose: ,in (gnu ...) ,binding <ArneBab>helibom: in code this can be a starting point: (module-for-each (λ x (write x)) (resolve-interface '(ice-9 rdelim))) <ArneBab>always starts with (resolve-module '(...)) or (resolve-interface '(...)) <helibom>ArneBab: Thank you! I'll play around with this. <helibom>The REPL meta command(s) mentioned above only lists the raw values of the modules' exported bindings, without any docstring <ArneBab>helibom: something that gives you all values (but feels like it’s too close to the implementation): (hash-map->list cons (module-obarray (resolve-interface '(ice-9 rdelim)))) <ekaitz>janneke: you were interested/involved on guile for windows? <ekaitz>idk how to deal with them, we should coordinate between lightening and guile <ekaitz>the lightening side seems harmless, so I could just merge <janneke>ekaitz: yes, but i contributed only mingw cross-compilation patches <janneke>ekaitz: doesn't look as if it it was integrated, only proposed <janneke>ACTION proposed x86_64 mingw64 patches a couple of years ago and "we"'re still working on that, so yeah... <ekaitz>so what should we do? merge the lightening part? <ekaitz>does it look good to you? i know nothing about mingw <janneke>ekaitz: it should fix compilation for mingw, so yeah; great? <ekaitz>i didn't test... maybe I need to? <janneke>it could very well be that it only applies for native builds, because afaik, guile "just builds" for 32bit mingw64 (windows naming is very confusing) <janneke>iwbn if the pull request would add a (guix) recipe to build/reproduce it <ekaitz>i don't think using guix build --target works for this, right? <ekaitz>the classic bash-minimal issue would prevent that from building <janneke>that's what i use...but as i said this sounds like it's about a native build <janneke>re bash-minimal; that's why guix has: (if (target-mingw?) '() (list bash-minimal)))) <janneke>ekaitz: why not ask the OP of the pull request? <janneke>hehe, we don't have --system mingw :) <janneke>otoh, if the plain build and cross still work, why not merge it? <ekaitz>i would just merge, but I'm trying to force myself to test things first <ekaitz>i asked the op how to test, let's see if they answer <johnwcowan>A trick for debugging syntax-rules macros id to insert a ' before each replacement. Doing this will make a macro call produce its expansion rather than the value of rhe expansion. <rlb>oh... good to know i suppose; looks like codeberg does not keep references to older pr trees indefinitely (changed via force-push), i.e. the hashes in the pr conversation can become 404 --- in this case, in "a month". <rlb>So some things referred to in the discussion may disappear.