[EMAIL PROTECTED] (Dan Sugalski) writes:
[...]
> It's an ongoing fight between the "go get the libs and install them"
> folks and the "self-contained distribution" folks. I'm in the latter
> category. :)
As Larry said, "self-contained" is good for users. For developers
(and CVS) "go get the libs
At 11:49 AM -0800 3/4/04, Robert Spier wrote:
> >I'd like to remove non-modified, non-parrot Perl modules from lib
>and install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more than it's going to run apt-get on
systems tha
At 4:45 PM +0100 3/4/04, Michael Scott wrote:
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib
and install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more
On 6 Mar 2004, at 05:31, Robert Spier wrote:
[...]
The problem isn't today. It's the "trend" and next month, when
someone decides they need to add some other module, and has a
precedent to follow. Then, suddenly we end up with 30 different
modules included in our distribution, each one changed
> >
> > "within reason". Thats where we're way off right now.
>
> Let's keep a bit of perspective here. The non-Parrot:: contents of lib
> accounts for only 4.6% of the non-ICU content (and only 1.5% if you
> count ICU in the total size). It's difficult to see that as
> unreasonable, or as "bl
On Mar 4, 2004, at 7:50 PM, Robert Spier wrote:
IMHO, the releases better include everything necessary to build the
application, within reason. Consistency and simplicity counts for a
lot.
Why create headaches we don't need?
"within reason". Thats where we're way off right now.
Let's keep a bit
> But once we start expecting people in the real world to compile this thing
> on their boxes in order to install perl, it would be extremely foolish to
> make them manually download and install perl6 + parrot + icu + perl5 +
> cpan modules 1 through 10, all from different sources.
Try building
At this point in the development cycle you can certainly make such
arguments (although I would tend to fall on the side of consistency
myself, at least for things that really Don't Matter in the grand scheme
of things, such as POD modules).
But once we start expecting people in the real world
> The determinism seems perhaps worth the bloat. It's quite localize
> bloat after all.
I disagree.
We _want_ a heterogeneous environment -- a homogeneous environment
doesn't exist in the real world -- most of your concerns were with
tracking down the issues. Since we have parrotbug now (or rea
There's no reason to include large, independently maintained modules
like Pod::Simple in the parrot CVS tree and tarball. It just turns
into a maintenance nightmare, should we ever start modifying these
things.
[...]
I don't understand why you are insisting on including these thin
> > No. Sorry, definitely not. Parrot's config isn't going to install
> > perl modules off the 'net any more than it's going to run apt-get on
> > systems that support it. We either provide it or do without.
>
> What about ICU. There is already a new version pending (again).
Since we haven't act
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> No. Sorry, definitely not. Parrot's config isn't going to install
> perl modules off the 'net any more than it's going to run apt-get on
> systems that support it. We either provide it or do without.
What about ICU. There is already a new version pending
On Thu, Mar 04, 2004 at 03:40:27PM +0100, Michael Scott wrote:
: I'd like to remove non-modified, non-parrot Perl modules from lib and
: install them via CPAN.pm. I have a version here which works, but I
: remember from experience it can be tricky to set up CPAN.pm to work
: behind firewalls, so
> >I'd like to remove non-modified, non-parrot Perl modules from lib
> >and install them via CPAN.pm.
>
> No. Sorry, definitely not. Parrot's config isn't going to install
> perl modules off the 'net any more than it's going to run apt-get on
> systems that support it. We either provide it or
On Mar 4, 2004, at 7:45 AM, Michael Scott wrote:
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib and
install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any m
On 4 Mar 2004, at 15:51, Dan Sugalski wrote:
[...]
I'd like to remove non-modified, non-parrot Perl modules from lib and
install them via CPAN.pm.
No. Sorry, definitely not. Parrot's config isn't going to install
perl modules off the 'net any more than it's going to run apt-get on
systems tha
At 3:40 PM +0100 3/4/04, Michael Scott wrote:
On 7 Feb 2004, at 00:53, Michael Scott wrote:
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote:
- icu
- lib/Test/*
- lib/Pod/*
are all "standard" thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna copying existing wheel
On 7 Feb 2004, at 00:53, Michael Scott wrote:
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote:
- icu
- lib/Test/*
- lib/Pod/*
are all "standard" thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna copying existing wheels, so
I'd
vote for just removing all that fro
On 6 Feb 2004, at 22:32, Leopold Toetsch wrote:
- icu
- lib/Test/*
- lib/Pod/*
are all "standard" thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are gonna copying existing wheels, so
I'd
vote for just removing all that from CVS.
yep
All non-trivial packages have some
Robert Spier <[EMAIL PROTECTED]> wrote:
> Pod::Simple is relatively easy to subclass. And Sean is pretty
> receptive to changes.
[ more referenced source inside ]
- icu
- lib/Test/*
- lib/Pod/*
are all "standard" thingys. I'm not thinking that we are gonna
reinventing wheels nor that we are go
> Suppose I could make a few changes to Pod-Simple, then our problem
> would be solved.
Pod::Simple is relatively easy to subclass. And Sean is pretty
receptive to changes.
> never have occurred to me to shove all of that in CVS. It always
> surprised me a that ICU was there, rather than just
Suppose I could make a few changes to Pod-Simple, then our problem
would be solved.
But, being serious, say I'd decided to use Template-Toolkit, it would
never have occurred to me to shove all of that in CVS. It always
surprised me a that ICU was there, rather than just what was needed to
get
> I can possibly help it, so it's ok by me to delete lib/Pod, if that's
> the consensus.
I'm not sure what the consensus is. But we should probably come to one.
-R
Ah, ok, my bad then. I'd just assumed that, apart from any need for
modification, the other things were there simply to save having to tell
everyone to go off and get them. I don't intend to change Pod-Simple if
I can possibly help it, so it's ok by me to delete lib/Pod, if that's
the consensus
> I've added the Perl modules for the docs tools to lib/Parrot/IO and
> lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes
> (1.03) which they use.
I probably blinked.. but why are we including CPAN modules that we are
not likely to change into the parrot repository?
-R
I've added the Perl modules for the docs tools to lib/Parrot/IO and
lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes
(1.03) which they use.
Running
perl tools/docs/write_docs.pl
should build the html tree in docs/html. I'd be interested to know of
any problems encountered.
26 matches
Mail list logo
