IRC channel logs
2024-02-24.log
back to list of logs
<old>mwette: and that's probably why they provide guile-3 under guile3.0 juste like python3 <old>unlike all of the other distro where guile-3 is just guile .. <civodul>“repository path '/builds/guile-git/guile-git/tmp-simple-7016/simple/' is not owned by current user” <civodul>seems weird because that directory is unpacked (from a tarball) right before attempting to open it <civodul>so i don’t see how it could have different ownership <rlb>Is this a "normal" host (vm), or a container? <civodul>hmm could it be that ‘tar xvf’ managed to restore different UIDs in that container?… <rlb>Offhand, then, wonder about container-related issues. <rlb>If it's easy, might stick some diagnostic cmds in there to print the `id`, and path ownerships, etc "find -ls", or whatever. <rlb>...no idea if it's relevant, either, though. <civodul>looks like “tar xvof” instead of “tar xvf” fixed it <civodul>so presumably ‘tar’ is running with UID 0 in the container, and thus it was restoring different UIDs? <rlb>Hmm, not sure. (I'm a bit wary of docker -- particularly if privileged). And nice. <rlb>civodul: btw, I realized maybe you were talking about even more sophisticated concerns wrt the bytes vs strings stuff, i.e. my main concern has mostly just been "how can I make (concurrent) calls that can handle arbitrary bytes", and for that, I'd be happy with, and might even prefer calls that just don't do strings (and I can handle that if/when I want to). But if you are going to do strings and/or do both, I think maybe you were <rlb>(also) thinking about some of the higher-level composition questions... <rlb>i.e. I might well be happy with lower-level module(s) that provide a bytevector-only basis. <rlb>(And for tools handling a *lot* of paths, say, the string round-tripping is just overhead.) <rlb>...otoh, if you're going to manipulate the paths at all, you'd either need byte-vector oriented operations like split, etc. Or now you do want strings(ish), and for paths in particular, where only '/' is significant, latin-1 string-split, etc. is "fine". <rlb>All in all, some tedious questions. <rlb>I guess for now, the easiest thing for me to do (as long as I need C code anyway) is to just continue to add my own wrappers to the project for the bits I need. <apteryx>why is it not possible to override the pkg_check_modules([GUILE], ...) check with ./configure GUILE=./some-path/my-own-guile-build ? <apteryx>I realize this is more of an autotool question <apteryx>it's overridable at make time to, but that's less convenient for my use case <rlb>apteryx: not, sure, but I believe I encountered the same thing. That said, depending on what you need, of course you might need more than GUILE. For now (for lokke and some other things) I just ended up creating a "guile-env" wrapper that adjusts PATH, PKG_CONFIG_PATH, and ACLOCAL_PATH to point to the one I want. <old>or there's a newer one? <rlb>If that's on the current rev-* branch, then yes, though I haven't rebased in the past week fwiw. <old>sounds good. which test needs to be run for reproducing the race? <rlb>Here, I could fairly reliably reproduce it via "make -j5 check" on that branch, without the last two commits, on a 4 core host. I believe the preceding commits, which make the tests faster by increasing the parallelism, likely exposed the problem more clearly. <rlb>I'd guess that any -j around/above your core count might do it too. <rlb>It would then hang in test-signal-fork much of the time, though sometimes (and more so as I added a lot of debugging statements) it'd get past that and hang in test-sigaction... <daviid>apteryx: i think you'd need to set all vars that are set in guile's source tree meta/uninstalled-env, then (assuming you update and copu the script in your project's repo) run ./uninstalled-env ./configure ... <rlb>Oh, right "see also, the commit message" ;) <daviid>apteryx: or maybe rlb's suggestion is better, not sure :) <rlb>fwiw, mine was just for an installed tree. <old>eeh stdatomic, never seen a project using them before guile <old>always saw atomic builtins <apteryx>rlb: for my purpose, currently it seems enough to hack GUILE = ... to use my value of choice in the generated Makefile <apteryx>it just seemed perhaps I should be able to bake the GUILE value recorded at configure time <rlb>Sure, I'd think something like that would be plausible for the macros. <rlb>i.e. so that $(GUILE) captures the right default at configure time. <rlb>But it's possibly tricky when you consider all the paths that "go together" for a version, and so we might need to define what we intend, i.e. do we intend for each one to just be "whichever is found first" in the relevant paths, or might we want some way for "$(GUILE) ..." itself to tell you where its companion files are (or would be if installed), or... And then there's cross-compilation to consider? <rlb>For now, fwiw, lokke just does whatever the macros do, which in practice means, I think, that you get whatever's first in the relevant paths, plus or minus GUILE_EFFECTIVE_VERSION effects. <dodoyada> fibers has both (fibers web server) and (web server fibers). it looks like they're both server implementations while (web server fibers) provides an interface to the server thread that includes open/close while (fibers web server) just provides run-server but has a nicer handler param. am I reading this right? It looks like you're supposed to use one or the other <old>rlb: I have a patch for you <old>Can I send it to you by mail (git format-patch)? I do not have codeberg <dodoyada>oic: Fibers includes a “backend” for Guile’s built-in web server that uses non-blocking fibers to read requests and write responses. Fibers also includes a standalone web server that uses Guile’s HTTP facilities, but not its web server framework. See Concurrent Web Server, for more on the standalone web server.