Using the *#@*&* Vlisp Editor

[Jack Gill]

I've been writing lisp programs for years, and when debugging I have always loaded the program into AutoCad and then simply tried the new command or function that I've written. With R2000, AutoCad stopped returning important information when it hit a program snag and just returned a cryptic "bad argument type: stringp nil" or something like that (it used to show you where it was screwing up).

I keep thinking I should do all my debugging using all those special debug tools in the Vlisp Editor, but I just don't seem to get it. Could any of y'all tell me what tools you use for simple debugging-- I'd be happy if I could just keep track of what program variables are being set to as the program is stepped through.

Thanks.

 

[PF]

"bad argument type: stringp nil" or something like that ...

is not so cryptic!
stringp indicates a required string contains an error
(stringp = "string predicate")

Perhaps we should collect these "less-than-adequate" messages and explain them better.

 

[Tom Smith]

That would be helpful.

I agree that the error messages are much less clear in Vlisp than before. R14 would at least echo back the offending statement. Now you just get the cryptic part, without a ponter to the flaw. If you use View>Error Trace in the editor, you get almost the same information as in R14, but everything about the Vlisp editor seems cumbersome to me. If Vlisp is going to echo anything at all to the Acad command line, it ought to be more useful info, as it used to be. I don't have any trouble figuring out "stringp nil" but I'd like to know WHICH string it thinks is nil.

 

[Doug Broad]

This hint came from Peter Tobey and perhaps someone else earlier as a way to get the old eror messages back.

(vl-bt) is the important function, standing for back trace.

(defun *error* (msg) (princ msg) (vl-bt) (princ))

 

[R. Robert Bell]

That, and set the VLIDE to Break On Error. When the source is loaded via the VLIDE and a break occurs, you can hit Last Break Source and get right to the offending statement.

--
R. Robert Bell, MCSE
www.AcadX.com

| This hint came from Peter Tobey and perhaps someone else | earlier as a way to get the old eror messages back. | | (vl-bt) is the important function, standing for back trace. | | (defun *error* (msg) (princ msg) (vl-bt) (princ)) | | | | | | > That would be helpful. | > | > I agree that the error messages are much less clear in Vlisp than before. | > R14 would at least echo back the offending statement. Now you just get the | > cryptic part, without a ponter to the flaw. If you use View>Error Trace in | > the editor, you get almost the same information as in R14, but everything | > about the Vlisp editor seems cumbersome to me. If Vlisp is going to echo | > anything at all to the Acad command line, it ought to be more useful info, | > as it used to be. I don't have any trouble figuring out "stringp nil" but | > I'd like to know WHICH string it thinks is nil. | > | |

 

[Doug Broad]

Which is even better than R14!

 

[R. Robert Bell]

Exactly! ;-)

--
R. Robert Bell, MCSE
www.AcadX.com

| Which is even better than R14!
|
| | > That, and set the VLIDE to Break On Error. When the source is loaded via the | > VLIDE and a break occurs, you can hit Last Break Source and get right to the | > offending statement. | > | > -- | > R. Robert Bell, MCSE | > www.AcadX.com | > | |

 

[Tom Smith]

Thanks guys!

 

[Jack Gill]

Thanks everyone, this helps.

(but I still think the editor is more awkward than it ought to be!)