IRC channel logs
2024-02-25.log
back to list of logs
<rlb>old: certainly -- and forgot to mention (or did I earlier) that I can add atomic store etc. ffor the happy path if we want that, and/or if we think some arch might not *ever* propagate the store without it. <rlb>Suppose that might be one of the things you were messing with... <dodoyada>how are you expected to stop a (fibers web server) run-server? I can kill some aspect of it if I start it in a thread and then cancel-thread but it seems like the server is still listening and just doesn't respond to anything <belzurix>Is it superfluous to test the file for reading permissions before using scm_c_primitive_load ? <Arsen>it is usually a bug to check perms then use said perms <Arsen>unsure how primitive-load actually handles errors, though <apteryx>daviid: v4 sent for the logging improvements, with your recommandations implemented <apteryx>rlb: (re having the GUILE_PKG work for my custom Guile build) ah, configuring PKG_CONFIG_PATH makes sense, thank you <apteryx>or we could modify GUILE_PKG to honor a pre-existing GUILE environment variable/flag to allow the ./configure GUILE=/path/to/my-guile use case <apteryx>(one could argue that the pkg_check_modules should do that itself) <apteryx>e.g. if the variable it's supposed to define is already set by the user, use that without doing any check <apteryx>so this points to GUILE_PKG being buggy / breaking tAT <apteryx>the ./configure --help of guix shows I can provide GUILE_CFLAGS and GUILE_LIBS, but not GUILE or GUILD <civodul>bummer that nobody touched it for two years, but we’re making progress! <graywolf>Hi, I am looking into (primitive-fork) and I see the notice regarding multithreaded programs, which is fair, that is known problem with fork in general. However when I run guile -c '(sleep 100)' is seems it already has multiple threads. <graywolf>So I am unclear on how to create a single thread program I could use primitive-fork from. <apteryx>rlb: hm, attempting to configure guix with: ../guile/meta/uninstalled-env ./configure --localstatedir=/var --sysconfdir=/etc --> fails because gcc conftest.c causes ld to abort with signal 6 <apteryx>the error oddly has to do with Guile, it seems: Pre-boot error; key: unbound-variable, args: (#f "Unbound variable: ~S" (error) #f)collect2: fatal error: ld terminated with signal 6 [Aborted] <apteryx>ah, the ld-wrapper from guix is a guile program <apteryx>so I think the error says ld itself errored with collect2: fatal error: ld terminated with signal 6 [Aborted] <apteryx>hm, that ld-wrapper script unset GUILE_LOAD_COMPILED_PATH and unset GUILE_SYSTEM_COMPILED_PATH, which is probably at cause <apteryx>civodul: any idea why the Guix ld-wrapper script fails with the above when run within Guile's meta/uninstalled-env environment ? <apteryx>it seems it should be self-sufficient (configuring its own environment) <apteryx>looks like comments at the top of said script are due to be revisited (2012 since resolved bugs) :-) <rlb>graywolf: if you make sure not to call fork until all the threads you've created are finished (e.g. joined), and you don't use any external code that has lingering threads, then I think guile intends to handle things correctly, i.e. it tries to come to a "safe point" before forking (stops the signal thread, etc.). <rlb>(...and restarts the signal thread when appropriate after the fork, etc.) <graywolf>rlb: I did not create any, it seems guile does by itself on startup; my whole program is `(sleep 120)', but I still see multiple threads in ps' output <rlb>But POSIX threads/signals/fork -- there be dragons. <rlb>Right, but those should be stopped before guile forks if you call fork. <graywolf>(I am rewriting a program from C, and would like to do 1:1 rewrite at this moment, I can re-architecture later) <rlb>apteryx: ...no idea wrt the crash. <apteryx>I guess because uninstalled-env sets GUILE, and the script doesn't reset it to use its own <belzurix>Arsen: thanks for the advice. I read the same in the docs, but the code I looked at did the buggy thing, so I asked. <rlb>old: so your patch is fairly substantial -- what were the critical changes as compared to "a change in approach"? i.e. I know the happy path was sloppy with exited, but could have been fixed (I think) by just making exited an atomic int. It also looks like it might suggest I overlooked a false wakeup. <rlb>Top-level, I think if there are smaller changes that could be made to my patch to make it "right", then perhaps that's worth considering. Otherwise, I'm wondering if it'd be better for your approach to just be presented as a wholesale alternative (complexity-wise), but not sure. <rlb>Basically, I thought I'd see what everyone wanted there during review, since I assumed we can't add stdatomic.h directly to threads.h. <rlb>(or rather, wasn't sure that'd be OK) <rlb>wingo, civodul: https://bugs.debian.org/1064437#5 The example at the top might be interesting, unless that's exactly what we expect. Personally, I think I'd expect guile to use the bytes I gave it in argv. (fwiw, I'm trying to decide how to respond.) <apteryx>civodul rlb: I had to unset 'GUILE_LOAD_PATH' in the Guix ld wrapper to fix it <apteryx>(when used with Guile's meta/uninstalled-env <apteryx>now I can: ../guile/meta/uninstalled-env ./configure --localstatedir=/var --sysconfdir=/etc <apteryx>-> checking for guile... (cached) /home/maxim/src/guile/meta/guile <apteryx>is there a Guile variable exposed for GUILE_SYSTEM_COMPILED_PATH [/ <apteryx>this envar doesn't even seem to exist per the doc <apteryx>hm, that's a documentation problem, it's honored in code by scm_init_load_path, along GUILE_SYSTEM_PATH <civodul>apteryx: unset GUILE_LOAD_PATH to fix what? <rlb>civodul: I'd like to decide how I want to respond to that debian bug report -- still inclined to say that it's an/our (upstream) problem, but wanted to check in case we feel that's inappropriate, and also because the problem might be interesting: https://bugs.debian.org/1064437#5 Perhaps sufficient to just look at the example at the top if/when you can. <apteryx>civodul: you'll should get X-Debbugs-CC'd to the issue/solution <civodul>rlb: arguments are interpreted in locale encoding, apparently with the ‘substitute’ strategy <rlb>I think this may just be another example of the fact that we can't round-trip data correctly in some cases (e.g. paths) because we can't round-trip arbitrary bytes? <rlb>And if so, I assume it's not something we're likely to fix very soon, though if we *could* just crash in some cases, that might be better, maybe? <civodul>this is happening in libguile/script.c <civodul>bu yes, the assumption here is that command-line arguments are strings, not byte sequences <civodul>it’s tricky, see the comment above ‘locale_arguments_to_string_list’ <rlb>Hmm -- yeah, I think we either shouldn't be converting to strings at all, should do byte-smuggling (though still not yet entirely comfortable with that), or should provide a way to get argv as #u8() values... <rlb>So I think I'll stick with the "should be solved in guile" position. In general, I want debian to stick fairly close to upstream. <apteryx>civodul: hm, seems debbugs has not processed that bug yet... seems slower than usual <civodul>rlb: yes, it’s really a Guile problem, not a Debian problem <rlb>civodul: Offhand, do you think in addition to whatever else we do, support for a lower-level module that just dealt directly with #u8() might be interesting/plausible/acceptable? If so, I might be willing to work on it. <rlb>i.e. it'd have "binary" vesions of getenv, setenv, program-arguments, etc. <rlb>I'm basically having to create that incrementally (and repeatedly) in some projects already. <rlb>...and even if we had "complete"/concurrent latin-1 support, it might still be nice to avoid the unnecessary conversions, when you know you want bytes. But not sure it'd pan-out. Just wondering whether you already think we probably wouldn't want it. <rlb>Is there no way to close just the read write half of an OPEN_BOTH popen port?