Debugging and the GUI Editor; Qt help needed

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Debugging and the GUI Editor; Qt help needed

John W. Eaton
Administrator
I checked in a series of changes that improve the way the GUI editor
works with Octave's debugger.  The editor will now display breakpoints
set with the mouse or with the dbstop function, and it will place a
pointer at the point where execution is currently stopped.  Clearing
breakpoints with the mouse or with dbclear removes the markers from the
editor tab.  Files are opened automatically as needed when stepping into
functions.

It's mostly working, but I've noticed a few quirks.  First, the debugger
is not returning to parent functions properly.  I don't think this has
anything to do with the editor, but is likely a problem that needs to be
fixed in the debugger/evaluator.

Sometimes, clicking in the editor margin to insert a breakpoint will
result in two markers being inserted in the margin for one click.  Then
dbclear won't always clear all of these markers.

The cursor is often displayed at the bottom of the window.  It might be
nice to automatically recenter.  Does someone know how to do that with
QScintilla?  I looked, but couldn't see how to do it easily.

When a breakpoint is set, the focus moves to the editor window.  I find
that I forget that the focus has shifted and start typing debugging
commands into the editor instead of the command window.  Maybe we should
display the window but not change the focus?

If the editor widget is docked when dbstop is used to set a breakpoint,
it remains docked and hidden.  I think this will not be very helpful for
new users, and that it would be better to pop up the editor window so
that the command window and the editor window are both visible.  I'm not
sure how to do that.  Can someone with Qt expertise help with that?

It would be helpful if people could test these new features.  There is
no need to report the problems I've listed above, but if you find other
things that don't work correctly, let me know.  Or if you'd just like to
say, "Wow, these new features look awesome!" that would be fine too.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Catalin Codreanu
Wow, these new features look awesome !

"Sometimes, clicking in the editor margin to insert a breakpoint will
result in two markers being inserted in the margin for one click.  Then
dbclear won't always clear all of these markers."

Is there any way to see which break markers are already present and
where. A simple test could prevent placing a second marker on the same line.

Cheers,
Cat
Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

John W. Eaton
Administrator
On 03/28/2013 04:06 AM, Catalin Codreanu wrote:

> Is there any way to see which break markers are already present and
> where. A simple test could prevent placing a second marker on the same
> line.

It's not that two breakpoints are set on the same line.  They are set on
adjacent lines, and I think that one of them should not be set.  I don't
think this will be too hard to debug and fix, I just haven't had a
chance to look at it yet.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Thorsten Liebig
Am 28.03.2013 09:09, schrieb John W. Eaton:

> On 03/28/2013 04:06 AM, Catalin Codreanu wrote:
>
>> Is there any way to see which break markers are already present and
>> where. A simple test could prevent placing a second marker on the same
>> line.
>
> It's not that two breakpoints are set on the same line.  They are set on adjacent lines, and I think that one of them should not be set.  I don't
> think this will be too hard to debug and fix, I just haven't had a chance to look at it yet.
>
> jwe
>
>
Nice work!

I noticed that two breakpoints are set if you mark an empty or comment only line. You end up with one on that line and the next not-empty line...  It
would make sense to only have the second one?

And I still suffer from the bug, that I cannot abort a running command with STRG+C in the GUI ... :(

br
thorsten
Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Torsten
In reply to this post by John W. Eaton
On 28.03.2013 08:43, John W. Eaton wrote:
> I checked in a series of changes that improve the way the GUI editor
> works with Octave's debugger.  The editor will now display breakpoints
> set with the mouse or with the dbstop function, and it will place a
> pointer at the point where execution is currently stopped.  Clearing
> breakpoints with the mouse or with dbclear removes the markers from the
> editor tab.  Files are opened automatically as needed when stepping into
> functions.

Very nice!

> It's mostly working, but I've noticed a few quirks.  First, the debugger
> is not returning to parent functions properly.  I don't think this has
> anything to do with the editor, but is likely a problem that needs to be
> fixed in the debugger/evaluator.
>
> Sometimes, clicking in the editor margin to insert a breakpoint will
> result in two markers being inserted in the margin for one click.  Then
> dbclear won't always clear all of these markers.
>
> The cursor is often displayed at the bottom of the window.  It might be
> nice to automatically recenter.  Does someone know how to do that with
> QScintilla?  I looked, but couldn't see how to do it easily.

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/f3c93e387865
should fix this.

> When a breakpoint is set, the focus moves to the editor window.  I find
> that I forget that the focus has shifted and start typing debugging
> commands into the editor instead of the command window.  Maybe we should
> display the window but not change the focus?

The editor is not shown but gets the focus which is indeed confusing.

> If the editor widget is docked when dbstop is used to set a breakpoint,
> it remains docked and hidden.  I think this will not be very helpful for
> new users, and that it would be better to pop up the editor window so
> that the command window and the editor window are both visible.  I'm not
> sure how to do that.  Can someone with Qt expertise help with that?

If the command and editor widgets are tabbed or if the editor widget is
floating and overlapping with the main window it is not possible to have
both visible. Should the command widget keep the focus when the
breakpoint was set from the command line?

What should be done if the debugger stops at a breakpoint? I suggest to
bring the editor on top.

> It would be helpful if people could test these new features.  There is
> no need to report the problems I've listed above, but if you find other
> things that don't work correctly, let me know.  Or if you'd just like to
> say, "Wow, these new features look awesome!" that would be fine too.

I found the following issues:

The directory in octave has to be set to the one of the script opened in
the editor if the breakpoints are set in the editor. Maybe this can be
done by just setting the directory before calling dpstop.

The debugger marker (yellow arrow) is not deleted when the script is
continued.

When continuing from the editor menu (or the toolbar) the script is not
continued before I hit return at the debug> prompt. This bug already
existed before and is not related to your changes (s. bug #38319).

Torsten

Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

bpabbott
Administrator
In reply to this post by John W. Eaton

On Mar 28, 2013, at 3:43 AM, John W. Eaton wrote:

> I checked in a series of changes that improve the way the GUI editor works with Octave's debugger.  The editor will now display breakpoints set with the mouse or with the dbstop function, and it will place a pointer at the point where execution is currently stopped.  Clearing breakpoints with the mouse or with dbclear removes the markers from the editor tab.  Files are opened automatically as needed when stepping into functions.
>
> It's mostly working, but I've noticed a few quirks.  First, the debugger is not returning to parent functions properly.  I don't think this has anything to do with the editor, but is likely a problem that needs to be fixed in the debugger/evaluator.
>
> Sometimes, clicking in the editor margin to insert a breakpoint will result in two markers being inserted in the margin for one click.  Then dbclear won't always clear all of these markers.
>
> The cursor is often displayed at the bottom of the window.  It might be nice to automatically recenter.  Does someone know how to do that with QScintilla?  I looked, but couldn't see how to do it easily.
>
> When a breakpoint is set, the focus moves to the editor window.  I find that I forget that the focus has shifted and start typing debugging commands into the editor instead of the command window.  Maybe we should display the window but not change the focus?
>
> If the editor widget is docked when dbstop is used to set a breakpoint, it remains docked and hidden.  I think this will not be very helpful for new users, and that it would be better to pop up the editor window so that the command window and the editor window are both visible.  I'm not sure how to do that.  Can someone with Qt expertise help with that?
>
> It would be helpful if people could test these new features.  There is no need to report the problems I've listed above, but if you find other things that don't work correctly, let me know.  Or if you'd just like to say, "Wow, these new features look awesome!" that would be fine too.
>
> jwe

John,

I'm encountering the error ...

        interpfcn/input.cc:52:22: fatal error: hook-fcn.h: No such file or directory

I see that hook-fcn.h  is included by input.cc in the changeset below.

        http://hg.savannah.gnu.org/hgweb/octave/rev/f33dcbd6a005

But I don't see where it was checked in.  Oversight? or work in progress?

Ben

Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Torsten
In reply to this post by Torsten
On 28.03.2013 12:44, Torsten wrote:
> The directory in octave has to be set to the one of the script opened in
> the editor if the breakpoints are set in the editor. Maybe this can be
> done by just setting the directory before calling dpstop.

I just have seen that the directory is correctly changed in
add_breakpoint_callback.

However, if you have a script named like an octave function (e.g. pkg.m)
and you add a breakpoint in the editor, then the octave file pkg.m is
opened and the breakpoint is set in that file unless the octave
directory matches the directory of your pkg.m file.

Torsten

Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Torsten
In reply to this post by Thorsten Liebig
On 28.03.2013 09:32, Thorsten Liebig wrote:
> Am 28.03.2013 09:09, schrieb John W. Eaton:
>> It's not that two breakpoints are set on the same line.  They are set on adjacent lines, and I think that one of them should not be set.  I don't
>> think this will be too hard to debug and fix, I just haven't had a chance to look at it yet.
>>
> Nice work!
>
> I noticed that two breakpoints are set if you mark an empty or comment only line. You end up with one on that line and the next not-empty line...  It
> would make sense to only have the second one?

In function add_breakpoint_callback the breakpoint is set via
bp_table::add_breakpoint at the next reasonable line (e.g. after blank
and comment lines). I guess setting this breakpoint also sets the marker
in the editor at that line (like dbstop from the command line would do).
At the end of add_breakpoint_callback the marker is set "manually" a
second time but at the original line number.

The same holds for remove_breakpoint_callback. Moreover, the increment
of the line number is missing in this function

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/75a6716b72a2
should fix this.

Torsten


Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

John W. Eaton
Administrator
In reply to this post by bpabbott
On 03/28/2013 07:46 AM, Ben Abbott wrote:

>
> On Mar 28, 2013, at 3:43 AM, John W. Eaton wrote:
>
>> I checked in a series of changes that improve the way the GUI editor works with Octave's debugger.  The editor will now display breakpoints set with the mouse or with the dbstop function, and it will place a pointer at the point where execution is currently stopped.  Clearing breakpoints with the mouse or with dbclear removes the markers from the editor tab.  Files are opened automatically as needed when stepping into functions.
>>
>> It's mostly working, but I've noticed a few quirks.  First, the debugger is not returning to parent functions properly.  I don't think this has anything to do with the editor, but is likely a problem that needs to be fixed in the debugger/evaluator.
>>
>> Sometimes, clicking in the editor margin to insert a breakpoint will result in two markers being inserted in the margin for one click.  Then dbclear won't always clear all of these markers.
>>
>> The cursor is often displayed at the bottom of the window.  It might be nice to automatically recenter.  Does someone know how to do that with QScintilla?  I looked, but couldn't see how to do it easily.
>>
>> When a breakpoint is set, the focus moves to the editor window.  I find that I forget that the focus has shifted and start typing debugging commands into the editor instead of the command window.  Maybe we should display the window but not change the focus?
>>
>> If the editor widget is docked when dbstop is used to set a breakpoint, it remains docked and hidden.  I think this will not be very helpful for new users, and that it would be better to pop up the editor window so that the command window and the editor window are both visible.  I'm not sure how to do that.  Can someone with Qt expertise help with that?
>>
>> It would be helpful if people could test these new features.  There is no need to report the problems I've listed above, but if you find other things that don't work correctly, let me know.  Or if you'd just like to say, "Wow, these new features look awesome!" that would be fine too.
>>
>> jwe
>
> John,
>
> I'm encountering the error ...
>
> interpfcn/input.cc:52:22: fatal error: hook-fcn.h: No such file or directory
>
> I see that hook-fcn.h  is included by input.cc in the changeset below.
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/f33dcbd6a005
>
> But I don't see where it was checked in.  Oversight? or work in progress?

It was a mistake that I didn't add it in that changeset, but it was
added later.  Also, all the changes I described are not present unless
you are working with

   http://hg.savannah.gnu.org/hgweb/octave/rev/4902484f9181

or later.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

bpabbott
Administrator

On Mar 28, 2013, at 10:35 AM, John W. Eaton wrote:

> On 03/28/2013 07:46 AM, Ben Abbott wrote:
>>
>> On Mar 28, 2013, at 3:43 AM, John W. Eaton wrote:
>>
>>> I checked in a series of changes that improve the way the GUI editor works with Octave's debugger.  The editor will now display breakpoints set with the mouse or with the dbstop function, and it will place a pointer at the point where execution is currently stopped.  Clearing breakpoints with the mouse or with dbclear removes the markers from the editor tab.  Files are opened automatically as needed when stepping into functions.
>>>
>>> It's mostly working, but I've noticed a few quirks.  First, the debugger is not returning to parent functions properly.  I don't think this has anything to do with the editor, but is likely a problem that needs to be fixed in the debugger/evaluator.
>>>
>>> Sometimes, clicking in the editor margin to insert a breakpoint will result in two markers being inserted in the margin for one click.  Then dbclear won't always clear all of these markers.
>>>
>>> The cursor is often displayed at the bottom of the window.  It might be nice to automatically recenter.  Does someone know how to do that with QScintilla?  I looked, but couldn't see how to do it easily.
>>>
>>> When a breakpoint is set, the focus moves to the editor window.  I find that I forget that the focus has shifted and start typing debugging commands into the editor instead of the command window.  Maybe we should display the window but not change the focus?
>>>
>>> If the editor widget is docked when dbstop is used to set a breakpoint, it remains docked and hidden.  I think this will not be very helpful for new users, and that it would be better to pop up the editor window so that the command window and the editor window are both visible.  I'm not sure how to do that.  Can someone with Qt expertise help with that?
>>>
>>> It would be helpful if people could test these new features.  There is no need to report the problems I've listed above, but if you find other things that don't work correctly, let me know.  Or if you'd just like to say, "Wow, these new features look awesome!" that would be fine too.
>>>
>>> jwe
>>
>> John,
>>
>> I'm encountering the error ...
>>
>> interpfcn/input.cc:52:22: fatal error: hook-fcn.h: No such file or directory
>>
>> I see that hook-fcn.h  is included by input.cc in the changeset below.
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/f33dcbd6a005
>>
>> But I don't see where it was checked in.  Oversight? or work in progress?
>
> It was a mistake that I didn't add it in that changeset, but it was added later.  Also, all the changes I described are not present unless you are working with
>
>  http://hg.savannah.gnu.org/hgweb/octave/rev/4902484f9181
>
> or later.
>
> jwe

I pulled the latest changes an hours ago.  Looking  now, I see I'm able to build again.

Thanks

Ben


Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

John W. Eaton
Administrator
In reply to this post by Torsten
On 03/28/2013 07:44 AM, Torsten wrote:
> On 28.03.2013 08:43, John W. Eaton wrote:

>> The cursor is often displayed at the bottom of the window.  It might be
>> nice to automatically recenter.  Does someone know how to do that with
>> QScintilla?  I looked, but couldn't see how to do it easily.
>
> Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/f3c93e387865
> should fix this.

Thanks.  Should we also scroll the window to keep the position marker
(the yellow arrow) near the center?

> If the command and editor widgets are tabbed or if the editor widget is
> floating and overlapping with the main window it is not possible to have
> both visible. Should the command widget keep the focus when the
> breakpoint was set from the command line?
>
> What should be done if the debugger stops at a breakpoint? I suggest to
> bring the editor on top.

If both editor and command window are tabbed, is it possible to split
the area where the editor and command window tabs appear so that one is
above the other?  If either is detached, then I think it is fine to
leave them alone as presumably the user has arranged them in some way.

> The directory in octave has to be set to the one of the script opened in
> the editor if the breakpoints are set in the editor. Maybe this can be
> done by just setting the directory before calling dpstop.

I think this problem is not limited to the GUI.  The debugger is
currently limited to setting breakpoints using only a function name.
The file found then depends in some way on the symbol table.  It should
probably be possible to set a breakpoint in a file directly.

> The debugger marker (yellow arrow) is not deleted when the script is
> continued.
>
> When continuing from the editor menu (or the toolbar) the script is not
> continued before I hit return at the debug>  prompt. This bug already
> existed before and is not related to your changes (s. bug #38319).

OK, I'll check these out.

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Torsten
On 28.03.2013 15:44, John W. Eaton wrote:

> On 03/28/2013 07:44 AM, Torsten wrote:
>> On 28.03.2013 08:43, John W. Eaton wrote:
>
>>> The cursor is often displayed at the bottom of the window.  It might be
>>> nice to automatically recenter.  Does someone know how to do that with
>>> QScintilla?  I looked, but couldn't see how to do it easily.
>>
>> Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/f3c93e387865
>> should fix this.
>
> Thanks.  Should we also scroll the window to keep the position marker
> (the yellow arrow) near the center?

After the debugger has stopped, the yellow arrow points to the line with
the cursor which is in the center. Or do I get you wrong?

>> If the command and editor widgets are tabbed or if the editor widget is
>> floating and overlapping with the main window it is not possible to have
>> both visible. Should the command widget keep the focus when the
>> breakpoint was set from the command line?
>>
>> What should be done if the debugger stops at a breakpoint? I suggest to
>> bring the editor on top.
>
> If both editor and command window are tabbed, is it possible to split
> the area where the editor and command window tabs appear so that one is
> above the other?  If either is detached, then I think it is fine to
> leave them alone as presumably the user has arranged them in some way.

Showing command ans editor window side by side is possible but should we
really destroy the users window layout during debugging?

>> The directory in octave has to be set to the one of the script opened in
>> the editor if the breakpoints are set in the editor. Maybe this can be
>> done by just setting the directory before calling dpstop.
>
> I think this problem is not limited to the GUI.  The debugger is
> currently limited to setting breakpoints using only a function name. The
> file found then depends in some way on the symbol table.  It should
> probably be possible to set a breakpoint in a file directly.

What I do not understand is that the directory of the function is
correctly set before setting the breakpoint but obviously without having
any effect. Changing the directory manually and then setting the
breakpoint works fine.

Torsten

Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

John W. Eaton
Administrator
On 03/28/2013 10:55 AM, Torsten wrote:
> On 28.03.2013 15:44, John W. Eaton wrote:

>> Thanks.  Should we also scroll the window to keep the position marker
>> (the yellow arrow) near the center?
>
> After the debugger has stopped, the yellow arrow points to the line with
> the cursor which is in the center. Or do I get you wrong?

No, I see now that it works.  Thanks.  I thought your change was about
centering the window around the location of the breakpoint marker (the
red dot).

> Showing command ans editor window side by side is possible but should we
> really destroy the users window layout during debugging?

I think Matlab splits the window, but maybe someone could confirm?

There's probably no way to please everyone here.  So long term, I think
the behavior may need to be customizable.  But for now, it would be good
enough to just have a reasonable default and worry about allowing
customization later.

> What I do not understand is that the directory of the function is
> correctly set before setting the breakpoint but obviously without having
> any effect. Changing the directory manually and then setting the
> breakpoint works fine.

I'll have to look at it.

Can you give a precise recipe for the problem?  Are you setting the
breakpoint from the editor with a file already open there?  What is the
current directory when it works/fails?  Are you setting the breakpoint
in a script or a function?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Torsten
On 28.03.2013 17:07, John W. Eaton wrote:

> On 03/28/2013 10:55 AM, Torsten wrote:
>> What I do not understand is that the directory of the function is
>> correctly set before setting the breakpoint but obviously without having
>> any effect. Changing the directory manually and then setting the
>> breakpoint works fine.
>
> I'll have to look at it.
>
> Can you give a precise recipe for the problem?  Are you setting the
> breakpoint from the editor with a file already open there?  What is the
> current directory when it works/fails?  Are you setting the breakpoint
> in a script or a function?

1. open a file (script or function) with the same name as an octave
function (e.g. home/ttl/pkg.m)

2a. The actual octave directory is _not_ /home/ttl:

    Setting a breakpoint in the editor (mouse click or menu) opens
    the octave funtion pkg.m and sets the breakpoint there

2b. The actual octave directory is /home/ttl:

    Setting a breakpoint in the editor (mouse click or menu) really
    sets the breakpoint in /home/ttl/pkg.m
    If starting with case 2a, it is not enough to change the
    directory but you have to run the file from the editor

In case of 2a, a dbstop from the command line clearly sets a breakpoint
in the octave function pkg.m. But setting the breakpoint in the editor
file /home/ttl/pkg.m should not open another file and set the breakpoint
there.

Torsten


Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Daniel Sebald
In reply to this post by John W. Eaton
On 03/28/2013 02:43 AM, John W. Eaton wrote:

> It would be helpful if people could test these new features. There is no
> need to report the problems I've listed above, but if you find other
> things that don't work correctly, let me know. Or if you'd just like to
> say, "Wow, these new features look awesome!" that would be fine too.

I haven't compiled and run yet, so I assume it looks awesome.

I looked at the code, though, e.g.,

   http://hg.savannah.gnu.org/hgweb/octave/rev/389b09a914e2

and I would suggest that we try to not introduce callbacks in the way
you have done.  The problem with the callbacks is it is connecting two
threads with functions.  We should be using the Qt signal/slot mechanism
across threads.  Otherwise there is a good chance we're unnecessarily
restricting capabilities and possibly making programming more difficult
down the road.

Feel free to continue though.  I have a dialog patch almost ready to go
that should give an example of what I'm talking about.  I'll write back
in a couple days and see what we can do to remain within the signal/slot
concept.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

John W. Eaton
Administrator
On 03/28/2013 02:08 PM, Daniel J Sebald wrote:

> On 03/28/2013 02:43 AM, John W. Eaton wrote:
>
>> It would be helpful if people could test these new features. There is no
>> need to report the problems I've listed above, but if you find other
>> things that don't work correctly, let me know. Or if you'd just like to
>> say, "Wow, these new features look awesome!" that would be fine too.
>
> I haven't compiled and run yet, so I assume it looks awesome.
>
> I looked at the code, though, e.g.,
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/389b09a914e2
>
> and I would suggest that we try to not introduce callbacks in the way
> you have done. The problem with the callbacks is it is connecting two
> threads with functions. We should be using the Qt signal/slot mechanism
> across threads. Otherwise there is a good chance we're unnecessarily
> restricting capabilities and possibly making programming more difficult
> down the road.

Then can you please provide an example that shows how to do that for one
of these cases?  I don't mind changing the way things are done if it
really does make a difference, but I need some pointers here as I'm
almost clueless about the proper way to do Qt programming.  Just saying
"use signals/slots" doesn't help me much.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Daniel Sebald
On 03/28/2013 01:21 PM, John W. Eaton wrote:

> On 03/28/2013 02:08 PM, Daniel J Sebald wrote:
>> On 03/28/2013 02:43 AM, John W. Eaton wrote:
>>
>>> It would be helpful if people could test these new features. There is no
>>> need to report the problems I've listed above, but if you find other
>>> things that don't work correctly, let me know. Or if you'd just like to
>>> say, "Wow, these new features look awesome!" that would be fine too.
>>
>> I haven't compiled and run yet, so I assume it looks awesome.
>>
>> I looked at the code, though, e.g.,
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/389b09a914e2
>>
>> and I would suggest that we try to not introduce callbacks in the way
>> you have done. The problem with the callbacks is it is connecting two
>> threads with functions. We should be using the Qt signal/slot mechanism
>> across threads. Otherwise there is a good chance we're unnecessarily
>> restricting capabilities and possibly making programming more difficult
>> down the road.
>
> Then can you please provide an example that shows how to do that for one
> of these cases? I don't mind changing the way things are done if it
> really does make a difference, but I need some pointers here as I'm
> almost clueless about the proper way to do Qt programming. Just saying
> "use signals/slots" doesn't help me much.

This evening and tomorrow I can clean up the code I have and create a
patch.  I think it is easiest to work from a diff file.  But for the
time being here are a few lines to illustrate, and I'm sure it will be
clearer with the whole changeset to follow:

IN THE OCTAVE THREAD

I've written some builtin routines that really don't touch core Octave
code.  Instead, they act like a driver of sorts.  e.g.,

           // Signal GUI thread to put up simple message box using OK
           // as the only button.
           uiwidget_creator.signal_dialog (message, title, icon,
QStringList (),
                                           QString (), QStringList ());

           // Wait while the user is responding to message box.
           waitcondition.wait (&mutex);

The above uiwidget_creator is just a basic class where I've organized
all the signals and slots.  It is basically an "emit" with the same
input arguments as "signal_dialog()".  I do that so that the data
transferred across threads can be stored in uiwidget_creator's object.
Anyway, you can see that the octave thread emits the signal, then
suspends itself, with no function call across to the GUI thread.  Later
the thread is awaken with:

void
QUIWidgitCreator::dialog_finish_continue (int result)
{
   // Store the value so that builtin functions can retrieve.
   dialog_result = result;

   // Wake up Octave process so that it continues.
   waitcondition.wakeAll();
}

which is a slot that is accessed by the GUI thread emitting the
connected signal.  The "result" is the data that the GUI thread is
sending.  Pretty minimal in this case.  After the "wakeAll", the Octave
thread continues right after the "waitcondition.wait (&mutex);" line in
the hunk above.

IN THE GUI THREAD

At startup, the main window makes the connections:

   connect (&uiwidgit_creator, SIGNAL (create_dialog (const QString&,
                               const QString&, const QString&,
                               const QStringList&, const QString&,
                               const QStringList&)),
            this,              SLOT (handle_create_dialog (const QString&,
                               const QString&, const QString&,
                               const QStringList&, const QString&,
                               const QStringList&)));

so that the Octave thread can signal that it would like a QMessageBox
placed on the screen.

The "handle_create_dialog" slot in the GUI thread then does this, and it
makes connections between the message box it is creating and the slots
(analogous to callbacks) in the Octave thread.

// Create a dialog with specified string and connect to a wait condition
// to wake up thread.
void
main_window::handle_create_dialog (const QString& message, const
QString& title,
                                    const QString& icon, const
QStringList& button,
                                    const QString& defbutton,
                                    const QStringList& role)
{
// Process all this stuff

   // Create a NonModal message about error.
   QMessageBox* msgBox = new QMessageBox (eicon, title, message, 0, 0);

   connect (msgBox,            SIGNAL (buttonClicked (QAbstractButton *)),
            &uiwidgit_creator, SLOT (dialog_button_clicked
(QAbstractButton *)));
   connect (msgBox,            SIGNAL (finished (int)),
            &uiwidgit_creator, SLOT (dialog_finish_continue (int)));
   msgBox->show ();

You can guess that the slot on the Octave thread side
(dialog_finish_continue), is that small hunk of code that wakes up the
Octave thread.  Whenever the button on the QMessageBox is pressed, it
signals the slot in the Octave thread that it is finished and gives it
the data.

SUMMARY

So, there isn't any function call across threads.  This example is a
little more dynamic than what might be needed for the debugger because
the message box is created and then connections are made.  In the
debugger case, maybe just the initial connections at startup would be
needed.  What the example I give does do is it enables the use of the
Mutex and other similar concepts in Qt.  That's the thing that could
prove beneficial down the line.  Hard to say, but I just think that
remaining within the Qt paradigm as much as possible can only be good.

How might this play out in the debugger case?  Well, one can be creative
and come up with different ways, but I can imagine that clicking a debug
tab issues a signal to some object in the Octave thread that then
disables the breakpoint in Octave core code.  So on.  These things are a
bit of trial and error for a while until everything falls in place and
then it is like, "I should have used that signal/slot sooner!".

Think in terms like this:

                                       |
OCTAVE CORE <--> BUILTIN COMM OBJECT  |  GUI THREAD
                                       |

and there are signals/slots across the thread.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Daniel Sebald
On 03/28/2013 02:00 PM, Daniel J Sebald wrote:

> Think in terms like this:
>
>                                      |
> OCTAVE CORE <--> BUILTIN COMM OBJECT | GUI THREAD
>                                      |

I should point out that the item labeled "BUILTIN COMM OBJECT" is not
included if the GUI is not compiled as part of octave.  That is why I've
put the builtin routines I've written under "libgui" and not "libinterp"
where all the other builtin functions are.

Dan
Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

Daniel Sebald
On 03/28/2013 02:18 PM, Daniel J Sebald wrote:

> On 03/28/2013 02:00 PM, Daniel J Sebald wrote:
>
>> Think in terms like this:
>>
>> |
>> OCTAVE CORE <--> BUILTIN COMM OBJECT | GUI THREAD
>> |
>
> I should point out that the item labeled "BUILTIN COMM OBJECT" is not
> included if the GUI is not compiled as part of octave. That is why I've
> put the builtin routines I've written under "libgui" and not "libinterp"
> where all the other builtin functions are.

Let me toss out an idea, just to give an alternate paradigm on this.
There are other ways to do this, I imagine.  Say I want to run the
"dbstop" command at the command line and that causes a red (yellow?) dot
to appear next to the appropriate line in the editor.  And I want to do
so without any alteration to the core Octave code.  I might do the
following:

1) Write a builtin routine "qtdbstop(FILE,RLINE)" that will send a
signal to the editor that it should place a dot somewhere.

2) Now, create an M-script (kept under the libgui code) that will
override Octave's dbstop internal routine, something like:

function
   try
     RLINE = dbstop (FUNC,LINE);
     qtdbstop (FILE,RLINE);
   catch
     display ("Sorry, break point not set");
   endtry

Is it possible to call Octave's builtin function from within an M-script
with the same name?

Dan
Reply | Threaded
Open this post in threaded view
|

Re: Debugging and the GUI Editor; Qt help needed

John W. Eaton
Administrator
In reply to this post by Daniel Sebald
On 03/28/2013 03:18 PM, Daniel J Sebald wrote:

> On 03/28/2013 02:00 PM, Daniel J Sebald wrote:
>
>> Think in terms like this:
>>
>> |
>> OCTAVE CORE <--> BUILTIN COMM OBJECT | GUI THREAD
>> |
>
> I should point out that the item labeled "BUILTIN COMM OBJECT" is not
> included if the GUI is not compiled as part of octave. That is why I've
> put the builtin routines I've written under "libgui" and not "libinterp"
> where all the other builtin functions are.

I'm still not sure I understand, but let me try to explain what
currently happens when using dbstop at the Octave command window
prompt as that is I think similar to your dialog example.

Initially, a callback function is installed when the
GUI starts so that the GUI can take some action when a breakpoint is
inserted in the Octave interpreter's table of breakpoints.

So, when dbstop is called, Octave sets the breakpoint in the
interpreter and calls the function installed by the GUI.

That function extracts the file and line number information and
ultimately calls octave_qt_event_listener::update_dbstop_marker, which
emits the signal update_dbstop_marker_signal.  That signal is handled by
main_window::handle_update_dbstop_marker_request, which calls
functions from the file_editor class to display the breakpoint marker
icon in the GUI edidtor window.

Which of these function calls is not safe to perform, or called in the
wrong context?

How should this job be done differently?

jwe
12