Source code organization

[Anonymous]

Never having taken a programming class, let alone having a CS degree.
Everything I know about programming (not a lot) has been self taught through
books, this NG, source code, help files, etc.

I have about 200 or so different LSP files that I maintain. Most of them
have been completely hands off for years, but I have had to go into and
edit/update/modify a good chunk of. Either by creating new ones, improving
the most used routines, fixing bugs, what have you.

My question to the group is this. What kind of source code organization do
you gurus have? File/directory structure, grouping of functions by task,
stuff like that and what ever else you can think of.

--
Kevin Nehls

[Anonymous]

I guess that's what I really need to work on is an autoloader. Does this
autoloader autoload a routine when the command is called or when a function
is called or both? Is it basically the same as the autoloader that comes
with Autocad or Express Tools?

Currently I either pre-load routines or load them at run time, but they are
not autoloaded. Now that I'm typing these questions out and thinking about
it more it would be really cool to have functions autoloaded just by calling
them. Then you just have to maintain the autoloader file and not really
worry about where anything is located when using those functions/routines in
other routines. Using this method you could also make your directory
structure as flat or convoluted as you wanted. I think anyway, I'm going to
have to play around with this idea to get a better handle on it.

--
Kevin Nehls


"R. Robert Bell" wrote in message
news:[email protected]...
> Since I have an autoloader file (Toolbox.lsp) that autoloads *all* my
> functions, I don't need to go looking for anything, unless I need to edit
a
> function...
>
> --
> R. Robert Bell, MCSE
> www.AcadX.com
>

[Anonymous]

How does that work? Does it load on startup or on demand?

--
Timothy Spangler
Product Manager
Rasche Brothers Inc.
"R. Robert Bell" wrote in message
news:[email protected]...
> Since I have an autoloader file (Toolbox.lsp) that autoloads *all* my
> functions, I don't need to go looking for anything, unless I need to edit
a
> function...
>
> --
> R. Robert Bell, MCSE
> www.AcadX.com
>
>
> "Timothy Spangler" wrote in message
> news:[email protected]...
> > My other thing is what about changing jobs or using multiple machines, I
> > want the ability to copy all of MY files out with little trouble. I
also
> > want to keep my functions separate from everything else (ACAD Standard
> > Files). As Far as the support path thing I just have a lisp that adds
all
> > of the directories I use with my lisp when I need it to. But I still
find
> > it hard to look in 1 or 2 folders of about 100+ routines each to find
what
> I
> > am looking for. How do you fix that?
> >
>
>
>

[Anonymous]

*Exactly*

I don't use AutoCAD's (or Express) autoloader, I created my own to fit my
circumstances.
And yes, I autoload functions in that Toolbox.lsp (which loads at startup)
so I may blissfully use my functions in my main code w/o worrying about
loading them.

To make the autoload as simple as possible, I wrote an internal load
function which performs the folder search (non-ACAD support folders),
handles file extension (vlx/fas/lsp), and bad functions (in case I make an
error in the autoload).


--
R. Robert Bell, MCSE
www.AcadX.com


"Kevin Nehls" wrote in message
news:[email protected]...
> I guess that's what I really need to work on is an autoloader. Does this
> autoloader autoload a routine when the command is called or when a
function
> is called or both? Is it basically the same as the autoloader that comes
> with Autocad or Express Tools?
>
> Currently I either pre-load routines or load them at run time, but they
are
> not autoloaded. Now that I'm typing these questions out and thinking
about
> it more it would be really cool to have functions autoloaded just by
calling
> them. Then you just have to maintain the autoloader file and not really
> worry about where anything is located when using those functions/routines
in
> other routines. Using this method you could also make your directory
> structure as flat or convoluted as you wanted. I think anyway, I'm going
to
> have to play around with this idea to get a better handle on it.
>

[Anonymous]

See reply to Kevin.

--
R. Robert Bell, MCSE
www.AcadX.com


"Timothy Spangler" wrote in message
news:[email protected]...
> How does that work? Does it load on startup or on demand?

[Anonymous]

Very good info. I'll have to take those points into consideration when (yes
when, not if) I write my own autoloader. I already have my own internal
load function, which does some checking, I just don't have the autoloader
portion setup. I'll probalby use Autocad's as a basis or at least an
example of how to construct one.

Thanks for the info.
--
Kevin Nehls


"R. Robert Bell" wrote in message
news:[email protected]...

> To make the autoload as simple as possible, I wrote an internal load
> function which performs the folder search (non-ACAD support folders),
> handles file extension (vlx/fas/lsp), and bad functions (in case I make an
> error in the autoload).
>
>
> --
> R. Robert Bell, MCSE
> www.AcadX.com

[Anonymous]

Robert, i see that in your prefix you have this line 'Dependencies:
rrbI:Error, rrbI:VarSav'. i'm also in the process of organizing my programs
and i was wondering what your error function checked for and what variables
your varsav function saves.

any info would be helpful
thanks,
Rob
--
'There is no knowledge that is not power.'
W2k, A2K2, VB6, VB.NET

"R. Robert Bell" wrote in message
news:[email protected]...
> As far as headers go, I settled on this awhile ago (see attached).
>
> My folder structure on the network is fairly flat also, with Toolbox
> routines stored in a folder under the "Program" folder.
>
> I do all development on my local drive (with frequent backups!) and
AutoCAD,
> on my laptop, uses these development folders as the primary support path.
>
> I also make sure that all toolbox functions have a unique prefix to help
me
> identify them (rrbI:).
>
> --
> R. Robert Bell, MCSE
> www.AcadX.com
>
>
> "Kevin Nehls" wrote in message
> news:[email protected]...
> > This is all really good info. I don't really need to check the old
> version,
> > I just usually keep them around a couple of weeks incase a new version
> > introduces a major bug I didn't find. This way I can go back to the
> > previous version and work the bug out without everyone having to wait on
> > that getting fixed.
> >
> > Some tasks are simple, some are complex and some are trying to make the
> > complex ones simple. For instance, I'm updating our "notes" routine to
> read
> > from a text file instead of inserting each note from a block.
Maintaining
> > 60+ dwg files for the different notes is a pain, but 1 text file is nice
> and
> > easy.
> >
> > We're not selling any of this code. It's all just for company use.
> >
> > Here's our setup.
> >
> > Everyone has 1 local directory (by default) C:\acadmech, which is listed
> at
> > the top of the support paths. They can put anything in here they want
and
> > that I don't want on the server.
> >
> > On the server (it's actually a pretty flat structure)
> > I:\Acad Files <- contains files installed by autocad, but customized by
> us
> > I:\Dev\Src <- contains the source code of all LSP files
> > I:\Dev\Update <- this is where I planned to work on updates and new
> > routines, but it usually ends up happening on my local system.
> > I:\Fonts <- duh
> > I:\SW Support <- Contains all "standard" compiled lsp files, menu files
> and
> > all "standard" blocks, there are a few sub-dirs of some specialty
blocks,
> > but that's it.
> >
> > The overall file structure is pretty flat. I want to organize it into
> > categories so that if I ever left, someone new could take a look at it
and
> > any readme.txt files I have and get a pretty good understanding of
what's
> > going on. I also need to go through all of the routines to add some
> > description to them. I inherited most of what's going on here and have
> > re-worked some of it. It was a real pain when I first started with it,
> but
> > after 4+ years I now know where everything and mostly how it works.
> >
> > --
> > Kevin Nehls
> >
> >
>
>


----------------------------------------------------------------------------
----


> ;|
>
> SampleHeader.lsp
>
> Version history
> 1.1 2002/03/28 A sample just for you!
> 1.0 2002/01/01 Initial release.
>
> Here is where I describe the program/function
>
> Dependencies: rrbI:Error, rrbI:VarSav
> Usage: (rrbI:MyFunc Data)
> Arguments: Data type of argument, desription of argument's purpose
> Returns: description of return values
>
> Copyright © 2002 by R. Robert Bell.
>
> Written permission must be obtained to copy, modify, and distribute this
software.
> Permission to use this software for any purpose and without fee is hereby
granted,
> provided that the above copyright notice appears in all copies and that
both
> the copyright notice and the limited warranty and restricted rights notice
below
> appear in all supporting documentation.
>
> R. ROBERT BELL PROVIDES THIS PROGRAM "AS IS" AND WITH ALL FAULTS.
> R. ROBERT BELL SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTY OF
> MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE.
> R. ROBERT BELL DOES NOT WARRANT THAT THE OPERATION OF THE PROGRAM
> WILL BE UNINTERRUPTED OR ERROR FREE.
>
> [email protected]
>
> |;
>
> (defun...

[Anonymous]

That is my generalized error handler. It simply checks for or nil, and
clean exits in those cases, running my rrbI:VarSav to restore the
environment.

rrbI:VarSav saves/sets specified setvars (provided as a list), and restores
them when called with a nil argument.


--
R. Robert Bell, MCSE
www.AcadX.com


"Rob Tomson" wrote in message
news:[email protected]...
> Robert, i see that in your prefix you have this line 'Dependencies:
> rrbI:Error, rrbI:VarSav'. i'm also in the process of organizing my
programs
> and i was wondering what your error function checked for and what
variables
> your varsav function saves.
>
> any info would be helpful
> thanks,
> Rob
> --
> 'There is no knowledge that is not power.'
> W2k, A2K2, VB6, VB.NET
>
> "R. Robert Bell" wrote in message
> news:[email protected]...
> > As far as headers go, I settled on this awhile ago (see attached).
> >
> > My folder structure on the network is fairly flat also, with Toolbox
> > routines stored in a folder under the "Program" folder.
> >
> > I do all development on my local drive (with frequent backups!) and
> AutoCAD,
> > on my laptop, uses these development folders as the primary support
path.
> >
> > I also make sure that all toolbox functions have a unique prefix to help
> me
> > identify them (rrbI:).
> >
> > --
> > R. Robert Bell, MCSE
> > www.AcadX.com
> >
> >
> > "Kevin Nehls" wrote in message
> > news:[email protected]...
> > > This is all really good info. I don't really need to check the old
> > version,
> > > I just usually keep them around a couple of weeks incase a new version
> > > introduces a major bug I didn't find. This way I can go back to the
> > > previous version and work the bug out without everyone having to wait
on
> > > that getting fixed.
> > >
> > > Some tasks are simple, some are complex and some are trying to make
the
> > > complex ones simple. For instance, I'm updating our "notes" routine
to
> > read
> > > from a text file instead of inserting each note from a block.
> Maintaining
> > > 60+ dwg files for the different notes is a pain, but 1 text file is
nice
> > and
> > > easy.
> > >
> > > We're not selling any of this code. It's all just for company use.
> > >
> > > Here's our setup.
> > >
> > > Everyone has 1 local directory (by default) C:\acadmech, which is
listed
> > at
> > > the top of the support paths. They can put anything in here they want
> and
> > > that I don't want on the server.
> > >
> > > On the server (it's actually a pretty flat structure)
> > > I:\Acad Files <- contains files installed by autocad, but customized
by
> > us
> > > I:\Dev\Src <- contains the source code of all LSP files
> > > I:\Dev\Update <- this is where I planned to work on updates and new
> > > routines, but it usually ends up happening on my local system.
> > > I:\Fonts <- duh
> > > I:\SW Support <- Contains all "standard" compiled lsp files, menu
files
> > and
> > > all "standard" blocks, there are a few sub-dirs of some specialty
> blocks,
> > > but that's it.
> > >
> > > The overall file structure is pretty flat. I want to organize it into
> > > categories so that if I ever left, someone new could take a look at it
> and
> > > any readme.txt files I have and get a pretty good understanding of
> what's
> > > going on. I also need to go through all of the routines to add some
> > > description to them. I inherited most of what's going on here and
have
> > > re-worked some of it. It was a real pain when I first started with
it,
> > but
> > > after 4+ years I now know where everything and mostly how it works.
> > >
> > > --
> > > Kevin Nehls
> > >
> > >
> >
> >
>
>
> --------------------------------------------------------------------------
--
> ----
>
>
> > ;|
> >
> > SampleHeader.lsp
> >
> > Version history
> > 1.1 2002/03/28 A sample just for you!
> > 1.0 2002/01/01 Initial release.
> >
> > Here is where I describe the program/function
> >
> > Dependencies: rrbI:Error, rrbI:VarSav
> > Usage: (rrbI:MyFunc Data)
> > Arguments: Data type of argument, desription of argument's purpose
> > Returns: description of return values
> >
> > Copyright © 2002 by R. Robert Bell.
> >
> > Written permission must be obtained to copy, modify, and distribute this
> software.
> > Permission to use this software for any purpose and without fee is
hereby
> granted,
> > provided that the above copyright notice appears in all copies and that
> both
> > the copyright notice and the limited warranty and restricted rights
notice
> below
> > appear in all supporting documentation.
> >
> > R. ROBERT BELL PROVIDES THIS PROGRAM "AS IS" AND WITH ALL FAULTS.
> > R. ROBERT BELL SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTY OF
> > MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE.
> > R. ROBERT BELL DOES NOT WARRANT THAT THE OPERATION OF THE PROGRAM
> > WILL BE UNINTERRUPTED OR ERROR FREE.
> >
> > [email protected]
> >
> > |;
> >
> > (defun...
>
>

[Anonymous]

thanks!

--
'There is no knowledge that is not power.'
W2k, A2K2, VB6, VB.NET

"R. Robert Bell" wrote in message
news:[email protected]...
> That is my generalized error handler. It simply checks for or nil,
and
> clean exits in those cases, running my rrbI:VarSav to restore the
> environment.
>
> rrbI:VarSav saves/sets specified setvars (provided as a list), and
restores
> them when called with a nil argument.
>
>
> --
> R. Robert Bell, MCSE
> www.AcadX.com
>
>
> "Rob Tomson" wrote in message
> news:[email protected]...
> > Robert, i see that in your prefix you have this line 'Dependencies:
> > rrbI:Error, rrbI:VarSav'. i'm also in the process of organizing my
> programs
> > and i was wondering what your error function checked for and what
> variables
> > your varsav function saves.
> >
> > any info would be helpful
> > thanks,
> > Rob
> > --
> > 'There is no knowledge that is not power.'
> > W2k, A2K2, VB6, VB.NET
> >
> > "R. Robert Bell" wrote in message
> > news:[email protected]...
> > > As far as headers go, I settled on this awhile ago (see attached).
> > >
> > > My folder structure on the network is fairly flat also, with Toolbox
> > > routines stored in a folder under the "Program" folder.
> > >
> > > I do all development on my local drive (with frequent backups!) and
> > AutoCAD,
> > > on my laptop, uses these development folders as the primary support
> path.
> > >
> > > I also make sure that all toolbox functions have a unique prefix to
help
> > me
> > > identify them (rrbI:).
> > >
> > > --
> > > R. Robert Bell, MCSE
> > > www.AcadX.com
> > >
> > >
> > > "Kevin Nehls" wrote in message
> > > news:[email protected]...
> > > > This is all really good info. I don't really need to check the old
> > > version,
> > > > I just usually keep them around a couple of weeks incase a new
version
> > > > introduces a major bug I didn't find. This way I can go back to the
> > > > previous version and work the bug out without everyone having to
wait
> on
> > > > that getting fixed.
> > > >
> > > > Some tasks are simple, some are complex and some are trying to make
> the
> > > > complex ones simple. For instance, I'm updating our "notes" routine
> to
> > > read
> > > > from a text file instead of inserting each note from a block.
> > Maintaining
> > > > 60+ dwg files for the different notes is a pain, but 1 text file is
> nice
> > > and
> > > > easy.
> > > >
> > > > We're not selling any of this code. It's all just for company use.
> > > >
> > > > Here's our setup.
> > > >
> > > > Everyone has 1 local directory (by default) C:\acadmech, which is
> listed
> > > at
> > > > the top of the support paths. They can put anything in here they
want
> > and
> > > > that I don't want on the server.
> > > >
> > > > On the server (it's actually a pretty flat structure)
> > > > I:\Acad Files <- contains files installed by autocad, but
customized
> by
> > > us
> > > > I:\Dev\Src <- contains the source code of all LSP files
> > > > I:\Dev\Update <- this is where I planned to work on updates and new
> > > > routines, but it usually ends up happening on my local system.
> > > > I:\Fonts <- duh
> > > > I:\SW Support <- Contains all "standard" compiled lsp files, menu
> files
> > > and
> > > > all "standard" blocks, there are a few sub-dirs of some specialty
> > blocks,
> > > > but that's it.
> > > >
> > > > The overall file structure is pretty flat. I want to organize it
into
> > > > categories so that if I ever left, someone new could take a look at
it
> > and
> > > > any readme.txt files I have and get a pretty good understanding of
> > what's
> > > > going on. I also need to go through all of the routines to add some
> > > > description to them. I inherited most of what's going on here and
> have
> > > > re-worked some of it. It was a real pain when I first started with
> it,
> > > but
> > > > after 4+ years I now know where everything and mostly how it works.
> > > >
> > > > --
> > > > Kevin Nehls
> > > >
> > > >
> > >
> > >
> >
> >
>
> --------------------------------------------------------------------------
> --
> > ----
> >
> >
> > > ;|
> > >
> > > SampleHeader.lsp
> > >
> > > Version history
> > > 1.1 2002/03/28 A sample just for you!
> > > 1.0 2002/01/01 Initial release.
> > >
> > > Here is where I describe the program/function
> > >
> > > Dependencies: rrbI:Error, rrbI:VarSav
> > > Usage: (rrbI:MyFunc Data)
> > > Arguments: Data type of argument, desription of argument's purpose
> > > Returns: description of return values
> > >
> > > Copyright © 2002 by R. Robert Bell.
> > >
> > > Written permission must be obtained to copy, modify, and distribute
this
> > software.
> > > Permission to use this software for any purpose and without fee is
> hereby
> > granted,
> > > provided that the above copyright notice appears in all copies and
that
> > both
> > > the copyright notice and the limited warranty and restricted rights
> notice
> > below
> > > appear in all supporting documentation.
> > >
> > > R. ROBERT BELL PROVIDES THIS PROGRAM "AS IS" AND WITH ALL FAULTS.
> > > R. ROBERT BELL SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTY OF
> > > MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE.
> > > R. ROBERT BELL DOES NOT WARRANT THAT THE OPERATION OF THE PROGRAM
> > > WILL BE UNINTERRUPTED OR ERROR FREE.
> > >
> > > [email protected]
> > >
> > > |;
> > >
> > > (defun...
> >
> >
>
>

[Anonymous]

Kevin, (Hope its ok to interject)

My main program is called keymac.lsp. It is basically a file that contains
hundreds of autoload statements like for the closet rod below.
(I also use my own, since I started before Autodesk had theirs)

;;Sample part of keymac.lsp

;;restore previous error program and variable settings
;;(restore) ;<--Of course this is old hat now that you can use local *error* functions
(defun restore()
(if (list oerr) (setq *error* oerr))
(moder) ;;<-Just like Autodesk's version
(command "undo""end") ;5-14-95
(princ)
)

;;$INI initialize function
;;($INI )
(defun $ini (a) (princ "\nInitializing .....")(load a))

;;$INR initialize, redefine, and run
;;($inr ' ')
(defun $inr(a b c)
(restore)
($ini a)
(eval (list 'defun b nil c))
(eval c)
)

;For the closet rods the autoload looks like:
(defun c:cr ()($inr "crod" 'c:cr '(c:crod)));;DCB closet rod

Doug


"Kevin Nehls" wrote in message
news:[email protected]...
> Very good info. I'll have to take those points into consideration when (yes
> when, not if) I write my own autoloader. I already have my own internal
> load function, which does some checking, I just don't have the autoloader
> portion setup. I'll probalby use Autocad's as a basis or at least an
> example of how to construct one.
>
> Thanks for the info.
> --
> Kevin Nehls
>
>
> "R. Robert Bell" wrote in message
> news:[email protected]...
>
> > To make the autoload as simple as possible, I wrote an internal load
> > function which performs the folder search (non-ACAD support folders),
> > handles file extension (vlx/fas/lsp), and bad functions (in case I make an
> > error in the autoload).
> >
> >
> > --
> > R. Robert Bell, MCSE
> > www.AcadX.com
>
>

[Anonymous]

No prob. Thanks for the info Doug.

--
Kevin Nehls


"Doug Broad" wrote in message
news:[email protected]...
> Kevin, (Hope its ok to interject)

[Anonymous]

Hi Kevin,
That's a problem I've had to ponder a lot in the past also. Here are a
couple of tricks you can use to make lisping easier I believe.

1. Apropos is great
One thing I did was to rename most of my functions at some point to make
them more logical and easier to find with the apropos in visual lisp. It was
a bit tedious to do but you can replace in files using many text editors and
you can search directories in visual lisp.

e.g if I had a function called getpointlist I might rename it to pts-get.
Other examples include:
centreofptlist - pts-get-centre
boundingbox - pts-get-boundingbox
sortpoints - pts-sort
scalepoints - pts-scale
printpoints - pts-print

do the same thing for entities (e.g. ent-get-color, ent-get-layer)
When you are trying to remember old functions just type in the obvious first
letters and use the apropos command to show you a list of possible
functions. By typing pts- and then holding down ctrl, shift and space-bar at
once you should get the above pts-* commands listed above. Therefore you
don't have to try to remember the name of the functions anymore as long as
the files are loaded into lisp memory.

2 . Encapsulate your files into projects
Try using visual lisp projects to associate files with one another. You can
keep all your source in certain directories and put your project compiled
fas files in your support path. I find this useful even if the files aren't
grouped together as an application. You can search through all files in a
project and open and close them easily with the projects window. And when
you compile the project it can reveal all sorts of naming conflicts and
unwanted local variables. You can also see what files dependencies exist so
that you don't give a lisp file to someone only to find that they are
missing certain libraries. I read about projects in the visual lisp pdf file
that comes with AutoCAD and I find them very useful for organising files.

I hope some of these suggestions come in handy,
Best of luck,
Chris Kelly

[Anonymous]

Thanks Chris. I'll look into that info.

BTW, I posted an Autoloader function that you may be interested in. The
topic is titled "My AutoLoader (sort of)".

--
Kevin Nehls


"Chris Kelly" wrote in message
news:[email protected]...