The new "pp" command in gud is no longer so dangerous...

The new "pp" command in gud is no longer so dangerous...

[Kim F. Storm]

I have installed changes to make a new safe_debug_print function which
does not crash the inferior emacs process if you pass something which
is not a valid Lisp Object (that's pretty easy if you click on the
pp toolbar button with the cursor placed on something which is not
a Lisp_Object variable.

There is now a new function valid_lisp_object_p that checks this.
Unfortunately, I only know how to make it work if GC_MARK_STACK != 0.
So it simply returns "undeterminable" if GC_MARK_STACK == 0, and
consequently safe_debug_print refuses to print any values.
If anybody has ideas how to improve this, pls. tell me (or fix it).

Also, I have added new commands to print the value of lisp variables,
e.g.
        pv debug-on-error

There is also a command pv1 which could be used as the command
to execute when user presses the "pp" toolbar button over a symbol
in a *.el file.  Someone wants to work on that?

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

The new "pp" command in gud is no longer so dangerous...

[Nick Roberts]

...but living on the edge is half the fun!

 > Also, I have added new commands to print the value of lisp variables,
 > e.g.
 >         pv debug-on-error
 > 
 > There is also a command pv1 which could be used as the command
 > to execute when user presses the "pp" toolbar button over a symbol
 > in a *.el file.  Someone wants to work on that?

How would that work?  The variable tool-bar-map is set locally in
gud-minor-mode so, as soon as you place the cursor in a buffer where
gud-minor-mode is nil e.g on an expression in a lisp file, the tool bar
reverts to the global one.

I could define it using gud-def so that it has a global binding e.g.

  (gud-def gud-pv "pv1 %e" "\C-v" "Print the value of the lisp variable.")

so that it's on C-x C-a C-v.  Is that any good?

Nick

Re: The new "pp" command in gud is no longer so dangerous...

[Richard M. Stallman]

    There is now a new function valid_lisp_object_p that checks this.
    Unfortunately, I only know how to make it work if GC_MARK_STACK != 0.
    So it simply returns "undeterminable" if GC_MARK_STACK == 0, and
    consequently safe_debug_print refuses to print any values.
    If anybody has ideas how to improve this, pls. tell me (or fix it).

It would be better to handle that case by treating all values
as ok, rather than treating all values as bad.
At least that would work as well as the old code.

Re: The new "pp" command in gud is no longer so dangerous...

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

>     There is now a new function valid_lisp_object_p that checks this.
>     Unfortunately, I only know how to make it work if GC_MARK_STACK != 0.
>     So it simply returns "undeterminable" if GC_MARK_STACK == 0, and
>     consequently safe_debug_print refuses to print any values.
>     If anybody has ideas how to improve this, pls. tell me (or fix it).
>
> It would be better to handle that case by treating all values
> as ok, rather than treating all values as bad.
> At least that would work as well as the old code.

Well, there is no "old code" in this case.

Nick just added the [pp] button to the tool-bar, and the first time
I tried it, the cursor as (accidentally) on a non-Lisp object, and I
crashed the inferior emacs without any warning.

I changed "pp" to call safe_debug_print as my experience shows that it
is also too easy to call it with non-Lisp objects.  

However, you can still use the good-ole "pr" command, as it calls the
old debug_print which will print whatever you pass it (or die trying).

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

Re: The new "pp" command in gud is no longer so dangerous...

[Kim F. Storm]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > There is also a command pv1 which could be used as the command
>  > to execute when user presses the "pp" toolbar button over a symbol
>  > in a *.el file.  Someone wants to work on that?
>
> How would that work?

You are right, it can't.

> I could define it using gud-def so that it has a global binding e.g.
>   (gud-def gud-pv "pv1 %e" "\C-v" "Print the value of the lisp variable.")
> so that it's on C-x C-a C-v.  Is that any good?

Looks good to me!  Let's try it!

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

Re: The new "pp" command in gud is no longer so dangerous...

[Richard M. Stallman]

    > It would be better to handle that case by treating all values
    > as ok, rather than treating all values as bad.
    > At least that would work as well as the old code.

    Well, there is no "old code" in this case.

It is useless to have the button and make it do nothing.
Meanwhile, just testing for a valid data type ought to enable
it to avoid most crashes.  So wouldn't it be better, in the
case where you can't test the pointer's validity, to assume
"yes" instead of assume "no"?