Multiple executions in one LISP file?

[tzframpton]

My apologies in advance for the lack of terminology.

 

I know I've seen it done before but I wanted to be sure it's (1) possible and (2) the best approach. Can I have one LISP routine that has multiple "programs" that you can execute individually, all by loading the one file? Here's a for instance:

 

(defun C:TEST (/)

 (defun Cmd1
   (command "command_1")
 )

 (defun Cmd2
   (command "command_2")
 )
 
 (defun Cmd3
   (command "command_3")
 )

)

I would like to combine some stuff that I'm working on and I just wanted to make sure I'm following the right path here. Thanks in advance.

[Hippe013]

You are on the right path, but should be coded as follows:

 

(defun c:Cmd1
   (command "command_1")
 )

 (defun c:Cmd2
   (command "command_2")
 )

 (defun c:Cmd3
   (command "command_3")
 )

 

All can be in one lisp file.

[tzframpton]

Ah, makes sense. So, this could also apply for my ACADDOC.LSP file, right? Could I just load one LISP file, instead of my current configuration:

;;; acaddoc.lsp

(load "C:\\path\\lisp1.lsp")
(load "C:\\path\\lisp2.lsp")
(load "C:\\path\\lisp3.lsp")

etc...

;;; end acaddoc.lsp

Or would containing every routine I use into one LISP file be overkill?

[Lee Mac]

Certainly, a LISP file can contain as many function definitions as you want/need.

 

As a little background on loading LISP files:

When a LISP file is loaded, the expressions inside the file are all evaluated in the order they appear in the file. Usually, LISP files only contain 'defun' expressions, hence those functions are defined when the file is loaded and the 'defun' expressions are evaluated (note - this is only defining the functions, not evaluating the functions themselves). But essentially any LISP expressions in the file will be evaluated (for example, loading messages when 'princ' expressions are found outside of a function definition and hence evaluated when the file is loaded).

 

With this in mind, note that in your example 'Cmd1', 'Cmd2' and 'Cmd3' will not be defined until you type 'test' at the command-line - at which point, the expressions within the 'test' function definition are evaluated, namely, the 'defun' expressions for 'Cmd1', 'Cmd2' and 'Cmd3'.

 

The alternative:

 

(defun c:test ( )
... test function expressions ...
)

(defun c:Cmd1 ( )
... Cmd1 function expressions ...
)

(defun c:Cmd2 ( )
...
)

etc.

 

With the above structure, the 'defun' expressions for 'test', 'Cmd1', 'Cmd2' and 'Cmd3' will be evaluated on loading and all four commands will be available after loading.

 

( Hope this post isn't too confusing )

[Lee Mac]

Or would containing every routine I use into one LISP file be overkill?

 

I doubt you would see a difference in performance: you are evaluating the same number of LISP expressions to define the commands, only, they are all located in one file instead of separate files.

 

However, most users will keep the programs in separate files and use 'load' statements or 'autoload' statements within the ACADDOC.lsp because each program is then compartmentalised in its own file and is far easier to manage (especially when updating the program to a new version for example).

[tzframpton]

With the above structure, the 'defun' expressions for 'test', 'Cmd1', 'Cmd2' and 'Cmd3' will be evaluated on loading and all four commands will be available after loading.

 

( Hope this post isn't too confusing )

Ah, I think I get it. You're stating that in my example, until I type TEST the other functions will not work because they haven't been evaluated yet.

 

However, most users will keep the programs in separate files and use 'load' statements or 'autoload' statements within the ACADDOC.lsp because each program is then compartmentalised in its own file and is far easier to manage (especially when updating the program to a new version for example).

Makes sense. In that case I will leave it as is.

[David Bethel]

Here's a scenario that I use a lot:

 

In acad.lsp or acaddoc.lsp or whatever they are calling it today

 

;;;SIMPLE DIMS
(defun c:dms ()(if (not c:dim-simp)(load "dim-simp"))(c:dim-simp))
(defun c:dmh ()(if (not c:dim-hor)(load "dim-simp"))(c:dim-hor))
(defun c:dmv ()(if (not c:dim-ver)(load "dim-simp"))(c:dim-ver))

 

This way you only load the overhead when you have an actual need for the program.

 

-David

[alanjt]

David, is autoload not available in r12?

[David Bethel]

Alan,

 

No, autoload went through various forms and incarnations in the older releases. By the time acaddoc.lsp came around you needed to have each release have it's own autoload. About like having to recompile arx with each new release. It was a pain so I never went that rout. -David

 

PS - My auto-loader for external apps:

;;;LOAD EXTERNAL PROGRAMS
(defun load_exp (/ v p a av)
 (setq v (ver)
       p (getvar "PLATFORM")
       a (getvar "ACADVER"))

 (setq av (cond ((and (wcmatch a "*12*")
                      (wcmatch p "*DOS*"))
                  "12DOS")
                ((and (wcmatch a "*12*")
                      (wcmatch p "*Win*"))
                  "12WIN")
                ((and (wcmatch a "*13*")
                      (wcmatch p "*DOS*"))
                  "13DOS")
                ((and (wcmatch a "*13*")
                      (wcmatch p "*Win*"))
                  "13WIN")
                ((wcmatch a "*14*")
                  "14")
                ((wcmatch a "*15*")
                  "15")
                (T "UnKnown")))

 ; (princ (strcat "\n" p " " v " " a " " av))

 (cond ((= av "12DOS")
        (and (not (member "C:/ACAD/12/ACADAPP.EXP" (ads)))
             (xload "c:/acad/12/acadapp.exp"))
        (and (not (member "C:/ACAD/12/HPMPLOT.EXP" (ads)))
             (xload "c:/acad/12/hpmplot.exp"))
        (and (not (member "C:\\ACAD\\UT\\DOSLIB12.EXP" (ads)))
             (xload "doslib12.exp")))
       ((= av "12WIN")
        (and (/= (type dos_dir) 'EXSUBR)
             (xload "doslib12.exe")))
       ((= av "13DOS")
        (xload "c:/acad/13/acadapp.exp")
        (xload "c:/acad/13/hpmplot.exp")
        (and (/= (type dos_dir) 'EXSUBR)
             (xload "doslib13.exp")))
       ((= av "13WIN")
        (load "c:/acad/common/ai_utils.lsp")
        (load "c:/acad/common/appload.lsp")
        (and (/= (type dos_dir) 'EXSUBR)
             (xload "doslib13.exe"))
        (and (not (member "c:\\accuren2\\accurend.arx" (arx)))
             (arxload "c:/accuren2/accurend.arx")))
       ((= av "14")
        (and (not (member "doslib14.arx" (arx)))
             (arxload "doslib14.arx")))
       ((= av "15")
        (and (not (member "doslib2k.arx" (arx)))
             (arxload "doslib2k.arx")))
             ))

[alanjt]

Alan,

 

No, autoload went through various forms and incarnations in the older releases. By the time acaddoc.lsp came around you needed to have each release have it's own autoload. About like having to recompile arx with each new release. It was a pain so I never went that rout. -David

Ahh, OK. Makes sense.

[BIGAL]

In the large architecture Lisp we did we had a master lisp that contained all the defuns that were common to all the other programs and say autoloaded that and just like above loaded each lisp as required no performance issues and it started life in R12.

 

The main thing was by putting the common bits of every lisp into a master then just call by defun, this makes programing easier and keeps the standards of whats being drawn under control also. The system had user defined layers but objects drawn on correct layer with no hard coding of the lisps a big advantage when the boss wants red instead of blue. Just had a look around 100 lisps. The partial menu was coded with load lisp so no problem for next version upgrade.

 

Just though of another good example of using a single defun in master lisp AlanJT's select from dialouge box lsp can be called from any other lisp.

 

If I started again I would definately add entmakes to master (line p1 p2)

[Lee Mac]

You're stating that in my example, until I type TEST the other functions will not work because they haven't been evaluated yet.

 

Essentially yes - just to be nit-picky: the other functions will not work because they haven't been defined yet, i.e. the respective 'defun' expressions haven't been evaluated.