Organizing lisp files

Tim Neumann

I just wanted to get some feedback on how you other folks organize your lisp routines and such. I've been putting everything under one folder separate from the Bricscad files called "cad support" but right now I have so many lisp routines it's hard to fathom what's what. I guess the common sense thing is to put them in their own folder. Any other ideas?  

Knut Hohenberg

I usually put routines that consist of several files in a sub-folder of their own. Since keeping track of all these folders in SRCHPATH is somewhat clumsy when moving between machines, I prefer going through the code and prefixing calls to external routines with the respective folder names (so I have just one parent folder in the search path)

John Gaunt

I keep mine in a directory called C:Dwgs, which contains all the general dwg files. Specific job folders are allll sub-directories of C:Dwgs.

That way the lisps are in a directory already a focus in the search path.

My windows explorer usually closes/opens in or under that directory and the directory is easy to find in backups.

The lisps are not too hard to pick out among the dwg files.

Greg Skelhorn

I have a private Src folder with several sub-folders where I work on the routines as they are developed. I do not have a lot of large projects. Mostly smaller ones. Each sub-folder under Src contains the test data and research material I use to develop the routines. While I am working on the programs I add it to the front of the SRCHPATH or create an app init function that re-loads everything. I keep all the stable in-use lisp / dcl files in a single directory on the network server. As I work on a file or set of files it does not affect others using the routines. Once all is working and tested I copy the lisp / dcl to the network support folder. I use bazaar for revision control in the Src sub-folders so it is easy to roll back if I mess up.

All that being said, I haven't had much time to write anything lately... long list of things I'd like to like to tackle...

Jason Bourhill

Hi Tim,

I work on the principal of keeping applications in 3 different locations, which reflects their usage.

1. Local User Library e.g "C:\users\jason\my documents\scripts".  Personal folder on the Network/Local machine only accessible by me. Use for hacks, and trialling new stuff before exposing it to others.
2. Project Library e.g. e.g "P:\Proj-XYZ\Drawings\scripts".  Project folder on the Network/Local machine accessible by all working on that project. Use for routines that developed specifically for the project.
3. Company Library e.g. "R:\CCL-CAD-Library\scripts". Central CAD library on the Network/Local machine accessible by all CAD users in the company.
   

I then use the set the support search path to set precedence e.g:

SRCHPATH
"C:\users\jason\my documents\scripts;"P:\Proj-XYZ\Drawings\scripts";"R:\CCL-CAD-Library\scripts"

I also maintain a lisp file that is a container to point to all the lisp programs is use e.g:
[code];-------------------------------- EXTRAPROG.LSP ---------------------------------

; Load External lisp routines
; These are small Commonly used external programs
; defined here to load & run automatically

(autoload "bd.lsp" '("BD")) ; Add Bearing Distance details to lines and polylines
(autoload "na.lsp" '("NA")) ; No Aids. Turns Off Drawing Aids
(autoload "tbc.lsp" '("TBC")) ; Toggle the background colour between Black and White
(autoload "vpr.lsp" '("VPR")) ; Rotate the view of selected paperspace viewports

(princ "\nEXTERNAL PROGRAMS loaded")
(prin1)
[/code]

I place a call to load "extraprog.lsp" in my on_doc_load.lsp e.g:

[code]
; FLNF
; Echoes a message when an external routine fails to load
(defun flnf (fil)
 (if (= (type fil) 'STR)
   (princ (strcat "\n" fil " not found on search path."))
  )
 (prin1)
)

;STARTUP
; function Automatic Runs on entering CAD
(defun-q S::STARTUP ( / filenm f)
   (flnf (load "QuickKey" "QUICKKEY"))  ; Load Quick key definitions, short lisp routines
   (flnf (load "extraProg" "EXTRAPROG")); External lisp routines
   (flnf (load (strcat (getvar "DWGPREFIX") "scripts\\extras") "EXTRAS")) ;Load extra routines specific to dwgs/contract if present
 (setq S::STARTUP ())
(prin1)
)[/code]

You will also see that my startup will load an extras.lsp relative to my current drawing, if present. This a hook to load routines specific to that project.

Knut's option for sub folders is valid, you just need to take care with applications that call additional files, such as lisp routines that require .dcl files.

Regards,

Jason Bourhill

CAD Concepts

Roy Klein Gebbinck

My two cents:

1.
I prefer giving Lisp programs a meaningful name. So I would use "ViewportRotate.lsp" instead of Jason's "vpr.lsp". In the file there would be two commands: c:ViewportRotate and c:vpr (calling the 'long' command).

2.
The function (vl-list-loaded-lisp) is very useful if you want to use files that reside in the same folder as the Lisp program but not add that folder to the search path or hard-code it into the lisp.

martin@enco.us

I create a new folder each year for work in progress.  Once a function is good enough for production use it gets copied into a master file that is automatically loaded when Bricscad or Autocad starts.  There are three master files that both CAD programs load plus a fourth file just for Bricscad which has replacements for several of the Express Tools.  All routines are written to work with both Bricscad and Autocad.  I keep the master files in a folder called "C:\CAD Master".  The CAD Master folder has all the customized files that would normally be in the CAD program's Support folders, and both Bricscad and Autocad had that folder at the top of the search list for files.  That gives me one place to maintain for customizations instead having some files in \Support and others in the \User chain. 

STEVEN SANDHORST

I downloaded a program from Cadalyst years ago that is very handy for loading lsp files.  It also provides a one-line description of the file to help you know what the file does.

LOADLSP.zip