Topic: ={ Challenge }=Find an interesting use for this routine.

[Kerry]

Cleaning up some folders this morning.
Though this may be put to some interesting usage.

The routine was designed as a testing aid and as a debug tool.

Lets see some interesting uses for it.
Have at it !

Code - Auto/Visual Lisp: [Select]

1.  
2. ;;;------------------------------------------------------------------
3. ;;;------------------------------------------------------------------
4. ;|
5.     (kdub:assert-dump-values <valueList> <msg> )
6.     Dump the Variable names and their values.
7.     kwb 20020730
8.     valueList argument must be quoted
9. (setq a1 1   b 22   c 33   dodo nil    str "Apple")
10. ( kdub:assert-dump-values (list 'a1 'b 'c 'd 'str) "Test 1A")
11. ( kdub:assert-dump-values (list '(+ a1 b 19) 'c '(+ 1 3)) "Test 3c")
12. ( kdub:assert-dump-values (list 'a1 'b 'c 'dodo) "")
13. |;
14.  
15. (defun kdub:assert-dump-values (valueList msg / _padright padlen)
16.   (defun _padright (str len)
17.     (substr (strcat str "                                                   ")
18.             1
19.             len
20.     )
21.   )
22.   (setq padlen
23.          (+ 5
24.             (apply
25.               'max
26.               (mapcar '(lambda (x) (strlen (vl-prin1-to-string x))) valueList)
27.             )
28.          )
29.   )
30.   (princ (strcat "\nassert-dump-values: " msg "\n"))
31.   (mapcar
32.     'princ
33.     (mapcar
34.       '(lambda (x)
35.          (strcat (_padright (strcat "  " (vl-prin1-to-string x) ":") padlen)
36.                  (vl-prin1-to-string (eval x))
37.                  "\n"
38.          )
39.        )
40.       valueList
41.     )
42.   )
43.   (princ)
44. )
45.  
46.  

The documented test results :

Code - Text: [Select]

1. assert-dump-values: Test 1A
2.   A1:   1
3.   B:    22
4.   C:    33
5.   D:    nil
6.   STR:  "Apple"
7.  
8.  
9. assert-dump-values: Test 3c
10.   (+ A1 B 19):  42
11.   C:            33
12.   (+ 1 3):      4
13.  
14.  
15. assert-dump-values:
16.   A1:    1
17.   B:     22
18.   C:     33
19.   DODO:  nil
20.  

[ymg]

Kerry,

It is some sort of Watch Window.

How about modifying so you get a sorted list of all defined variables.

ymg

[Kerry]

Kerry,

It is some sort of Watch Window.

How about modifying so you get a sorted list of all defined variables.

ymg

The elements are evaluated in the sequence they are listed in the parameter list.

[Kerry]

Just a note.
If we use this in large code files I'd recommend using a unique msg parameter for each call. This makes finding the relevant instance a little easier.

If the routine running in a loop it is easy to fashion a unique identifier for each iteration.

If you make the effort to use something like this don't delete the function call after testing .. simply do a find/replace and add a comment prefix to the function call. That way the functions can be used again later when/if we make modifications to the code body.

[danallen]

rather than commenting out, I use this in my routines

Code: [Select]

(if XYZDebug (princ "\nLoaded XYZ Commands -> before defun startup")) ;; or princ any message you want

this code is run at drawing open before processing any code

the idea of brief and verbose comes from infocom, and I use for giving controlling between small or large dumps of info during routines

Code: [Select]

;;;============================================================================
;;; Debugging functions
;;;============================================================================
(if (= (getenv "XYZ\\Debug") "1")(progn(setq XYZdebug_brief T)))
(if (= (getenv "XYZ\\Debug") "2")(progn(setq XYZdebug T)(setq XYZdebug_brief T)(setq XYZdebug_verbose T)))

(defun c:debug ()
  (cond
  ( (= (getenv "XYZ\\Debug") "2") ;if in debugmode verbose
      (setenv "XYZ\\Debug" "0") ;turn it off
      (setq XYZdebug nil)
      (setq XYZdebug_brief nil)
      (setq XYZdebug_verbose nil)
      (princ "\nDebugging turned OFF")
    )
    ((or (= (getenv "XYZ\\Debug") "0")
         (= (getenv "XYZ\\Debug") nil)
     )
      (setenv "XYZ\\Debug" "1") ;else turn it on
      (setq XYZdebug T)
      (setq XYZdebug_brief T)
      (princ "\nDebugging turned ON to brief")
    )
    ((= (getenv "XYZ\\Debug") "1")
      (setenv "XYZ\\Debug" "2") ;else turn it on
      (setq XYZdebug T)
      (setq XYZdebug_brief T)
      (setq XYZdebug_verbose T)
      (princ "\nDebugging turned ON to verbose")
    ) ;progn
  ) ;cond
  (princ)
)


[Kerry]

I have used a similar design in the past Dan, but found the single switch limiting and the in-line test if debug mode was on wasteful in production code. Sometimes we just want to run the asserts-xx in a small part of the code and not run others.

I still use a global variable as a debug mode switch but it's primarily used to control the (vl-bt) function call in error handlers.

What you see above is not the full testing suite. We try to target specific potential problem areas with a suitable test element.

Please note I'm not suggesting superiority of one system over another ; just indicating what we do.

It's pleasing to me to see that others take testing and error prevention as seriously as we do.

Regards,

[danallen]

I wish I was more serious, it was born more out of frustration in finding my errors than anything else! I totally forgot about the (vl-bt) function, it was even in my default error handler, IF my debug was on! I've moved on to Bricscad and have no more VLIDE, and finding errors in brics is really difficult. (vl-bt) will definitely help (if I turn my debug on...)

thanks