[ On Thursday, April 29, 1999 at 12:13:54 (+0200), Jaromir Dolecek wrote: ]
> Subject: Re: CVSup collections for a NetBSD CVS tree
>
> If CVSup knows all the dirty details of RCS and CVS and in function
> is something like anoncvs (though more efficient), I don't quite understand
> why it was not written as enhancement of anoncvs and is maintained separately.

Don't ask me -- ask its author.

> And more -- the person who wrote CVSup wrote it in such a obscure and
> dying language as the Modula-3 is. Really unfortunate decision. They
> can't even share any code with CVS, they HAVE to rewrite the whole thing.

As I understand it Modula-3 is *not* a dying language, and it's also not
anywhere near as limited or "academically" oriented as it's namesake,
Modula-2.  People have told me that they think it probably shouldn't
have even been given the name "Modula" because that's done more to hurt
it than anything else.  I'm personally not a Modula-3 advocate -- I've
never written even a line of it.  Since some people writing in this
thread seem to like to pontificate in the dark, perhaps I can shed a wee
bit of light by quoting a paragraph from the web that concisely
describes the language and its benefits:

                              Modula-3 Home Page
   
  Welcome to the world of Modula-3! (TM)
   
   As Sam Harbison writes in his book Modula-3,
   
     Modula-3 is a member of the Pascal family of languages. Designed in
     the late 1980s at Digital Equipment Corporation and Olivetti,
     Modula-3 corrects many of the deficiencies of Pascal and Modula-2
     for practical software engineering. In particular, Modula-3 keeps
     the simplicity of type safety of the earlier languages, while
     providing new facilities for exception handling, concurrency,
     object-oriented programming, and automatic garbage collection.
     Modula-3 is both a practical implementation language for large
     software projects and an excellent teaching language.

In any case this side of the argument is so totaly bogus that it's just
not funny.  You can ask this question about any number of projects
written in languages you don't know.  Why didn't James Clark write groff
in C?  The only correct answer is to ask the author, and if that's not
possible then you'll have to learn the language and discover for
yourself why they chose it.  Many people tackle big projects in new
languages just so they can learn the new language.  (I think that was
James Clark's reason for using C++ in groff, but it was at a party a
long time ago when I asked him this so I'm not sure of my memory.)

I think this quote from from the CVSup FAQ sums things up pretty well:

   33. I've heard lots of horror stories about building CVSup from the
       sources. Why is that?
       The basic problem is that CVSup is written in the programming
       language NotC. What is NotC? Well, to most people, it really
       doesn't matter. The important thing is that NotC is not C.
       Consequently, it takes a little extra work to use it.
   [[ .... ]]

I don't see anything wrong with having an application written in
Modula-3, provided that I don't have to maintain it.  However that's not
to say that I couldn't -- it's a very readable and relatively simple
language.  If I want to use that application then I will try to find a
platform that it's supported on -- it's just that simple.  I'd even run
FreeBSD binaries to transfer the repository if that were necessary, but
of course that *would* be bogus when the source is available and already
usable on NetBSD.

> Such approach makes me scream ;-)

The mere fact that NetBSD users and developers seem afraid of this tool
makes me scream!  ;-)

> Somebody mentioned porting M3 to (n-2) NetBSD architectures. Well, it's
> doable, but M3-based CVSup has some more disadvantages:
> 1) not many programmers are common with M3 (the amount of such
> 	programmers is IMHO compared with COBOL programmers) -- 
> 	modifying CVSup to better fit NetBSD environment and
> 	bug fixing would be quite hard or near to impossible
> 2) need to install (potentially huge) environment for M3 for just
> 	ONE application (not such a big problem with binary packages,
> 	but still)

I find that people not willing to install larger packages are often the
very same people who are comfortable with binaries....

> 3) M3 folks have to re-do all the hard work of gcc/egcs folks
> 	of optimizing compiler for all the archs/oses it might run on;
> 	if we would decide to use it for tool NetBSD relies on, we
> 	would have to actually SUPPORT it on our side -- any voluteers
> 	willing to do it ?

I don't think that's quite the issue you claim it is.  Besides, the hard
work is already being done by M3 fanatics.  NetBSD wouldn't necessarily
*rely* on CVSup any more than it relies on any other third-party
package, such as emacs for example.

> Is there any great demand for M3 under all the NetBSD architectures ?
> If not, porting it just for one application seems to me like enormous
> wasting of valueable human resources. Rewriting the application in C
> seems like much better idea -- and merging to cvs is the way to go.

Well, until someone rewrites CVSup in C we'll just have to use the M3
implementation on the platforms where it is supported.

> NOT porting M3 to all NetBSD archs or CVSup to C is not an option.
> I would be really sad, if NetBSD way of thinking would change to:
> "Well, we distribute our source tree via highly efficient and
> fast CVSup service. Enjoy."
> "Ah, forgot to mention. You have to have i386 or alpha to use it."

You've not been paying attention!  That *is* the option!  Besides, it's
merely a matter of attitude adjustment and expectation management:

	There are several ways to access the NetBSD CVS repository:
	1. CVS itself using anonymous CVS access.
	2. FTP a copy of the entire repository.
	3. Use SUP to track a copy of the repository.
	4. If you have an i386 or alpha (and soon m68k and sparc) then
           you can also use the CVSup system.

> One reason I love NetBSD is we are treating all the archs equal -- I can
> choose whatever hardware I happen to have and am still able to work
> more-or-less the same way.

That's the biggest load of "bull stuff" there is!  Not all NetBSD ports
are treated as equal.  I challenge anyone claiming this to obtain at
least one, and possibly two, machines in every supported architecture
and to use all of those machines on a daily basis and to dilligently
upgrade each machine to the latest NetBSD software every time.  You'll
find so many differences, discrepancies, etc., that you'll probably
start pulling your hair out long before you've done one iteration of
upgrades.

This is *not* a bad thing.  This just comes with the territory.

In any case, we're not talking about the basic OS functionality -- we're
only talking about one highly specialized and narrowly used application.
Get off your high horses and try it before you put it down.  Don't tell
me that *I* can't use something just because *you* don't want to, or
can't use it.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>