On Tue, Dec 02, 2008 at 11:39:43PM -0800, Stephen Weeks via RT wrote:
> I think this is fixed in r33451. Can anyone confirm?
>
> If nobody speaks up in a few days, we should close this ticket.
I tried the test code in RT #56458 and if I remove the 'pop_eh'
it appears to work correctly in r33451
I see that on 0.6.4 within cygwin my linker does not work anymore.
Latest svn smokes from before the release built fine.
Checking the Makefiles I see that some objects had been added to
the end of the linker lines which is invalid on newer gcc versions and windows.
First the objects, then the
# New Ticket Created by Bob Rogers
# Please include the string: [perl #56458]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56458 >
Every RetContinuation in the active call chain must be promoted to a
full Continuation
This appears to have been resolved by jonathan++ in r28716.
Way to go Jonathan!
Pm
PDD15 says:
: =item - Objects may have a custom vtable or use a class-wide vtable.
How does one do this?
Also, at one time it was mentioned that we would have a way to
add roles to individual objects -- is that still on the table?
Pm
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #48507]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48507 >
The n_add, n_sub, etc. opcodes don't seem to work when an object
is used as the fi
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #48467]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=48467 >
Using assign with an Object causes it to create a Ref
instead of assigning a copy
On Mon, Nov 26, 2007 at 04:01:37PM +0200, Allison Randal wrote:
> Patrick R.Michaud (via RT) wrote:
> >
> >This isn't a super-huge priority at the moment... for the
> >time being we can simply have PCT not attach any :outer
> >flags to methods. But eventually we'll probably want to
> >have this wo
Patrick R.Michaud (via RT) wrote:
This isn't a super-huge priority at the moment... for the
time being we can simply have PCT not attach any :outer
flags to methods. But eventually we'll probably want to
have this working.
Can you give me an HLL use case, so we get the implementation right? A
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #47794]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47794 >
The :method flag on subs doesn't seem to work when
the :outer flag is present. H
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46687]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46687 >
In src/pmc/eval.pmc:thaw() there is the todo item (with some context):
/*
Resolved in r22089 with a patch from Juan Natera (Pabellon) at the PPW
Hackathon.
Klaas-Jan Stol (via RT) wrote:
a code snippet like this:
the_value = new 'Type'
the_value = 42
is in my eyes not clear. It seems as if the first line creates an object,
and it seems to be discarded on the second line, as some value is assigned
to the_value.
The key thing to keep in mind is t
On 10/2/07, via RT Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
>
> # New Ticket Created by Klaas-Jan Stol
> # Please include the string: [perl #45935]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=45935 >
>
>
> hi,
>
> a cod
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #45935]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45935 >
hi,
a code snippet like this:
the_value = new 'Type'
the_value = 42
is in my eyes n
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45997]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45997 >
In src/objects.c:attr_str_2_num() there is the todo item:
/* XXX Shared objects h
RUCT for creating new objects?
Then work out why it's used in the code that follows the comment, and
adjust if necessary.
This patch (not quite for application) builds on yesterday's free list
de-sucking patch. It sets the "Hey, I'm free!" flag on all objects on the
free list, then adds assertions to the PMC_IS_NULL() and saneify_string()
macros to make sure that neither use free PMCs.
Parrot
# New Ticket Created by Sandy Bultena
# Please include the string: [perl #43424]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43424 >
The documentation in pdd15_objects.html referring to callmethod and
callmethodcc st
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
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 prototype-based languages like Self and
ECMAScript, objects might also want to act
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
Since classes are now a great deal more polymorphic, it seems we don't
really need a newclass opcode anymore, since HLLs will instantiate the
class objects themselves anyway. Instead of having
$P0 = get_class "HLLClass"
$P1 = $P0.new()
Or:
$P0 = get_hll_namespace
$P1 =
Allison Randal wrote:
Class is the base for all classes. I can see the value of stripping away
any methods that may interfere with a particular HLL's concept of how a
class should behave, so we'll do that. And what should we call the
subclass of Class that adds lots of methody syntactic sugar
Alek Storm wrote:
I've asked for something pretty darn close to what you've suggested
(see #41619), but you've explained it a lot better than I ever could.
Glad we're thinking similar things.
What I think you were saying:
Default
|
Jonathan Worthington wrote:
All that said, there is an argument for having it as a vtable method
that I think stands, which is the same argument that suggests not having
any methods on the class PMC at all and making everything a vtable
method. The argument is that if a language wants to inheri
On 4/3/07, Jonathan Worthington <[EMAIL PROTECTED]> wrote:
There is a compromise - make them all vtable methods, write a BaseClass
PMC and inherit Class from it. BaseClass implements all of the vtable
variants of the method, and Class can then provide a sane interface. HLL
implementers who need
work for the semantics of all languages. According to PDD15,
"[Isolation from implementation details] also allows for multiple
concurrent interoperable object systems. The major thrust is for
transparent use of objects, though most class activity (including
creation of subclasses and modifications
hod
called on the instance of the class object. The two don't conflict
because they're called on different objects.
It sounds like you're getting confused about what a PCCMETHOD is. It's a
method defined in C code that can be called using the full Parrot
calling conventions. Tha
Am Montag, 2. April 2007 07:37 schrieb Joshua Isom:
> I'm not sure how the imcc compiler handles the .Foo syntax internally,
> but there's a file, runtime/parrot/include/pmctypes.pasm that at least
> appears as though it's magically included into the beginning of every
> pir/pasm file.
Nope the pm
Joshua Isom wrote:
I'm not sure how the imcc compiler handles the .Foo syntax internally,
but there's a file, runtime/parrot/include/pmctypes.pasm that at least
appears as though it's magically included into the beginning of every
pir/pasm file. If it were changed to output a string instead
On Mar 31, 2007, at 3:24 PM, Allison Randal wrote:
Jonathan Worthington wrote:
Does this also imply that all number-based type instantiation is
going away, and thus we need to deprecate the find_type op too?
Eventually, yes (almost certainly), but not in the next month.
Allison
I'm not su
Allison Randal wrote:
Or, can I also write:
$P0 = Integer.new() # create new Integer PMC object
$P1 = Hash.new()# create new Hash PMC object
No, we're eliminating bareword class names from PIR/PASM entirely. It's
easy to do that in an HLL, though.
Unless, of course, you declare Int
Klaas-Jan Stol wrote:
$P0 = get_class "HLLClass"
$P1 = $P0.new()
IIUC, instead of create a new object (either a built-in PMC or an OO
object) in 1 instruction, it should now be done in 2?
Yes. It adds a small amount of tedious typing, but gains us a great deal
of power in our OO system. We
Allison Randal wrote:
Klaas-Jan Stol wrote:
Hello,
I have a short and simple question w.r.t. syntax for constructing new
objects for the architect :-)
Currently, it's done through:
new P0, .Integer
or in PIR:
$P0 = new Integer # or .Integer
I thought to have read somewhere this wi
On Saturday 31 March 2007 12:42, 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
> way I can see this syntax not conflicting with normal method-calling
> syntax.
I
d on the class object, and foobar() is a method
called on the instance of the class object. The two don't conflict
because they're called on different objects.
It sounds like you're getting confused about what a PCCMETHOD is. It's a
method defined in C code that can be called using the full Parrot
calling conventions. That is, it's an ordinary method.
Allison
Jonathan Worthington wrote:
Allison Randal wrote:
No dot-prefix, but also no bareword class names. Only quoted names.
Same is true for both high-level objects and low-level PMC objects.
I guess the upshot of this is we need to deprecate the old syntax and
make sure the new one works. Deprecate
ordinary method on the class object. So, in
this code:
$P1 = get_class "Dog"
$P2 = $P1.new()
$P2.foobar()
new() is a method called on the class object, and foobar() is a method
called on the instance of the class object. The two don't conflict
because they're called on d
Allison Randal wrote:
No dot-prefix, but also no bareword class names. Only quoted names.
Same is true for both high-level objects and low-level PMC objects.
I guess the upshot of this is we need to deprecate the old syntax and
make sure the new one works. Deprecate in the next release, remove
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?
It's implemented as a PCCMETHOD in the Class PMC, yes.
Though at the moment you must write:
$P2 = $P1.'new'()
But that may well be a bug in I
$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.
Klaas-Jan Stol wrote:
Hello,
I have a short and simple question w.r.t. syntax for constructing new
objects for the architect :-)
Currently, it's done through:
new P0, .Integer
or in PIR:
$P0 = new Integer # or .Integer
I thought to have read somewhere this will be changed into some
Hello,
I have a short and simple question w.r.t. syntax for constructing new
objects for the architect :-)
Currently, it's done through:
new P0, .Integer
or in PIR:
$P0 = new Integer # or .Integer
I thought to have read somewhere this will be changed into something
like this:
# New Ticket Created by Will Coleda
# Please include the string: [perl #41776]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41776 >
from docs/BROKEN.pod
=item * ParrotIO objects that work on strings
It should
# 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
ity to attach methods to subs
sooner rather than later
(subs as real objects isn't that critical, but it's
continually coming up)
(I can continue to implement workarounds)
patrick: put together a list of what you need sub objects to do
I'll roll it into the objects PDD
allison:
On Sat, Nov 04, 2006 at 08:46:37PM +, Jonathan Worthington wrote:
> Jonathan Worthington wrote:
> >At the moment, if you have some ParrotObject instance, say foo, and do
> >something like:
> >
> > $S0 = foo
> >
> >Then $S0 will contain the name of the class.
> >
> >=item C
>
> Erm, what the h
Jonathan Worthington wrote:
At the moment, if you have some ParrotObject instance, say foo, and do
something like:
$S0 = foo
Then $S0 will contain the name of the class.
...
=item C
Erm, what the heck was I smoking when I wrote this...the name method
doesn't control what an object stringi
Patrick R. Michaud wrote:
I propose this is removed in a week, please respond if you'd have an
issue with that or think that's too short.
I think it's too long. :-)
Does anything fail if you eliminate it (e.g., via "make tests")?
If no, then I think it's okay to eliminate, and we'll see
On Sat, Oct 28, 2006 at 06:50:05PM +0100, Jonathan Worthington wrote:
> So, I want to get rid of this and allow this v-table method to just
> dispatch to a user implementation or a fallback. But before I do that, I
> wanted to check if anyone is relying on the behavior? I'd really rather
> not b
Hi,
At the moment, if you have some ParrotObject instance, say foo, and do
something like:
$S0 = foo
Then $S0 will contain the name of the class. This is BAD because it
means you can't overload what a class stringifies too! In fact, there is
a comment in the code saying that:
/*
=item C
Am Samstag, 13. Mai 2006 05:36 schrieb Patrick R.Michaud (via RT):
> I've run into the following problem using concat with
> Match objects from PGE. The code below performs a match,
> then attempts to concatenate a string with the results
> of the returned Match object:
This i
On Mon, May 15, 2006 at 03:29:23AM -0700, Leopold Toetsch via RT wrote:
> Patrick R.Michaud (via RT) wrote:
>
> > I've run into the following problem using concat with
> > Match objects from PGE. The code below performs a match,
> > then attempts to concatenate a s
Patrick R.Michaud (via RT) wrote:
I've run into the following problem using concat with
Match objects from PGE. The code below performs a match,
then attempts to concatenate a string with the results
of the returned Match object:
There are several problems with the internals of ob
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #39135]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39135 >
I've run into the following problem using concat with
Match objects
Patrick R.Michaud (via RT) wrote:
If a subclass doesn't define an "__init" method, then creating
a new instance of the subclass results in multiple calls to
the base class "__init" method.
Fixed, r12594. (__init was searched in parents with find_method, which
also searched parents ...)
I'v
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #39081]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39081 >
If a subclass doesn't define an "__init" method, then creating
a new instance of
Patrick R.Michaud (via RT) wrote:
This patch (which replaces the patch I sent earlier in #37430)
adds support for the other *_keyed_int methods (needed for PGE).
The patch also updates the corresponding test in t/pmc/object_meths.t .
Looks good. Just ci it - thanks.
leo
et_*_keyed_int
and set_*_keyed_int methods for parrot objects.
This patch (which replaces the patch I sent earlier in #37430)
adds support for the other *_keyed_int methods (needed for PGE).
The patch also updates the corresponding test in t/pmc/object_meths.t .
Sorry for the double-patch submission
int methods for parrot objects.
This patch adds support for delete_keyed_int (needed for PGE),
as well as updating the corresponding test in t/pmc/object_meths.t .
Pm
Index: classes/parrotobject.pmc
===
--- classes/parrotobject.
On Sun, Jun 12, 2005 at 10:52:37AM +0200, Klaas-Jan Stol wrote:
> I read that when creating a new class, then a new ParrotClass is
> created. (ParrotObject is the PMC that takes care of the
> implementation of a run-time object in Parrot, right?). But, a new
> class can inherit from a built-in PMC
Leopold Toetsch wrote:
Klaas-Jan Stol wrote:
hi,
My question concerns functionality of PMCs and Objects.
while reading the docs about the functionality of classes and
objects, I read that the vtable entries of a class can be overridden
to give the class special behaviour. I'd li
Klaas-Jan Stol wrote:
hi,
My question concerns functionality of PMCs and Objects.
while reading the docs about the functionality of classes and objects, I
read that the vtable entries of a class can be overridden to give the
class special behaviour. I'd like to know if I'm corre
hi,
My question concerns functionality of PMCs and Objects.
while reading the docs about the functionality of classes and objects, I
read that the vtable entries of a class can be overridden to give the
class special behaviour. I'd like to know if I'm correct (I just
realized this)
ould (in the default implementation) return the first matching
attribute in the objects MRO. A full qualified name
"class_name\0attr_name" could still be used, if needed.
Performance considerations:
A class system can implement the (new) vtable:
ptrdiff_t get_attribute_offset(.
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:13 AM +0100 12/14/04, Leopold Toetsch wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>
>>> subclass - To create a subclass of a class object
>>
>>Is existing and used.
>
> Right. I was listing the things we need in the protocol. Some of the
rading as other classes, but I can see some other cases)
> get_anonymous_subclass - to put the object into a singleton anonymous
subclass
How is the singleton object created in the first place?
For now, I think singletons will all be objects of a normal cl
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> subclass - To create a subclass of a class object
Is existing and used.
> add_parent - To add a parent to the class this is invoked on
> become_parent - Called on the class passed as a parameter to add_parent
What is the latter used for?
e, I can imagine the following scheme:
0) Our current MMD_table is 2-dimensional only and totally static.
Furthermore it doesn't really fit into method lookups as it's an
assymmetric second case.
1) Single method lookup.
Current state: works for objects and NCI class methods. Does not work
Leopold Toetsch wrote:
OTOH when you have
math.sin(2)
Python emits:
6 44 LOAD_NAME0 (math)
47 LOAD_ATTR1 (sin)
50 LOAD_CONST 1 (2)
53 CALL_FUNCTION1
which actually is a method call on the "
his is in order to supports Ruby's feature of being able
: add methods to individual objects.
:
: In the following code
:
: class A
: end
:
: a = A.new
: def a.method()
: end
:
: this creates an anomynous subclass of A and makes a an instance of the
: new class.
Perl 6 also does this if y
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>> Well, and that's not true. I've already shown the opposite:
>> Here are agains these numbers (-O3 build, AMD 800, 5 Meg operations):
>>
>> MMD add PerlInt PerlInt 0.693220
>> MMD add PerlInt INTVAL 0.609069
>> MMD sub PerlInt PerlInt
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
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> Point of order: discussions would be a lot easier if they didnt *start
> out* with perjorative terms like "ugly hacks". One of my goals is to
> eliminate the need for if (!Interp_flags_TEST(INTERP,
> PARROT_PYTHON_MODE)) sprinkled thr
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Anyway, so much for the 'outside world' view of objects as black box
things that have properties and methods.
[ ... ]
Almost everything we do here is going to be with method calls.
There's very little that I can
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Almost everything we do here is going to be with method calls.
Just one additional note:
$ python
>>> from cmath import sin
>>> print sin(2+3j)
(9.15449914691-4.16890695997j)
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Anyway, so much for the 'outside world' view of objects as black box
> things that have properties and methods.
[ ... ]
> Almost everything we do here is going to be with method calls.
> There's very little that I can se
method, then I'm quite OK with
> that. If "we" is Parrot_default_find_method, then I'm fine too.
> However, if "we" is src/object.c, then let's talk some more.
The object's find_method vtable can do the method lookup on its own of
course. The implementat
Sam Ruby wrote:
All objects also must be able to perform the method:
get_anonymous_subclass - to put the object into a singleton
anonymous
subclass
Sorry, you lost me here.
A singleton object is the sole instantiation of a class. You'll always
get that one o
ll the "core" and "dynclass" are indexed for
convenient access. But, in any case, there should be a "new_p_p" opcode
which should do a $1=$2->vtable->instantiate(interpreter);
That is exactly what is currently PObj = Pclass->vtable->new_extended().
Cool!
A
ind_global.
> And, yes, the PMC's for all the "core" and "dynclass" are indexed for
> convenient access. But, in any case, there should be a "new_p_p" opcode
> which should do a $1=$2->vtable->instantiate(interpreter);
That is exactly what is c
Dan Sugalski wrote:
Right, so with at least a basic rework of the string stuff in, it's time
to turn our attention to objects and all the stuff that goes with them.
I'd originally thought that the bits we'd put in place would be
sufficient to do everyone's object system (wel
Right, so with at least a basic rework of the string stuff in, it's
time to turn our attention to objects and all the stuff that goes
with them.
I'd originally thought that the bits we'd put in place would be
sufficient to do everyone's object system (well, all th
On Tue, 22 Jun 2004, Leopold Toetsch wrote:
> Pie-thon has Exception objects. We'll need such beasts too. So:
> 1) How do we "translate" Python classes? Properties only? Or
> full ParrotClass objects?
I think ParrotClass objects with properties should work fine.
Pie-thon has Exception objects. We'll need such beasts too. So:
1) How do we "translate" Python classes? Properties only? Or
full ParrotClass objects?
2) We'll need to classify our exceptions somehow so that we can model an
exception class hierarchy. We'll al
William Coleda <[EMAIL PROTECTED]> wrote:
> I've been trying to wrap my head around freezing and objects. My
> current understanding is that:
> o parrotclass extends delegate
> o delegate's freeze vtable entry is Parrot_delegate_freeze
> o Parrot_delegate_fr
I've been trying to wrap my head around freezing and objects. My current
understanding is that:
o parrotclass extends delegate
o delegate's freeze vtable entry is Parrot_delegate_freeze
o Parrot_delegate_freeze should delegate the freeze vtable method to PASM.
However, when parrotcl
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> If we do that it means every PMC class is essentially a base type as
> far as Parrot's concerned.
Basically yes. We just borrow some functions from parents to avoid
reimplementation and to reduce code size. I don't think that we need
much more inside the
At 9:39 AM +0200 5/18/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The question isn't whether they *do*--rather it's whether they
*should*. The current implementation's not all that relevant except
as a demonstration of one set of semantics. What I want to do is work
out w
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The question isn't whether they *do*--rather it's whether they
> *should*. The current implementation's not all that relevant except
> as a demonstration of one set of semantics. What I want to do is work
> out what the 'proper' semantics ultimately should
At 5:54 PM +0200 5/17/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
The basics of MMD are almost done. The two things we still need to
deal with are:
*) Inherited methods
*) Objects
... Either way we need to build up
the tables so inherited MMD methods actual
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The basics of MMD are almost done. The two things we still need to
> deal with are:
> *) Inherited methods
> *) Objects
> ... Either way we need to build up
> the tables so inherited MMD methods actually get inherited.
MMD re
The basics of MMD are almost done. The two things we still need to
deal with are:
*) Inherited methods
*) Objects
The big issue with inherited methods is how we treat parents of PMC
classes, since they're both on a separate inheritance tree and also
feel like they've got a very
At 10:14 PM + 3/27/04, Harry Jackson wrote:
In PDD 15 it says
Creating a new class with attributes
Adding the attributes a and b to the new class Foo:
D'oh! Docs are wrong, I'll go fix 'em.
--
Dan
--"it's like this"--
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> C becomes C if only P-registers are used. Saving only
>>> 3 or 5 registers isn't possible yet. We have no opcodes for that.
>
>> save Pn
>> save Pm
>
> Well
Piers Cawley wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Out of interest, why do we have distinct register and user stacks?
User stack entries are typed and you save and restore one item per
operation. The register backing stores first took 32 registers of one
kind (now 16 or 32). To get
ybe I'm just being a numpty but should this not be
Creating a new class with attributes
Adding the attributes a and b to the new class Foo:
newclass $P0, "Foo"
addattribute $P0, "a" # "Foo::a" This is offset 0
addattribute $P0, "b" # "Foo
At 4:34 PM +0100 3/26/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote:
Or: after the 1st delegate lookup create a JITed stub
Which is swell, except for that pesky can't-guarantee-a-JIT thing... :)
I've running that now for the C
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 6:46 PM +0100 3/17/04, Leopold Toetsch wrote:
>>Or: after the 1st delegate lookup create a JITed stub
> Which is swell, except for that pesky can't-guarantee-a-JIT thing... :)
I've running that now for the C<__init> call. In the absence of
C<__init> t
1 - 100 of 420 matches
Mail list logo
