IRC channel logs

2024-03-14.log

back to list of logs

<rlb>also might have a race wrt guile-procedures.txt...
<rlb>i.e. doesn't work with make -j...
<rlb>wingo: looks like your change worked fine with the thread deadlock fix and utf-8, but it (or something else very recent) breaks lokke: https://paste.debian.net/1310632/ -- in case that means anything to you offhand. Of course also reasonably likely that lokke's doing something it shouldn't. Regardless, I'll delve later.
<apteryx>daviid: recreated guile-lib's devel branch as requested
<daviid>apteryx: great, thanks - tomorrow i'll start to work on the next release
<glenneth>good morning :)
<wingo>rlb: could that be https://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=9e0f03c5fd36764827c8bb03887f14640c883b70 ?
<apteryx>daviid: thanks to you!
<RavenJoad>I have a bash script I would like to convert to Guile (though it is not important to do so). The bash script uses | to send the output from the previous command to grep. This seems a bit challenging to do in Guile. I would have to do the C-like thing and create a pipe object, connect them to the separate subprocesses, and then let them run, right?
<dsmith>RavenJoad, Check out https://www.gnu.org/software/guile/manual/html_node/Pipes.html#index-pipeline
<RavenJoad>dsmith: Ahh. There it is. Thanks! Apparently (guile) Pipes does not have an index entry for "pipe". If I do an index search, I end up in (guile) Ports and File Descriptors for the syscall wrapper.
<RavenJoad>Oh. It does. It is just "hidden" behind a <1> counter. Whoops.
<rlb>wingo: hmm, thanks -- I'll check later, though I thought I'd already tested "past" that one (unless you just pushed it). Refer's also a normal function in (lokke ns), fwiw. But perhaps that's not be what it's complaining about.
<rlb>My guess so far, is that it's related to the way we build the module representing a clj namespace somehow -- iirc that process was a bit sketchy. Anyway, I'll have to investigate later.
<rlb>(...that is, also, I think, the first .clj file it tries to compile during the build -- all files leading up to that are .scm)
<RavenJoad>Is this a typo? "...returning an input port to the end of the pipeline, an output port to the beginning of the pipeline..." It should be the other way around, right? An input port to the beginning of the pipeline and an output port from the end of the pipeline? (From (guile) Pipes).
<old>RavenJoad an input to the end means you can read from the last process in the pipeline
<old>A output to the beginng mean you can feed stuff to the pipeline
<dsmith>I believe it from the view of the caller, not the pipeline.
<dsmith>You read from the input port, which is the output of the pipeline..
<dsmith>What old said
<RavenJoad>That makes more sense. That is just a confusing sentence to me. When I read it, I read input port and figured that is the input to the pipeline.
<dsmith>Perspecitve
<dsmith>The guile pipe stuff confuses me a lot too
<old>I think the confusion is that a pipe(2) system call returns: fds[2] where fds[0] is the input and fds[1] is the output; thus read <- fds[0] <- fds[1] <- write
<old>in other words, the flow of data is right to left <--
<old>while pipeline is the reverse, the data flow from left to right -->
<old>at least that's my confusion
<old>but like dsmith says, it is a matter of point of view
<dsmith>Same thing with drivers. When getting data into the driver, it happens on the "write" method, and when sending, you use the "read" method.
<RavenJoad>Yeah. I did not not read the manual closely enough. I may add a sentence there in the manual to clarify.
<dsmith>sneek, botsnack
<sneek>:)
<rlb>wingo: you called it -- that commit appears to be th culprit, though I really though I'd already noticed and tested it a bit back. Though maybe I'm remembering testing the utf8 and/or threads changes, and not lokke. Anyway, I'll look in to it. Thanks again.