khoshravan Posted August 16, 2011 Posted August 16, 2011 Maybe it is better to ask the question in this manner: What is the best way to manage the LISP codes and know when to load which code from which address. Maybe it is not wise to load all codes at ACAD startup as it is related to loading, I can assume it consumes bits and bytes and make the program fat which is not good. But my problem is that: When number of codes are handful, there is no problem remembering the name and what they do, but when they increase it is hard to know which LISP is necessary and in which folder I should look for it? How the you guys manage your LISP codes? Quote
JONTHEPOPE Posted August 16, 2011 Posted August 16, 2011 I like to keep all lisps loaded thru cui. Quote
alanjt Posted August 16, 2011 Posted August 16, 2011 I have a .mnl file that's tied to my mnu, which has all my active LISPS loaded with the autoload or load functions. Quote
David Bethel Posted August 16, 2011 Posted August 16, 2011 I use a combination of styles For common everyday small routines, I store them in a library file ( lib.lsp ) and load it via s::startup with each drawing. I have 6-8 of these type of apps. For larger and more complex routines, I use a loader app that is located in my acad.lsp ( acaddoc.lsp ) file (defun c:vca ()(if (not vca_)(load "vcart"))(vca_)) (defun c:vcp ()(if (not vcp_)(load "vcartp"))(vcp_)) (defun c:vsc ()(if (not vsc_)(load "vscart"))(vsc_)) This gives shortcut access to (3) large and varied serving cart routines the I have and yet doesn't use that much overhead or resources. I have several hundred of these. One of the library style short comings is if you get a error while editing the library. Tracing them down can be a bear. Also overwriting a routine can very difficult to track down as well. All of the routine should in an ACAD search path directory. I would not recommend trying to do exclusive pathing for these. -David Quote
khoshravan Posted August 16, 2011 Author Posted August 16, 2011 I like to keep all lisps loaded thru cui. Could you please explain more on the procedure and what is its benefit? Quote
khoshravan Posted August 16, 2011 Author Posted August 16, 2011 I have a .mnl file that's tied to my mnu, which has all my active LISPS loaded with the autoload or load functions. .mnl? mnu? autoload? Could you please give some explanation on above phrases? Quote
ReMark Posted August 16, 2011 Posted August 16, 2011 I use the acaddoc.lsp file by inserting a line that "calls" my master acad.lsp file which has all the routines on use on a daily basis stored within. For those I seldom use I just APPLOAD them. Quote
khoshravan Posted August 16, 2011 Author Posted August 16, 2011 I use the acaddoc.lsp file by inserting a line that "calls" my master acad.lsp file which has all the routines on use on a daily basis stored within. For those I seldom use I just APPLOAD them. I need more explanation to understand. Does acaddoc (AutoCad Document) have special meaning? What is the master LISP file and its relation to acaddoc.lsp? Quote
Lee Mac Posted August 16, 2011 Posted August 16, 2011 I use the acaddoc.lsp file by inserting a line that "calls" my master acad.lsp file which has all the routines on use on a daily basis stored within. For those I seldom use I just APPLOAD them. Why are you loading twice? the ACAD.lsp loads when ACAD is opened, loading all your routines into the first opened drawing, then you are reloading the ACAD.lsp file from the ACADDOC.lsp file. Why not either load all your routines from the ACADDOC.lsp file or set ACADLSPASDOC=1 to load the ACAD.lsp into every drawing opened and forget the call from the ACADDOC.lsp? Or have I misunderstood? Quote
irneb Posted August 16, 2011 Posted August 16, 2011 To answer khoshravan's questions: Loading through CUI: Each CUI file (main/partial/enterprise) can have a list of LSP files which must load as well. MNU is the old menu file. It's been replaced by the CUI files, though you can still load MNU as is, it just gets converted to CUI / CUIx. MNL is a special lisp file, if it's in the same folder as the MNU/CUI/CUIx and has the same name, it gets loaded automatically, as if you listed it for loading in the CUI command. ACAD.LSP is a special lisp file which gets loaded at least once per acad session. Don't use the ACAD20##.LSP file, that's ADesks one and could get overwritten by an update. If you don't have an ACAD.LSP create one for yourself in one of your support folders, note only the first one found will get loaded. ACADDOC.LSP this acts the same as ACAD.LSP but will always be loaded for each DWG opened. Again don't use the ACADDOC20##.LSP. Master Lisp ... I think it's something similar to David's Lib.LSP. Lib.LSP is simple a file created (could be named anything) whioch has all the usual suspects of defuns used inside. That way it's one file to load for all the common stuff. Usually this "Library" would contain helper defuns which is used in other LSP files. The question about if it's good to load everything all the time, is a bit of a "How long is a piece of string" type question. At a guess, I'd say if you have around 100 or less defuns, it's probably not bad just loading them. If you have 1000's you might be better off having a manual load (like David's codes) or using the autoload defun. Best way to know for sure which is best for your case, is to test how long it takes to open your DWG if you load all your LSP files at the start. If it takes noticably longer than when you don't load them all, then you know the answer to the question! You should keep your LSP's in a folder which is on your support path. Preferably a custom folder you created yourself - it just makes upgrades and such a whole lot simpler. There are ways of getting around not having to place your folder on the support paths, but that's quite complex. As a sample my Caddons package reads the folder where the CUI is placed, then loads the LSP from there. Also I've rewritten a version of auaoload so it works with normal defuns instead of just c:CommandName defuns. These codes I've placed into the Caddons.MNL file: http://caddons.svn.sourceforge.net/viewvc/caddons/Caddons.MNL?revision=56&view=markup See the Caddons:Path defun on line 106 for getting the path of the CUI. Then the Caddons:AutoLoad on line 182. This I've done sine the Caddons is meant to be installed as easily as possible - i.e. just load the CUI as partial, nothing else is needed. Quote
khoshravan Posted August 17, 2011 Author Posted August 17, 2011 http://caddons.svn.sourceforge.net/viewvc/caddons/Caddons.MNL?revision=56&view=markup See the Caddons:Path defun on line 106 for getting the path of the CUI. Then the Caddons:AutoLoad on line 182. This I've done sine the Caddons is meant to be installed as easily as possible - i.e. just load the CUI as partial, nothing else is needed. Dear irneb Thanks for your full and complete note. I am intersted in 'CUI issue but I need time to check all of them, and post again if there is an unclear point. I visited the site you mentioned but without looking at the code, what is that site? Is it a place to keep your codes in the Internet?!? Quote
irneb Posted August 18, 2011 Posted August 18, 2011 Dear irnebThanks for your full and complete note. I am intersted in 'CUI issue but I need time to check all of them, and post again if there is an unclear point. I visited the site you mentioned but without looking at the code, what is that site? Is it a place to keep your codes in the Internet?!? No, it's actually a site dedicated to Open Source programs: sourceforge.net. I simply created a project over there called Caddons, which I felt was something I'd like to give to the community (most of my existing codes, redone to be a bit more robust). The page I linked to is the online browser of sourceforge's SVN code repository. SVN (or Source Version Numbering) is a way to share code between several developers and have a way of finding out what was changed in which revision by whom & when. Quote
Recommended Posts
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.