Re: GUI work (was: Graphical help browser)

[Pedro L. Lucas]

Hi, I have written a xml interface for Octave. Then, you can insert
commands in xml format and results are returned in xml format. IDEs
can use this interface. Example: IDE can write:
<octave>
<command>2+2</command>
<ide>2+2</ide>
</octave>
the xml interface, then, returns:
<octave>
<command>ans = 4
</command>
<ide>ans = 4
</ide>
</octave>

Using xml tags you can build several pipes for IDE commands.

But I have next problem:

I can not see plots. If you send: "<command>sombrero(20)</command>",
xml interface returns: "<command></command>".

To execute commands, I'm using this function, from 'octave.cc':

------------------

static int
execute_eval_option_code (const char *code)
{
  unwind_protect::begin_frame ("execute_eval_option_code");

  octave_save_signal_mask ();

  can_interrupt = true;

  octave_signal_hook = octave_signal_handler;
  octave_interrupt_hook = unwind_protect::run_all;
  octave_bad_alloc_hook = unwind_protect::run_all;

  octave_catch_interrupts ();

  octave_initialized = true;

  unwind_protect_bool (interactive);

  interactive = false;

  int parse_status = 0;

  try
    {
      eval_string (code, false, parse_status, 0);
    }
  catch (octave_interrupt_exception)
    {
      recover_from_exception ();
      octave_stdout << "\n";
    }
  catch (std::bad_alloc)
    {
      std::cerr << "error: memory exhausted or requested size too
large for range of Octave's index type -- eval failed"
                << std::endl;
    }

  unwind_protect::run_frame ("execute_eval_option_code");

  return parse_status;
}

------------------

I don't know how to do it. Must plot function be executed in
main_loop? Could anybody help me?

Thanks

2009/1/29, Pedro L. Lucas <address@hidden>:
> 2009/1/28, John Swensen <address@hidden>:
>>
>> On Jan 27, 2009, at 10:28 PM, John W. Eaton wrote:
>>
>>> On 28-Jan-2009, Pedro L. Lucas wrote:
>>>
>>> | We need your help to do that. You (or all togheter) must define an
>>> | interface for IDEs.
>>> | If you don't do that, every IDE will make its own interface ==>
>>> Chaos
>>>
>>> Why should this be my job?  I don't personally care that much about
>>> using an IDE for Octave, so I'm fairly certain that I would not be the
>>> right person for this job.  Instead, I think the people who care about
>>> writing and using IDEs should be involved in the discussion, and
>>> should ultimately be the ones to write most of the code.  That doesn't
>>> mean I won't have an opinion about what design is good or bad, or what
>>> should be included in Octave, but I doubt that I will be making it a
>>> priority to come up with something.
>>>
>
> Ok.
>
>> I don't think it is your job. In fact, after the patch was applied to
>> allow multiple event hooks for the readline idle event, I think there
>> is little that need to be added to the core of Octave.  In my case,
>> where I run OctaveDE in the same process, I am able to register an
>> event hook for direct access to Octave data.  However, even for those
>> running in a different process and using IPC, it is really as simple
>> as making something like the octave_server class in OctaveDE as an OCT
>> file and registering it at startup.  It may make sense to have all the
>> IDE people get together and hammer out what this combined IPC and
>> direct call class should look like, and try to make it the same for
>> all IDEs, but in the long run it may *never* need to be part of Octave
>> proper.
>
> input_event_hook is a good solution. I have found some problems in it,
> but they are not important. Example: If you connect octave with pipes
> to IDE,  input_event_hook doesn't work. You must run Octave with
> --read-line option. Try "cat | octave | cat" to check it.
>
>
>>
>>> | If I start to send patches, these patches will work only for
>>> QtOctave,
>>> | because I will define my own interface.
>>>
>>> What prevents you from designing something more general?
>>>
>>> | XML interface sounds good. Easy to use and can be used from all
>>> | programming languajes. I think thqt QtOctave can be modified to
>>> use it
>>> | and so do other IDEs.
>>> |
>>> | What do you think?
>>>
>>> Does XML do a good job for large amounts of binary data (like a large
>>> double precision floating point array, which is something that is
>>> common in Octave)?  If not, then I'm not sure it's really a good
>>> choice.
>>
>> I can imagine the main reason for sending back data will be for
>> scalars.  I often use the variable inspector in the Matlab IDE to
>> quickly see variable values.  I also often use the mouseover feature
>> in the editor after a breakpoint has been hit to see variables.  But,
>> you are right that it is rarely for variables larger than 3 elements.
>>
>
> I'm writing an experimental XML interface for Octave. I'm going to
> check it. Then we can think about it can be useful for IDEs or not. I
> think that IDEs written in Java or Python can use this interface.
> Moreover other tools can use it, a CAD tool could use Octave for its
> calculations. Or tools can send this XML output by sockets and control
> several Octave sessions in several computers (parallel computing).
>
>
>>>
>>>
>>> Why should the IDE run separately from Octave?  It seems to me that it
>>> would be better for it to be more closely integrated.  For example,
>>> running in a separate thread.
>>>
>>>
>>> jwe
>>
>>
>> Having made these comments, I also must comment that as I get further
>> into my PhD, I am finding less and less time to work on OctaveDE.  In
>> fact, the last 2-3 months I probably haven't done more than add a few
>> code comments and answer people's emails about it.  So, I don't know
>> if a call for help is deemed proper by the list admins, but if someone
>> is interested I would be open to some help.  It also might motivate me
>> to stay up late a few more nights if I know someone else is depending
>> on me making progress for them to make progress.
>>
>> John Swensen
>>
>