IRC channel logs
2026-09-18.log
back to list of logs
<old>rlb: pointer->string expect a C aBI string so any NUL is the end of string <old>however I find that we probably need a bytevector->c-string variant <old>I'm doing so ELF hack and I am slicing bytevector from the file <old>and I want to access a string from the symtab. I have to do: (pointer->string (bytevector->pointer (bytevector-slice (elf-bytes elf) offset)))) <old>that extra pointer allocation is anoying <rlb>Might we just want something like (bytevector->string* bv [offset [length [encoding [strategy]]]])? <rlb>one stop shopping, if I understand you correctly... <rlb>I guess if we weren't worried about the bit of extra argument parsing complexity, or the extension, could even just have bytevector->string support that (just test whether the first two args are strings when bound, etc.). <rlb>(first two args after the bytevector, of course) <rlb>And actually, maybe that should be start and end, not offset and length? That's at least what say srfi-152 does. Dunno. <rlb>also matches substring I suppose <old>well reall something similiar to from_locale_string I suppose <gabber>hi! i think i have a bug in the Guix auto-upgrade script i'm developing. it regularly seems to hang while invoking subprocesses. using strace these are of various kinds. i guess this could be from me misusing the (pipe) command? passing the O_DIRECT flag seems to be of little help. any hints towards example code/literature or other sources of insight that could help me resolve the issue? <old>by sub-process, you mean with spawn ? <old>ah seems like you are using open-pipe <old>I bet it's with 3.0.11 only you have this issue <old>hm perhaps not. it seems to be using posix_spawn and I have had not any problem with it so far <old>who's hanging? Is the child completing ? <gabber>strace just stops mid-output of (not sure if every time) `write' calls <gabber>(as describen in the Codeberg Issue) <old>the pipe is probably full <old>the parent is not draining the read-end of it <old>thus the child is waiting for the pipe to be drain while the parent is waiting on reading stdout of the child <old>I would suggest to use a tmpfile instead for the stderr of the child, not a pipe <gabber>this makes sense (and seems like a fine solution!) <old>that's what I did in BLUE. All child output go to a tmpfs <old>this works like a charm <old>especially if you discard stderr when nothign bad happen <old>it's just a matter of properly unlinking the tmpfile <gabber>which is pretty much exactly my use-case (: <gabber>ACTION should be able to achieve that ;) <old>there's a couple of quirk that I had to make it works, but it is all fixed in main guile now <lechner>old: wow, thanks! that helped gabber a lot! <old>been there wrt to deadlock pipe lol <old>I immediatly see it with the strace <rlb>Hmm, I'd vaguely thought that POSIX guaranteed writes of PIPE_BUF size or less would never block (if there's no other data pending), but maybe it only guarantees that the write is atomic... <rlb>old: oh, and I think I mentioned, but we have full srfi-152 support in the utf8 branch now, fwiw. <old>rlb: IIRC PIPE_BUF is only about atomicity of the message wrt to concurrent write <old>> OSIX.1 says that writes of less than PIPE_BUF bytes must be atomic: the output data is written to the pipe as a contiguous sequence. Writes of more than PIPE_BUF bytes may be nonatomic: the kernel may interleave the data with data written by other processes. <rlb>right, that's what I was noticing <rlb>Was looking at the spec. (Somehow I'd gotten the idea that it might also promise not to block.) <rlb>So glad y'all got me to look :)