On Wed May 16 04:27:03 2007, [EMAIL PROTECTED] wrote:
> The results of my first post in this thread were probably caused by
> the fact that some files were not updated correctly (I am new to
> revision control). Both Allison's and Alek's patches have in fact the
> same effect.
>
> But the problem
bly only ok, if the invoke is "near" the
* set_addr ins
*/
Check whether or not the code following this comment is ok, and in which
situations. Also, what does "ok" mean in this context? And is there a
good feeling for what "near" is with respect to the inv
The results of my first post in this thread were probably caused by
the fact that some files were not updated correctly (I am new to
revision control). Both Allison's and Alek's patches have in fact the
same effect.
But the problem that I stated in my second post and the proposed
solution are val
On 5/15/07, Alek Storm <[EMAIL PROTECTED]> wrote:
On 5/14/07, Mehmet Yavuz Selim Soyturk <[EMAIL PROTECTED] >
wrote:
> Should we not be able to use an object that implements 'invoke' as a
> method of another object? There is some strange behaviour when I try
> to.
On 5/15/07, Allison Randal via RT <[EMAIL PROTECTED]> wrote:
And reverted in r18541. The patch is fragile. Broken on Windows, and
fixing it for Windows breaks it for OSX and Linux.
Whoops, I had no idea it didn't work on Windows. I have no way to test on
that platform. What was the problem?
On 5/14/07, Mehmet Yavuz Selim Soyturk <[EMAIL PROTECTED] >
wrote:
Should we not be able to use an object that implements 'invoke' as a
method of another object? There is some strange behaviour when I try
to.
I see what you're saying, and it looks like you want a
And reverted in r18541. The patch is fragile. Broken on Windows, and
fixing it for Windows breaks it for OSX and Linux.
Allison
PIR can't tell the difference between invoking an object PMC and
invoking a sub PMC, it doesn't generate a correct set_args when an object is
invoked. Since the 'invoke' override is a method, it expects the current
object to be the first parameter. There are currently two workarou
Thanks, applied in r18535 with some modifications. Particularly, changed
the name of the flag from PARROT_ARG_OBJECT to PARROT_ARG_INVOCANT,
moved the code for handling object overrides of 'invoke' from
delegate.pmc to parrotobject.pmc, and kept the regression test for RT
#41732 (stil
and
invoking a sub PMC, it doesn't generate a correct set_args when an object is
invoked. Since the 'invoke' override is a method, it expects the current
object to be the first parameter. There are currently two workarounds: pass
the current object explicitly as the first paramete
Thanks! Applied in r17859.
Note: I had to update include/parrot/debug.h to make sure that src/
debug.c
about this issue.
> ># http://rt.perl.org/rt3/Ticket/Display.html?id=42156 >
> >
> >
> >In this next round of cleanups, I switched over the invoke() methods
> >to return opcode_t* as Andy Dougherty suggested. Also, I added
> >a change to the NEED_CONTINUATION base
round of cleanups, I switched over the invoke() methods
to return opcode_t* as Andy Dougherty suggested. Also, I added
a change to the NEED_CONTINUATION based on Kevin Tewks suggestions.
Finally, I also included a couple of additional changes to back out some
of my changes yesterday that are now irrel
# New Ticket Created by Steve Peters
# Please include the string: [perl #42156]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42156 >
In this next round of cleanups, I switched over the invoke() methods
to return opcod
Following conversation with Matt Diephouse on #parrot, I realized that
that was pretty confusing. What I meant was that invoke() should
accept parameters and return values as a normal subroutine. This
would probably be done by moving the code that deals with the pc out
of the invoke() method
That is definitely the most elegant solution. Now, the question is, shouldn't
the invoke() vtable method behave that way in the first place, since passing a
pc address to and returning another pc address from the invoke() method only
makes sense for Sub, Coroutine, and Continuation? In
On Wed Mar 07 17:02:47 2007, mdiep wrote:
> This gets us close to what I want:
>
>
>
> void* invoke(void *next) {
> STRING *meth = CONST_STRING(interp, "__invoke");
> STRING *meth_v = CONST_STRING(interp, "invoke");
> PM
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
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
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
ace ['Foo']
.sub invoke :vtable
say "you invoked me!"
.return()
.end
.sub main :main
$P0 = newclass "Foo"
$P1 = new "Foo"
$P1()
say "got here"
.end
The final "got here" is never printed.
Also parrot segfaults with th
nvoke :method
.param pmc a
say 'hi'
.end
.sub main :main
$P0 = newclass "Foo"
$P1 = new "Foo"
$P1()
.end
Removing the __invoke method generates a method not found error, avoiding
the segfault. Removing the .param also avoids the segfault. Changing t
In Lua, a metamethod '__call' is needed.
So in the base PMC, I want write something like this:
void* invoke(void* next) {
PMC *meth = find_meth(INTERP, SELF, "__call");
/*
* Here, I need to insert SELF as first argument,
* in the argu
hink
of it), and two more showing its limitations.
Problems:
1. It doesn't invoke the actions in the right dynamic environment.
This is largely because "the current dynamic environment" is tied into
"the currently-executing sub", rather than being stored in the
in
Can't reproduce, seems to pass C call. Should be closed.
.sub _main # void win32_setup(void)
loadlib P1, "kernel32.dll"
dlfunc P0, P1, "GetStdHandle", "pi"
set I0, 1
set I5, -11
invoke # Will crash here.
store_global "kernel32
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Currently parrot sets the current object for a method call *after*
> calliing invoke on the invokable thing. This is a bit problematic,
> since the invokable thing likely needs to have the object in place to
> invoke right.
Fixed.
leo
# New Ticket Created by Dan Sugalski
# Please include the string: [perl #33031]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33031 >
Currently parrot sets the current object for a method call *after*
calliing inv
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> Hi,
> I am trying to implement the 'eval' macro im Parrot m4. The Parrot m4
> interpreter is implemented in PIR. The 'eval' is a simple interpreter for
> integer artithmetic and forms thus a micro language within a mini language.
> Can I use 'invo
voked.
In a test script this looks like:
.sub _main
.local pmc m4_eval_compiler_lib
m4_eval_compiler_lib = loadlib "m4_eval_compiler"
compreg P1, "m4_eval_compiler"
.local string code
code = '1 + 1'
.local pmc compiled_code
compiled_code
Clinton Pierce <[EMAIL PROTECTED]> wrote:
>> I checked in a fix for something that *may* have fixed this, but I'm
>> not sure as I can't test it out at the moment. Try sync'ing up to CVS
>> and giving it another whirl.
> Still no luck. No luck either in getting a stack trace to the problem.
> Th
rk in MSVS.NET. I can't get the vcdg (debug) version of the
program to run beyond:
pmclass NCI {
void* invoke (void * next) {
Parrot_csub_t func = (Parrot_csub_t)D2FPTR(PMC_data(SELF));
func(INTERP, SELF); // <-- here
return next;
}
}
My guess is that my
At 4:26 PM -0400 6/30/03, Piers Cawley wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
... I'd also like to be able to manipulate the stacks in a context,
pushing things on them, changing values on them, and generally
messin
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote:
>>Dan Sugalski wrote:
>>> ... I'd also like to be able to manipulate the stacks in a context,
>>> pushing things on them, changing values on them, and generally
>>> messing about with the things, so I'm al
Clinton Pierce wrote:
Clarification:
running an invoke() at *any* time will cause all subsequent tracing to segfault.
I can't reproduce that on Linux (even with Dan's patch not applied yet).
leo
At 7:58 PM -0400 6/29/03, Clinton Pierce wrote:
Clarification:
running an invoke() at *any* time will cause all subsequent tracing
to segfault. Thus (pseudoPASM):
loadlib
dlfunc
invoke
trace 1
end
Will cause the segfault.
I checked in a fix for
Clarification:
running an invoke() at *any* time will cause all subsequent tracing to segfault. Thus
(pseudoPASM):
loadlib
dlfunc
invoke
trace 1
end
Will cause the segfault.
> Original Message-
> From: &quo
At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote:
Dan Sugalski wrote:
... I'd also like to be able to manipulate the stacks in a context,
pushing things on them, changing values on them, and generally
messing about with the things, so I'm all for it.
Do you have some examples for a usage of such
Dan Sugalski wrote:
[ update continuation PMC at call time ]
Here are some possibilities to achieve this:
- invokecc (this is slow)
- a new opcode e.g. C (update continuation ctx)
- toss invokecc's current functionality and use this opcode to update
the context and call the sub.
I like option 2.
unc, _ret
...
invoke
and _func turns warnings off, the warns are restored fine.
When C is after C, the continuation has the old
state of warns. So we should update the continuation context at
C time.
Here are some possibilities to achieve this:
- invokecc (this is slow)
- a new opcode e.g
In the meantime interpreter->warns has moved to the context structure
and gets now restored for CPS subroutine calls.
But there is a slight problem (as well as with e.g. pad_stacks)
When we have:
warningson 1
newsub .Sub, .Continuation, _func, _ret
...
invoke
and _func turns warnings
# New Ticket Created by "Clinton A. Pierce"
# Please include the string: [perl #22706]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22706 >
Running imcc -t or parrot -t over an invoke instruction causes the
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]
[snip]
> I see. Yes, this shorthand is fine, the more that it will be used
> heavily. What about:
>
> invokecc the_sub_label
>
> which would include constructing the subroutine object in P0 too?
This would be co
Leopold Toetsch wrote:
Jonathan Sillito <[EMAIL PROTECTED]> wrote:
We need them. Parrot calling conventions are not the only convention we
have. And for parrot calling conventions you have to save registers too.
I was not suggesting that we not save registers, just that we use a context
object
Jonathan Sillito <[EMAIL PROTECTED]> wrote:
>> We need them. Parrot calling conventions are not the only convention we
>> have. And for parrot calling conventions you have to save registers too.
> I was not suggesting that we not save registers, just that we use a context
> object to do it rather
Jonathan Sillito <[EMAIL PROTECTED]> wrote:
> this is just the "current continuation". In pasm this could be:
> new P1, .Continuation
> set_addr I3, returnhere
> set P1, I3
> invoke # or invoke_method
> returnhere:
> # etc ...
>
Jonathan Sillito wrote:
[snip]
> -inline op invoke(in PMC) {
+inline op call(in PMC) {
>opcode_t *dest;
> - PMC * p = $1;
> -
> - dest = (opcode_t *)p->vtable->invoke(interpreter, p, expr NEXT());
> -
> + PMC * sub = $1;
> + dest = (opcode_t *)p->vtable-&g
Jonathan Sillito wrote:
[snip]
> -inline op invoke(in PMC) {
+inline op call(in PMC) {
>opcode_t *dest;
> - PMC * p = $1;
> -
> - dest = (opcode_t *)p->vtable->invoke(interpreter, p, expr NEXT());
> -
> + PMC * sub = $1;
> + dest = (opcode_t *)p->vtable-&g
Hey, thanks for the comments.
So you suggest leaving as the op as invoke? I don't mind, I just think we
should be consistent in our naming; what about having the following four
ops:
- invoke
- invokecc
- invoke_method
- invokecc_method
You also wondered about the need for th
h (as suggested by Mitchell).
Thats fine.
> 3. updates tests, examples and documentation to use call instead of invoke.
> still to do:
>- update language/imcc to use call instead of invoke??
This - if ever - can only be done in one big change in parrot and imcc.
But I don't know,
les and documentation to use call instead of invoke.
- t/pmc/sub.t
- t/pmc/coroutine.t
- t/pmc/eval.t
- t/pmc/nci.t
- examples/assembly/coroutines.pasm
- examples/assembly/sub.pasm
- docs/pdds/pdd06_pasm.pod
still to do:
- update language/imcc to use call instead of inv
On Feb-25, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >On Feb-23, Leopold Toetsch wrote:
> >
> >I think I kind of have a grasp on what's going on, now. So I've
> >attached two possible patches.
>
>
> I'm currently on the imcc stuff and could have a more detailed look at
> both patches afte
Steve Fink wrote:
On Feb-23, Leopold Toetsch wrote:
I think I kind of have a grasp on what's going on, now. So I've
attached two possible patches.
I'm currently on the imcc stuff and could have a more detailed look at
both patches after. But I think, both have the same effect on generated
co
On Feb-22, Dan Sugalski wrote:
> At 10:20 AM -0800 2/20/03, Steve Fink wrote:
> >The invoke op is bothering me -- namely, it disturbs me that it
> >implicitly operates on P0. I know that P0 is the correct register to
> >use according to pdd03, but I dislike having it be imp
interpreter->ctx.control_stack, CUR_OPCODE + OP_SIZE,
STACK_ENTRY_DESTINATION, STACK_CLEANUP_NULL);
loc = INTVAL2PTR(opcode_t *, $1);
goto ADDRESS(loc);
}
@@ -4592,7 +4592,7 @@ inline op invoke() {
opcode_t *dest;
PMC * p = interpreter->ctx.pmc_reg.registers[0];
- dest = (o
Steve Fink wrote:
On Feb-22, Leopold Toetsch wrote:
Yep. At least add B.
Ok, done.
Good.
One minor note - and it is my fault to haven't documented that in the
first place - I did revert all the other changes, they are necessary for
pbc2c compiled code.
Of course, it would be better, to have
On Feb-22, Leopold Toetsch wrote:
> Steve Fink wrote:
>
> >So would anyone mind if I eliminated the zero-arg invoke op in favor
> >of a one-arg invoke that takes a single PMC? (I may also have
> >situations where I don't need to follow pdd03, and it would be more
>
At 10:20 AM -0800 2/20/03, Steve Fink wrote:
The invoke op is bothering me -- namely, it disturbs me that it
implicitly operates on P0. I know that P0 is the correct register to
use according to pdd03, but I dislike having it be implicit. The user
is required to set the rest of the pdd03
Steve Fink wrote:
The invoke op is bothering me -- namely, it disturbs me that it
implicitly operates on P0. I know that P0 is the correct register to
use according to pdd03, but I dislike having it be implicit. The user
is required to set the rest of the pdd03 conventions up manually, so I
don&#
The invoke op is bothering me -- namely, it disturbs me that it
implicitly operates on P0. I know that P0 is the correct register to
use according to pdd03, but I dislike having it be implicit. The user
is required to set the rest of the pdd03 conventions up manually, so I
don't see any nee
ent this directly to the list so sorry about the duplication).
The attached patch makes the following changes:
- adds invoke op to core.ops (patch does not remove call and callco)
- adds vtable method 'invoke' to vtable.tbl
- adds simple description (stolen from Dan's email) of the
On 22 Jul 2002, Jonathan Sillito wrote:
> I had a small patch ready for docs/core_ops.pod, but I see that the file
> has been removed, so now I am not sure where to put the description of
> the invoke op.
Oh, no it hasn't... core_ops.pod is autogenerated from core.ops dur
On Fri, 2002-07-19 at 16:36, Melvin Smith wrote:
> Send me a complete patch and I'll put it in. I might rename the
> op to 'call'.
The attached patch makes the following changes:
- adds invoke op to core.ops (patch does not remove call and callco)
- adds vtable method &
62 matches
Mail list logo
