Author Topic: ={ Challenge }=Find an interesting use for this routine.  (Read 2081 times)

0 Members and 1 Guest are viewing this topic.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
={ Challenge }=Find an interesting use for this routine.
« on: April 02, 2014, 06:43:17 PM »

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.  
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

ymg

  • Guest
Re: ={ Challenge }=Find an interesting use for this routine.
« Reply #1 on: April 03, 2014, 04:33:17 PM »
Kerry,

It is some sort of Watch Window.

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

ymg

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: ={ Challenge }=Find an interesting use for this routine.
« Reply #2 on: April 03, 2014, 04:38:56 PM »
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.
kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

Kerry

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: ={ Challenge }=Find an interesting use for this routine.
« Reply #3 on: April 03, 2014, 05:12:29 PM »
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.

kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

danallen

  • Guest
Re: ={ Challenge }=Find an interesting use for this routine.
« Reply #4 on: April 03, 2014, 08:22:14 PM »
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

  • Mesozoic relic
  • Seagull
  • Posts: 11654
  • class keyThumper<T>:ILazy<T>
Re: ={ Challenge }=Find an interesting use for this routine.
« Reply #5 on: April 03, 2014, 08:47:01 PM »
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,

kdub, kdub_nz in other timelines.
Perfection is not optional.
Everything will work just as you expect it to, unless your expectations are incorrect.
Discipline: None at all.

danallen

  • Guest
Re: ={ Challenge }=Find an interesting use for this routine.
« Reply #6 on: April 03, 2014, 08:54:36 PM »
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