IRC channel logs

<civodul>wingo: re Fibers, another "would-be-nice" thing that came to mind: making it possible to compose i/o operations like "normal" operations in a choice-operation

<civodul>which i think isn't possible currently because i/o operations are not actual "operations"

<civodul>just a thought for later :-)

<wingo>civodul: yes, basically i think that means making a read-available-operation and a write-available-operation or something

<wingo>hard to know tho

<wingo>i mean usually you want to read more than one byte, right? so you want to read a whole term of some grammar

<wingo>in that case you would do well to just spawn off a fiber and do a normal read

<wingo>and if the read completes, send the parsed datum or chunk or whatever via a channel

<civodul>you can always do that, indeed

<civodul>yeah maybe that makes more sense after all

<wingo>linux is tricky too, it could be that select/poll/whatever returns "this fd is readable" but then you try to read and it blocks

<civodul>really?

<wingo>yeah, let me find the reference.

<civodul>i'm interested, because the offload bug i'm hunting looks like this

<wingo>"Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded.

<wingo> There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block.

<wingo>"

<wingo>that from select's man page under the "bugs" section

<wingo>if the fd is nonblocking, that doesn't block fibers

<wingo>but it does mean that the system "commits" to one operation among a choice operation, if that's how you structure things

<civodul>uh

<civodul>interesting

<wingo>when reading from multiple fds, to my mind it's better to spawn a thread per fd to parse that data and proxy to a channel; just my instinct tho

<wingo>er

<wingo>s/thread/fiber/

<civodul>yeah, probably

<civodul>i don't remember where it was that i wanted that feature, i'll see if that comes up again :-)

<civodul>the libc manual doesn't mention that shortcoming

<civodul>that's terrible

<wingo>that's what samth's opinion was too :)

<wingo>anyway, doesn't matter. the kernel has already buffered data per-operation. having to read or parse it into a buffer on the fibers side doesn't fundamentally change anything afaics

<civodul>sure, i was just considering the consequences in a more general context

<wingo>so select-over-ports as a select-over-channels-that-parse-the-data seems a fine enough abstraction

<civodul>yes

<wingo>in a more general context it just means you need O_NONBLOCK, which you need for reliability anyway :)

<wingo>and which should be OK if you are using select in the first place

<civodul>yes, though you would expect this simple piece of code to just DTRT: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ssh.scm#n102

<civodul>now i have to throw some O_NONBLOCK and catches and all in there, for something that should really be trivial :-/

<wingo>in theory, though perhaps with AF_UNIX there's no problem

<wingo>but are you sure that's what's going on?

<wingo>like you have determined that the problem is in that code?

<wingo>just wondering of course

<civodul>not entirely sure, but that looked plausible

<wingo>civodul: is it deadlocking?

<wingo>you could be running into that i/o pipe bug. can be the case where e.g. you have the pipe creator which is waiting for a write to complete, but on the subprocess side of things it's producing output as it reads from the input, and it fills up the return side of the pipe and is ultimately blocking on the pipe creator, waiting for it to read off some of the return buffer

<wingo>the solution would be to expose both sides of the pipe as separate ports and operate on them concurrently via fibers

<wingo>or, use threads

<civodul>wingo: the process running the select loop above is stuck in read(0, ...)

<civodul>i thought that this "couldn't happen" because it reads only if select says the FD is ready

<wingo>exciting

<wingo>i wonder what the deal is

<civodul>found a bug of Scheme-level 'select' vs EINTR, though it may not be the one that's hurting me in guix offload

<civodul> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30368

<cmaloney>tzag

<jlicht>hi guile!

<OrangeShark>hello

<jeko>hi guys

<amz3>o/

<jlicht>o/

<jlicht>I just started playing around with the guile FFI (which is loads of fun btw), and am currently playing around with marshalling my types around. Am I correct in understanding that any custom structs are express as void* as far as `pointer->procedure' is concerned?

<jlicht>and how do I express the `const'-ness of certain argument types wrt `pointer->procedure'?

<catonano`>jlicht: hhave you cecked that Bytestructures covers your case ? I'm not sure I understand your question but when I had to deal with a custom struct in C Bytestructures was extremely useful

<catonano`>jlicht: https://github.com/TaylanUB/scheme-bytestructures/releases/

<jlicht>catonano`: Thanks. I was already making use of it a bit, but am new to trying FFI's of any kind. I _think_ that I just can deal with my specific case as an opaque structure, so void* works out okay enough. Maybe I can use bytestructures if I need more control over what is happening :-)

<jlicht>If I wanted to play around with signalfd in guile, what would be the easiest way to do this? Like calling the right functions dynamically, building a part-c-with-libguile wrapper or even directly making changes to a local copy of guile?

<civodul>jlicht: i would create bindings to libc's 'signalfd' using the FFI

<civodul>in shepherd you can stick that in (shepherd system), if that's what you're looking at :-)

<jlicht>civodul: guilty as charged ;-)

<jlicht>thanks

<civodul>heheh

<jeko>I am looking for a way print a file line by line with all lines prefixed with the line number. actually i have a list containing all the lines as string from the file.

<dsmith-work>Morning Greetings, Guilers

<jeko>dsmith-work: Hi !

<rain1>you can use for-each to go through each line

<rain1>e.g. (for-each (lambda (line) (display line) (newline)) lines)

<rain1>then you get a counter for the line number

<rain1>(let ((counter 1)) (for-each (lambda (line) (display counter) (display line) (newline) (set! counter (+ 1 counter))) lines))

<dsmith-work>I keep forgetting that guile has channels now.

<jeko>rain1: I have to test it. thank you very much

<rekado>jeko: you can also use named let instead of mutating the counter:

<rekado> https://paste.debian.net/plain/1009068

<stis>haya guilers!

<rain1>hi