Re: GUI work (was: Graphical help browser)

[John Swensen]

On Jan 23, 2009, at 4:21 PM, Ryan Rusaw wrote:

> On Fri, Jan 23, 2009 at 2:09 PM, John Swensen  
> <address@hidden> wrote:
> > On Jan 23, 2009, at 2:30 PM, Pedro L. Lucas wrote:
> >
> > > Hi, I'm developer of QtOctave. I would rather a new API to connect
> > > Octave with IDEs. This API should open pipes from Octave to IDE and
> > > from IDE to Octave. You could send commands to Octave and read  
> > > results
> > > from those pipes. This pipes should be different of stdin and stdout
> > > used by user. Then IDE could send, for example, commands to read  
> > > some
> > > matrix or read help from some command.
> > >
> > > I have read code of Octave and I think it could be written easyly.  
> > > It
> > > doesn't need any thread or fork, only pipes.
> > >
> > > Every-IDE should use this API. Then you could use Emacs, OctaveDE or
> > > whatever you want. This API would be "multi-platform", it can be  
> > > used
> > > in Windows or UNIX.
> > >
> > > Kind regards.
> >
> > Once again, I think we should define an interface and let the guts be
> > implemented independently.  For IDEs like OctaveDE, where the IDE  
> > and Octave
> > are in the same process, pipes or some other IPC is complete  
> > overkill.  Plus
> > I would guess they are slower than the straightforward function  
> > calls used
> > by OctaveDE.  I think that similar to the new graphics frontend/ 
> > backend,
> > there should be a predefined interface which lists the common use  
> > cases for
> > IDE to Octave communications and then let people implement the  
> > backend
> > required to talk to their IDE.
> >
> > That being said, I think there is a case to be made for having a  
> > direct
> > backend (e.g. function call access as in octave_server) and an IPC  
> > backend
> > (e.g. as proposed by you for pipes or recently via DBus).
> >
> > I recently made a list of the expected functionality of this  
> > interface
> > 1) Set, clear, and list breakpoints (maybe extend to watchpoints  
> > when octave
> > supports such a thing)
> > 2) Get a command history list (possibly incremental as in  
> > octave_server?)
> > 3) Get a list of variables in the current scope and the global scope
> > 4) Get or set a variable's value
> >
> > I don't see a real reason to have it return help text, as that is  
> > something
> > that can be pre-processed and put in a help browser.  Although  
> > maybe it
> > would be nice for custom m-files.  Maybe it makes sense to return the
> > current search path, so the help browser can look through user-added
> > directories and generate HTML-ized help.
> >
> > John Swensen
>
> John,
>
> As part of my work on octave/eclipse integration, I implemented an
> Octave interface for DBGP, http://www.xdebug.org/docs-dbgp.php, which
> meets most of the requirements you specify here. DBGP has an advantage
> that several editors already have support for the protocol available.
>
> Emacs: http://code.google.com/p/geben-on-emacs/
> Vi: http://www.vim.org/scripts/script.php?script_id=1152
>
> A snapshot of the source code is available at
> http://octclipse.svn.sourceforge.net/viewvc/octclipse/trunk/octave_dbgp.tar.gz?view=tar
>
> If there is interest, I could spend some time working on removing the
> external threading and socket library dependencies, and get a patch
> ready for inclusion directly into Octave.
>
> Ryan

I don't have a problem with this.  This is essentially the same as  
what I am doing, except the data is returned in XML rather than  
structures and STL containers, and the fact that it is an established  
protocol.  I would still like, however, for there to be multiple ways  
of getting the commands and responses (e.g. a direct function call  
interface and a IPC method).

One more question.  As I read through the spec, it says that the data  
is to be bundled up in BASE64 HEX for the XML, but isn't very specific  
about how that is done for different datatypes.  Can you elaborate?   
Do you do the conversion after a pointer cast to (unsigned char*)?

John