clearing variable values

is there a tool to clear the value of variables w/out exiting autocad or declaring them as local? This is for testing and debugging purposes.

Thnx, Shawn.

 

Why do you think you need to have global
variables for testing/debugging?

 

(defun C:CLEAR ()
(setq var1 nil var2 nil var3 nil)
(princ)
)
Type clear at command prompt.

Bob

 

Hey tader…salad. None that I know. If you have a problem, like your appending a list of points and every time you run the program the list gets longer, just (setq var nil) someplace. I either do it at the start where there is usually a bunch of vars being set, or right before it needs to be set… so it’s apparent why it was made nil.

 

None that I know.

There's a workaround involving atoms-family which has been kicked around in
here repeatedly, though IMHO it's in the category of tricks that are
contrary to good programming practice.

the list gets longer...

Like Tony, I don't understand why leaving a global dangling would be
considered useful. Least of all in a situation where's it's allowed to grow
uncontrollably. I suspect that if the OP explained what is being tested or
debugged, someone could suggest a way to accomplish it with localized
variables.

 

To me, a beginner using Atoms-family to null variables sounds like a good way to kill acad.
Agreed, declaring a var local is the simplest way to insure it’s nil, but… IF (a big if) your writing lisp with note pad and running it from the command line you would not be able to see your vars values.

 

I use Notepad almost exclusively, simply because I got accustomed to using a
text editor for years before VLIDE came along. I always declare a variable
local at the time I first use it. If I need to track a variable's value, I
use a temporary print statement in the code. My experience has taught me
that leaving floating globals is a bad habit to develop -- far more likely
to cause a bug than to cure one.

If you're a beginner, why not learn to use the debugging tools in VLIDE?

 

Had to re-register for some reason. So i'm under a diff. username. I'm sure that i didn't offend anyone, even though those posts are always entertaining to read. Anyway, I've been playing w/ the lisp for about 6 years now off and on, so i'm still a beginner. I've always used vlide. I know you can set the var. to nil by writing (var nil) in the console. I'll try to answer all the quest. posted in my post. I think i need global variables temporarily so i can see the data that's being stored in them. It helps me find my mistakes by looking at that data. When the prog. is complete and finally works then i go back and declare local. It sounds like from reading the posts that I'm going about something wrong. When "you" write your lisps, don't you have the need to see the info that's being stored in the variables? Maybe I'm doing things the hard way.
TIA, Shawn.

 

I don't understand what you mean by "seeing" values, or why you think that
dangling global variables will help. I normally write functions to have
return values. If I want to "see" the value I run the function. If there's
any doubt about intermediate values during the processing of the function,
as I said, I throw in a temporary print statement, so whatever value I care
to check is displayed on the command line as the function runs. Then I
delete the print statement when I'm done.

(setq n 0)
(while (< n 100)
(setq n (+ 3 n))
(print n) ;temporary print statement
)

This is an old-fashioned, crude method, and I'm not recommending it. It's
just what I do, by habit, in the rare and unusual cases that I need to
"watch" a variable in action. In VLIDE, you can add a watch window, and use
the other debugging tools, to do the same job in a better way.

I seldom have a need to "see" a variable to know what's in it -- the code
determines that. If I make it a real or a string, well, that's what it is.
It's not going to change unpredictably unless the function is badly
written -- and then the real issue at hand is not seeing the variable, it's
rewriting the bad code. If you keep functions short and simple, they aren't
hard to understand and debug.

There are people who have been doing what you do for years -- there actually
used to be books which recommended it, and some people developed that (IMHO
bad) habit. And their constant chore is going back and tracking down all
those variables to localize them after the fact. If you don't make a mess to
start with, you don't ever have a mess to clean up later. I localize every
variable the first time I use it, and don't have that chore. I also don't
have to add all the workarounds that result from the dangling globals, like
setting a variable nil the first time it's used, which will be superfluous
in the "finished" code.

 

If you're using the Visual LISP IDE, you can inspect the
values of local variables in a breakpoint.

You can also use a simple read-eval-print loop in your
code, which pauses to let you type in the name of a
symbol, and see its value:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; BREAK.LSP Copyright (c) 1992-2005 Tony Tanzillo
;;
;; Manual breakpoint debugging tool
;;
;; Usage:
;;
;; After loading this file, you can place a call to the (break)
;; function at any point in your code, and it will pause the
;; execution of your program, and let you inspect the values of
;; local variables, and evaluate arbitrary LISP expressions.
;;
;; When the call to (break) is encountered, you will see the
;; following prompt on the AutoCAD command line:
;;
;;
;; *** Break >>
;;
;; At this prompt, you can repeatedly enter any LISP expression,
;; (which can be nothing but a symbol used as a local variable
;; in your program), and its value/result will be displayed on the
;; command line. You can repeatedly enter expressions as long
;; as you wish. When you're done and want to resume execution
;; of your program, just press ENTER at the *** Break >> prompt.
;;
;; Simple example usage of the (break) function:
;;
;; (defun C:TEST ( / a b c)
;; (setq a 1.25)
;; (setq b (list 2 "foo" 99.5 "bar"))
;; (setq c "Hello there")
;; (break)
;; (princ "\nResuming execution of C:TEST")
;; (princ)
;; )
;;
;; After defining and running the above command C:TEST:
;;
;; Command: TEST
;; Pick a point: <pick a point in the drawing>
;;
;; *** Break >> a
;; Result: 1.25
;;
;; *** Break >> b
;; Result: (2 "foo" 99.5 "bar")
;;
;; *** Break >> c
;; Result: "Hello there"
;;
;; *** Break >> D
;; Result: (17.8133 14.9435 0.0)
;;
;; *** Break >> (entget (entlast))
;; Result: ((-1 . <Entity name: 7ef52e98>) (0 . "LINE") (330 . <Entity
name:
;; 7ef52cf8>) (5 . "8B") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8
.. "0")
;; (100 . "AcDbLine") (10 2.0 2.0 0.0) (11 4.0 4.0 0.0) (210 0.0 0.0 1.0))
;;
;; *** Break >> (getvar "dwgname")
;; Result: "Drawing1.dwg"
;;
;; *** Break >>
;; Resuming execution of C:TEST
;;
;; Command:


(defun break_error (s)
(princ "\nError in break expression - Aborting.")
(princ)
)

(defun getexpr (msg / rslt)
(initget 128)
(setq rslt (getint msg))
(if (eq (type rslt) 'str)
(catch-error
'(lambda ()
(read rslt)
)
'(lambda (error)
(write-line (strcat "\nREAD Error: " error))
T
)
)
)
)

(defun break ( / break_expr *break-result*)
(while (setq break_expr (getexpr "\n*** Break >> "))
(catch-error
'(lambda ()
(princ (strcat
"Result: "
(vl-prin1-to-string (setq *break-result* (eval
break_expr)))
"\n"
))
;; (print (setq *break-result* (eval break_expr)))
)
'(lambda (error)
(write-line (strcat "\nEVAL Error: " error))
)
)
)
(print *break-result*)
)


(defun catch-error (catchrotected catch:OnError / catch:err)
(setq catch:err
(vl-catch-all-apply catchrotected)
)
(if (and (vl-catch-all-error-p catch:err)
catch:OnError
)
(Apply catch:OnError
(list (vl-catch-all-error-message catch:err))
)
catch:err
)
)

;; BREAK.LSP