IRC channel logs

2024-11-25.log

back to list of logs

<lechner>Hi, is there a command-line option that "writes" out the (last) evaluated result of '-c' or '-s'? It would be a little bit like Perl's '-p'. Thanks!
<lechner>I think it would make one-liners easier. Otherwise I have to write something like: guile -c '(use-modules (ice-9 textual-ports))(call-with-input-file "config.scm" (lambda (port) (write (eval-string (get-string-all port)))))'
<old>lechner: you could just do: -c '(pk expression ...)' ?
<lechner>old / i can't find 'pk' in the manual but it looks like it comments the result?
<lechner>How may I evaluate 'sample.scm' and use the result elsewhere?
<lechner>i'm in the shell but the executable is not allowed to eval because it's setuid
<lechner>so i'm passing it the expression evaluated as my user, kind of the way Guix does it for configurations
<lechner>Hi, what is a "module excursion" in the manual for 'eval-string', please? Also, is there a way to refer to the current line number in a file, for the #:line argument, like $. in Perl?
<graywolf>lechner: Hi! :) (I swear I am not stalking you)
<graywolf>For the line you can give try to: (assq-ref (current-source-location) 'line)
<graywolf>For the module excursion, my understanding is that if you pass some @var{module} to the procedure, it will switch to it and ("save a module excursion") once the eval is done restore back the previous module.
<lechner>okay, thanks for both! i appreciate your presence---especially last night. you supercharged my development efforts
<graywolf>^_^
<mwette>I think `port-line' works.
<lechner>actually, i can just use 'load' except it has a bug with relative path names
<mwette>for ports
<graywolf>"bug with relative path names" is there a bug report?
<lechner>load evaluates relative to the location of the calling script, not getcwd
<lechner>i haven't yet, but it yields funny results especially on nested calls to load
<lechner>it's also documented but i think it's a bug
<mwette>(load-in-vinicty (getcwd) "file.scm")
<lechner>mwette / yay and thanks!
<msavoritias>anyone has a guide how to decypher guile errors? for example this is part of an error I got
<msavoritias>In unknown file:
<msavoritias> 5 (apply-smob/0 #<thunk 7faab7705300>)
<msavoritias>searcing in the manual there is no mention of what this means.
<mwette>msavoritias: sometimes you get more info if you `guild compile -O0 file.scm' on your scheme code.
<lechner>mwette / thanks again! that just made a lot of things simpler in guile-pam
<msavoritias>mwette that actually gave even less than that :/ it basically has one line saying
<msavoritias>$ guild compile -O0 Connections.scm
<msavoritias>wrote `/home/fannys/.cache/guile/ccache/3.0-LE-8-4.7/home/fannys/mutable/Engineering/My Projects/Applesauce/Guile_XMPP/Guile_XMPP/Core/Connections.scm.go'
<mwette>now run your code
<msavoritias>you mean `guile /path to file/Connections.scm.go`?
<mwette>no: `guile /path/to/connections.scm'
<msavoritias>hmm. it does have one more line. but the message is still basically the same. this time thunk is:
<msavoritias>In unknown file:
<msavoritias> 6 (apply-smob/0 #<thunk 7f33c7115300>)
<msavoritias>in the sense that there is a message on the bottom saying
<msavoritias>In unknown file:
<msavoritias> 0 (_ #<procedure 7f33c6cc7738 at Connections.scm:21:0 (on…>)
<msavoritias>ERROR: Unbound variable: new-onion-netlayer
<msavoritias>so i can kind of get what this says. but i still have no idea what the rest of the message means
<msavoritias>the full message -> https://paste.debian.net/hidden/a9cddd64/
<mwette>the hint is connection.scm, line 21
<dthompson>that's a backtrace being printed from an error caught in a goblins vat fiber :)
<msavoritias>right. is there any guide how to read backtraces? i am looking into https://www.gnu.org/software/guile/manual/guile.html#Interactive-Debugging-1
<msavoritias>but none of the errors here look like this.
<msavoritias>searching for backtrace in the manual it writes about the api mapped to C functions but no examples either
<msavoritias>my reasoning is that the rest of the error can't be useless and i only have to look at the last line :P (unless i am missing something)
<mwette>I usually just use the last line.
<msavoritias>XD thing is Guix errors are a lot of the time much more "mystical" to me still. So it would be interesting to learn what exactly it means.
<msavoritias>Sounds like I know my next piece of Documentation for Bechamel at least: "Anatomy of a Guile error"
<mwette>msavoritias: for that you may want to dig into the Guile Implementation part of the Guile Manual. say, A Virtual Machine for Guile, Instruction Set
<msavoritias>noted thank you :D
<mwette>I've tried times in the past to work on the debuging capability. There is a lot there already, but a lot of work to go to make it significantly better, I think.
<lechner>Hi, what's the convention for prefixing variable names with '%'? Are those association lists?
<dthompson>lechner: generally reserved for low-level things. like you might have a public procedure 'foo' that wraps a private, lower-level procedure '%foo'
<lechner>dthompson / thanks!
<dthompson>np, it's a weird little naming convention that no one explains. people kind of just infer what it might mean and carry it into their own code
<graywolf>I wonder whether having more conventions would be good. I think I saw +var+ for constants somewhere.
<lechner>for my 2 pennies, it should be +variable+. I find most abbreviations too short
<graywolf>That was just an example, I maybe should have writen +ideal-water-temperature+ or something
<shawnw>That comes from Common Lisp convention.
<shawnw>*foo* for global dynamic/special variables, +foo+ for constants.
<graywolf>Interesting. Do you think there is value in doing that in guile?
<dthompson>I find *foo* useful for global mutables but I never reach for +foo+
<rlb>ACTION hasn't used +foo+ much, if at all, either.
<rlb>I thought I recalled % from common lisp, and looks like maybe it's a thing there sometimes too...
<graywolf>dthompson: "global mutables" as in parameters or just variables you set!?
<rlb>...I've seen *foo* for "globals" of any kind too, and/or for "dynamic vars" (parameters) (in clj, that's the norm -- i.e. always/only for dynamic bindings -- like guile fluids).
<dthompson>graywolf: not parameters, something you'd set! or otherwise use in a globally mutable way
<dthompson>parameters are not globally mutable
<dthompson>like sometimes I need a global hash table which I'd name *cache* or something
<mwette>I have used atomic-box for globals, but they are a bit of a pain.
<graywolf>I see, thanks
<dthompson>those are good when you need thread-safety and the data in the box is immutable
<old>parameters are usually prefix with current-
<old>since they are nestable and per thread
<dthompson>annoying in some ways but soooo much better than dealing with locks
<old>mwette: the main problem with atomic box currently is that everything has to be implemented with a cmpxchg operation
<old>would no be that hard to add support for add/sub without having to rely on cmpxchg
<dsmith>ISTR something about @earmufs@ being used for something too. (or is that *'s )
<daviid>lloda: could you, when tima allows, rebase your wip-exception-truncate patch on 'actual' main, we can't cherry pick it anymore, thanks