Jump to content

Type of DEFUN


Sheep

Recommended Posts

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 by Sheep
Questions has solved. Thank you to all who has responded.
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

  • 3 weeks later...

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?

Link to comment
Share on other sites

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 by devitg
  • Thanks 1
Link to comment
Share on other sites

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 by Sheep
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 

check selection or window.png

  • Thanks 1
Link to comment
Share on other sites

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 by Jonathan Handojo
  • Thanks 1
Link to comment
Share on other sites

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 by Lee Mac
  • Like 1
Link to comment
Share on other sites

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 

check selection or window.png

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)
   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 by hanhphuc
  • Thanks 1
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by hanhphuc
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...