Cleanup before migration to 2007...Your thoughts?

Anonymous · ‎06-06-2006

I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!

Anonymous · ‎06-09-2006

You just made my weekend. That's great stuff, Matt - thanks for sharing! I
smell an AU class...
"Matt Stachoni" wrote in message
news:5201499@discussion.autodesk.com...
On Wed, 7 Jun 2006 18:09:30 +0000, pkirill
wrote:

>I guess, I'm just looking for some creative ideas for minimizing startup
>time.

>Also, for a while I was in the habit of grouping a bunch of similar
>routines
>into one LISP file.

Here's my approach, which works pretty well:

I currently have over 1,000 keyboard macors and utilities which my users use
on
a daily basis. As you can imagine, there's a lot of code that doesn't need
to be
loaded for each DWG file, so I worked to minimize code bloat.

First, I removed almost everything from acaddoc.lsp, opting to load things
externally instead. This was done to more easily manage things granularly
than
have to deal with a source file that's way huge. I can also cut off the
loading
of all customization with a single comment, which is a nice little software
valve to have.

Second, I created many smaller macro libraries, grouping each macro into a
file
named by starting letter, e.g., a.lsp, b.lsp, c.lsp, and so on. This made it
easier to work on macros files instead of having everything in one huge
honkin'
LSP file.

To edit these easily, I have an MEDIT command, that asks for a single letter
character, and the appropriate macros file loads up in my text editor (I
don't
use the VLISP editor except when compiling stuff). So "medit" "m" would load
up
the "m.lsp" source file for editing.

Thirdly, I created many small "support function" libraries, one for each
type of
work it does. For example, here's a partial list:

corelib.lsp - Core global functions (loaded from acaddoc.lsp)
reglib.lsp - registry handling functions
blocklib.lsp - Block handling
entlib.lsp - entity data handling
annotlib.lsp - Annotation (text, dimstyle) handling
dialoglib.lsp - Dialog box functions
filelib.lsp - File handling
geomlib.lsp - Geometry handling
layerlib.lsp - Layer handling

and so on.

The idea here is that each macro uses (and reuses) code from one or more of
these function libraries, instead of having 10 macros which have the same
function defined in the macro code itself. This maximizes code reuse, making
the
overall footprint of the LSP files much smaller.

In my corelib.lsp file, I created "include" functions which checks and loads
the
required function libraries.

For example, (core:IncludeFileLib) will check to see if filelib.lsp is
loaded.
So, in a macro that is going to access files (such as a block insertion
command
macro) I have something like this

;; Insert a file as a block
(defun c:IF ()
;; load required function libraries
(core:IncludeFileLib)
(core:IncludeBlockLib)

(body of code here)
:
:
(princ)
)

That way, the user only loads the support functions when they need them when
the
macro is run for the first time.

After all of this is done, I compile all of the "macro" functions into a
single
"MACROS.VLX" file, and compile each of the smaller function libraries into
their
own VLX files. My startup code only needs to load the single "macros.vlx"
file;
all the support function files are then demand loaded.

I use (autoload) only for some larger command utilities which have their own
dedicated LSP file. Because I have so many command macros, I did not want
the
overhead of a (autoload) function for each one. I would also have to track
thems
in two locations, one as I write the command function, then also create
another
(autoload) statement in the acaddoc.lsp file.

If I could figure out a way to load a set of macros automatically just be
recognizing the first character, that would be cool, so I wouldn't even have
to
compile/load a macros.vlx at all - running the "IF" command would load the
"i.vlx" file and run the command. But that's something for the future...

Because everything is compiled into smaller VLX files, the overhead for
loading
stuff is greatly reduced over the raw LSP code, and provides a means of
securing
the source code, as users have access to compiled VLX files - my LSP source
is
in a separate folder structure with admin-only access rights.

Hope this gives you some ideas.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

> For example we have a bunch of block insertion routines
>that control insertion scale, layering, insert multiple, etc. I put them
>all
>in one BlockInsertion.LSP. Some have upwards of 20 small routines in them.
>I
>think these are part of what's bogging me down and I need to harvest the
>C:XXXX and put those in an autoload list.
>
>
>"David Allen" wrote in message
>news:5197904@discussion.autodesk.com...
>Are you saying that the autoload code is slow?
>What I do in my shortcut key lisp and my menu's is the simple code of
>(defun c:G ()
> (ECHOOFF) (princ "\nMacro >\tGlue: ")
> (if (not c:glue)(load "glue.lsp")) (c:glue)
> (princ)
>)
>
>or in my menu
>^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF
>
>The only code I place in my .mnl is code to place the pulldown menu in the
>list
>I have an acaddoc.lsp that loads my shortcuts, variable settings, config
>and
>a few
>other items that have to run on every drawing.
>
>I too have 4 decipline menu's
>I don't load much code per decipline.
>
>Not sure what else your code could be doing

Anonymous · ‎06-09-2006

I don't know why it would not work from acaddoc.lsp. However, you do have
to load a routine before you can call it so if you are loading and running
"MYLISP" before loading LISPLOG then it won't work... If you are calling
LISPLOG before you call MYLISP and your txt file is not writeable for some
reason, then the MYLISP routine will bomb because LISPLOG bombed...

"SD'y" wrote in message
news:5200576@discussion.autodesk.com...
This is where I am at. I all works ONLY if I load the LISPLOG first then
MYLISP next, after the dwg is open. It does not work using acaddoc.lsp with
them loading in the same order. Why would that be?

"pkirill" wrote in message
news:5200356@discussion.autodesk.com...
Try loading it here:

(defun C:MYLISP ()
(lisplog) ;;********************
(alert "This routine is being logged")
(princ)
)

"SD'y" wrote in message
news:5200299@discussion.autodesk.com...
I actually have it working, kinda. Seems to have something to do with the
order they load. If I go back and forth and reload them a few times it
starts working. Let me play around and see what I can learn. If I do not bet
it I will take you up on your offer. Any insight on the loading order would
be helpful.
Thanks,
S

"pkirill" wrote in message
news:5200250@discussion.autodesk.com...
Can you email me directly with your test LISP and what you modified in the
lisplog code? Just take out the NO SPAM and the spaces in my address...

"SD'y" wrote in message
news:5200040@discussion.autodesk.com...
I am to the point of it creating the log file and that is about it. It is
blank and does not get updated after that. Also, when loading my lisp to
test I get the following:

Command: appload
xxRCL.LSP successfully loaded.
Command: bad argument type: stringp nil
Command:

Any help is appreciated,
Thanks,

"pkirill" wrote in message
news:5199989@discussion.autodesk.com...
Put the code below in a txt file and call it "LISPLOG.LSP". Change "G:/CAD
Standards/LogFiles/" to a location on your network that everyone can write
to. Save it and put that file in your AutoCAD path. Then load the
LISPLOG.LSP file from your ACADDOC.LSP.

In every LISP routine you want to log add a call to (lisplog) - for example:

(defun C:MYLISP ()
(alert "This routine is being logged")
(lisplog)
(princ)
)

Every routine that has (lisplog) in it, writes out to a text file (or csv,
or log, etc.) username, date and routine. Like this:

paulk,6/7/06,(C:QL)
paulk,6/7/06,(C:SCA)
paulk,6/7/06,(C:Q)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:VPL)
paulk,6/7/06,(C:VPU)

I'm sure the data could be organized better, but I didn't want to spend a
bunch of time on it...

"SD'y" wrote in message
news:5199779@discussion.autodesk.com...
Could you explain how this works, or how to use it?
Thanks,

"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)

"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.

"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.

"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!

Anonymous · ‎06-09-2006

I tried it in every possible order. What I found was this. That my lisp,
modified, would not load if lisplog was in the acaddoc, period. I had to put
lisplog in the start up and it all came together.
Thanks,

"pkirill" wrote in message
news:5201863@discussion.autodesk.com...
I don't know why it would not work from acaddoc.lsp. However, you do have
to load a routine before you can call it so if you are loading and running
"MYLISP" before loading LISPLOG then it won't work... If you are calling
LISPLOG before you call MYLISP and your txt file is not writeable for some
reason, then the MYLISP routine will bomb because LISPLOG bombed...

"SD'y" wrote in message
news:5200576@discussion.autodesk.com...
This is where I am at. I all works ONLY if I load the LISPLOG first then
MYLISP next, after the dwg is open. It does not work using acaddoc.lsp with
them loading in the same order. Why would that be?

"pkirill" wrote in message
news:5200356@discussion.autodesk.com...
Try loading it here:

(defun C:MYLISP ()
(lisplog) ;;********************
(alert "This routine is being logged")
(princ)
)

"SD'y" wrote in message
news:5200299@discussion.autodesk.com...
I actually have it working, kinda. Seems to have something to do with the
order they load. If I go back and forth and reload them a few times it
starts working. Let me play around and see what I can learn. If I do not bet
it I will take you up on your offer. Any insight on the loading order would
be helpful.
Thanks,
S

"pkirill" wrote in message
news:5200250@discussion.autodesk.com...
Can you email me directly with your test LISP and what you modified in the
lisplog code? Just take out the NO SPAM and the spaces in my address...

"SD'y" wrote in message
news:5200040@discussion.autodesk.com...
I am to the point of it creating the log file and that is about it. It is
blank and does not get updated after that. Also, when loading my lisp to
test I get the following:

Command: appload
xxRCL.LSP successfully loaded.
Command: bad argument type: stringp nil
Command:

Any help is appreciated,
Thanks,

"pkirill" wrote in message
news:5199989@discussion.autodesk.com...
Put the code below in a txt file and call it "LISPLOG.LSP". Change "G:/CAD
Standards/LogFiles/" to a location on your network that everyone can write
to. Save it and put that file in your AutoCAD path. Then load the
LISPLOG.LSP file from your ACADDOC.LSP.

In every LISP routine you want to log add a call to (lisplog) - for example:

(defun C:MYLISP ()
(alert "This routine is being logged")
(lisplog)
(princ)
)

Every routine that has (lisplog) in it, writes out to a text file (or csv,
or log, etc.) username, date and routine. Like this:

paulk,6/7/06,(C:QL)
paulk,6/7/06,(C:SCA)
paulk,6/7/06,(C:Q)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:VPL)
paulk,6/7/06,(C:VPU)

I'm sure the data could be organized better, but I didn't want to spend a
bunch of time on it...

"SD'y" wrote in message
news:5199779@discussion.autodesk.com...
Could you explain how this works, or how to use it?
Thanks,

"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)

"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.

"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.

"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!

Anonymous · ‎06-12-2006

Its good, but not new right?
Essentially, you are just demand loading whatever is needed instead of all at once.

The fact is, you are loading the main vlx at startup, so this whole subject is whether you are careful to make things
demand load or not.

The reason I say this is because many are not good at vlx, and its intimidating.
You can get the same bang by making your key-ins simply load the code needed.

by the way, I have a vlx that contains lisps with over 50,000 lines of code from dialogs and you name it. Its my own
land desktop program. That vlx loads so fast you don't notice it. So I might say it does not matter how elegent you
are, as long as you put it all in one vlx. The problem is the people that have tons of lisps, and load them all up
front.

Either way, the idea of placing all key-ins in one file, or some set of highly organized files is important. Do not
fragment your life by searching through tons of disorganized files to find what you need to. The method in Matt's post
is great.
I personally have one key-in lisp with about 130 functions defined.
That lisp loads super fast, so the only no-no here is to load a ton of full lisps, instead of just the key-in
"assignments" like (defun c:TM () (load "gtrim.lsp")(c:gtrim))

So when you do the AU class, watch out for some guy with a smile on his face and a USB key in his hand. It might be me
with my key-ins lisp that loads plenty fast and has all the advantages of compiling to vlx (except secrecy for
sure)....or it might be an AVI of my LDT replacement program.

thx

pkirill
|>You just made my weekend. That's great stuff, Matt - thanks for sharing! I
|>smell an AU class...
|>"Matt Stachoni" wrote in message
|>news:5201499@discussion.autodesk.com...
|>On Wed, 7 Jun 2006 18:09:30 +0000, pkirill
|>wrote:
|>
|>>I guess, I'm just looking for some creative ideas for minimizing startup
|>>time.
|>
|>>Also, for a while I was in the habit of grouping a bunch of similar
|>>routines
|>>into one LISP file.
|>
|>Here's my approach, which works pretty well:
|>
|>I currently have over 1,000 keyboard macors and utilities which my users use
|>on
|>a daily basis. As you can imagine, there's a lot of code that doesn't need
|>to be
|>loaded for each DWG file, so I worked to minimize code bloat.
|>
|>First, I removed almost everything from acaddoc.lsp, opting to load things
|>externally instead. This was done to more easily manage things granularly
|>than
|>have to deal with a source file that's way huge. I can also cut off the
|>loading
|>of all customization with a single comment, which is a nice little software
|>valve to have.
|>
|>Second, I created many smaller macro libraries, grouping each macro into a
|>file
|>named by starting letter, e.g., a.lsp, b.lsp, c.lsp, and so on. This made it
|>easier to work on macros files instead of having everything in one huge
|>honkin'
|>LSP file.
|>
|>To edit these easily, I have an MEDIT command, that asks for a single letter
|>character, and the appropriate macros file loads up in my text editor (I
|>don't
|>use the VLISP editor except when compiling stuff). So "medit" "m" would load
|>up
|>the "m.lsp" source file for editing.
|>
|>Thirdly, I created many small "support function" libraries, one for each
|>type of
|>work it does. For example, here's a partial list:
|>
|>corelib.lsp - Core global functions (loaded from acaddoc.lsp)
|>reglib.lsp - registry handling functions
|>blocklib.lsp - Block handling
|>entlib.lsp - entity data handling
|>annotlib.lsp - Annotation (text, dimstyle) handling
|>dialoglib.lsp - Dialog box functions
|>filelib.lsp - File handling
|>geomlib.lsp - Geometry handling
|>layerlib.lsp - Layer handling
|>
|>and so on.
|>
|>The idea here is that each macro uses (and reuses) code from one or more of
|>these function libraries, instead of having 10 macros which have the same
|>function defined in the macro code itself. This maximizes code reuse, making
|>the
|>overall footprint of the LSP files much smaller.
|>
|>In my corelib.lsp file, I created "include" functions which checks and loads
|>the
|>required function libraries.
|>
|>For example, (core:IncludeFileLib) will check to see if filelib.lsp is
|>loaded.
|>So, in a macro that is going to access files (such as a block insertion
|>command
|>macro) I have something like this
|>
|>;; Insert a file as a block
|>(defun c:IF ()
|>;; load required function libraries
|> (core:IncludeFileLib)
|> (core:IncludeBlockLib)
|>
|> (body of code here)
|> :
|> :
|> (princ)
|>)
|>
|>That way, the user only loads the support functions when they need them when
|>the
|>macro is run for the first time.
|>
|>After all of this is done, I compile all of the "macro" functions into a
|>single
|>"MACROS.VLX" file, and compile each of the smaller function libraries into
|>their
|>own VLX files. My startup code only needs to load the single "macros.vlx"
|>file;
|>all the support function files are then demand loaded.
|>
|>I use (autoload) only for some larger command utilities which have their own
|>dedicated LSP file. Because I have so many command macros, I did not want
|>the
|>overhead of a (autoload) function for each one. I would also have to track
|>thems
|>in two locations, one as I write the command function, then also create
|>another
|>(autoload) statement in the acaddoc.lsp file.
|>
|>If I could figure out a way to load a set of macros automatically just be
|>recognizing the first character, that would be cool, so I wouldn't even have
|>to
|>compile/load a macros.vlx at all - running the "IF" command would load the
|>"i.vlx" file and run the command. But that's something for the future...
|>
|>Because everything is compiled into smaller VLX files, the overhead for
|>loading
|>stuff is greatly reduced over the raw LSP code, and provides a means of
|>securing
|>the source code, as users have access to compiled VLX files - my LSP source
|>is
|>in a separate folder structure with admin-only access rights.
|>
|>Hope this gives you some ideas.
|>
|>Matt
|>mstachoni@comcast.net
|>mstachoni@bhhtait.com
|>
|>
|>
|>
|>
|>> For example we have a bunch of block insertion routines
|>>that control insertion scale, layering, insert multiple, etc. I put them
|>>all
|>>in one BlockInsertion.LSP. Some have upwards of 20 small routines in them.
|>>I
|>>think these are part of what's bogging me down and I need to harvest the
|>>C:XXXX and put those in an autoload list.
|>>
|>>
|>>"David Allen" wrote in message
|>>news:5197904@discussion.autodesk.com...
|>>Are you saying that the autoload code is slow?
|>>What I do in my shortcut key lisp and my menu's is the simple code of
|>>(defun c:G ()
|>> (ECHOOFF) (princ "\nMacro >\tGlue: ")
|>> (if (not c:glue)(load "glue.lsp")) (c:glue)
|>> (princ)
|>>)
|>>
|>>or in my menu
|>>^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF
|>>
|>>The only code I place in my .mnl is code to place the pulldown menu in the
|>>list
|>>I have an acaddoc.lsp that loads my shortcuts, variable settings, config
|>>and
|>>a few
|>>other items that have to run on every drawing.
|>>
|>>I too have 4 decipline menu's
|>>I don't load much code per decipline.
|>>
|>>Not sure what else your code could be doing
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-12-2006

On Tue, 13 Jun 2006 00:43:39 +0000, James Maeding
wrote:

>Its good, but not new right?
Nope.

>Essentially, you are just demand loading whatever is needed instead of all at once.
Yep

>The fact is, you are loading the main vlx at startup, so this whole subject is whether you are careful to make things
>demand load or not.
>
>The reason I say this is because many are not good at vlx, and its intimidating.
>You can get the same bang by making your key-ins simply load the code needed.

Not really - there's not really any such thing as being "good" with creating
VLXs - they are simply compiled FAS files. If you go through the motions of
creating Projects, which can then easily create FAS files from the LSP source,
then build VLXs of those FAS files, all you need to do is (a) write code in your
macros files, (b) compile them to FAS files, and (c) build your VLXs.

The point is, once all of the setup work is done in VLisp editor, it's done for
good. All you need to do is code/compile.

>So I might say it does not matter how elegent you are, as long as you put it all in one vlx. The problem is the people that have tons of lisps, and load them all up
>front.

Programming elegance is ALWAYS the key to solid and fast code execution.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

Anonymous · ‎06-13-2006

"Programming elegance is ALWAYS the key to solid and fast code execution."

Yeah, I don't have that...

Anonymous · ‎06-13-2006

Matt,
Don't get me wrong, I'm just like you where the system I use has been refined over years of use.
The reason I asked if it was new was because I figured there would be something that stood out in your mind as a key
difference in how most people handle stuff. I wasn't sure if you felt it was your organization of things, or the fact
that you compiled, or the fact that you demand load.
All of it is good and I'm glad you posted it.

The main point of my post was that if you are afraid of compiling code, you can still get the speed advantage by simply
sticking to the method of demand loading stuff.

As far as elegence goes, I would say that with lisp, you cannot develop large tools unless you are fairly elegent.
You start to get so much duplication of code that its hard to maintain.
Thats a bit off topic, but its the same for your situation. I would say the elegence allows you to maintain your code
efficiently. You can still get the speed by using demand load - although vlx will always be faster.

Don;t you think far fewer people know how to compile than should? Thats why I think some are intimidated, I agree that
its simple though.

Matt Stachoni
|>On Tue, 13 Jun 2006 00:43:39 +0000, James Maeding
|>wrote:
|>
|>>Its good, but not new right?
|>Nope.
|>
|>>Essentially, you are just demand loading whatever is needed instead of all at once.
|>Yep
|>
|>>The fact is, you are loading the main vlx at startup, so this whole subject is whether you are careful to make things
|>>demand load or not.
|>>
|>>The reason I say this is because many are not good at vlx, and its intimidating.
|>>You can get the same bang by making your key-ins simply load the code needed.
|>
|>Not really - there's not really any such thing as being "good" with creating
|>VLXs - they are simply compiled FAS files. If you go through the motions of
|>creating Projects, which can then easily create FAS files from the LSP source,
|>then build VLXs of those FAS files, all you need to do is (a) write code in your
|>macros files, (b) compile them to FAS files, and (c) build your VLXs.
|>
|>The point is, once all of the setup work is done in VLisp editor, it's done for
|>good. All you need to do is code/compile.
|>
|>>So I might say it does not matter how elegent you are, as long as you put it all in one vlx. The problem is the people that have tons of lisps, and load them all up
|>>front.
|>
|>Programming elegance is ALWAYS the key to solid and fast code execution.
|>
|>Matt
|>mstachoni@comcast.net
|>mstachoni@bhhtait.com
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-13-2006

at first I thought this was a logger that used a reactor only.
That would be nice as I dont like adding in the (lisplog) to all my lisps.

so I did this to your code:

(defun setlispname (reactor name / CDATE TMP f)
(setq CDATE (rtos (getvar "cdate") 2 4)
TMP (strcat (getvar "LOGINNAME") "," (strcat (substr CDATE 5 2) "/" (substr CDATE 7 2) "/" (substr CDATE 3 2))
"," (car name))
)
(IF (OR (NOT *LASTLOGSTR*)(/= TMP *LASTLOGSTR*))
(PROGN
(setq f (open (strcat "C:\\TEMP\\" (getvar "LOGINNAME") "_lisplog.txt") "a"))
(write-line TMP f)
(close f)
)
)
(SETQ *LASTLOGSTR* TMP)
(princ)
)

(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))

watch the word wrap on that big strcat line...
This code does not require the (lisplog) function to be added to all lisps, but does have the drawback of capturing ALL
lisp calls, not just those you added the function to.
The trick I did of not logging an entry if it was the same as last time, is necessary as the reactor fires three times
per lisp call. Its no good to have threee duplicate entries every time its adds something.
thx

SD'y
|>Could you explain how this works, or how to use it?
|>Thanks,
|>
|>"pkirill" wrote in message
|>news:5199740@discussion.autodesk.com...
|>Ah - about a year ago I went through all the LISPs we have and inserted a
|>call to another little routine called (lisplog) which rights out the
|>command, date and time, and user to a csv file. I am going through and
|>evaluating a bunch of our routines to see if they aren't being used because
|>they are useles or because no on knows about them...
|>
|>In case anyone wants it, here it is. I can't take full credit as I had help
|>from this NG and the LISP NG for the reactor part...
|>
|>;;;(lisplog) - add this inside any LISP routine you want to log
|>
|>(defun setlispname (reactor name)
|> (setq *lispname* (car name))
|> )
|> (vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
|>(defun lisplog ()
|> (setq *CDATE* (rtos (getvar "cdate") 2 4)
|> YEAR (substr *CDATE* 3 2)
|> MONTH (itoa (atoi (substr *CDATE* 5 2)))
|> DAY (itoa (atoi (substr *CDATE* 7 2)))
|> )
|> (setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
|> (setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
|>"_Lisp.log") "a")
|> )
|> (write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
|> (close f)
|> (princ)
|>)
|>
|>
|>
|>"FG" wrote in message
|>news:5199002@discussion.autodesk.com...
|>Its also a good time to ask everyone which commands are no longer being
|>used. We seem to remove a few each year as autodesk incorporates them into
|>the program.
|>
|>
|>"pkirill" wrote in message
|>news:5198784@discussion.autodesk.com...
|>I don't think it's the "autoload" code spcifically that's slow. I'm looking
|>at the process as a whole. And on the whole, it's too slow for my taste.
|>I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
|>that seems to speed things up a bit. There are also some vba macros that
|>load up into each drawing - why I don't know yet. There seems to be no
|>reason why they can't load when the command is called. I think I can back
|>those out to the mnl's...
|>
|>I guess, I'm just looking for some creative ideas for minimizing startup
|>time. Your shortcut idea is a nice one...
|>
|>Also, for a while I was in the habit of grouping a bunch of similar routines
|>into one LISP file. For example we have a bunch of block insertion routines
|>that control insertion scale, layering, insert multiple, etc. I put them all
|>in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
|>think these are part of what's bogging me down and I need to harvest the
|>C:XXXX and put those in an autoload list.
|>
|>
|>"David Allen" wrote in message
|>news:5197904@discussion.autodesk.com...
|>Are you saying that the autoload code is slow?
|>What I do in my shortcut key lisp and my menu's is the simple code of
|>(defun c:G ()
|> (ECHOOFF) (princ "\nMacro >\tGlue: ")
|> (if (not c:glue)(load "glue.lsp")) (c:glue)
|> (princ)
|>)
|>
|>or in my menu
|>^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF
|>
|>The only code I place in my .mnl is code to place the pulldown menu in the
|>list
|>I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
|>a few
|>other items that have to run on every drawing.
|>
|>I too have 4 decipline menu's
|>I don't load much code per decipline.
|>
|>Not sure what else your code could be doing
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-13-2006

Anonymous · ‎06-13-2006

James, you may have been the one who helped me with the orginal... I went
ahead and added the LISPLOG to the programs i wanted to track as I did not
want to track everything - including all the Express Tools and 3rd party
apps we use that use LISP. I just use it as a tool to help me decide where
to target my efforts and where to just let it go...

What would be sweet is if you could code it so it would oly fire on certain
commands. Like anything that started with X: - like X:MYLISP. Then it would
be like a toggle...

"James Maeding" wrote in message
news:5204578@discussion.autodesk.com...
at first I thought this was a logger that used a reactor only.
That would be nice as I dont like adding in the (lisplog) to all my lisps.

so I did this to your code:

(defun setlispname (reactor name / CDATE TMP f)
(setq CDATE (rtos (getvar "cdate") 2 4)
TMP (strcat (getvar "LOGINNAME") "," (strcat (substr CDATE 5 2) "/"
(substr CDATE 7 2) "/" (substr CDATE 3 2))
"," (car name))
)
(IF (OR (NOT *LASTLOGSTR*)(/= TMP *LASTLOGSTR*))
(PROGN
(setq f (open (strcat "C:\\TEMP\\" (getvar "LOGINNAME")
"_lisplog.txt") "a"))
(write-line TMP f)
(close f)
)
)
(SETQ *LASTLOGSTR* TMP)
(princ)
)

(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))

watch the word wrap on that big strcat line...
This code does not require the (lisplog) function to be added to all lisps,
but does have the drawback of capturing ALL
lisp calls, not just those you added the function to.
The trick I did of not logging an entry if it was the same as last time, is
necessary as the reactor fires three times
per lisp call. Its no good to have threee duplicate entries every time its
adds something.
thx

SD'y
|>Could you explain how this works, or how to use it?
|>Thanks,
|>
|>"pkirill" wrote in message
|>news:5199740@discussion.autodesk.com...
|>Ah - about a year ago I went through all the LISPs we have and inserted a
|>call to another little routine called (lisplog) which rights out the
|>command, date and time, and user to a csv file. I am going through and
|>evaluating a bunch of our routines to see if they aren't being used
because
|>they are useles or because no on knows about them...
|>
|>In case anyone wants it, here it is. I can't take full credit as I had
help
|>from this NG and the LISP NG for the reactor part...
|>
|>;;;(lisplog) - add this inside any LISP routine you want to log
|>
|>(defun setlispname (reactor name)
|> (setq *lispname* (car name))
|> )
|> (vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
|>(defun lisplog ()
|> (setq *CDATE* (rtos (getvar "cdate") 2 4)
|> YEAR (substr *CDATE* 3 2)
|> MONTH (itoa (atoi (substr *CDATE* 5 2)))
|> DAY (itoa (atoi (substr *CDATE* 7 2)))
|> )
|> (setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
|> (setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
|>"_Lisp.log") "a")
|> )
|> (write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
|> (close f)
|> (princ)
|>)
|>
|>
|>
|>"FG" wrote in message
|>news:5199002@discussion.autodesk.com...
|>Its also a good time to ask everyone which commands are no longer being
|>used. We seem to remove a few each year as autodesk incorporates them into
|>the program.
|>
|>
|>"pkirill" wrote in message
|>news:5198784@discussion.autodesk.com...
|>I don't think it's the "autoload" code spcifically that's slow. I'm
looking
|>at the process as a whole. And on the whole, it's too slow for my taste.
|>I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
|>that seems to speed things up a bit. There are also some vba macros that
|>load up into each drawing - why I don't know yet. There seems to be no
|>reason why they can't load when the command is called. I think I can back
|>those out to the mnl's...
|>
|>I guess, I'm just looking for some creative ideas for minimizing startup
|>time. Your shortcut idea is a nice one...
|>
|>Also, for a while I was in the habit of grouping a bunch of similar
routines
|>into one LISP file. For example we have a bunch of block insertion
routines
|>that control insertion scale, layering, insert multiple, etc. I put them
all
|>in one BlockInsertion.LSP. Some have upwards of 20 small routines in them.
I
|>think these are part of what's bogging me down and I need to harvest the
|>C:XXXX and put those in an autoload list.
|>
|>
|>"David Allen" wrote in message
|>news:5197904@discussion.autodesk.com...
|>Are you saying that the autoload code is slow?
|>What I do in my shortcut key lisp and my menu's is the simple code of
|>(defun c:G ()
|> (ECHOOFF) (princ "\nMacro >\tGlue: ")
|> (if (not c:glue)(load "glue.lsp")) (c:glue)
|> (princ)
|>)
|>
|>or in my menu
|>^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF
|>
|>The only code I place in my .mnl is code to place the pulldown menu in the
|>list
|>I have an acaddoc.lsp that loads my shortcuts, variable settings, config
and
|>a few
|>other items that have to run on every drawing.
|>
|>I too have 4 decipline menu's
|>I don't load much code per decipline.
|>
|>Not sure what else your code could be doing
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-13-2006

possibly, but I tend to avoid reactors, and I would have done the code changes I posted.
So I don't get the credit 🙂

You could do filtering quite easily.
What I would do is make a global variable that is a list of the functions I care about.
I might make the list from a text file or something easy to edit, but make the variable global so it does not reread the
text file over and over.
Do a quick (member...) comparison of the function captured and the list, and only log if a match is found.
You want the code for that?

pkirill
|>James, you may have been the one who helped me with the orginal... I went
|>ahead and added the LISPLOG to the programs i wanted to track as I did not
|>want to track everything - including all the Express Tools and 3rd party
|>apps we use that use LISP. I just use it as a tool to help me decide where
|>to target my efforts and where to just let it go...
|>
|>What would be sweet is if you could code it so it would oly fire on certain
|>commands. Like anything that started with X: - like X:MYLISP. Then it would
|>be like a toggle...
|>
|>
|>"James Maeding" wrote in message
|>news:5204578@discussion.autodesk.com...
|>at first I thought this was a logger that used a reactor only.
|>That would be nice as I dont like adding in the (lisplog) to all my lisps.
|>
|>so I did this to your code:
|>
|>(defun setlispname (reactor name / CDATE TMP f)
|> (setq CDATE (rtos (getvar "cdate") 2 4)
|> TMP (strcat (getvar "LOGINNAME") "," (strcat (substr CDATE 5 2) "/"
|>(substr CDATE 7 2) "/" (substr CDATE 3 2))
|>"," (car name))
|> )
|> (IF (OR (NOT *LASTLOGSTR*)(/= TMP *LASTLOGSTR*))
|> (PROGN
|> (setq f (open (strcat "C:\\TEMP\\" (getvar "LOGINNAME")
|>"_lisplog.txt") "a"))
|> (write-line TMP f)
|> (close f)
|> )
|> )
|> (SETQ *LASTLOGSTR* TMP)
|> (princ)
|>)
|>
|>(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
|>
|>watch the word wrap on that big strcat line...
|>This code does not require the (lisplog) function to be added to all lisps,
|>but does have the drawback of capturing ALL
|>lisp calls, not just those you added the function to.
|>The trick I did of not logging an entry if it was the same as last time, is
|>necessary as the reactor fires three times
|>per lisp call. Its no good to have threee duplicate entries every time its
|>adds something.
|>thx
|>
|>
|>SD'y
|>|>Could you explain how this works, or how to use it?
|>|>Thanks,
|>|>
|>|>"pkirill" wrote in message
|>|>news:5199740@discussion.autodesk.com...
|>|>Ah - about a year ago I went through all the LISPs we have and inserted a
|>|>call to another little routine called (lisplog) which rights out the
|>|>command, date and time, and user to a csv file. I am going through and
|>|>evaluating a bunch of our routines to see if they aren't being used
|>because
|>|>they are useles or because no on knows about them...
|>|>
|>|>In case anyone wants it, here it is. I can't take full credit as I had
|>help
|>|>from this NG and the LISP NG for the reactor part...
|>|>
|>|>;;;(lisplog) - add this inside any LISP routine you want to log
|>|>
|>|>(defun setlispname (reactor name)
|>|> (setq *lispname* (car name))
|>|> )
|>|> (vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
|>|>(defun lisplog ()
|>|> (setq *CDATE* (rtos (getvar "cdate") 2 4)
|>|> YEAR (substr *CDATE* 3 2)
|>|> MONTH (itoa (atoi (substr *CDATE* 5 2)))
|>|> DAY (itoa (atoi (substr *CDATE* 7 2)))
|>|> )
|>|> (setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
|>|> (setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
|>|>"_Lisp.log") "a")
|>|> )
|>|> (write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
|>|> (close f)
|>|> (princ)
|>|>)
|>|>
|>|>
|>|>
|>|>"FG" wrote in message
|>|>news:5199002@discussion.autodesk.com...
|>|>Its also a good time to ask everyone which commands are no longer being
|>|>used. We seem to remove a few each year as autodesk incorporates them into
|>|>the program.
|>|>
|>|>
|>|>"pkirill" wrote in message
|>|>news:5198784@discussion.autodesk.com...
|>|>I don't think it's the "autoload" code spcifically that's slow. I'm
|>looking
|>|>at the process as a whole. And on the whole, it's too slow for my taste.
|>|>I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
|>|>that seems to speed things up a bit. There are also some vba macros that
|>|>load up into each drawing - why I don't know yet. There seems to be no
|>|>reason why they can't load when the command is called. I think I can back
|>|>those out to the mnl's...
|>|>
|>|>I guess, I'm just looking for some creative ideas for minimizing startup
|>|>time. Your shortcut idea is a nice one...
|>|>
|>|>Also, for a while I was in the habit of grouping a bunch of similar
|>routines
|>|>into one LISP file. For example we have a bunch of block insertion
|>routines
|>|>that control insertion scale, layering, insert multiple, etc. I put them
|>all
|>|>in one BlockInsertion.LSP. Some have upwards of 20 small routines in them.
|>I
|>|>think these are part of what's bogging me down and I need to harvest the
|>|>C:XXXX and put those in an autoload list.
|>|>
|>|>
|>|>"David Allen" wrote in message
|>|>news:5197904@discussion.autodesk.com...
|>|>Are you saying that the autoload code is slow?
|>|>What I do in my shortcut key lisp and my menu's is the simple code of
|>|>(defun c:G ()
|>|> (ECHOOFF) (princ "\nMacro >\tGlue: ")
|>|> (if (not c:glue)(load "glue.lsp")) (c:glue)
|>|> (princ)
|>|>)
|>|>
|>|>or in my menu
|>|>^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF
|>|>
|>|>The only code I place in my .mnl is code to place the pulldown menu in the
|>|>list
|>|>I have an acaddoc.lsp that loads my shortcuts, variable settings, config
|>and
|>|>a few
|>|>other items that have to run on every drawing.
|>|>
|>|>I too have 4 decipline menu's
|>|>I don't load much code per decipline.
|>|>
|>|>Not sure what else your code could be doing
|>James Maeding
|>Civil Engineer and Programmer
|>jmaeding - athunsaker - com
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-13-2006

woo hold on. I missed the post. What exactly is this code supposed to do?
James pls explain more

--
Dave

"James Maeding" wrote in message
news:5204578@discussion.autodesk.com...
at first I thought this was a logger that used a reactor only.
That would be nice as I dont like adding in the (lisplog) to all my lisps.

so I did this to your code:

(defun setlispname (reactor name / CDATE TMP f)
(setq CDATE (rtos (getvar "cdate") 2 4)
TMP (strcat (getvar "LOGINNAME") "," (strcat (substr CDATE 5 2) "/"
(substr CDATE 7 2) "/" (substr CDATE 3 2))
"," (car name))
)
(IF (OR (NOT *LASTLOGSTR*)(/= TMP *LASTLOGSTR*))
(PROGN
(setq f (open (strcat "C:\\TEMP\\" (getvar "LOGINNAME")
"_lisplog.txt") "a"))
(write-line TMP f)
(close f)
)
)
(SETQ *LASTLOGSTR* TMP)
(princ)
)

(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))

watch the word wrap on that big strcat line...
This code does not require the (lisplog) function to be added to all lisps,
but does have the drawback of capturing ALL
lisp calls, not just those you added the function to.
The trick I did of not logging an entry if it was the same as last time, is
necessary as the reactor fires three times
per lisp call. Its no good to have threee duplicate entries every time its
adds something.
thx

SD'y
|>Could you explain how this works, or how to use it?
|>Thanks,
|>
|>"pkirill" wrote in message
|>news:5199740@discussion.autodesk.com...
|>Ah - about a year ago I went through all the LISPs we have and inserted a
|>call to another little routine called (lisplog) which rights out the
|>command, date and time, and user to a csv file. I am going through and
|>evaluating a bunch of our routines to see if they aren't being used
because
|>they are useles or because no on knows about them...
|>
|>In case anyone wants it, here it is. I can't take full credit as I had
help
|>from this NG and the LISP NG for the reactor part...
|>
|>;;;(lisplog) - add this inside any LISP routine you want to log
|>
|>(defun setlispname (reactor name)
|> (setq *lispname* (car name))
|> )
|> (vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
|>(defun lisplog ()
|> (setq *CDATE* (rtos (getvar "cdate") 2 4)
|> YEAR (substr *CDATE* 3 2)
|> MONTH (itoa (atoi (substr *CDATE* 5 2)))
|> DAY (itoa (atoi (substr *CDATE* 7 2)))
|> )
|> (setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
|> (setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
|>"_Lisp.log") "a")
|> )
|> (write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
|> (close f)
|> (princ)
|>)
|>
|>
|>
|>"FG" wrote in message
|>news:5199002@discussion.autodesk.com...
|>Its also a good time to ask everyone which commands are no longer being
|>used. We seem to remove a few each year as autodesk incorporates them into
|>the program.
|>
|>
|>"pkirill" wrote in message
|>news:5198784@discussion.autodesk.com...
|>I don't think it's the "autoload" code spcifically that's slow. I'm
looking
|>at the process as a whole. And on the whole, it's too slow for my taste.
|>I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
|>that seems to speed things up a bit. There are also some vba macros that
|>load up into each drawing - why I don't know yet. There seems to be no
|>reason why they can't load when the command is called. I think I can back
|>those out to the mnl's...
|>
|>I guess, I'm just looking for some creative ideas for minimizing startup
|>time. Your shortcut idea is a nice one...
|>
|>Also, for a while I was in the habit of grouping a bunch of similar
routines
|>into one LISP file. For example we have a bunch of block insertion
routines
|>that control insertion scale, layering, insert multiple, etc. I put them
all
|>in one BlockInsertion.LSP. Some have upwards of 20 small routines in them.
I
|>think these are part of what's bogging me down and I need to harvest the
|>C:XXXX and put those in an autoload list.
|>
|>
|>"David Allen" wrote in message
|>news:5197904@discussion.autodesk.com...
|>Are you saying that the autoload code is slow?
|>What I do in my shortcut key lisp and my menu's is the simple code of
|>(defun c:G ()
|> (ECHOOFF) (princ "\nMacro >\tGlue: ")
|> (if (not c:glue)(load "glue.lsp")) (c:glue)
|> (princ)
|>)
|>
|>or in my menu
|>^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF
|>
|>The only code I place in my .mnl is code to place the pulldown menu in the
|>list
|>I have an acaddoc.lsp that loads my shortcuts, variable settings, config
and
|>a few
|>other items that have to run on every drawing.
|>
|>I too have 4 decipline menu's
|>I don't load much code per decipline.
|>
|>Not sure what else your code could be doing
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-14-2006

I'd love the code for that. That would really make it a flexible tool...

Thanks!

Paul

"James Maeding" wrote in message
news:5205236@discussion.autodesk.com...
possibly, but I tend to avoid reactors, and I would have done the code
changes I posted.
So I don't get the credit 🙂

You could do filtering quite easily.
What I would do is make a global variable that is a list of the functions I
care about.
I might make the list from a text file or something easy to edit, but make
the variable global so it does not reread the
text file over and over.
Do a quick (member...) comparison of the function captured and the list, and
only log if a match is found.
You want the code for that?

pkirill
|>James, you may have been the one who helped me with the orginal... I went
|>ahead and added the LISPLOG to the programs i wanted to track as I did not
|>want to track everything - including all the Express Tools and 3rd party
|>apps we use that use LISP. I just use it as a tool to help me decide where
|>to target my efforts and where to just let it go...
|>
|>What would be sweet is if you could code it so it would oly fire on
certain
|>commands. Like anything that started with X: - like X:MYLISP. Then it
would
|>be like a toggle...
|>
|>
|>"James Maeding" wrote in message
|>news:5204578@discussion.autodesk.com...
|>at first I thought this was a logger that used a reactor only.
|>That would be nice as I dont like adding in the (lisplog) to all my lisps.
|>
|>so I did this to your code:
|>
|>(defun setlispname (reactor name / CDATE TMP f)
|> (setq CDATE (rtos (getvar "cdate") 2 4)
|> TMP (strcat (getvar "LOGINNAME") "," (strcat (substr CDATE 5 2)
"/"
|>(substr CDATE 7 2) "/" (substr CDATE 3 2))
|>"," (car name))
|> )
|> (IF (OR (NOT *LASTLOGSTR*)(/= TMP *LASTLOGSTR*))
|> (PROGN
|> (setq f (open (strcat "C:\\TEMP\\" (getvar "LOGINNAME")
|>"_lisplog.txt") "a"))
|> (write-line TMP f)
|> (close f)
|> )
|> )
|> (SETQ *LASTLOGSTR* TMP)
|> (princ)
|>)
|>
|>(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
|>
|>watch the word wrap on that big strcat line...
|>This code does not require the (lisplog) function to be added to all
lisps,
|>but does have the drawback of capturing ALL
|>lisp calls, not just those you added the function to.
|>The trick I did of not logging an entry if it was the same as last time,
is
|>necessary as the reactor fires three times
|>per lisp call. Its no good to have threee duplicate entries every time
its
|>adds something.
|>thx
|>
|>
|>SD'y
|>|>Could you explain how this works, or how to use it?
|>|>Thanks,
|>|>
|>|>"pkirill" wrote in message
|>|>news:5199740@discussion.autodesk.com...
|>|>Ah - about a year ago I went through all the LISPs we have and inserted
a
|>|>call to another little routine called (lisplog) which rights out the
|>|>command, date and time, and user to a csv file. I am going through and
|>|>evaluating a bunch of our routines to see if they aren't being used
|>because
|>|>they are useles or because no on knows about them...
|>|>
|>|>In case anyone wants it, here it is. I can't take full credit as I had
|>help
|>|>from this NG and the LISP NG for the reactor part...
|>|>
|>|>;;;(lisplog) - add this inside any LISP routine you want to log
|>|>
|>|>(defun setlispname (reactor name)
|>|> (setq *lispname* (car name))
|>|> )
|>|> (vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
|>|>(defun lisplog ()
|>|> (setq *CDATE* (rtos (getvar "cdate") 2 4)
|>|> YEAR (substr *CDATE* 3 2)
|>|> MONTH (itoa (atoi (substr *CDATE* 5 2)))
|>|> DAY (itoa (atoi (substr *CDATE* 7 2)))
|>|> )
|>|> (setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
|>|> (setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar
"LOGINNAME")
|>|>"_Lisp.log") "a")
|>|> )
|>|> (write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*)
f)
|>|> (close f)
|>|> (princ)
|>|>)
|>|>
|>|>
|>|>
|>|>"FG" wrote in message
|>|>news:5199002@discussion.autodesk.com...
|>|>Its also a good time to ask everyone which commands are no longer being
|>|>used. We seem to remove a few each year as autodesk incorporates them
into
|>|>the program.
|>|>
|>|>
|>|>"pkirill" wrote in message
|>|>news:5198784@discussion.autodesk.com...
|>|>I don't think it's the "autoload" code spcifically that's slow. I'm
|>looking
|>|>at the process as a whole. And on the whole, it's too slow for my taste.
|>|>I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
|>|>that seems to speed things up a bit. There are also some vba macros that
|>|>load up into each drawing - why I don't know yet. There seems to be no
|>|>reason why they can't load when the command is called. I think I can
back
|>|>those out to the mnl's...
|>|>
|>|>I guess, I'm just looking for some creative ideas for minimizing startup
|>|>time. Your shortcut idea is a nice one...
|>|>
|>|>Also, for a while I was in the habit of grouping a bunch of similar
|>routines
|>|>into one LISP file. For example we have a bunch of block insertion
|>routines
|>|>that control insertion scale, layering, insert multiple, etc. I put them
|>all
|>|>in one BlockInsertion.LSP. Some have upwards of 20 small routines in
them.
|>I
|>|>think these are part of what's bogging me down and I need to harvest the
|>|>C:XXXX and put those in an autoload list.
|>|>
|>|>
|>|>"David Allen" wrote in message
|>|>news:5197904@discussion.autodesk.com...
|>|>Are you saying that the autoload code is slow?
|>|>What I do in my shortcut key lisp and my menu's is the simple code of
|>|>(defun c:G ()
|>|> (ECHOOFF) (princ "\nMacro >\tGlue: ")
|>|> (if (not c:glue)(load "glue.lsp")) (c:glue)
|>|> (princ)
|>|>)
|>|>
|>|>or in my menu
|>|>^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF
|>|>
|>|>The only code I place in my .mnl is code to place the pulldown menu in
the
|>|>list
|>|>I have an acaddoc.lsp that loads my shortcuts, variable settings, config
|>and
|>|>a few
|>|>other items that have to run on every drawing.
|>|>
|>|>I too have 4 decipline menu's
|>|>I don't load much code per decipline.
|>|>
|>|>Not sure what else your code could be doing
|>James Maeding
|>Civil Engineer and Programmer
|>jmaeding - athunsaker - com
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-14-2006

it sets up a reactor to log lisp function calls
so if I type M it logs that as (c:M) in some text file.
I might make it so it filters and only logs ones you want.
Its not that great if you ask me because I am interested in the lisp files AND functions.
So I'd be more interested in a tool that logged what lsp, vlx, arx...files got loaded, so I can archive ones that never
get used.

David Allen
|>woo hold on. I missed the post. What exactly is this code supposed to do?
|>James pls explain more
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-14-2006

On Tue, 13 Jun 2006 16:25:51 +0000, James Maeding
wrote:

>The reason I asked if it was new was because I figured there would be something that stood out in your mind as a key
>difference in how most people handle stuff. I wasn't sure if you felt it was your organization of things, or the fact
>that you compiled, or the fact that you demand load.

I think it's more of the demand load mechanism I use. But I dunno - lots of
people could be doing this. I've never seen it dicussed on the customization NG.
but I'm in and out of there.

>The main point of my post was that if you are afraid of compiling code, you can still get the speed advantage by simply
>sticking to the method of demand loading stuff.

You get SOME advantage through compilation. My point was that if the source code
is elegant (i.e., able to do lots of stuff in a logical fashion) then the
comiled code will be that much more efficient.

>You can still get the speed by using demand load - although vlx will always be faster.

You gain speed on initial DWG file startup, because you aren't loading stuff
that doesn't need to be loaded (yet). In return, you lose some on the first run
of the program, as the extra code libraries are loaded. It's a trade off.

But, compiled or not, programming statements that do "dumb," inelegant things
(like constantly performing needless I/O file opening) will be slow.

It should be also noted that even "elegant" streamlined code will sometimes
execute slower than more verbose code. You always have to look at what the
interpreter is doing behind the scenes for the task at hand. That just takes
experience.

>Don't you think far fewer people know how to compile than should? Thats why I think some are intimidated, I agree that
>its simple though.

I don't know - I've never queried people on compiling to VLXs. I think a lot of
people who do a lot fo customization have moved to using VBA for much of their
work.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

Anonymous · ‎06-14-2006

Well what I was thinking of doing was putting a function into each of the
keyins to do the logging
For example all my keyins have a ECHOOFF function

(defun C:1 () (ECHOOFF)(princ "\nOffset 1'")

So I could just add to that function or search and replace.

I never thought about the reactor idea before

--
Dave

"James Maeding" wrote in message
news:5206205@discussion.autodesk.com...
it sets up a reactor to log lisp function calls
so if I type M it logs that as (c:M) in some text file.
I might make it so it filters and only logs ones you want.
Its not that great if you ask me because I am interested in the lisp files
AND functions.
So I'd be more interested in a tool that logged what lsp, vlx, arx...files
got loaded, so I can archive ones that never
get used.

David Allen
|>woo hold on. I missed the post. What exactly is this code supposed to
do?
|>James pls explain more
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-15-2006

You caught my attention with that last statement - using VBA.
I cannot help but feel inside that somehow, VBA is not going to be around as long as I like.
We are already seeing vba.net under development, I wonder what will happen to VBA?
That being said, my use of ODCL and lisp is even more fragile - but also more powerful (IMO of course...)
I have done modeless dialogs with lisp and ODCL that VBA does not do well.
Its probably just my lack of pursuing VBA as much as I have lisp.
I just keep thinking that using .net is way better than moving to VBA, its going slow so far though.
We need more open source .net tools so we can learn the patterns better.

Matt Stachoni
|>On Tue, 13 Jun 2006 16:25:51 +0000, James Maeding
|>wrote:
|>
|>>The reason I asked if it was new was because I figured there would be something that stood out in your mind as a key
|>>difference in how most people handle stuff. I wasn't sure if you felt it was your organization of things, or the fact
|>>that you compiled, or the fact that you demand load.
|>
|>I think it's more of the demand load mechanism I use. But I dunno - lots of
|>people could be doing this. I've never seen it dicussed on the customization NG.
|>but I'm in and out of there.
|>
|>>The main point of my post was that if you are afraid of compiling code, you can still get the speed advantage by simply
|>>sticking to the method of demand loading stuff.
|>
|>You get SOME advantage through compilation. My point was that if the source code
|>is elegant (i.e., able to do lots of stuff in a logical fashion) then the
|>comiled code will be that much more efficient.
|>
|>>You can still get the speed by using demand load - although vlx will always be faster.
|>
|>You gain speed on initial DWG file startup, because you aren't loading stuff
|>that doesn't need to be loaded (yet). In return, you lose some on the first run
|>of the program, as the extra code libraries are loaded. It's a trade off.
|>
|>But, compiled or not, programming statements that do "dumb," inelegant things
|>(like constantly performing needless I/O file opening) will be slow.
|>
|>It should be also noted that even "elegant" streamlined code will sometimes
|>execute slower than more verbose code. You always have to look at what the
|>interpreter is doing behind the scenes for the task at hand. That just takes
|>experience.
|>
|>>Don't you think far fewer people know how to compile than should? Thats why I think some are intimidated, I agree that
|>>its simple though.
|>
|>I don't know - I've never queried people on compiling to VLXs. I think a lot of
|>people who do a lot fo customization have moved to using VBA for much of their
|>work.
|>
|>Matt
|>mstachoni@comcast.net
|>mstachoni@bhhtait.com
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Anonymous · ‎06-15-2006

Well, .Net is truly a solid future in Windows app development; I wish I knew
more about it myself. From people I know who do, it seems that "normal" VBA is
pretty much going to die out in the future. But, like Vlisp, it will definitely
stick around for a long time to come. programming languages, like old habits,
die hard.

I've found that I can get by pretty well without resorting to VBA for many
things, because I can code much faster in Vlisp due to sheer experience. But
once I need to develop something with an actual User Interface, it's off to VBA
for that.

You can always code huge portions of your app in VLisp for speed or whatever
reason, then call up a VBA form for the UI and pass data between them, so you
can get the best of both worlds.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com

On Thu, 15 Jun 2006 15:56:57 +0000, James Maeding
wrote:

>You caught my attention with that last statement - using VBA.
>I cannot help but feel inside that somehow, VBA is not going to be around as long as I like.
>We are already seeing vba.net under development, I wonder what will happen to VBA?
>That being said, my use of ODCL and lisp is even more fragile - but also more powerful (IMO of course...)
>I have done modeless dialogs with lisp and ODCL that VBA does not do well.
>Its probably just my lack of pursuing VBA as much as I have lisp.
>I just keep thinking that using .net is way better than moving to VBA, its going slow so far though.
>We need more open source .net tools so we can learn the patterns better.

Anonymous · ‎07-03-2006

I know the hybrid approach is tempting, but its not good for modeless forms.
That is where .net (or ODCL if it was available) is totally the way to go.
If it were my choice, I'd prefer ODCL to continue on. Lisp is just so easy to code with. I just did a section cutting
routine the other day that had some fancy command line input stuff. The grread function is so nice for allowing typing
or picking of an entity. VBA can't do that from what I have seen.

Matt Stachoni
|>Well, .Net is truly a solid future in Windows app development; I wish I knew
|>more about it myself. From people I know who do, it seems that "normal" VBA is
|>pretty much going to die out in the future. But, like Vlisp, it will definitely
|>stick around for a long time to come. programming languages, like old habits,
|>die hard.
|>
|>I've found that I can get by pretty well without resorting to VBA for many
|>things, because I can code much faster in Vlisp due to sheer experience. But
|>once I need to develop something with an actual User Interface, it's off to VBA
|>for that.
|>
|>You can always code huge portions of your app in VLisp for speed or whatever
|>reason, then call up a VBA form for the UI and pass data between them, so you
|>can get the best of both worlds.
|>
|>Matt
|>mstachoni@comcast.net
|>mstachoni@bhhtait.com
|>
|>
|>On Thu, 15 Jun 2006 15:56:57 +0000, James Maeding
|>wrote:
|>
|>>You caught my attention with that last statement - using VBA.
|>>I cannot help but feel inside that somehow, VBA is not going to be around as long as I like.
|>>We are already seeing vba.net under development, I wonder what will happen to VBA?
|>>That being said, my use of ODCL and lisp is even more fragile - but also more powerful (IMO of course...)
|>>I have done modeless dialogs with lisp and ODCL that VBA does not do well.
|>>Its probably just my lack of pursuing VBA as much as I have lisp.
|>>I just keep thinking that using .net is way better than moving to VBA, its going slow so far though.
|>>We need more open source .net tools so we can learn the patterns better.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

Cleanup before migration to 2007...Your thoughts?

Forums Links

Post to forums