Re: RFC 260 (v1) More modules
"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
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
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
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
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
"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
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 ==*/