***jfred9 is now known as jfred
***sneek_ is now known as sneek
<rlb>...any known races wrt ice-9 future and touch? I'm seeing some odd behavior that might well be my fault, but also somewhat looks like it might be a race condition. <rlb>(2.2.6 if it matters) <sneek>Sneeky bot running on Guile version 3.0.0 using bobot++ 2.3.0-darcs <rlb>I'd assumed that a future always started with a "clean slate" with respect to fluids, but it looks like sometimes it doesn't? ***17WAAKK40 is now known as jboy
<civodul>rlb: i think you can't tell what dynamic extent the future will run in <civodul>so in short, mixing fluids and futures is risky <civodul>as in you don't know what value you're going to get <rlb>sneek: tell civodul even though the (touch (future ...)) is entirely within the with-fluids form? It looked to me (naively) like the second future's thread "remembered" the changed fluid value, which I thought might be due to the pool, i.e. re-using the thread. That might make sense if say threads capture the current non-thread-local-fluid values at creation and aren't influenced by subsequent changes to (in this case restoration of) <sneek>civodul, rlb says: even though the (touch (future ...)) is entirely within the with-fluids form? It looked to me (naively) like the second future's thread "remembered" the changed fluid value, which I thought might be due to the pool, i.e. re-using the thread. That might make sense if say threads capture the current non-thread-local-fluid values at creation and aren't influenced by subsequent changes to (in this case restoration of) <rlb>hmm, did I do that wrong? <rlb>sneek: later tell civodul even though the (touch (future ...)) is entirely within the with-fluids form? It looked to me (naively) like the second future's thread "remembered" the altered fluid value, which I thought might be due to the pool, i.e. thread re-use. That might make sense if say threads capture the current non-thread-local-fluid values at creation and aren't influenced by subsequent changes to (say restoration of) the fluid <rlb>We fixed the only issue I know about so far (test-repl), and so if nothing else comes up, I hope to upload 3.0.0+1-1 by the end of the weekend. <rlb>And then we get to argue with all the buildds :) <rlb>Find out just how portable arch-wise 3.0 really is... ***ng0_ is now known as ng0
<jcowan>Building on MacOS (using brew for deps) is not working, per my last message to the list <jcowan>also, Cygwin works but only with JIT disabled <rlb>jcowan: was that for me in the sense of arch/platform issue examples? <jcowan>so I'd say not very portable yet <nly>It's official. This year #nomad-browser intends to apply for and participate in Google Summer of Code. Guix being an organisation that has participated in Gsoc before, we'd be super grateful if anyone from Guix can guide us in the process. *jcowan muses on the spectacle of a program with a huuuuuge ./configure file that runs only on Linux <nly>I'll be sending out formal emails later *jcowan takes the Chicken/Chibi view of autotools generally <nly>rekado I'd be super happy if you can guide us. Not just through Gsoc, but in community building as well. <jcowan>"Just type make. There is probably a sub-Makefile with the options for your OS and architecture, and we autodetect when possible (not yet on Chicken, but *this* close). If you want a totally OS/arch, write your own sub-Makefile and send it to us." <RhodiumToad>separate makefile for os/arch only goes so far, once you start depending on stuff that changes between OS releases <rlb>(...and there's bootstrapping new architectures, cross-compiling, etc.) <rlb>I'm not sure how many harnesses handle that to the extent that the autotools do... <rlb>(Of course that's not critical for a lot of projects.) <jcowan>Well, exactly. That's why I made an explicit comparison with two other Schemes <jcowan>In any case, it is not a separate Makefile, just a short section that writes various #defines into a suitable .h file. <dsmith-work>It really is discouraging to have megabyte sized configure scripts for a C program with only a few hundred lines. <RhodiumToad>though there is a lot of boilerplate in the script, intended to work around shell issues and so on <RhodiumToad>postgresql's configure is ~0.5 megs, and that's from over 80kb of configure.in <dsmith-work>RhodiumToad: Oh, I'm probably exaggerating too much. <dsmith-work>dales@debian:~/src/guile-sqlite$ wc configure sqlite.c <sirgazil>I'm not happy with Guile logo. I'm fine with the G in parentheses, but the expanded version of the logo bothers me. The overlapping of text and the closing parenthesis doesn't feel right. <jcowan>I don't think they have to be: there is no question of trademark here. <jcowan>FWIW which is not much, I like the third row best. ***zap` is now known as zzap`
***zzap` is now known as zap`
