IRC channel logs

<rlb>Oh, wait, does get-bytevector-some* completely obviate (ice-9 rw)...

<rlb>yeah, maybe it does; though I don't see any corresponding put-bytevector-some*.

<sneek>tohoyn: Greetings!!

<tohoyn>daviid: it seems that "make install" in guile-fluidsynth doesn't install the documentation. is this intentional?

<tohoyn>sneek: botsnack

<sneek>:)

<tohoyn>daviid: now I get some documentation files installed when I build the debian package

<yarl>Hi

<spk121>rlb: in the latest updates, make distcheck fails on Ubuntu. It appears that srfi-13.test is searching for a module (test-suite data) that wasn't included in the distibution.

<spk121>you probably need to add it to EXTRA_DIST or something like that

<TheTaoOfSu>#lispgames

<TheTaoOfSu>whoops

<AwesomeAdam54321>Hi, I think I have a strange question

<AwesomeAdam54321>Is it expected that identical literal lists in the same program are shared under the hood, where mutating operations can inadvertently affect subsequent code (even though the lists aren't explicitly shared)?

<AwesomeAdam54321>I can't think of another reason why this test suite hangs in Guile (due to a circular list error) but works fine in MIT Scheme: https://codeberg.org/AwesomeAdam54321/mit-schemeboot/src/branch/main/src/tests/runtime/test-srfi-1.scm

<identity>AwesomeAdam54321: in general, literals are immutable and may or may not be shared, and the result of attempting to mutate an immutable object is unspecified in, at least, R⁵RS and R⁷RS, i.e. «it is an error»; in Guile, (eq? '(1) '(1)), and immutability of literals is supposedly enforced, but i am not sure about that

<identity>…which test hangs, exactly? the file is almost 300 lines long

<identity>AwesomeAdam54321: <http://logs.guix.gnu.org/guile/2026-05-17.log>

<AwesomeAdam54321>identity: The append-reverse! test hangs, but if I comment out the append! test then the test suite runs to completion

<rlb>spk121: yet again... Thanks, I'll fix it.

<rlb>spk121: hopefully fixed. And regarding rw -- yeah, the main issue is just that the current functions don't make sense with utf-8 because they're using a string to carry binary data as Latin-1. I also remembered that we have get-bytevector-some! which appears to perform as well as a read-string!/partial converted to bytevectors, so maybe there's no call for the latter now.

<rlb>spk121: Though not sure we have an obvious current parallel for a write-bytevector/partial.

<rlb>i.e. do we already have anything like get-bytevector-some* for writes.

<lechner>Hi, a recent, system-wide upgrade from 3.09 to 3.0.11 by the Guix maintainers is giving me warnings about incompatible bytecode versions. Was it not possible to store the new an incompatible bytecode at new locations in the file system?

<humm>anyone wanna take a look at https://codeberg.org/guile/guile/pulls/54 ?

<lechner>humm / looks reasonable to me, but I'm not a maintainer