Re: GUI work (was: Graphical help browser)

[John Swensen]

On Jan 23, 2009, at 11:30 PM, Ryan Rusaw wrote:

> On Fri, Jan 23, 2009 at 8:29 PM, John Swensen  
> <address@hidden> wrote:
> > 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
>
> I just use a std::stringstream << operator and the appropriate
> octave_value function, then just base64 encode the string.
>
> if (val.is_complex_type()) {
>       data_type = "octave_complex";
>       in << val.complex_value().real()
>                               << std::string(" + ")
>                               << val.complex_value().imag()
>                               << std::string("i");
> } else if (val.is_bool_type()) {
>       data_type = "bool";
>       in << val.bool_value();
> } else if (val.is_integer_type()) {
>       data_type = "int";
>       in << val.int_value();
> } else if (val.is_double_type() ||
>       val.is_single_type()) {
>       data_type = "float";
>       in << val.double_value();
> } else ...
>
> b64.encode(in.str(), base64_encoding);
>
> Its entirely possible there is much more optimal way of doing so,
> especially when I'm iterating through matrices converting each
> element.

I couldn't tell exactly from the spec, but is sending the data back  
with variable information optional?  It seems very large to get every  
variable every time we just want to get variables names.

John Swensen