clocc-devel

Re: CLOCC Documentation

[Paolo A. <am...@mc...>]

On Tue, 1 Feb 2000 22:55:04 +0100 (CET), Stefan <st...@hi...> wrote:

> First of all I have to look what infrastructure is needed. Any hints,
> beside the docbook dtd?  The sgml-tools might be helpful. I think, I will

Here are a few useful resources:

  DocBook (official site?)
  http://www.docbook.org/

  DocBook Crash Course
  http://www.kde.org/documentation/docbook/index.html

  DocBook Resources (maintained by Norman Walsh)
  http://www.nwalsh.com/

  DocBook Support for PNG
  http://www.labs.redhat.com/png/custom.html

  DocBook - The Definitive Guide
  http://www.docbook.org/tdg/

  DocBook Tools
  ftp://sourceware.cygnus.com/pub/docbook-tools/

  Get Going with DocBook - Notes for Hackers
  http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro.html

  OSWG - Open Source Writers Group
  http://www.oswg.org/


> And after all, you all are professional software developers, aren't you??
> :-]

Of course you are not talking about me :-)


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

Re: Cannot cvs to sourceforge....

[Paolo A. <am...@mc...>]

On Tue, 1 Feb 2000 20:27:41 -0800, do...@co... (Don Cohen) wrote:

> I get:
> /usr/X11R6/bin/xauth:  creating new authority file /home/users/donc/.Xauthority
> Sorry, you don't have read/write access to the history file /cvsroot/clocc/CVSROOT/history
> Permission denied

Maybe you don't have write permissions because your username has not been
added to the appropriate--Unix--group yet, e.g. cvs. I have read about this
possible explanation in the document:

  CVS Version Control for Web Site Projects
  http://interactivate.com/cvswebsites/

Although it deals with Web site development, it's a useful CVS tutorial.


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

code & infrastructure

[Sam S. <sd...@gn...>]

I am sorry to observe that this list is quckly degenerating into an
infrastructure religious war playground.
Documentation format, defsystem deficiencies, coding standards, code
duplication are all *secondary*.

We need to get killer apps, like cl-emacs and closure web browser
working to get as many people on the CL bandwagon as possible.

Gilbert Baumann, who is on this list, but is, apparently, too busy
(hopofuly, with closure :-) to participate in our stupid bickering,
should get as much help as possible.  Until closure gets good enough for
mainstream use, we will get no additional members and ***USERS***, and
WE NEED THEM, if we don't want CL to go sour.

Ergo: I suggest that Gilbert put closure into clocc and we try to help
him with it.  Many parts of closure qualify as separate modules (http,
ftp, xml/sgml parsing &c), so I would be reluctant to suggest that
closure should be in a separate project.  OTOH, I wouldn't argue
otherwise either.  In fact, I shall try to abstain from any
administrative/infrastructure discussions from now on.  I want to write
lisp, not flames.

-- 
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
The world will end in 5 minutes.  Please log out.

Re: CLOCC Documentation

[Sam S. <sd...@gn...>]

>>>> In message <Pin...@hi...>
>>>> On the subject of "Re: CLOCC Documentation"
>>>> Sent on Tue Feb 01 16:54:06 EST 2000
>>>> Honorable Stefan <st...@hi...> writes:
 >> 
 >> Hey, thats sounds interesting. At least I think it would be worth
 >> the effort. But has anybody of you a xml - capable browser??  :-)

forget it.
xml is meta-language, there cannot be a browser.

use nsgmls to check and docbook2texi to convert to texinfo (then
texi2html and dvips).  I wish there were a direct docbook2ps and
docbook2html. 

 >> I am not going to do the job, if it means that from now on I would
 >> be the only one to document the software.

you will translate the mkant paper and it will be used as a reference
for each of us who will be documenting one's own code.

-- 
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
The early worm gets caught by the bird.

Re: what sort of modules should be in clocc

[Sam S. <sd...@gn...>]

>>>> In message <200...@co...>
>>>> On the subject of "Re: what sort of modules should be in clocc"
>>>> Sent on Wed Feb 02 05:13:23 EST 2000
>>>> Honorable Marco Antoniotti <ma...@pa...> writes:
 >> 
 >> Anyway, just to give an extra bit of code to the repository, here is
 >> a very, very, very, early stage CL.ENVINRONMENT package.  I intend
 >> to eventually release it under LGPL or PD.  Please comment on it

You cannot release it under PD if it is base on my code.
LGPL only.  Sorry.

 >> before I enter it in the repository.  As you can see I cannibalized
 >> Sam's SYSINFO.

Please look at  src/port/sys.lsp.
Why don't you like the version there?

-- 
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Whom computers would destroy, they must first drive mad.

Re: CLOCC Documentation

[Stig E. S. <st...@ii...>]

On Tue, 1 Feb 2000, Don Cohen wrote:

> 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.

[snip example of a lisp-form with info]

I think this is a good idea and it should be trivial to add a small
script which translates it into xml which can be included in
presentations and printed docs.

> 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.
> 
> 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.
> 
> Comments?

This is probably not such a good idea, I think cvs will do a better
job with versioning than a short hack will.  The key thing would be
to keep the file with the info in sync with the code and when people
check out the code the info-file comes along and is correct for the
code checked out. 



------------------------------------------------------------------
Stig Erik Sandoe     st...@ii...    http://www.ii.uib.no/~stig/

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

Re: what sort of modules should be in clocc

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

Apologies for the long quotes.  I need the context.

> Delivery-Date: Tue, 01 Feb 2000 17:18:57 +0100
> Date: Tue, 1 Feb 2000 08:17:48 -0800
> From: do...@co... (Don Cohen)
> 
>   > > I see no evidence of that.  What I see is the ability to load or
>   > > compile a given version of a system.  However there is no notion of
>   > > dependency of one version of one system on a given version of another.
>   > > So loading version 1.1 of system 1 will call load on its dependent
>   > > systems without a version, or perhaps you could bind *version* and
>   > > load version 1.1 of all of them, but this is not what I want either.
>   > 
>   > First of all, MK:DEFSYSTEM does have some minimal (directory based)
>   > version control.  However, I recall having this discussion on the PRCS
> 
> If anyone has information contrary to my summary above I'd be
> interested in hearing it.

MK:DEFSYSTEM has a directory based versioning system.  I do not like
it and do not use it, CVS and PRCS are better suited for this.

>   > list.  Somebody was going the "other direction" as well and proposing
>   > that PRCS did not only version control but also "configuration
>   > management".
>   > 
>   > Now, I strongly believe that [1] system building, [2] version control,
>   > and [3] configuration management (which includes "release management")
>   > are mostly orthogonal aspects of the same problem.  Designing a system
>   > that does all three well is IMHO very difficult.  That is why we see
>   > autoconf/automake, make and CVS (PRCS - my favourite :) ) around.
>   > 
>   > > The other part of the problem is that, even if you can teach defsystem
>   > > to do this, we need it to work on the server.  The user who wants 
>   > > animals 4.5 wants the server to tell him that this transitively
>   > > requires the following systems (and versions) and offer to get those
>   > > for him at the same time.  Ideally the systems you need could all be
>   > > packaged into one archive for you.
>   > 
>   > As I said before, I believe these concerns must be kept
>   > separate. Although I will be very happy to see a proposal integrating
>   > all of them.
> 
> Part of the problem is where to draw boundaries between these
> different aspects.  Defsystem is doing more than make - which only
> deals with one consistent set of files for one system - it's also
> worrying about what other systems this one relies on and arranging to
> load those before it does the make for this one.  In order to do that
> it clearly has to be aware of versions for those other systems, and of
> the dependency relationship not only among systems, but system
> versions.

Not necessarily.  MK:DEFSYSTEM does not do this (i.e. discriminate
among different "versions" of other systems). You can add this
functionality, but at the cost of introducing in MK:DEFSYSTEM the
functionalities required by a "configuration management" system.

I believe this is not a trivial task to get right.

> In c-like environments (in which I claim no expertise) I generally do
> not see a very strong model of that sort.  RPM seems to be a notable
> exception.  More typically you see configure scripts that test whether
> various things work and try to configure the system being built to
> work in as many cases as possible.  I often wonder how many bugs are
> caused by incompatibilities that have never been noticed and therefore
> are never checked.

Many.  I do have a lot of experience with autoconf and make and I know
the pitfalls.

So, the question is:  how do I go ahead and fix this?  Can I do better
that the C/C++ situation?   We need to discuss these things before
going ahead and propose soemthing.

> I like the idea of testing particular capabilities as part of a build
> (in lisp this would likely be in the source of your system), but I
> also like the idea of knowing what particular versions you're using of
> all (or at least as many as possible) of the things you depend on.
> 
> To the extent that common lisp is really common then, the important
> dependencies are the versions of the subsystems on which our system
> relies.

Yes and no.

> In reality, of course, it will also be useful to know that the
> maintainer actually debugged/tested his system, e.g., with
> clisp-1999-07-22 on redhat 5.2 etc. etc.  I would be very happy to
> have this data also recorded in the repository, but I expect it will
> be less important than the dependencies among the lisp system
> versions.

Anyway, just to give an extra bit of code to the repository, here is a
very, very, very, early stage CL.ENVINRONMENT package.  I intend to
eventually release it under LGPL or PD.  Please comment on it before I
enter it in the repository.  As you can see I cannibalized Sam's
SYSINFO.

Please comment on its design as well.

Cheers

Marco

-- 
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

CL.ENVIRONMENT package

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

-- 
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

RE: Cannot cvs to sourceforge....

[Stefan <st...@hi...>]

Hi,

On Tue, 1 Feb 2000, Don Cohen wrote:
> This seems to imply that the above should work, but you'll
> have to type your password (what's wrong with that?).
> 
Locally on your machine you could run ssh-agent which will allow
you to type in your passphrase only once. Afterwards you will be 
able to use CVS without retyping your passphrase every time.

> Sorry, you don't have read/write access to the history file /cvsroot/clocc/CVSROOT/history
> Permission denied
Do you still get that message?

> On the other hand, I don't seem to be listed in the clocc developers
> list.  

Fixed.

> Can someone tell me what to do to create a new directory and
> put stuff into it?

cvs import is the way to go. Have a look at the cvs - docu.
---
cvs import [-m msg] repository vendor-tag release-tags

While issueing this command your current path MUST be IN the directory
you want to import.
repository is the target path in the repository (relative to ROOT)
---

>Also, if anyone has an opinion where I should put
> it ...

Hmmm.

clocc/src/"???"

if you haven't your own dir structure yet I would propose
"???" = "donc" for starters.


Bye,

Stefan

clocc - devels

[Stefan <st...@hi...>]

Hi Don and Stig,

I have added you as developers to the clocc.

This implies write permission to the CVS.

please use your rights in a way that doesn't offend
other developers.

In particular: Don't yet make changes to the basic structure
of the repository before you haven't discussed it on clocc-devel
and achieved a majority of votes.

Thanks.


Happy Lisping!

Stefan

RE: Cannot cvs to sourceforge....

[<do...@co...>]

    > 1> cvs -d ma...@cv...:/cvsroot/clocc checkout clocc
    > Host key not found from the list of known hosts.
    > Are you sure you want to continue connecting (yes/no)? yes
    > Host `cvs.clocc.sourceforge.net` added to the list of known hosts.
    > ma...@cv...`s password: <my sourcefoge passwd here>
    > 
    > Permission denied.
    > cvs [checkout aborted]: end of file from server ...

  >  I think you must give your ssh key (contents of identity.pub) into the
  >  appropriate web form, and then wait 6 hours so the thing gets propagated
  >  to the correct machine.

Under CVS/SSH Shared Keys it says:

  To avoid having to type your password every time for
  your CVS/SSH developer account, you may upload
  your public key(s) here and they will be placed on
  the CVS server in your ~/.ssh/authorized_keys file. 

  To generate a public key, run the program
  'ssh-keygen' (or ssh-keygen1). The public key will be placed at
  '~/.ssh/identity.pub'. Read the ssh documentation for
  further information on sharing keys. 

  Updates will be reflected in the next 6 hour cron
  job. 

This seems to imply that the above should work, but you'll
have to type your password (what's wrong with that?).

I get:
/usr/X11R6/bin/xauth:  creating new authority file /home/users/donc/.Xauthority
Sorry, you don't have read/write access to the history file /cvsroot/clocc/CVSROOT/history
Permission denied

On the other hand, I don't seem to be listed in the clocc developers
list.  Can someone tell me what to do to create a new directory and
put stuff into it?  Also, if anyone has an opinion where I should put
it ...

Re: CLOCC Documentation

[<do...@co...>]

  > 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.

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.]

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.

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.

Comments?

Re: CLOCC Documentation

[Stefan <st...@hi...>]

Hi,

> I hope either it's acceptable to maintain ascii doc or there's an easy
> way to generate the desired form from ascii.

xml can be provided in "ascii"-format! :-)

Sorry for the joke. :-)

By "ascii" you mean that the docu to be viewable without any
specialised software. (other than cat,less,more,...)

Now serious:
From xml there should be numerous ways to other document "formats".
even to plain text. (at least I hope so)


On Tue, 1 Feb 2000, Don Cohen wrote:
> Perhaps if we can agree on a few standards we can write a piece of
> lisp code that will collect all the systems (actually system
> versions), their documentation summaries, the files in each, the other
> systems required by each, and then give you a way to retrieve the sets
> of files needed for an input set of systems (and tell you about any 
> version inconsistencies).  Can we run our own code at sourceforge or
> does someone have to do this from elsewhere?
> 

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.
:-)


Bye,

Stefan

Re: CLOCC Documentation

[<do...@co...>]

  > >  >> BTW: Has it been decided on a system for documenting the content of
  > >  >> CLOCC?
  > > 
  > > I suggest comprehensive docs using docbook/xml.
  > 
  > Hey, thats sounds interesting. At least I think it would be worth the
  > effort. But has anybody of you a xml - capable browser??  :-)

That's a good question to start with.  (I don't know the answer.)

I hope either it's acceptable to maintain ascii doc or there's an easy
way to generate the desired form from ascii.

Another is whether there can be a standard (or several) for where this
doc is kept.  For single files it's convenient to put it in a comment
at the top.  For large systems it makes more sense to have a separate file.

Regardless of the format, I'd like to have one automatically
maintained document that contains summaries of all the packages in the
collection.  The purpose is to make it easy to browse the whole
collection at once.

Perhaps if we can agree on a few standards we can write a piece of
lisp code that will collect all the systems (actually system
versions), their documentation summaries, the files in each, the other
systems required by each, and then give you a way to retrieve the sets
of files needed for an input set of systems (and tell you about any 
version inconsistencies).  Can we run our own code at sourceforge or
does someone have to do this from elsewhere?

Re: CLOCC Documentation

[Stefan <st...@hi...>]

Hi everyone,

On 1 Feb 2000, Sam Steingold wrote:
>  >> BTW: Has it been decided on a system for documenting the content of
>  >> CLOCC?
> 
> I suggest comprehensive docs using docbook/xml.

Hey, thats sounds interesting. At least I think it would be worth the
effort. But has anybody of you a xml - capable browser??  :-)

> 
> a first step would be to translate the aforementioned paper to the
> docbook/xml format.  any takers?  

Well, I am interested in docbook/xml. But be warned! :-) I would use the
opportunity to learn it while converting the docu, which means: The result
might be suboptimal... :-)

First of all I have to look what infrastructure is needed. Any hints,
beside the docbook dtd?  The sgml-tools might be helpful. I think, I will
have a look at the Linux Documentation Project, because DocBook is their
standard format. So they should also have a howto on how to ( :-))
generate DocBook - Docu.

And there is another problem. How accurate/recent is the documentation. If
it is older than the current software, it is likely to be wrong.

And we all know the famous saying:"If documentation and program
disagree,
 ...
probably both are wrong..." :-)

So I should compare docu and source. ups, that sounds like a lot of
work...

But I will do it, nevertheless.  Sacrificing myself to the community...
:-) heroically... 

> (one would have to contact mkant first
> and get his permission).

Well, Marco, don't you have a specifically friendly contact to him?

I mean, I am a stranger to him,  and I am so shy... :-)

But there is one most important boundary condition: !!!!!

I am not going to do the job, if it means that from now on I would be the
only one to document the software.

My opinion is that any good professional software developer should be
capable to document his source. Everything else is looser behaviour, and I 
am not going to support this kind of lazyness!!! :-)

And after all, you all are professional software developers, aren't you??
:-]

Bye

Stefan

Re: CLOCC Documentation

[Sam S. <sd...@gn...>]

>>>> In message <Pin...@ap...>
>>>> On the subject of "CLOCC Documentation"
>>>> Sent on Mon Jan 31 18:05:35 EST 2000
>>>> Honorable Stig Erik Sandoe <st...@ii...> writes:
 >> 
 >> I had a look through the source tree so far (once I got past the
 >> local firewall), but I found documentation to be lacking.  For
 >> example, mk:defsystem is documented in MK's "Portable Utilities for
 >> CL, User Guide & Implementation Notes" but this document wasn't in
 >> the tree.
 >> 
 >> BTW: Has it been decided on a system for documenting the content of
 >> CLOCC?

I suggest comprehensive docs using docbook/xml.

a first step would be to translate the aforementioned paper to the
docbook/xml format.  any takers?  (one would have to contact mkant first
and get his permission).

-- 
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
I'm out of my mind, but feel free to leave a message...

Re: what sort of modules should be in clocc

[<do...@co...>]

  > > I see no evidence of that.  What I see is the ability to load or
  > > compile a given version of a system.  However there is no notion of
  > > dependency of one version of one system on a given version of another.
  > > So loading version 1.1 of system 1 will call load on its dependent
  > > systems without a version, or perhaps you could bind *version* and
  > > load version 1.1 of all of them, but this is not what I want either.
  > 
  > First of all, MK:DEFSYSTEM does have some minimal (directory based)
  > version control.  However, I recall having this discussion on the PRCS

If anyone has information contrary to my summary above I'd be
interested in hearing it.

  > list.  Somebody was going the "other direction" as well and proposing
  > that PRCS did not only version control but also "configuration
  > management".
  > 
  > Now, I strongly believe that [1] system building, [2] version control,
  > and [3] configuration management (which includes "release management")
  > are mostly orthogonal aspects of the same problem.  Designing a system
  > that does all three well is IMHO very difficult.  That is why we see
  > autoconf/automake, make and CVS (PRCS - my favourite :) ) around.
  > 
  > > The other part of the problem is that, even if you can teach defsystem
  > > to do this, we need it to work on the server.  The user who wants 
  > > animals 4.5 wants the server to tell him that this transitively
  > > requires the following systems (and versions) and offer to get those
  > > for him at the same time.  Ideally the systems you need could all be
  > > packaged into one archive for you.
  > 
  > As I said before, I believe these concerns must be kept
  > separate. Although I will be very happy to see a proposal integrating
  > all of them.

Part of the problem is where to draw boundaries between these
different aspects.  Defsystem is doing more than make - which only
deals with one consistent set of files for one system - it's also
worrying about what other systems this one relies on and arranging to
load those before it does the make for this one.  In order to do that
it clearly has to be aware of versions for those other systems, and of
the dependency relationship not only among systems, but system
versions.

In c-like environments (in which I claim no expertise) I generally do
not see a very strong model of that sort.  RPM seems to be a notable
exception.  More typically you see configure scripts that test whether
various things work and try to configure the system being built to
work in as many cases as possible.  I often wonder how many bugs are
caused by incompatibilities that have never been noticed and therefore
are never checked.

I like the idea of testing particular capabilities as part of a build
(in lisp this would likely be in the source of your system), but I
also like the idea of knowing what particular versions you're using of
all (or at least as many as possible) of the things you depend on.

To the extent that common lisp is really common then, the important
dependencies are the versions of the subsystems on which our system
relies.

In reality, of course, it will also be useful to know that the
maintainer actually debugged/tested his system, e.g., with
clisp-1999-07-22 on redhat 5.2 etc. etc.  I would be very happy to
have this data also recorded in the repository, but I expect it will
be less important than the dependencies among the lisp system
versions.

Re: what sort of modules should be in clocc

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

> Delivery-Date: Mon, 31 Jan 2000 23:52:30 +0100
> Date: Mon, 31 Jan 2000 14:52:37 -0800
> From: do...@co... (Don Cohen)
> CC: ma...@pa..., clo...@li...
> 
  ...

> I see no evidence of that.  What I see is the ability to load or
> compile a given version of a system.  However there is no notion of
> dependency of one version of one system on a given version of another.
> So loading version 1.1 of system 1 will call load on its dependent
> systems without a version, or perhaps you could bind *version* and
> load version 1.1 of all of them, but this is not what I want either.

First of all, MK:DEFSYSTEM does have some minimal (directory based)
version control.  However, I recall having this discussion on the PRCS
list.  Somebody was going the "other direction" as well and proposing
that PRCS did not only version control but also "configuration
management".

Now, I strongly believe that [1] system building, [2] version control,
and [3] configuration management (which includes "release management")
are mostly orthogonal aspects of the same problem.  Designing a system
that does all three well is IMHO very difficult.  That is why we see
autoconf/automake, make and CVS (PRCS - my favourite :) ) around.

> The other part of the problem is that, even if you can teach defsystem
> to do this, we need it to work on the server.  The user who wants 
> animals 4.5 wants the server to tell him that this transitively
> requires the following systems (and versions) and offer to get those
> for him at the same time.  Ideally the systems you need could all be
> packaged into one archive for you.

As I said before, I believe these concerns must be kept
separate. Although I will be very happy to see a proposal integrating
all of them.

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

CLOCC Documentation

[Stig E. S. <st...@ii...>]

hi,

I had a look through the source tree so far (once I got past the
local firewall), but I found documentation to be lacking.  For
example, mk:defsystem is documented in MK's "Portable Utilities for
CL, User Guide & Implementation Notes" but this document
wasn't in the tree.  

BTW: Has it been decided on a system for documenting the content of
CLOCC?

------------------------------------------------------------------
Stig Erik Sandoe     st...@ii...    http://www.ii.uib.no/~stig/

Re: what sort of modules should be in clocc

[Sam S. <sd...@gn...>]

>>>> In message <Zey...@4a...>
>>>> On the subject of "Re: what sort of modules should be in clocc"
>>>> Sent on Mon Jan 31 16:12:48 EST 2000
>>>> Honorable Paolo Amoroso <am...@mc...> writes:
 >> On 31 Jan 2000 12:22:44 -0500, you wrote:
 >> 
 >> > now, wait a second - *currently* no CL comes with mk:defsystem (acl has
 >> > its own defsystem though).  But unless you adopt my approach, you will
 >> 
 >> ACL for Linux includes both a proprietary Franz defsystem and MK:DEFSYSTEM
 >> (check directory contrib/mkant-cmu of the distribution tree).

what I meant was that the *image* does not include mk:defsystem by
default.

at any rate, you just support my point.

-- 
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Bill Gates is great, as long as `bill' is a verb.

Re: what sort of modules should be in clocc

[<do...@co...>]

  >  >> You imagine there is one ideal defsystem for all uses.  I don't buy
  >  >> that.  A system that supports lots of complex features is not worth
  >  >> the trouble for simple uses.  Just like defsystem is not worth the
  >  >> trouble for very small facilities.
  > 
  > so what?
  > 
  > nobody re-implements make(1) in his/her package, and everyone supplies a
  > Makefile (or a tool to build one).
  > 
  > defsystem on lisp is just like make(1) on unix.  people should assume
  > that there is one on the host lisp and use it for everything instead of
  > reimplementing it.  if you run into limitations, complain, fix, or
  > whatever, but don't duplicate the exisiting functionality.
  > 

  > Again, Don, IMO your position is inconsistent: you are prepared to load
  > several packages which do more or less the same, while worrying about
  > loading some extra string-parsing routines which you might actually use
  > (I bet you wouldn't use two different build routines).
If a system has its own build routine  it's probably a very large
system and the build routine is a tiny part of it.  Therefore you are
not getting (in a relative sense) a lot of code you don't need.  Also,
unless the build routine does a lot that mk defsystem does not, it's
probably a whole lot smaller, since it's specific to this particular
system.
I find all this consistent with my desire to avoid large amounts of 
code that is not needed.

  > 
  >  >> What the downloading user then needs (I don't know what we have now)
  >  >> is (1) a tar/gzip bundle of all the files that make up one system so
  >  >> he doesn't have to find and download them separately, and (2) some
  >  >> facility for tracing the dependencies among systems that helps him
  >  >> to download the transitive closure of those systems needed by the
  >  >> one he wants.  Since we do seem to have versioning, it would be nice
  >  >> if these things were version sensitive.  That is, the "database" I
  >  >> have in mind should indicate that system get-quote version 3.2
  >  >> relies on system web-interface version 5.3.  If I want to load
  >  >> get-quote 3.2 and also animals 4.5, and one of these relies on base
  >  >> 2.1 while the other relies on base 2.2, there's an incompatibility.
  >  >> (BTW, this is the kinds of thing that is supported by on of the
  >  >> build facilities I mentioned earlier.)
  > 
  > I am pretty sure that mk:defsystem can do that now (or can be easily
  > taught to do this).

I see no evidence of that.  What I see is the ability to load or
compile a given version of a system.  However there is no notion of
dependency of one version of one system on a given version of another.
So loading version 1.1 of system 1 will call load on its dependent
systems without a version, or perhaps you could bind *version* and
load version 1.1 of all of them, but this is not what I want either.

The other part of the problem is that, even if you can teach defsystem
to do this, we need it to work on the server.  The user who wants 
animals 4.5 wants the server to tell him that this transitively
requires the following systems (and versions) and offer to get those
for him at the same time.  Ideally the systems you need could all be
packaged into one archive for you.

Re: what sort of modules should be in clocc

[Paolo A. <am...@mc...>]

On 31 Jan 2000 12:22:44 -0500, you wrote:

> now, wait a second - *currently* no CL comes with mk:defsystem (acl has
> its own defsystem though).  But unless you adopt my approach, you will

ACL for Linux includes both a proprietary Franz defsystem and MK:DEFSYSTEM
(check directory contrib/mkant-cmu of the distribution tree).


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/

Re: what sort of modules should be in clocc

[Stig E. S. <st...@ii...>]

On 31 Jan 2000, Sam Steingold wrote:

> now, wait a second - *currently* no CL comes with mk:defsystem (acl has
> its own defsystem though).  But unless you adopt my approach, you will
> be loading 4 different defsystems whenever you load 4 different
> packages.  this is a chicken-and-egg problem - defsystem will not be
> standardtized until everyone uses it, and people will not use it until
> it is standard, and I suggest that people start fixing the problem by
> using mk:defsystem, which is the best available candidate for
> standardtization.

Both ACL and Lispworks come with their own defsystems but I think
they both provide mk:defsystem in their contribution directories. 

But was the license issues cleared with mk:defsystem, can it be used
with LGPL/GPL/BSD-Style code?  I recall MK coming with a statement
on cll but a few issues was mentioned in the debate that followed. 

------------------------------------------------------------------
Stig Erik Sandoe     st...@ii...    http://www.ii.uib.no/~stig/

Re: what sort of modules should be in clocc

[Sam S. <sd...@gn...>]

>>>> In message <200...@is....>
>>>> On the subject of "Re: what sort of modules should be in clocc"
>>>> Sent on Sat Jan 29 15:15:10 EST 2000
>>>> Honorable Don Cohen <do...@co...> writes:
 >> 
 >> You imagine there is one ideal defsystem for all uses.  I don't buy
 >> that.  A system that supports lots of complex features is not worth
 >> the trouble for simple uses.  Just like defsystem is not worth the
 >> trouble for very small facilities.

so what?

nobody re-implements make(1) in his/her package, and everyone supplies a
Makefile (or a tool to build one).

defsystem on lisp is just like make(1) on unix.  people should assume
that there is one on the host lisp and use it for everything instead of
reimplementing it.  if you run into limitations, complain, fix, or
whatever, but don't duplicate the exisiting functionality.

now, wait a second - *currently* no CL comes with mk:defsystem (acl has
its own defsystem though).  But unless you adopt my approach, you will
be loading 4 different defsystems whenever you load 4 different
packages.  this is a chicken-and-egg problem - defsystem will not be
standardtized until everyone uses it, and people will not use it until
it is standard, and I suggest that people start fixing the problem by
using mk:defsystem, which is the best available candidate for
standardtization.

Again, Don, IMO your position is inconsistent: you are prepared to load
several packages which do more or less the same, while worrying about
loading some extra string-parsing routines which you might actually use
(I bet you wouldn't use two different build routines).

 >> I should be able to get the url stuff without getting the animals or
 >> gnuplot stuff

you can do that now.
OTOH, if you load gq.lsp (aka GetQuote), you will need gnuplot since gq
includes routines for history plotting.
if you never call those and skip loading gnuplot, you will do fine.

 >> On the other hand, if he breaks cllib into 10 systems, there will be
 >> a lot of dependencies between them.  I don't mind that, as long as
 >> those are really essential dependencies, e.g., getting stock quotes
 >> off the web relies on web stuff.

there will be much fewer dependencies than you think.
please look at *current-project* in base.lsp

 >> What the downloading user then needs (I don't know what we have now)
 >> is (1) a tar/gzip bundle of all the files that make up one system so
 >> he doesn't have to find and download them separately, and (2) some
 >> facility for tracing the dependencies among systems that helps him
 >> to download the transitive closure of those systems needed by the
 >> one he wants.  Since we do seem to have versioning, it would be nice
 >> if these things were version sensitive.  That is, the "database" I
 >> have in mind should indicate that system get-quote version 3.2
 >> relies on system web-interface version 5.3.  If I want to load
 >> get-quote 3.2 and also animals 4.5, and one of these relies on base
 >> 2.1 while the other relies on base 2.2, there's an incompatibility.
 >> (BTW, this is the kinds of thing that is supported by on of the
 >> build facilities I mentioned earlier.)

I am pretty sure that mk:defsystem can do that now (or can be easily
taught to do this).

-- 
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Flying is not dangerous; crashing is.