# New Ticket Created by "Julian Fondren"
# Please include the string: [perl #41726]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41726 >
Currently, evaluating this:
function bad (n) return n * bad(n) end bad(2)
will c
OK: before I submit a patch, let me make sure that I've got the
concepts straight:
"@x[0]" always means "the first element of the array"; "@x[-1]" always
means "the last element of the array"; "@x[*+0]" always means "the
first element after the end of the array"; "@x[*-1]" always means "the
first
Author: audreyt
Date: Wed Mar 7 09:10:48 2007
New Revision: 14314
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: Instead of introducing the conjectural concept of
single-semicolon delimited multiple-longnames, delegate
the discussion to S12 and present the non-controversial
double-s
# New Ticket Created by Will Coleda
# Please include the string: [perl #41732]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41732 >
The following (improper?) code segfaults:
.namespace ['Foo']
.sub __invoke :method
Jerry Gay (via RT) ha scritto:
i suspect there's trouble with the platform-specific c/h files, given
the nature of the warnings during build. the configure/make output is
below.
the only relevant warning I see is:
config/gen/platform/win32/exec.c: In function `Parrot_Exec_OS_Command':
conf
On Wednesday 07 March 2007 08:42, Aldo Calpini wrote:
> on the other hand, I had a totally different experience using strawberry
> perl to build parrot. it doesn't work at all, make groks because of
> backslashes in paths in the Makefile (had to change them to forward
> slashes), libparrot.dll ref
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #41733]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41733 >
Hi There,
Given the following (latest svn today - parrot 0.49+):
.namespace ['Fo
Jerry Gay (via RT) wrote:
it's old, not used anywhere, and defunct. let's list it in
DEPRECATED.pod before 0.4.10, and remove it before the following
release.
Agree.
Allison
On February 27th Darren Duncan writes:
> At 4:45 PM + 2/27/07, Nicholas Clark wrote:
>
> > > 4. rename():
>
> > rename is a Perl 5 builtin.
> I see this situation as being similar to Dog.bark() vs Tree.bark();
The difference is that those are methods. Having different objects
which have
On 3/7/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Jerry Gay (via RT) wrote:
> it's old, not used anywhere, and defunct. let's list it in
> DEPRECATED.pod before 0.4.10, and remove it before the following
> release.
Agree.
i've added a note to DEPRECATED.pod, in preparation for the 0.4.10 re
Author: larry
Date: Wed Mar 7 16:18:15 2007
New Revision: 14315
Modified:
doc/trunk/design/syn/S03.pod
Log:
made "my Any $x; $x := [1,2,3]" a little dwammy (do what audreyt++ means :)
Modified: doc/trunk/design/syn/S03.pod
Author: particle
Date: Wed Mar 7 16:38:50 2007
New Revision: 17380
Modified:
trunk/docs/pdds/pdd22_io.pod
Log:
[PDD22]:
~ added note about Status PMC passing for async ops
~ added Status PMC return value for I/O print method
~ renumbered example code registers for consistency
~ expanded tabs
The invoke vtable method is supposed to take one argument - the
address of the opcode immediately following the invokecc opcode, so we
can return to it later. It then returns the address of the subroutine
to jump into. The problem is that, in C, the invoke method takes and
returns an opcode_t*,
Alek Storm <[EMAIL PROTECTED]> wrote:
The invoke vtable method is supposed to take one argument - the
address of the opcode immediately following the invokecc opcode, so we
can return to it later. It then returns the address of the subroutine
to jump into. The problem is that, in C, the invoke
On Wednesday 07 March 2007 17:02, Matt Diephouse wrote:
> I don't think that's the right route to take. Exposing the pc to PIR-land
> code seems dangerous and I don't think there's much point. As a PIR user, I
> want the invoke vtable to behave just like any other PIR subroutine.
Agreed.
> This
On Sun, 4 Mar 2007, Will Coleda wrote:
Good News: Thanks for the Summaries!
Bad News: Isn't that in about 2 weeks? ^_^
I realized the mistake after I posted it. I corrected the web posts
but it's rather hard to correct email. At Darren Duncan's suggestion,
I will repost with the correct sub
Author: larry
Date: Wed Mar 7 17:25:32 2007
New Revision: 14316
Modified:
doc/trunk/design/syn/S03.pod
Log:
Clarifications requested by TheDamian++
Defined ++ and -- in terms of .succ and .pred so I could write s[] = $0.succ
Modified: doc/trunk/design/syn/S03.pod
===
On 3/7/07, Jonathan Lang wrote:
Looks good to me.
As well, the fact that @x[-1] doesn't refer to the element
immediately before @x[0] is awkward, as is the fact that @x[*-1]
doesn't refer to the element immediately before @x[*+0]. IMHO, it
would be cleaner to have @x[n] count forward and
On 2/28/07, [EMAIL PROTECTED] wrote:
Ranges are not autoreversing: C<2..1> is always a null range.
I assume the reason for not having ranges automatically go in either
direction is that it would make it easier for subtle bugs to creep in
when either end is smaller (or bigger) than you expecte
Release is a little under two weeks away...
There's a placeholder ticket here:
http://rt.perl.org/rt3/Ticket/Display.html?id=41581
Which contains all the tickets (so far) I'd preferentially like to
see resolved before the next release.
If you've got something you're working on that you th
Author: larry
Date: Wed Mar 7 20:38:15 2007
New Revision: 14317
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S11.pod
Log:
Module longnames now specified in terms of ident plus adverbials.
Modified: doc/trunk/design/syn/S02.pod
==
Author: larry
Date: Wed Mar 7 20:40:33 2007
New Revision: 14318
Modified:
doc/trunk/design/syn/S02.pod
Log:
typo spotted by TimToady++ :/
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod
Author: larry
Date: Wed Mar 7 21:35:52 2007
New Revision: 14319
Modified:
doc/trunk/design/syn/S02.pod
Log:
Definition of version sorting order.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02
23 matches
Mail list logo
