octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Octave workshop for Octave 3.0.0 on windows Xp


From: Moritz Borgmann
Subject: Re: Octave workshop for Octave 3.0.0 on windows Xp
Date: Fri, 28 Mar 2008 21:15:11 +0100

At 15:31 Uhr -0400 2008-03-28, John W. Eaton wrote:
On 28-Mar-2008, Moritz Borgmann wrote:

| I don't think Octave should do much in the way of GUI, simply provide
| good hooks for 3rd-party IDE apps to support the features that people
| are used to in the Matlab GUI.

As far as I can tell, that's difficult to do since Octave wants
control of the event loop in order to handle command-line input
properly (i.e., without having the GUI reinvent readline).   But maybe
you have some ideas about how it can be designed so that the GUI can
be in complete control of all events and Octave can still function
properly?

I'm not an expert at all in these matters, so please take my statements with caution. I wasn't actually alluding so much to the handling of the command-line input. I guess it would indeed by hard to have a GUI on top of Octave, but still have Octave handle all command-line editing including readline. But is that a problem? I mean, doesn't the GUI simply have to include decent readline support by itself and it's done?

What I also meant was hooks for debugger and profiler. I don't know how complete debugger support is, profiler is not implemented.

Ryan Rusaw has, as part of the Octclipse project, implemented a) a console proxy that allows IDEs to attach to Octave via sockets, and b) a wrapper that implements the DBGP (Common Debugger Protocol) on top of Octave; again, IDEs can attach to this standardized interface. I'm not too familiar with the technicalities, but this sort of stuff looks interesting in my eyes and may fall under the category "good hooks", possibly applicable beyond the Octclipse project. Broadly speaking, once one supports simple and standardized interfaces, there may be a whole ecosystem of (GUI) tools available to interact with Octave that weren't necessarily made for that.

Another example would be profiling: it could make sense to write out profiler data in, e.g., callgrind format. Then a whole slew of options for display and analysis, far more powerful than the Matlab profiler, would become available, like Kcachegrind.

I'm cross-posting to maintainers since this is turning into a development-related discussion.

-M


reply via email to

[Prev in Thread] Current Thread [Next in Thread]