PMC union struct

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

Tuesday 25 March 2008 21:01:41 Will Coleda via RT wrote:

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

Tuesday 25 March 2008 21:01:41 Will Coleda via RT wrote:

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

Tuesday 25 March 2008 21:01:41 Will Coleda via RT wrote:

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

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/FLATVAL 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 =
PARRT_EXPRTER(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_<PMCnamestruct 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

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