Fix for a minor problem. Found by inspection.
- Sam Ruby
.sub main @MAIN
$P1 = new PerlInt
$P1 = 5
$P2 = new PerlNum
$P2 = 0.2
$P3 = new PerlNum
$P3 = $P1 / $P2
print $P3
print "\n"
.end
? classes/pyboolean.pmc
? classes/pydict.pmc
? classes/pyfloat.pmc
Dan Sugalski wrote:
At 4:23 PM -0400 10/9/04, Michal wrote:
On Sat, 9 Oct 2004, Sam Ruby wrote:
Inheritance can reduce the combinatorial problem, but it can
introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MMD_ADD, PerlString, PyString)
What if, as
e expense of
interlanguage interop.
Seems like the right thing to do to me.
As I am doing this work, should I put this on my server some place?
Check it in some place? Send it as patches?
- Sam Ruby
Leopold Toetsch wrote:
Dan Sugalski wrote:
At 2:03 PM -0400 10/11/04, Sam Ruby wrote:
Separate op won't work for Python. Consider:
def f(x,y): return x+y
print f(5,6) # 11
print f("a","b") # ab
Oh, sure it'd work, if you had an ADD_OR_CONCATENATE op
to be frequently
enough used that optimizing for such cases is warranted.
- Sam Ruby
#! perl -w
# Copyright: 2001-2003 The Perl Foundation. All Rights Reserved.
# $Id$
=head1 NAME
t/pmc/buildin-meths.t - Builtin Methods
=head1 SYNOPSIS
% perl -Ilib t/pmc/builtin-meths.t
=head1 DESCRIPTION
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Concrete example: should ResizablePMCArray inherit sort from FixedPMCArray?
Yes. But the inheritance should be (and is AFAIK already partially) in
the method lookup. But it's not quite finished. Objects derived from
PMCs inherit
Dan Sugalski wrote:
At 9:33 AM -0400 10/15/04, Sam Ruby wrote:
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Concrete example: should ResizablePMCArray inherit sort from
FixedPMCArray?
Yes. But the inheritance should be (and is AFAIK already partially) in
the method lookup. Bu
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
It still doesn't make sense to me. Try adding the following line to
both fixedpmcarray.pmc and perlint.pmc:
METHOD INTVAL inheritme() { return 42; }
Ok, that's exactly that part, which currently *is* broken. If yo
Please forgive the newbie question, but I am trying to see if I can
assess the current state of Python on Parrot to see if I can help in any
way.
I've jotted down some of what I have found so far here:
http://www.intertwingly.net/blog/2004/10/02/Pyrate
- Sam Ruby
sort through the debris in order to identify what
codebase is most likely to attract a sustainable community of developers.
- Sam Ruby
Comparison of various Python implementations for conformance:
http://www.intertwingly.net/blog/2004/10/04/Comparing-Pythons
- Sam Ruby
s with 'em... not so much sense.
Here's another one:
http://www.onlamp.com/pub/a/python/2003/04/17/metaclasses.html
- Sam Ruby
/intertwingly.net/stories/2004/10/04/summary.html
http://intertwingly.net/stories/2004/10/05/summary.html
- Sam Ruby
#x27;test/for.pir' line 1
error:imcc:parse error, unexpected FLOATV, expecting IDENTIFIER
in file 'test/for.pir' line 2
- Sam Ruby
eclared (first use in this function)
src/dynext.c:147: error: (Each undeclared identifier is reported only once
src/dynext.c:147: error: for each function it appears in.)
src/dynext.c:176: error: `PARROT_SHARE_EXT' undeclared (first use in this function)
make: *** [src/dynext.o] Error 1
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Doesn't compile for me on Debian. Did a header file change not get
checked in?
Did you reconfigure: "perl Configure.pl", possibly after "make clean"?
DOH! Thanks.
- Sam Ruby
us?
Should the Python specific behavior be removed from the Perl PMCs? If
so, when?
- Sam Ruby
h is a nearly complete disjoint set of
PMCs per language.
Inheritance can reduce the combinatorial problem, but it can introduce a
precendence question. The most interesting case still seems to be:
mmd_lookup(MMD_ADD, PerlString, PyString)
- Sam Ruby
ond on the mailing list. Suggestions welcome, in
particular, a PIR equivalent to the Perl would be most helpful.
- Sam Ruby
Aaron Sherman wrote:
On Mon, 2004-10-18 at 07:55, Sam Ruby wrote:
I've been trying to make sense of Python's scoping in the context
of Parrot, and posted a few thoughts on my weblog:
http://www.intertwingly.net/blog/2004/10/18/Python-Parrot-and-Lexical-Scopes
It seems like everything on
Sam Ruby wrote:
Unfortunately, these PMCs don't seem to have test cases.
Correction: t/pmc/sub.t
- Sam Ruby
Sam Ruby wrote:
It seems like everything on that page boils down to: all functions
are module-scoped closures.
A closer translation: "How do I implement module-scoped closures in
Parrot?"
OK, I've roughed out an implementation:
http://intertwingly.net/stories/2004/10/18/
Dan Sugalski wrote:
At 7:55 AM -0400 10/18/04, Sam Ruby wrote:
I've been trying to make sense of Python's scoping in the context of
Parrot, and posted a few thoughts on my weblog:
http://www.intertwingly.net/blog/2004/10/18/Python-Parrot-and-Lexical-Scopes
While I posted it on my
Sam Ruby wrote:
Consider the following code:
def f(x): return len(x)
for i in [0,1]:
print f("foo")
f = lambda x: x.upper()
No, don't. Consider the following code instead:
def f(x): return len(x)
for i in [0,1]:
print f("foo")
len
od on every object (an example for int is
attached). I want to pass the CPython test suite. And pass the
parrot/languages/python/t/pie tests.
- Sam Ruby
ct[1]
For Python support, it would be ideal if there would be a hash method
entry in the VTABLE for each object.
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I'm now converting to dynclasses. To be honest, I'm not thrilled with
this. What I would really prefer is a Parrot_new_p_s opcode with the
runtime worrying about caching class names across sub and module boundaries.
$
pression.
Patch attached.
Note: previously base_type for dynclasses was set twice in dynclasses.
I'm not clear why this was done. If this is important, this will need
to be restored; but without it dynclasses/dynfoo.pasm passes anyway.
- Sam Ruby
ONST_STRING()?
At the moment, each interpreter has exactly one const_cstring_table, and
there is no string_register function. Additionally, c2str.pl would need
to maintain a separate all_cstring.str file per library.
Does this sound about right?
- Sam Ruby
ed message that will simply be ignored.
If all this seems too abstract or complicated, remember that it can be
implemented incrementally, and as needed.
If logger methods map to a vtable, performance when logging is disabled
should not be a significant concern.
I'm willing to help.
- Sam Ruby
llowing, but pie-thon is not:
a=1
d={"a":a}
a=2
print d
a=[1]
d={"a":a}
a[0]=2
print d
The "correct" result is:
{'a': 1}
{'a': [2]}
With pie-thon, the results are:
{'a': 2}
{'a': [2]}
- Sam Ruby
http://cvs.
typeof S0, I0
+ print S0
- Sam Ruby
-ascii and perform a
us-ascii uppercase on them. The remaining bytes are left alone.
Example output:
>>> u'\u0061\u00e1'.upper()
u'A\xc1'
>>> '\x61\xe1'.upper()
'A\xe1'
>>> u'\u0061\u00e1'.encode('iso-8859-1').upper()
'A\xe1'
- Sam Ruby
Dan Sugalski wrote:
At 5:43 PM + 11/2/04, Nicholas Clark wrote:
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
However, str has an upper() method defined on it. The way it operates
is to take the range of bytes that correspond to us-ascii and perform a
us-ascii uppercase on them
t least to me:
.sub main @MAIN
$P0=new PerlInt
$P0=1
$P1=new PerlInt
set $P1, $P0
$P2=new PerlInt
setref $P2, $P0
$P0=2
print "$P1 = "
print $P1
print "\n"
print "$P2 = "
print $P2
print "\n"
.end
- Sam Ruby
Dan Sugalski wrote:
At 1:16 PM -0500 11/2/04, Sam Ruby wrote:
Dan Sugalski wrote:
At 5:43 PM + 11/2/04, Nicholas Clark wrote:
On Tue, Nov 02, 2004 at 12:35:26PM -0500, Sam Ruby wrote:
However, str has an upper() method defined on it. The way it
operates
is to take the range of bytes that
This omission seems odd. Was this intentional?
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it
easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
- Sam Ruby
Dan Sugalski wrote:
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
This omission seems odd. Was this intentional?
Nope.
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make it
easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Yeah, it would. I
the function below correctly (I think the Lua
syntax won't be a problem, it's quite straightforward).
(2): what is causing my strange result (see below).
[snip]
# foo(q)
.arg q
$P0()
Try this instead:
$P0(q)
- Sam Ruby
Attached patch makes building in the dynclass ghetto a bit less
inhospitable...
- Sam Ruby
? pyint.imc
? test.imc
? config/gen/makefiles/.dynclasses_pl.in.swp
? dynclasses/pyboolean.pmc
? dynclasses/pydict.pmc
? dynclasses/pyfloat.pmc
? dynclasses/pyfunc.pmc
? dynclasses/pyint.pmc
? dynclasses
Jeff Clites wrote:
On Nov 3, 2004, at 8:09 AM, Dan Sugalski wrote:
At 11:04 AM -0500 11/3/04, Sam Ruby wrote:
A single pow_p_p_p op backed by a (non-MMD) vtable entry would make
it easier to support code like the following:
def f(x): return x**3
print f(3), f(2.5)
Yeah, it would. I know
Dan Sugalski wrote:
At 10:07 AM +0100 11/4/04, Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Attached patch makes building in the dynclass ghetto a bit less
inhospitable...
Thanks, applied.
Are we comfortable adding the dynclasses to the default build target? I
want to a
into each shared library
3) linking to libparrot.so
As an added complication, the link step for dynclasses is by default run
from a different directory than the main build.
Preferences?
- Sam Ruby
enable user level __add__
methods to be called.
Prior to calling the method, there will need to be a check to ensure
that the method to be called was, in fact, overridden. If not, a
type_error exception will be thrown.
- Sam Ruby
Dan Sugalski wrote:
At 3:49 PM -0500 11/4/04, Sam Ruby wrote:
Background: Pmc2c.pm emits code which references Parrot_PMC_typenum.
This code is present in libparrot.so, which currently is not
referenced as a library by the link step for dynclasses.
Options include:
1) eliminating this
Sam Ruby wrote:
I have a simple unit test[1], one that was not intended to be a
benchmark.
I probably should have included the following in my email *blush*:
[1] http://intertwingly.net/stories/2004/11/05/parrot/t/dynclass/pyint.t
- Sam Ruby
nd Pirate tests will pass, with the exception of
the getprop test mentioned above.
I've also posted more thoughts and background at [4].
- Sam Ruby
[1] http://intertwingly.net/stories/2004/11/09/parrot/
[2] http://intertwingly.net/stories/2004/11/09/parrot.tgz
[3] http://intertwingly.net/stori
pave over, and which we simply need to post a big bold
lighthouse at.
If you can wait a few weeks, I'm willing to take a stab at it, but just
not yet. If somebody else takes the lead, I will certainly contribute.
- Sam Ruby
Sam Ruby wrote:
A patch is attached, but it bears a little discussion.
Well, that didn't exactly work. I've since commmitted these patches,
and more. A the moment, all the python and pirate unit tests pass. (Woot!)
In the absense of other direction, I plan to write more tests and u
Leopold Toetsch wrote:
There are likely some more inconsistencies, which should be fixed rather
sooner then later.
One that I noticed:
=item B(out PMC, in PMC, in STR)
=item B(out PMC, in STR, in PMC)
- Sam Ruby
Leopold Toetsch wrote:
cvsuser 04/11/19 08:28:06
Modified:imcc/t/imcpasm opt0.t optc.t pcc.t
imcc/t/syn bsr.t
Log:
replace invoke P1 in imcc tests
Revision ChangesPath
1.7 +2 -2 parrot/imcc/t/imcpasm/opt0.t
[snip]
- invoke P1/
+ returncc/
Ev
agree with this
deprecation as well as introduction of the new push_eh opcode.
All that being said, would it make sense to collect these type of
changes to a single place in CVS or on the web?
A simple CHANGES file in CVS, with a list of interfaces deprecated and
removed since 0.1.1 would suf
ites, some of which may be functions. And classes are essentially
templates for such objects.
- Sam Ruby
Jeff Clites wrote:
On Nov 27, 2004, at 5:58 PM, liorean wrote:
On Sat, 27 Nov 2004 19:30:20 -0500, Sam Ruby <[EMAIL PROTECTED]>
wrote:
Overall, JavaScript would be a good match for Parrot. One place
where it would significantly diverge at the moment is in the concept
of a "class&qu
Leopold Toetsch wrote:
I've checked in intial support for anonymous subroutines.
.sub foo @ANON
creates an anonymous subroutine.
Cool.
I can't seem to combine it with "non_prototyped".
- Sam Ruby
ly double lookup on every method call (first to see if
there's a registered MMD method for the named method, then the regular
dispatch if there's not) so I'm not sure we will. Efficient MMD wins, if
we can make it look like perl/python/ruby/tcl's method lookup rules are
in force, even if they really aren't under the hood.
Yes, MMD is the big elephant in the room. A commit later today will
create a PyComplex and PyLong that (for the moment) is a wholesale clone
of Complex and BigInt respectively simply because I wanted to override a
few methods and couldn't figure out how to get MMD to behave the way I
wanted. Obviously, this will need to be refactored later.
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Dan Sugalski wrote:
[ method lookup ]
Parrot_CompositeObject_find_method should do that. object.c should not.
I think, when going down the class hierarchy, we just have to call
class->vtable->find_method() again, i
int j(1,2,3)
for j in [f,g]: print j(a=1,b=2,c=3)
for j in [f,g]: print j(*args.values())
for j in [f,g]: print j(**args)
I see nothing in pdd 03 that provides any guidance as to how to handle
this. What makes this issue so critical is that any solution will
potentially affect *ev
Sam Ruby wrote:
Python provides the ability for any function to be called with either
positional or keyword [1] arguments. Here is a particularly brutal
example:
args={'a':1,'b':2,'c':3}
def f(a,b,c): return (a,b,c)
def g(b,c,a): return (a,b,c)
se is made of
things like infix operators and square brackets. And implemented
methods like __sub__ which, while rarely used, will operate correctly by
invoking to the opcodes.
I *don't* see a need to heavily optimize for rarely used mechanisms.
I encourage you to check out Pirate. The IMCC output of pirate.py is
now remarkably close to the output of pie-thon.pl.
- Sam Ruby
Leopold Toetsch wrote:
Sorry about that. These hacks of course include pieces like...
Cool. Peace.
Furthermore, it is
clear that operators like "sub_p_p_p" and "set_p_p_kic" will always
perform better than callmethodcc_sc "__sub__" and callmethodcc_sc
"__getitem__" respectively.
Well, and th
Am I right? Who can tell at this point. We'll know when we get there.
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
+void init () {
+SUPER();
+PMC *func_args = pmc_new(INTERP, dynclass_PyList);
Please be careful to avoid definitions after code. This doesn't compile
with C89 compilers like gcc 2.95.3
Sorry about t
Michael Walter wrote:
Uh, C89 is an ANSI/ISO C.
I'm not enough of a language lawyer to know when various features came
into to the language, but
gcc -std=c89 test.c
does *NOT* warn about declaration ordering issues. At least not with
gcc version 3.3.4 (Debian 1:3.3.4-6sarge1)
- Sam Ruby
Klaas-Jan Stol wrote:
Sam Ruby wrote:
Michael Walter wrote:
Uh, C89 is an ANSI/ISO C.
I'm not enough of a language lawyer to know when various features came
into to the language, but
gcc -std=c89 test.c
does *NOT* warn about declaration ordering issues. At least not with
gcc version
Test case attached.
- Sam Ruby
Index: t/pmc/perlhash.t
===
RCS file: /cvs/public/parrot/t/pmc/perlhash.t,v
retrieving revision 1.48
diff -u -r1.48 perlhash.t
--- t/pmc/perlhash.t1 Oct 2004 21:16:52 - 1.48
+++ t/pmc
nguage specific "wrapper", and then to the
common code which backs it. There are advantages and disadvantages to
making the dispatch methods the same. Ultimately, if they are the same,
the names should be picked in a way that minimizes the possibility of
collisions. If they differ, no such possibility exists.
- Sam Ruby
ation as possible.
Re: continuations... frankly, I'm hoping that a solution emerges that
doesn't involve significant reduction in functionallity. I might be
misunderstanding you, but it sounds to me like you are proposing
ditching lexical pads.
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
"correct". I've discovered and analysed the problem with continuations.
I've made a proposal to fix that. No one has said that it's technically
wrong or couldn't work. It se
fined in
config/init/data.pl as the "Tool used to build shared libraries and
dynamically loadable modules."
I can't find anything that fails if this is removed, so I committed the
change.
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
My philosophy is simple: things without test cases tend not not get
fixed, and when fixed, tend not to stay fixed.
There is of course a test case. I have mentioned it at least 20 times ;)
t/op/gc_13.imc - cur
Matt Fowles wrote:
keyword arguments
Sam Ruby wondered how he out to handle keyword arguments to functions.
Dan admitted that this is complex and outlined the cheat he has been
contemplating. No one has either commented on or implemented it yet.
<http://xrl.us/d955>
Oh,
done confidently and correctly.
If anybody has any issues with this plan, please let me know now.
- Sam Ruby
n both cases.
Also, I would prefer not to have to deal with implicit registers.
new_p_p would be the method signature I would prefer. The name of the
vtable entry could remain instantiate.
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
Another good reason to use pmc->vtable->fine_method in *all* lookups. So
the PMC has full control over the dispatch.
How does one lookup the C method? That will remain a
VTABLE, entry right?
Yes of cou
Ah! Now we are getting somewhere!
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
So *all* lookups (complete with the asterisks) does not mean *all* lookups.
How about ?
Let's first concentrate on simpler stuff like infix operators.
OK, but the po
rst
correct and complete, then speed considerations.
Neither of which match Python semantics. We are going to need a system
where classes are anonymous, not global. Where methods are properties
that can be added simply by calling the equivalent of set_pmc_keyed.
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
Leopold Toetsch wrote:
Here's the part that you snipped that addresses that question:
> And there is a piece that I haven't written yet that will do the
> reverse: if MMD_ADD is called on a PyObject that has
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
[ snipped - all ok }
If I define an __add__ method with 16 arguments, Python will not throw
an exception.
I didn't write that. I've said: *if* you call it via "a + b", Python
throws an exception - that one I&#x
aybe others) is currently not appropriate for Python (and likely other
languages).
That is only because the design you have in mind conflates Parrot and
language operations. There is no reason that __abs__ couldn't call
VTABLE_abs, or that __add__ can't make use of MMD_ADD.
- Sam Ruby
shared object file: No
such file or directory
Try rebuilding after you issue the following from your top level parrot
directory:
perl Configure.pl --prefix=`pwd`
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I took a look into this. Apparently, in Perl5, the result of xor'ing
undef with anything is undef. I'm not suggesting that this is either
right or wrong (it actually was surprising to me),
Yep. It doesn't really fol
Klaas-Jan Stol wrote:
Sam Ruby wrote:
Klaas-Jan Stol wrote:
Hello,
I just got a fresh cvs checkout, compiled it, compiled pge and tried
to make tcl.
This is what I get:
(cd ../../ && ./parrot --output=languages/tcl/lib/tcllib.pbc
languages/tcl/lib/tcllib.imc)
Couldn't lo
Mike Guy wrote:
Perl5 C always returns a "standard" boolean value, i.e.
dualvar(0, '') or dualvar(1, '1').Perl6/Parrot should do the same
thing.
Try:
perl -le "print 'day' xor 'night'"
On the version of Perl I have installed, I get "day" as the result.
- Sam Ruby
refactoring and documentation of a complete proposal
on how this can work.
- Sam Ruby
P.S. Peeking at the current implementation may not be wise, as a number
of shortcuts were taken (example: int objects behave as their own class,
etc), which confuses the picture.
interpinfo calls, but I feel
compelled to ask: why isn't P2 passed? It seems to me quite likely that
most methods will want to know what object they are working on.
- Sam Ruby
.sub main @MAIN
newclass $P0, 'c'
find_type $I0, 'c'
new $P1, $I0
new $P2, .PerlInt
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I'll go back and all the necessary interpinfo calls, but I feel
compelled to ask: why isn't P2 passed?
P2 is a non-preserved register and as such rather improper to hold the
object throughout a whole method.
I wasn'
tval has access to the register set
which were active when the Sub was invoked.
This patch brings Parrot_runops_fromc to parity by providing access to
those registers.
- Sam Ruby
Index: include/parrot/interpreter.h
===
RCS file
Leopold Toetsch wrote:
Sam Ruby <[EMAIL PROTECTED]> wrote:
I don't understand this. At all. But the test case added to pyclass.t
(motivated by test 4 in pie/b3.t) only passes if this change to the
get_repr op is made.
[ ... ]
-op get_repr(out STR, in PMC) {
-$1 = $2->vt
Leopold Toetsch wrote:
Sam Ruby wrote:
A few observations, first from an Parrot Internal perspective... in
general, the code for the opcodes tend to do things like the following:
$1->vtable->get_string(interpreter, $1)
Note that the object tends to be repeated as the first argument. It
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
cvsuser 04/12/15 02:36:29
Modified:.vtable.tbl
Log:
stub in object vtables
[snip]
+void add_parent(PMC* parent)
+void become_parent(PMC* class)
+INTVAL class_type()
+void add_method(STRING* method)
+void
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
+inline op get_repr(out STR, in PMC) {
+STRING *s = $2->vtable->get_repr(interpreter, $2);
+$1 = s;
goto NEXT();
}
Strange. Stranger. Strangest. Did the test fail with JIT/i386 only?
I didn't mean to
Leopold Toetsch wrote:
Sam Ruby wrote:
My need is to be able to call add_method for methods defined as @ANON.
This doesn't make sense to me. The @ANON pragma avoids the add_method
(or store_global) call in the first place.
I don't want the method added to a namespace, or stored as a
Leopold Toetsch wrote:
Sam Ruby wrote:
Before this line is executed,
(gdb) p interpreter->ctx.bp
$1 = (struct parrot_regs_t *) 0x40b6bd88
After the above line is executed:
(gdb) p interpreter->ctx.bp
$2 = (struct parrot_regs_t *) 0x40b6bae8
Then is obviously your implementation of ge
s there a reason why the invoke couldn't be done immediately prior to
the call to runops?
- Sam Ruby
be well suited for all current target
languages - IMHO.
Again, just to be clear: this hinges on dual assumptions: (1) that
wrappers aren't needed in the majority of cases, and (2) every time
someone gets or sets a method, a mapping can be done from language
defined names to Parrot conventions.
Note that in Python, all attributes may potentially be a method.
- Sam Ruby
wo objects with the same class have different
implementations of a given method.
Furthermore, every assignment to any property of any instance has the
potential of invalidating whatever caches you may have.
- Sam Ruby
Leopold Toetsch wrote:
Sam Ruby wrote:
However, VTABLE_invoke on NCI methods is where the "real work" is done
(including reading from and writing to registers), and a null dest is
returned.
Ouch. Sorry, probably cut'n'paste code, relicts or whatever. "runops_*"
i
Leopold Toetsch wrote:
Sam Ruby wrote:
Leopold Toetsch wrote:
Sam Ruby wrote:
However, VTABLE_invoke on NCI methods is where the "real work" is
done (including reading from and writing to registers), and a null
dest is returned.
Ouch. Sorry, probably cut'n'paste code,
Leopold Toetsch wrote:
Sam Ruby wrote:
But I need to do more than that. I need to do what
Parrot_run_meth_fromc_args is attempting to do (i.e., create a return
continuation and do argument or returnvalue passing.), but correctly.
1) runops_fromc and friends are running *opcodes*, nothing else
2
1 - 100 of 156 matches
Mail list logo
