IRC channel logs

2013-03-28.log

back to list of logs

<davexunit>djcb: nice! it will be great for some distros to finally have guile 2.
<ijp> https://gist.github.com/5259164
<ijp>Do those sentences work well separately, or should I try and make a paragraph out of it?
<ijp>they seem fine in plain text/info, but for the pdf, not so much
***sneek_ is now known as sneek
<nalaginrut>morning guilers~
<aidalgol>mornin
<nalaginrut>heya
<dsmith>mark_weaver, Well, not that someone would do this, but: scm_t_port port_pair[2];
<dsmith>sneek, logs?
<sneek>Someone once said logs is at http://rotty.xx.vu/irclogs/freenode/%23guile/
<mark_weaver>dsmith: okay, but then what do you do with it? there are no public APIs that have scm_t_port arguments.
<dsmith>sneek, forget logs
<sneek>Consider it forgotten.
<dsmith>mark_weaver, Right.
<dsmith>sneek, logs is https://gnunet.org/bot/log/guile/
<sneek>So noted.
<dsmith>mark_weaver, The old problem with 1.8 in Debian without threads was because the size of some struct changed.
<mark_weaver>dsmith: which struct?
<dsmith>mark_weaver, Whoo. I don't remember. Something that changed size when configured --with or --without threads.
<nalaginrut>mark_weaver: I thought our current 'let' is the same with 'letpar', or not?
<mark_weaver>obviously it's not safe in the general case. in this case, there are no public APIs with scm_t_port arguments, and only guile is allowed to allocate it.
<mark_weaver>nalaginrut: I don't know what letpar is
<mark_weaver>I'm very busy right now on a merge to master.
<dsmith>mark_weaver, Ok.
<nalaginrut>mark_weaver: well, according to the manual, it's let but work on parallel bindings
<nalaginrut>mark_weaver: please concentrate on your current work ;-)
<mark_weaver>no, with letpar, the initializers run in parallel, potentially in separate threads.
<dsmith>mark_weaver, I do think that as long as compiled user code can't know the sizeof the thing, and that the visible members are all at the same offsets, it should be no problem.
<mark_weaver>dsmith: in this case, the user could ask for the size of a scm_t_port, but then what do they do with that?
<mark_weaver>anyway, it looks like we're not going to do it that way anyway.
<nalaginrut>mark_weaver: last question, does let binds vars in parallel?
<dsmith>mark_weaver, RIght. I can't imagine what.
<mark_weaver>nalaginrut: it depends what you mean by "parallel". the initializers all run in the same thread in a 'let'. in some unspecified by serializable order.
<mark_weaver>s/by/but/
<mark_weaver>nalaginrut: let binds in parallel in the sense that you can do (let ((x 1) (y 2)) (let ((x y) (y x)) (list x y))) => 2 1
<mark_weaver>but 'letpar' runs the right-hand-sides potentially in separate threads... thus in "parallel" in a different sense.
<nalaginrut>so x and y could be evaluated in the same time in the same thread in let?
<nalaginrut>I think your "parallel" means runs on different threads
<nalaginrut>but my "parallel" is "maybe evaluated in same time"
<dsmith>nalaginrut, How can it be at the same time unless in different threads on different cores?
<nalaginrut>yes, that make sense
<nalaginrut>so let won't bind in parallel, right? only letpar does that?
<dsmith>Hmm. Nothing to *prevent* let from evaluating bindings in parallel.
<dsmith>iirc, there is no specified order. Could be different from one let to another.
<nalaginrut>well, the aim to my question is about the performance, if 'let' could bind in parallel, I wonder how to use 'letpar'
<dsmith>(let ((v e) ...) body ...) is pretty much identical to ((lambda (v ...) body ...) e ...) , right? (sure hope I got that right)
<dsmith>And function application has no defined order.
<nalaginrut>so 'let' won't bind in parallel, but bind order may different, right?
<dsmith>I think let makes no guarantees. let* does.
<nalaginrut>ok I see thanks
*nalaginrut have to read manual in detail again, since the manual updated much since then...
<dsmith>nalaginrut, I think that's so implementors have freedom to things.
<dsmith>s/to/to do different/
<mark_weaver>dsmith: yes, that equivalence is exactly correct.
<mark_weaver>nalaginrut: there are different meanings of the word "parallel".
<mark_weaver>nalaginrut: latpar means "parallel" in terms of concurrent execution in different threads.
<nalaginrut>mark_weaver: alas, it's so hard for me since I'm not a native English user ;-P
<mark_weaver>'let' is parallel in the sense that all of the variables are *bound* simultaneously, even though the right-hand-side expressions are evaluated sequentially (though in an unspecified order).
<dsmith>mark_weaver, Sequentially? Not in some possibly random order?
<mark_weaver>nalaginrut: you might think that you should use 'letpar' whenever possible, because concurrent execution is good and potentially more efficient, but beware that you pay a heavy price in thread synchronization costs whenever you do anything involving threads. so it only makes sense if the right-hand-side expressions are already fairly expensive to compute.
<cky>mark_weaver: What about if parallelism uses places?
<cky>mark_weaver: Surely that's a huge improvement over using shared memory.
<mark_weaver>dsmith: take the right hand sides, and shuffle them. the implementation is allowed to pick a different order each time it is evaluated. however, once that random order is chosen, they must be evaluated sequentially.
<dsmith>Ok. I see.
<mark_weaver>e.g. in (let ((x (foo)) (y (bar))) (list x y)), either (foo) will finish executing before (bar), or (bar) will finish executing before (foo).
<nalaginrut>OK, I see, so the par-* family functions should use in a scenario that each item needs rather harder computation, or it's totally no need to use it, since it's slower than do it sequentially
<mark_weaver>cky: no matter what you do, there is a heavy cost in today's stock hardware.
<nalaginrut>mark_weaver: do you think par-map/par-for-each is suit for server request handling?
<dsmith>Ok, so implementations are *not* free to automatically evaluate the expressions in multiple threads, possibly in parallel,
<mark_weaver>dsmith: correct.. not with 'let' or procedure calls.
<dsmith>I thought I read that somewhere it could. Maybe it was a proposal to allow it?
<mark_weaver>dsmith: definitely not.
<dsmith>Ok
<dsmith>Thanks
<mark_weaver>dsmith: I can't imagine such a proposal would have gotten anywhere.
<dsmith>Ok. Now I have to go look..
<mark_weaver>cky: the thing is, at the very least, you need to synchronize between threads when to join them before running the body of the letpar.
<cky>Yeah, true.
<mark_weaver>dsmith: what I should have written is: e.g. in (let ((x (foo)) (y (bar))) (list x y)), either (foo) will finish executing before (bar) BEGINS executing, or (bar) will finish executing before (foo) BEGINS executing.
<mark_weaver>in case that wasn't clear.
<dsmith>It was.
*mark_weaver works on merging stable-2.0 to master
<mark_weaver>we should really do this more often. such big merges are a pain.
<mark_weaver>(147 patches this time)
<nalaginrut>nice work~
<mark_weaver>83 patches merged, 64 remaining
<sw2wolf>where is 2.0 github ?
<mark_weaver>git clone git://git.sv.gnu.org/guile.git
<mark_weaver>and checkout the "stable-2.0" branch
<sw2wolf>thx
<mark_weaver>welcome :)
<mark_weaver>note that github is a particular website that we don't use for guile
<sw2wolf>then how to get the newest guile ?
<mark_weaver>we use git, but we don't use github
<sw2wolf>oh , i see
*sw2wolf cloning ...
<sw2wolf>what's the version of master branch ?
<mark_weaver>I don't understand the questoin
<sw2wolf>why do we need to checkout stable-2.0 ?
<mark_weaver>master will eventually be 2.2, but it's a work-in-progress. I recommend you use stable-2.0 for now.
<mark_weaver>actually, we are doing most of our development work directly on the stable-2.0 branch, and only occasionally merge those changes to the master branch. so stable-2.0 is actually more cutting edge.
<sw2wolf>i ever downloaded 2.0.7 which cannot work on FreeBSD
<mark_weaver>(in some ways)
<sw2wolf>i see
<mark_weaver>We are succesfully building the stable-2.0 branch on freebsd <http://hydra.nixos.org/build/4480024> but without thread support.
<mark_weaver>I vaguely recall that there are some unresolved issues with threads on freebsd, but I'm not sure.
<sw2wolf>yeah, i am still using 1.8.x under FB
<mark_weaver>do you need multi-thread support in guile?
<mark_weaver>IMO, the advantages of 2.0 are quite compelling. unless you really need threads, it's probably worth upgrading anyway.
<mark_weaver>(most guile programs don't need threads)
<sw2wolf>I install guile-1.8 from FB packages. And in our codes, we ever used (make-tread ...) call ?
<mark_weaver>I don't understand the question.
<sw2wolf>anyway it is better to use guile with thread support
<mark_weaver>why do you say that?
<mark_weaver>all other things being equal, perhaps. but 2.0 is vastly superior to 1.8.
<mark_weaver>and most scheme programs don't use threads at all.
<mark_weaver>but as you wish...
<sw2wolf>If there is (make-thread ...) call, whether or not we need threaded guile ?
<mark_weaver>there are a lot of different ways to make threads.
<sw2wolf>it doesnot matter. guile-1.18.x works great now. i just want to test 2.x.
<mark_weaver>okay
<mark_weaver>good morning, wingo!
<wingo>good evening, mark_weaver :-)
<mark_weaver>I'm almost done merging stable-2.0 into master.
<mark_weaver>147 patches. whew!
<wingo>you are a valiant individual
<wingo>:)
<mark_weaver>thanks :)
<mark_weaver>everything seems good, but I'm getting two ERRORs and a FAIL in sxml.simple.test
<wingo>humm
<mark_weaver>I seem to recall seeing that in stable-2.0 at some point in the past.
<wingo>about encoding and latin-1 but non-ascii characters?
<mark_weaver>ahh, it must have to do with that.
<wingo>yeah, i would ignore the issue for now -- i/we can fix it later i think
<mark_weaver>maybe. I remember coming across the patch that implemented the environment variable for setting the locale, and concluding that I could just skip it in master.
<mark_weaver>(since master *always* does that)
<wingo>mark_weaver: master needs that patch
<wingo>it will just have a different default
<mark_weaver>ah, okay.
<mark_weaver>so the environment variable can be used to avoid setting the locale, and the test depends on that? is that the issue?
<wingo>no, that test is related to the default encoding on string ports, i think
<wingo>and also, master is more strict than stable-2.0 about ascii versus latin-1
<mark_weaver>okay
<mark_weaver>but we need that patch because we want to be able to disable the locale-setting behavior via the env var?
<mark_weaver>well, I'll take a closer look...
<wingo>you can still have a locale that can't represent all characters
<mark_weaver>*nod*
<wingo>morning, civodul
<mark_weaver>hi civodul!
<civodul>Hello Guilers!
<civodul>it's h24 here :-)
<mark_weaver>hehe
<mark_weaver>would it be possible to postpone 2.0.8 until early next week? maybe monday or tuesday?
<wackOnline>good afternoon
<wingo>h24? :)
<wingo>mark_weaver: fine with me, fwiw; tuesday maybe. dunno if civodul has holiday plans next week?
<civodul>no holiday plans on my side
<civodul>Monday would be a bad idea (April 1st)
<wingo>:)
<mark_weaver>hehe
<civodul>and i won't be avaiable on Tue evening
<civodul>Wed should be fine
<wingo>cool
<mark_weaver>sounds good, thanks!
<mark_weaver>wingo: given that master will install the locale by default, should I remove the explicit GUILE_INSTALL_LOCALE=1 bits during the build?
<mark_weaver>or do you think they should be left?
<wingo>mark_weaver: yes please!
<mark_weaver>cool :)
<nalaginrut>will you consider apply colorized-REPL in 2.0.8? If answer is negative, I'll modify it for guildhall
<nalaginrut>but it can be used in 2.0.8-...
<mark_weaver>my preference would be guildhall
<nalaginrut>hmm...how can I check the version and throw out a error if users don't use 2.0.8?
<mark_weaver>it's better to check for the functionality you need directly.
<mark_weaver>iirc, guile provides the precise version number only in string form.
<nalaginrut>is there a way to compare
<nalaginrut>?
<nalaginrut>ok I see
<nalaginrut>string<?
<mark_weaver>it's not a good idea to check by version number.
<mark_weaver>better to check for the functionality you need.
<nalaginrut>hmm
<mark_weaver>or just don't worry about it, and tell users that it won't work in earlier versions.
<nalaginrut>mark_weaver: users don't read README or manual you know, even me, I haven't read Guile manual for a while...
<mark_weaver>isn't there a hook that you use? can you just check for that hook somehow?
<nalaginrut>so I think throw an info then quit is better while they run it
<nalaginrut>that's fine, I can check it
<nalaginrut>I'm not sure if I put the check in activate-colorized, and it's called from ~/.guile
<nalaginrut>is that a proper way ?
<mark_weaver>you could perhaps use 'eval-when' to check at compile time
<mark_weaver>I don't know. either way.
<mark_weaver>wingo: okay, I pushed the stable-2.0 merge to master. would you like to look into the sxml.simple.test problems?
<mark_weaver>I have to sleep now :)
<mark_weaver>btw, you'll need to clear out language/tree-il/*.go, due to the usual issue with macro dependencies.
<ArneBab>is there a way to disable the initial notes from guile?
<ArneBab>this stuff: ;;; note: source file /tmp/wisptmp.scm
<ArneBab>(and so forth)
<ArneBab>I created a tiny wrapper¹ to make guile run whitespace-lisp programs and the initial notes disturb experimenting. ¹: http://draketo.de/light/english/wisp-lisp-indentation-preprocessor#guilewisp
<civodul>ArneBab: are you aware of http://readable.sf.net ?
<ArneBab>civodul: yes. Being frustrated with the direction of readable was the reason why I wrote wisp.
<ArneBab>civodul: Readable added more and more syntax to optimize for fringe cases and for me that killed the simplicity of lisp.
<ArneBab>civodul: You can find a more detailed reasoning at http://draketo.de/light/english/wisp-lisp-indentation-preprocessor#sec-5
<civodul>aah, too bad
<civodul>i wonder if there's "enough room" for two competing approaches
<civodul>ArneBab: back to your original question, there's `current-warning-port'
<ArneBab>civodul: different goals. I don’t know, but I actually don’t care. Wisp can be used as simple preprocessor, so there is no need to get support from existing interpreters - except from being able to pass lisp code via stdin.
<ArneBab>civodul: where would I put that? .guilerc
<civodul>yes: (current-warning-port (%make-void-port "w"))
<ArneBab>which is the rc file?
<ArneBab>~/.guile and ~/.guilerc don’t work
<ArneBab>~/.config/guilerc?
<civodul>~/.guile should work
<ArneBab>civodul: it seems that I have to actually put -l ~/.guile into the script
<ArneBab>civodul: but now it works. Thank you!
<civodul>~/.guile is only read when running an interactive guile, and without -q
<ArneBab>is there something else?
<ArneBab>civodul: actually there aren’t only 2 competing whitespace-lisp ideas. There’s already SRFI-49, and I think there were some other experiments.
<ArneBab>wisp differs by being simpler (just a preprocessor), but if it should not become the dominant indentation based lisp, then it simply joins the other 99% of languages people created.
<civodul>ok
<ArneBab>civodul: the cool part is that I can already program in wisp now, and I can harness all the power of guile.
<ArneBab>thanks again for the .guile info!
<civodul>you're welcome :-)
<wingo>mark_weaver: i'll take a look at the sxml things
<ijp>morning
<ijp>nalaginrut: I'm increasingly concerned that you are taking a cargo cult approach to performance
<ijp>that might be unfair, but as always, please make sure you are taking the time to profile your program, and making changes where it can actually matter
<ijp>civodul: I am _shocked_ to learn that it has taken us this long to document and=>
<civodul>ijp: me too :-)
<civodul>it had been reported by Guix people who were unfamiliar with that
<taylanub>Is libtool required when using ./configure --enable-shared=no ? Is there more I need to do to disable shared libraries ?
***sneek_ is now known as sneek
<cky>ArneBab: Preprocessor? That sounds terrible, since both SRFI 49 and "readable" are reader replacements, not preprocessors.
<cky>ArneBab: Preprocessing seems to add an extra step, whereas the workflow for a reader replacement is the same as the standard workflow, just with a different reader.
*ijp is sceptical that anyone can write a non-ugly indentation-sensitive lisp
<cky>ijp: Well, ugly is subjective, so....
<cky>ijp: People who are used to S-expressions will probably find anything else ugly. ;-)
<cky>Too bad sw2wolf is gone. I was going to tell them that I do mirror the Guile repo onto GitHub, but only the stable-2.0 branch, and only when new releases are tagged.
<ijp>well, one issue is that, in the presence of macros, you can't limit it to specific forms
<ijp>since people will write forms that expect to be able to take advantage of it
<ijp>but, I don't think it can work for arbitrary sexps
<ijp>i.e. I don't think lisp has enough syntax for it to work
<cky>ijp: Are you talking about "readable", or ArneBab's thing?
<ijp>readable and srfi 49
<cky>ijp: Really? I thought that readable can handle all forms.
<ijp>I never claimed otherwise
<ijp>cky: actually, that's why I find it objectionable
<civodul>from the Serveez announcement: "Unless there is a major outcry from users (unlikely), the next release will drop (all pretense of) support for Guile 1.3.4."
*civodul wonders if he was born when 1.3 was released
<wingo>for reals
<wingo>i honestly wonder if ttn's fork has any non-ttn users
<civodul>heh
<taylanub>Can I build Guile without libtool ?
<wingo>you need ltdl
<wingo>though imo we should remove that dep ;)
<taylanub>I'm trying to cross-compile for iOS, and it complains that it can't find GNU libltdl...
<cky>Isn't libltdl just a layer atop libdl or something like that?
<civodul>yes
<taylanub>It sounds wrong to depend on that even when --enable-shared=no is given to ./configure.
<wingo>it's a dep
<wingo>dependency is the nature of dependencies
<cky>taylanub: I thought --disable-shared just makes libguile static, but it still can load dynamic modules.
*taylanub doesn't know autotools very well.
<taylanub>Oh, I see ..
<civodul>it's not autotools, it's your friendly configure script :-)
<taylanub>The several layers of file-generation involved in the GNU build system is still very unclear to me. I guess theoretically you could do everything with a Makefile, but then it would be full of platform-checks, so OK, you have a configure script that generates a Makefile from a template Makefile.in (although in truth it first generates config.status, to do that?). But then there's configure.ac to generate the configure script, and
<taylanub>Makefile.am to generate the Makefile.in ... WTF ? :P
<taylanub>Hahaha, I just opened the autoconf Info manual, and saw the quote at the start of the Introduction section.
<cky>taylanub: configure.ac is expanded into a bunch of files (including configure) using some m4 scripts.
<cky>taylanub: Makefile.am is expanded into Makefile.in, which is Makefile with some substitutions that configure have to perform.
<cky>taylanub: configure is much much much bigger than configure.ac, and Makefile.in is much much much bigger than Makefile.am.
<muep>afaik some build their Makefile.in files by hand without automake
<taylanub>I know that FFmpeg and MPlayer2 use hand-written configure scripts.
<cky>The auto-generated ones have an advantage in that they're really using a DSL, which means they're easier to review.
<cky>Well, I mean the source versions are easier to review, not the generated ones. ;-)
<taylanub>Hrm, I think I start to understand. A DSL simply has lots of advantages over writing a configure script (which is in sh) manually. Then comes the question why we don't directly use a DSL to transform a Makefile.in into a Makefile, or even use an alternative Makefile format, to which I guess the answer is that sh and make are standard Unix tools and a developer can simply deploy the output configure and Makefile.in files instead of
<taylanub>requiring the users to install non-standard tools ...
<muep>there are also some quite well known solutions which generate Makefiles more directly from a DSL
<taylanub>I reckon some pieces of software require having a special make-alternative installed. cmake comes to mind.
<taylanub>And SCons, and Waf. (Looking at the CMake page on Wikipedia ..)
<lloda>I switched to SCons after a bad experience with Automake
<lloda>I just wish it was in Guile instead of Python
<cky>I'm sure Guile will have its own Guile-based make system soon. Just like in the Ruby world there's Rake.
<civodul>cky: Guix :-)
<civodul>it can be used like Make, even if that's not the primary application
<fangism>!lart cmake, scons, and waf
<taylanub>How do I find out how much memory a function-call used ? E.g. I wrote a tail-recursive function which actually still uses as much memory as the non-tail-recursive version, because it piles up a stack of lambdas each calling the next in its body, so the ,trace output is misleading, so to say.
<stis>The best is to to a theoretical analysis of the program, but typically you win memory.
<stis>Also in guile it is awkward to pile up a hugh stack!
<taylanub>(I guess I kind of confused myself there; stack-growth is only a very specific kind of memory-usage, of course.)
<mark_weaver>taylanub: I don't think Guile currently has much in the way of memory profiling tools, but there are some environment variables that will cause Boehm GC to print statistics, e.g. GC_PRINT_STATS. See http://www.doc.ic.ac.uk/~awl03/cgi-bin/trac.cgi/miro/browser/trunk/gcc/boehm-gc/doc/README.environment
<wingo>there is memprof
<mark_weaver>wingo: do you mean http://gitorious.org/memprof ? Does that work well with Guile?
*wingo looking for link
<wingo>gcproc
<wingo>*gcprof
<mark_weaver>wingo: ah, thanks!
<wingo>(h(gcprof (lambda () (map list (map list (iota 10000000)))))
<wingo>pretty lame
<wingo>but hey
<wingo>s/(h//
<civodul>quite useful, still
<mark_weaver>it's a start :)
<civodul>mark_weaver: i just pushed a fix for GMP < 5, but i only tested with 4.3.2
<civodul>our README says 4.1 is OK
<civodul>do you think it's still the case?
<mark_weaver>I don't know, we'd have to try running numbers.test on a guile built with 4.1
<civodul>i mean, would it /build/ with 4.1? :-)
<civodul>(if it compiles, it works)
<mark_weaver>I remember wanting to add support for exact roots (other than square roots) and getting nak'd because we had to continue supporting an old version of GMP. but I don't remember the details.
<civodul>ok
<mark_weaver>but I confess I haven't been very careful about making sure that 4.1 supports the GMP functions I've been using in new code.
<mark_weaver>I guess I should check it out.
<mark_weaver>OTOH, 4.1 is extremely old, as in the last version of Debian that had a version that old has been moved to the archive.
<mark_weaver>I suspect that almost no one is running such an old version.
<mark_weaver>well, the above is from vague memory, don't take it as reliable information.
<civodul>yeah, 4.1 is old
<civodul>we are all "Skipping PI" now
<civodul>whatever that means
<civodul>:-)
<mark_weaver>ah, here's the thread I started about this: http://lists.gnu.org/archive/html/guile-devel/2011-02/msg00210.html
<mark_weaver>so GMP 4.2 was released in March 2006, and has been in Debian since sarge.
<mark_weaver>(three stable releases ago)
<mark_weaver>so yeah, I'd be really surprised if anyone would be bothered by dropping support for 4.1
<mark_weaver>correction: four stable releases ago...
<mark_weaver>I'd be glad if we could just forget about GMP 4.1, so I could add exact roots to stable-2.0.
<mark_weaver>but if you don't want to, I understand.
<mark_weaver>Four Debian stable releases ago, in case that wasn't clear. The most recent Debian release that didn't have GMP 4.2 or later was Debian woody, released in July 2002.
<civodul>woow, indeed
<civodul>so i'm fine with requiring something later than 4.1
<civodul>just don't know which one exactly
<civodul>4.3.2 was in Jan. 2010
<mark_weaver>excellent, thanks!
<mark_weaver>oops, I see that I corrected myself in a followup to that post I just referenced. actually sarge was the most recent debian release that didn't have GMP 4.2 or later. sarge was released in June 2005.
<mark_weaver>anyway, still pretty old.
<civodul>everything works fine on FreeBSD 8.2 (but with an old pre-7.2 libgc)
<mark_weaver>from what I can see from that old thread, I'd be happy with GMP 4.2 being the minimum required version.
<civodul>so wingo, your thread-related fix did the trick
<dsmith>Oh no! Someone is trying to ./configure PKG_CONFIG=true
<civodul>mark_weaver: ok, then i update README and NEWS
<mark_weaver>thanks :)
<dsmith>Mark Sutton
<wingo>civodul: the freebsd one? excellent!
<wingo>score one for shots in the dark
<mark_weaver>yay!
<wingo>and for premature bug-closing ;)
<mark_weaver>I was just talking to a freebsd user on this channel in the last day or two who would have been happy to know that.
<dsmith>one handed no less.
<wingo>that patch was made with both hands ;)
<wingo>some three weeks ago or so
<mark_weaver>sneek: later tell sw2wolf apparently stable-2.0 can now be built with threads on freebsd :)
<sneek>Got it.
<dsmith>I take it back then
<civodul>wingo: yay, good catch!
<cky>mark_weaver: Maybe I should mirror that commit through to my cky/guile GitHub repo so sw2wolf can use it. ;-)
<cky>mark_weaver: since they seem to like using GitHub. :-P
<civodul>wingo: i did spend some time on it back then, with access to the machine, but i was clueless
<mark_weaver>cky: I really don't see why we need a github mirror.
<cky>mark_weaver: It's my private unofficial mirror.
<mark_weaver>cky: and I don't get the impression that he cared.. he just asked the question sloppily.
<wingo>civodul: many eyes, shallow bugs, & such platitudes
<cky>mark_weaver: Just a place to put in my private branches.
<civodul>:-)
<wingo>i think i looked at other instances of cond_wait, but would be good for someone else to double-check
<civodul>now, note that there are other problems with newer libgcs: http://hydra.nixos.org/build/4516208/log/tail-reload
<civodul>i'll try that
<cky>wingo: cond_wait? Is this to do with fixing up the spurious wakeups? :-)
*cky will be happy to review, as will mark_weaver (I'm sure). :-)
<wingo>yes
<mark_weaver>civodul: oops, thanks for catching my use of GMP 5isms.. ugh.
<mark_weaver>I guess I better try a build against GMP 4.2.
<mark_weaver>also, I think I should just change mpz_inits to multiple calls to mpz_init. more efficient.
<civodul>i don't think it'd make a big difference
<mark_weaver>maybe not, but I only use mpz_* calls directly in places where I'm worry a lot about the overhead (which is already more than I'd like). and mpz_init and mpz_clear are preprocessor macros as I recall.
<mark_weaver>anyway, I'll make sure to test building against an old libgmp in the next couple of days.
<mark_weaver>GMP 4.2 I guess.
<mark_weaver>anyway, gotta go afk for a while. ttyl!
<jaaso>Is (gnome gdk) installed with guile-gnome. Wierd can not find it