From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 22:59:05 -0500
On Fri, Jul 11, 2008 at 08:00:40PM -0700, Bob Rogers via RT wrote:
>Of course, if cloning works the same as newclosure than we don't
>need an explicit newclosure for the examples given, beca
On Fri, Jul 11, 2008 at 08:00:40PM -0700, Bob Rogers via RT wrote:
>Of course, if cloning works the same as newclosure than we don't
>need an explicit newclosure for the examples given, because
>assignment already makes a clone.
>
> Assignment seems to do assign_pmc, which for a clos
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 21:55:41 -0500
On Fri, Jul 11, 2008 at 10:04:54PM -0400, Bob Rogers wrote:
> Absolutely, but that's not where the problem lies. The problem is that
> r28763 did so implicitly and unconditionally, overwriting anyt
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 19:22:49 -0500
On Sat, Jul 12, 2008 at 01:11:12AM +0200, Jonathan Worthington wrote:
> This is consistent with my view of the specified Perl 6 semantics[1] for
> closure handling. I translated Bob's Perl 5 exampl
On Fri, Jul 11, 2008 at 10:04:54PM -0400, Bob Rogers wrote:
> Absolutely, but that's not where the problem lies. The problem is that
> r28763 did so implicitly and unconditionally, overwriting anything
> newclosure might have done. If you meant "have its outer_ctx set
> I whenever an outer sub is
Will Coleda wrote:
What's this branch for, out of curiosity?
http://rt.perl.org/rt3/Ticket/Display.html?id=56716
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 16:23:28 -0500
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
>Based on what Bob has been saying, I can't now think of a case where
>an inner closure _shouldn't_ go ahead and have its outer_ct
On Sat, Jul 12, 2008 at 03:29:31AM +0200, Jonathan Worthington wrote:
> But I'm not convinced that
> we always take clones on referencing a block in Rakudo (OK, I've not
> gone and looked, but I can't remember seeing anything that explicitly
> does that, and I spend a lot of time staring at Raku
Patrick R. Michaud wrote:
Yes, the translation helps a lot.
OK, good.
But what you came up with is almost exactly what I would expect PCT/Rakudo to be generating _now_ for this code example (modulo a few minor details).
I tried to write it so it wouldn't be far off what Rakudo would produce
Closing ticket
On Sat, Jul 12, 2008 at 01:11:12AM +0200, Jonathan Worthington wrote:
> This is consistent with my view of the specified Perl 6 semantics[1] for
> closure handling. I translated Bob's Perl 5 example into PIR and put
> newclosure where the Perl 6 specification would suggest to put it and it
> pro
On Fri Jul 11 05:29:20 2008, coke wrote:
> Belatedly add Moritz's response to the ticket.
A fix for this bug was committed in r29289 which looks like it will
resolve this issue. If that's the case, this ticket can be closed.
Closing ticket
Hi all,
Patrick R. Michaud wrote:
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
Content-Description: message body text
This is certainly not the case for recursive subs. Consider the
attached example, a lightweight Perl 5 dumper. (It is slightly
artificial to break the rec
Applied in r29309
--
Salu2
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
Content-Description: message body text
>This is certainly not the case for recursive subs. Consider the
> attached example, a lightweight Perl 5 dumper. (It is slightly
> artificial to break the recursive step out into a sub, but tha
On Fri, Jul 11, 2008 at 04:49:55PM -0400, Bob Rogers wrote:
>Based on what Bob has been saying, I can't now think of a case where
>an inner closure _shouldn't_ go ahead and have its outer_ctx set
>whenever an outer sub is invoked . . .
>
> Foul! That's exactly what r28763 does to break
Can someone who is attending OSCON write up a blurb for the parrot web
site similar to the (now past) one there for YAPC::NA?
I'd be happy to post it if the person that writes it isn't Allison or
chromatic... ^_^
Thanks...
--
Will "Coke" Coleda
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Fri, 11 Jul 2008 01:55:11 -0500
On Thu, Jul 10, 2008 at 11:06:55PM -0500, Patrick R. Michaud wrote:
>
> I _think_ [methods and subs] are the only two cases where we
> have to do something like this, and I guess they aren't to
On Friday 11 July 2008 13:32:40 Will Coleda via RT wrote:
> > Two versions:
> > Full CVS-style version: disassemble-long.patch
> > I don't know how svn handles file renames.
> > After svn renaming it would just be the shorter disassemble_rename.patch
> This seems to have been warnocked. I have n
On Mon Jul 07 08:43:14 2008, [EMAIL PROTECTED] wrote:
> Is this '\n' controlled? it is suposed to be an example or it is a bug?
>
> [EMAIL PROTECTED]/prg/parrot/languages/punie$ svn diff
> Index: demo.p1
> ===
> --- demo.p1 (revis
On Wed Jul 02 15:31:05 2008, rurban wrote:
> disassemble is too generic when being packaged into /usr/bin/.
>
> Two versions:
> Full CVS-style version: disassemble-long.patch
> I don't know how svn handles file renames.
> After svn renaming it would just be the shorter disassemble_rename.patch
Th
> When #39930 is resolved, we can eliminate the workaround.
After applying a patch to #39930 in r29301, deleted this workaround in r29304
--
Salu2
Author: cotto
Date: Fri Jul 11 09:15:28 2008
New Revision: 29298
Modified:
trunk/docs/pdds/draft/pdd19_pir.pod
Changes in other areas also in this revision:
Modified:
trunk/languages/pipp/src/pct/actions.pm
Log:
[codingstd] whitespace fix and line length fix
Modified: trunk/docs/pdds/dra
Hearing no objections, ticket closed.
Patch applied in r29301
I changed the test, because the unicode: prefixed string is utf8 by
default according the specs, and the current implementation seems to
agree, so the result in utf8 is the expectation both with or without
icu.
--
Salu2
On Thu, Jul 3, 2008 at 11:12 PM, Allison Randal via RT
<[EMAIL PROTECTED]> wrote:
> A bit more detail on the conversion process for a PMC:
(snip)
> 3) Change 'init' and 'init_pmc' to initialize the auto-generated struct
> instead of whatever initialization it was doing before. For example, if
> it
On Thu, 10 Jul 2008, Andrew Whitworth wrote:
> I found this while tracking a nasty GC-related bug. In
> src/packfile/pf_items.c:PF_fetch_integer, we have the following two
> notes:
>
> XXX assumes C INTVAL size in the PackFile header
>
> XXX assume sizeof (opcode_t) == sizeof (INTVAL) on the mac
Fixed in r29283, and your PIR turned into a test.
We might consider caching PMCProxy for all built-in PMCs (where they
have no namespace attached), but with my current understanding, only
classes need it, and then only if they extend built-in PMCs. That seems
somewhat rare.
# New Ticket Created by Donald Hunter
# Please include the string: [perl #56828]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56828 >
Added support for void** params, i.e. for out parameters. This is
required for functio
On Fri, Jul 11, 2008 at 03:27:26PM +0200, TSa wrote:
> >Note that we already have:
> >
> >my @s = sort { $^a <=> $^b }, @a;
> >my @s = @a.sort { $^a <=> $^b };
>
> Is that the adverbial block syntax? If not how
> would it look?
The adverbial block syntax would be:
@a.sort:{ $^a <=> $
# New Ticket Created by Donald Hunter
# Please include the string: [perl #56824]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56824 >
Fixes a segv in the has_exec_protect test on Cygwin.
config/auto/jit/test_exec_cygwin.
HaloO,
Patrick R. Michaud wrote:
S29 doesn't show a 'sort' method defined on block/closure
invocants... should there be?
I doubt that. And to my eyes it looks funny. Only real block
methods should be useful and since the class is mostly known
at parse time unapplicable methods should be a co
Author: kjs
Date: Fri Jul 11 06:24:05 2008
New Revision: 29292
Modified:
trunk/docs/pdds/draft/pdd19_pir.pod
Log:
[pdd19] add :lexid, but description not complete yet (not sure about details).
Modified: trunk/docs/pdds/draft/pdd19_pir.pod
=
t/spec/S29-list/sort.t has the following test:
my @a = (2, 45, 6, 1, 3);
my @e = (1, 2, 3, 6, 45);
my @s = { $^a <=> $^b }.sort: @a;
is(@s, @e, '... with closure as direct invocant');
S29 doesn't show a 'sort' method defined on block/closure
invocants... should there be?
Note
Belatedly add Moritz's response to the ticket.
--
Will "Coke" Coleda
-- Forwarded message --
From: Moritz Lenz <[EMAIL PROTECTED]>
Date: Fri, Jul 11, 2008 at 6:00 AM
Subject: Re: src/jit/i386/core.jit:1031: error: 'DO' undeclared
To: tuxdna <[EMAIL PROTECTED]>, Perl 6 Internals <[
> Looks like it was just a DO/do typo, but the file has been changed
> before I can try to do some test.
No, it was a bad diagnostic from svn, my change has been commited.
--
Salu2
>> src/exec_cpu.c
>> src/jit/i386/core.jit: In function 'Parrot_eq_n_n_ic_exec':
>> src/jit/i386/core.jit:1031: error: 'DO' undeclared (first use in
>> this function)
Looks like it was just a DO/do typo, but the file has been changed
before I can try to do some test.
--
Salu2
# New Ticket Created by Will Coleda
# Please include the string: [perl #56832]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56832 >
Open a ticket...
--
Will "Coke" Coleda
Begin forwarded message:
> From: tuxdna <[EMAIL
tuxdna wrote:
> Hi,
>
> I am using Fedora 8
> Linux 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686
> i386 GNU/Linux
> gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
It seems that was introduced in r29284 while trying to fix another issue.
Maybe someone more familiar with the guts s
Hi,
I am using Fedora 8
Linux 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686
i386 GNU/Linux
gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
$ make
Compiling with:
xx.c
gcc -I./include -D_REENTRANT -D_GNU_SOURCE -pipe
-Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_
HaloO,
Mark J. Reed wrote:
For any numeric type of $x, $x++ should mean $x += 1.3.14 becomes
4.14. -3.14 becomes -2.14 (which indicates that floor() is not
involved) . 5/8 becomes 13/8. The step size is irrelevant. If $x is
so large that adding 1 gets lost due to the precision, then OK, ++
42 matches
Mail list logo
