<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 6.6.6.5 Extended Read Syntax for Symbols <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 ... <daviid>in the defvar, you want a string? <apteryx>when I attempt to provide it as a symbol that makes it '\#gnugo-imgen-create-xpms... confusing <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
***janneke_ is now known as janneke
<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? *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. <lilyp>apteryx: (replacement (as-display)) looks wrong <lilyp>should probably be one level of brackets less <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>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 ***lampilelo_ is now known as lampilelo
<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. <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? <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>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>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? <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. <dadinn>dsmith-work: I've tried (eval-when (expand load eval) (add-to-load-path (dirname (current-filename)))) <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]