IRC channel logs


back to list of logs

<ajarara>Hello! Is there a proc that takes a dependency tree to a list? I don't care about topology or the different dependency relationships (propagated/compile) , just want to assert that every dependency in the tree satisfying some predicate satisfies another.
<ajarara>Oops I asked this in the wrong channel. Sorry!
<lispmacs[work]>Is there some way to kill a process that was spawned using open-pipe(*)? It my application, I sometimes need to kill that process, and then later recreate it, but it seems that the program hangs on the close-pipe call
<lispmacs[work]>open-pipe* is quite convenient to use in my code, except that I don't seem to have a way to just kill the process if I want to
<lispmacs[work]>from the documentation, I *think* that close-pipe is waiting for the process to end itself
<lispmacs[work]>but the docs also say that close-pipe "reaps" the process, whatever that means precisely
<lispmacs[work]>I see in the docs I could do something like primitive-fork instead, to get the PID, but then I don't know how to create a pipe from it
<samplet>lispmacs[work]: AFAIK, you need to use primitive-fork to get the PID of the child process (which you can use to send it signals).
<samplet>To get the pipe, you have to use the "pipe" procedure and dup everything just like you are writing C code.
<lispmacs[work]>samplet: can you explain what you mean by "dup everything"
<samplet>That’s assuming you want to exec something else.
<samplet>For example, you want to run some command and read its output, killing it if you see something in particular.
<samplet>So, you call pipe to get two ends of a pipe, and then you fork to get two processes.
<samplet>In the child process, you close the read end of the pipe, and then you use the "dup" system call to make sure that write end has the same file descriptor as stdout (which I believe is 1).
<samplet>Finally, you exec the other utility. When it write to standard out, it ends up writing to your pipe.
<samplet>In the parent process, you close the write end of the pipe, and read the other program’s output from the read end.
<samplet>I’m sure that’s as clear as mud if you’ve never done it before. :)
<samplet>Are you reading from another process or writing to it or both?
<lampilelo>lispmacs[work]: samplet: (ice-9 popen) exports port/pid-table, so you can get the pid with (hash-ref port/pid-table my-pipe)
<samplet>lispmacs[work]: Right, but the comment in the code says “XXX use of this table is deprecated”.
<samplet>That’s always scared me away. Although it does add “[It] is populated for backward compatibility” so maybe it’s stable.
<lampilelo>i didn't read the comment, you're right
<samplet>It’s a useful feature – maybe we need a ‘pipe-pid’ or something.
<lampilelo>i feel like the api for popen is sub-optimal, there always are some hoops you have to jump through to do what you want
*samplet agrees while sauntering off
<dsmith-work>Thursday Greetings, Guilers
***sneek_ is now known as sneek
<lispmacs[work]>samplet: lampilelo: I'm not excited to use something deprecated, but I see using the hash-ref solution involves writing an extra two lines of code, as opposed to another twenty lines of code I don't even understand yet
<lispmacs[work]>not sure why that is deprecated, seems extremely useful.
<samplet>lispmacs[work]: I think using it would be justified. It’s not like it will break silently, either. If/when it breaks, you will likely notice.
<lispmacs[work]>samplet: is there some way to check if a pipe is already closed?
<lispmacs[work]>it seems that char-ready? throws an exception if the pipe is closed already
<samplet>lispmacs[work]: Does ‘port-closed?’ work?
<samplet>The popen module just returns ports that are tagged with PIDs, so I assume it would.
<lispmacs[work]>I'll try that, thanks
<wingo>good evening
<civodul>hey wingo
*wingo thinking about moving mpz to mpn
<civodul>these are pleasant thoughts :-)