IRC channel logs

2014-03-03.log

back to list of logs

<davexunit>what is #{}# ?
<ft>(string->symbol "")
<davexunit>ft: thanks
<nalaginrut>morning guilers~
<Madsy>hey nalaginrut
<Madsy>mark_weaver: I have a stacktrace for you now, regarding where guile crashes in Windows with threads enabled
<Madsy>Using w32-pthread
<Madsy>Long story short, it's inside GC_grow_table() called by scm_init_strings () during setup
*nalaginrut pull && make master everyday~
<b4283>nalaginrut: i just found out there's an daily snapshot for guile
<b4283>nalaginrut: http://hydra.nixos.org/build/9326932
<nalaginrut>yeah, nixos, I know it ;-)
<b4283>nalaginrut: compilation froze on the line "GUILEC ice-9/eval.go" for hours, i wonder if it went into infinite loop
<nalaginrut>b4283: master?
<nalaginrut>to my experiences for Guile, the halt is normal, vice versa is abnormal ...
<b4283>nalaginrut: it's still going XD
<nalaginrut>s/vice versa/the opposite
<nalaginrut>sorry for my bad English, I should spend more time on English rather than Scheme..
<b4283>nalaginrut: you should just say "halt is normal, and vice versa"
<b4283>though we are both non-native speakers ...
<nalaginrut>hmm..
<lloda`>b4283: I had the freeze on ice-9/eval-go, fix (from wingo) was to recompile libgc with GC_MARKERS=1
<lloda`>I had an old version...
<lloda>join #guile
<lloda>(sorry)
<b4283>lloda: thanks for the hint
<nalaginrut>b4283: is it solved by the solution?
<b4283>nalaginrut: i haven't had the time to find out yet
<amoe>hey there -- wondering what the best way to write unit tests for guile code is?
<amoe>I'm going to try the SRFI-64 port
<cluck>:)
<dsmith-work>Howdy Guilers
<amoe>I'm curious to know how people would develop using the module system with modules in the current directory.
<amoe>Do you just set GUILE_LOAD_PATH=.?
<dsmith-work>wingo: Did you noticed that the setitimer changes broke a couple of tests in master?
<amoe>Or are most people always "installing" to a secondary location during development.
<wingo>dsmith-work: no i did not!
<dsmith-work>amoe: And -L
<wingo>i will take a look
<wingo>could be that the broken tests are new tests, of course
<dsmith-work>wingo: I've got a build running now. I'll let you know the exact tests that fail in a bit.
<wingo>works for me on my two machiens
<dsmith-work>Hmm. Well, I've not run it here yet.
<Madsy>wingo: I have to ask. Do you know of anyone who have successfully built Guile with threads for Windows, or am I the first bold one? :)
<wingo>Madsy: i have heard of such people :) i think i did so at one point in time? but i don't know tbh
<wingo>Madsy: are you cross-compiling or compiling natively?
<dsmith-work>signals.test
<wingo>dsmith: which one?
<Madsy>cross-compiling. And I'm out of ideas for the moment. Guile still hangs in scm_init_strings()
<dsmith-work>ERROR: signals.test: setitimer: setting values correctly: reset to zero - arguments: ((match-error "match" "no matching pattern" ((1 . 62) (3 . 4187))))
<dsmith-work>ERROR: signals.test: setitimer: usecs > 1e6: reset to zero - arguments: ((match-error "match" "no matching pattern" ((1 . 62) (3 . 4187))))
<dsmith-work>
<wingo>that's interesting
<dsmith-work>Well, I *assumed* it was a setitimer thing.
<wingo>i guess your timer has a different resolution
<Madsy>wingo: Do you remember if libatomic_ops should be built/linked with libgc, even when using pthreads? Also if WIN32_THREADS_TRUE and GC_WIN32_PTHREADS should be defined?
<Madsy>I have a theory that for threading to work with libgc and guile combined, I have to trick libgc to use w32-pthread as vanilla pthreads, without any additional win32 code paths
<wingo>libatomic_ops is built as part og libgc
<wingo>yes you have to get libgc to use pthreads
<Madsy>It does use pthreads here. But it also does some extra windows specific handling
<Madsy>Which I suspect it shouldn't
<Madsy>Also, libatomic_ops is built here but not linked with libgc, because ./configure doesn't think it is required given the platform/thread combination
<Madsy>If you're positive libatomic_ops is required, that's at least something I can try :)
<wingo>dunno actually
<mark_weaver>amoe: the reference implementation of SRFI-64 now fully supports guile 2. IMO, I would stay away from the "port" of SRFI-64 to Guile, which was actually a major rewrite of the SRFI-64 code.
<mark_weaver>SRFI-64 is also in guile git now, and will come with guile 2.0.10
<mark_weaver>the reference implementation is at: http://srfi.schemers.org/srfi-64/testing.scm
<mark_weaver>Madsy: thanks for looking into thread support for guile on mingw. as far as I know, no one has yet gotten it to work.
<Madsy>mark_weaver: I have a GDB stacktrace and a full description of all the different build combinations I've tried, if you're interested
<Madsy>mark_weaver: Also, an interesting note is that the libgc and w32-pthread tests all pass. So if this isn't a bug in guile, then guile does something with libgc that isn't covered in libgc's test, nor w32-pthread's tests
<stis>hej guilers!
<artyom-poptsov>Hi stis
***dje__ is now known as xdje
<Madsy>mark_weaver: Is it possible that using a GULE_FOR_BUILD built without threads/threading support when compiling guile sources for a guile with thread/threading support could lead to a deadlock in the final executable?
<Madsy>Oh, nevermind. I had built guile with threading support locally