Re: GUI work (was: Graphical help browser)

[Ryan Rusaw]

On Sat, Jan 24, 2009 at 5:44 PM, John Swensen <address@hidden> wrote:
>
> 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
>

The max_children, max_data, and max_depth features can be configured
so that only a limited amount of data is sent initially, the IDE would
then have to issue additional property_get or property_value commands
to retrieve any more data.

Ryan