IRC channel logs

<mwette>ArneBab: That 00-repl-server.test is VERY sensitive to any changes. I tried many things. Nothing works.

<mwette>If you want to revert to GUILE_QUIET env variable for everything I won't complain.

<mwette>cpli: found more prob's w/ renamer, but did add context internally; enabling with #:renamer will be an issue: not easy to make backward compatible

<mwette>or maybe not

<dsmith>sneek, botsnack

<sneek>:)

<ArneBab>mwette: I like your change for the compilation messages a lot. That wasn’t my problem, but it is a solid improvement which fixes an issue people had for years and years.

<ArneBab>mwette: so unless civodul or wingo want to veto that, I would merge your patch without the welcome message change. Then we can finally silence the compilation messages.

<civodul>ACTION doesn’t know what patch we’re talking about :-)

<ArneBab>civodul: about the patch by mwette adding the -I commandline switch that silences the compilation messages. It adds an info-output-port in addition to the warning output port, and -I silences the info port. https://lists.gnu.org/archive/html/guile-devel/2024-10/msg00013.html

<ArneBab>civodul: this started as alternative to adding GUILE_QUIET as environment variable (to silence the welcome message: https://lists.gnu.org/archive/html/guile-devel/2024-01/msg00007.html ), but should actually stand pretty well on its own, because it fixes the long-standing annoyance that compilation messages clobber the output of simple commandline scripts.

<civodul>oh i see, thanks ArneBab

<civodul>have you considered adding a variable that one could set in ~/.guile?

<civodul>i would prefer something along these lines, keeping env vars for rare generic/crosscutting concerns

<old>IMO, I much prefer the granularity of environment variable compared to .guile. I might want to quiet down the compilation info on a invokation basis

<old>Both are not mutual exclusive

<civodul>right, but the patch uses GUILE_QUIET (generic-sounding) for only one specific purpose: the REPL greeter

<civodul>for the REPL-greeter, i think it’d be fine to let users add (set! %greeter? #f) in ~/.guile

<old>ah it is only for the greeter or also for compilation message?

<civodul>(i thought there was already such a variable, actually)

<old>(haven't check the patchset)

<civodul> https://lists.gnu.org/archive/html/guile-devel/2024-01/msg00007.html is just for the greeter

<civodul>but then there’s another patch

<civodul>maybe i should look more closely and talk less :-)

<old>(-:

<mwette>civodul: there were two solutions proposed: one used GUILE_QUITE env var; the other, adding current-info-port to absorb compile messages previously sent to warning port, and command line arg -I to set current-info-port to /dev/null.

<ArneBab>civodul: the current-info-port change is the more elegant one, but when applying it to the greeter, it breaks backwards compatibility (because the greeter is by default stdout while the other messages are stderr).

<mwette>So we add an extra global %greeter? to snuff the welcome message? I have not dug into that idea but will do so.

<ArneBab>old: I did the smallest change possible for GUILE_QUIET to make it possible to simply use the output of guile blocks in babel without postprocessing. I’ve been running that patch locally for some months now.

<ArneBab>mwette: there actually is already an option for that — see https://www.draketo.de/software/shell-tricks#inline-gpg-verification-bash

<ArneBab>mwette: guile -c '(set! (@@ (system repl common) repl-welcome) (λ _ #f))

<ArneBab> (eval (read) (current-module))' <<- EOF

<ArneBab> (display "Hello \n")

<ArneBab>EOF

<ArneBab>but that’s an annoying hack for a pretty common requirement when scripting.

<old>This all makes me think of inhibit-message in emacs

<old> https://scripter.co/using-emacs-advice-to-silence-messages-from-functions/

<old>really would like a "advice" thing in Scheme

<ArneBab>yes, something like that — but for the invocation of Guile itself. And the equivalent tool for that is an environment variable.

<ArneBab>old: isn’t advice similar to module-set! in non-declarative modules?

<old>ArneBab: I would have implement advice as a primitive in the VM

<old>In VM_DEFINE_OP "call", iterate over a list of registered advice before/after

<mwette> old: is that similar to Guile's hooks?

<old>mwette: I guess, but hooks need to be define as object

<old>The way I see advice is that, I can add hooks to any function, before/after the call without the function knowing about it

<old>This is equivalent to kprobe return probes work in the linux kernel

<old>Call a list of callbacks before and after entering/leaving the function

<old>without the function having to call `run-hook'

<weary-traveler>ArneBab: iiuc, neither the -I nor the GUILE_QUIET patches have been merged, correct? (but hopefully will be soon™)

<mwette>How about this in .guile? `((@ (system repl repl) %inhibit-welcome-message) #t)'

<weary-traveler>mwette: does that work today, or you're communicating how it might in future?

<mwette>I just put it in, and it does not break the 00-repl-server test.

<mwette>not in yet, wanting to see if acceptable solution

<ArneBab>weary-traveler: they are not yet merged, no. I’m just waiting for a "no veto from me" answer from civodul or wingo

<ArneBab>mwette: will you merge it yourself?

<ArneBab>(I have push access, but I’m limiting it to small or obvious changes because that’s what I got that for)

<weary-traveler>ArneBab: understood. i look forward to it. i recall having to take some steps to get rid of the compilation messages

<mwette>I don't have push access, if that is what you are implying. I can send to the devel list, when I clean it up.

<ArneBab>mwette: so if there’s no veto, I’ll merge and push it.

<mwette>great - have a good day

IRC channel logs

2024-10-07.log