On Fri, May 13, 2011 at 11:57 PM, Patrick R. Michaud <[email protected]> wrote: >> TT #2035 already gives an upgrade path. > > I vehemently disagree with the notion of "upgrade path" implied by this > response and the ticket.
We're obviously not going to get anywhere arguing yuh-huh/nuh-uh over and over again. For the sake of everybody's sanity, can we agree to disagree on this point? Information was provided, the user would have liked more of it. Let's make a note of this going forward and make a conscious effort not to fall into this situation again. > Based on reading the #2035 ticket, I have no clue what a Ptr, PtrBuf, > PtrObj, or StructView PMC might be, what they can do, or how to use them. > It provides me no links or suggestions where I might look for this > information. > > Doing a search through the Parrot sources reveals little documentation > on any of these classes, unless I want to try to decipher the C code that > implements them. AFAICT there is exactly one test that makes use of > StructView (in t/pmc/nci.t), and in that test I have no clue what > the constants .DATATYPE_STRUCT or .DATATYPE_PIR are intended to > represent. Unlike UnManagedStruct, there are no existing examples, > PDDs, or library code that I can look to for an idea of how these new > classes might be used. (UnManagedStruct has all of these.) > > A search for "StructView" in trac.parrot.org only brings up a few > tickets; the #2035 ticket and a few others that describe problems > with StructView. A search for "PtrObj" only brings up the #2035 ticket. We clearly need more/better documentation about these things. I'll open a ticket to make sure we do that. Also, it seems like we need to take some effort to improve the quality and accuracy of PDD16 and eventually move that out of draft so that everybody is on the same page about what Parrot is trying to achieve with recent and future changes to that system. What we need to do right now is find a satisfactory way forward. We need to figure out how much of a headache it is going to be for Parrot to add back the 't' signature (or something very very similar to it), vs how much headache is going to be required to work around it in Zavolaj. We need to do this keeping in mind that Parrot has a release coming up in only a few days, and we very likely will have a code freeze in place (depending on what the release manager has to say) during part of the remaining time. I'm going to focus as much of my attention to this issue as possible. We should aim to have some kind of a solution agreed upon by tomorrow. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
