Topic: 15+ Years of Clutter Cleanup Required

[RocksterB]

After multiple mergers and CAD managers, it's time to cleanup 15 years of code clutter. Lisp, VBA and .NET codes created by past employees need to be consolidated. It seems in some instances, directories of data have been carried along for years because new tools intertwine with data in old directories. I've even found a folder of dialog box slides (SLD).  When’s the last time you used the MSLIDE command? What I need is a way to trace the resources of these custom DCL, VBA, lisp, SLD, etc., so I can consolidate them and get rid of the all the unused dust bunnies. The preferred way to do this is to first start a tracer routine and thereafter, any command I run appends a list of resource names & paths to a log file. Even better would if the routine would collect the actual files for me. Has anyone seen routine that can do something like this?

[CAB]

I still use a few slides.

Lisp logging:
http://www.theswamp.org/index.php?topic=1695.0
http://www.theswamp.org/index.php?topic=39921.0

Your task can be quite tedious but these loggers may help.

Each DCL can be traced to a lisp if the lisp is not compiled.
Slides too can be traced that way.
The lisp to do that may exist as well.
I'll look tomorrow if I get some free time.

Another approach would be to save all to a backup drive & then delete all.
Each time you get an error , restore the files needed. Still a tedious job.

[dgorsman]

Another approach would be to save all to a backup drive & then delete all.
Each time you get an error , restore the files needed. Still a tedious job.

+1.  Take off and nuke the site from orbit - its the only way to be sure.  One of the easiest ways to find out whats being used is to simply remove it.  If enough people want it back then you can focus your attention there instead of things that are not being used.

[mkweaver]

I still use a few slides.

Lisp logging:
http://www.theswamp.org/index.php?topic=1695.0
http://www.theswamp.org/index.php?topic=39921.0

Your task can be quite tedious but these loggers may help.

Each DCL can be traced to a lisp if the lisp is not compiled.
Slides too can be traced that way.
The lisp to do that may exist as well.
I'll look tomorrow if I get some free time.

Another approach would be to save all to a backup drive & then delete all.
Each time you get an error , restore the files needed. Still a tedious job.

I would approach this using logging (see Cab's second link) and redefine the procedures that tie to your old data to log when they are called.  This would also need a reactor to keep track of running lisp routines.  For example, if you have a data file that is loaded with the "open" procedure then I would redefine "Open" to look something like this:

Code: [Select]

(defun Open(FileName Mode)
  (writetologfile (vl-prin1-to-string variable-with-lisp-commands-active) "Open routine run using: " filename mode)
  (_.open FileName Mode)
)

variable-with-lisp-commands-active would have to be populated with a reactor (:vlr-lispwillstart) something like this:

Code: [Select]

(defun LogLisp ( reactor params )
  (mapcar (function(lambda(param)(setq variable-with-lisp-commands-active param))) params)
  (princ)
)

I would write the writetologfile to create a tab delimited text file that can be opened with Excel then filtered for the filename for which you are trying to trace usage.

You could also redefine load_dialog to log access to dcl files.

Unfortunately, this won't help you with vba and .net:-/

[irneb]

Just a warning regarding a redefine of standard functions. Making a defun called open would redefine the old open. There's no _.open already (the lisp functions aren't like commands).

So you'd probably need to do something like this instead:

Code - Auto/Visual Lisp: [Select]

1. (setq _.open open) ; Save standard open into a new name
2. (defun open ( ;.... Continue as per your function from here

You could do a similar approach with load as well. Though in such case there's a problem. The standard load function takes either one or two arguments. There's no way to make an optional argument in an AutoLisp defun. In which case you could create such from DotNet perhaps.

[mkweaver]

Just a warning regarding a redefine of standard functions. Making a defun called open would redefine the old open. There's no _.open already (the lisp functions aren't like commands).

So you'd probably need to do something like this instead:

Code - Auto/Visual Lisp: [Select]

1. (setq _.open open) ; Save standard open into a new name
2. (defun open ( ;.... Continue as per your function from here

You could do a similar approach with load as well. Though in such case there's a problem. The standard load function takes either one or two arguments. There's no way to make an optional argument in an AutoLisp defun. In which case you could create such from DotNet perhaps.

Good points.

As I worked on my first post I considered that I would probably just do a search through my lisp files.