Christoph Otto wrote:
So you're saying that multiple inheritance in its current state should
be allowed to continue, and that there's only a problem with ATTRs if a
PMC tries to extend two PMCs, both of which have their own ATTRs?
I'm saying that multiple inheritance between two C-level
Allison Randal via RT wrote:
Christoph Otto wrote:
The PMC UnionVal deprecation can't be completed until Parrot has
improved ATTR
reuse between extending PMCs. I'm rewriting code to minimize dependence on
the PMC_x_val macros, but I can't eliminate them completely without better
inheritance
Christoph Otto via RT wrote:
Allison Randal via RT wrote:
snip
Parent and child had to have the same struct in the original (because
every PMC defined the same union val struct), and so still have to have
the same struct in the new version. It is progress: at least the struct
members will
Christoph Otto schrieb:
Christoph Otto via RT wrote:
The attached patch implements this behavior and fixes two core PMCs
that had been doing the inheritance manually. All tests in make test
pass. I didn't bother testing any HLLs as this is more of a here's
what I'm thinking patch, but it's
Bernhard Schmalhofer via RT wrote:
Christoph Otto schrieb:
Christoph Otto via RT wrote:
The attached patch implements this behavior and fixes two core PMCs
that had been doing the inheritance manually. All tests in make test
pass. I didn't bother testing any HLLs as this is more of a
Allison Randal via RT wrote:
Christoph Otto wrote:
Allison Randal wrote:
(Actually, at the moment you're required to declare
all parent attributes in the ATTR list before the child attributes, so
inherited attributes *are* child attributes.)
When I say attributes, I mean the things that are
On Wednesday 21 January 2009 17:23:42 Christoph Otto wrote:
If there's a cheaper way to implement this and still support C-level PMC
ATTR multiple inheritance, I'll be thrilled to implement it.
We've never really supported C-level PMC multiple inheritance. As best I can
figure, it was a
Christoph Otto wrote:
The PMC UnionVal deprecation can't be completed until Parrot has
improved ATTR
reuse between extending PMCs. I'm rewriting code to minimize dependence on
the PMC_x_val macros, but I can't eliminate them completely without better
inheritance support. I'd like to
Allison Randal wrote:
Christoph Otto via RT wrote:
I'm running into a snag trying to implement this. It turns out that
many lines which use the PMC_x_val macros use them on different types of
PMCs, especially parents and children (e.g. FixedPMCArray and
ResizablePMCArray). There are also some
Christoph Otto wrote:
Allison Randal wrote:
(Actually, at the moment you're required to declare
all parent attributes in the ATTR list before the child attributes, so
inherited attributes *are* child attributes.)
When I say attributes, I mean the things that are declared in .pmc
files right
Christoph Otto via RT wrote:
I'm running into a snag trying to implement this. It turns out that
many lines which use the PMC_x_val macros use them on different types of
PMCs, especially parents and children (e.g. FixedPMCArray and
ResizablePMCArray). There are also some instances where the
Christoph Otto via RT wrote:
I'm running into a snag trying to implement this. It turns out that
many lines which use the PMC_x_val macros use them on different types of
PMCs, especially parents and children (e.g. FixedPMCArray and
ResizablePMCArray). There are also some instances where the
On Tue, Jan 13, 2009 at 10:17 PM, Will Coleda via RT
parrotbug-follo...@parrotcode.org wrote:
On Wed Nov 05 13:04:11 2008, chroma...@wgz.org wrote:
On Wednesday 22 October 2008 09:28:38 Bernhard Schmalhofer via RT wrote:
Does this mean that this ticket can be closed and the deprecation item
chromatic wrote:
On Wednesday 22 October 2008 09:28:38 Bernhard Schmalhofer via RT wrote:
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
Not until we apply this patch and all tests still pass.
Looks like you've missed few lines from
chromatic wrote:
On Wednesday 22 October 2008 09:28:38 Bernhard Schmalhofer via RT wrote:
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
Not until we apply this patch and all tests still pass.
Looks like you missed few lines from this
On Thursday 06 November 2008 12:52:38 Vasily Chekalkin wrote:
Not until we apply this patch and all tests still pass.
Looks like you missed few lines from this patch. Few thousand lines :)
This patch is necessary, but not sufficient!
Anyone who does want to help though should apply this
On Wednesday 22 October 2008 09:28:38 Bernhard Schmalhofer via RT wrote:
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be removed?
Not until we apply this patch and all tests still pass.
-- c
=== include/parrot/pobj.h
On Mo. 08. Sep. 2008, 13:59:08, julianalbo wrote:
Done in r30914: changed name to Parrot_type_attributes, fixed
codingstd, changed also pmc in languages lua and perl6, and updated
pdd17_pmc.pod
Does this mean that this ticket can be closed and the deprecation item
in DEPRECATED.pod be
On Wed, Oct 22, 2008 at 6:28 PM, Bernhard Schmalhofer via RT
[EMAIL PROTECTED] wrote:
Done in r30914: changed name to Parrot_type_attributes, fixed
codingstd, changed also pmc in languages lua and perl6, and updated
pdd17_pmc.pod
Does this mean that this ticket can be closed and the
NotFound wrote:
Given that the name will be mainly used via macros, a long and
meaningful name can be used, such as Parrot_PMCdata_PMCname
That's a good refinement, we can make the change after the next release.
The attached patch does it. There is a lot of changes, I suspect many
of them are
Reading through the updated code, it seems that (using Task as an
example):
Parrot_PMCdata_Task
is not much clearer than the original Parrot_Task was. Let's go with:
Parrot_Task_attributes
A fast ack'ing of: Parrot_[_a-zA-Z]+_attributes for possible
collisions shows only:
The attached patch does it. There is a lot of changes, I suspect many
of them are candidates for replacing with use of the SET_ATTR and
GET_ATTR macros. Maybe defining a macro SELF_DATA_TYPE will be a
convenient shortcut.
Reading through the updated code, it seems that (using Task as an
On Fri Jul 11 09:41:21 2008, julianalbo wrote:
There is a problem with the autogenerated name: in several cases there
are other things with that name. For example, for the float.pmc we
have the Parrot_Float type defined in include/parrot/config.h
Given that the name will be mainly used via
On Thu, Jul 3, 2008 at 11:12 PM, Allison Randal via RT
[EMAIL PROTECTED] wrote:
A bit more detail on the conversion process for a PMC:
(snip)
3) Change 'init' and 'init_pmc' to initialize the auto-generated struct
instead of whatever initialization it was doing before. For example, if
it was
A bit more detail on the conversion process for a PMC:
1) Find the core data of the PMC, and convert it into a series of ATTR
statement at the beginning of the pmclass block. So, if the PMC uses
only 'PMC_int_val', create a single entry: 'ATTR INTVAL integer_data;'
(Pick a meaningful name, and
On Tue, Mar 25, 2008 at 9:30 PM, chromatic [EMAIL PROTECTED] wrote:
On Tuesday 25 March 2008 21:01:41 Will Coleda via RT wrote:
On Sat Dec 01 14:22:59 2007, coke wrote:
from DEPRECATED.pod
The PMC union struct is deprecated and will be removed once all core PMCs
have been
On Sat Dec 01 14:22:59 2007, coke wrote:
from DEPRECATED.pod
The PMC union struct is deprecated and will be removed once all core PMCs
have
been updated.
This has happened, correct?
Some pointers on how to implement this would probably turn this into a decent
CAGE task...
On Tuesday 25 March 2008 21:01:41 Will Coleda via RT wrote:
On Sat Dec 01 14:22:59 2007, coke wrote:
from DEPRECATED.pod
The PMC union struct is deprecated and will be removed once all core PMCs
have been updated.
This has happened, correct?
Not yet. PDD 17 made this possible, but
# New Ticket Created by Will Coleda
# Please include the string: [perl #48014]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48014
from DEPRECATED.pod
The PMC union struct is deprecated and will be removed once
29 matches
Mail list logo
