rakudo now builds correctly. btw : the subject is wrong. I did not
notice because
I use a script to get the last trunk, build parrot and rakudo.
On Sun, Nov 2, 2008 at 5:37 PM, Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> That's trunk, and I did a make real clean
>
> On Sat, Nov 1, 2008 at 9:36 P
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #60356]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60356 >
rakudo: class A {}; class C is A {}; say "OH HAI"
rakudo 32364: OUTPUT[OH HAI]
rakud
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #60358]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60358 >
rakudo: grammar A { token foo { foo } }; say "foo" ~~ A::foo
rakudo 32364: OUTPUT[foo
# New Ticket Created by Brad Bowman
# Please include the string: [perl #60364]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60364 >
Hi,
The pdd19_pir.pod is no longer a draft, this patch corrects the
L<> references.
-
On Wed Nov 05 21:38:15 2008, chrisdolan wrote:
> ... and here's a patch to Rakudo's actions.pm to implement the fix. I
> would be very happy if someone more experienced with NQP and PAST looked
> over the patch to see if there's a better way to do this.
>
Looks to be pretty much what I'd have done
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #60368]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60368 >
Hi,
since 2008-11-04 I'm getting this error from
t/spec/S12-class/declaration-order.t:
# New Ticket Created by Chris Dolan
# Please include the string: [perl #60366]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60366 >
There are two bugs here. The attached patch fixes bug #2 but not bug
#1.
Bug #1) "rol
Bernhard Schmalhofer via RT wrote:
On Mi. 05. Nov. 2008, 21:02:19, [EMAIL PROTECTED] wrote:
Could you take a look at line 182 of compiler_faq.pod?
I get a coding standard complaint because of the linelength:
Oops. I've tweaked that line to be under the limit and
the test should be passing aga
On Wed, Nov 5, 2008 at 23:22, Chris Dolan <[EMAIL PROTECTED]> wrote:
> In "[perl #60350] [TODO] default __get_string method", Patrick added a
> default Object.Str() that classes can override to get custom
> stringification. Formerly, you could do that only by defining a method
> named __get_string
On Thu, Nov 06, 2008 at 01:22:24AM -0600, Chris Dolan wrote:
> Currently, you can overload number context by creating a __get_number()
> method and boolean context via __get_bool(). Should there be an
> analogous Num() and Bool() method on Object? Would it Num() return 0 by
> default? And a
On Sat Dec 01 14:36:44 2007, coke wrote:
> From DEPRECATED.pod:
>
> Type IDs will go away in 0.5.0.
> Instead of:
>
> $P0 = new Integer
>
> or
>
> $P0 = new .Integer # better, but ...
>
> we are moving to use:
>
> $P0 = new 'Integer'
new_p_i and new_p_i_p are now gone in trunk.
On Thu Nov 06 08:52:18 2008, coke wrote:
> new_p_i and new_p_i_p are now gone in trunk.
find_type_i_s and find_type_i_p now gone in trunk.
--
Will "Coke" Coleda
Author: coke
Date: Thu Nov 6 10:12:45 2008
New Revision: 32395
Modified:
trunk/docs/pdds/pdd17_pmc.pod
Changes in other areas also in this revision:
Modified:
trunk/DEPRECATED.pod
trunk/src/pmc/hash.pmc
trunk/src/vtable.tbl
trunk/tools/dev/vtablize.pl
Log:
RT #48581 - remove [DEP
On Thu Dec 13 19:17:48 2007, coke wrote:
> From PDD17:
>
> INTVAL type_keyed_str(INTERP, PMC* self, STRING* key)
>
> [NOTE: To be
> deprecated when type IDs are deprecated.]
>
Removed in r32395.
--
Will "Coke" Coleda
valid_type_i_i removed in r32397.
--
Will "Coke" Coleda
removed typeof_i_p, typeof_i_p_ik, typeof_i_p_k, typeof_s_i in r32401
--
Will "Coke" Coleda
Author: coke
Date: Thu Nov 6 12:23:11 2008
New Revision: 32403
Modified:
trunk/docs/pdds/pdd17_pmc.pod
Changes in other areas also in this revision:
Modified:
trunk/DEPRECATED.pod
trunk/lib/Parrot/Pmc2c/PMC/ParrotClass.pm
trunk/src/pmc/array.pmc
trunk/src/pmc/default.pmc
trunk/
On Thu Dec 13 19:17:09 2007, coke wrote:
> From PDD17:
>
> INTVAL type_keyed_int(INTERP, PMC* self, INTVAL key)
>
> [NOTE: To be
> deprecated when type IDs are deprecated.]
>
Removed in r32403.
--
Will "Coke" Coleda
Author: coke
Date: Thu Nov 6 12:41:25 2008
New Revision: 32404
Modified:
trunk/docs/pdds/pdd17_pmc.pod
Changes in other areas also in this revision:
Modified:
trunk/DEPRECATED.pod
trunk/src/pmc/hash.pmc
trunk/src/pmc/iterator.pmc
trunk/tools/dev/vtablize.pl
Log:
RT #48577 remove
On Thu Dec 13 19:16:31 2007, coke wrote:
> From PDD17:
> INTVAL type_keyed(INTERP, PMC* self, PMC* key)
>
> ...
>
> [NOTE: To be
> deprecated when type IDs are deprecated.]
>
>
Removed in r32404
--
Will "Coke" Coleda
chromatic wrote:
On Wednesday 22 October 2008 09:28:38 Bernhard Schmalhofer via RT wrote:
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
Not until we apply this patch and all tests still pass.
Looks like you've missed few lines from this
chromatic wrote:
On Wednesday 22 October 2008 09:28:38 Bernhard Schmalhofer via RT wrote:
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
Not until we apply this patch and all tests still pass.
Looks like you missed few lines from this p
On Thursday 06 November 2008 12:52:38 Vasily Chekalkin wrote:
> > Not until we apply this patch and all tests still pass.
> Looks like you missed few lines from this patch. Few thousand lines :)
This patch is necessary, but not sufficient!
Anyone who does want to help though should apply this p
Author: coke
Date: Thu Nov 6 14:41:14 2008
New Revision: 32407
Modified:
trunk/docs/pdds/pdd19_pir.pod
Changes in other areas also in this revision:
Modified:
trunk/DEPRECATED.pod
trunk/compilers/imcc/imcc.y
trunk/compilers/imcc/imcparser.c
trunk/compilers/pct/src/POST/Compiler.pi
On Mon Oct 20 11:37:51 2008, pmichaud wrote:
> > >> The big hangup for this ticket is that various parts of PCT and
> the
> > >> CodeString PMC do not support empty brackets, and therefore PCT
> does not
> > >> emit ".namespace []" in these situations.
> > >> [...]
> > >> I know pmichaud was talkin
25 matches
Mail list logo
