IRC channel logs


back to list of logs

<mwette>based on content of psyntax I was expecting src arg to seq to be #f
<apteryx_>Hello Guilers! Would someone know how to achieve the following: (format #f "~s" '#gnugo-imgen-create-xpms) -> "'#gnugo-imgen-create-xpms"
***apteryx_ is now known as apteryx
<rlb>apteryx: what's the broader context there -- not sure what you're asking.
<rlb>If you're asking how to get the symbol name back from an #'foo syntax, then might be a way, but I don't know it offhand.
<drakonis>CL has a function that can be called that gets the symbol's contents, i'm not sure what it is called in scheme, sadly.
<drakonis>or are you trying to do something like "symbol->string"?
<daviid>apteryx: afaict, # is not in the 'Extended alphabetic characters may be used within identifiers'
<daviid>so you'd have to surrond the identifier using #{...}#
<daviid>and (format #f "~s" '#{#gnugo-imgen-create-xpms}#) => "#{#gnugo-imgen-create-xpms}#"
<daviid>apteryx: see Extended Read Syntax for Symbols
<apteryx>OK, I'll try
<apteryx>rlb: I'm trying to substitute the 'emacs-substitute-variables' syntax in (guix build emacs-utils) to set the value of a defvar elisp variable to #'gnugo-imgen-create-xpms; but because it does (format #f "~S" replacement), it ends up double quoted if passed as a string; thus I was experimenting with providing it as a symbol
<daviid>apteryx: ah, you wrote '#gnugo-imgen-create-xpms when you asked, now you write #'gnugo-imgen-create-xpms - not the same thing ...
<apteryx>yes, sorry, that was a typo
<daviid>in the defvar, you want a string?
<daviid>not a symbol
<apteryx>when I attempt to provide it as a symbol that makes it '\#gnugo-imgen-create-xpms... confusing
<apteryx>err, '\#'gnugo-imgen-create-xpms
<apteryx>I want the final result to be #'gnugo-imgen-create-xpms, which is a symbol (of a procedure)
<apteryx>and somewhere in the emacs-substitute-variables macro itends up doing (format #f "~S" replacement), so if I naively provide it with "#'gnugo-imgen-create-xpms" it produces "\"#'gnugo-imgen-create-xpms\""
<apteryx>which ends up in the edited source code as "#'gnugo-imgen-create-xpms" (i.e., as a string, rather than a symbol)
<apteryx>perhaps I'm better off adding some form to the macro, like (emacs-substitute-variables file (variable replacement (as display)) ...), where (as-display) would signal to use (format #f "~a" replacement) instead of (format #f "~s" replacement) further down.
<apteryx>then I could simply provide the replacement as a string like "#'gnugo-imgen-create-xpms"
<apteryx>the issue is that I'm not exactly good with (non-trivial) macros, despite trying my hand a couple times with them.
*apteryx reads tspl section 8.2 again
***alMalsamo is now known as lumberjack123
<apteryx>this is an interesting read:
***janneke_ is now known as janneke
<dsmith-work>Monday Greetings, Guilers
<sneek>I've been running for 14 days
<sneek>This system has been up 2 weeks, 1 hour, 17 minutes
<darth-cheney>hello all, is there a known module for parsing HTML, ie could be used in scraping?
<darth-cheney>My Google-fu is failing on this one
<dsmith-work>darth-cheney: Um. yeah
*dsmith-work tries to remember..
<darth-cheney>dsmith-work: yeah seems that still requires using xpaths, which is fine. I found an example on the mailing list I think, thanks
<apteryx>darth-cheney: if you need more actual examples you could look in the Guix code base, especially the Go packages importer.
<apteryx>here's the syntax I'm juggling with:; doesn't work thus far
<lilyp>apteryx: (replacement (as-display)) looks wrong
<lilyp>should probably be one level of brackets less
<apteryx>the current source now reads:; still not working
<apteryx>with error: source expression failed to match any pattern in form (replacement-helper ((string-append "(def[a-z]+[[:space:]\n]+" "gnugo-xpms" "\\>") "#'gnugo-imgen-create-xpms" (as-display)))
<apteryx>OK, this works:
<apteryx>as usual, parameterizing macros feels clunky (leads to duplication in the template, or convoluted helpers). If a macro expert is able to streamline this, I'd be happy to learn how it can be done.
<lilyp>for the record, you could avoid this at all by writing '( function gnugo-imgen-create-xpms) instead
<lilyp>elisp #' is simply an alias for function IIRC
<apteryx>indeed; "The read syntax ‘#'’ is a short-hand for using ‘function’."
<morenonatural>hey, y'all … is `with-output-to-string` not supposed to capture output of `system` (or `system*`) calls?
<lilyp>with-output-to-string is no port redirection, see pipe for that
<lilyp>or well, maybe it redirects ports, but it doesnt affect libc file descriptors
<lilyp>so you could call to printf and still print to stdout for example
<morenonatural>I see… I thought I was being convoluted, but I gues I was capturing stdout the right way
<morenonatural>and what about stderr? is there a convenience procedure to capture a command's stdert?
<lilyp>dup is your friend I guess :P
<morenonatural>ok, thx
***lampilelo_ is now known as lampilelo
<dadinn>hi all
<dadinn>I have submodule structure in my guile project using git, and I use (add-to-load-path (dirname (current-filename))). This used to work fine, and I was able to use-module the the submodules. Now I check out the code on my remote Debian server, and it fails to run. It complains about (dirname #), which never was a problem before.
<dadinn>on both my local machine, and on the remote server I have Guile version 3.0.5. :/
<dadinn>any suggestions why this might be happening?
<dsmith-work>dadinn: What version used to work? Check the NEWS file and see what changed between those versions.
<dsmith-work>dadinn: You might need to use an eval-when
<dadinn>dsmith-work: it's working on my local machine, but it's not working on the remote server. Both Debian Bullseye, both Guile version 3.0.5
<dsmith-work>Could the %load-path be different? Could there be some old cached files under ~/.cache/guile/ccache ? Could there be more than one version of libguile installed?
<dsmith-work>So, *something* has to be different, right?
<dadinn>dsmith-work: hmm, I have some 2.2-LE-8-3.a/ and some 3.0-LE-8-4.4 subdirectories under ~/.cache/guile of all my code's .go files
<dadinn>it might be that it is working because it is still really running the 2.2 cached code?
<dadinn>dsmith-work: is it safe to delete the ~/.cache/guile directory? Does it mean I the code will just recompile the next time I'll run it?
<dadinn>I assume it might be the case that once recompiled against 3.0 it will fail even locally?
<dsmith-work>Yeah, it's safe to blow that away. Will come back when Guile compiles somehing.
<dsmith-work>There is versioning in those files, so a 3.0 shouldn't be using a 2.2 file
<dsmith-work>But maybe you are picking up a 2.2 libguile?
<dsmith-work>Just trying to come at it from a "what could possible be different" perspective.
<dadinn>the only things in the cache which is not my compiled code is ../usr/share/guile/2.2/ice-9/readline.scm.go ... and ../system/repl/debug.scm.go
<dadinn>dsmith-work: hah, after I cleaned the cache, not it fails locally too!
<dadinn>so it is something with guile-3.0 ?
<dsmith-work>So now you might need to look at eval-when:
<dsmith-work>Just guessing that editing the %load-path is not happening the same for all passes of the compiler/loader/expander etc.
<dadinn>dsmith-work: I am assuming that current-filename is the macro here? Or is it add-to-load-path?
<dsmith-work>sneek: guile help add-to-load-path
<sneek>`add-to-load-path' is an object in the (guile) module.
<sneek>Add ELT to Guile's load path, at compile-time and at run-time.
<dsmith-work>sneek: botsnack
<dadinn>what's an ELT?
<dsmith-work>element I would guess
<dsmith-work>dadinn: It's in boot-9.scm
<dsmith-work>Take a look
<dadinn>dsmith-work: I've tried (eval-when (expand load eval) (add-to-load-path (dirname (current-filename))))
<dadinn>doesn't work
<dadinn>with compile neither
<dadinn>is there any more trick here?
<dadinn>fortunately Bullseye still supports guile-2.2
<dadinn>next time I'll have to read the release notes! :D
*civodul grumbles at primitive-load being a continuation barrier
<dadinn>holy shit, I'm now i a sitation on Debian when I uninstall guile-3.0, 2.2 immediately gets installed instead. When I remove 2.2 it's 3.0 gets installed!
<dadinn>I must have digged a deep grave here... let me lie down
***ec_ is now known as ec
<daviid>dsmith-work: add-to-load-path takes care of modifying the path both at compile-time and at run-time [from the manual]