During OSCON, over beers with Chip, I made the observation that there is
probably a large group of people that would like to contribute a few
hours per work to Parrot development but that there are no TODO tasks
that can be done reasonable accomplished at that level of commitment.
Chip stated that
Is it just me or is it b0rked to have a file named src/parrot.c that
does nothing while the entry point for the parrot executable lives in
imcc/main.c?
-J
--
On Wed, Aug 31, 2005 at 04:04:45PM -0700, chromatic wrote:
> Hi all,
>
> In a recent discussion with Chip and Leo, the idea came up to ask
On 9/3/05, Stuart Cook <[EMAIL PROTECTED]> wrote:
> On 03/09/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > A multi sub is a collection of variants, so it doesn't have arity,
> > each variant has arity.
> >
> > I'd say it 'fail's.
>
> But if the reason you're calling `&foo.arity` is to answer the
On Sun, Sep 04, 2005 at 00:27:39 +1000, Stuart Cook wrote:
> if &foo.accepts(:pos(1..3) :named :code) { ... }
I prefer this api... Arity is ambiguous will multiply variadic args.
We have any number of positionals, nameds, and zero, one or two
slurpies.
> None of this really answers the question
On 03/09/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> A multi sub is a collection of variants, so it doesn't have arity,
> each variant has arity.
>
> I'd say it 'fail's.
But if the reason you're calling `&foo.arity` is to answer the
question "Can I call this sub with three arguments?" then that
> ExtUtils::Command provides Unix commands on several platforms.
> So it make sense to use ExtUtils::Command per default and not only for
> Win32.
This is now applied in r9128. Please tell me about aventual problems.
CU, Bernhard
--
/* [EMAIL PROTECTED] */
On Fri, Sep 02, 2005 at 17:56:39 +0200, Ingo Blechschmidt wrote:
> Hi,
>
> multi foo ($a) {...}
> multi foo ($a, $b) {...}
>
> say &foo.arity;
> # die? warn and return 0? warn and return undef? return 1|2?
A multi sub is a collection of variants, so it doesn't have arity,
eac
On Sat, Sep 03, 2005 at 11:45:33 +0300, Yuval Kogman wrote a lot.
I'd like to summarize:
* if operators are not special than they are defined in perl 6
(maybe)
* if operators are defined in terms of other operators, then
overriding an operator may interfere with t
On Thu, Sep 01, 2005 at 17:12:51 +, Luke Palmer wrote:
> On 9/1/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > On Wed, Aug 31, 2005 at 13:43:57 -0600, Luke Palmer wrote:
> > > Uh yeah, I think that's what I was saying. To clarify:
> > >
> > > sub foo (&prefix:<+>) { 1 == 2 }# 1 and 2
