chromatic wrote:
Suppose I extend a built-in PMC through PIR code. If certain vtable methods
can share the same implementation, it would be nice to be able to re-use a
single implementation through some mechanism other than copy and paste.
Yeah, through composition or inheritance. Manually
On Thursday 03 May 2007 21:53:33 [EMAIL PROTECTED] wrote:
> Log:
> [pdd]: Standardizing objects PDD on 'vtable function' rather than 'vtable
> method'.
I don't understand this. They're "vtable methods" everywhere else. They all
take at least one parameter--the invocant--so they're methods in ju
Klaas-Jan Stol wrote:
Hi,
reading pdd15, I don't get this:
To override a vtable function, either add the :vtable to the declaration of
the method, or pass a named, slurpy parameter "vtable" into the
add_methodmethod on a class or role.
How would you write code for the 2nd way? If passing a par
Author: allison
Date: Thu May 3 22:55:01 2007
New Revision: 18419
Modified:
trunk/docs/pdds/pdd15_objects.pod
Log:
[pdd]: A few clarifications for objects PDD from Klass-Jan Stol.
Modified: trunk/docs/pdds/pdd15_objects.pod
===
On Thursday 03 May 2007 22:17:32 Allison Randal wrote:
> Matt Diephouse wrote:
> > As a feature, this could do a world of hurt. I'm not sure how much
> > sense it makes to copy a method from one class to another...
> This is the key point. Direct import/export is really for libraries.
> Classes
hi,
IIRC (currently no pc around to check, but I realized this issue when
reading on objects pdd), calling a method in PIR can be done as follows:
$P0.'someMethod'()
but also:
.local string meth /* or maybe a pmc ?*/
meth = 'someMethod'
$P0.meth()
However, this looks like as if the object in
Hi,
reading pdd15, I don't get this:
To override a vtable function, either add the :vtable to the declaration of
the method, or pass a named, slurpy parameter "vtable" into the
add_methodmethod on a class or role.
How would you write code for the 2nd way? If passing a parameter, shouldn't
it sa
Matt Diephouse wrote:
Are you sure? It seems like this bug/feature will go away when pdd15
is implemented. At that point, setting a Sub in a namespace will no
longer modify the methods or vtable functions of a class.
The feature is "when you import a sub from another namespace, it has all
the
Allison Randal <[EMAIL PROTECTED]> wrote:
Klaas-Jan Stol wrote:
> In a way, when copying it, it does make sense all attributes are copied as
> well (it seems "clean")
Indeed. Let's categorize this bug as a feature.
Are you sure? It seems like this bug/feature will go away when pdd15
is imp
Author: allison
Date: Thu May 3 21:53:32 2007
New Revision: 18418
Modified:
trunk/docs/pdds/pdd15_objects.pod
Log:
[pdd]: Standardizing objects PDD on 'vtable function' rather than 'vtable
method'.
Modified: trunk/docs/pdds/pdd15_objects.pod
Allison Randal <[EMAIL PROTECTED]> wrote:
For classes, the 'add_method' method takes a named parameter to say
whether it's a vtable function. And, vtable functions aren't stored in
the namespace at all anymore, but in a data structure inside the class,
so you wouldn't have 'root' and 'hll' varian
Klaas-Jan Stol wrote:
In a way, when copying it, it does make sense all attributes are copied as
well (it seems "clean")
Indeed. Let's categorize this bug as a feature.
Allison
chromatic wrote:
Allison, what do you think about holding onto this one until the revised IO
PDD gets finished?
The revised IO PDD is finished, just not implemented. Go ahead and check
the mmap io layer in, we'll port it to the new system when we implement it.
Also convert the test PIR fil
Matt Diephouse (via RT) wrote:
There's no real way to set a vtable function at runtime. It's
possible to use the PIR compiler to eval a new function, but there's
no way to take an existing sub and add it as a vtable function[1].
Before :vtable, this operation simply meant adding the sub to t
Andy Dougherty wrote:
On Tue, 1 May 2007, James Keenan via RT wrote:
On Tue Apr 10 01:45:31 2007, [EMAIL PROTECTED] wrote:
Configure should act as though writing --foo=no is false instead of
true. Tonight I tried using --execcapable=no to get around a compile
failure, but then realized that
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', if they have the :vtable pragma set, like the old
object system. I kept this capability for compatibili
On 5/2/07, via RT Matt Diephouse <[EMAIL PROTECTED] > wrote:
There's no real way to set a vtable function at runtime. It's
possible to use the PIR compiler to eval a new function, but there's
no way to take an existing sub and add it as a vtable function[1].
Before :vtable, this operation simpl
Closing ticket.
On Fri Apr 27 19:03:28 2007, jkeen at verizon.net wrote:
> Feedback requested on patch attached.
>
Having heard no objections, patch was applied tonight in r18417.
kid51
# New Ticket Created by James Keenan
# Please include the string: [perl #42872]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42872 >
1. Refactored Parrot::BuildUtils::parrot_version() to eliminate
unreachable code.
2.
On Thursday 03 May 2007 17:54:42 Will Coleda wrote:
> In happier news, it makes partcl's 'make test' run in 75% of the time
> it did earlier in the week, so I'd rather find the one issue here
> rather than revert the patch.
I'll debug the segfault and see if that reveals anything interesting.
Th
On May 3, 2007, at 8:35 PM, chromatic wrote:
On Thursday 03 May 2007 16:22:13 [EMAIL PROTECTED] wrote:
Sort the vtable functions list alphabetically and use a binary
search when
looking functions up by name. This gets us part way to some of the
speedup
we should see from the pdd15 implemen
On Thursday 03 May 2007 16:22:13 [EMAIL PROTECTED] wrote:
> Sort the vtable functions list alphabetically and use a binary search when
> looking functions up by name. This gets us part way to some of the speedup
> we should see from the pdd15 implementation.
>
> Time to run ../../parrot tcl.pbc t/c
Am Mittwoch, 2. Mai 2007 21:25 schrieb Yehoshua Sapir:
> I'm working on ticket #38929
> ( http://rt.perl.org/rt3//Public/Bug/Display.html?id=38929 )
>
> As far as I can tell, there's a JIT_EMIT #define that the .c files set
> before they #include jit_emit.h, and what it does is switch out parts of
In a way, when copying it, it does make sense all attributes are copied as
well (it seems "clean")
kjs
On 5/3/07, via RT Matt Diephouse <[EMAIL PROTECTED]> wrote:
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #42864]
# in the subject line of all future corres
On Tue May 01 17:23:07 2007, chromatic at wgz.org wrote:
> > The patch makes PIO_unix_seek to update io->fsize value if lseek
> exceeds
> > the file boundaries.
>
> This seems sensible to me, but we don't use fsize anywhere within in
> the
> system, so I'm not sure how or where to test it. I'd l
On May 2, 2007, at 11:37 PM, chromatic via RT wrote:
Everything worked fine for me with Svk, barring some fuzz when
updating
MANIFEST.SKIP and the lack of Svn properties set in the diff. Nice
work.
This was the first time that I used tools/dev/mk_manifest_and_skip.pl
to (re-)genera
=HI!
To avoid any uncertainty: the subject is a parody for similar
discussion on perl6-internals@ about Parrot.
=FOREWORD
What I want to say is that after N years of developing Perl 6 we do
not have a practical (P in Perl stands for Practical) tool which can
work in real life.
Even worse: today
28 matches
Mail list logo