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
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
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
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*,
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
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
# 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
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
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
# 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
# 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
12 matches
Mail list logo
