IRC channel logs

<dsmith>old, I've often thought it would be nice to have something like that. Kind of like re-implementing make, but with more smarts of module internals.

<mwette>check out `module-observe-weak' in boot-9

<apteryx>looking at the doc of 'spawn', it looks like (spawn "hello" (list "hello")) should be valid, but it's not: In procedure spawn: Wrong type argument in position 3 (expecting open file port): #<input:soft-port 7ff1c3948820>

<czan>Is that soft-port the value of (current-input-port)?

<apteryx>yes

<apteryx>that's with Guile 3.0.11

<czan>Does spawn need a port for which file-port? returns #t, or something? I don't know. Are you running this at a REPL?

<apteryx>yes, I'm testing from a Geiser REPL

<czan>See, for me (current-input-port) returns #<input: file /dev/pts/0>, and spawn works as I expect.

<czan>In a Geiser REPL.

<apteryx>actually I lied, that experiment was from a M-x shell -> guile, so maybe that explains that

<czan>Yeah, and using with-input-from-string around the spawn causes it to fail with the same error message. So I think you'll need to work out why your ports are soft ports instead of file ports.

<apteryx>I'll retry from a proper Geiser REPL to see if it improves things

<czan>Ah, yeah, I see the same thing with running guile in M-x shell.

<apteryx>the reason I was doing it that way was because it was easier to setup the environment (guix shell -D ...)

<apteryx>ACTION falls back to good old sledgehammer M-x guix-set-emacs-environment RET /gnu/store/kadwwrynwrvf8h59b32ww21rsf0vymbf-profile RET, where the profile is taken from $GUIX_ENVIRONMENT

<czan>Yeah, fair. I use emacs-envrc to set up my guile environment. Just a .envrc with "use guix -Df guix.scm" or "use guix -D whatever-package" usually does what I need (after an M-x envrc-allow).

<apteryx>this sets these globally; I should look again into tusharhero's efforts at improving this here: https://codeberg.org/guix/emacs-guix/issues/8

<apteryx>ah, emacs-envrc would set the environment variables as directory-local, which would be an improvement over guix-set-emacs-environment, IIUc.

<czan>It also sets things buffer-local, which is nice.

<apteryx>nice

<czan>Anyway, I'm going AFK for a bit now, so good luck with whatever solution you end up choosing. :)

<apteryx>thanks for the help :-)

<apteryx>czan: looks like 'guile' alone (not in M-x shell in emacs, but from a plain bash shell), always give you a soft-port object as (current-input-port)

<czan>That's true for me too, but in a "guix shell guile --pure" it doesn't. I wonder if it's related to readline, or something.

<apteryx>ah yes, it's due to guile-readline. weird

<apteryx>I don't care about the input port; is there a value I could provide as spawn's #:input to make it work in all situations?

<apteryx>this didn't work: #:input (%make-void-port "r")

<apteryx>I would have thought #f could have meant "don't bother setting up a pipe for that" but apparently not

<apteryx>(open-file "/dev/null" "r") does it

<apteryx>weird that %make-void-port would be different

<apteryx>shouldn't this line in a .envrc : "use guix --no-grafts -D -f guix-dev.scm" be "guix shell ..." instead?

<apteryx>no, apparently direnv has native support for guix, interes56g

<apteryx>interesting*

<rlb>Is our utfN->string wrong? This says that invalid input sequences should produce the replacement character U+FFFD, but right now we use iconveh_question_mark: https://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-3.html#node_sec_2.9

<jcowan>Yes, that's wrong. You should only use ? when transcoding to a charset that doesn't contain U+FFFD (namely most of them)

<rlb>iconveh_question_replacement_character

<rlb>I don't know offhand whether we can fix that in a Z release, but I'll fix it in utf8 at least.

<jcowan>s/transcoding/encoding

<rlb>...the apis we have available right now are a little bit frustrating at times.

<rlb>(in C)

<rlb>e.g. atm libunistring doesn't know or care about endianness, and iconv() can't portably report bad characters (on musl it just replaces with "*" and on some *bsds with "?"), and so far I don't see any gnulib portable replacements (iconveh, etc.) that can either (naturally) handle a single char (so you can know how much of the source was consumed), or allow you to compute the byte and char sizes without allocation.

<rlb>i.e. I want an "encoded_char/byte_len(enc, x)" to compute the utf-8 byte and char sizes before allocating the result.

<rlb>or if libunistring had a variant of u32_to_u8 with an endianness parameter, that'd also work

<rlb>etc.

<rlb>I can still solve the problem, we're just going to do pointless work (either extra passes, or unnecessary allocation in some cases).

<rlb>(looks like we also don't handle the endianness-mandatory argument ye, assuming we want to)

<jcowan>Unless you are concerned with running on s390, it's not worth bothering about.

<rlb>I don't understand why the iconveh "whole string" conversion functions don't also return the character count at the end, unless the answer somehow "depends".

<rlb>(instead I have to traverse the result to figure out what happened)

<rlb>...libunistring 1.3 documents iconveh_question_replacement_character but (apparently) forgot to add it to its headers.

<rlb>:/

<rlb>oh, it has a different name.

IRC channel logs

2026-04-14.log