OCaml Forge
SCM

Detail: [#1450] Closing a graphics window in utop crashes utop

Bugs: Browse | Download .csv | Monitor

[#1450] Closing a graphics window in utop crashes utop

Date:
2015-01-11 15:52
Priority:
3
State:
Open
Submitted by:
Carmelo Piccione (struktured)
Assigned to:
Nobody (None)
Hardware:
PC
Resolution:
Accepted As Bug
Severity:
minor
Version:
None
Component:
None
Operating System:
Linux
Product:
None
 
URL:
Summary:
Closing a graphics window in utop crashes utop

Detailed description
utop # #require "archimedes.top";;
Module Archimedes loaded and aliased as A. Module Archimedes loaded and aliased as A. utop # Archimedes.init ["graphics"];;
(Now close window with mouse, eg. the top right X button)
utop # Fatal error: exception Graphics.Graphic_failure("fatal I/O error")
carm@ultima:~/workspace$

Perhaps archimedes.top should catch this close event more gracefully?

Followup

Message
Date: 2015-01-14 09:58
Sender: Pierre Hauweele

> Why do you think ocaml core would never take a patch like that?

Because that would mean interface change, breaking retro-compatibility. And we also need to implement that for windows.

> Maybe this means the native graphics backend is not a great choice.

To achieve interactivity, yes. It lacks too much functionnality.

> Finally, maybe you imagined Archimedes to be controlled programmatically or via top level *text* commands only, in which case I can certainly start molding my process around that methodology.

Archimedes is actually not finished and still subject to big interface changes. Fully interactive backend was in the plans, but not high priority. For now, programmatical control is the way to go.

A "good" way to have something better than Graphics is to put a Cairo backend in GTK. But for now, it's a hackish thing. We may discuss it off-bug-report if you want to dig in that way.
Date: 2015-01-14 05:17
Sender: Carmelo Piccione

Yeesh..what a can of worms!

I'm still exploring the "dynamic" plotting universe in ocaml so I really don't have enough expertise here to advise, except to say I like (2). Failing that, perhaps (4). Why do you think ocaml core would never take a patch like that? Maybe this means the native graphics backend is not a great choice.

This raises questions about interactivity in general with the graphics backend. How limited is it, ultimately? Can one portably implement zoom in/out with a click (or maybe by selecting a rectangular region)? What about dragging the graph to navigate regions? Etc Etc.

Perhaps the above is difficult to do portably unless you used some other graphics backend altogether like Qt or a web frontend to handle ui interactions.

Finally, maybe you imagined Archimedes to be controlled programmatically or via top level *text* commands only, in which case I can certainly start molding my process around that methodology.

Cheers,
Carmelo
Date: 2015-01-13 23:38
Sender: Pierre Hauweele

It actually isn't an easy bug to fix.

Firstly, it's not really Archimedes' fault that the toplevel exits in that case. Exceptions should be (and are) caught by the toplevel which shouldn't crash on it. The fact here is that this exception is not raised by an OCaml function call but by a callback in the C stubs of Graphics after an I/O error which is considered *fatal* by XLib.

Let's say we want to make it not fatal anymore. In order to fix this, one has to ask himself : what code should I wrap in my [try ... with] expression ?
Handling that error after the user has issued an [Archimedes.close vp] is easy. Catching that exception before that, and while the user is doing stuff (or just waiting in the toplevel), is not so straightforward.
One can actually write some code where everything is wrapped in a [try .... with] but the exception is still not caught.

This exception comes from a callback set in the Graphics stubs, which calls :
XSetIOErrorHandler(caml_gr_ioerror_handler);
And caml_gr_ioerror_handler simply raises this exception.
I thus see four ways of solving the bug :
1. spawn a thread to poll-wait for events on the Graphics window. That way, exceptions should be raised through the wait_for_event call and we've got a place to intercept them and make all subsequent calls to the backend raise a proper exception. I don't like it, it's dirty, will introduce complicacies with concurrency, and is not guaranteed to always work.
2. fix Graphics by adding an optional callback argument to open_graph to let the user set his own ioerror handler. Or better, fix the implementation by registering WM_DELETE_WINDOW to the WM_PROTOCOLS of the window and implement a real event handler in Graphics. But I doubt such a patch would be accepted in the OCaml core.
3. in Archimedes' Graphics backend, after the open_graph, manually set the ioerror handler by a call to XLib. The problem with that solution is that we would need to add a dependency to XLib. Moreover, XLib is used for the unix implementation of Graphics. So we would need to check for the OS in the runtime, and at compile time for the dependency.
4. the same as 3., but put the call in a custom C stub shipped with the Graphics backend where we can do the check for windows at compile-time and replace the call by a do-nothing in that case. That should be do-able.

Any other thoughts ?

Attached Files:

Changes:

Field Old Value Date By
ResolutionNone2015-01-13 23:38antegallya