Re: GUI work (was: Graphical help browser)

[Ryan Rusaw]

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.