IRC channel logs

2022-12-23.log

back to list of logs

<stis>tjaba guilers!
<old>Anyway to find the full path of a module?
<old>(module-filename (resolve-module '(ice-9 match))) returns "ice-9/match.scm"
<old>Possible to have something that return "/gnu/store/.../ice-9/match.scm" ?
<flatwhatson>old: i think you might need to then search %load-path for that
<old>right
<old>However, there could be collision
<old>And I can't be sure which one is actually loaded by Guile
<old>But that would suffice I think :-)
<flatwhatson>yeah it's not perfect, but then even if guile kept the absolute path there's no guarantee that file still exists, or wasn't modified since loading
<flatwhatson>i think traversing %load-path in order will get you the file that would be used if you reloaded that module
<old>I think so too thanks!
<civodul>hey ho!
<civodul>jpoiret: just replied to https://issues.guix.gnu.org/59321, thank you!
<civodul>i pushed a new wip-posix-spawn branch
<civodul>i think we're pretty much ready to merge
<stis>Hello guilers
<jpoiret>civodul: great! I'm looking at it right now, I didn't know the portable "W_EXITCODE" existed, which is why I resorted to the fork in all cases
<jpoiret>wrt spawn being exposed to users, that's what the spawn procedure in the third patch was for, maybe we could split it out of that patch and apply it already
<civodul>jpoiret: hey! W_EXITCODE isn't in POSIX AFAICS, but it's "pretty much portable" it seems
<civodul>i skipped the 3rd patch beacuse i thought it was a 3.2 thing, but lemme take another look
<jpoiret>i didn't let the user specify the environment though, maybe that could added
<jpoiret>well, not _maybe_, that can definitely be added :p
<jpoiret>the separation between spawn*/spawn is the same as for system*/system
<jpoiret>ie. let the user be able to use the port-less interface, but the recommended one would be just spawn
<civodul>well not really the same, because 'system' goes through /bin/sh
<civodul>jpoiret: do you feel like tweaking this last patch to provide 'spawn' while keeping the rest untouched?
<civodul>or should we leave that for next time?
<jpoiret>i could do that, sure
<jpoiret>I'll get your fixups as well
<civodul>or you can base it on top of current wip-posix-spawn if that's fine with you
<civodul>whichever is more convenient for you!
<jpoiret>do you mind being added to Co-authored-by:?
<civodul>sure, np
<jpoiret>civodul: do you still want to keep scm_spawn_process internal for now?
<civodul>jpoiret: yes, i think so
<civodul>it has a clunky API that we'd rather not commit to i guess
<civodul>plus it's not very useful if you're in C
<jpoiret>where should i put spawn? It doesn't rely on the popen feature, so I don't think it's the best place civodul
<jpoiret>I meant, not in (ice-9 popen)
<civodul>right, good question
<civodul>could be in the root module, for lack of a better place?
<jpoiret>you mean ice-9 boot-9?
<civodul>well, (guile)
<civodul>the-scm-module
<civodul>that complicates thing a little because right now the binding is defined when scm_init_popen is called
<jpoiret>right, but the thing is I'd rather write it in Guile and put it into modules/, I don't really know how to handle optional parameters in C
<jpoiret>isn't spawn* defined all the time from SCM_DEFINE though?
<jpoiret>I didn't have to (use-module ) anything to test it
<civodul>jpoiret: oh right, sorry
<civodul>so spawn* remains in C and you can access it from any module with (@@ (ice-9 popen) spawn*)
<civodul>and then, spawn itself, hmm
<civodul>we could create a new module, but what do we call it?
<civodul>(ice-9 spawn)?
<civodul>but then circular dep between (ice-9 spawn) and (ice-9 popen)?
<civodul>ACTION thinks out loud
<jpoiret>popen could be moved to ice-9 spawn when the major version changes
<jpoiret>i mean, everything currently in (ice-9 popen) could be moved there
<jpoiret>this would make the change much more visible, and in the meantime we can put only spawn in (ice-9 spawn)
<civodul>ok, sounds good
<civodul>my only concern then is the circular dep
<jpoiret>would there be any?
<civodul>so 'spawn' would be defined in (ice-9 spawn), but it depends on 'spawn*' from (ice-9 popen), right?
<civodul>oh but (ice-9 popen) doesn't need 'spawn'?
<civodul>i guess that's fine, apologies for adding confusion
<jpoiret>it does if we do want to move everything to that interface at the end, but for now popen relies on piped-process
<civodul>right, so for 3.0.x it'll be fine
<jpoiret>the end goal is to just remove piped-process and make everything go through spawn. We could even implement system* in pure Guile using that (and have it available on more systems, since posix_spawn and waitpid are available in places where fork isn't)
<civodul>yes, i agree with the goal; it'll have to wait for the next major series, but it'll be nicer this way
<civodul>perhaps we could make the transition smoother by keeping 'system*' as-is and eventually deprecating it in favor of 'spawn'
<civodul>that would cause less friction than changing the semantics of 'system*'
<jpoiret>but system* is buggy as-is right now
<jpoiret>not redirecting the fdes properly seems like something that should be fixed asap
<jpoiret>in some corner cases it could cause data corruption
<civodul>not redirecting properly?
<jpoiret>yes, that's the origin of the bug report
<jpoiret>basically, the in/out/err of the child can be set improperly right now
<jpoiret>you can even end up with a child with only fd 0, meaning that the next file descriptors are going to get number 1 and 2 and thus standard error will get redirected there