IRC channel logs

2013-07-09.log

back to list of logs

<tupi>what version of guile ? what doc ?
<agumonkey> http://pastebin.com/i4HkyY1p
<agumonkey>guile 2.1.0 , latest stable doc 2.0.9
<agumonkey>I tried other initargs structures : ... 'r 1 'i 1) or ... #:r 1 #:i 1) in vain
<tupi>agumonkey: see the section 8.5 of the manual, in particular look at how slots are defined to allow setter, getter, accessor, init keyword and init value
<tupi>of course 8.5 is the example code, you'd want to read, before, section 8.4 :)
<agumonkey>tupi: thank, I assumed too much
***ijp` is now known as ijp
<shanecelis>Does SWIG work with guile 2.0?
<nalaginrut>dunno, long time no play SWIG
<nalaginrut>IIRC it doesn't support guile2
<shanecelis>I looked at it a while back and that's what I thought too. It looks like it might have been updated since then though.
<shanecelis>New question, how does Guile run in the REPL such that you can interrupt it with CTRL-C?
<nalaginrut>I don't understand, I always could interrupt it ctrl-c
<shanecelis>nalaginrut: well, what I mean is, that it is interrupted but rather than terminating the process, it drops back to the REPL.
<nalaginrut>you want to quit REPL?
<nalaginrut>ctrl-d
<shanecelis>No, I want to have an interactive app that runs code that might have a endless loop that the user can break out of.
<shanecelis>The app isn't running the REPL. I just want to replicate this bit of functionality.
*shanecelis looks at top-repl.scm
<shanecelis>Hmm... looks like just catching the signal is enough then signaling an error in the signal handler (can we do that?).
<nalaginrut>then you never quit it
<nalaginrut>anyway, it's not the only way to quit using SIGINT
<shanecelis>yeah, quitting is the easier part though.
<dsmith>shanecelis, Sounds like a job for delimited-continuations/prompts
<dsmith>shanecelis, http://www.gnu.org/software/guile/manual/html_node/Prompts.html#Prompts
<shanecelis>dsmith: Yep. I'm using prompts to build up coroutines, but I just want to make sure I can kill rogue coroutines too. :)
<shanecelis>So there's no way to make a non-procedure callable/applyable, right?
<dsmith>Right. Doesn't make sense to apply 3 to something.
<dsmith>Though there are things called applicable smobs. That's about all I know about them though.
<nalaginrut>shanecelis: using SIGINT to kill rogue coroutines?
<shanecelis>nalaginrut: Not necessarily. I just wanted know how the REPL was going about killing its rogue computations.
<shanecelis>I thought it might be doing some kind of weird debug/interpretive thing that might be hard to replicate.
<shanecelis>I still don't know how it's going to work with a GUI though, because the rogue coroutine isn't going to let the run-loop do its thing. :(
<shanecelis>Dammit. Perhaps this will require threads.
<nalaginrut>mitsuki
<nalaginrut>sorry for wrong channel
<shanecelis>Let's say I have this rogue code running (while #t #f) in my GUI app, which is preventing me from continuing my run-loop, so it becomes difficult to see whether the user wants to interrupt the computation. Signals do allow me to interrupt it but those must be delivered from the terminal not the GUI. I tried setting an alarm, but that doesn't seem to work with (while #t #f). If this were C code I'd add a SCM_TICK t
<shanecelis>o try and make the alarm signal work.
<shanecelis>Nevermind. The alarm signal works fine--when you set it! :P
<nalaginrut>shanecelis: yeah~you use alarm for scheduler implementation?
<nalaginrut>but I wonder how can I stop a thread on the fly if I didn't insert (abort) in its code
<nalaginrut>or it have to be cooperative
***nalaginrut_ is now known as nalaginrut
<nalaginrut>hmm...disconnected
<nalaginrut>shanecelis: how can you stop a thread on the fly? if the thread proc didn't insert (abort)?
<nalaginrut>wingo: is there any possible to stop/break a thread if there's no (abort) in the original thread code?
<wingo>moin
<janneke>moin wingo!
<nalaginrut>heya
<wingo>nalaginrut: with asyncs i guess, sigitimer, that kind of thing
<wingo>or traps
<wingo>not sure if traps can capture resumable continuations though
<nalaginrut>well, I have to try, since it could be a common request in the future
<taylanub>shanecelis: As an iOS developer (not proud :P), I can tell you that it's a generally acknowledged and accepted problem (at least in these circles) that functions in the main run-loop block the GUI; application developers are expected to program in dispatch-based style with many short-running functions, or if they want, start a second thread.
<taylanub>(With "these circles" I mean Apple/iOS developers. Not all un-smart people, technically, even if the opposite political camp.)
<wingo>morning civodul
<civodul>hey wingo
<civodul>Hello Guilers! :-)