IRC channel logs

2024-12-13.log

back to list of logs

<rlb>dthompson: wrt names, I'd vaguely wondered about something perhaps like (guile persist map) and (guile persist vector) modules, and then pmap-* and pvec-* for the operations, or pvector-* if prefered.
<rlb>But haven't though of anything I *really* liked.
<rlb>"thought"
<sneek>dsmith: Greetings!
<dsmith>sneek, botsnack
<sneek>:)
<dsmith>!uptime
<sneek>I've been faithfully serving for 3 days
<sneek>This system has been up 3 days, 8 hours, 22 minutes
<xelxebar>Okay, dumb question, how do we connect to a repl server?
<xelxebar>I guess ncat is sufficient?
<ekaitz>xelxebar: yes
<ekaitz>xelxebar: you can use telnet too
<bryce_m>In the reference manual for let*, "Similar to let, but the *variable bindings* are performed sequentially, that means that all init expressions are allowed to use the variables defined on their left in the binding list."
<bryce_m>That pretty much means that the *init* expressions have to be *evaluated* sequentially .... but it doesn't say that, and I wonder if a smart evaluator could parallelize init expressions that didn't refer to each other.
<dsmith>(let* ((a 1) (b 2)) (cons a b)) is the same as (let ((a 1)) (let ((b 2)) (cons a b)))
<bryce_m>there's no case where 2 could be evaluated before 1 according to spec?
<bryce_m>R7RS has similar wording as the Guile Reference manual. I'm just worried that the binding doesn't mean the same thing as evaluation order for a "smart" evaluator that recognizes it could evaluate 1 and 2 in parallel.
<apteryx>how can I programmatically refer to a variable from the current module?
<apteryx>(resolve-module (current-module) 'name) doesn't work because (current-module) returns an object, shoud be a plain module name
<civodul>apteryx: it’s no possible in a general context because the variable’s body might have been inlined, etc.
<civodul>there’s no guarantee that it “exists” as a first-class object at run time
<apteryx>I'm working in the Guix special case, where the variables are packages, so out to exist, right?
<apteryx>ought*
<civodul>yes, because they’re exported and we turn off cross-module inlining and other optimizations for package modules
<civodul>yet! reflection is a double-edge sword :-)
<civodul>i mean: (module-ref (resolve-interface '(gnu packages whatever)) 'my-package) would work
<apteryx>ah, module-ref; that's the one I was forgetting, thank you
<civodul>whether to use that power is a good idea is a different question :-)
<apteryx>the use case I'm experimenting with: https://paste.debian.net/1339674/
<apteryx>clearly still full of bugs and pks but you get the idea
<civodul>i see, nice
<civodul>in this case, i would probably go for an explicit mapping between bootstrap and non-bootstrap packages
<civodul>with an alist or something
<apteryx>I see. That may be a bit easier to comprehend on a first read yes.
<civodul>yeah
<civodul>less “magic” and it’s all greppable
<apteryx>civodul: there's another problem with my idea; the package generators are evaluated at the top level, which is too eager -- most bootstrap definitions needed are defined only later
<civodul>oh, right
<johnjaye>does guile have a 'scheme shell' mode? i see something in the NEWS file about accepting SCSH style arguments.
<shawnw> https://www.gnu.org/software/guile/manual/html_node/The-Scheme-shell-_0028scsh_0029.html
<rgherdt>Does anyone have a minimal example of using traps? Like outputting some text if a procedure is called? I'm trying following:
<rgherdt>(with-default-trap-handler (lambda args (display "Hello from trap-handler\n")) (lambda () (display "Hello world!\n")))
<rgherdt>It only outputs "Hello world!", I would expect to see "Hello from trap-handler" also
<mwette>I think you need to add a trap, like add-trap-at-procedure-call!
<rgherdt>mwette: it worked, thanks!