On Thu, 30 Jul 2009, Will Coleda wrote:
On Thu, Jul 30, 2009 at 8:17 PM, Timothy S. Nelson<[email protected]> wrote:
On Thu, 30 Jul 2009, James E Keenan wrote:
1. Discussion of the benefits of adding any particular library to our
"standard set" should also include any disadvantages or risks that that
addition may pose. Potential downsides would include: More complexity in
configuration? Slows down the executables? Bigger memory footprint?
Hmm. Have we also considered Larry's reasons for including as little
as possible[*] in the Perl6 standard libraries? Not that I'm saying we have
to go with this, just that it might be a thought.
[*] FSVO "little" and "possible"
Obligatory mention that parrot NE Perl 6 ...
I was trying to say that, but didn't communicate it well. Thanks :).
.... but considering that point in the context of parrot itself is
probably worth doing.
Note that we're not talking about bundling the C libraries, just
probing for them and having some wrapper PIR to invoke them; the
footprint on that should be low. We also don't have a CPAN to fall
back on; if we're going to want to provide things we don't ship core,
we need a mechanism for users and distros to bundle them in if they
want; having that will make the "in or out" decision for each library
easier to make, I think.
I vote packaging system++. But it has to work well with the packaging
systems that are native to the various OSs.
HTH,
---------------------------------------------------------------------
| Name: Tim Nelson | Because the Creator is, |
| E-mail: [email protected] | I am |
---------------------------------------------------------------------
----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
