IRC channel logs
2023-07-16.log
back to list of logs
<haugh>I'm looking for a demonstration of recursive `force'. I didn't understand how useful promises were until I really needed one, so I'd rather not ignore this feature that I don't currently see the point of. <haugh>oh maybe this should go in #scheme <haugh>Oh I see, you can construct streams this way <jpoiret>cross-compiling guile programs is super slow, is there anything that could help? <jpoiret>i'm not even cross-compiling to another incompatible arch, only to Hurd on i586 from Linux on x86_64 <civodul>i suspect this is because we're evaluting the modules being compiled over and over again <civodul>we could check that hypothesis by adding a native variant of the code being compiled to 'native-inputs' <jpoiret>ah, I see! that's also the case for guile itself <jpoiret>civodul: I can confirm that for guile it's going much faster now! <sneek>spk121, dthompson says: I wonder if whippet will improve the situation for gc + threads on windows. <civodul>i was wondering whether to display the warning only when writing to 'environ' <civodul>but now that i write this i think it makes no sense <old>civodul: I agree. The warning should only be emit on store to environ not load <old>however, for the `environ' procedure, it is a bit tricky <old>the only true way of making a copy of envrion would be under the mutex-lock internal to glibc <old>the whole environment API was not meant for multi-thread :-) <civodul>old: yes, you can't even traverse it safely, so the warning is needed even when not setting it, i'd say <civodul>terrible that we're still dealing with this 50y later <spk121>old: one thing to note is that Guile's mktime and localtime both completely replace the environ with another environ, and then restore the original environ. <spk121>I'm not saying this has anything to do with your issue, but, I was just looking at that code, and I found it interesting. <old>spk121: fascniting. Idk if my patch address this issue, but that would also be a big problem <wingo>lol. peval takes a module argument; "peval this exp with respect this module". it doesn't use the module <old>Maybe it is worth exploring if Guile should have its own environ and manipulate the C environ under a global mutex <rlb>wingo: ...think I may agree even more now (just spent a chunk of time caused by the "hidden" off-by-one the null introduces into some of the stringbuf/index math). <spk121>This is so that it can temporarily update "TZ" for broken OSs like Windows and Solaris. <rlb>I think I'll plan to remove it (had been carrying it along). <old>we could perhaps also add a environ for /proc/self/environment which is immutable <civodul>old: Guile could have its own mutex, though that doesn't prevent non-Guile manipulations of 'environ' <old>idk if other OS have such immutable environment <old>civodul: Right. That's the big problem I guess. Runtime mangling <old>Note that every string passed to putenv are leaked by glibc <old>I was kind of shocked when I saw this <spk121>aside from setting environ in mktime & localtime, I'm fairly sure the only other time Guile modifies environment variables is setting GC_MARKERS for null-threads during Guile's startup. It uses getenv in a bunch of places, of course.