gdba probs

gdba probs

[Nick Roberts]

Miles Bader writes:

> Seeing the recent activity on `gdba', I decided to check it out, and got
> bunches of errors.  The gdb command line I used was this:
...

> It initially divided the frame into 6 (!) windows, most of which I
> don't want; 

The totalview debugger starts with 6 windows. But, hey!, lets be open minded
about this. How do you know you don't want them before you know what they do ?

> is there a way to customize which windows it uses?

(setq gdb-many-windows nil) gives you the just the two windows that I think
you're looking for. C-h f `gdba' explains a bit more.

Regarding the bunches of errors, they occur because you're using commands that
stop/step at the instruction level (break *_start, stepi, etc). Handling these
commands is on my TODO list. ;-)

For the moment if you want explore what this mode does you have to stick to
the statement level (break main, step, etc). I append below a nonsense program
that I have used to develop gdb-ui.el. Clearly this isn't useful test the lisp
code but it might help to show what it can do.

> BTW, note all the spurious `Mark set' and `Replaced 0 occurrences'
> messages (I never set the mark or did any replacing) -- it looks like
> some lisp code is using the `replace-string' function when it shouldn't
> (generally lisp code shouldn't use it at all).

I'm using replace-regexp which I know I shouldn't. The elisp manual does say
this but doesn't offer an alternative. I have noticed in vc.el from emacs-20.7 :

;; (replace-regexp (concat ":" (regexp-quote file) "$") (concat ":" newname))
(while (re-search-forward (concat ":" (regexp-quote file) "$") nil t)
   (replace-match (concat ":" newname) nil nil))

Is this construction a standard replacement for replace-regexp in lisp programs ?
(if so I think it would be a good idea to say so in the manual)

Nick

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

temp.c...

/* cc -g -o temp temp.c myprint.o */
typedef struct {
  int r;
  float s;
} substruct;

typedef struct {
  int* r;
  float* s;
} subref;

main(int argc, char **argv) {
  int a[10]={0,1,4,9,16,25,36,49,64,81};
  int i,j,n,bigarray[20][20];
  int* k;
  char* b="fred";
  int c[4][3][2];
  substruct fred;
  substruct* bert;
  struct {
    int p;
    substruct q1;
    substruct q2;
  } t, *u;
  struct {
    int* p;
    subref* q;
  } w, *x;
  int l,m;
  for (i=0;i<20;i++) {
    for (j=0;j<20;j++) bigarray[i][j] = 20*i + j;
  }
  fred.r = 1;
  fred.s = 5.5;
  bert = (void*)malloc(8);
  w.p = (void*)malloc(4);
  w.q = (void*)malloc(4);
  bert->r = 7;
  bert->s = 8.5;
  *w.p = 8;
  t.p = 7;
  t.q1.r = 2;
  t.q1.s = 2.5;
  t.q2.r = 3;
  t.q2.s = 3.5;
  /*  *x->q->r = 1;
   *x->q->s = 1.5; */
  k = (void*)malloc(4*sizeof(int));
  printf("Enter number of iterations : ");
  scanf("%d",&n);
  printf("Enter number of iterations again : ");
  scanf("%d",&n);
  printf("And again : ");
  scanf("%d",&n);
  for (i=0;i<n;i++) {
    m = 4;
    a[i] = 2*i;
    myprint(i,a[i]);
  }
}

myprint.c...

myprint(int i,int j) {
  printf("a[%d] = %d\n",i,j);
}

Re: gdba probs

[Stefan Monnier]

> Regarding the bunches of errors, they occur because you're using commands
> that stop/step at the instruction level (break *_start, stepi, etc).
> Handling these commands is on my TODO list. ;-)

I have no idea what this entails, but maybe it is related to another
wish of mine: to make it usable when running "gdb --fullname foo".
Right now, it seems that if gdb is not started with "--annotate=2"
gdba just "freezes" (typing stuff at gdb prompt leads nowhere).

I understand that with "gdb --fullname foo" most things won't work, but I'd
like to slowly merge M-x gdb and M-x gdba, so I think that the gdba
code should be made to work even if the underlying gdb process is not
configured as expected: it should then behave more or less like M-x gdb does.

> > BTW, note all the spurious `Mark set' and `Replaced 0 occurrences'
> > messages (I never set the mark or did any replacing) -- it looks like
> > some lisp code is using the `replace-string' function when it shouldn't
> > (generally lisp code shouldn't use it at all).
> 
> I'm using replace-regexp which I know I shouldn't. The elisp manual does say
> this but doesn't offer an alternative. I have noticed in vc.el from emacs-20.7 :

C-h f replace-regexp ;-)


	Stefan

Re: gdba probs

[Nick Roberts]

Stefan Monnier writes:

 > > Regarding the bunches of errors, they occur because you're using commands
 > > that stop/step at the instruction level (break *_start, stepi, etc).
 > > Handling these commands is on my TODO list. ;-)
 > 
 > I have no idea what this entails, but maybe it is related to another
 > wish of mine: to make it usable when running "gdb --fullname foo".
 > Right now, it seems that if gdb is not started with "--annotate=2"
 > gdba just "freezes" (typing stuff at gdb prompt leads nowhere).

I don't think they're related. The bunches of errors occur because
gdb-info-breakpoints-custom only parses the output of "info breakpoints"
properly when they are at a statement boundary (have a line no. associated
with them) to place to breakpoint icons. There will be similar problems with
"info frames".

I don't know exactly what happens if gdba starts without "--annotate=2" but
the annotations are needed to tell it the status of the prgram. "--fullname"
just gives line information for display of the source. 

Looking at it, gdba doesn't freeze but to seems expect its input to come from
the input/output buffer (try, for example, typing break main in there)

 > I understand that with "gdb --fullname foo" most things won't work, but I'd
 > like to slowly merge M-x gdb and M-x gdba, so I think that the gdba
 > code should be made to work even if the underlying gdb process is not
 > configured as expected: it should then behave more or less like M-x gdb does.

You could infer how gdb was running from the lack/type of annotations (=1, =2)
but I don't think this would be easy. At the moment I run two gdb commands
requiring annotations *before* the executable is run to find out in what
file main is stored.

 > C-h f replace-regexp ;-)

I've also used insert-buffer. C-h f gives :

  This function is meant for the user to run interactively.
  Don't call it from programs!

What should I use this time ?

Nick

Re: gdba probs

[Miles Bader]

On Sat, Dec 07, 2002 at 02:38:37AM +0000, Nick Roberts wrote:
> I've also used insert-buffer. C-h f gives :
> 
>   This function is meant for the user to run interactively.
>   Don't call it from programs!
> 
> What should I use this time ?

I think `insert-buffer-substring' should work (if you omit the START/END
args, it will just insert the whole buffer).  Also note
`insert-buffer-substring-no-properties' if that's an issue.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: gdba probs

[Stefan Monnier]

> I've also used insert-buffer. C-h f gives :
> 
>   This function is meant for the user to run interactively.
>   Don't call it from programs!
> 
> What should I use this time ?

I guess insert-buffer-substring ?
I'll add it to the docstring.  Thanks for pointing it out.


	Stefan

Re: gdba probs

[Stefan Monnier]

> I don't know exactly what happens if gdba starts without "--annotate=2" but
> the annotations are needed to tell it the status of the prgram. "--fullname"
> just gives line information for display of the source.

I understand that.  But the `M-x gdb' subset of `M-x gdba' should still
work if you pass `-fullname'.  The rest of course won't, but that's OK:
you get what you asked for.

> Looking at it, gdba doesn't freeze but to seems expect its input to come from
> the input/output buffer (try, for example, typing break main in there)

Interesting.

>  > I understand that with "gdb --fullname foo" most things won't work, but I'd
>  > like to slowly merge M-x gdb and M-x gdba, so I think that the gdba
>  > code should be made to work even if the underlying gdb process is not
>  > configured as expected: it should then behave more or less like M-x gdb does.
> 
> You could infer how gdb was running from the lack/type of annotations (=1, =2)
> but I don't think this would be easy. At the moment I run two gdb commands
> requiring annotations *before* the executable is run to find out in what
> file main is stored.

And probably more in order to get the initial `info breakpoints'
and things like that.
That should just result in error messages or other unexpected output
in the *gdb* buffer, but without breaking the command-line prompt behavior.


	Stefan

Re: gdba probs

[Nick Roberts]

 > I feel like it must be possible to have a single filter deal with both cases.
 > The worst case would be to have a `gud-gdb-undecided-marker-filer' which
 > would call either one of the two filters or could even replace itself with
 > the appropriate filter once it has determined which case it's dealing with.

How about :

--- gud.el.~1.169.~	Wed Dec 11 18:41:06 2002
+++ gud.el	Wed Dec 11 22:16:45 2002
@@ -85,6 +85,8 @@
   (let ((sym (gud-symbol sym t minor-mode)))
     (if (boundp sym) (symbol-value sym))))
 
+(defvar gud-first-time)
+
 (defvar gud-running nil
   "Non-nil if debuggee is running.
 Used to grey out relevant toolbar icons.")
@@ -453,6 +455,7 @@
 and source-file directory for your debugger."
   (interactive (list (gud-query-cmdline 'gdb)))
 
+  (setq gud-first-time t)
   (gud-common-init command-line nil 'gud-gdb-marker-filter)
   (set (make-local-variable 'gud-minor-mode) 'gdb)
 
@@ -2344,6 +2347,42 @@
 
 (defun gud-filter (proc string)
   ;; Here's where the actual buffer insertion is done
+  (when (and gud-first-time (string-match 
+       "\n\032\032[a-z]" string))
+    (with-current-buffer gud-comint-buffer    
+      (setq gud-minor-mode 'gdba)
+      (setq gud-marker-filter 'gdba-marker-filter)
+      (setq comint-input-sender 'gdb-send))
+    (gud-def gud-break (if (not (string-equal mode-name "Assembler"))
+			   (gud-call "break %f:%l" arg)
+			 (save-excursion
+			   (beginning-of-line)
+			   (forward-char 2)
+			   (gud-call "break *%a" arg)))
+	     "\C-b" "Set breakpoint at current line or address.")
+
+    (gud-def gud-remove (if (not (string-equal mode-name "Assembler"))
+			    (gud-call "clear %f:%l" arg)
+			  (save-excursion
+			    (beginning-of-line)
+			    (forward-char 2)
+			    (gud-call "clear *%a" arg)))
+	     "\C-d" "Remove breakpoint at current line or address.")
+
+    ;; (re-)initialise
+    (setq gdb-main-or-pc "main")
+    (setq gdb-current-address nil)
+    (setq gdb-display-in-progress nil)
+    (setq gdb-dive nil)
+
+    (gdb-make-instance)
+    (gdb-clear-inferior-io)
+
+    ;; find source file and compilation directory here
+    (gdb-instance-enqueue-idle-input (list "server list\n" 'ignore))
+    (gdb-instance-enqueue-idle-input (list "server info source\n"
+					   'gdb-source-info))
+    (setq gud-first-time nil))
   (let (output process-window)
     (if (buffer-name (process-buffer proc))
 	(if gud-filter-defer-flag

Re: gdba probs

[Stefan Monnier]

> 
>  > I feel like it must be possible to have a single filter deal with both cases.
>  > The worst case would be to have a `gud-gdb-undecided-marker-filer' which
>  > would call either one of the two filters or could even replace itself with
>  > the appropriate filter once it has determined which case it's dealing with.
> 
> How about :
> 
> --- gud.el.~1.169.~	Wed Dec 11 18:41:06 2002
> +++ gud.el	Wed Dec 11 22:16:45 2002
> @@ -85,6 +85,8 @@
>    (let ((sym (gud-symbol sym t minor-mode)))
>      (if (boundp sym) (symbol-value sym))))
>  
> +(defvar gud-first-time)

This construction is probably better left for the dynamic-binding
and the defined-elsewhere cases.  Just use

  (defvar gud-first-time nil)

instead.

>  (defvar gud-running nil
>    "Non-nil if debuggee is running.
>  Used to grey out relevant toolbar icons.")
> @@ -453,6 +455,7 @@
>  and source-file directory for your debugger."
>    (interactive (list (gud-query-cmdline 'gdb)))
>  
> +  (setq gud-first-time t)
>    (gud-common-init command-line nil 'gud-gdb-marker-filter)
>    (set (make-local-variable 'gud-minor-mode) 'gdb)

I don't see why we need to change something to the generic part of GUD.

> @@ -2344,6 +2347,42 @@
>  
>  (defun gud-filter (proc string)
>    ;; Here's where the actual buffer insertion is done
> +  (when (and gud-first-time (string-match
> +       "\n\032\032[a-z]" string))

What if DBX outputs this same sequence?  Clearly, we want this
hack to be GDB-specific and should thus put it in GDB's filter.


	Stefan

Re: gdba probs

[Nick Roberts]

 > I don't see why we need to change something to the generic part of GUD.

Currently gdb-ui.el requires gud.el. If M-x gdb can be used with "-annotate=2"
then gud.el will require gdb-ui.el. This means they might as well be one
(large) file doesnt it ?

 > > @@ -2344,6 +2347,42 @@
 > >  
 > >  (defun gud-filter (proc string)
 > >    ;; Here's where the actual buffer insertion is done
 > > +  (when (and gud-first-time (string-match
 > > +       "\n\032\032[a-z]" string))
 > 
 > What if DBX outputs this same sequence?

You take the patch too literally. It should have something like:

(string-match "\n\032\032pre-prompt\|\n\032\032breakpoints-invalid" string)

but I haven't worked out exactly what as gud-filter seems to process the last
chunk first. The first annotaion might even be "\032\032error-begin" if gdb
tries to debug a file that doesn't exist. Of course in the unlikely event of
DBX ouputting this sequence it would choke but then it would probably have
come from the program being debugged in which GDB would choke too.

 > Clearly, we want this hack to be GDB-specific and should thus put it in
 > GDB's filter.
 
It could go there but you will still end up with only one file. So it might be
better to keep M-x gdba. If, one day, it works properly, then M-x gdb could go.

Nick

Re: gdba probs

[Stefan Monnier]

>  > I don't see why we need to change something to the generic part of GUD.
> Currently gdb-ui.el requires gud.el. If M-x gdb can be used with "-annotate=2"
> then gud.el will require gdb-ui.el. This means they might as well be one
> (large) file doesnt it ?

Note I said "the generic part of GUD" I didn't say "gud.el".
`gud-foo' is part of the generic code, while `gud-gdb-foo' is not.

>  > > @@ -2344,6 +2347,42 @@
>  > >  
>  > >  (defun gud-filter (proc string)
>  > >    ;; Here's where the actual buffer insertion is done
>  > > +  (when (and gud-first-time (string-match
>  > > +       "\n\032\032[a-z]" string))
>  > 
>  > What if DBX outputs this same sequence?
> 
> You take the patch too literally. It should have something like:
> 
> (string-match "\n\032\032pre-prompt\|\n\032\032breakpoints-invalid" string)

And?  Same thing: some other debugger might use the exact same sequence.
Better put the test in gud-gdb-marker-filter so there's not ambiguity
and so the generic part of the code stays cleaner.

> > Clearly, we want this hack to be GDB-specific and should thus put it in
> > GDB's filter.
> 
> It could go there but you will still end up with only one file.
> So it might be better to keep M-x gdba. If, one day, it works properly,
> then M-x gdb could go.

I think those problems are mostly orthogonal.  We may want to move
all of gdb-ui.el into gud.el or instead to move all the gud-gdb-foo
stuff out of gud.el into gdb-ui.el.  But there's no hurry.
After all, a few days ago, gud-gdb-complete-filter used to call
gdba-complete-filter (or something like that) and that didn't force you to
merge things into a single file.
The ultimate goal is to merge M-x gdb and M-x gdba, but it doesn't
have to be done in a single step.  I think the first step is to make
sure that both work (maybe with quirks) regardless of whether
--annotate=2 was used or not.

Miles said:
> [Yeah I know gud.el is a big ball of hair already, but there's no sense
> in making it worse]

Which part are you thinking of ?  It's really not that bad.
It has annoying limitations due to excessive use of global state
(you can't have both a GDB and a PerlDB running at the same time),
but the code itself is pretty clean and simple if you ask me (at
least the generic part of the code is very slim AFAIK).


	Stefan

Re: gdba probs

[Miles Bader]

On Thu, Dec 12, 2002 at 08:49:54AM -0500, Stefan Monnier wrote:
> > [Yeah I know gud.el is a big ball of hair already, but there's no sense
> > in making it worse]
> 
> Which part are you thinking of ?  It's really not that bad.  It has
> annoying limitations due to excessive use of global state (you can't have
> both a GDB and a PerlDB running at the same time), but the code itself is
> pretty clean and simple if you ask me (at least the generic part of the
> code is very slim AFAIK).

Well, OK, I haven't really looked at the whole thing very closely, so perhaps
what I said above is unjustified.  However, when I've had to fix a bug or
something in that code, I always come away feeling a bit dirty, and thinking
`boy somebody needs to clean this up.'

-Miles
-- 
We live, as we dream -- alone....

Re: gdba probs

[Richard Stallman]

    Currently gdb-ui.el requires gud.el. If M-x gdb can be used with "-annotate=2"
    then gud.el will require gdb-ui.el.

I don't think that follows.  That would be just one way to implement
things, but as you point out, it would be an undesirable way.  So
implement it another way.

Re: gdba probs

[Miles Bader]

Nick Roberts <nick@nick.uklinux.net> writes:
>  (defun gud-filter (proc string)
>    ;; Here's where the actual buffer insertion is done
> +  (when (and gud-first-time (string-match 
> +       "\n\032\032[a-z]" string))
.....
> +    (setq gud-first-time nil))
>    (let (output process-window)

Please put all the junk inside the `when' (which I replaced by .....)
into a separate function to avoid cluttering up gud-filter, something
like `gdba-take-over-process' or something.  It could even be an
autoloaded function in gdb-ui.el.

The segment of code marked `(re-)initialize' should probably also be put
into a separate function (in gud.el), since set of commands needed may
change in the future, and this keeps things a bit organized.  If gud
also calls this function, then it's even more clear.

[Yeah I know gud.el is a big ball of hair already, but there's no sense
in making it worse]

Thanks,

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: gdba probs

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Nick Roberts <nick@nick.uklinux.net> writes:
> >  (defun gud-filter (proc string)
> >    ;; Here's where the actual buffer insertion is done
> > +  (when (and gud-first-time (string-match 
> > +       "\n\032\032[a-z]" string))
> .....
> > +    (setq gud-first-time nil))
> >    (let (output process-window)
> 
> Please put all the junk inside the `when' (which I replaced by .....)
> into a separate function to avoid cluttering up gud-filter, something
> like `gdba-take-over-process' or something.  It could even be an
> autoloaded function in gdb-ui.el.

Alternatively, there could be a `gud-filter-hook' which gdb-ui.el
could hook into when loaded.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdba probs

[Nick Roberts]

Stefan Monnier writes:

 > I have no idea what this entails, but maybe it is related to another
 > wish of mine: to make it usable when running "gdb --fullname foo".
 > Right now, it seems that if gdb is not started with "--annotate=2"
 > gdba just "freezes" (typing stuff at gdb prompt leads nowhere).

I've looked at it now. 

It "freezes" because when a gdb command is typed in the GUD buffer goes onto
the queue (C-h v gdb-input-queue). It goes on the input queue because
gdb-instance-prompting is nil therefore thinks its not ready for
input. gdb-instance-prompting is nil because it hasn't received the prompt
annotation. It hasn't received the prompt annotation because its been called
with "--fullname".

> > > > @@ -2344,6 +2347,42 @@
> > > >  
> > > >  (defun gud-filter (proc string)
> > > >    ;; Here's where the actual buffer insertion is done
> > > > +  (when (and gud-first-time (string-match
> > > > +       "\n\032\032[a-z]" string))
> > > 
> > > What if DBX outputs this same sequence?
> > 
> > You take the patch too literally. It should have something like:
> > 
> > (string-match "\n\032\032pre-prompt\|\n\032\032breakpoints-invalid" string)

> And?  Same thing: some other debugger might use the exact same sequence.
> Better put the test in gud-gdb-marker-filter so there's not ambiguity
> and so the generic part of the code stays cleaner.

I see now that "^Z^Z" is some kind of universal marker, I had thought it was
GDB specific.

> Better put the test in gud-gdb-marker-filter so there's not ambiguity
> and so the generic part of the code stays cleaner.
> ...

It might be easier to approach it from the other end i.e add an annotation
rule for gdb-output-burst to accommodate "--fullname".

> The ultimate goal is to merge M-x gdb and M-x gdba, but it doesn't
> have to be done in a single step.  I think the first step is to make
> sure that both work (maybe with quirks) regardless of whether
> --annotate=2 was used or not.

I think I understand now. I'll go away and think about it.

Miles Bader writes :

> into a separate function to avoid cluttering up gud-filter, something
> like `gdba-take-over-process' or something.  It could even be an
> autoloaded function in gdb-ui.el.
  ^^^^^^^^^^

So gdb-ui.el wouldn't get loaded unless gdb was invoked with annotations, right?
Thats a good point, I hadn't thought of that. 

Nick

Re: gdba probs

[Richard Stallman]

    The totalview debugger starts with 6 windows. But, hey!, lets be open minded
    about this. How do you know you don't want them before you know what they do ?

Is there a way to make it more self-evident what these windows do?
What measures are taken in the code as it is now
to show the user what these windows do and how to use them?

    I'm using replace-regexp which I know I shouldn't. The elisp manual does say
    this but doesn't offer an alternative.

If you know enough Lisp to write what you have written,
you shouldn't have any trouble writing the Lisp code
for that little job.

Re: gdba probs

[Nick Roberts]

Richard Stallman writes:

 > > The totalview debugger starts with 6 windows. But, hey!, lets be open
 > >  minded about this. How do you know you don't want them before you know
 > >  what they do ?

 > Is there a way to make it more self-evident what these windows do?
 > What measures are taken in the code as it is now
 > to show the user what these windows do and how to use them?

At the moment there's only what you get from `C-h f gdba' (reproduced below).
As far as layout goes, I share some of Miles' reservations. There are a
further 3 buffers (assembler, registers, display) that the user might want to
display and each user will have his/her own preferences. I have looked at trying
to save a window configuration and I note that this concept has been on the
TODO list of desktop.el for a long time. I can imagine this is not an easy
thing to do.

As for what each buffer does I could start to document it in info format but
its still evolving and I don't know if there is sufficient interest yet. Apart
from the errors, I like to think much of the functionality is self evident. What
do others think ?

Nick

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

gdba is an interactive compiled Lisp function in `gdb-ui'.
(gdba COMMAND-LINE)

Run gdb on program FILE in buffer *gdb-FILE*.
The directory containing FILE becomes the initial working directory
and source-file directory for your debugger.

If `gdb-many-windows' is set to t this works best in X (depending on the size
of your monitor) using most of the screen. After a short delay the following
layout will appear (keybindings given in relevant buffer) :

---------------------------------------------------------------------
                               GDB Toolbar
---------------------------------------------------------------------
GUD buffer (I/O of gdb)           | Locals buffer
                                  |
                                  |
                                  |
---------------------------------------------------------------------
Source buffer                     | Input/Output (of debuggee) buffer
                                  | (comint-mode)
                                  |
                                  |
                                  |
                                  |
                                  |
                                  |
---------------------------------------------------------------------
Stack buffer                      | Breakpoints buffer
[mouse-2] gdb-frames-mouse-select | SPC    gdb-toggle-bp-this-line
                                  |   g    gdb-goto-bp-this-line
                                  |   d    gdb-delete-bp-this-line
---------------------------------------------------------------------

All the buffers share the toolbar and source should always display in the same
window e.g after typing g on a breakpoint in the breakpoints buffer. Breakpoint
icons are displayed both by setting a break with gud-break and by typing break
in the GUD buffer.

Displayed expressions appear in separate frames. Arrays may be displayed
as slices and visualised using the graph program from plotutils if installed.

If `gdb-many-windows' is set to nil then gdb starts with just two windows :
the GUD and the source buffer.

The following interactive lisp functions help control operation :

`gdb-many-windows'  - Toggle the number of windows gdb uses.
`gdb-restore-windows' - to restore the layout if its lost.
`gdb-quit'            - to delete (most) of the buffers used by gdb.

Re: gdba probs

[Richard Stallman]

     Apart
    from the errors, I like to think much of the functionality is self evident.

Maybe so, but the person who said he didn't know what these windows
were for apparently did not find it so.  How about if you talk with him
about why it wasn't evident to him?

    At the moment there's only what you get from `C-h f gdba' (reproduced below).

Can you think of ways to make the text in the windows themselves show
what they do and how to use them?  Please put some effort into this.  A
major part of the idea of graphical interfaces is that they can, with
some effort, be self-explanatory.  But just putting text in a window
doesn't automatically achieve that; you have to design your interface
for it.

One idea is that a window, when "empty" or nearly so, could show a
command list for that window.  However, it could also contain buttons
which provide a graphical way to give the window commands.  Then a
user would not need to learn and remember special commands for each
window.  This would be an easier-to-use interface.

    There are a
    further 3 buffers (assembler, registers, display) that the user might want to
    display and each user will have his/her own preferences. I have looked at trying
    to save a window configuration and I note that this concept has been on the
    TODO list of desktop.el for a long time. I can imagine this is not an easy
    thing to do.

This is less important.  As long as there is a way people can specify
the layout they want, that is good enough for starters.  Please focus on
making the interface natural and self-explanatory.

    As for what each buffer does I could start to document it in info format but
    its still evolving and I don't know if there is sufficient interest yet.

Please do document it (in Texinfo format).

Miles suggested this:

    The GUI debuggers I've used typically start out displaying only one or two
    windows (e.g., the command window and a source window, sort of like normal
    gud mode), but offer toolbar buttons to easily pop up others; once the others
    are popped up, they are updated continuously.  Note that for some window
    types, you can pop up more than one instance -- e.g. memory display windows,
    where you may want to display several regions of memory simultaneously.

I think this is a good idea.  If users want to change configurations
as they go, then saving a configuration permanently is NOT very
useful.

Re: gdba probs

[Nick Roberts]

Richard Stallman (RMS), Stefan Monnier(SM), Miles Bader(MB) write:

RMS>     Apart from the errors, I like to think much of the functionality is self
RMS>     evident.
RMS> 
RMS> Maybe so, but the person who said he didn't know what these windows
RMS> were for apparently did not find it so.  How about if you talk with him
RMS> about why it wasn't evident to him?

If you mean Miles, I think he was only confused by the display window that
popped up in its own frame when it wouldn't have done if there were no errors.

SM> Their meaning is indeed obvious when they're not empty.
SM> When they're empty, the buffer name gives a good hint, but I'm not
SM> sure it's enough to make it "obvious".

They're never completely empty. Even `No breakpoints or watchpoints.' or
`No stack.' are clues. I would say that they were `self-evident to anyone
familiar with GUI debuggers'. Since that doesn't include everyone, I will
document it.

RMS> Please do document it (in Texinfo format).

How does this work ? Do I put my changes in building.texi ? Do I install the
patch or submit it to the mailing list/you. Can it have references to gdb info
pages or only ones in the emacs distribution ? Texinfo files don't seem to be
updated very frequently. Do I install something rough and ready now and
develop it or wait until I feel its stable?

MB> The GUI debuggers I've used typically start out displaying only one or two
MB> windows (e.g., the command window and a source window, sort of like normal
MB> gud mode), but offer toolbar buttons to easily pop up others; once the others
MB> are popped up, they are updated continuously.  Note that for some window
MB> types, you can pop up more than one instance -- e.g. memory display windows,
MB> where you may want to display several regions of memory simultaneously.

OK, I'll change the default value of gdb-many-windows to nil. This means gdba
will start with just two windows : the GUD buffer and the source.  The user
will then have to express a preference for six. Note, however, that other
buffers, such as the breakpoints buffer, are still needed (in this case for
placing the breakpoint icons), even though they are not visible. The
input/output buffer will automatically appear when the program is run but I'll
try to stop that.

RMS> Can you think of ways to make the text in the windows themselves show
RMS> what they do and how to use them?  Please put some effort into this.  A
RMS> major part of the idea of graphical interfaces is that they can, with
RMS> some effort, be self-explanatory.

I will try to bear in mind these things and the other comments made on this
mailing list as the mode develops.

Nick

Re: gdba probs

[Kim F. Storm]

Nick Roberts <nick@nick.uklinux.net> writes:

> 
> OK, I'll change the default value of gdb-many-windows to nil.

Maybe you could make a key binding to toggle it (and update the display
accordingly).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: gdba probs

[Richard Stallman]

    RMS> Please do document it (in Texinfo format).

    How does this work ? Do I put my changes in building.texi ?

If it is short, yes.  Otherwise write a separate file.

     Do I install the
    patch or submit it to the mailing list/you. Can it have references to gdb info
    pages or only ones in the emacs distribution ?

Referring to the GDB manual is very useful.
The Texinfo manual says how to do that.

Re: gdba probs

[Miles Bader]

On Sat, Dec 07, 2002 at 04:25:57PM -0500, Richard Stallman wrote:
>     The totalview debugger starts with 6 windows. But, hey!, lets be open
>     minded about this. How do you know you don't want them before you know
>     what they do ?
> 
> Is there a way to make it more self-evident what these windows do?
> What measures are taken in the code as it is now
> to show the user what these windows do and how to use them?

The meaning of the windows should be pretty obvious to most people who have
some debugger experience I think; at least they were to me.  I presumed when
Nick said that, he meant it as a joke.

THe bigger problem is that they simply aren't very useful unless they have
some contents; until then they're just a waste of space -- and in many cases
they're a wast of space even if they _do_ have some contents, because the
contents are not something you want to see continuously (for instance the
breakpoints window).  The set of windows you want is highly dependent on what
you're debugging.

The GUI debuggers I've used typically start out displaying only one or two
windows (e.g., the command window and a source window, sort of like normal
gud mode), but offer toolbar buttons to easily pop up others; once the others
are popped up, they are updated continuously.  Note that for some window
types, you can pop up more than one instance -- e.g. memory display windows,
where you may want to display several regions of memory simultaneously.

Since screen-space is a fairly precious commodity for me this is a very good
method of operation (and I suspect the same is true of many users -- not
everyone uses a 1600x1280 display with an 8 point font!).

I gather that gdba is modelled after GUI debuggers that initially pop up many
very small windows; I've seen these, but don't like them, largely for the
reasons stated above (the other reason is that such debuggers usually seem to
use an `every window has a different obnoxious neon background color' look; I
guess they do this so you can sort out all those windows easily, but man it's
ugly!).

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: gdba probs

[Stefan Monnier]

> On Sat, Dec 07, 2002 at 04:25:57PM -0500, Richard Stallman wrote:
> >     The totalview debugger starts with 6 windows. But, hey!, lets be open
> >     minded about this. How do you know you don't want them before you know
> >     what they do ?
> > 
> > Is there a way to make it more self-evident what these windows do?
> > What measures are taken in the code as it is now
> > to show the user what these windows do and how to use them?
> 
> The meaning of the windows should be pretty obvious to most people who have
> some debugger experience I think; at least they were to me.  I presumed when
> Nick said that, he meant it as a joke.

Their meaning is indeed obvious when they're not empty.
When they're empty, the buffer name gives a good hint, but I'm not
sure it's enough to make it "obvious".

> The bigger problem is that they simply aren't very useful unless they have
> some contents; until then they're just a waste of space -- and in many cases

Agreed.  Only displaying them when there's something to display would
also solve the above "problem".


	Stefan

Re: gdba probs

[Richard Stallman]

    Their meaning is indeed obvious when they're not empty.
    When they're empty, the buffer name gives a good hint, but I'm not
    sure it's enough to make it "obvious".

When they are empty of real contents, they should instead display some
text that explains what the window is for and how to use it.

    Agreed.  Only displaying them when there's something to display would
    also solve the above "problem".

Many users will like that feature, but I think it would be good to
implement the help text also.

gdba probs

[Miles Bader]

Seeing the recent activity on `gdba', I decided to check it out, and got
bunches of errors.  The gdb command line I used was this:

   kgdb -annotate=2 $lkb/as85ep1-rom/linux

[kgdb is just a symbolic link to `v850e-elf-gdb']

It initially divided the frame into 6 (!) windows, most of which I
don't want; is there a way to customize which windows it uses?

I think ideally, certain windows would only show up if they had
contents.  Note that most GUI debuggers I've used only display the
source-code window and command windows by default; you have to
explicitly pop up windows to show registers/breakpoints/stack/etc
(though once they're popped up, the debugger keeps them updated).

Here's the *gdb-linux* buffer's contents:

   Current directory is /proj/soft2/uclinux/uclinux/build/as85ep1-rom/
   GNU gdb 4.18-v850ice-000414-nmit-20010327
   Copyright 1998 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and you are
   welcome to change it and/or distribute copies of it under certain conditions.
   Type "show copying" to see the conditions.  This version of GDB is supported
   for customers of Cygnus Solutions.  Type "show warranty" for details.
   This GDB was configured as "--host=i386-pc-linux-gnu --target=v850e-elf"...
   warning: Target may not support unknown architecture

   Connected to the simulator.
   Breakpoint 1 at 0x80
   Breakpoint 2 at 0x4b0
   Loading section .intv, size 0x480 vma 0x0
   Loading section .text, size 0x45be0 vma 0x480
   Loading section .init_text, size 0x3b7c vma 0x47000
   Loading section .root, size 0x7a800 vma 0x4b000
   Loading section .data, size 0x6000 vma 0x400000
   Loading section .init_data, size 0x3b8 vma 0x406000
   Start address 0x480
   Transfer rate: 6634656 bits in <1 sec.
   (gdb) break *_start
   Breakpoint 3 at 0x480
   (gdb) run
   Starting program: /proj/soft2/uclinux/uclinux/build/as85ep1-rom/linux 
     C-c C-cQuit
   (gdb) (gdb) (gdb) fr
   #0  0x480 in _start ()
   (gdb) fr
   #0  0x480 in _start ()
   (gdb) si

It seemed to hang despite the fist break point, which is why I hit `C-c C-c'.

At that point, it also popped up _another_ window in its own frame,
called `*display 1*'; I have no idea what the purpose of this is...

I got various lisp errors too; here's the contents of my *Messages*
buffer:

   Loading gdb-ui (source)...done
   Loading cc-mode...done
   Loading vc-cvs...done
   Followed link to /proj/soft2/uclinux/uclinux/uClinux-2.4.x/init/main.c
   Mark set
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set [3 times]
   error in process filter: progn: Search failed: "in\\s-+\\S-+\\s-+at\\s-+"
   error in process filter: Search failed: "in\\s-+\\S-+\\s-+at\\s-+"
   Mark set [2 times]
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set [3 times]
   error in process filter: progn: Search failed: "in\\s-+\\S-+\\s-+at\\s-+"
   error in process filter: Search failed: "in\\s-+\\S-+\\s-+at\\s-+"
   error in process filter: not: Wrong type argument: stringp, nil
   error in process filter: Wrong type argument: stringp, nil
   error in process filter: cond: Phase error in gdb-prompt (got emacs)
   error in process filter: Phase error in gdb-prompt (got emacs)
   Mark set
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set [4 times]
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set [3 times]
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set
   Replaced 0 occurrences
   Mark set [2 times]
   error in process filter: not: Wrong type argument: stringp, nil
   error in process filter: Wrong type argument: stringp, nil
   error in process filter: cond: Phase error in gdb-prompt (got emacs)
   error in process filter: Phase error in gdb-prompt (got emacs)

BTW, note all the spurious `Mark set' and `Replaced 0 occurrences'
messages (I never set the mark or did any replacing) -- it looks like
some lisp code is using the `replace-string' function when it shouldn't
(generally lisp code shouldn't use it at all).

Hmmm, is there anything I can do to provide more useful bug reports?

Thanks,

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)