Lisp management a starting point

Firstly I am asking others to comment also on their experinces.

One of thing I notice a lot is the lisp programs posted as singular answers for a problem. But often this is only a single part in multiple routines that the user will develop to enhance their work load.

I was involved in a commercial Autocad add on product with around 100 lisp programs so management of this with various people writing code was important.

What I am suggesting is if your going to write a suite of lisps take a moment to plan it, have a think about what code will be repeated in multiple lisps and make a single common lisp that contains this code and gets called via defuns.

An example is that as you added objects there relevant layer was added via a look up table that the end user could change to suit them two benefits we wrote the code the end user picked layer names. Another noticed in a couple of bits of code here is where you need version numbers to get to say CIV3d database put this in its own routine so when upgrade occurs add 1 line and all code still works.

Another example thanks to Alanjt is a lisp that populates a dialouge box for user input rather than a dialouge for every program.

I had image choices 2x2 3x2 4x4 etc just populate the correct dialouge but write only once.

A post today my time was about choosing pipe sizes a perfect example to have it at first as a seperate defun that can later be saved outside once testing is done and then available for more programs.

People like Lee and AlanJT must have 100's of lisps so how do you guys manage them ? Do you have a common lisp and use defuns a lot?

There's lots of ways. But having common defuns in some form of library is a good starting point. Only as good as your management of such library though. I've run into situations where my libraries have modified themselves over years - and this tends making me "forget" what I already have. A very good, yet much omitted thing is documentation - you could very easily forget that you even had a defun for such-and-such which you've written years ago. But if you have a common documentation for such it's a case of simply searching through it. An example is Lee's webpage - though it's geared to explaining to others what he's routines do, a documentation for yourself might be much more succinct.

Some of us have been making lisps since the 90's (some even earlier), so it's not uncommon to have a library of 1000's (perhaps not that all of them are used anymore).

Another thing I would have liked to do, but usually just don't have the time for is to plan a structure for such library. It's really come back to haunt me with the Caddons project, which definitely needs a lot better structure than it has as yet.

I'm currently reevaluating my current code organizational structure, and am greatly lacking in documentation. When I first started developing, I created a command that would list all commands and a one-line description within the defun. That quickly fell behind the more I developed.

I'm at the point now, where simply getting this documentation compiled into a Word document for starters would be advantageous. From there I can export to HTML, but I feel that ultimately I'd like to produce a compiled HTML (.CHM). :sigh: I just don't know where I'm going to make time for all of that!? LoL I 'spose that's all just part of the job.

I'm actually working on something like that for Caddons as well. Extract all the defuns (especially theose with c: prefixes) and save this as code + a description of what's in the header (i.e. arguments if any) + any preceding comments to a html file (using a template with some tags which gets replaced). Then I use HelpChm to compile those html files into a chm, as well as for upload to the Caddons wiki pages. Though it only gives a rough document start-point, most of the data is at least there, since I tend to at least describe a defun in a preceding comment, all that's left is to neaten the comment (cross referencing through a bread-crumb system is handled by the documentation system, indexing by the chm).

Our "how to use lisps.doc" contained in our "How to" directory is 7 pages long it is alphabetical and has a short description of what each lisp/vba does and how to make it work, next stage is to add images (started this) to make it easier to understand multi pick routines. The help is not extensive as most people know what they are trying to achieve and the way to go about it. We make sure new staff are shown this, even old staff need a reminder now and then and its growing thanks to sites like cadtutor.

I just started with Run CMD change to lisp directory dir *.lsp >dirlisp /b creates dirlisp.txt file with lisp file names.

FYI if your writing a full blown help manual allow about .5 day per program if your going to have lots of screen shots showing what to do next you will be suprised how slow it is showing pick point 1 2 3 4 etc.

The idea of the C: defuns is good and in the "how to" there is the shortcut key is listed versus the menu pick option.

Another thing hardly ever mentioned is the old fashioned screen menu pop $S on the left or right up it can be used for user input particuarly where the objects are always the same and saves typing these can display something but the answer is built in behind. Brick lengths 1 2 3 4= 230 475 730 etc

Hey all, if it is for the lisp you are using, and having a smaal discription in use this http://www.jefferypsanders.com/autolisp_LOADLSP.html

The real code i wrap in a vlx file so that i'm sure that i have the lsp with the sub lsp and dcl file's.

For the lisp you see in the "loadlsp" in have a folder with little links that if you load the lisp via " loadlsp" it also starts.

; Merge are replace TextStyles with others present in the drawing                                                                           

(defun C:mergetextstyle- ()

   (load "mergetextstyle.vlx")

  )
   
(c:mergetextstyle-)

;;;
;;;
;;;Next line auto starts the routine

(c:mts)

;;;

(princ)

Greetz John

Not native enghlis

Hi all read a post today tip of the day put the following in on first line of code to prevent "loaded the lisp nothing happened"

(princ "\nTo run type XYZ..")

That's probably a good idea for lisps you share to others. Though not everyone wants to have their command line cluttered.

Can you imagine if every single comand you (or someone else) wrote displayed a load message!? LoL