Hi,
Karl Voelker wrote:
> I'd like to help out with Perl 6 development, but I can't find any
> really specific details about what needs to be done. I found some
> general documents (the roadmap and such), but I don't want to jump into
> a new codebase without a well-defined task.
First of all
chromatic a écrit :
On Tuesday 08 July 2008 02:36:37 François PERRAD via RT wrote:
This bug starts with r28354 (cache string).
The cache don't handle empty string.
Now, in Pipp (PHP), an empty string is used to stringify boolean False.
// languages/pipp/src/pmc/phpboolean.pmc
STRING* get_s
François Perrad schrieb:
chromatic a écrit :
On Tuesday 08 July 2008 02:36:37 François PERRAD via RT wrote:
This bug starts with r28354 (cache string).
The cache don't handle empty string.
Now, in Pipp (PHP), an empty string is used to stringify boolean False.
// languages/pipp/src/pmc/phpboo
On Wed, Jul 09, 2008 at 01:27:29AM -0400, Bob Rogers wrote:
>What "foo" should do is create a closure and call that:
>
> .const .Sub inner = 'inner'
> inner = newclosure inner
> inner()
If I understand what you're saying, and then take it to what I see
as its ultimate conclu
[typo clarification]
On Wed, Jul 09, 2008 at 08:25:52AM -0500, Patrick R. Michaud wrote:
> [...] If we now say that a newclosure op is required to invoke 'foo',
> then that means that the 'foo()' HLL subroutine has to be generated as:
>
> .local pmc $P0
> $P0 = find_name_not_null 'foo'
Since the introduction of :lexid in PCT, the code generation in Lua is
wrong (empty outer). For example :
$ parrot luap.pir --target=pir
Compiler Lua 5.1 on Parrot Copyright (C) 2005-2008, The Perl Foundation.
> print "hello"
.include "interpinfo.pasm"
.HLL "Lua", "lua_group"
.namespace
.sub "&
On Tuesday 08 July 2008 17:55:42 NotFound wrote:
> On Mon, Jun 23, 2008 at 4:37 PM, Andrew Johnson <[EMAIL PROTECTED]> wrote:
> >> Here is the patch. It avoids the warning both in C and C++ with gcc.
> >
> > Works fine for me, no warning.
> > It might be worth adding a comment into parrot.h to clar
# New Ticket Created by Christoph Otto
# Please include the string: [perl #56718]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56718 >
r29183 adds a test to t/pmc/array.t that exposes some brokenness in the Array
PMC's f
# New Ticket Created by Jerry Gay
# Please include the string: [perl #56716]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56716 >
the configure tests take too much time to run, and should be sped up
by whatever means nece
On Wednesday 09 July 2008 08:27:35 Andrew Johnson wrote:
> > Done in r29179, please confirm that gives no warning now.
>
> Confirmed, those warnings have gone. I'm still getting loads of "warning:
> statement not reached" but I'll work out how to suppress those and post a
> fix separately.
Does
We're planning to meet Saturday after OSCON for a Perl 6/Parrot
hackathon. Location still to be determined, but it will be somewhere
close to the OSCON convention center.
Allison
Patch applied in r29201, keep ticket open for some days.
Closing ticket
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #56748]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56748 >
I found a small piece of code that reproduces the "Null PMC access in
type()" error:
sub
On Tue, 8 Jul 2008, Jerry Gay wrote:
> # New Ticket Created by Jerry Gay
> # Please include the string: [perl #56716]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=56716 >
>
>
> the configure tests take too much time
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 08:25:52 -0500
On Wed, Jul 09, 2008 at 01:27:29AM -0400, Bob Rogers wrote:
> What "foo" should do is create a closure and call that:
>
>.const .Sub inner = 'inner'
>inner = newclosure inner
>i
On Wednesday 09 July 2008 13:46:19 Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Wed, 9 Jul 2008 08:25:52 -0500
>If I understand what you're saying, and then take it to what I see
>as its ultimate conclusion, you're basically claiming that every
>cal
> First of all Perl 6 is a language, and multiple compilers are being
> written that target that language.
I'm aware. I guess I should have said "Rakudo" instead of "Perl 6," but I
thought this list was specific to Rakudo.
> If you decide which sub project you want to help, we can tell you much
>
Allison Randal wrote:
We're planning to meet Saturday after OSCON for a Perl 6/Parrot
hackathon. Location still to be determined, but it will be somewhere
close to the OSCON convention center.
Location confirmed:
Urban Grind East
2214 NE Oregon St.
Portland, OR 97232
Saturday July 26th, 9am-
[EMAIL PROTECTED] wrote:
>> First of all Perl 6 is a language, and multiple compilers are being
>> written that target that language.
>
> I'm aware. I guess I should have said "Rakudo" instead of "Perl 6," but I
> thought this list was specific to Rakudo.
Mostly Rakudo, but not only.
>> If you d
From: chromatic <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 13:59:16 -0700
I read that in the lexicals PDD, and I think the current behavior is
bizarre *without* the call to newclosure. How is it even possible to
close over a lexical environment in an outer when that lexical
envir
On Wednesday 09 July 2008 15:37:51 Bob Rogers wrote:
>I suspect the motivation for the bizarreness of the specification is the
>desire to make code like this work in Parrot:
>
> {
> my $x;
>
> sub set_x { $x = shift }
> sub get_x
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>...
>If we now say that a newclosure op is required to invoke 'foo',
>then that means that the 'foo()' HLL subroutine has to be generated as:
>.local pmc $P0
>
# New Ticket Created by Will Coleda
# Please include the string: [perl #56756]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56756 >
On a win32 build with AS perl and the MS tools, I get the following results:
Failed Test
On Wed, Jul 09, 2008 at 03:45:31PM -0700, chromatic wrote:
>
> That example is fine with me. I almost deleted all of the hijinks necessary
> in Closure PMC to attach to a never-initialized outer lexical scope before I
> read the lexical spec again and realized that someone designed it that way.
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
Content-Description: message body text
>In effect this is little different from having 'foo' as an immediate
>block. If we now say that a newclosure op is required to invoke 'foo',
>then that means that the 'foo()' HLL subrou
Since I closed this ticket in January, more code has been added.
Tonight, while writing unit tests for internal subroutine
_handle_ncurses_need(), I noticed the following lines:
if ( $osname =~ /mswin32/i ) {
if ( $cc =~ /^gcc/i ) {
$conf->data->add( ' ', libs => '-lncuses
With additional unit tests added in r29216-29217, test coverage is now
100% in all major categories. Resolving ticket.
kid51
On Tue Jul 08 20:01:11 2008, [EMAIL PROTECTED] wrote:
> Committed to trunk in r29181:
> http://www.parrotvm.org/svn/parrot/revision?rev=29181
>
> kid51
Revisions appear to be passing smoke tests. Marking ticket resolved.
kid51
# New Ticket Created by James Keenan
# Please include the string: [perl #56760]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56760 >
This configuration step class did not exist when I began to write
tests for the steps
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Wed, 9 Jul 2008 18:49:53 -0500
On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
> Not true. The compiler always knows when it's compiling a closure. So
> if, at the point of definition, the emitted code does:
>
On Thu, Jul 10, 2008 at 12:29:57AM -0400, Bob Rogers wrote:
>From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>Date: Wed, 9 Jul 2008 18:49:53 -0500
>
>On Wed, Jul 09, 2008 at 04:46:19PM -0400, Bob Rogers wrote:
>> Not true. The compiler always knows when it's compiling a closure. S
32 matches
Mail list logo
