IRC channel logs
2026-05-05.log
back to list of logs
<rlb>utf8 branch has been updated to include the new "basis strings" (promotion of stringbuf to an inline immutable string subtype) <rlb>The docs have not been updated, but that's generally true, i.e. for now I'm waiting to see how things look to others, and what, broadly, might need changing, before pursuing that. <rlb>For example, I don't want to update the docs until we know what we want to call various things (like, atm, "basis string"). <rlb>Hah, I suppose in some sense these are both Immediate and Immutable... <apteryx>when re-reraising an exception in the with-exception-handler handler, should #:unwind? #t be used? I've seen this pattern and was wondering if it was correct/needed. <rlb>It depends on what you want, but in general I'd say yes, you may want #t --- that's more like the behavior of try/catch, etc. Among other things, if you say #t, returning from your thunk will return from the with-exception-handler call, instead of from the raise-exception call. <rlb>The context of the execution of thunk is also different --- there's elaboration in the info pages, but I've thought before that we should add some examples there too... <GalaxyNova>but inside of a `guix repl` when I try to `(use-modules (ice-9 posix))` I get `no code for module (ice-9 posix)` <apteryx>rlb: I had read the info pages, but still unclear on things. <apteryx>GalaxyNova: I think these are part of the regular environment already <apteryx>I also don't see a (ice-9 posix) module mentioned in the manual <janneke>sneek: later tell yelninei: good call wrt --enable-cpus=8 for 32-bit, it gets *very* slow with only 4GB of memory, and we don't have pae just yet, have we? <janneke>oops, that should have been #guix, oh well, sneek doesn't care, do they? <apteryx>janneke: IIRC the Hurd had PAE for a long while for 32 bit <janneke>apteryx: thanks, /me is going to try; let's take this to #guix? <janneke>hehe, the hurd experts live in #hurd, i guess <old>apteryx: you can re-raise an exception like you want. `#:unwind` does not play into this. However, if you pass `#:unwind #f`, you have to raise something (a new exception or the one received) if the catched exception is not continuable (must exception are not continuable) <old>this is because when you do `#:unwind #f`, you see think of the handler running at the point where the `raise-exception` happened <old>if you just return from the handler, you are effectively continuing the program at the point where the raise happened. <old>anyway, you can re-raise the exception on both cases <apteryx>#:unwind #f is the default, if I read correctly <apteryx>good to know that for 'raise-exception caught-exception' (re-raising) cases, it doesn't matter <apteryx>old: maybe you meant #:unwind #t instead of #:unwind #f in your explanation? <apteryx>I would expect #:unwind #f (the default), to include the frame of the handler itself, but with #:unwind #t the last frame to be unwound back to where the exception was raised (before the handler runs) <old>without unwinding, you have the frame of the caller of raise-exception <old>but you need to raise an exception if the original exception was not continuable <old>it can be a new exception, not stricly the one you received <mooseball>is there a way to point geiser to guile sources installed via guix? for me the [source] button in the documentation buffer is broken. <mooseball>i looked in geiser customizes and found nothing <mwette>I'm no expert at geiser. But, in the repl you can brute force via `(add-to-load-path "/path/to/guix"); inside your emacs init.el file I believe you can `(setq geiser-guile-load-path (list "/path/to/..."))'. <mwette>and I assume guix generated path is "~/.guix-profile/share/guile/site/3.0" (and w/o "/3.0") <mooseball>hm so the load path is correctly pointing to the guile sources <mooseball>it even has my /gnu/store/xyz/guile.3.0.9/etc paths, which is what i figured was missing <ieure>mooseball, (setq geiser-guile-binary '("guix" "repl")) <ieure>It defaults to the guile repl, which doesn't have the load-path for Guix stuff, telling it to use the guix repl fixes that. Least, it did for me. <mwette>ieure: That's for guix itself versus "sources installed via guix" ? <ieure>mwette, Good question, not sure. I would assume that stuff installed in the active profile would be loadable by Guile. <mooseball>ieure: how is that an ok value for the variable? <ieure>mooseball, Because geiser's customization interface is incorrect. <ieure>It does not break it for me, though the customization UI doesn't work right. <ieure>From my system right now, with a working geiser: geiser-guile-binary is a variable defined in ‘geiser-guile.el’. Its value is ("guix" "repl") <mooseball>so you are running "guix repl" as your geiser exec <mooseball>but it can't accept the args geiser wants to send it, so breaks <ieure>Please paste the value of geiser-guile-binary you set. <ieure>I'm confused, I thought you said setting it to '("guix" "repl") broke geiser? Did you change it back? In what way did it break? <mooseball>yeah i set it back pronto coz it broke geiser! <ieure>What did you set it to, and how did it break? <ieure>I've had this configuration a good while and haven't had any issues. <mooseball>Process Guile REPL<1> exited abnormally with code 1 <mooseball>am not so convinced that running guix repl is the solution tho <mooseball>(i mean, just to get jump-to-source to work...) <ieure>M-. on a symbol for a thing in Guix opens the source for me when I'm hacking code for my Guix channel. <ieure>It can't find the Guile code if I put point on that stuff and M-. though. <ieure>Just "Couldn't find location for `define-module'" <mooseball>for me M-. works for libraries, but not if the function is in guile itself.