IRC channel logs


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
<wingo>rlb: strict, i think
<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!
<ArneBab>jpoiret: wow — nice!
<sneek>spk121, you have 1 message!
<sneek>spk121, dthompson says: I wonder if whippet will improve the situation for gc + threads on windows.
<civodul>old: hey! i'm looking at
<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
<civodul>thanks for listening :-)
<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>(like your patch does)
<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.