IRC channel logs
2023-02-27.log
back to list of logs
<flatwhatson>sneek: later tell civodul The libgc package uses the --disable-munmap configure flag as a workaround for this bug. That should be removed so libgc will actually release some memory. Testing locally, a libgc-8.2.2 build without --disable-munmap does pass test-out-of-memory, horay! Here's my hacked-up guile/guix.scm to reproduce that: https://paste.debian.net/1272261/ <old>Is it possible to list the instructions of the current frame? <old>I'm single stepping instruction of a function in the REPL with ,si <old>but I would like to have a listing of the instructions around like in GDB <lloda>ok to push? (let ((betadeg (from (cart->sph2-deg (from ralpha #t 0)) #t 0))) <lloda>i thought there might be an arguments-match-signature? test somewhere in guile but i didn't look very hard <wingo>i wish we had a gitlab, i could expand the context on the patch <lloda>i'm mildly concerned that case-lambda* isn't all that exercised, I had a buggy patch earlier and neither guile's suite nor my own noticed it <wingo>but case-lambda and keywords and defaults are great <wingo>so, i guess we just have to fill in testing gaps <attila_lendvai>i'm trying to use fibers with guile-json, but it uses peek-char, which is implemented in C. shall i hope for this to get fixed any time soon? <attila_lendvai>my current workaround is to call read-line and parse the string into json. not ideal, but it works <wingo>attila_lendvai: (use-modules (ice-9 suspendable-ports)) (install-suspendable-ports!) <attila_lendvai>wingo, fibers does that behind the curtains, but i think it doesn't help with functions that are implemented in C (they all are non suspendable) <flatwhatson>attila_lendvai: (ice-9 suspendable-ports) installs a pure-scheme peek-char <attila_lendvai>hrm. it means that i'm probably wrong to assume that it is hanging for me due to peek-char. but guile-json's json->scm on a port does hang, while json-string->scm on a line read by read-line works as expected in the same environment. <civodul>you have to make the port O_NONBLOCK too <attila_lendvai>civodul, but that would interfere with read-line also, no? all i'm doing is leaving out the read-line from the story, and i get a hang <flatwhatson>(fcntl port F_SETFL (logior O_NONBLOCK (fcntl port F_GETFL))) <civodul>attila_lendvai: read-line has a Scheme implementation in (ice-9 suspendable-ports), so it's all good <flatwhatson>the suspendable-ports routines handle waiting for you by running the read-waiter, fibers installs a waiter which suspends/resumes the fiber <attila_lendvai>i understand these (i think). what i don't understand is why these two implementations behave differently in the same environment: 1) read-line, then call json-string->scm on the string; 2) json->scm directly on the same port, without a read-line call <attila_lendvai>but again, it works, it's not a show-stopper, so... finding the answer is not crucial. i'll just mark it as a kludge in my code and wait for you opensource fairies to even things out... :) <wingo>it sounds like what civodul said, maybe your port is not nonblocking <attila_lendvai>wingo, does that mean that fibers + read-line is capable of dealing with a blocking port? (it's in the same environment) <wingo>if your port is O_NONBLOCK then fibers will suspend peek-char if it would block. if not O_NONBLOCK peek-char will block regardless <attila_lendvai>...and read-line would suspend regardless of the O_NONBLOCK state of the port? <wingo>no, read-line should behave same as peek-char <attila_lendvai>ok, let me clarify things: my app hangs when i use json->scm directly, but works as expected when i do a read-line and then a json-string->scm. no other change is done, only this. (the port is set to O_NONBLOCK, i just double checked it) <attila_lendvai>and by hang i mean not that a single fiber is waiting for input, but some kind of deadlock happens (this app spawns a process and talks to its stdio through pipe's, and also through an IPC socket) <attila_lendvai>but anyway, i feel that i'm stealing precious developer time with this. it works for now. <flatwhatson>suspendable read-line uses read-char, not peek-char, maybe that's the difference? <ArneBab>If operations are run in a different order, it can cause a fiber to start waiting (and blocking) for a message that is not yet ready from another fiber. <attila_lendvai>ArneBab, oh, good question, i forgot to add that i'm mimic'ing here what Shepherd does: #:parallelism 1 #:hz 0, i.e. it's a single kernel thread. <attila_lendvai>i mean i call run-fibers with #:parallelism 1 #:hz 0, and spawn-fiber with the default args <mwette>In this async fibers config, how would you set up a repl-server? Use repl-server or coop-repl-server? I tried many ways and end up using coop-repl-server and sleep after each poll. It seems like the repl's i/o should be included in the epoll call somehow. <ArneBab>attila_lendvai: I spent far too much time wondering why my code didn’t work to forget that again ☺ <pinoaffe>hi folks, is there a particular reason why the "scheme" language (in (language scheme spec)) doesn't have a "joiner"? <daviid>pinoaffe: i don't understand your quetion, but in any case, scheme spec related quiz better asked in #scheme