On 4/4/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
(*) Yes, I know that the core Perl distribution includes many modules,
but ask any P5Porter and he'll answer you that the core is over-crowed
and that all core modules that can be made dual-life should be released
on the CPAN.
I
Anyway, i just wanted to add this because I dont think that you can
take it for granted that all perl5porters believe the core module set
should be as restricted as possible. I dont. I believe that the core
should contain out of the box enough support for the various platforms
that perl runs on
# New Ticket Created by Andy Lester
# Please include the string: [perl #38844]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38844
The lint target needs to be renamed to splint.
Then create a new lint target to
demerphq wrote:
On 4/4/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
(*) Yes, I know that the core Perl distribution includes many modules,
but ask any P5Porter and he'll answer you that the core is over-crowed
and that all core modules that can be made dual-life should be
Many module authors set a design objective of making their modules
dependent only on core modules. This is a comment that I see on a
regular basis.
When I hear or read that, I always wonder if the author realised that
core modules is something dependant on the Perl distribution version.
For
Almost a year ago (2005-04-27), I wrote the list asking a question about
junctions.
Specifically, the ability to find the intersection, union, etc of a list.
my $matches = any( @x_chars ) eq any( @y_chars );
my $match = $matches.pick;
all( any() eq any() );
Patrick Michaud offered an infix myeq
demerphq wrote:
On 4/4/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
(*) Yes, I know that the core Perl distribution includes many modules,
but ask any P5Porter and he'll answer you that the core is over-crowed
and that all core modules that can be made dual-life should be released
on
On Tue, 04 Apr 2006 16:20:09 +0200, David Landgren [EMAIL PROTECTED] wrote:
demerphq wrote:
On 4/4/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
(*) Yes, I know that the core Perl distribution includes many modules,
but ask any P5Porter and he'll answer you that the core is
Who was it who was working on the global CPAN dependency graph, to
figure out what module was dependent on what? Whatever became of that? I
think hard numbers that stand on their own merits are about the only way
to get new stuff into core. Let the early adopters try out non-CPAN
low-level
On Tue, Apr 04, 2006 at 09:16:23AM -0400, Joshua Gatcomb wrote:
: Almost a year ago (2005-04-27), I wrote the list asking a question about
: junctions.
: Specifically, the ability to find the intersection, union, etc of a list.
Junctions are not intended for that use. We have Sets for that now.
Moin,
On Tuesday 04 April 2006 18:30, Adam Kennedy wrote:
Who was it who was working on the global CPAN dependency graph, to
figure out what module was dependent on what? Whatever became of
that? I think hard numbers that stand on their own merits are about
the only way to get new stuff
On the other hand, if junctions really are sets of sets, then maybe it's
a mistake to autocoerce junctions to sets by swiping their internal set
of values. Arguably any(1,2,3) should coerce not to
(1,2,3)
but to
(
(1),
(2),
(3),
(1,2),
(1,3),
Will perl6 Sets include set negation and/or a universal set? In
effect, an internal flag that says, this set contains every possible
element _except_ the ones listed?
--
Jonathan Dataweaver Lang
On 4/4/06, Larry Wall [EMAIL PROTECTED] wrote:
On Tue, Apr 04, 2006 at 09:16:23AM -0400, Joshua Gatcomb wrote:
Junctions are not intended for that use. We have Sets for that now.
Ok. So this will work out of the box if you use the right tool. Cool.
The cabal already decided once (in
On Tue, Apr 04, 2006 at 11:02:55AM -0700, Jonathan Lang wrote:
: Will perl6 Sets include set negation and/or a universal set? In
: effect, an internal flag that says, this set contains every possible
: element _except_ the ones listed?
Arguably, that's what none() is. And all() is the only
On Tue, Apr 04, 2006 at 12:02:55 -0700, Jonathan Lang wrote:
Will perl6 Sets include set negation and/or a universal set? In
effect, an internal flag that says, this set contains every possible
element _except_ the ones listed?
Sure! How else will we implement the garbage collector?
;-)
--
Moin,
On Tuesday 04 April 2006 01:35, Sébastien Aperghis-Tramoni wrote:
Tels wrote:
Moin,
Hello Tels,
OTOH, who still runs pre-5.8.x code deserves what they get.
There are horrible bugs in older Perls, and I don't know why people
still
insist using insecure, buggy and
On Tuesday 04 April 2006 10:32, Tels wrote:
There is also the point that supporting ancient Perls means you
can't use all the new, wonderfull features that were added to later
versions of Perl, like our, warnings etc.
This to me is the biggest problem. After 6 years, is it finally okay for
Larry Wall wrote:
On Tue, Apr 04, 2006 at 11:02:55AM -0700, Jonathan Lang wrote:
: Will perl6 Sets include set negation and/or a universal set? In
: effect, an internal flag that says, this set contains every possible
: element _except_ the ones listed?
Arguably, that's what none() is.
Moin,
On Tuesday 04 April 2006 01:50, Tyler MacDonald wrote:
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote:
OTOH, who still runs pre-5.8.x code deserves what they get.
There are horrible bugs in older Perls, and I don't know why people
still
insist using insecure, buggy and
As a followup to my previous early opinions:
I've done some [more] reading up on value types. I'm now more sure now than
ever that my initial decision was the right one: Parrot 1.0 will _not_ have
native support for anything like value types. Parrot 1.0's type universe
will consist entirely of
On Tue, Apr 04, 2006 at 11:23:14AM -0700, Jonathan Lang wrote:
: Larry Wall wrote:
: On Tue, Apr 04, 2006 at 11:02:55AM -0700, Jonathan Lang wrote:
: : Will perl6 Sets include set negation and/or a universal set? In
: : effect, an internal flag that says, this set contains every possible
: :
Larry Wall wrote:
You're confusing the map with the territory. We're trying to decide
*how* Junctions are like Sets, not defining them into two different
universes. I'm saying that all() is the Junction tha is most like
a Set. A none() Junction can be viewed as the specification for an
* demerphq [EMAIL PROTECTED] [2006-04-04 08:05]:
Personally i think the core is too big argument is a
red-herring given that bandwidth is as cheap as it is these
days. Adding a couple of modules to core would increase the
rsynch time by what a second or two? It would suck up a couple
of extra
On Tuesday 04 April 2006 12:16, A. Pagaltzis wrote:
Is it any wonder that people say core is too big?
Want more heresy?
If the core contained more modules, there'd be even less possibility of
getting managed hosts or hostile system administrators in really picky
environments to install or
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #38849]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38849
In 'include/parrot' there are some header files, like runops_cores.h,
that
On 4/4/06, Larry Wall [EMAIL PROTECTED] wrote:
On the other hand, if junctions really are sets of sets, then maybe it's
a mistake to autocoerce junctions to sets by swiping their internal set
of values. Arguably any(1,2,3) should coerce not to
(1,2,3)
but to
(
(1),
On 4/4/06, Jonathan Lang [EMAIL PROTECTED] wrote:
OK, then; what would be the specification for a _single_ set that
contains everything that doesn't intersect with a corresponding all()
Junction (the sort of thing that I'd use if I wanted to find the
largest subset of A that doesn't intersect
2006/4/4, Luke Palmer [EMAIL PROTECTED]:
I don't follow. Why is that the representation of any(1,2,3)? Is
this a disjunctive normal form; i.e. is 2 any(1,2,3) equivalent to
the test:
2 1
|| 2 2
|| 2 3
|| 2 1 2 2
|| ...
2 1
| 2 2
| 2 3
which ends up being the
* H.Merijn Brand [EMAIL PROTECTED] [2006-04-04T10:40:39]
And then still people make more of the same. Take Getopt::Long. A perfect and
very functional module. Full of features, matured, and actively maintained.
Now go look at CPAN, and see how many people either do not like it or find
other
Ricardo SIGNES wrote:
* H.Merijn Brand [EMAIL PROTECTED] [2006-04-04T10:40:39]
And then still people make more of the same. Take Getopt::Long. A perfect and
very functional module. Full of features, matured, and actively maintained.
Now go look at CPAN, and see how many people either do not
On Mon, Apr 03, 2006 at 10:32:12PM +1000, Adam Kennedy wrote:
Yitzchak Scott-Thoennes wrote:
On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote:
B when it breaks, end-users cannot fix the problem for themselves, they
need to bug the author and he has to release a new version. (Good luck
chromatic wrote:
On Tuesday 04 April 2006 10:32, Tels wrote:
There is also the point that supporting ancient Perls means you
can't use all the new, wonderfull features that were added to later
versions of Perl, like our, warnings etc.
This to me is the biggest problem. After 6 years, is
On Tuesday 04 April 2006 21:57, Adam Kennedy wrote:
Seeing as the worst support cases are about 10 years in a variety of
countries and situations, I think that is what we should be aiming for
for highly used CPAN modules.
Which last time I checked is now 5.005.something
So I aim there.
34 matches
Mail list logo
