Type of DEFUN

[Sheep]

SOLVED.

Hi all, i seen several defun with a unique word(?) like

(defun Test ()

(defun c:Test ()

(defun m:Test ()

(defun LM:test ()

(defun DT:Test ()

What does the c, DT, m and LM stands for? When should i use it and why? Thank you for your time. Are there any other defun type other then the above sample?

Edited March 14, 2020 by Sheep
Questions has solved. Thank you to all who has responded.

[rlx]

only if your command begins with 'c:' , you can call the command (after loading) on the command line with the name that follows. So when you load 'MyRoutine.lsp' and this routine has a function called 'c:test' you would only have to type test on the command line. In all other cases you have to call the command with parentheses. So when you have a function that is written as (defun test1 ().... you have to start it with (test1). If you have a function (defun LM:Test1 ()... you have to start it with (LM:Test1).

 

The reason why someone uses LM: as prefix would be when your name is Lee Mac. See it as a sort of signature , calling card whatever. So when you write a few  brilliant routines for us here on this forum , you could write them as (defun Sheep:Test1 ()... and then someone would have to type (Sheep:Test1) to start your mean lean lsp routine.

 

There are more types of defun , like defun-q and this has to do with how your function will be evaluated (as a list) . This is often used for functions that can modify themselves so very useful for self 'learning' routines. But this is more advanced stuff and there are people that can explain this far more better than me.

[Lee Mac]

@rlx has pretty much covered it, but I've also posted an explanation here which you may find useful.

Edited February 13, 2020 by Lee Mac

[Sheep]

thanks you. i need to learn more.

[Sheep]

Recently i saw a different defun:

Quote

Defun ( a b/c d)

Why is the slash at the middle?

2. When should i localised defun's setq.

3. How can i determine when to use global setq?

[devitg]

2 hours ago, Sheep said:

Recently i saw a different defun:

Why is the slash at the middle?

2. When should i localised defun's setq.

3. How can i determine when to use global setq?

before slash : arguments  to send to the defun

after slash : such variables c and d are local , so it will set to nil or lost it's value when the defun ends 

2: to avoid other lisp to get such value from one to another 

3: if you don't care  the variable would interfere in other lisp 

 

Edited March 4, 2020 by devitg

[Sheep]

Thanks @devitg for your answers. If the whole routine of the LISP done, and i start it again, will the global variable (from the previous routine) exists? Or will it flush out after the LISP has finished its purpose?

5 hours ago, devitg said:

before slash : arguments  to send to the defun

after slash : such variables c and d are local , so it will set to nil or lost it's value when the defun ends 

2: to avoid other lisp to get such value from one to another 

3: if you don't care  the variable would interfere in other lisp 

 

Edited March 5, 2020 by Sheep

[BIGAL]

A global variable will remain till you close Autocad or if you change dwgs  your global value will not be in the current dwg. Going back it will be there. There are ways though to get around this.

[Sheep]

Can you please give me an example @BIGAL.

9 minutes ago, BIGAL said:

 There are ways though to get around this.

[BIGAL]

The blackboard is one way http://help.autodesk.com/view/ACD/2015/ENU/?guid=GUID-4E317058-1E6A-45E2-A9BE-71D63D2D0A33

 

The setenv is another.

[Sheep]

What if i do this:

Quote

(Defun test1 ()

...some codes

)

(Defun test2()

....another code

)

(Defun c:RunTest (/ Test1 Test2)

(Test1)

(Test2)

Will it purge(?) The setq in all the defuns?

[hanhphuc]

2 hours ago, Sheep said:

What if i do this:

Will it purge(?) The setq in all the defuns?

 

Try read about localizing.

 

In your c:runtest

(test1) 

(test2)

functions won't work due to symbol localized and not defined

unless both are defined inside c:runtest

[Sheep]

Thanks @hanhphuc for the link. Again, Lee Mac put it in simple words. BTW, i just noticed the legendary @Lee Mac replied to this thread! Wow..im honoured.

 A friend once told me, if the senior members actively helped new members, that is the best forum. Im in the right forum. Thank to all.

[Sheep]

Correct me if im wrong, is it a good practice to let the setq global while making/testing the LISP and then localize it after everything is done?

[devitg]

YES, no DOUBT.

Meanwhile you can set the variable to nil at the  start.

and after it work as  need you can use the VLIDE Check Selection or or Check Edit Window, it will give you all globals variables names 

[Jonathan Handojo]

13 hours ago, Sheep said:

Correct me if im wrong, is it a good practice to let the setq global while making/testing the LISP and then localize it after everything is done?

 

Yes, that's for sure... Localizing your variables is a very good practice, as devitg says, no doubt. And it's not only variables you can localize, functions are also the same.

 

(defun function1 ( / )

    (defun tstfunc (a b)

        (/ (+ a b) 2)

        )

    (tstfunc 4 10)

    )

 

;; ----------------------------------------------------- ;;

 

(defun function2 ( / )

    (defun tstfunc (a b)

        (/ (- a b) 2)

        )

    (tstfunc 4 10)

    )

 

;; ----------------------------------------------------- ;;

(defun function3 ( / )

    (tstfunc 5 7)

    )

 

Take above for example. Try calling function1 then function3. Now try calling function2 then function3. You'll see that even though you run function3 twice, the result is different when you run it the first time and the second.

 

As such, this is why localizing variables are important. Then there's another case where users do (setq a (cons b a)) without ever setting (setq a nil) at the beginning. If you don't localise the variable a, the result you'll get will be screwed. 

Edited March 6, 2020 by Jonathan Handojo

[Lee Mac]

17 hours ago, Sheep said:

Correct me if im wrong, is it a good practice to let the setq global while making/testing the LISP and then localize it after everything is done?

 

I strongly disagree with this practice: failing to declare the scope of variables before running a program has the potential to introduce unexpected & undesirable behaviour into an otherwise working program, resulting in self-inflicted debugging. If the objective is to inspect variables following evaluation, I would suggest either printing the value of the variable using print or prin1 or watching the variable in the Visual LISP IDE.

Edited March 6, 2020 by Lee Mac

[hanhphuc]

another for VLX

vlax-add-cmd

vl-acad-defun or undefun

(vl-acad-defun (defun c:tt ()(princ "Hello World" )(princ) )) 
2172 
'c:tt

not sure why it always return as integer? 2172

 

 

14 hours ago, devitg said:

YES, no DOUBT.

Meanwhile you can set the variable to nil at the  start.

and after it work as  need you can use the VLIDE Check Selection or or Check Edit Window, it will give you all globals variables names 

FWIW

Tools->General Options->Diagnostic->Report statistics during syntax checking (must be checked)

 

another interesting in VLIDE, when you change the settings in Tools->Environment Options->Visual LISP Format Options

after formatting, the bottom comments will be updated real time.

ie: you can also change the options in the comment list then reformat (triangle button)

;|«Visual LISP© Format Options»
(120 2 1 1 nil "end of " 50 9 0 0 0 T nil T T)
;*** DO NOT add text below the comment! ***|;

120    Right text margin
2     Narrow style indentation
1     Single-semicolon comment indentation
1     Closing paren style (0/1/2)
nil    Insert form closing comment (T/nil)
"end of " Form closing comment prefix
50    Approximate line length
9    Maximum wide-style car length
0    Setting case for symbol protected (0/1/2)
0    Setting case for symbol unprotected (0/1/2)
0    Long list format style (nil/2/0/1)
T    Insert tabs (T/nil)
nil    Preserve existing line breaks (T/nil)
T    Split comments (T/nil)
T    Save options in source file (T/check in dialog box for nil)? not sure 

 

 

 

 

 

Edited March 7, 2020 by hanhphuc

[Sheep]

I need to clear the haze a bit. Let say i made 2 (defun) and localizing both. After the first defun is done will Autocad reset all the setq (in the 1st) to nil? Can the second defun still call any setq in the first defun or i will get a nil instead of its value?

[hanhphuc]

21 minutes ago, Sheep said:

I need to clear the haze a bit. Let say i made 2 (defun) and localizing both. After the first defun is done will Autocad reset all the setq (in the 1st) to nil? Can the second defun still call any setq in the first defun or i will get a nil instead of its value?

 

since both functions vars localized then you will get nil

unless during debugging/testing you have few global symbols (variable) exposed, then it returns that global value.

 

assume you have variables named a b c d e exposed to global, reset it

(foreach x '( a b c d e )

(set x nil)

)

 

Edited March 7, 2020 by hanhphuc