Re: debug display options

[Daniel J Sebald]

On 08/27/2013 10:49 AM, Rik wrote:
> On 08/27/2013 04:58 AM, address@hidden wrote:
> > Message: 1
> > Date: Mon, 26 Aug 2013 14:35:31 -0500
> > From: Daniel J Sebald<address@hidden>
> > To: "address@hidden"<address@hidden>
> > Subject: Is a debug "silent" option desirable?
> > Message-ID:<address@hidden>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > I don't see any type of option for controlling the text that is
> > displayed by dbstep (either as an option to dbstep() or via separate
> > function such as dbopt()).  With the GUI and its markers and hot-keys in
> > the editor, the verbose text in the command window, such as:
> It's true, it might be nice to be able to control the debug verbosity.  But
> one doesn't usually spend a lot of time in the debugger so my desire to see
> this feature implemented, over others, is pretty low; It just doesn't rise
> to the level of major irritant for me.

That's because, it sounds like, you are content with the command-line 
interface.  It all depends upon what one gets used to and good 
ergonomics and information display.  With the GUI inherently now 
containing much of the information about debugging (and down the line a 
means to quickly get info about the variables via tool tips or whatnot) 
it seems the command line no longer needs to serve that purpose.  A 
dearth of info is bad, while at the same time an abundance of info is 
bad.  I would hope that effort into making a good GUI debugger gets used 
and the user doesn't fall back onto their command-line approach to 
things.  They are certainly welcome to, and should probably be given the 
option to do so in the GUI, but there's always the --no-gui option that 
does that.


> > > > > > test importdata
> > stopped in
> > /usr/local/src/octave/octave/build-gui-12/../octave/scripts/testfun/assert.m
> > at line 102
> > 102:     if (ischar (expected))
> > debug>
> > stopped in
> > /usr/local/src/octave/octave/build-gui-12/../octave/scripts/testfun/assert.m
> > at line 120
> > 120:     elseif (iscell (expected))
> > debug>
> > stopped in
> > /usr/local/src/octave/octave/build-gui-12/../octave/scripts/testfun/assert.m
> > at line 146
> > 146:     elseif (isstruct (expected))
> > debug>
> > etc.
> >
> > seems sort of redundant.  There is this function "dbwhere" which creates
> > the same text as above.  If in debug mode the text is always displayed
> > at the command line, the function "dbwhere" probably doesn't find much
> > use.  Also, wasn't it on the Octave list where there was discussion of a
> > debug feature that allowed showing more lines of text around the current
> > position in the file?
> Yes, I added a function called dblist which lists the current line and +/-5
> lines.  It's still not perfect because it has problems with subfunctions
> and private functions.  But it's been workable enough for me that I haven't
> done anything more.
> >    With that feature, and not having the GUI, the
> > user could probably use the command line interface without requiring the
> > line of code be displayed with each "dbstep".
> I use dbwhere all the time.  Once I get to a failing line I start examining
> variables, running snippets of code, and pretty soon the original
> breakpoint line has scrolled off the screen entirely and I use 'dbwhere' to
> find out where I am again.

Right, but the point wasn't to argue that dbwhere doesn't have a use, 
more that it is available to provide such information (even in the GUI 
setting) such that verbosity doesn't need to be so high.  Going back to 
my point above, I think with the GUI the goal is a new and improved 
paradigm for displaying the info you mentioned.

Dan