IRC channel logs
2022-10-09.log
back to list of logs
<rekado_>I’ve got problems with the time machine <rekado_>this seems to load .go files from /run/current-system/profile, which are known to be incompatible <rekado_>I guess ultimately this would fail anyway, because the old Guix specified in channels.scm does not support these newer transformations anyway <old>rekado_: I have time to work on an option to terminate GWL prematurely. <old>I was thinking something like `--terminate-on-signal=SIG1[:SIG2]`. By default, SIG1 would be SIGTERM and SIG2 would be SIG1. SIG1 would be the signal handler for GWL itself to terminate gracefully. GWL would then send SIG2 to sub-processes and waitpid them before exiting. <old>On another note, stderr of sub-processes are the same as of GWL I think. Since processes can be concurent, it would be a good idea to capture stderr of sub-processes and buffered them by line. Maybe adding a header before it. Using epoll that should be easy. <rekado_>on the topic of termination: I feel it would be a good idea to spend a little bit of time to look if there’s a common idiom for this kind of thing <rekado_>in other workflow language runners, or elsewhere <rekado_>but if there is none I’m okay with what you propose. <rekado_>not sure about the option’s name, but that’s bikeshedding <rekado_>re stderr capture: we have call-with-output-processor; is this not working as it should? <rekado_>the problem I faced was that independent polling can give you an EOF and you can’t know if that’s because the log file was closed or if the polling process just outpaced the process that writes the log. <old>IIRC, I used stderr for debugging (writing to the terminal) from the processes. I don't see how polling can be a problem. You will get EPOLLHUP when the pipe is closed and EPOLLIN when there's data to read <old>And do you have a reference implementation that we could inspired from for the early termination? <old>A quick guix-search shows me cwltool