Re: Debugging and the GUI Editor; Qt help needed

[Ben Abbott]

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