Is there an undocumented way to specify an error handler in Gambit 3.0? I mean, instead of going into a nested REPL, can Gambit run a function that we provide?
I wrote an X11 window manager with Gambit 3.0. (It's very fast! ;-) ) I run it inside Gambit in interactive mode so that I can watch the log and interact with the system if there's an error. However, if I've switched to a desktop besides the one with the xterm/REPL, and the wm crashes, I can't see the window I need... So I basically need a simple error handler that will map that window. In the meantime I've taken to running the wm from a virtual console under linux (F1, F2, F3, etc...) and switching to it whenever it crashes. For times when it's really unstable, I just use Xnest.
Eduardo
Afficher les réponses par date
Is there an undocumented way to specify an error handler in Gambit 3.0? I mean, instead of going into a nested REPL, can Gambit run a function that we provide?
There is ##catch-all. Here's how you can use it
(define (catch-all-errors thunk) (call-with-current-continuation (lambda (cont) (##catch-all (lambda (x args) (cont "error")) thunk))))
(catch-all-errors (lambda () (+ 1 (/ 2 0)))) => "error"
I wrote an X11 window manager with Gambit 3.0. (It's very fast! ;-) )
Interesting... What are the features of this window manager and do you expect to release it?
By the way, why are you still using 3.0? In 4.0 you could use the documented with-exception-catcher.
Marc
Interesting... What are the features of this window manager and do you expect to release it?
Here's what it looks like right now:
http://proteus.freeshell.org/atomic/screens/anarchy.jpg
From left to right you see... a simple file browser, a couple of
rudimentary REPL's, a text pager, and the main menu. Everything you see, except for the xterm, is running in the same Gambit image. The REPL's are able to introspect into the running gambit image.
Technically, it's already released. Some time ago I posted on the gambit mailing list about a collection of code for gambit called "atomic". The window manager part has been updated since then and I'll probably make another release soon.
As far as features go, it isn't very featureful yet. For example, it doesn't have themes.
It isn't robust either. I.e. there has been no effort towards making it support gnome or kde.
By the way, why are you still using 3.0? In 4.0 you could use the documented with-exception-catcher.
At one point I tried to move all my code to 4.0, but I ran into trouble with compiling it. The gsi/gsc command line interface differences between 3.0/4.0 had not yet been documented. I was having trouble figuring out the new interface. My gsc invocations aren't covered in the examples in 4.0. So I decided to roll back to 3.0 and work on it for a bit.
I am VERY interested in porting all of my atomic library code to 4.0. I'd like to stabilize the code before porting it.
I will have to make some decisions about how to redesign the X11 event handling so as to better utilize the thread support in 4.0. The threads are the main reason why I would want to port to 4.0. In my current system, there is one event loop that reads events. There is a simple alist that maps X11 windows to "widget objects" that know how to handle events. The event handler dispatches events according to the table. When a new widget is created, it registers itself with that table. With 4.0 threads, I wonder if every object that expects events should run in it's own thread and have it's own event loop. Then I could eliminate the global event dispatcher.
Ed
-
Eduardo Cavazos -
Marc Feeley