IRC channel logs

<mwette>The manual only says that, as I can see, you may use #u8 (srfi-4) routines to access #vu8() (bytevector) objects. I dug through the code a little while ago and it looks like underneath most things (vectors, arrays, srfi-4, bytevectors) is bytevectors. See DEFINE_SRFI_4_C_FUNCS in srfi-4.c

<lechner>mwette / thanks! I just explored it in the REPL, and it's eq? #t all around. Should I use one notation over the other? I have a lot of literals.

<mwette>I guess depends on context. If just char buffers then #vu8() if other types involved then #u8().

<lechner>the only difference seems to be in display!

<dsmith>!uptime

<sneek>I've been aware for 2 months

<sneek>This system has been up 12 weeks, 4 days, 4 hours, 27 minutes

<dsmith>sneek, botsnack

<sneek>:)

<janneke>ArneBab_: congrats and thanks for the headsup! i'll have to see what this does for our 64bit mingw binaries or patch set; but i guess it's better to wait for #86 anyway

<janneke>ah, great; i see spk121 has been involved in the review, possibly he has already rebased (parts of) our work somewhere

<janneke>hmm, many package updates to master, are these all fixes for the release?

<janneke>sorry; that was meant for #guix, of course

<janneke>ACTION manages to build wip-mingw-2026 and provides a pull request that shows `main' doesn't support x86_64-mingw32 just yet

<janneke>fwiw, wip-mingw-2026 segfaults for me; tomorrow i'll have a look at wip-mingw-2025

<yelninei>sneek: later tell civodul thanks a lot for the quick fix

<sneek>Will do.

IRC channel logs

2026-01-06.log