IRC channel logs
2026-04-28.log
back to list of logs
<rlb>utf8 updated, now includes the xsubstring/xstring-copy! fixes for main, complete srfi-152 support, and separately, a string-concatenate-vectors-reverse (mirroring string-concatenate-reverse). <rlb>thanks for all the help <jcowan>I hope the day comes when there are no more Unicode experts (as there are no ASCII experts) but until then... <rlb>Given unicode's (and human) complexity, I suspect that day may be a way off ;) <rlb>see also "time zones, how hard could it be?" <rlb>I distinctly remember the first time I encountered non-hour, and not even half-hour timezones (i.e. in that case 45min offset iirc). <jcowan>Yes. At least hours and minutes are enough: no current timezones are off UTC by seconds. <rlb>Yeah, sure hope so, I think the fix and the tests assumed that :) <rlb>(For a demonstration "TZ=Australia/Adelaide date".) <jcowan>The Olsen names are great. Much better than Posix. <jcowan>The only irritant is that if you use an unknown name in TZ, you get UTC time -- but not marked as such. <apteryx>another odd thing found with spawn: you can't give it the port created with 'call-with-output-string' as its #:output: In procedure spawn: Wrong type argument in position 4 (expecting open file port): #<output: string 7fed2ecdf310> <apteryx>shouldn't this work? it'd be convenient if it did <jcowan>It's opened on file descriptor 1 in the child process, but there's nobody home to pass the string to it. <jcowan>As I was trying to explain (rather obscurely), the spawn procedure returns as soon as the git process is created. <jcowan>Now in order for this to work, a thread would have to be created to read from the pipe representing git's stdout and transfer it to the internals of the c-w-o-s procedure. <jcowan>and anyway, this is confusing: I think you want spawn to take an in: argument rather than an out: argument. <spk121>JohnCowen: I'm not sure why GC is slow on Cygwin. I suspect it has something to do with how Cygwin fakes POSIX signals where BDW-GC relies on sending signals to do its stop-the-world. But that just a guess. <spk121>old: In my CI, Cygwin is about 2.5x the compile time of Ubuntu. Ubuntu is usually 30 minutes. Cygwin is 1hr 15min. <spk121>The speedy builds are Ubuntu and MacOS at 30min. <spk121> The Debian Hurd x64 CI is running in a VM, and it takes 1hr 15min. MinGW 32-bit no-JIT is about an 1hr 15min. <dsmith>apteryx, Hmm. I wonder if if it could be possible to make a fd with memfd_create to pass to the child process and then laster mmap that into a string buffer. Would need to munmap it at sometime though. <dsmith>sneek, Later tell spk121 What was the problem with obsd and date during ./configure time? <old>apteryx: string port are not backed by file so you can't use them across memory space <old>memfd could be used but is linux specific <dsmith>old, Yeah, was going to say, could fall back to a tmp file. <old>in any case, avoid using pipe. You risk deadlocking <apteryx>old: interesting; where does the deadlock risk comes from where using pipe, if I may ask? <apteryx>and I assume with-output-string is backed by pipes? <dsmith>apteryx, If you write to the child's input pipe and read from it's output pipe, it could be blocked waiting for input while the parent is blcoked reading it's output <dsmith>Like sort. Won't produce anything until is reads all it's input <apteryx>I don't yet see how this could be a problem with something like my earlier example, where git is spawned and its output collected to a port (I expected any port would do, but apparently there's a file port undocumented restriction, as old explained) <dsmith>apteryx, That will probably be ok. It's just that you have to be cautious. <apteryx>dsmith: Do I understand the risk you mentioned exists only when doing bi-directional (input/output) over pipes with child processes? <dsmith>String ports are just a bit of memory. There is no file descriptor that another process can read or write. <apteryx>that could be seen as (a current) implementation detail though, right, rather than a designed property? <dsmith>apteryx, Right, if you are only reading or writing, things should be ok. But it depends on what the child is doing/expecting <apteryx>(given that old said the call-with-output-string port mechanism could be implemented using something like memfd with a tmpfile fallback) <apteryx>it'd be nice if the port API promise could always hold :-) <dsmith>Well, ports are an abstraction, no promise they are backed by os file descriptors. They are just sinks and sources that you can (write) to and (read) from. <sneek>Welcome back spk121, you have 1 message! <sneek>spk121, dsmith says: What was the problem with obsd and date during ./configure time? <spk121>dsmith: It is just that Guile's autogen.sh fails if m4 doesn't have a --version flag, and BSD m4 doesn't. Patch that out of autogen.sh and FreeBSD builds. I haven't tested OpenBSD to see if the build completes once you patch autogen.sh <apteryx>dsmith: what I'm saying is that it appears the abstraction is a bit broken when one must know if a port is file-backed or not to ensure proper operation (as seen with spawn) <dsmith>spk121, Ah yes, is required to use gm4 IIRC (and gmake) <spk121>ok. I added the m4 package to the openbsd build rule. Maybe that'll fix it. <spk121>Now that Github Actions are mostly working, someday I'll have to figure out how to migrate away from Github into something more free <old>apteryx: there are no point in using memfd except for: <old>possible race condition for unlinking on the file-system. memfd is anonymous and does not require unlink <old>it's equivalent to open a file in a tmpfs and unlink it atomically <old>there's also memfd_secret which is equivalent, but the pages are removed from the kernel address space. but I guess this is not what you need <old>for the pipe, the deadlock risk is if you don't drain the output. In the case of BLUE, we let the process finish entirely before reading back their content and printing it to the terminal and storing it to the BLUE store. So we don't have a fiber hanging there for reading the bytes. pipe are good if you are streaming so they are okay if that's what you need <old>with-output-string is a Scheme concept. AFAIK, they use internal buffer and not pipe. This is much faster <old>it's also difficult to make the string port be handle internally in spawn. You need to do conversation with file-backed ports like BLUE does. But should the port be async or not? What are the flags you set on that file descriptor? <old>memfd_secret is great for sharing things like keys <dsmith>ACTION doesn't have a memfd_secret man page <old>and protecting the memory against gadget or passing it to syscall by accident <old>if the kernel tries to read the user memory that's secret, it will fault <rlb>dsmith: here it's in manpages-dev fwiw. <old>it also pin the memory like mlock(2), so no swapping possible <old>there's probably other mitigation made by the kernel to the underlying page <old>such as putting the pages in specific location (physically) to avoid side-channel attack on it via the cache. Not sure <rlb>version I have is 6.9.1-1 (presumably trixie) <rlb>glad to know aobut it <old>right because it implies swapping <old>it would require for the kernel to write random bytes into the region where the secret was swapped to disk <old>also not sure, but I assume that once all referneces are dropped, the kernel will zeroed the pages in RAM <old>to avoid cold boot attack for example <lechner>Hi, what could be a reason for different formatting of pretty-print output between Guix and Debian, please? Both seem to be on 3.0.11. Thanks! <dsmith>lechner, Can't help you, but (if you haven't already) probably should ask in #guix too.