chromatic wrote:
These are the headerizer changes that bother me the most.
Feel free to revert them.
Allison
HaloO,
Buddha Buck wrote:
Is this right? (E,D,D) to (A,C,C) is (4,1,1), with a L1 metric of 6.
(E,D,D) to (D,A,A) is (1,3,3) with an L1 metric of 7. Are you sure
(E,D,D) would bind to (D,A,A)?
Oh, shit. I fail with the simplest of mathematics. Indeed
(E,D,D) binds to (D,A,A). The problem I w
HaloO,
John M. Dlugosz wrote:
When I mentioned this before, there was big flack over mentioning the
way C++ did it. I think that must have been miscommunicated, since I
wasn't even talking about summing all the arguments when he brought up
"Manhattan dispatch".
That he there being me, I jus
TSa wrote:
BTW, what is a flack?
See http://en.wikipedia.org/wiki/Flak_%28disambiguation%29
Originally, (FL)ug(a)bwehr (K)anone -- German 88mm anti-aircraft cannon
of WWII.
Subsequently, any anti-air gun or cannon, particularly when fired at a
position rather than aimed at a particular
Digging a little further into the consequences of null_lib_name.patch,
I see trouble ahead if the new library PMC is cloned into another
interpreter.
The fix lets you create a library PMC with no '_lib_name' property,
but src/dynext.c:Parrot_clone_lib_into assumes that every library
PMC has one.
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #53802]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53802 >
The attached patch mainly cleans up the implementation of GLUT
callbacks, simplify
# New Ticket Created by Stephen Weeks
# Please include the string: [perl #53804]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53804 >
Both rakudo's grammar and STD.pm have this line in token methodop:
| ':'
t/spe
# New Ticket Created by "AVELING BEN"
# Please include the string: [perl #53808]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53808 >
Hi,
I've just received an error message saying:
elseif should be elsif at blah.pl
# New Ticket Created by Stephen Weeks
# Please include the string: [perl #53812]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53812 >
Placeholder vars in rakudo currently augment the parameter list instead
of replacing it
Ben (>):
> I've just received an error message saying:
>
> elseif should be elsif at blah.pl line 103.
>
>
>
> What happened to do-what-I-mean?
>
>
>
> Perl is usually pretty forgiving. In this case, it knows that I should
> have typed elsif, so why does it care that I typed elseif? Why not
# New Ticket Created by Stephen Weeks
# Please include the string: [perl #53814]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53814 >
Rakudo currently passes positional arguments into named parameters of
functions. This
On Wed, May 07, 2008 at 02:12:00AM -0700, Stephen Weeks wrote:
> Rakudo currently passes positional arguments into named parameters of
> functions. This is in violation of S06:748.
>
> sub a (:$a) { say $a }
> a(1);
There's a somewhat significant mismatch between Perl 6's handling of
arguments a
On 2008 May 7, at 4:21, TSa wrote:
BTW, what is a flack?
He's using "flak" (shrapnel; usual usage "catching flak over ...")
without understanding it.
Coming back to how C++ handles static overloading. How is
the sort order of (int *), (int &), (int), (const int *),
(const int &), (const
On 2008 May 7, at 7:21, Carl Mäsak wrote:
Ben (>):
I've just received an error message saying:
elseif should be elsif at blah.pl line 103.
What happened to do-what-I-mean?
I'm not sure laxity among keywords would really be a feature.
Correctly spelled, it's "elsif" in Perl, so why allow mi
On Tue, May 06, 2008 at 09:38:56PM -0700, Patrick R. Michaud via RT wrote:
> I think this ticket is ready to be closed. A lot of the PMC_* items
> were likely fixed as part of the pdd15oo change, and the problem I cited
> has apparently been fixed.
Looking a bit further, there are still a few ins
On Fri Jul 13 18:51:14 2007, coke wrote:
> Someone suggested using the PIR parser written in TGE to output PIR,
> and have *that* be our
> pretty printer.
>
> Good idea. If that happens, just kill the perl module.
Changed my mind. There's no point in keeping a half baked version of
something we k
On Tue, May 06, 2008 at 11:35:20PM -0700, Stephen Weeks wrote:
> Both rakudo's grammar and STD.pm have this line in token methodop:
>
> | ':'
>
> t/spec/S29-list/minmax.t has the following parse failure in a few places,
> though:
>
> is @array.min:{ $^a <=> $^b }, -9,
>
> This doesn
Not long ago, Patrick R. Michaud via RT proclaimed...
> There's a somewhat significant mismatch between Perl 6's handling of
> arguments and Parrot's handling of them; at the moment Rakudo
> is following the Parrot conventions.
>
> My guess at this point is that unless/until Parrot updates its
> c
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #53826]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53826 >
$ svn di -x -u languages/perl6/docs/STATUS
Index: languages/perl6/docs/STATUS
==
Author: larry
Date: Wed May 7 09:07:46 2008
New Revision: 14541
Modified:
doc/trunk/design/syn/S05.pod
Log:
[S05] better characterize Match and Cursor methods
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/
On Wed, May 07, 2008 at 08:11:28AM -0600, Stephen Weeks wrote:
> Not long ago, Patrick R. Michaud via RT proclaimed...
> > There's a somewhat significant mismatch between Perl 6's handling of
> > arguments and Parrot's handling of them; at the moment Rakudo
> > is following the Parrot conventions.
# New Ticket Created by Jerry Gay
# Please include the string: [perl #53834]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53834 >
changes to subrule design in S05 have not yet been reflected in PGE.
specifically,
~ alias
On Fri, May 02, 2008 at 12:21:27PM -0700, chromatic wrote:
> On Friday 02 May 2008 11:55:54 Larry Wall wrote:
>
> > On Fri, May 02, 2008 at 11:15:34AM -0700, chromatic wrote:
>
> > : All classes imply the existence of a role of the same name.
>
> > If a role is derived from a class, it must of
> In src/objects.c:Parrot_add_attribute() there is the todo item:
>
> /* TODO escape NUL char */
>
> I think this applies to calling real_exception just afterwards.
According a discussion in #parrot this function and some related parts
is dead code. The attached patch removes it.
--
Salu2
Ind
On Wednesday 07 May 2008 11:54:31 NotFound wrote:
> According a discussion in #parrot this function and some related parts
> is dead code. The attached patch removes it.
Thanks, applied as r27377.
-- c
On Sat, Apr 26, 2008 at 10:15:05AM -0700, James Keenan via RT wrote:
> On Sat Apr 26 09:37:06 2008, geoff wrote:
> > On Sat, 2008-04-26 at 09:25 -0700, James Keenan via RT wrote:
>
> > > +are to be added. Wordspace-delimited string.
> >
> > Did you mean "Whitespace-delimited"?
>
> No, because
On Wed May 07 13:45:37 2008, [EMAIL PROTECTED] wrote:
>
> I would prefer the phrase "space delimited string" since a tab
> character could be a single whitespace?
>
Cf. http://svn.perl.org/parrot/trunk/lib/Parrot/Configure/Step/Methods.pm
What ultimately was committed to trunk was: "Single
wh
> In src/objects.c:Parrot_single_subclass() there is the todo item:
>
> /* XXX not really threadsafe but good enough for now */
>
> This needs to be made threadsafe.
This ticket can be closed, as Parrot_single_subclass was dead code and
has been removed.
Looking a this, I discovered that the s
NotFound wrote:
Looking a this, I discovered that the subclass function in default.pmc
contains a call to Parrot_single_subclass, but this function is not
present in default.c and there is no error nor warning about that
fact. Is this a behavior expected?
Anyway, the attached patch removes it.
Fixed in r27384, closing ticket.
Pm
As of r27389 most of the above changes are made, except that we can't
yet switch (zero-width assertion) because there are still a
number of languages and/or tools that are using as the
non-capturing syntax.
For now I've listed the syntax as deprecated and we can switch it
immediately following
On Wed May 07 16:53:11 2008, [EMAIL PROTECTED] wrote:
> Thanks, applied as r27388.
(Hitting the list with this thanks message. Thanks!)
Fixed in r27390. The step for automatically creating the makefile only
works for things in the languages/ subdirectory, so I modified
mk_languages_shell.pl to only attempt the reconfigure if a path wasn't
given.
Thanks,
Pm
On Sun Apr 20 19:01:44 2008, [EMAIL PROTECTED] wrote:
>
> I would like to propose both short-term and long-term remedies.
>
> Short-term: If you are proposing a new configuration step, or doing
> a significant overhaul of any existing step, please post an RT with
> the code and with a [TODO]
On May 5, 2008, Andy Lester wrote:
> On May 5, 2008, at 10:23 AM, Eric Wilhelm wrote:
> > Lurkers (potential contributors.) Posting it on use.perl.org (and/or
> > various other feed sources) would reach more of us.
>
> But do those lurkers actually exist? My gut says no. My gut says
> that the p
On Wed, 2008-05-07 at 18:22 -0700, James Keenan via RT wrote:
> On Sun Apr 20 19:01:44 2008, [EMAIL PROTECTED] wrote:
> >
> > I would like to propose both short-term and long-term remedies.
> >
> > Short-term: If you are proposing a new configuration step, or doing
> > a significant overhaul o
36 matches
Mail list logo
