Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
LablGTK2: problem w/ GMain.Io
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-05-08 (18:26)
From: Olivier Andrieu <oandrieu@n...>
Subject: Re: [Caml-list] LablGTK2: problem w/ GMain.Io

> I have a GUI application (the Bantam file manager) that I originally
> wrote in LablTk, and have just ported to LablGTK2. I wrote most of the
> code on a Slackware 10.1 box using GODI with OCaml 3.08.4 and LablGTK2
> 20040716. The GTK2 version is 2.6.1. After implementing all current
> features in GTK and eliminating most of the known serious bugs, I built
> and installed the package on my other Linux box, which runs Arch Linux
> 0.7.1, with Ocaml-3.09.2, GTK2-2.8.17, and LablGTK2-2.6.0.
> Since I found startup to be a bit slow with GTK, I implemented a 'daemon
> mode' for the application. When you start it in daemon mode, the GUI is
> initialized, but remains hidden until it receives a '%show' command via
> a named pipe. Also, when you 'quit' the application via a keystroke
> command or the window manager, it actually only hides the main window.
> To actually quit the application in daemon mode, you send a '%quit'
> command via the above-mentioned pipe.
> Here's the problem: on the development (Slackware) box, I had the app
> running in both normal (GUI shows on startup & is destroyed by quitting)
> and daemon modes with no apparent problems. On the second box, normal
> mode works fine; the app will also run in daemon mode. But when I
> attempt to send a command to the app in daemon mode, I get the following
> error message:
>   ** (bantam.bin:13244): CRITICAL **: GIOChannel watch: callback raised \
>      an exception

That's because your callback raised an exception (!). LablGTK traps
uncaught exceptions from callbacks instead of re-raising them and exiting
the main  loop. For signals, there is a user-overridable handler that
simply prints the exception name to stderr ; for other types of callbacks
(IO watches, timeouts, etc.) you simply get this error message.

In your code you should wrap your "watcher" function in a try...with block
and print the exception using Printexc.to_string to see what's going