Re: CLOCC Documentation

[Marco A. <ma...@pa...>]

> Delivery-Date: Wed, 02 Feb 2000 02:35:10 +0100
> Date: Tue, 1 Feb 2000 17:35:34 -0800
> From: do...@co... (Don Cohen)
> CC: clo...@li...
> Sender: clo...@li...
> X-Mailman-Version: 1.1
> Precedence: bulk
> List-Id:  <clocc-devel.lists.sourceforge.net>
> X-BeenThere: clo...@li...
> 
> 
>   > Don, I appreciate you looking ahead to the ultimate goal. 
>   > This is a good idea which makes the clocc really usable. 
>   > But every long journey begins with the first step. So before we settle
>   > on a grand scheme, lets have fun with reading the code and writing down
>   > our thoughts on the code while we read the code.
>   > 
>   > Then we can have a look at what we have written. And then we can see
>   > how we organize what we have written in an easily accessible manner.
>   > :-)
> 
> 
> Two responses:
> 
> 1.
> I haven't seen a lot of evidence of people reading each others' code.
> I've reported on some of what I found in Sam's code and in the
> defsystem source, but nobody has reported back to me on the code I've
> posted.  I guess I'll add my line about putting in PD and try to stick
> it (and the next piece or two) in the collection.

I perused your code and have a question.  What does it add to the
'metering' package?

> 2.
> I don't think it's too early to think about such a database.
> I notice that sorceforge includes a MYSQL DB for each project.
> However, my first impulse is to do something totally different.
> 
> Here's an initial design:
> 
> The current repository provides version control for individual files.
> I propose we use that to add system descriptions to a new subdirectory
> that I'll call database.
> First, every "system" has a unique name (you can't have two in the
> clocc with the same name).  The system name will be the name of a file
> in the database directory.  There will be versions of that file and
> these will define versions of that system.
> The version file will contain a single lisp form.  It will contain no
> symbols other than keywords, so its package is immaterial.  This form
> will be a plist containing 
> 
> :system - name of this system (useful if you copy it out of the
> 	repository)
> :version - as above
> :files - a list of files, including location in clocc and version
>         (I don't know what format is good for this)
> :requires - a list of other systems in clocc with their versions
> 	(Again, format TBD)
> 	Obviously only one occurrence of a given system in this list;
> 	there are other obvious requirements that can only be checked
> 	when you have the descriptions of all system versions.
> :summary - a one paragraph summary of what the system is/does
> :packages - a list of packages that this system creates - useful first
> 	in order to see that two systems might have a conflict, second
> 	so that people who add new systems will know which packages to
> 	avoid
> :maintainers - a list of email addresses
> :platforms - some text describing where this system is expected to run
> 	and perhaps where it has been tested.
>  ...
> (any other keywords possible, but they'll only be useful if we can
>  agree on a meaning)
> 
> [Note that this provides completely different information from the
> defsystem description.]

Yes and no.  The list of files is redundant. As is the list of
packages.

> So, in order to "release" a new version, you create a new version of
> the description file containing the appropriate data.  I assume that
> existing versions of files never change, though in this case it would
> be useful to delete a version if you find you made a mistake in the
> description.  The repository then contains lots of versions of files 
> that are not in any released system, but you can easily find out which 
> versions are expected to work together.

Note that what you propose is similar to what CVS provides (PRCS is
closer to this model).

> This would then be the data that would be read to generate a list of
> all the systems and their descriptions, figure out what files to
> download, etc.

If you download a "system" you should get all the files of the system.

> Comments?

I am afraid we will be getting into a religious war pretty soon, but
what you are really asking here is to define what a "system" and/or a
"module" is.  Having read Gabriel :) I am wary of such definitions.
Not that thery are not useful, but I fear re-doing work that could be
avoided.

Cheers
-- 
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa