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*
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.
//
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 conclusion,
[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 start
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 clarify that
# New Ticket Created by Christoph Otto
# Please include the string: [perl #56718]
# in the subject line of all future correspondence about this issue.
# URL: 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
# New Ticket Created by Jerry Gay
# Please include the string: [perl #56716]
# in the subject line of all future correspondence about this issue.
# URL: 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
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 your
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.
# URL: 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:
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56716
the configure tests take too much time to
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
inner()
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
call to a
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
better
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,
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
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
$P0 =
# New Ticket Created by Will Coleda
# Please include the string: [perl #56756]
# in the subject line of all future correspondence about this issue.
# URL: 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
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
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.
# URL: 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
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. So
31 matches
Mail list logo
