IRC channel logs

<mwette>guile has a lot of action going these days

<mwette>kudos to the guix and spritely teams

<rlb>wingo: I'll look again more carefully, but offhand does the new reader to anything with wide chars independently of strings.c? I'm seeing some behavior that's most likely just a bug in my new code, but looks like something I didn't expect is still passing around wide char arrays in memory.

<rlb>(and I did rebase on top of current main a bit back, so all the newer code is there, fwiw)

<rlb>Also want to trace the path of a '(write "something\n") via "guile -s script". By the time it gets to write_string(), the data's already wrong.

<rlb>(in my tree)

<rlb>s/to anything/do anything/

<rlb>(oh, but only when "something" is the string from test-mb-regexp)

<rlb>i.e. not ascii

<rlb>Ahh, maybe the assembler (at least). Perhaps I'd deferred paying attention to dependencies on string-bytes-per-char for too long. Had mostly focused on tag/wide-flag references so far, but looks like that missed some sites.

<spk121>rlb: a million years ago, when I was working the 1st rev of Guile Unicode, I coerced GDB into giving backtraces every time I hit read/write, which I made into plot with graphviz, just so i could figure out the actual routes strings took into the code

<spk121>wouldn't be helpful now that Guile spends more time in the scheme VM, but, it was a fun trick back then

<rlb>wingo: in my current arrangement there are two types of stringbuf, ascii and utf-8 (the latter is currently never modified in place, i.e. copied entirely on every string-set!), and ascii stringbufs have the same two header cells (type and char-n). utf-8 stringbufs have three, type, char-n and byte-n. I'm to the point where I need to adjust the assembler and wondering how that should look.

<rlb>iirc we mmap those? If so, then we can't maintain backward compat?

<rlb>Well, at least not naively.

<rlb>spk121: interesting.

<rlb>...perhaps there's some kind of "poisioning"-ish approach we could take where we tag the new utf-8 format with a different bit, and then we'd have to have all the relevant paths detect old/wide instances and immediately convert to utf-8 if we didn't want a hard-break.

<rlb>Anyway, just wondering if you might have already had a plan for this bit.

<rlb>(fwiw, in the current tree I've withdrawn effectively all access to stringbufs from code outside strings.c, so it wouldn't be nearly as daunting to do something like that if we needed to)

<rlb>Also, the current plan is for utf-8 stringbufs to be even longer than just the 3 cell header plus the bytes -- they'll also have the variable-grain offset index. Alhough its length can be computed directly from the char count, so overall length will be 3 cells + byte_count + alignment + index-length.

<rlb>The offset index will be at the end both so that code that doesn't care about it won't have to jump past it (better I think for short strings wrt cache, etc. -- may even omit it for strings under N chars).

<wingo>sneek: later ask civodul would it be ok if bytevector-slice where start is 0 and count is bytevector len, if it just returned the source bytevector?

<sneek>Okay.

<wingo>good morning civodul :)

<civodul>heya!

<civodul>re bytevector-slice, sure

<civodul>it wouldn't change the semantics so that's ok

<civodul>probably an uncommon case though

<wingo>oh i dunno, in the case of ports i would think it could be very common

<wingo>for example when you write a big bytevector to a port and it exceeds the buffer size, it will get written directly without buffering

<wingo>with start=0 and count=len

<civodul>ah yes

<wingo>the semantic change is whether the result of bytevector-slice is guaranteed to be fresh or not

<wingo>if there were no change at all i would have done it already ;)

<civodul>there's no guarantee that the result is not eq?

<civodul>so that's fine IMO

<rlb>...so I'm guessing we use stringbufs directly in some cases, if so, the "convert mmapped strings from wide to utf-8 on first use" approach won't work? i.e. if we only used them via strings, then we could convert and swap the string's pointer to the stringbuf, but I suspect that's not always true.

<rlb>I suppose my main question now is whether my incomplete understanding of the .go files string handling is roughly right, i.e. do we just mmap them, and do some things expect the pointers to be static such that we can't replace them with utf-8 at run time.

<rlb>(...and what do we require wrt backward compatibility on this front)

<wingo>rlb: in 3.2 i think all strings should be utf-8, right?

<wingo>so stringbufs are utf-8 too, in the .go file they are utf8, etc

<wingo>i could be misunderstanding of course

<wingo>civodul: i landed wip-custom-ports

<wingo>civodul: do you think that ssl ports could become suspendable now?

<wingo>i would think so

<wingo>if they were implemented instead in scheme, closing over a session, using non-blocking fd's

<civodul>wingo: SSL ports?

<civodul>oh GnuTLS?

<civodul>they're already suspendable i believe

<civodul>they implement read_fd and write_fd

<janneke>spk121: happy to see your mingw post!

<wingo>civodul: afaiu they implement that to allow for polling when they are readable/writable but do they actually not block when writing?

<wingo>ACTION unclear on that point

<civodul>wingo: i think they can be used with a SOCK_NONBLOCK socket and the current-{read,write}-waiter gets called

<civodul>that's my understanding

<wingo>neat

<janneke>the guile-fibers (1.3.1) test suite has been running for almost 2h on the Hurd, with --verbosity=1, how much more time should i give it to finish?

<jpoiret>it usually takes quite a long time, since it spawns a *lot* of fibers

<janneke>ok

<jpoiret>not sure test suites are supposed to be performance benchmarks though

<jpoiret>2 h is very long though=

<jpoiret>but on Hurd with no SMP and more expensive syscalls, maybe that's to be expected

<janneke>ok, well from a packager's perspective, the ux sucks

<janneke>ACTION knows they are prolly invited to send patches...

<janneke>git's test suite also takes ~1h, like automake, terrible

<jpoiret>tests should in general be focused and reproducible, so here i think it's failing at both

<cbaines>(also, I should be moaning in #guix)

<civodul>jpoiret: yeah i think we should separate actual tests from benchmarks

<lloda>is procedure? always a cheap operation?

<mwette>.

<rlb>wingo: you may have answered my question -- i.e. I'd assumed that it might not be OK to force all .go files to be rebuilt on a Y release, but then overnight I realized that if it is, then that solves the problem "cleanly" (excepting the rebuild). Is that what you were thinking?

<sneek>dsmith: wb!!

<dsmith>sneek, botsnack

<sneek>:)

<dsmith>sneek, later tell dsmith-work This is a test

<sneek>Okay.

<dsmith-work>Hey

<sneek>dsmith-work, you have 1 message!

<sneek>dsmith-work, dsmith says: This is a test

<dsmith>!uptime

<sneek>I've been serving for one month and 17 days

<sneek>This system has been up 9 weeks, 4 days, 21 hours, 55 minutes

<spk121>janneke: yeah. Over on my personal repo, I've got Cygwin 100% passing 'make check'. Cygwin is easy. Next is MSYS, which should be slightly less easy. MinGW after.

<dsmith>Has the bot been delivering messages? Looks like not, from the logs. Maybe they were sent to a different chan?

<dthompson>spk121: do threads and/or jit work?

<spk121>janneke: not sure how to get it into 'main' though. Should I file bugs for each problem? It would be dozens of bugs, and no one would review them but me, haha.

<spk121>dthompson: Cygwin and MSYS link to an emulated POSIX, so threads work, as far as I can tell. Still haven't tried JIT.

<spk121>dthompson: But I'm starting out with no JIT/Threads/LTO and with minigmp as my baseline for now.

<dthompson>spk121: well that's a good start :)

<dthompson>I need threads and JIT at minimum to be able to ship my stuff for windows. hopefully some day...

<dthompson>so go go go spk121 :)

<dthompson>solving any windows build issues is much appreciated

<spk121>civodul: what say you on this whole Guile on Windows nonsense? Should I file a bug for each problem and start working it now one-by-one in 3.0.x? Keep a separate branch and target 3.2 or something? Give up?

<spk121>Most of the changes will be smallish until Guile decides if it wants 64-bit support, which would require every 'long' to become 'intptr_t'

<civodul>spk121: hey! that long/intptr_t thing is tricky! seems like we might need to review them one by one, no?

<civodul>last time i looked, it wasn't obvious to me that we really meant "pointer-long integer" in every case

<civodul>at any rate, i think these changes could go in 3.0, *if* we've confirmed that the ABI is unchanged

<civodul>unchanged on all supported platforms

<civodul>which may be hard to guarantee

<spk121>civodul: there must exist some tool that checks if ABIs change. I've never investigated.

<Arsen>yes, abidiff

<spk121>Arsen: I'll check it out

<Arsen>spk121: https://sourceware.org/libabigail/ for your convenience

<civodul>yes

<vbramselaar>Hi all, I'm trying to embed guile in a c/c++ lib

<vbramselaar>application I mean

<vbramselaar>And I wanted to run like a hook in Guile script when, for example, a message is received in the c application

<vbramselaar>But I have a bit a hard time to figure it out, does someone anyone maybe have any pointers or tips?

<RhodiumToad>there's a couple of ways

<vbramselaar>So like: message -> c application -> run-hook -> all hooked guile functions are ran with as argument the message as string

<vbramselaar>I was now first looking at the chapter 6.9.6 Hooks

<vbramselaar>But don't know how to mix that with c

<RhodiumToad>er, what guile version?

<vbramselaar>I now have 3.0.5

<RhodiumToad>so one approach is to call scm_run_hook from C

<vbramselaar>The part I don't get is that, when I do scm_make_hook in C, how do I do add-hook in guile after that?

<RhodiumToad>the hook object can be created from C and stored in a variable for guile code to access, for example

<vbramselaar>Yes that is what I want todo

<vbramselaar>how do I store it?

<RhodiumToad>see scm_c_define

<vbramselaar>ah yes I just saw it

<wingo>rlb: assuming we are aiming for guile 3.2 there are no .go binary compat concerns

<RhodiumToad>is a 3.2 release planned? (even in the sense of "the next release will be 3.2 if it ever happens")

<RhodiumToad>(it matters to me because of needing to know what program names, package names, etc. to use for different guile versions when concurrently installed)

<vbramselaar>RhodiumToad: Hi, thanks for the tips, got it working now. Again a bit wiser about Guile/Scheme :) thanks

IRC channel logs

2023-06-08.log