the problem? The patch was kind of a hack, so I'm
not surprised it exploded in a different environment. I'll try a completely
different approach, and get back to you. Thanks.
--
Alek Storm
t is $P2 when you use PIR syntax. Here's
how to get the effect you want:
.sub main :main
$P0 = newclass 'Func'
$P1 = newclass 'Obj'
$P2 = new 'Obj'
$P3 = find_method $P2, 'some_method'
$P3.$P3()
.end
The patch has been reverted, though, so that won't work until it's fixed and
reapplied.
--
Alek Storm
On 5/11/07, Alek Storm <[EMAIL PROTECTED]> wrote:
Whew. Thanks for looking over my giant patch :). I've split the original
patch into three parts - testing, specs, and code, and rebased it on
r18494. I've also cut out the code that modified the implementation of
invoke() i
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42919]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42919 >
Because PIR can't tell the difference between invoking an object PMC
efined in a PIR class to
override a vtable function.
I like that differentiation. Now I can eliminate a lot of ambiguity when I
talk about vtables :)
--
Alek Storm
d in PDD15.
As far as I know, we still need :method, because it changes the arg
signature of the sub to get 'self' as the first argument. If we were to
remove it, we could work around this and still get 'self' to work without it
being an argument, but then how would 'self&#x
eated at load time in both the PDD15 and
old object systems - that's where we stick the 'newclass' opcode.
--
Alek Storm
wn
for
> 'init_pmc', see below.
(morph) FYI, there are dynamic PMCs that already override morph, for good
or
evil.
Allowing 'morph' is possible. Let's see what others think.
--
Alek Storm
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42905]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42905 >
I've attached a patch to implement vtable overriding for PDD15. Th
by other things. Great work. Thank you very much for
accomplishing what I failed to do :)
--
Alek Storm
On 5/3/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm wrote:
> I'm almost done with the PDD15 implementation of vtable overriding. It
> adds
> the 'add_vtable_method' PCCMETHOD to Class, but also adds methods to the
> vtable in 'add_method'
pendent on the object
system used. The default (PDD15) object system utilizes vtable overriding,
but other object systems have different semantics. This means, while PIR
code can wrap PMCs in their own object system, we can't make all PMCs
object-aware. If you want to override vtable methods for built-in PMCs such
as Integer, you need to implement PMC subclassing for PDD15 ;)
--
Alek Storm
On 4/24/07, via RT Ron Blaschke <[EMAIL PROTECTED]> wrote:
The output of the failed tests is attached.
No, it's not. One more time, with feeling ;).
--
Alek Storm
de in r18305 and applied Alek's original patch as
r18306.
Thanks, everyone!
Gracias. I attached one more small patch that gets rid of two
seemingly unnecessary lines in smop_init() - they're easy to miss when
one's looking at the big picture.
--
Alek Storm
Index: src/p
On 4/23/07, Matt Diephouse <[EMAIL PROTECTED]> wrote:
Looks like either (a) you forgot to attach the patch or (b) RT ate it.
Care to try again? :)
Oops - looks like the former. Here we go...
--
Alek Storm
--- /dev/null 1994-07-17 23:46:18.0 +
+++ ./test.pir 2007-04-20
oesn't trigger a DOD run on an unpatched parrot, so it doesn't show
up unless you use gdb. At least it's Not My Fault(TM), but this one looks like
a doozy to fix. Someone more familiar with the garbage collector than I needs
to sort this out. Should we start a new ticket?
--
Alek Storm
This patch has been sitting for over a week. Is there a problem? I
can't continue work in this area until this is committed.
--
Alek Storm
, it's rare, but the patch doesn't cost anything, so it
might as well be applied. It won't matter once we get rid of the old
object system, but it makes me feel better for now :)
P.S. I picked Integer to stick foo() in arbitrarily, just to make
things simpler.
--
Alek Storm
thing unless I
understand it. You've tried to explain things to me in several tickets that
I already fully understand. I am especially surprised you would try to
explain the current implementation of vtable overriding to me, since I
implemented a lot of it. Thanks.
--
Alek Storm
On 4/18/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm wrote:
>> >
>> > So, that still means :method can mean two different things, depending
>> > on whether :vtable is present or not. That's still bad.
>>
>> How so? Without
On 4/18/07, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 18 April 2007 15:59, Alek Storm wrote:
> Without :vtable, :method adds a method to the class. With :vtable,
> :method doesn't add a method to the class - it makes the sub visible.
> Two completely different thin
On 4/18/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm wrote:
>
>> Again, the only part of :method that :vtable needs to imply is the
>> part that
>> sets the invocant in the proper register and makes 'self' available
>> within
>>
On 4/18/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm wrote:
> .sub get_string :vtable :method :anon # now we're in trouble
Just like ":method :anon", but also stores it as a vtable entry.
But herein lies the problem. Saying ":vtable :method :anon
On 4/18/07, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 18 April 2007 14:15, Alek Storm wrote:
> > If that's true, then users have to *know* the implementation details of
> > vtable methods. Is it in C code or is it in PIR code?
>
> I have no idea why you
Okay, I think we completely misunderstood each other. Honestly, most of what I
said was a reply to Allison's proposal.
On 4/18/07, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 18 April 2007 13:34, Alek Storm wrote:
> Vtable methods defined in C are visible from C.
Of cou
This patch has been sitting for over a week. Is there a problem?
It's just a bugfix.
--
Alek Storm
m the namespace, but in a
vtable sub, it's detached by default, and the :method flag attaches it
to the namespace. Reversal bad. Continuity good.
--
Alek Storm
get_string :vtable :method # same as before
.sub get_string :vtable :anon # same, but not attached to the
namespace (note that the user has actually specified this, so they
expect it to happen)
.sub get_string :vtable :method :anon # same as before
--
Alek Storm
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42548]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42548 >
The following code demonstrates the reversed output of Object.can():
.s
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42547]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42547 >
The following code causes a segfault:
.sub main :main
$P0 = new "
e namespace - the sub itself
retains a reference to the namespace. How would you want it to work?
--
Alek Storm
are deleted, and a few more are added. If
that looks like an single operation at the HLL level, even though it
takes a slew of Parrot ops, then you want to be sure that the class
manipulation succeeds completely before replacing the original class
definition as the one that find_class should return.
That's only a problem if add_method and friends register the cloned class
every time they're called, which in my opinion should not be done. Class
registration should take place after all modifications are completed.
Sorry for the length - couldn't help myself ;)
--
Alek Storm
r this. Vtable methods are
methods, and they're called as methods from C.
--
Alek Storm
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42430]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42430 >
This patch makes the :vtable sub pragma imply the :method pragma,
whi
ll be screwed up/inconsistent. I'm not sure how
requiring HLLs to deal with explicit cloning would be simpler than
having it abstracted away. This system is much more flexible.
Error recovery would also be easier for explicit cloning; what happens
if one of the class-mutating methods throws an error?
I'm afraid you lost me. How would this be different? Could you
provide some more information?
--
Alek Storm
k of is the overhead involved in creating
a new clone of the class for every change to it, for example, when
many attributes are added at once, but I imagine it would be minimal,
since classes are generally initialized once and that's it. If it is
a problem, we could create a shortcut method that takes a list of
attributes to add, or something like that.
--
Alek Storm
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42408]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42408 >
And... oops. Here's the patch, in all its glory.
--
Alek Storm
In
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42407]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42407 >
This patch refactors and optimizes methods involved in vtable
overriding
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42406]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42406 >
This patch fixes the bug in which the "init" vtable method ove
On 4/4/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm wrote:
>
> Whoops, that metaclasses reference didn't quite make sense (it was
pretty
> late in my timezone). I meant that, in Smalltalk for example, classes
are
> also first-class objects. Also, in prototy
On 4/3/07, Alek Storm <[EMAIL PROTECTED]> wrote:
we can just use set_hll_global and get_hll_global, storing the class
PMCs like normal objects. Which makes sense, given that class PMCs
can also *be* normal objects (metaclasses, etc), and we don't need a
separate container for c
talk-to-PIR compiler used
this, and it worked quite well.
Then again, the syntactic sugar methods could just be a role applied to
Class, once we get roles working for low-level PMCs.
Now *that* would be cool.
--
Alek Storm
s" to the list of do-able interfaces available to PMCs
in tools/build/pmc2c.pl.
--
Alek Storm
On 3/31/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm wrote:
>>
>> $P0 = get_hll_namespace
>> $P1 = $P0.find_class("HLLClass")
>> $P2 = $P1.new()
>
>
> Will new() be a vtable method or PCCMETHOD in a Class PMC? That's the
only
&
Thank you, but I know what a PCCMETHOD is.
On 3/31/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm wrote:
>>
>> $P0 = get_hll_namespace
>> $P1 = $P0.find_class("HLLClass")
>> $P2 = $P1.new()
>
>
> Will new() be a vtable method or PCCME
$P0 = get_hll_namespace
$P1 = $P0.find_class("HLLClass")
$P2 = $P1.new()
Will new() be a vtable method or PCCMETHOD in a Class PMC? That's the only
way I can see this syntax not conflicting with normal method-calling syntax.
On 3/31/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm wrote:
> Hmm. You know what I just found out? The ParrotInterpreter PMC
> doesn't implement set_pmc_keyed. Any objections to implementing it?
Pass. It has methods, and access to the internal data of the i
dence that it significantly hurts performance, which was, IIRC, the only
objection to the patch. Also, it's quite easy to change the benchmark time:
just add another zero to the command-line parameter, and it'll take about
ten times as long.
P.S. Thanks for the link! That'll come
s Clark <[EMAIL PROTECTED]> wrote:
On Fri, Mar 30, 2007 at 10:25:59PM +, Alek Storm wrote:
> How about like this:
>
> $P0 = getinterp
> $P0["recursionlimit"] = 2000
> $P0["recursionlimit"] = -1
>
> Where the last one signifies an infinite recu
keyed string interface to the
flags would be a lot nicer than OR-ing values together.
Come to think of it, why are we using a keyed interface at all? Why
can't we just use getprop and setprop, or getattribute and
setattribute? It's what they were designed for, after all.
On 3/30/07, Ale
How about like this:
$P0 = getinterp
$P0["recursionlimit"] = 2000
$P0["recursionlimit"] = -1
Where the last one signifies an infinite recursion limit (unsafe, but
it should still be available to HLL implementors).
On 3/30/07, chromatic <[EMAIL PROTECTED]> wrote:
On Friday 30 March 2007 13:38,
bench.pir 10
Since leo was concerned about memory usage, by running valgrind:
$ valgrind --tool=massif parrot bench.pir 10
I found that, over several runs, the spacetime (time * bytes) usage is
slightly better with the patch than without. Can someone confirm this
also?
Thanks,
Alek Storm
On 3/28/07, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
1) This ism't needed, these pointers are only valid and needed up to the
next
sub call/return.
The current_results member already lives in Parrot_Context; this patch
just moves the rest of them there as well. Variables can't be global
simp
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42155]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42155 >
This patch moves args_signature, params_signature, returns_signature,
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #42074]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42074 >
This patch defines a RECURSION_LIMIT macro in include/parrot/sub.h,
Sun Mar 04 19:33:30 2007, [EMAIL PROTECTED] wrote:
> Just kidding! Here's the patch, for real this time.
>
> On 3/4/07, Alek Storm <[EMAIL PROTECTED]> wrote:
> > That's because the patch refers to a function that is now outdated
> because
> > of #41549. I'
I'm still working on my use case, but it appears the new MetaClass PMC
(src/pmc/metaclass.pmc) could use this vtable method as well; currently it
only has an add_attribute PMETHOD.
On 3/4/07, Alek Storm <[EMAIL PROTECTED]> wrote:
Hmm, no, these deal with normal object attributes.
and into the invokecc opcode. This would
result in invoke() being abstracted away from dealing with the pc.
On 3/10/07, Alek Storm <[EMAIL PROTECTED]> wrote:
That is definitely the most elegant solution. Now, the question is,
shouldn't the invoke() vtable method behave that way in the
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 other
d
.param int address
say "you invoked me!"
.return(address)
.end
.sub main :main
$P0 = newclass "Foo"
$P1 = new "Foo"
$P1()
say "got here"
.end
Thanks,
Alek Storm
On 3/7/07, via RT richard @ hive-systems. com
<[EMAIL PROTECTED]&g
Hmm, no, these deal with normal object attributes. I believe you're
thinking of properties. I'll put together some sketch code with what
I already have and post that.
Thanks,
Alek Storm
On 3/5/07, chromatic <[EMAIL PROTECTED]> wrote:
On Sunday 04 March 2007 19:13, Alek St
Just kidding! Here's the patch, for real this time.
On 3/4/07, Alek Storm <[EMAIL PROTECTED]> wrote:
That's because the patch refers to a function that is now outdated because
of #41549. I've attached an updated version of the patch.
Thanks,
Alek Storm
On 3/2/07, [EM
Alek Storm
On 3/4/07, Joshua Isom <[EMAIL PROTECTED]> wrote:
On Mar 4, 2007, at 12:40 PM, Alek Storm wrote:
> For the same reason we have set_attr, set_attr_str, get_attr, and
> get_attr_str, even though they're only used by ParrotObject - it
> allows for
> multiple, conc
That's because the patch refers to a function that is now outdated because
of #41549. I've attached an updated version of the patch.
Thanks,
Alek Storm
On 3/2/07, [EMAIL PROTECTED] via RT <[EMAIL PROTECTED]> wrote:
On Sun Feb 25 20:10:00 2007, [EMAIL PROTECTED] wrote:
>
I'm almost done with a different patch that preserves the parent context for
the purpose of returning values into it. All further tailcalled contexts
are freed as normal. That's pretty vague, but it's easier just to see the
code. I just haven't had time to finish and relea
lt way of doing
things? In Smalltalk, objects and classes work very differently, to the
point where I have a wrapper object around every class. It would be a whole
lot easier if I could define my own class implementation.
On 3/2/07, Allison Randal <[EMAIL PROTECTED]> wrote:
Alek Storm (vi
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #41620]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41620 >
This patch changes the , , and syntax in opcodes to , , and , respe
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #41619]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41619 >
This patch adds the add_attr, rem_attr, and rem_attr_str vtable
methods
Now that 0.4.9 has been released, can this be committed?
Thanks,
Alek Storm
On 2/19/07, Alek Storm <[EMAIL PROTECTED]> wrote:
Thanks for the head start; now I know to include a test in the future.
Here is an updated version of your patch, with various minor fixes.
On 2/17/07, Allison
The problem is that a Sub is not a ParrotObject, so it has nowhere to
store attributes. That's why attr_str_2_num throws "Can't set
non-core object attribs": it can't safely use PMC_data unless you've
passed a ParrotObject. I've attached a patch that implements a basic
attribute storage system f
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #41549]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41549 >
This patch resolves the problem mentioned in Patrick's replies to
Thanks for the head start; now I know to include a test in the future.
Here is an updated version of your patch, with various minor fixes.
On 2/17/07, Allison Randal via RT <[EMAIL PROTECTED]> wrote:
On Sat Jan 27 11:39:15 2007, [EMAIL PROTECTED] wrote:
> This patch allows object vtable method o
# New Ticket Created by "Alek Storm"
# Please include the string: [perl #41364]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41364 >
This patch allows object vtable method overrides for find_method, get_a
73 matches
Mail list logo
