Re: Bug in method calling with nonconst keys

2004-11-22 Thread Leopold Toetsch
Luke Palmer <[EMAIL PROTECTED]> wrote: > There's a pretty bad problem with calling the vtable proxy methods with > keys that aren't constant. Best illustrated by example: > .sub _main > newclass $P0, "Foo" > > find_type $I0, "Foo" > new $P1, $I0 > $I1 = $P1["foo"] > $S0 = "f

Bug in method calling with nonconst keys

2004-11-22 Thread Luke Palmer
There's a pretty bad problem with calling the vtable proxy methods with keys that aren't constant. Best illustrated by example: .sub _main newclass $P0, "Foo" find_type $I0, "Foo" new $P1, $I0 $I1 = $P1["foo"] $S0 = "foo" $I1 = $P1[$S0] end .end .namespace ["F

Re: [BUG] problem with non existing methods (Was: Re: [BUG] method calling problem)

2004-03-13 Thread Leopold Toetsch
Jens Rieks <[EMAIL PROTECTED]> wrote: > $ tar xzf err5.tgz > $ cd err5 > $ ../parrot main.imc > calling source."open"( name, "<" )... > segmentation fault I'be now turned off the stacked exceptions (one per entering the runloop) OTOH that seems to be needed for t/src/extend_13 - so I've disabled t

Re: [BUG] problem with non existing methods (Was: Re: [BUG] method calling problem)

2004-03-13 Thread Leopold Toetsch
Jens Rieks <[EMAIL PROTECTED]> wrote: > $ tar xzf err5.tgz > $ cd err5 > $ ../parrot main.imc > calling source."open"( name, "<" )... > segmentation fault The interpreter is toatally messed up after the longjmp. I'll look further what's happening here. > jens leo

[BUG] problem with non existing methods (Was: Re: [BUG] method calling problem)

2004-03-13 Thread Jens Rieks
Hi, On Saturday 13 March 2004 09:41, Leopold Toetsch wrote: > Jens Rieks <[EMAIL PROTECTED]> wrote: > > get_string() not implemented in class 'SArray' > > I've gone through err3 and err4 and found a couple of flaws, which should > mostly be fixed now: > > - method subs got compiled as non-prototyp

Re: [BUG] method calling problem

2004-03-13 Thread Leopold Toetsch
Jens Rieks <[EMAIL PROTECTED]> wrote: > get_string() not implemented in class 'SArray' I've gone through err3 and err4 and found a couple of flaws, which should mostly be fixed now: - method subs got compiled as non-prototyped - namespace resetting to main wasn't really working (now the namespa

[BUG] method calling problem

2004-03-12 Thread Jens Rieks
Hi, another day, another bug... :-) $ tar xzf err4.tgz $ cd err4 $ ../parrot main.imc main.imc: calling method readFile... get_string() not implemented in class 'SArray' I can not see whats wrong with it. It works only if the called method does not use ".param"... jens err4.tgz Description: a

Re: Method calling

2003-06-01 Thread Dan Sugalski
At 8:30 PM +0100 5/30/03, Nicholas Clark wrote: I'm not sure if I'm asking a stupid question here, but: On Fri, May 30, 2003 at 08:12:34AM -0400, Dan Sugalski wrote: You say P2 is a continuation [snip] But you seem to be using P2 like it's the object I'm confused. No, I was. There are three slot

RE: Method calling

2003-06-01 Thread Dan Sugalski
At 9:38 AM -0700 5/30/03, Jonathan Sillito wrote: Thanks Dan. One little picky thing what is the naming convention for ops? Good question--there really isn't one. I've been trying to avoid underscores in names, since it was inconvenient when the assembler was trying to figure out if you were usin

RE: Method calling

2003-05-31 Thread Jonathan Sillito
Calling convention says that before a sub/method is invoked: - P0 Holds the object representing the subroutine. - P1 Holds the continuation for the caller, assuming this sub was called with callcc. Otherwise NULL. - P2 Holds the object the sub was called on. (For method calls) Or put another wa

Re: Method calling

2003-05-31 Thread Nicholas Clark
I'm not sure if I'm asking a stupid question here, but: On Fri, May 30, 2003 at 08:12:34AM -0400, Dan Sugalski wrote: > We add three ops, findmeth, callmeth and callmethcc. (The latter just > automatically takes a continuation for the following op and stashes > it in P2, while the former assume

RE: Method calling

2003-05-31 Thread Jonathan Sillito
Thanks Dan. One little picky thing what is the naming convention for ops? find_method (currently in core.ops), call_method, and call_method_cc (or callcc_method?) or findmeth, callmeth, and callmethcc (or callccmeth?) or findmethod, callmethod, and callmethodcc (or callccmeth

RE: Method calling

2003-05-31 Thread Dan Sugalski
At 9:20 AM -0700 5/30/03, Jonathan Sillito wrote: Dan, Why is there a callmeth op? Can't we just use a regular invoke as with other subs? Or does the callmeth op do both a find and invoke as an optimization? It does a find and invoke, and the callmethcc does a find, cc-capture, and invoke. I'm n

RE: Method calling

2003-05-31 Thread Jonathan Sillito
Dan, Why is there a callmeth op? Can't we just use a regular invoke as with other subs? Or does the callmeth op do both a find and invoke as an optimization? Jonathan Sillito > -Original Message- > From: Dan Sugalski [mailto:[EMAIL PROTECTED] > > Nope, not objects, but at least it's part

Method calling

2003-05-30 Thread Dan Sugalski
Nope, not objects, but at least it's partway there. This bit is about making method calls. We've two issues on the front end. First, we need to be able to get a method PMC from an object, in those cases where we want to save that for later, and second we need to call methods. So, here's how we'