Networking Lisp files

Bear with me please...(TIA)

I've looked into this NG regarding loading lisp files. Here's my deal.

It seems that the easiest method to distribute lisp files is to put 'em in a
network directory and then have each user (5 here) just add them to their
startup suite, rather than hack their acad2004doc.lsp file with a load
function simply to avoid the possibility of a typo (not an uncommon event
for some of them, sad to say).

What are the pros and cons that I may be missing? Are there better ways?
We've got maybe a dozen lisps that we use now, but will there be a downside
if that list grows to a hundred?
Will a large number of files in the startup suite cause performance issues
down the road (as opposed to acad2004doc.lsp)?
Is there a REAL difference between the two?
Sorry for the remedial nature here, I'm only up to my ankles in Lisp.

Perhaps it'd be better for users to copy the files from a network location
to their own lisp directory so's to avoid complications if the network goes
down....on the other hand...I don't think I wanna chase around "tweaking" a
half dozen copies of the same files if we make an improvement, and then
worrying about which one is "latest and greatest".

Thanks for the help.

 

Wherever you put it, don't mess with acad2004doc.lsp -- make your own
acaddoc.lsp. Keep your customizations separate from the Acad-supplied files,
in one or more folders which are earlier on the search path then their
stuff. The more clearly you separate your customizations from what's
supplied by Acad, the easier your future upgrades will be.

Wherever you put your lisps, networked or local, don't run around doing
anything. Keep a master copy in a secure location, networked or local, where
only you can make changes. (Keep a backup of this too.) Make your changes in
only that one place.

Chief advantage of the networked solution is that everyone can simply use
the central master copy of the lisps, no distribution required. Chief
advantage of a local install is that Acad remains fully functional if the
station isn't logged onto the network.

Distribution of files from the "master" location to local machines isn't a
big deal. Write a batch file (hint: xcopy) that runs from the workstation to
copy down the files. Don't run around tweaking anything, do your work from
one spot.

 

Thank you Tom.
That is what I was looking for... not running all 'round every time I tweak
something.

 

just make a acad.lsp file on the network, and add that dir to each users
support path. the file will be loaded on it's own, and you can then
have all your lisp loaded by acad.lsp. (tis how we do it).

 

If you go with the local install, there are any number of ways you could
distribute the files, depending on your network and permissions. For a small
number of files, you might them copied down to the workstations via the
login script, which would refresh them every day. Or you might write a batch
file to do the same, and ask your users to run the batch file. Or with the
right permissions, you may be able to "push" the files onto the workstations
without the users' participation.

One tip -- keep all your customizations in a single folder tree. It's easier
to keep straight if you emulate Acad's tree, and add a sub-tree for your
block libraries:

CustomFolder
Drv
Fonts
Plot Styles
Plotters
Support
Template
etc
CustomBlocks
Door
Elec
Window
etc.

If everything is under one folder, it's easy to copy it from place to place
in a single motion, or to use a batch command like xcopy on it.

In some cases, like the custom fonts, you'll want to add your custom folder
to the search path in addition to the standard Acad folder, so all your
fonts and theirs are both available. In other cases, like plot styles and
templates, you'll want to point Acad toward your folder instead of theirs,
so only your custom files are easily available to the user. Again, it's best
to not touch any of the Acad-supplied files at all. If you want to customize
one, put a copy in "your" folder, earlier in the search path, and work on
that one. Just ignore "their" version. It won't be found or used since yours
will supercede it.

Think carefully about how you set things up, how you name files, and so
forth. It's hard to clean up a sloppy structure later. Our system has about
1200 customized files, of which about 1000 are blocks. This would be a real
nightmare if the organization wasn't clear.

 

If you create an "acaddoc.lsp" file you might want to use the "autoload"
function to cut down on load times when starting AutoCAD.

(autoload "LispFileName" (list "Program1" "Program2" "Program3"))
Then the "LispFileName" won't be loaded until the Program# is run.

 

Thank You both.
I am trying to straighten out a (somewhat) horrendus legacy system from a
previous CAD manager. Not that he wasn't good, just that I am adding some
customizations to increase productivity and wanna get my duckies straight
before it gets to be a big mess to clean up down the road. In the past it's
been; "Here, put this in your support folder...." and I can see that it'll
get way out of control.

Unfortunately, this is one thing I will have to deal with. We have legacy
blocks scattered all over the place. I'll just tackle them a dozen or so at
a time. and grind through it.

 

Thanks Alan.
That was one concern: we don't have a lot of lisp files at this time, but I
don't want to stretch out the boot time for stuff that isn't used often.
"Autolisp in plain english" by ....escapes me at the moment seemed to imply
this idea, although its written for earlier releases... a pretty good book
(recommended to me from this NG! Thanks). Late nite reading doesn't sink in
as deep, ya know.

 

With five users to support, you don't need to make things too complicated but...
If you want to get fancy sometime down the road, you can set up multi-level support folders for your custom files that will allow you to keep the files local and yet override them from the network when necessary. Of course, this won't work for certain files, such as most printer support files, that can only be assigned a single path in the options menu, but it's VERY handy for making an updated/fixed lisp file available to a department at a moment's notice.
Also, you can provide your users with a batch file that will remove their current custom support files before replacing them with updated versions from a secure network location, thereby ensuring that old and new files don't get mixed.
Eventually, you can go a little frivolous and set up a flag routine in your ACAD.lsp that will compare the version of their local custom support files with those on the network, and automatically prompt the users to update their files if their local ones are out of date. This allows for updates to be handled in a timely fashion without needlessly updating the support files every time AutoCAD starts.
Just make sure you document it to death so that you don't create another legacy nightmare for the next guy...

 

Yes. Kinda what I was hoping to accomplish. Simple (for now) but flexible
for the future. I can see lots of room for customization, but maybe 10
users long term. We're not a big company. Not to sound pessimistic, but I
can't see we'll ever get beyond maybe a dozen CAD stations. (I know, never
say never.) They have a "slow controlled growth" policy here. Kinda nice,
actually.

legacy nightmare for the next guy...

LOL. Agreed. Everything I'm doing it's getting documented (& revised as
req'd.) so they'll know where I've been. Mainly though, for my refrence.

 

This is what I do:
I create an "ACAD.LSP" for every user. I can access any one of them with
just one command that I write in AutoCAD. They all get their own which I
will not replace except if absolutely necessary. The absolute
non-programmers seem to like everything I write, so they aren't a problem,
really. Here is the real problem: It's when a guy who writes little
routines that don't work as well as your own but he refuses to use yours and
puts his LISP folder in line ahead of yours in the Support File Search Path.
Well, I've learned to accept that to a degree until he needs something that
everybody else is using and can't because he screwed it up. Everybody gets
his own LISP folder that I update from my PC when I update routines as
needed as time goes on. This prevents losing the routines because the
server crashed and burned. Somebody/Everybody will have a good copy of
any/all routines. I also update all the partial menus, slide libraries, and
script files in the same way. Of course I make a backup of all project
files on another drive. We're considering Xdrive for an offsite backup
solution. If anybody were to change a routine and if failed, I can
overwrite it from my station by copying the original to where it's supposed
to go on a user's PC. All the updating I've sped up by using batch files
(DOS) that I invoke from within my ACAD.LSP. The system is working great
and is really speedy. If somebody is missing a necessary file, it's easy to
update them, although I am aware if the customization were centralized, then
EVERYBODY would be missing the file until EVERYBODY had it. There's
definitely some good in that system, but if the server goes down and
everybody has drawings open, then the user can make a choice at that time to
save and draw on his own p.c. (Obviously if he had xrefs in the drawing, he
wouldn't be able to do that very well.). On the other hand if customization
were all on the server, some people just would not know how to draw
(unfortunately).

Another thing I like about having multiple copies of the drawings is that I
am free to edit routines on the fly. After I fine-tune a routine, everybody
gets it. If the routine were on the server, I would have to copy it to my
computer in order to work on it (so that I wouldn't wreck the good-working
version) and that would take more time than sending everybody the routine.
My LISP editor opens up right to the folder I want. I edit it, test it,
finish it and deliver it to all. Yes I could keep all the originals on my
P.C. and just deliver to the server, but then there's still the problem of
"what happens when the server is down?"

 

Still, your best bet is to limit other users from inputting their peculiar
devices. Looks like you need to limit their access by using the server solely.
Might be more time consuming but in the long run, you will not spend so much
time trying to correct things that one user "de-rails". As for me, I would put
up a steel wall that nobody could get through - some people are impossible to
work with.

 

Hi Bill,

For curiosity, how do you handle documentation of your programs?
It seems from this post you have an extensive range of programs available
and you are actively improving them.

If started with your company, how would I get to find out what
customisation is available, and then if you modify it how would you let me
know ?

--


Laurie Comerford
CADApps
www.cadapps.com.au