Re: [perl #48014] [DEPRECATED] PMC union struct
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 PMCs with different attributes never worked before, so it's no loss that it doesn't work now. If this is the case, I'm happy. The PMCs I've found which use multiple inheritance (LuaFunction, TclInt and TclFloat) all have one parent which appears to be a generic or abstract PMC type for that language (LuaAny and TclObject, respectively). I'll get to work on a patch to propagate ATTRs to children and post it here when it gets close to ready. Sounds good. Thanks! Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
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 support. I'd like to implement whatever the long-term
solution is, which seems to mean multiple inheritance regarding ATTRs.
I've been puzzling over how to implement this in a way that would work
similarly to the current PMC_x_val macros. The problem with allowing
multiple inheritance is that we can't simply copy ATTRs from parents
into the same slot in their children when multiple parents have an ATTR
in the same slot.
This doesn't make sense. The PMC_x_val macros accessed the union value
of the PMC. Any PMC that used them had a fixed set of attributes, either:
- a buffer
- two pointers
- two integers
- a float, or
- a string
Because it was a union value, the PMC could use one and only one of the
alternatives, and the parent and child had to use the same alternative.
So, when you're translating an old-style PMC to a new-style PMC, you'll
define one of:
- a buffer
ATTR void * _bufstart;
ATTR size_t _buflen;
- two pointers
ATTR DPOINTER * _struct_val;
ATTR PMC * _pmc_val;
- two integers
ATTR INTVAL _int_val;
ATTR INTVAL _int_val2;
- a float
ATTR FLOATVAL _num_val;
- a string
ATTR STRING * _string_val;
And hopefully give it a more meaningful name than the original.
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 have more meaningful names, and it will become possible to
subclass these older PMCs from within PIR. More progress will come later
with enhancements to inheritance, but that's no reason to hold up the
deprecation of the union struct.
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?
If this is the case, I'm happy. The PMCs I've found which use multiple
inheritance (LuaFunction, TclInt and TclFloat) all have one parent which
appears to be a generic or abstract PMC type for that language (LuaAny and
TclObject, respectively). I'll get to work on a patch to propagate ATTRs to
children and post it here when it gets close to ready.
The best I've been able to come up with is to use yet another Hash to
store the ATTRs, turning the GETATTR/SETATTR macros into something like
the following (modulo supporting code):
#define GETATTR_PMCType_foo(interp, pmc, x) {
x = (AttrTypeGoesHere)parrot_hash_get(interp, pmc-attr_hash,
key_new_cstring(interp, PMCType_foo));
}
This would allow the accessor macros to work on PMCs similarly to how
PMC_x_val is used now, i.e. they'll DTRT as long as the PMC is in the
right inheritance tree.
This is overkill. Accessor macros already work on PMCs similarly to how
PMC_x_val is used.
Allison
I agree and am glad that such a heavyweight solution is evitable.
Re: [perl #48014] [DEPRECATED] PMC union struct
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 have more meaningful names, and it will become possible to
subclass these older PMCs from within PIR. More progress will come later
with enhancements to inheritance, but that's no reason to hold up the
deprecation of the union struct.
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?
If this is the case, I'm happy. The PMCs I've found which use multiple
inheritance (LuaFunction, TclInt and TclFloat) all have one parent which
appears to be a generic or abstract PMC type for that language (LuaAny and
TclObject, respectively). I'll get to work on a patch to propagate ATTRs to
children and post it here when it gets close to ready.
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 not likely there will need to be any changes other than nuking a few
more now-redundant ATTRs. Obviously, the HLLs will get a test before this
gets committed, barring any other objections.
Index: src/pmc/timer.pmc
===
--- src/pmc/timer.pmc (revision 35876)
+++ src/pmc/timer.pmc (working copy)
@@ -59,16 +59,6 @@
#include parrot/scheduler_private.h
pmclass Timer extends Task provides event need_ext {
-ATTR INTVALid;/* The task ID. */
-ATTR INTVALpriority; /* The priority of the task. */
-ATTR FLOATVAL birthtime; /* The creation time stamp of the task. */
-ATTR STRING *type; /* The type of the task. */
-ATTR STRING *subtype; /* The subtype of the task. */
-ATTR STRING *status;/* The status of the task. */
-ATTR Parrot_Interp interp;/* The interpreter that created the task. */
-ATTR PMC *codeblock; /* An (optional) codeblock for the task. */
-ATTR PMC *data; /* Additional data for the task. */
-ATTR char *cb_data; /* Additional data for a callback event. */
ATTR FLOATVAL duration; /* The duration of the timer pause */
ATTR FLOATVAL interval; /* How often to repeat */
ATTR INTVALrepeat;/* Whether to repeat:
Index: src/pmc/callsignature.pmc
===
--- src/pmc/callsignature.pmc (revision 35876)
+++ src/pmc/callsignature.pmc (working copy)
@@ -30,8 +30,6 @@
PARROT_CAPTURE(obj)-hash = pmc_new((i), enum_class_Hash);
pmclass CallSignature extends Capture need_ext provides array provides hash {
-ATTR PMC*array; /* Positional arguments */
-ATTR PMC*hash; /* Named arguments */
ATTR PMC*returns;/* Result PMCs, if they were passed with the call */
ATTR PMC*type_tuple; /* Cached argument types for multiple dispatch */
ATTR STRING *short_sig; /* Simple string signature args returns */
Index: lib/Parrot/Pmc2c/Parser.pm
===
--- lib/Parrot/Pmc2c/Parser.pm (revision 35876)
+++ lib/Parrot/Pmc2c/Parser.pm (working copy)
@@ -76,7 +76,7 @@
my $lineno = count_newlines($preamble) + $chewed_lines + 1;
my $class_init;
-($lineno, $pmcbody)= find_attrs( $pmc, $pmcbody, $lineno, $filename);
+($lineno, $pmcbody)= find_attrs( $pmc, $pmcbody, $lineno, $filename, $pmc2cMain);
($lineno, $class_init) = find_methods($pmc, $pmcbody, $lineno, $filename);
$pmc-postamble( Parrot::Pmc2c::Emitter-text( $post, $filename, $lineno ) );
@@ -90,7 +90,7 @@
}
sub find_attrs {
-my ($pmc, $pmcbody, $lineno, $filename) = @_;
+my ($pmc, $pmcbody, $lineno, $filename, $pmc2cMain) = @_;
# backreferences here are all +1 because below the qr is wrapped in quotes
my $attr_re = qr{
@@ -130,6 +130,24 @@
(/\*.*?\*/)?
}sx;
+#prepend parent ATTRs to this PMC's ATTR list
+if (@{$pmc-{parents}} 0 $pmc-{parents}[0] ne 'default') {
+my $got_attrs_from = '';
+foreach my $parent (@{$pmc-{parents}}) {
+my $parent_dump = $pmc2cMain-read_dump(lc($parent).'.dump');
+if ($got_attrs_from ne '' $parent_dump-{has_attribute}) {
+die $filename is trying to extend $got_attrs_from and $parent, .
+but both these PMCs have ATTRs.;
+}
+if ($parent_dump-{has_attribute}) {
+$got_attrs_from = $parent;
+foreach my $parent_attrs
Re: [perl #48014] [DEPRECATED] PMC union struct
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 not likely there will need to be
any changes other than nuking a few more now-redundant ATTRs.
Obviously, the HLLs will get a test before this gets committed,
barring any other objections.
+#prepend parent ATTRs to this PMC's ATTR list
+if (@{$pmc-{parents}} 0 $pmc-{parents}[0] ne 'default') {
+my $got_attrs_from = '';
+foreach my $parent (@{$pmc-{parents}}) {
+my $parent_dump = $pmc2cMain-read_dump(lc($parent).'.dump');
+if ($got_attrs_from ne '' $parent_dump-{has_attribute}) {
+die $filename is trying to extend $got_attrs_from and $parent,
.
+but both these PMCs have ATTRs.;
+}
+if ($parent_dump-{has_attribute}) {
+$got_attrs_from = $parent;
+foreach my $parent_attrs (@{$parent_dump-{attributes}}) {
+$pmc-add_attribute($parent_attrs);
+}
+}
+}
+}
+
I am wondering about the check with check with $got_attrs_from.
How is the case handled, where an PMC 'child' inherits from the PMC 'parent'
and 'child' wants to add an attribute to the attributes inherited from
'parent' ?
Regards,
Bernhard
Re: [perl #48014] [DEPRECATED] PMC union struct
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 here's
what I'm thinking patch, but it's not likely there will need to be
any changes other than nuking a few more now-redundant ATTRs.
Obviously, the HLLs will get a test before this gets committed,
barring any other objections.
+#prepend parent ATTRs to this PMC's ATTR list
+if (@{$pmc-{parents}} 0 $pmc-{parents}[0] ne 'default') {
+my $got_attrs_from = '';
+foreach my $parent (@{$pmc-{parents}}) {
+my $parent_dump = $pmc2cMain-read_dump(lc($parent).'.dump');
+if ($got_attrs_from ne '' $parent_dump-{has_attribute}) {
+die $filename is trying to extend $got_attrs_from and $parent,
.
+but both these PMCs have ATTRs.;
+}
+if ($parent_dump-{has_attribute}) {
+$got_attrs_from = $parent;
+foreach my $parent_attrs (@{$parent_dump-{attributes}}) {
+$pmc-add_attribute($parent_attrs);
+}
+}
+}
+}
+
I am wondering about the check with check with $got_attrs_from.
How is the case handled, where an PMC 'child' inherits from the PMC 'parent'
and 'child' wants to add an attribute to the attributes inherited from
'parent' ?
Regards,
Bernhard
Currently, there are no PMCs which multiply inherit from parents where more
than one parent has ATTRs. As far as I know, this currently falls under the
don't do that category.
The case where a child wants to have some ATTRs in addition to the ones its
parent has is handled gracefully. That's why the patch removes some ATTRs
from a couple PMCs. A child's ATTRs are a strict superset of the parent's.
Re: [perl #48014] [DEPRECATED] PMC union struct
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 declared in .pmc
files right after the pmclass line, e.g.
ATTR INTVAL foo_refs; /*foo refcount*/
These do not appear to be passed down to extending PMCs. This is a
problem for e.g UnManagedStruct/ManagedStruct, where PMC_int_val is used
the same way by both PMCs.
Right, at the moment it is absolutely required that the first ATTR
declarations of the child are manual copies of the ATTR declarations of
the parent. Otherwise, the inheritance won't work at all. (Ultimately,
inheritance will automatically copy the parent's attributes and prepend
them onto the front of the child's attribute list, but at the moment it
has to be done manually.)
What I'd like is for the pmc2c code to be smart enough to make ATTRs
from an extended PMC accessible by an extending PMC through the
GET_ATTR/SET_ATTR macros. If I could get a description of how such a
patch should behave from our architect, I'd be glad to write one up and
submit it for review.
The fix actually goes in a different place. The GET_ATTR/SET_ATTR macros
will be correctly generated for all child attributes. What really needs
to change is to add the parent's attribute list to the child's attribute
list during PMC parsing in Pmc2c. Take a look at
lib/Parrot/Pmc2c/Parser.pm. (I can give more specific guidance after the
release, working on milestone items at the moment.)
Allison
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 implement whatever the long-term solution
is, which seems to mean multiple inheritance regarding ATTRs.
I've been puzzling over how to implement this in a way that would work
similarly to the current PMC_x_val macros. The problem with allowing multiple
inheritance is that we can't simply copy ATTRs from parents into the same slot
in their children when multiple parents have an ATTR in the same slot.
The best I've been able to come up with is to use yet another Hash to store
the ATTRs, turning the GETATTR/SETATTR macros into something like the
following (modulo supporting code):
#define GETATTR_PMCType_foo(interp, pmc, x) {
x = (AttrTypeGoesHere)parrot_hash_get(interp, pmc-attr_hash,
key_new_cstring(interp, PMCType_foo));
}
This would allow the accessor macros to work on PMCs similarly to how
PMC_x_val is used now, i.e. they'll DTRT as long as the PMC is in the right
inheritance tree.
The obvious downside is that this is a major increase in runtime cost for
something that's currently a pointer deref and a struct offset calculation.
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.
Either way, something needs to be done.
Re: [perl #48014] [DEPRECATED] PMC union struct
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 quirk of the PMC preprocessor that allowed the appearance of multiple inheritance. Certainly the semantics have never been defined, at least as far as inheriting behavior or attributes. If C PMCs need to proclaim that they conform to the interface of another PMC, they should use 'does'. -- c
Re: [perl #48014] [DEPRECATED] PMC union struct
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 implement whatever the long-term
solution is, which seems to mean multiple inheritance regarding ATTRs.
I've been puzzling over how to implement this in a way that would work
similarly to the current PMC_x_val macros. The problem with allowing
multiple inheritance is that we can't simply copy ATTRs from parents
into the same slot in their children when multiple parents have an ATTR
in the same slot.
This doesn't make sense. The PMC_x_val macros accessed the union value
of the PMC. Any PMC that used them had a fixed set of attributes, either:
- a buffer
- two pointers
- two integers
- a float, or
- a string
Because it was a union value, the PMC could use one and only one of the
alternatives, and the parent and child had to use the same alternative.
So, when you're translating an old-style PMC to a new-style PMC, you'll
define one of:
- a buffer
ATTR void * _bufstart;
ATTR size_t _buflen;
- two pointers
ATTR DPOINTER * _struct_val;
ATTR PMC * _pmc_val;
- two integers
ATTR INTVAL _int_val;
ATTR INTVAL _int_val2;
- a float
ATTR FLOATVAL _num_val;
- a string
ATTR STRING * _string_val;
And hopefully give it a more meaningful name than the original.
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 have more meaningful names, and it will become possible to
subclass these older PMCs from within PIR. More progress will come later
with enhancements to inheritance, but that's no reason to hold up the
deprecation of the union struct.
The best I've been able to come up with is to use yet another Hash to
store the ATTRs, turning the GETATTR/SETATTR macros into something like
the following (modulo supporting code):
#define GETATTR_PMCType_foo(interp, pmc, x) {
x = (AttrTypeGoesHere)parrot_hash_get(interp, pmc-attr_hash,
key_new_cstring(interp, PMCType_foo));
}
This would allow the accessor macros to work on PMCs similarly to how
PMC_x_val is used now, i.e. they'll DTRT as long as the PMC is in the
right inheritance tree.
This is overkill. Accessor macros already work on PMCs similarly to how
PMC_x_val is used.
Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
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 instances where the PMCs with a related purpose but no inheritance (e.g. RetContinuation and ExceptionHandler) have the unionval used in the same way on a line of code. What's the right way to fix these cases to use the GETATTR/SETATTR macros? Tough to answer without looking at the code, but... The GET_ATTR/SET_ATTR macros will work on inherited attributes as well as child attributes. (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.) If two unrelated PMCs are being called in the same line of code, that probably means it should really be a vtable function call instead of direct access into the data struct. Allison When I say attributes, I mean the things that are declared in .pmc files right after the pmclass line, e.g. ATTR INTVAL foo_refs; /*foo refcount*/ These do not appear to be passed down to extending PMCs. This is a problem for e.g UnManagedStruct/ManagedStruct, where PMC_int_val is used the same way by both PMCs. For example, say that I add ATTR INTVAL struct_size; to UnManagedStruct. It's possible to replace some instances of PMC_int_val with VTABLE_get_integer in these two PMCs, but I can't use GETATTR_UnManagedStruct_struct_size in UnManagedStruct's get_integer VTABLE function because ManagedStruct uses UnManagedStruct's get_integer, but doesn't have its ATTRs. It would be possible to add the same ATTR to ManagedStruct and make sure that it had its own get_integer VTABLE function. Unfortunately this would mean more code duplication and would negate some of the benefits of allowing PMCs to extend each other. What I'd like is for the pmc2c code to be smart enough to make ATTRs from an extended PMC accessible by an extending PMC through the GET_ATTR/SET_ATTR macros. If I could get a description of how such a patch should behave from our architect, I'd be glad to write one up and submit it for review.
Re: [perl #48014] [DEPRECATED] PMC union struct
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 after the pmclass line, e.g. ATTR INTVAL foo_refs; /*foo refcount*/ These do not appear to be passed down to extending PMCs. This is a problem for e.g UnManagedStruct/ManagedStruct, where PMC_int_val is used the same way by both PMCs. Right, at the moment it is absolutely required that the first ATTR declarations of the child are manual copies of the ATTR declarations of the parent. Otherwise, the inheritance won't work at all. (Ultimately, inheritance will automatically copy the parent's attributes and prepend them onto the front of the child's attribute list, but at the moment it has to be done manually.) What I'd like is for the pmc2c code to be smart enough to make ATTRs from an extended PMC accessible by an extending PMC through the GET_ATTR/SET_ATTR macros. If I could get a description of how such a patch should behave from our architect, I'd be glad to write one up and submit it for review. The fix actually goes in a different place. The GET_ATTR/SET_ATTR macros will be correctly generated for all child attributes. What really needs to change is to add the parent's attribute list to the child's attribute list during PMC parsing in Pmc2c. Take a look at lib/Parrot/Pmc2c/Parser.pm. (I can give more specific guidance after the release, working on milestone items at the moment.) Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
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 PMCs with a related purpose but no inheritance (e.g. RetContinuation and ExceptionHandler) have the unionval used in the same way on a line of code. What's the right way to fix these cases to use the GETATTR/SETATTR macros? I have a file that lists these, which I'll be sticking on the wiki later tonight. Here's the more detailed version: Thanks to Infinoid++, I was able to follow particle's recommendation earlier in the thread and modify the PMC_x_val macros to record some information at runtime. This will make the cage task *much* more approachable and parallelizable, but it also exposes places where code makes promiscuous assumptions about PMC internals. The referenced files were generated by modifying include/parrot/pobj.h [1], then building and testing Parrot and any currently maintained HLLs that use custom PMCs. The results are on trac, sorted by file [2] and by PMC [3]. I did this to help clarify how the UnionVal macros would need to be converted to GETATTR/SETATTR macros, since the latter are PMC-specific. The files are generated from r34501 and can be regenerated as needed. The problem with using ATTRs in their current state is that, depending on control flow, a given instance of a PMC_x_val may be called with several different PMC types (see src/hash.c:1045 in [2] for an extreme case). This is fairly common and makes ATTRs unusable for any PMCs whose UnionVals are twiddled by common code. One solution to this would be to make ATTRs follow the inheritance chain so the following code works: PMC *foo = new_pmc(INTERP, enum_class_Foo); /*Foo has no ATTRs, extends Bar*/ INTVAL baz; /*Bar has a baz ATTR*/ GETATTR_Bar_baz(INTERP, foo, baz); I'm not attached to any particular solution, but it's clear that the migration away from the PMC UnionVal can't happen without some kind of significant change. [1] http://xrl.us/becsw4 (diff) [2] http://xrl.us/becswu (csv, sorted by source code file) [3] http://xrl.us/becsww (csv, sorted by PMC type)
Re: [perl #48014] [DEPRECATED] PMC union struct
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 PMCs with a related purpose but no inheritance (e.g. RetContinuation and ExceptionHandler) have the unionval used in the same way on a line of code. What's the right way to fix these cases to use the GETATTR/SETATTR macros? Tough to answer without looking at the code, but... The GET_ATTR/SET_ATTR macros will work on inherited attributes as well as child attributes. (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.) If two unrelated PMCs are being called in the same line of code, that probably means it should really be a vtable function call instead of direct access into the data struct. Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
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 in DEPRECATED.pod be removed? Not until we apply this patch and all tests still pass. -- c I removed one definition (PMC_str_val) locally and tried to fix the build. made some decent progress: I assume that the replacement for this define and direct struct access are the corresponding vtable entries; One problem, string.pmc's set_string_native uses the macro to set its own value; How do I replace it there? -- Will Coke Coleda ___ http://lists.parrot.org/mailman/listinfo/parrot-dev Nevermind; I just saw allison's in depth explanation earlier in the ticket history. (And that cotto claimed this ticket a scant 16 hours ago so I can ignore it! =-) -- Will Coke Coleda
Re: [perl #48014] [DEPRECATED] PMC union struct
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 this patch. Few thousand lines :) -- Bacek
Re: [perl #48014] [DEPRECATED] PMC union struct
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 patch. Few thousand lines :) -- Bacek
[perl #48014] [DEPRECATED] PMC union struct
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 removed? -- /* [EMAIL PROTECTED] */
Re: [perl #48014] [DEPRECATED] PMC union struct
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 deprecation item in DEPRECATED.pod be removed? No, this was just a helper step. -- Salu2
Re: [perl #48014] [DEPRECATED] PMC union struct
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 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 example): Parrot_PMCdata_Task is not much clearer than the original Parrot_Task was. Let's go with: Parrot_Task_attributes (Fortunately, with the string PMCdata in all the type names, it should be easy to write an automatic search-and-replace.) I only modified and tested parrot core, surely several languages needs some patching. Also, don't fixed line length codingstd. I expect approval before taken care of that, Otherwise approved, and thanks! Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
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: Parrot_Class_nci_attributes Parrot_Role_nci_attributes We can live with this. (Fortunately, with the string PMCdata in all the type names, it should be easy to write an automatic search-and-replace.) That was the main reason for using a long ugly name. -- Salu2
Re: [perl #48014] [DEPRECATED] PMC union struct
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 example): Parrot_PMCdata_Task is not much clearer than the original Parrot_Task was. Let's go with: Parrot_Task_attributes (Fortunately, with the string PMCdata in all the type names, it should be easy to write an automatic search-and-replace.) I only modified and tested parrot core, surely several languages needs some patching. Also, don't fixed line length codingstd. I expect approval before taken care of that, Otherwise approved, and thanks! Done in r30914: changed name to Parrot_type_attributes, fixed codingstd, changed also pmc in languages lua and perl6, and updated pdd17_pmc.pod -- Salu2
[perl #48014] [DEPRECATED] PMC union struct
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 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. Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
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 previously setting a default value in PMC_int_val, it now needs to allocate a struct of the appropriate type (the autogenerated structe is always named Parrot_PMCname, so the Exporter PMC has a struct named Parrot_Exporter), store that struct in PMC_data, and then set default values on the struct. See src/pmc/exporter.pmc for a good example of 'init'. 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 macros, a long and meaningful name can be used, such as Parrot_PMCdata_PMCname -- Salu2
[perl #48014] [DEPRECATED] PMC union struct
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 add a comment at the end of the line explaining what it is. A good example is src/pmc/eventhandler.pmc.) If the core data of the PMC is a whole struct stored in PMC_data, you can directly copy the body of that struct into the .pmc file, and just prepend ATTR to each line. 2) Change any calls to PMC_int_val (or whatever macro the particular PMC uses) to 'GET_ATTR_integer_data' or 'SET_ATTR_integer_data' (the lower-case half of the accessor macros matches the name you gave the attribute in the 'ATTR' declaration.) If your attribute is a PMC/STRING/INTVAL/FLOATVAL type, the accessor is generated to correctly set/retrieve the native type directly. These macros must be used on a separate line, and can't be embedded within other C code on a line. See src/pmc/exporter.pmc for an example. So this is correct: GET_ATTR_ns_src(interp, SELF, tmp_ns_src); but this is wrong: tmp_ns_src = GET_ATTR_ns_src(interp, SELF); 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 previously setting a default value in PMC_int_val, it now needs to allocate a struct of the appropriate type (the autogenerated structe is always named Parrot_PMCname, so the Exporter PMC has a struct named Parrot_Exporter), store that struct in PMC_data, and then set default values on the struct. See src/pmc/exporter.pmc for a good example of 'init'. 4) Any place you need to directly access the core struct of the PMC, use the accessor macro for the PMC's struct. It is named the same as the struct but in all caps (for example, the Exporter PMC's accessor macro for the core data struct used like 'Parrot_Exporter *core_struct = PARROT_EXPORTER(SELF);'). 5) Change 'destroy' to destroy PMC_data. 6) Change 'mark' to mark any PMC elements of the core data struct. 7) Check 'freeze'/'thaw' and related vtable entries for direct access to old data elements and update it to the new data elements. That should get you 90-95% of the way there. Rebuild the PMC (make sure the src/pmc/pmc_PMCname.h header file for the PMC was regenerated to include the Parrot_PMCname struct GETATTR and SETATTR macros). Check for compile errors and test failures. If the cause of any errors isn't immediately obvious, check with allison or chromatic. Allison
[perl #48014] [DEPRECATED] PMC union struct
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...
Re: [perl #48014] [DEPRECATED] PMC union struct
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 someone (and your first two guesses don't count) has to update all of the core PMCs and the language PMCs not to use the cache structure. Some pointers on how to implement this would probably turn this into a decent CAGE task... 1) Figure out what kind of data the PMC stores 2) Replace all uses of PMC_int_val(), PMC_float_val(), and PMC_str_val() with attribute access within the PMC 3) Replace all uses of those macros with attribute access outside of the PMC 4) Fix any compilation errors -- c
[perl #48014] [DEPRECATED] PMC union struct
# 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 all core PMCs have been updated.
