Octave workshop for Octave 3.0.0 on windows Xp

Moritz Borgmann octave at moriborg.de
Fri Mar 28 15:15:11 CDT 2008


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


More information about the Help-octave mailing list