IRC channel logs

2014-03-05.log

back to list of logs

<mark_weaver>civodul: fyi, "./configure --help" in stable-2.0 now says: "--enable-threads={posix|solaris|pth|windows} specify multithreading API"
<mark_weaver>the reason is that the sys_time module now depends on part of the gnulib threadlib module, and this configure option got pulled in as part of the recent gnulib update.
<mark_weaver>I'm not sure if this is a problem, but I'm not sure what to do about it.
<mark_weaver>actually, I wonder if we should switch to using the gnulib threadlib module, instead of posix threads.
<mark_weaver>(but not in stable-2.0, obviously :)
<civodul>mark_weaver: there's an open bug about regexp-exec being not thread-safe because of some gnulibery, and the solution is to provide a glthreads implementation that uses scm_i_pthread
<civodul>soo...
<civodul>the --enable-threads= option is confusing though
<civodul>and i guess it has some real effet
<mark_weaver>hmm
<mark_weaver>I wonder if a better solution would be to not use regexp-exec at all.
<mark_weaver>or rather, to not use the C implementation.
<civodul>hmm
<mark_weaver>SRFI-115, based on irregex, looks very nice.
<civodul>ah yes
<civodul>but still
<civodul>that problem must be solved somehow :-)
*civodul goes to bed, hopes not to dream of all that
<civodul>good night/day!
<zacts>hi
<zacts>mark_weaver: hey, yo. any news on when guile-2.0.10 is going to be released? I have some guys from FreeBSD who are interested.
<nalaginrut>morning guilers!
<mark_weaver>zacts: hopefully soonish. what's the status on getting the new boehm-gc-pthreads package into freebsd?
<zacts>mark_weaver: boehm-gc-pthreads? I just have to clean up my patch and then let a couple of people review it.
<zacts>I'll probably get that in by thu or fri.
<zacts>I'll work on it tonight. I have been exchanging emails with a couple of FreeBSD ports committers.
<mark_weaver>zacts: cool, thanks!
***_zxq9_ is now known as zxq9
***mario-go` is now known as mario-goulart`
***mario-goulart` is now known as mario-goulart
<Madsy>mark_weaver: I think I have some bad news. w32-pthreads doesn't implement pthread_sigmask at all. You can at most get a function that does nothing.
<Madsy>That might mean that guile with threads won't work on Windows without some extra work
<cluck>:)
<davexunit>always smiling, that cluck
<Madsy>Me too, although I try to avoid using emoticons on IRC too much
<Madsy>:) :) :)
<cluck>davexunit: it is one of the few things not yet taxed, got to enjoy it while it lasts =)
<davexunit>if you can't beat em, join em. :)
***dsmith-work is now known as dsmith_}
***dsmith_} is now known as dsmith-work
***sethalve_ is now known as sethalves
<mark_weaver>Madsy: okay, thanks for looking into it. I know of one use of pthread_sigmask that might be important, although I'd like to replace all of that code anyway.
<Madsy>So I'll change my code to use single threading until things gets improved for Windows
<Madsy>mark_weaver: Btw, do you have a rough idea of how much work it would be to get run-server working in Windows? It currently complains about a missing ioctl implementation
<Madsy>I might take a shot at it, if the change required is minor
<mark_weaver>well, run-server needs threads.
<mark_weaver>also, finalizers are very problematic without threads
<Madsy>Crap :(
<Madsy>I thought only spawn-server required threads
<mark_weaver>oh, hmm. I suppose that might be true.
<mark_weaver>oh, no.
<mark_weaver>run-server runs the server listening thread, but then another thread is spawned for each REPL.
<mark_weaver>if all you need is a REPL, you could use scm_shell.
<Madsy>That's how I invoke run-server currently
<mark_weaver>but we need to get threads working on Windows
<Madsy>From a scm_shell
<Madsy>But scm_shell itself isn't exactly fun to develop in
<mark_weaver>why don't you develop on something other than Windows?
<Madsy>I do, but not everyone involved in the project does
<Madsy>So I guess the plan now is to keep two branches around. One with multithreading and one without
<Madsy>The idea was not just to be able to use geiser locally, but also do troubleshooting/debugging on my graphic artist's machine remotely
<mark_weaver>is the issue simply that you want the REPL to be connected to a socket instead of the native stdin/stdout/etc?
<Madsy>I don't know. How would that differ from run-server?
<mark_weaver>run-server can accept multiple connections, so for each connection it spawns a thread.
<Madsy>Right. I guess I can live without that :)
<mark_weaver>if you need only one connection, then just wait for the connection yourself, and then run scm_shell with stdin/stdout/stderr pointing to that socket.
<Madsy>Without threads, I can't connect to a remote REPL and change state while another thread is running, but I can work around that
<Madsy>Hm, if that worked, that would be a great solution
<mark_weaver>do you know anything about how signals are simulated on Windows? in particular, which thread gets a signal?
<mark_weaver>guile has a "signal delivery thread", a dedicated thread that just reads from an internal pipe waiting for messages about signals.
<Madsy>Err.. it's not exactly beautiful. The manual to w32-pthreads mentions some huge obstacles.
<Madsy>For example, all threads in a process share a single signal handler
<Madsy>It's per process, not per thread
<mark_weaver>well, that's already the case for portable POSIX, unfortunately.
<mark_weaver>which is a serious problem, but it's what we already have to deal with.
<mark_weaver>signals are kind of a mess, to be honest.
<mark_weaver>(not just in guile, but generally)
<Madsy>Also, the manual says this:
<Madsy>In any implementation, for sigwait to work reliably, the signals being waited for must be blocked in all threads, not only in the calling thread, since otherwise the POSIX semantics for signal delivery do not guarantee that it’s the thread doing the sigwait that will receive the signal. The best way to achieve this is to block those signals before any threads are created, and never unblock them in the program other than by calling sigwait. This works because
<mark_weaver>how can we block threads is pthread_sigmask is not implemented?
<mark_weaver>s/is/if/
<mark_weaver>that's actually precisely what we need to do: we must arrange (somehow) that our signal delivery thread blocks all signals.
<mark_weaver>maybe there's a way to do that on w32-pthreads, even if it doesn't support the full generality of pthread_sigmask ?
<mark_weaver>see 'signal_delivery_thread' in libguile/scmsigs.c
<mark_weaver>iirc, it has been determined in the past that our problems with threads on mingw are related to this signal delivery thread.
<Madsy>Sorry, I have no idea. Apparently sigwait, sigmask and kill are all noop functions with error handling
<mark_weaver>Madsy: for now, it might be a sufficient hack to change the three checks of SCM_USE_PTHREAD_THREADS in scmsigs.c (lines 116, 253, and 663) to use the non-threaded code on mingw
<Madsy>Oh, I wasn't aware I needed to change anything for single-threaded guile :)
<mark_weaver>(and to avoid the use of signals)
<mark_weaver>Madsy: I mean to try compiling a multi-threaded guile, but with the signal handling in signal-threaded mode.
<mark_weaver>I'd be curious how that works out, because I seem to recall that the signal delivery thread was the problem on mingw.
<Madsy>But without signal support in w32-pthreads, how would signals work at all?
<mark_weaver>do you need signals to work?
<Madsy>Unless guile doesn't use them internally for something, no not at al
<Madsy>all*
<mark_weaver>well, then I think it would be worth a try.
<Madsy>Will do
<Madsy>Should I build guile with multithreading, but without support for threads then?
<Madsy>Those are separate options
<mark_weaver>build everything (guile, libgc, others?) with pthreads support. the only difference is to switch the signal handling in scmsigs.c to use the single-threaded mode for signal delivery.
<mark_weaver>(simple way: replace all occurrences of SCM_USE_PTHREAD_THREADS with 0 in that file)
<mark_weaver>(don't define it to be 0, because that might affect macros that are used in that file)
<Madsy>okay
<mark_weaver>I want to get rid of the signal delivery thread soon anyway.
<mark_weaver>so hopefully this whole issue will be moot.
<mark_weaver>it occurs to me that libgc might not do the right thing on windows when it's compiled for posix threads.
<mark_weaver>libgc needs a way to suspend all threads temporarily while it sweeps.
<mark_weaver>on posix, this is done using signals.
<mark_weaver>they must have some other mechanism for doing it on windows, but maybe that code is not used when it's compiled to use pthreads.
<Madsy>Right. Will multithreaded guile work with libgc built without thread support then?
<mark_weaver>no
<mark_weaver>it may be that our best option for multithreaded guile on windows is to use gnulib's threadlib module, instead of using posix threads directly.
<Madsy>The thing is, Windows today supports everything you need from pthreads. w32-pthreads is just very old
<mark_weaver>is there another project (besides w32-pthreads) that's better?
<mark_weaver>i guess there are several ways we could go here.
***vicenteH` is now known as vicenteH
***dje_ is now known as xdje
<janneke>i could use some help with geiser
<janneke>how do i run it like GUD/gdb in emacs, have it jump to source location of an error or breakpoint?
<janneke>(why is geiser not a GUD backend?)
<davexunit>is that even a feature of geiser?
<davexunit>geiser isn't just a debugger.
<janneke>davexunit: ehh, what is geiser
*janneke is confused
<davexunit> http://geiser.nongnu.org/
<davexunit>geiser integrates the racket and guile REPLs into emacs.
<janneke>davexunit: yes...i'm reading all that
<janneke>but i do C-c C-k (compile buffer) and expect to be able to set (command-line) or something
<janneke>i don't "get" it :-(
<janneke>like gdb bin/lilypond my-music.ly
<davexunit>I have never compiled files with geiser.
<janneke>ah
<davexunit>I use geiser to start a guile REPL
<janneke>geiser pointed me to paredit, which is awesome
<davexunit>so I can interactively develop software.
<janneke>yes, i found repl
<janneke>so i have a wrapper script called bin/ssh.scm which defines the module (ssnel ssh)
<janneke>in repl, i do (use-modules (ssnel ssh))
<janneke>how do i handily set (command-line) and jump to errors?
<janneke>or isn't that how it's done? %-/
<janneke>i'm getting tired of inserting (format) statements and would like a debugger
<davexunit>what is (command-line) ?
<janneke>but i can't wrap my head around geiser
<janneke>that's guile
<davexunit>what does that procedure do?
<janneke>(command-line) returns argv
<davexunit>ah okay
<davexunit>it is a built-in guile procedure.
<janneke>ie, when i run ssh.scm as a script, it has parameters etc
<janneke>yes
<janneke>so i want to run ssh.scm under a debugger, specify a command line, step etc.
<davexunit>janneke: http://www.gnu.org/software/guile/manual/html_node/Pre_002dUnwind-Debugging.html#index-call_002dwith_002derror_002dhandling
<davexunit>this might be what you're looking for
<davexunit>when an error occurs in the procedure called via call-with-error-handling, you will enter the debugger
<davexunit>where you can type things like ,bt to see a backtrace
<mark_weaver>janneke: one common way is to make a 'main' procedure that gets passed the result of (command-line) as an argument. then you can just call 'main' with the arguments you want.
<janneke>davexunit: ... with (call-with-error-handling I managed to get a jump to my ssh.scm source location... :-)
<janneke>thanks!
<davexunit>neat!
<janneke>mark_weaver: of course...that's what i already have...
<mark_weaver>okay
<janneke>mark_weaver: so i start my repl and do (main '(....))
<janneke>hmm
<janneke>mark_weaver: thanks!
<janneke>In ssnel/bin/ssh.scm:
<janneke> 143:18 1 (main ("10" "20"))
<janneke> 64:19 0 (parse-opts ("10" "20"))
<janneke>scheme@(guile-user) [1]>
<janneke>i'm confused that ((@ (ssnel ssh) main) '("10" "20")) did not work...
<janneke>i needed to export main?
<janneke>ah, that's @@ :-/
<mark_weaver>yep :)
<janneke>the call-with-error-handling is also interesting...i just get a prompt upon error
<janneke>but i still do something wrong, i break the program by adding call-with-error-handling
<janneke>hmm
<mark_weaver>janneke: how does it break your program?
<janneke>i insert it here
<janneke>(define (bjobs jids long?)
<janneke> (call-with-error-handling
<janneke> (for-each (lambda (x) (bjob x long?)) jids)))
<janneke>and get
<janneke>ice-9/boot-9.scm:2085:9: In procedure #<unspecified>:
<janneke>ice-9/boot-9.scm:2085:9: Wrong type to apply: #<unspecified>
<wingo>janneke: you are missing a lambda
<wingo>lambda around the (for-each ...)
<janneke>wingo: thanks.... if only i understood why ;-)
<wingo>call-with-error-handling is a procedure
<wingo>not syntax
<janneke>it works! :-)
<mark_weaver>the argument to 'call-with-error-handling' is a procedure to call.
<janneke>ah .. and for-each is not a procedure
<janneke>wow
<mark_weaver>no, for-each is also a procedure.
<mark_weaver>but (for-each ...) does not return a procedure.
*mark_weaver goes afk
<janneke>okay
***adhoc__ is now known as adhoc