LISP: Problem with insert and pause...

Roy Klein Gebbinck

Hello,

This may be the pause problem as referred to by Dan Wiseman in this forum post:
http://www.bricsys.nl/common/support/forumthread.jsp?id=12268

If I use this function:

(defun c:er ()
  (command "_.-insert" "testBlock" "_scale" 1 pause 0)
  (princ)
)

and cancel before supplying an insertion point, this message appears:

Cancel

; ----- LISP Error : Call Stack -----
; [0]...C:ER <<--
;
; ----- Error around expression -----
(COMMAND PAUSE)
;
; error : Lisp execution failure < <PAUSE input after command finished>> at [COMMAND]

 

So basically the error-function kicks in, but only after a lisp error report has been displayed. Is there a way to supress this report? Using (getpoint) instead of pause is not a good alternative because then you cannot see the insert as you are determining the insertion point.

Thanks in advance, Roy.

 

 

 

Torsten Moses

Dear Roy,
indeed, this is not the normal + correct behaviour ... I have just checked what happens here :
as I found, the INSERT command returns a wrong status to Lisp after (command PAUSE) is executed.

It returns ERROR, instead of CANCELLED, thus the Lisp engine also reports + behaves other than expected.
I just added a workaround, so any "erroneous" input to PAUSE (like ESCAPE) is treated as cancellation.

Then, your code works as expected ... I hope to get this fix included in next Bricscad Beta version.

Many greetings, and many thanks, Torsten

Roy Klein Gebbinck

Thank you!

philippe Sérange

Hello,

This also happens in other cases... for example :

1)

(setq pnt1 nil)
(getpoint pnt1 "Pick a point") -> 

----- Error around expression -----
(getpoint nil "Pick a point")

 

2)

(setq pc1 nil pc2 nil)
(ssget "_F" (list pc1 pc2) (list (cons 0 "3DFACE")))  ->

; ----- Error around expression -----
(CONS 0 "3DFACE")
;

I run version 10.3.11

Torsten, can you confirm the problem ?

 

Philippe

 

Roy Klein Gebbinck

Your problem doesn't seem related to pause. I think that both your code snippets fail because you use nil instead of valid points. What is your intention?

Philippe Serange

Hello,

 

This is intentional...

What I mean is that the error is not trapped correctly.

Philippe

Roy Klein Gebbinck

Right (and of course...)! So what we need is something like (setvar "do-not-show-extended-lisp-error-reports" 1). Because if you are debugging you do want to see this information.

Philippe Serange

I'd prefer the same behaviour than Autocad instead of another variable (if it is possible...).

I generally define my error function like this :

(defun myerror(msg)
 (vl-bt)   --> for debugging
)

then once debugged :

(defun myerror(msg)
  (princ)  --> no echo
)

Philippe

Torsten Moses

Hello, Philipp & Roy ...

that report
----- Error around expression -----
(getpoint nil "Pick a point")

most often is not exactly the point of the error condition -
it is the last successful operation executed - to give a hint where
the error is.

But your idea is good :
in case, any other error handler than the built-in *error* is the active
one (like 'MyError'), then the default "error call back-track" could be
suppressed ...

The only point is, how to show that error location, even to developer ?
As part of the error message itself ?

Philippe Serange

Hello Torsten,

I don't understand what you mean by:

" The only point is, how to show that error location, even to developer ?
As part of the error message itself ?"

Can't we simply mimic Acad behaviour ? Just asking, hey... Bricscad is getting better and better, keep on the good job.

Philippe

 

Roy Klein Gebbinck

@ Torsten:

Maybe this could work:
If (vl-bt) is present inside the error-handler:
Incorporate "error call back-track" in error message,
Else:
Use AC-compatible error message.

But in any case, incorporating the "error call back-track" in the error message seems a logical approach. As long as  this message starts with a fixed string, a developer can always decide to either display or hide it.

Torsten Moses

@Philippe - what I meant is : the error handler gets a string as argument ...
my idea is, to add the extra (extended) error message regarding the error location
to the same string, but with \n between - thus it is still 1 error message, that splits
across multiple lines ...
and developers might check if there is a \n and if so, limit text up \n, if desired.

@Roy - I guess, you also assumed this ? :-)

Probably a beter approach here :
instead of using a system variable which is not present in Acad, we can also have
a "magic" variable, like
*extended*error*

By default, it would be set to t - so extended error log (like current) is active -
otherwise, if developer prefers to suppress this :

(setq *extended*error* nil)

will suppress both the callstack and error location message, thus, we have Acad
like behaviour;

this "magic" Lisp variable will work dynamically, so it can always switched to t or nil.

Mainly we got only positive feedback on our Lisp error mode ... but I agree, it might
be good to reduce the error output, especially if a custom error handler is defined.

Another advantage of that "magic" Lisp variable - that variable can be changed even
on client's machine, to investigate problems, which are only present on client machine,
and not reproducable on developer machine ...

So feedback is welcome :-)

Philippe Serange

Hello

Ok, the magic variable seems to be a good solution. Can we give it a name so we remember it is Bricscad only.

Philippe

Torsten Moses

Dear All,

as mentioned before, the mode of extended error message and behaviour can now
be controlled by Lisp code directly.

(vl-bt-on)    : enabled "error callstack backtrace"
(vl-bt-off)   : disabled "error callstack backtrace"
(vl-bt <n>) : outputs the "error callstack backtrace" to commandline, regardless of
                      enabled / disabled backtrace state; uses <n> error levels;
                      intended to be used from inside error handler, usually

This effects the behaviour of default *error* error handler, whether to show the
error callstack backtrace.

Additionally, there is now a "magic" Lisp variable which controls whether or not to
display the extra error location message :

(setq bcad$disable-extended-error t)   : disables output of error location message
(setq bcad$disable-extended-error nil) : enables output of error location message

Internal (startup) defaults :
- error callstack backtrace is on
- (setq bcad$disable-extended-error nil)

Using these 2 features, the error output can be reduced to minimum style (like AutoCAD)
or to maximum style incl. error callstack and error location message.

I hope this is a good solution ?

Philippe Serange

Hello,

Great.

Philippe

Roy Klein Gebbinck

@ Torsten: this seems like a good solution. Two questions:

1. What exactly is the difference between: "error callstack backtrace" and "error location message"?
2. Is (vl-bt-off)  enough for "totally silent mode" do you have to use (setq bcad$disable-extended-error t) as well?

Torsten Moses

Dear Roy,
(vl-bt-on) and (vl-bt-off) controls the "error callstack backtrace" only -
that is the stack of called functions

(setq bcad$disable-extended-error t/nil) controls the extra message regarding
the error location, like
; ----- Error around expression -----
(+ 1 "")

Both is independent (at the moment) ... but if prefered, both could be controlled
by (vl-bt-on) resp. (vl-bt-off) ... just to your (and other developers' preference)

Roy Klein Gebbinck

@ Torsten:

These considerations spring to mind:

1. Does (vl-bt-off) give you "totally silent mode" in AC? And should BC therefore behave the same?
2. What use is an "error location message" without an "error callstack backtrace"?

But because I only work with Bricscad both solutions wil be OK.

Torsten Moses

Dear Roy,

2. the "error callback backtrace" is the sequence of called functions ...
    but the "error location" is the particular code which immediately triggered the error.
    So you can have a callstack of 3 levels, and the innermost is s (defun xxx ...) with 50 statements :
    the "error location" indicates the statement where the error happend - 1 of those 50

1. (vl-bt-off) does not give a "totally silent mode" - this depends on active error handler :
    Acad AutoLISp always calls the active *error* function as (*error* "error message")
    So if a client code switches to its own error handler, then custom error handler can choose
    whether to print that message or not.
    Bricscad Lisp engine does exactly the same - no difference.
    Inside a custom error handler, the client code might call (vl-bt) to get an error call backtrace,
    but looks pretty strange

I will improve Lisp engine, to call (vl-bt) - the standard output - only in case that the active error
handler is the built-in error handler, not a client error handler.
I think, this would be the best approach ... ?