Re: RFC 260 (v1) More modules

2000-09-22 Thread Chaim Frenkel

 "AD" == Andy Dougherty [EMAIL PROTECTED] writes:

AD Making the build process fairly modular and keeping a Config.pm
AD record of what this particular perl binary can and can not do are
AD both seemingly reasonable goals for the perl6-build process.

Please, make the Config.pm be internal. So it can not be seperated from
the executable.

chaim
-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183



RE: RFC 260 (v1) More modules

2000-09-21 Thread Garrett Goebel

From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
 
 Doh!  Don't read email for two days and look what happens.  Its like
 going on vacation and leaving the iron on.

Speaking of which, I just re-read my previous email, and I want apologize
for contributing to the flamebait. Sorry. Hopefully this post will be more
constructive...


 On Tue, Sep 19, 2000 at 04:08:21PM -0400, Adam Turoff wrote:
  Are you proposing something like this:
  
  Standard distribution: 
  1: Everything (core, docs, standard modules)
  
  Alternative Distribution: 
  2a: core language (+ pragmatic modules)
  2b: standard modules
  2c: docs (possibly split into tutorials and reference)
 
 #1 would be the primary distribution.  Definately #1.  #2a..2c would
 be made available, but in a slightly less obvious way.  When you go to
 download perl-current.tar.gz, you get #1.  #2a..c wouldn't even be in
 the same directory.

I share Tom's view here. I think it would be a bad idea to distribute the
source tarball for the Core Perl Distribution without documentation. Has
anyone made a case for the size of download issue? I was under the possibly
mistaken impression that this was a size of install thing.


 the simplest way to do this is to make the default
 distribution contain the docs and let the user hunt
 a bit for the tarball without docs.

If you're talking binary distributions I'd agree. If you're talking
source... I'd differ. I'd rather see everyone start with the same package,
and enable them to strip it down as they need. This goes back to whether its
a size of install or download issue.


   Another is to provide several different install options.
   "make install" installs everything, as usual.  
   "make small_install" installs just the current set of
   modules.  "make tiny_install" installs a bare minimum,
   not even docs.

Hmm. Might want to be a bit more fine grained. How about the heretical
option to strip pod and comments from the standard library?


  How much of the problem is the size of the install vs. the size of
  the download?
 
 It would be nice if I could have one or two be full installs
 and the rest minimalist.

Size of install is my issue.

But, to bring this back to a Standard Library discussion... When does the
need arise to draw a distinction between "The Standard Library" and
"Standard Libraries"?  The size of the standard library seems to be ever
expanding... 

Garrett



Re: RFC 260 (v1) More modules

2000-09-21 Thread Tom Christiansen

I don't think that the documentation should be removed from the core
distribution, BUT I do think that there should be an "easter egg" that
allows people to build a Perl distribution without documentation or
whatever else they choose.  There have been times that I've
wanted/needed to build a "tinyperl" (even smaller than "miniperl" :-) )
and I've had to hack things significantly to Make It So.

The documentation is 700k compressed, or about thrice that otherwise.

% cat /usr/local/perl/lib/pod/*.pod | gzip -9 -v | wc
 65.7%
2564   15232  696465 

% cat /usr/local/perl/lib/pod/*.pod | wc 
   61212  313779 2031560 

If you remove it, you will no longer have a functioning Perl distribution.

% perl -Mdiagnostics -we 'print $a + 1'
Name "main::a" used only once: possible typo at -e line 1 (#1)

(W once) Typographical errors often show up as unique variable names.
If you had a good reason for having a unique name, then just mention
it again somehow to suppress the message.  The our declaration is
provided for this purpose.

Use of uninitialized value in addition (+) at -e line 1 (#2)

(W uninitialized) An undefined value was used as if it were already defined.  It 
was
interpreted as a "" or a 0, but maybe it was a mistake.  To suppress this
warning assign a defined value to your variables.


% sudo chmod 0 /usr/local/lib/perl5/5.6.0/pod/perldiag.pod

% perl -Mdiagnostics -we 'print $a + 1'
couldn't find diagnostic data in /usr/local/lib/perl5/5.6.0/pod/perldiag.pod 
/home/tchrist/perldoc/lib /usr/local/lib/perl5/5.6.0/OpenBSD.i386-openbsd 
/usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0/OpenBSD.i386-openbsd 
/usr/local/lib/perl5/site_perl/5.6.0 
/usr/local/lib/perl5/site_perl/5.00554/OpenBSD.i386-openbsd 
/usr/local/lib/perl5/site_perl/5.00554 
/usr/local/lib/perl5/site_perl/5.005/OpenBSD.i386-openbsd 
/usr/local/lib/perl5/site_perl/5.005 /usr/local/lib/perl5/site_perl . -e at 
/usr/local/lib/perl5/5.6.0/diagnostics.pm line 241, POD_DIAG line 549.
Compilation failed in require, POD_DIAG line 549.
BEGIN failed--compilation aborted, POD_DIAG line 549.
Exit 2


+---+
| Permit me to repeat: if you remove the documentation, you will no |
| longer have a functioning Perl distribution.  |
+---+

And yes, I intend to make more of these, too.

--tom



Re: RFC 260 (v1) More modules

2000-09-21 Thread Andy Dougherty

On Thu, 21 Sep 2000, Michael G Schwern wrote:

 Sounds like a seperate RFC.  Like I said, I want to reverse some of
 the philosophies that have kept things like LWP out of the core for so
 long.

The differing timescales of development by the myriad different authors
involved has always been one of the biggest obstacles.  We've averaged
approximately one major release per year for the past 6 years.  Getting
everbody in sync for that one release is likely to be pretty hard.

In the early days of 5.00*, most modules were evolving far too rapidly to
try to freeze and incorporate into the main distribution.  A lot of them
were too non-portable too and didn't necessarily work in a lot of places
where perl did.  More recently, in the 5.005 - 5.6.0 era, many modules
have stabilized and the synchronization problem is somewhat smaller.

Whether or not the early days of perl6.0.x will again be times of rapid
module evolution (in which case freezing too many of them to ship with
6.0.0 might be a mistake) is not obvious to me at this point.

This is not to argue either for or against "more modules", nor to argue
that the perl5 distributions have been perfect.  But I do wish to
emphasize that many (but not necessarily all) of "the philosophies that
have kept things ... out of the core for so long" are actually reasonable
philosophies that I hope are continued under perl6.

Specifically, I think a necessary (but not necessarily sufficient) set of
criteria ought to include at least the following:

1.  The module is stable.  That is, during the lifetime of the relevant
perl release (e.g. 1 year in the perl5 universe) no major changes are
expected.  (Maintenance fixes on the perl6.even.x time-scale are of
course, ok.)

2.  The module works (or at least passes its own regression tests) on most
(if not all) of the platforms that perl supports.  (Note that "work" may
simply mean "fail gracefully" in some circumstances.  I wouldn't really
expect System V IPC to work on the Palm Pilot, for example.)

3.  The module is likely to be sufficiently useful to a sufficiently broad
set of perl users that inclusion in the main distribution is worth the
effort involved.  (As a corollary, the larger and the more complex the
module, the higher this hurdle ought to be.  A module that would double
the size of the perl .tar.gz distribution had better be very useful
indeed.)

4.  The module is of sufficiently high quality.

5.  The module author agrees.


During my time as pumpkin holder, nearly all modules proposed for
inclusion quickly fell over under either 1, 2, or 5.

I suspect that some that have fallen afoul of numbers 2 or 3 might not
have done so had a champion stepped forward and said (in effect) "I want
this in the core and I will personally take care of whatever patching and
support is needed to make it so."

Items 3 and 4, of course, call for more difficult judgments, and this RFC
is a good start towards spelling them out more carefully.  That is a quite
welcome development.  You might also want to comment explicitly on the
SDK and the balance between more modules in the standard library and
more effort on developing an SDK.  Then again, you might not prefer to go
there :-).

-- 
Andy Dougherty  [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042






Re: RFC 260 (v1) More modules

2000-09-21 Thread Michael G Schwern

On Thu, Sep 21, 2000 at 12:23:25PM +0200, Bart Lateur wrote:
 On 19 Sep 2000 19:41:20 -, Perl6 RFC Librarian wrote:
 Perl should come distributed with more modules.
 
 I know of people/sites where installing the whole lot of Perl just to
 run a tiny script, is not acceptable as an option.

Please read the entire RFC before responding.  Note the section on
breaking up the distribution into smaller pieces.


-- 

Michael G Schwern  http://www.pobox.com/~schwern/  [EMAIL PROTECTED]
Just Another Stupid Consultant  Perl6 Kwalitee Ashuranse
But honestly, the more expensive the better. Just depend on how much you
trust us.
 --Alex Chiu, Immortality Guy



Re: RFC 260 (v1) More modules

2000-09-20 Thread Chaim Frenkel

 "CRT" == Casey R Tweten [EMAIL PROTECTED] writes:

CRT rm them.

Sure, and I can sling around the manpages after they have been installed
in the wrong place. I can also run all of the make files by hand.

If I can go in and simply comment out the INSTALL section of the makefile
(which I have to tweak occasionally) why not simply make it an option.

We aren't discussing taint mode. We are trying to make some poor 
sysadmins life easier.

I've got scripts that chroot and then run installation into a naked
tree. Then after exiting the environment I have a clean nice place
to work from either making a tarball or just using SysV packaging.

Why make life hard, an option can be a lot easier than having to
manually rm stuff. (I.e. rm everything except perldiag.pod.)
And what about when the installation changes? Or 

Perl is about making things easy.

chaim
-- 
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]   +1-718-236-0183



Re: RFC 260 (v1) More modules

2000-09-19 Thread Dave Rolsky

On 19 Sep 2000, Perl6 RFC Librarian wrote:

 =head2 Which modules?

Just to throw out some possibilities for discussion:

Date::Manip or some other date manipulation module.  Date::Manip is cool
but awfully huge, I know.

Can't think of others right at this moment.

-dave

/*==
www.urth.org
We await the New Sun
==*/