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
s) in pmc_new
at line 70 in file "pmc.c"
70 PMC *const classobj =
interp->vtables[base_type]->pmc_class;
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] pmc_new(interp = 0x485318, base_type = 79), line 70 in "pmc.c"
[2] Parrot_cx_
;PjsObject' ]
.sub get_string :vtable :method
$P0 = self['toString']
# ...
.end
But then PROTO(x) does not work anymore, because x is most of the time
not a raw PjsObjectBase, but it's PjsObject which wraps my
PjsObjectBase. I solved that problem with some ugly hacks,
On Thu, Apr 06, 2006 at 01:46:09PM -0700, Bernhard Schmalhofer via RT wrote:
> As PGE nowadays happily works with Parrot standard PMCs, I assume that
> this old issue has been taken care of.
Actually, this particular todo item didn't have anything to do with
PGE. Leo and I were conversing about
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> This patch implements (some) jitted vtables for the sun4/sparc platform.
Thanks, applied.
leo
# New Ticket Created by Stephane Peiry
# Please include the string: [perl #32535]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32535 >
This patch implements (some) jitted vtables for the sun4/sparc platform.
That
ot;gr_cap" seems to take integers only. If yes it should be
eventually a ResizableIntegerArray. But this needs 2 TODO items (which
I'd just drop off to the list): implement missing vtables like pop and
use the allocation style from ResizablePMCArray, i.e. the size in
PMC_int_val2(ar). T
On Nov 2, 2004, at 12:41 AM, Leopold Toetsch wrote:
When we have objects with finalizers, we have to run the finalizers in
order from most derived down the parent chain.
Maybe, but not necessarily. The case of loops means that we cannot
always do this cleanly (no "top" of the chain), and the fact
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 9:03 PM +0100 11/1/04, Leopold Toetsch wrote:
>>We need more vtables.
>>
>>* INTVAL hash()
>>
>>To properly support Python, we need:
>>- a hash PMC that isn't restricted to STRING* keys
> Works for m
Leopold Toetsch wrote:
We need more vtables.
* INTVAL hash()
To properly support Python, we need:
- a hash PMC that isn't restricted to STRING* keys - low level hash code
has AFAIK already all the necessary stuff, or mostly. I don't know, how
much Python specific it really is, b
At 9:03 PM +0100 11/1/04, Leopold Toetsch wrote:
We need more vtables.
* INTVAL hash()
To properly support Python, we need:
- a hash PMC that isn't restricted to STRING* keys - low level hash
code has AFAIK already all the necessary stuff, or mostly. I don't
know, how much Python s
We need more vtables.
* INTVAL hash()
To properly support Python, we need:
- a hash PMC that isn't restricted to STRING* keys - low level hash code
has AFAIK already all the necessary stuff, or mostly. I don't know, how
much Python specific it really is, but Perl5's "hashing
# New Ticket Created by Will Coleda
# Please include the string: [perl #31182]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31182 >
PythonInteger/String/Object?
(from the TODO file)
# New Ticket Created by Will Coleda
# Please include the string: [perl #31135]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31135 >
Fill in vtables for non-ASCII encodings: UTF-8, UTF-16, UTF-32, etc.
(From
d some of these
vtables. Don't know yet, which.
leo
On Thu, 24 Jun 2004, Leopold Toetsch wrote:
> There are currently 19 bignum vtable slots, which take a BIGNUM* value
> argument of some kind. These are IMHO useless. We don't have a Parrot
> basic type like BIGNUM.
>
> A BIGNUM (BigInteger, BigNumber) will just be a PMC, AFAIK.
>
> So I think thes
There are currently 19 bignum vtable slots, which take a BIGNUM* value
argument of some kind. These are IMHO useless. We don't have a Parrot
basic type like BIGNUM.
A BIGNUM (BigInteger, BigNumber) will just be a PMC, AFAIK.
So I think these entries should just get deleted.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... We rework the current pmc
> processor to take the entries that are getting tossed and
> automatically add them to the MMD tables on PMC load instead.
I've now implemented MMD for PerlInt's bitwise_xor as a test case. Syntax
looks like this:
void b
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... And... we
> move *all* the operator functions out of the vtable and into the MMD
> system. All of it.
This *all* includes vtable functions like add_int() or add_float() too,
I presume. For these we have left argument dispatch only. But what is
the rig
On Thu, 2004-04-29 at 03:33, Leopold Toetsch wrote:
> As Dan already said there is no performance hit (at least if the MMD
> tables don't blow the caches).
Good stuff! One thing leaps to mind when you mention the cache though...
keep in mind that blowing L2 cache (which we might be in no danger o
At 11:42 AM -0400 4/29/04, Dan Sugalski wrote:
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Another long running discussion: do we need duplicate mmd tables.
Here is a proof of concept to avoid it:
Oh, right, and... this is really, really evil. Which is why I just
put it in. :)
And just to add
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Another long running discussion: do we need duplicate mmd tables.
Here is a proof of concept to avoid it:
Oh, right, and... this is really, really evil. Which is why I just
put it in. :)
--
Dan
--
At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, we've a long-running discussion between Leo and I about the
keyed variants for all the binary vtable entries.
Another long running discussion: do we need duplicate mmd tables.
Dunno. Don't care, really
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, we've a long-running discussion between Leo and I about the
> keyed variants for all the binary vtable entries.
Another long running discussion: do we need duplicate mmd tables.
Here is a proof of concept to avoid it:
#v+
--- parrot/src/mmd.cTh
re is no performance hit (at least if the MMD
tables don't blow the caches).
Doing 5 M divide vtables[1] on Athon 800, -O3 build:
$ parrot -j mmdp.imc# 10 / 2
PerlInt 1.048340
Integer 1.097163# left arg MMD, right is VTABLE_get_integer [2]
Integer 1.039819# left+right
At 8:21 PM +0200 4/28/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
We toss the keyed variants for everything but get and set. And... we
move *all* the operator functions out of the vtable and into the MMD
system. All of it. Math, logical ops, bit ops... the works. All
tha
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We toss the keyed variants for everything but get and set. And... we
> move *all* the operator functions out of the vtable and into the MMD
> system. All of it. Math, logical ops, bit ops... the works. All
> that's left are the gets, sets, and meta-informa
Ok, nuff said. I think there are slightly too many definitions that
we're not agreeing on (though, I suspect if we ironed those out, we'd be
in violent agreement).
As for INT/PMC thing I'm pretty sure all of my concerns come down
to: compilers can really screw each other over, but then we knew
Oh, yeah, another thing--if we do kill all the non load/store vtable
operations, then all the hyper ops just move to a separate set of MMD
dispatch tables.
--
Dan
--"it's like this"---
Dan Sugalski
At 12:51 PM -0400 4/28/04, Aaron Sherman wrote:
On Wed, 2004-04-28 at 12:33, Dan Sugalski wrote:
At 12:21 PM -0400 4/28/04, Aaron Sherman wrote:
>Since we're specifically talking about Perl here (and probably not Perl
>5, since its overloading model is baroque and probably has to be managed
>b
On Wed, 2004-04-28 at 12:33, Dan Sugalski wrote:
> At 12:21 PM -0400 4/28/04, Aaron Sherman wrote:
> >Since we're specifically talking about Perl here (and probably not Perl
> >5, since its overloading model is baroque and probably has to be managed
> >by the compiler, not Parrot)
>
> Actually pe
At 12:21 PM -0400 4/28/04, Aaron Sherman wrote:
On Wed, 2004-04-28 at 12:06, Dan Sugalski wrote:
I'm not sure of the hit--an MMD version of the perl base scalar PMCs
is faster than the non-mmd version in some tests. I fully expect that
can't hold, though. And no, there's no way around it--if we
On Wed, 2004-04-28 at 12:06, Dan Sugalski wrote:
> I'm not sure of the hit--an MMD version of the perl base scalar PMCs
> is faster than the non-mmd version in some tests. I fully expect that
> can't hold, though. And no, there's no way around it--if we do this
> everyone pays. (OTOH, all perl
At 11:59 AM -0400 4/28/04, Aaron Sherman wrote:
On Wed, 2004-04-28 at 11:33, Dan Sugalski wrote:
We toss the keyed variants for everything but get and set. And... we
move *all* the operator functions out of the vtable and into the MMD
system.
[...]
Comments?
Only one question. What's the perfo
On Wed, 2004-04-28 at 11:33, Dan Sugalski wrote:
> We toss the keyed variants for everything but get and set. And... we
> move *all* the operator functions out of the vtable and into the MMD
> system.
[...]
> Comments?
Only one question. What's the performance hit likely to be and is there
any
Okay, we've a long-running discussion between Leo and I about the
keyed variants for all the binary vtable entries.
On the one hand, there's a hell of a lot of 'em, of potentially
limited utility.
On the other, without them it means creating temporary PMCs if we do
something like:
foo[1
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Shouldn't {g,s}etattribute opcodes call vtable methods of the object?
Sorry - check in messages reads:
attribute vtables
(Shouldn't ask silly questions on p6i but first read pdd15 again)
* implement speced vtables
* change ops to
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 4:51 PM +0100 3/4/04, Leopold Toetsch wrote:
>>
>>Rather not. But if we have to allocate a separate vtable, we should
>>set a flag in the vtable->flags, mark the PMC as special, so that
>>destroy can free the vtabl
At 4:51 PM +0100 3/4/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
It'd be simple enough to do--prepend a PObj front to the vtables
and allocate the vtables themselves out of a separate managed
arena, and do a bit of custom mark noting. This'd make collecting
up unused vtables e
Dan Sugalski wrote:
It'd be simple enough to do--prepend a PObj front to the vtables and
allocate the vtables themselves out of a separate managed arena, and do
a bit of custom mark noting. This'd make collecting up unused vtables
easy enough. The downside to this is it means we add
It'd be simple enough to do--prepend a PObj front to the vtables and
allocate the vtables themselves out of a separate managed arena, and
do a bit of custom mark noting. This'd make collecting up unused
vtables easy enough. The downside to this is it means we add in a
*lot* of ext
At 10:54 AM -0500 1/23/04, Benjamin Kojm Stuhl wrote:
Well, that was why I had my suggested sample pseudocode restore the
previous vtable pointer before calling down to the next function
(and put itself back when that's done).
That has reentrancy issues, unfortunately. Potentially threading and
ly access the guts of the
> >>PMC, but can instead rely on the other vtable functions to get the
> >>information that they need to operate.
> >>
> >>Not that this necessarily mandates passing in the vtable pointer to
> >>the functions, but the uses are
functions, but the uses aren't exactly marginal.
Going back to the idea of generating these vtables on the fly (and
caching them): each instance of a vtable gets a void* closure in the
vtable itself,
so at a certain expense in extra vtables, one could hang a structure off
of that that includ
assing in the vtable pointer to the
functions, but the uses aren't exactly marginal.
Going back to the idea of generating these vtables on the fly (and caching
them): each instance of a vtable gets a void* closure in the vtable itself,
so at a certain expense in extra vtables, one could hang
At 8:37 AM -0500 1/19/04, Benjamin K. Stuhl wrote:
Luke Palmer wrote:
Benjamin K. Stuhl writes:
Other than the special case of :readonly, can you give me an example
of when you'd need to, rather than simply writing a PMC class that
inherits from some base? I'm having trouble thinking of an exampl
Luke Palmer wrote:
Benjamin K. Stuhl writes:
Other than the special case of :readonly, can you give me an example
of when you'd need to, rather than simply writing a PMC class that
inherits from some base? I'm having trouble thinking of an example of
when you'd want to be able to do that... After
Benjamin K. Stuhl writes:
> Other than the special case of :readonly, can you give me an example
> of when you'd need to, rather than simply writing a PMC class that
> inherits from some base? I'm having trouble thinking of an example of
> when you'd want to be able to do that... After all, since o
Thusly did Dan Sugalski inscribe:
At 3:33 PM -0500 1/16/04, Benjamin K. Stuhl wrote:
Dan Sugalski wrote:
I was going to go on about a few ways to do this, but after I did I
realized that only one option is viable. So, let's try this on for size:
Vtables are chained. That means each vtabl
At 3:33 PM -0500 1/16/04, Benjamin K. Stuhl wrote:
Dan Sugalski wrote:
I was going to go on about a few ways to do this, but after I did I
realized that only one option is viable. So, let's try this on for
size:
Vtables are chained. That means each vtable has a link to the next
in the
Dan Sugalski wrote:
I was going to go on about a few ways to do this, but after I did I
realized that only one option is viable. So, let's try this on for size:
Vtables are chained. That means each vtable has a link to the next in
the chain. It *also* means that each call into a vtable fun
At 11:53 AM +0100 1/16/04, Leopold Toetsch wrote:
PMCs use Vtables for almost all their functionality *and* for stuff
that in Perl5 term is "magic" (or they should AFAIK).
E.g. setting the "_ro" property of a PMC (that supports it[1]) swaps
in the Const$PMC vtable, where all
PMCs use Vtables for almost all their functionality *and* for stuff that
in Perl5 term is "magic" (or they should AFAIK).
E.g. setting the "_ro" property of a PMC (that supports it[1]) swaps in
the Const$PMC vtable, where all vtable methods that would change the PMC
thr
I've remove the rather hackish set_integer_native() and get_integer()
methods for Sub-like PMCs.
The old sequence:
set_addr I0, _label
set P0, I0
is now just
set_addr P0, _label
This might break some languages using such constructs.
Also obtaining the address of a Sub-like PMC is changed
"Brent Dax" <[EMAIL PROTECTED]> wrote:
> # > The result would mean that something like:
> # > pmc->vtable->add
> #
> # > Might become:
> # > pmc->vtable->math->add
> #
> # Seems too expensive to me for the normal math stuff.
>
> Perhaps, although one dereference doesn't seem to painful to me.
Is t
On Tue, 23 Sep 2003, Brent Dax wrote:
> Leopold Toetsch:
> # That's what happening anyway. All unimplemented stuff has a default
> hook
> # throwing an exception.
>
> The indirection would allow for a default set. It's the difference
> between eight default pointers per vtable (to default sectio
nal
trig_vtable.
I didn't catch this bit before.
# > Vtable.tbl already divides vtables into sections. I suggest we take
# > this a step further and express these sections in the vtables
itself.
# > Sections that a particular object didn't need would be loaded with a
# > def
On Mon, 22 Sep 2003, Gregor N. Purdy wrote:
> On a related note, I wonder how all this fits in with
> methods and multimethods?
One-arg vtable methods don't have to do multimethod stuff, since you're
calling the vtable method on the argument, so it can do the right thing
without checking.
Two
On Mon, Sep 22, 2003 at 04:08:24PM -0600, Luke Palmer wrote:
> And let's not forget our handy trig identities. We definitely don't
> need all those vtable. Technically, all we need are sine and arccosine.
I believe that atan2() is more useful than arccosine, as it returns
information about whic
ointers, and Scratchpads forced to implement acosh,
they won't.
> Vtable.tbl already divides vtables into sections. I suggest we take
> this a step further and express these sections in the vtables itself.
> Sections that a particular object didn't need would be loaded with a
re very infrequently used, and can
> be implemented in terms of exp, which in turn can be implemented in
> terms of pow, but shouldn't.
>
> > Basically, where do you draw the line between a vtable method and a
> > find_method method? Unless the line is "methods that e
vtable method and a
> find_method method? Unless the line is "methods that everything should
> support", I'd say it's been crossed when you add acosh to the vtable.
> And if that *is* where the line is, don't be surprised when vtables
> cross the megabyte line
hod?
Basically, where do you draw the line between a vtable method and a
find_method method? Unless the line is "methods that everything should
support", I'd say it's been crossed when you add acosh to the vtable.
And if that *is* where the line is, don't be surprised wh
Okay, since it seems reasonable to hang the trig functions off of PMCs,
we'd best get a list of the functions we want. I can think of:
pow
logarithm
square root (yes, I know, it's for speed)
Normal and hyperbolic versions of:
sine
cosine
tangent
cotangent
arcsine
arccosine
arc
On Mon, Aug 25, 2003 at 08:13:48PM +0200, Leopold Toetsch wrote:
> This patch generates a second vtable (and class enum) for a PMC, when
> the pmc class defintions contains C.
>
> To make that actually usable, I'm thinking of:
> - the vtable gets a flag for const classes
> - pmc_new uses the cons
This patch generates a second vtable (and class enum) for a PMC, when
the pmc class defintions contains C.
To make that actually usable, I'm thinking of:
- the vtable gets a flag for const classes
- pmc_new uses the constant PMC pool, when that flag is set
- but the vtable is first the writeable
Sean O'Rourke <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> A keyed "add" vtable doesn't help to provide more semantics. The set vs
>> assign thread applies here too. On the contrary: to provide all
>> semantics you would need "add_set_p_k_p_k_p_k" and "add_assign_p_k
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> And semantic differences--don't forget those.
>
> A keyed "add" vtable doesn't help to provide more semantics. The set vs
> assign thread applies here too. On the contrary: to provide all
> semantics you would
keys (even NULL keys?) for each argument.
Constructing these keys (albeit at load time) isn't free. Where we now
have an optimized keyed_int opocde, the 3-key variant needs a full PMC
key, just holding an immediate constant.
To handle all permutations of keyed/non-keyed, each of these vtables has
to che
At 6:06 PM +0200 8/16/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 11:58 PM +0200 8/15/03, Leopold Toetsch wrote:
What is that? I'd tossed all (hopefully) of the math, boolean, and
logical keyed vtables,
Ah yes - docu needs updating, but Dan didn't put
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:58 PM +0200 8/15/03, Leopold Toetsch wrote:
>>What is that? I'd tossed all (hopefully) of the math, boolean, and
>>logical keyed vtables,
>>Ah yes - docu needs updating, but Dan didn't put his "yes agree
At 11:58 PM +0200 8/15/03, Leopold Toetsch wrote:
Togos <[EMAIL PROTECTED]> wrote:
... a bit strange that there is a keyed version
of 'add', anyway.
What is that? I'd tossed all (hopefully) of the math, boolean, and
logical keyed vtables, for which we never want to have op
Togos <[EMAIL PROTECTED]> wrote:
> ... a bit strange that there is a keyed version
> of 'add', anyway.
What is that? I'd tossed all (hopefully) of the math, boolean, and
logical keyed vtables, for which we never want to have opcodes. Did I
miss one?
Ah yes - docu nee
> I have checked in some functionality for string bitwise ops.
> - vtable
> - B, B opcodes
> - string_bitwise_{or,and} functions in string.c
> - minimal tests
>
> Missing:
> - B ops
> - support for perl scalar PMCs
>
> I'd be glad if someone wants to continue that stuff.
The patch below implements
> At 1:35 AM +0300 8/8/03, Vladimir Lipskiy wrote:
> > > What in $DEITY's name is *that*? It sure isn't a context diff.
> >> A context diff is what you get from "diff -u" or "diff -c".
YAY! Thanks Chip for you caustic remark -- it made me to
know about how to get a context diff with WinCVS.
Da
> According to Vladimir Lipskiy:
> > The patch below implements the missing XORS ops.
>
> Context diffs preferred, I think.
Sure.
Index: string.c
===
RCS file: /cvs/public/parrot/string.c,v
retrieving revision 1.141
diff -r1.141 stri
> What in $DEITY's name is *that*? It sure isn't a context diff.
> A context diff is what you get from "diff -u" or "diff -c".
What you saw was the context diff I provided myself (~:
I doubt it's possible to provide a context diff WinCVS.
Though, I could be mistaken.
Recently I found some logic redundancy in string_bitwise_or
and this seems like I quite forgot to correct that in my just now
sent patch. Sorry.
Index: string.c
===
RCS file: /cvs/public/parrot/string.c,v
retrieving revision 1.141
di
According to Vladimir Lipskiy:
> STRING *res;
> size_t len;
>
> < len = s1 ? s1->bufused : 0;
> < if (s2 && s2->bufused < len)
> < len = s2->bufused;
> <
> < if (dest && *dest)
> ---
> >if (dest && *dest)
> res = *dest;
> else if (!s1 || !s2)
> r
At 1:35 AM +0300 8/8/03, Vladimir Lipskiy wrote:
> What in $DEITY's name is *that*? It sure isn't a context diff.
A context diff is what you get from "diff -u" or "diff -c".
What you saw was the context diff I provided myself (~:
I doubt it's possible to provide a context diff WinCVS.
Though, I
Vladimir Lipskiy <[EMAIL PROTECTED]> wrote:
> The third attempt, here it is:
Applied finally, thanks for the patch.
Some minor notes: please send patches as attachments (some lines got
wrapped). And as already mentioned please try to figure out, how to get a
unified diff: "cvs diff -u ...".
Ther
I have checked in some functionality for string bitwise ops.
- vtable
- B, B opcodes
- string_bitwise_{or,and} functions in string.c
- minimal tests
Missing:
- B ops
- support for perl scalar PMCs
I'd be glad if someone wants to continue that stuff.
Have fun,
leo
Simon Glover <[EMAIL PROTECTED]> wrote:
> 1. What is supposed to do?
Probably setup a new PMC *and* attach the passed properties.
> 2. What, precisely, do and do?
C does kind of a subroutine call on the PMC. The functionality
depends on the class implementing the method. C is AFAIK
unuse
1. What is supposed to do?
(It's currently in vtable.tbl, but isn't documented in PDD02.)
2. What, precisely, do and do?
(These are documented, but the prototypes given in PDD02 don't
agree with the ones used the the vtables).
Specifically, given the protot
- the {g,s}et__keyed_int vtables take a plain INTVAL now, no more
a pointer to one
- the src_key argument of pmc_keyed functions is gone
- all arithmetic, logical and boolean multi keyed vtables are gone
- as well as set P[k], P[k]
All these were unused. Tests still pass.
This did reduce the
During moving and looking at the IO tests, I was a little confused about
hacks_3 (now io_9) which wrote to stdout (now to the file).
Anyway I have added a check in io.c, if a file is opened for writing. Is
that ok, or should the lower layers just do the Rigth Thing?.
leo
Dan Sugalski wrote:
> *) Spec the vtable changes
Starting from my proposal ...
Subject: [RFC] 2. Proposal for _keyed opcodes
I have some more implementation details, WRT _keyed.
- An aggregate should provide these vtable methods:
* entry_type ... get info about the aggregates storage
Okay, folks, I'm back from travel, at least for a little while. My
short term goals are:
*) Finish up the calling convention changes
*) Spec the PMC changes
*) Spec the vtable changes
*) Get exceptions fully defined and a preliminary implementation
The variable/vtable stuff should be done in th
On Tue, Jul 16, 2002 at 03:35:30PM -0500, David M. Lloyd wrote:
> On Mon, 15 Jul 2002, John Porter wrote:
>
> > > There is really no inheritance of any kind going on,
> > > it just sticks pointers to the default functions into the vtable
> > > structure method entries for undefined methods.
> >
>
David M. Lloyd wrote:
> No, the point is that all this talk about type-space mm dispatch
> depends on there *being* type space. Since there is currently
> no inheritance to speak of then there really is no typespace so
> all of this talk is moot,
I agree; but you did express a concern earlier t
On Tue, 16 Jul 2002, John Porter wrote:
>
> David M. Lloyd wrote:
> > John Porter wrote:
> > > The MM dispatch problem is pretty much solidly in
> > > the realm of pmc inheritance,
> >
> > There _is_ no pmc inheritance right now.
> > There's just a set of default functions.
>
> Call it what you w
John Porter wrote:
> The point is that this type schema is at the parrot level,
> and is not the concern of a user-level language like perl
Of course this is not really true; perl scalars, arrays, and
hashes (etc.?) are implemented as PMCs under the hood, so
in that sense they are related by wha
David M. Lloyd wrote:
> John Porter wrote:
> > The MM dispatch problem is pretty much solidly in
> > the realm of pmc inheritance,
>
> There _is_ no pmc inheritance right now.
> There's just a set of default functions.
Call it what you want.
The point is that this type schema is at the parrot
On Mon, 15 Jul 2002, John Porter wrote:
> "David M. Lloyd" wrote:
> > Do we really want *two* inheritance trees per object
> > in Perl 6? One language-level and one PMC-level?
>
> Well, parrot != perl6, so I don't see a problem.
Ugh.
> The MM dispatch problem is pretty much solidly in
> the re
"David M. Lloyd" wrote:
> Do we really want *two* inheritance trees per object
> in Perl 6? One language-level and one PMC-level?
Well, parrot != perl6, so I don't see a problem.
The MM dispatch problem is pretty much solidly in
the realm of pmc inheritance, and that's something
we have control
entors some typing. There is really no inheritance of any kind
going on, it just sticks pointers to the default functions into the vtable
structure method entries for undefined methods.
I'm inclined to say that vtables shouldn't inherit at all, but I may be
missing something important. I usually am.
- D
<[EMAIL PROTECTED]>
On Thu, Jul 11, 2002 at 08:20:21PM -0700, John Porter wrote:
>
> Dave Mitchell wrote:
> > IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
> > are strongly equivalent, ie they give rise to the *same* ordering.
> > (In the limit as n -> Inf, the metric is max(x,y).)
>
> I'm sorry, YD
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 11, 2002 at 01:18:51PM -0700, John Porter wrote:
> > Nicholas Clark wrote:
> > > I was thinking that the metric (x*x + y*y) would be fast to
> > > calculate, as that's all we need for ordering.
> >
> > Point is, it's rather *more* than w
Dave Mitchell wrote:
> IIRC, all metrics of the form (x^n + y^n)^(1/n), n=1,2,...Inf
> are strongly equivalent, ie they give rise to the *same* ordering.
> (In the limit as n -> Inf, the metric is max(x,y).)
I'm sorry, YDNRC.
Consider the distance from the origin to the points (0,6) and (3,4).
On Thu, Jul 11, 2002 at 01:18:51PM -0700, John Porter wrote:
> Nicholas Clark wrote:
> > I was thinking that the metric (x*x + y*y) would be fast to
> > calculate, as that's all we need for ordering.
>
> Point is, it's rather *more* than we need for ordering.
> x + y will suffice.
IIRC, all metr
1 - 100 of 256 matches
Mail list logo
