IRC channel logs

<ArneBab>rlb: I agree, those compilation messages are totally annoying. I’d prefer to only see them when I pass --verbose. Or maybe with an environment variable GUILE_COMPILATION_MESSAGES or such (I sent a patch to devel that suppresses the startup with GUILE_QUIET — I’d love to get reviews on that; actually I’d love to get a "yes, go for it", but I’d also like to get some easily doable changes to get it merge-ready)

<Kolev>ArneBab: Is it possible to do my Guix config in Wisp? That would be fun.

<Kolev>ArneBab: Yeah, the compilation messages are not normal for other scripting languages.

<mwette>I sent proposal to add a current-info-port and use that to classify compile message and welcome message to info. IMO, those messages go against the (or my) goal to use guile as an extension language for domain-specific tools. https://github.com/mwette/guile-contrib/blob/main/patch/3.0.9/info-port.patch

<rlb>mwette: haven't had a chance to look yet, but offhand, logging-wise, I've generally seen "info" level enabled by default. Or maybe that's not what you mean. The non-default levels I've seen are generally debug or trace. But of course that might not be relevant for guile.

<kimjetwav>Here's a question: what explains the following?:

<kimjetwav>(let ((val (when #f #t))) (list val (if val 'a 'b)))

<kimjetwav>⇒ (#<unspecified> a)

<kimjetwav>Why does the `if' return 'a?

<haugh>kimjetwav, (unspecified? (if #f #f))

<jpoiret>well, unspecified is truthy, that's what it means. Usually everything but #f is truthy.

<kimjetwav>Iiiinteresting. I wasn't sure if that was what it was.

<jpoiret>usually one shouldn't rely on unspecified values

<jpoiret>it's imo a problem a schemes that one can return zero or multiple values, something that other functional languages handle way better 🙃

<kimjetwav>I wasn't, of course, I was just doing something else and was like "wait, will this bust if I `when' vs `if'?"

<haugh>,exp(when #f #f)

<kimjetwav>jpoiret: Yes I started testing with `values' as well to see if I could get other surprising results.

<kimjetwav>But that's good to know.

<lloda>i'd be glad to get rid of that use of *unspecified*. I wonder how much stuff would break if we did

<haugh>I'm nobody, but lots of my stuff would break. In my opinion, the only relevant issue is a general uncertainty about multi-value truth. I have an augmentation of srfi-8 which treats (values) as truthy and (values #f #t) as falsy, implemented by transforming the FORMALS form. This, in conjunction with multi-value-literate extensions to SRFI-235, make Guile's flexibility on this issue an asset rather

<haugh>than a liability.

<haugh>I will share this library once I'm less confused about merging MIT and GPL3 licenses

<Arsen>they're compatible, so you should be able to ship both together as GPL3

<Arsen>(since MIT code can be distributed under the GPL)

<kimjetwav>lloda: Yeah, obviously this is all idle talk, but I'm not a fan of unspecified showing up.

<kimjetwav>Feels weird.

<lloda>it's cruft from before scheme got multiple values

<lloda>(if (values) ...) is an error and will always be, so making (values) testable in other contexts isn't something i'd do

<haugh>I need to compose polyvariadic functions up in here

<kimjetwav>lloda: By `(values)' I assume you don't mean `(values …)', right?

<lloda>no i mean (values)

<kimjetwav>Okay, thought so.

<kimjetwav>lloda: I guess that gets into the weeds of, at which stage do you want your (values) form to be caught as an error.

<kimjetwav>Guile as is lets the form evaluate and the complains as it notices the number of values popped off the stack is wrong.

<kimjetwav>There's a paper in this: Values Should Not Evaluesate Its Arguments. I think somebody may have scooped the idea, though.

<ArneBab>Kolev: currently you could only write the config in wisp and then convert it to parenthesized Scheme with wisp2lisp /etc/config.w > /etc/config.scm

<mwette>rlb: I'd love to have info /dev/null by default, but the current behavior of guile is to display informative messages.

<mwette>If folks agree, I will change the patch and make info /dev/null by default, with arg `-i /dev/tty2', say, if you want it.

<old>mwette: I'm all for a info port. Just add an option like `--info=FILE' ? This way we can do: `--info=/dev/stderr' if we want

<rlb>Also wonder whether we'd want more ports or port-indepdent selectivity, i.e. are the existing output and error ports more aligned with the stdout stderr conventions, or the semantic contents?

<rlb>(I'd originally just been imagining changing the defaults, and/or having some way to turn them on/off -- maybe just move them to --debug or some --verbose or..., dunno).

<dsmith>Ya, *something*. Getting compiling messages all the time without being able to turn then off is annoying.

<mwette>OK, let me clean up the patch; currently -I just sets to /dev/null; see https://github.com/mwette/guile-contrib/blob/main/patch/3.0.9/info-port.patch

<mwette>I'll change to: -i /dev/stderr -i /dev/null ; but what should the default be? /dev/null or /dev/stderr?

<old>mwette: I tend to avoid breaking thing. In the small chance that someone relies on this information to be on stderr, I would default to stderr

<old>however, this require to do `-i /dev/null', which mean it is not compatible with older version of Guile

IRC channel logs

2024-05-02.log