<tupi>what version of guile ? what doc ? <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 :) ***ijp` is now known as ijp
<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. <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>anyway, it's not the only way to quit using SIGINT <dsmith>shanecelis, Sounds like a job for delimited-continuations/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>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>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_ is now known as nalaginrut
<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>nalaginrut: with asyncs i guess, sigitimer, that kind of thing <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.)