Is there a way to remove all .lsp from the startup suite via lisp?

[Lee Mac]

Have you tried AutoLoader?

If I keep this up, I might as well have a sales position... Just saying. LoL

 

lmao, cheers Renderman

 

i try to omit using "load" beacuse this may slow down opening autocad/new dwg

 

Kruuger, just to clarify, the program suggested by Renderman will create 'autoload' expressions, which enable functions to be demand-loaded (loaded when required).

 

@ Irneb & Lee - Great job guys; it's educational to see your problem solving unfold.

 

Cheers Renderman, it was mostly Irné but I'll lend a hand here and there

[Guest kruuger]

Kruuger, just to clarify, the program suggested by Renderman will create 'autoload' expressions, which enable functions to be demand-loaded (loaded when required).

i know but my mnl was created a years ago. only from time to time i add new lisp and resend to all pc's

can't use autoloader because some of files from folder needs to be load at startup.

maybe it's time to cleanup

k.

[irneb]

Thanks for the kudos, though I'm just extrapolating from other posts. :wink:

[Jeff H]

When you guys worry about not loading too many .lsp files is because of what the interpreter can handle or is it the memory for the application(AutoCAD)?

 

 

Or was it a issue in the past and newer hardware make it less of a problem?

 

Like one of the decisions for lisp was for it to fit in 64K

AutoCAD's architecture & APIs

 

We've talked a little about Variables and Expressions, already. What was behind the decision to use Lisp as a language?

Well, that's interesting. I would say, as much as anything, opportunity. We had this menu macro language, and that clearly had gone as far as it could go. We needed something that would provide access to the database. We needed something that could actually do algorithmic operations needed in writing the program. And it had to fit in 64K. It had to fit in a 64K segment, basically, and it had to fit - with that 64K segment - in a 640K IBM PC environment. Along with all the rest of AutoCAD, which at that point was hideously overlaid just to squeeze AutoCAD - alone - into that environment. Now a whole programming language had to go in there.

 

LINK

Edited August 6, 2011 by Jeff H

[irneb]

These days it's no big issue regarding ram anymore. The problem now is that it takes time to load those lisps. And in general LSP's need to be loaded for each DWG opened. So the more LSP's you have loading the longer it takes to open a file - especially if there are errors in some of those LSPs. Usually "compiling" them to FAS/VLX makes them load (and run) faster though, but it's not as if there's no loading time when you do so.

[Jeff H]

You should be using this.

And take the time if your not familiar.

 

Starting with 2012 a great thing for deploying and loading your app is the plug-in auto loader.

PerDocument

AutoLISP only - When True, the AutoLISP file is loaded once per document. Default is True.

For 2012 search for AppAutoLoader in help files.

 

Here is some things it will control for you

LINK

 

 

Video showing advantages

VIDEO

 

 

I stole one of Lee's routines from his website for a example

also could add a cuix file for Ribbon and to link his commands with ballon or bubble help

 

<?xml version="1.0" encoding="utf-8"?>
<ApplicationPackage SchemaVersion="1.0" AppVersion="1.0" Author="Yo Mama"
   Name="Mud Butt" Icon="./Contents/Resources/ringtones.ico"
   Helpfile="./Contents/Help/AlignTexttoCurve.htm"
ProductCode="{EE75CF25-CB7F-4CA0-98FF-6D9147DC12BE}">
 <CompanyDetails
   Name="Dog Farts"
   Phone="1 (555)-415-1234"
   PhoneEsp="34 5554 151234"
   Url="[url]http://lee-mac.com/index.html[/url]"
   UrlEsp="[url="http://www.abcindoorcad.es"]www.abcindoorcad.es[/url]"
   Email="[email="support@goFuckYourself.com"]support@goFuckYourself.com[/email]">
   </CompanyDetails>
 <Components>
   <RuntimeRequirements SupportPath="./Contents/Support" OS="Win32|Win64" SeriesMin="R17"/>
   <ComponentEntry
   AppName="LeeAlignCurve"
   ModuleName="./Contents/LeesApp/LeeCurvedAlignedText.lsp"
     AppDescription="poop"
     PerDocument="True">
             <Commands>
<Command Global="CurveAlignedText" Local="CurveAlignedText"/>
       </Commands>
   </ComponentEntry>
 </Components>


   <Components>
   <RuntimeRequirements SupportPath="./Contents/Support" OS="Win32|Win64" SeriesMin="R17"/>
   <ComponentEntry
   AppName="Example"
   ModuleName="./Contents/Example/ExampleLoad.lsp"
     AppDescription="fart"
     PerDocument="True">
             <Commands>
<Command Global="ExampleLoad" Local="ExampleLoad"/>
       </Commands>
   </ComponentEntry>
 </Components>

</ApplicationPackage>

Example.bundle.zip

[Jeff H]

Here is one with Lisp example

 

 

http://download.autodesk.com/media/adn/DevTV_Autoloader_Format_Explained/DevTV_Autoloader_Format_Explained.html

[irneb]

Thanks for the links Jeff. I suppose ADesk is trying to go the route of Mozilla - this is very similar to the install.RDF file inside FireFox's Extension package (those XPI zip files).

 

I just don't like the idea that it installs the "plugin" to the user and version specific folder. IMO you only want that in some cases, usually you'd want to install on all versions for all users on the PC (probably even to a server share to all users on all PCs - i.e. included into the Enterprise CUIx). Is there a setting to have it install to a custom folder (or at least an option to be checked during install)?

[BlackBox]

Usually "compiling" them to FAS/VLX makes them load (and run) faster though, but it's not as if there's no loading time when you do so.

 

I've been subscribing to FAS for some time... but using FAS/VLX still dumps the lot (of compiled code) into memory, instead of demand loading the called sub-component of the compiled code, correct?

[irneb]

I've been subscribing to FAS for some time... but using FAS/VLX still dumps the lot (of compiled code) into memory, instead of demand loading the called sub-component of the compiled code, correct?

Yes, the FAS is exactly the same idea as loading a normal LSP (though it's a bit optimized and bit-code compiled - so possibly uses less RAM).

 

The VLX is basically one/more FAS in a package together with any resource files (e.g. DCL). The resources gets "extracted" from the package on the fly - as if they get placed into the support folders, so you can use normal load-dialog (and such) on them.

 

But both would simply load all code into RAM in one go, not like a "dynamic" portion-loaded linked library. Actually there's very few OS's where you get a DLL/SH/etc. dynamic library only loading partially, mostly this was only done in old OS's where there was severe restrictions on RAM size. This is one of the reasons I prefer splitting my LSP's into several separate files instead of one. Then have some form of "auto"-load per file only when needed, i.e. only when the command is issued. There's actually very few addons where I have to load it at DWG-open (e.g. my SelectResult routine needs to load at drawing open, since it instantiates a command reactor, but my AutoIncr only loads once one of the commands inside gets called). That way I keep the extra-load at opening time to a bare minimum, and leave the rest for the first command invocation.

 

It's a bit complex going through it all, but I've also written a helper utility to "automate" the process: http://caddons.svn.sourceforge.net/viewvc/caddons/Libraries/MenuHelp.LSP?revision=55&view=markup

[BlackBox]

Yes, the FAS is exactly the same idea as loading a normal LSP (though it's a bit optimized and bit-code compiled - so possibly uses less RAM).

 

Thought so... As I've said before, since I've only been coding for a year+ I started out with very little code, so direct load wasn't an issue memory wise. Not that I feel it (loading 3-FAS) is an issue today, I'm simply critiquing my methodology moving forward.

 

For example, I'm adopting 'demand loading' via the registry with my (limited) .NET development.

 

This is one of the reasons I prefer splitting my LSP's into several separate files instead of one. Then have some form of "auto"-load per file only when needed, i.e. only when the command is issued.

 

I've started looking at Lee's Autoloader, but this is the first time I've heard of the function you linked. I'll have to give it a look-see.

[irneb]

Actually the one I'm using is a bit more complex than the standard AutoLoad. It allows for autoloading on not just commands but normal lisp functions as well. Though it's written a bit specific for the Caddons extension, the idea can be ported to other places as well.

 

See from line 180 here: http://caddons.svn.sourceforge.net/viewvc/caddons/Caddons.MNL?revision=55&view=markup

 

What it does is create a minimalist defun on the fly for each function listed to be autoloaded from the file. All that this minimalist defun does is load it's source file and then run itself (as it would have been overwritten due to the load). So if it's not a huge defun / LSP the space saving is negligible, speedwise it "might" be a bit faster on opening DWGs - though also barely noticeable. It's when your LSP's are huge (some 100's if not 1000's of lines each) that the benefit of this method comes to play.

 

BTW, the standard autoload function does much the same, though it adds that "Initializing ..." message and does some extra error checking (which I think is overkill to place inside these minimalist / temporary defuns - you could do the error checking while defining the defun instead of writing it into the defun). Also, with all the error checking in the standard, you can end up in situations where there's an endless loop of "Initializing...", one of these situations where someone went a bit overboard with complexity and actually made it less useful! Not so with mine ... since it just stops in such cases. I also don't "clutter" the commandline with useless messages: IMO the user doesn't want to know that the addon has loaded, he might want to know if something went wrong!

[Lee Mac]

What it does is create a minimalist defun on the fly for each function listed to be autoloaded from the file. All that this minimalist defun does is load it's source file and then run itself (as it would have been overwritten due to the load).

 

You might also be interested in this thread from theSwamp wherein a similar method is discussed.

 

Also, with all the error checking in the standard, you can end up in situations where there's an endless loop of "Initializing...", one of these situations where someone went a bit overboard with complexity and actually made it less useful!

 

I'm not certain, but I believe the endless loop is caused by having a file in the support path with the same name as the file you are trying to load, but with a different function definition than that appearing in the command list. I've noticed this same behaviour with the acet-autoload2 function loading Express Tools: see this post onwards (may require membership).

 

Also, there is another bug with the autoload function: since the loader subfunction is constructed using a concatenation of strings, followed by a read/eval expression, extra backslashes are not added when the filename contains backslashes, resulting in an incorrect filename and the LISP file not being loaded.

[Jeff H]

Thanks for the links Jeff. I suppose ADesk is trying to go the route of Mozilla - this is very similar to the install.RDF file inside FireFox's Extension package (those XPI zip files).

 

I just don't like the idea that it installs the "plugin" to the user and version specific folder. IMO you only want that in some cases, usually you'd want to install on all versions for all users on the PC (probably even to a server share to all users on all PCs - i.e. included into the Enterprise CUIx). Is there a setting to have it install to a custom folder (or at least an option to be checked during install)?

 

When you install it you can specify all versions, min or max version for it to apply to.

 

Also you can put it C/ProgramFiles/Auodesk/Pluginns

 

To apply to all users