<dsmith>amz3, Is that a spaceballs reference? <amz3>I didn't know about spaceballs <amz3>anyway, someone is working on a 2D graphics library with a shell, so maybe this might be of interest <dje42>I like John Candy's character. He's a mog, part man part dog. he's his own best friend. <taylanub>amz3: There's guile-2d .. don't know if it's analogous to schwartzapp. <taylanub>Well, Quartz is Apple technology, and the intersection between Apple product users and Guile users is probably rather small. guile-2d uses SDL if memory serves right. <taylanub>Oh wait, sorry, I didn't realized that guile-2d was specifically meant for game development. Not the same thing then, nevermind. ***FractalF1ve is now known as FractalFive
<civodul>ijp: i just saw the peval bug, this is terrible <madsy>I spawn new threads with scm_spawn_thread and scm_primitive_load. Is there a way to interrupt the thread execution from another thread? <ijp>madsy: you want to kill it or ... <ijp>you can call cancel-thread <madsy>ijp: Any idea how I can interrupt a thread without destroying the environment? <madsy>Basically what I want is to create a better REPL <ijp>what do you mean by interrupt <madsy>While embedding scheme in my application <madsy>ijp: Pause the execution of a specific guile environment made by scm_spawn_thread and scm_primitive_load. Without killing it entirely. <ijp>so you want to look at the synchronisation stuff <madsy>But I might have wrong approach. As I said, my goal is to make a better repl. <madsy>I have a message queue from the main thread. By writing to the queue, I can check for input and invoke OpenGL. Somehow I want to glue that to an interactive guile REPL if possible. <ijp>you might look at davexunit's post to guile, since he is using a modified repl in guile 23 <madsy>Ah, he has a github repo. Thanks <madsy>ijp: I think I found a solution. I can just call read with a new port :) <madsy>ozzloy: davexunit implemented coroutines in his 2D game library <ozzloy>that explains why it's not in google docs <ijp>madsy: well that's one way to block <ozzloy>that will help in finding it on the nets <madsy>ijp: Not sure if I can send control characters over a new port though <ijp>if there is a codepoint, you can write it to a port <ijp>if you want something that doesn't have a codepoint (like say, ctrl+tab), then no <ijp>at least once a week someone on #emacs doesn't realise this limitation of terminals <madsy>ijp: Yep, exactly. I thought guile got traps from the terminal instead of the stream, but I wasn't sure <madsy>ijp: That's what I meant earlier. I want to suspend a busy guile program similarly to Ctrl-C <mark_weaver>Ctrl-C is intercepted by the kernel terminal driver, which then sends a signal to the processes in that session. <mark_weaver>you can put a terminal into raw mode, where the kernel doesn't do that, but that's not what most terminal-based programs expect. <mark_weaver>I have another proposed solution, which I think is more practical to do on stable-2.0: <mark_weaver>keep a flag, or maybe some kind of hook, that records the fact that the module has yet been loaded, and then have 'resolve-module' load it if needed. <mark_weaver>your proposed solution is probably better in the long term, but it seems like it might be a big change to do on stable-2.0 <madsy>mark_weaver: Yeah, so (read) by default reads from (current-input-port), which is a dumb byte stream <mark_weaver>madsy: all I/O in Guile is based on byte streams, or character streams built on top of byte streams (using encodings such as UTF-8) <mark_weaver>I'm not aware of any standard byte stream format that encodes arbitrary keyboard combinations such as Ctrl-Tab. <madsy>No, and that would be weird of course. <mark_weaver>for that, you need to use some other kind of library like guile-gnome or guile-xcb <madsy>But I wonder if there's a guile function which temporarily suspends execution, similar to the new environment you get when you hit Ctrl+C ? <madsy>Or is that functionality only done on signals? <mark_weaver>GUI keyboard interfaces also tell you when keys are pressed and released, even if they are just bare modifier keys like Shift or Control. <mark_weaver>madsy: at a higher level, what are you trying to do? for what purpose do you want to interrupt a thread? <mark_weaver>you can queue asyncs on an arbitrary thread in guile, but that won't interrupt a blocking call such as 'read'. <madsy>I want to implement a new REPL. I have my own source for input and displaying output. And I want to be able to interrupt the running guile REPL <mark_weaver>whenever you preempt threads, that raises a lot of thorny issues, mostly having to do with data integrity. <mark_weaver>well, signals are the best tool we have for that in the POSIX world, but they are rather crufty and their interaction with multithreaded programs are not very well standardized. <mark_weaver>I'm afraid that I don't have a good answer for how to do what you want in the general case. <mark_weaver>at least not if you want to have arbitrary numbers of these REPLs running, each in its own threa. <mark_weaver>the basic problem is that signals are process-wide. thread-specific signal delivery is non-standard and not supported by guile's standard signal handling. <mark_weaver>however, if the threads don't block on kernel system calls such as 'read', then it's a bit easier <mark_weaver>if the input is ultimately coming from GUI events, where the threads are in some wait queue pending their input, then you could arrange for those wait queues to be woken up yourself. <mark_weaver>and then, if you've queued an async to run on that thread, it will run and then you can do abort-to-prompt or whatever. <madsy>I guess I'll just ditch the interrupt. It's not that useful anyway. <madsy>I can kill the thread instead if it becomes unresponsive <mark_weaver>I suppose you could evaluate each REPL expression in a fresh new thread, so that if you kill it then it simply returns to the REPL, as you'd expect. <mark_weaver>the REPL thread would wait for the subthread to finish before continuing, of course. <mark_weaver>note that in stable-2.0, ports are not thread safe. you must ensure that two threads don't try to operate on the same port at the same time. <bubble>About yesterday, I've sort of made it with a Linux machine, it was only bootonly lol but I'll manage to install fedora tomorrow when my fuzzball 1GHz dd's the usb img <bubble>after that, I'll try to help out <mark_weaver>bubble_: indeed! Guile 2 is what got me excited enough to get involved :) <bubble_>I was also looking for a project to work on, I am going to try something with graphics or networking e.g. scx <bubble_>X11 scheme interface for scsh and scheme48 <mark_weaver>ah, you might want to take a look at guile-xcb, a relatively new project. <mark_weaver>and guile-wm which is very preliminary, but promising. <bubble_>I have been into SVGs way back, perlyroids, SVG games written in perl and browser <bubble_>guile inside web software would also be cool <bubble_>web integration of smalltalk on HTTP/HTML <mark_weaver>it would be great to be able to run guile code within a web browser, but it's a non-trivial job. <mark_weaver>ijp has suggested writing an implementation of the Guile VM in Javascript, which is a good idea, but we have a lot of C code that would have to be rewritten in either Javascript or Scheme. <ijp>I'm not inclined to do it while we're switching VMs <bubble_>I amgoing to look into cugwin guille also <bubble_>I have debian box at work, I'll try guile 2.2 first on that then later on transfer it to home linux <mark_weaver>bubble_: keep in mind that guile 2.2 doesn't yet exist, there's only the 'master' branch on git which will eventually become 2.2 but is currently in flux and no where near what it will eventually become. <bubble_>I am just back from the kids, on sunday I can talk somewhat <mark_weaver>I'd recommend starting out with the 'stable-2.0' branch. <bubble_>I mean, if I write a patch, would it be for stable ? <mark_weaver>the stable-2.0 branch is still active, and will become 2.0.10 and beyond. but we're somewhat more limited in the changes we can make there: basically, nothing that breaks ABI compatibility. <mark_weaver>but in practice, quite a lot can be done on the stable-2.0 branch. <bubble_>are dependencies a persistent choice ? <bubble_>would we write our own libs in time of e.g. the garbage collector (Boehm) <mark_weaver>I'm sorry, you'll have to phrase your questions more clearly. I still don't understand. <bubble_>In time, would we write e.g. our own garbage collector code instead of using the dependency the boehm library <bubble_>some scheme implementations are written in scheme and have a small vm <bubble_>therefor I thought to minimize dependencies <mark_weaver>bubble_: I don't know. it would be nice to support an optional moving garbage collector at some point. <bubble_>if libguile would have a small footprint there'd be other options <mark_weaver>but boehm gc has significant advantages when mixing with a lot of standard C code that wasn't meant to work in a garbage collected environment. <bubble>thanks, I am going to eat something <vinipsmaker>so, what happened to the guileemacs gsoc project? is it integrated in the repository? will it be available in the next version of emacs/guile? <civodul>vinipsmaker: bipt` said he would send a summary to the lists... <civodul>basically, good progress has been made <civodul>but before anything can be integrated, people will have to talk to each other <vinipsmaker>thanks civodul, i hope everything is gonna be alright <dje42>Is there a canonical (already-implemented) way to plug another app's readline into Guile (e.g. when Guile is linked into an app with its own readline support) ? <dje42>My first thought would be to provide in the app what guile-readline/readline.c provides (at least the minimum to get it working). LIkely to be fragile though.