<Madsy>mark_weaver: I have a stacktrace for you now, regarding where guile crashes in Windows with threads enabled <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: compilation froze on the line "GUILEC ice-9/eval.go" for hours, i wonder if it went into infinite loop <nalaginrut>to my experiences for Guile, the halt is normal, vice versa is abnormal ... <b4283>nalaginrut: it's still going XD <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 ... <lloda`>b4283: I had the freeze on ice-9/eval-go, fix (from wingo) was to recompile libgc with GC_MARKERS=1 <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 <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>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 <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? <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)))) <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 :) <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>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 ***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