stm ready (was Re: More review of current stm branch code)
So, given the below, looks like we've got everything sewn up and the long-awaited day of the STM merge is upon us. Charles, care to do the honors? On Tue, Aug 15, 2006 at 06:31:38PM -0400, Charles Reiss wrote: > On 8/15/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote: > >On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote: > >> I wrote: > >> >It also does not allow .pmc files to overide the default idea of > >> >whether a vtable method is read-only. > >> > >> This remains unresolved though I'm not certain it should be allowed. > >> The hard part of doing it correctly is handling inheritance. > > > >It's an interface guarantee, and as such I think it's OK that it can't be > >overridden in a derived class. Agree? > > Er, when I first read that I thought you meant that with respect to > the inheritance issue, but reading again I'm not sure. Yes, that's what I meant. > But, anyways, looking over pmc2c I found that doing it 'properly' was not > too difficult, so I've done that (read/writeness is inherited by default > and can be overridden). Works For Me, thanks. > I provide the feature in the hope that people will think really hard > before using it to violate interface guarantees. Big friendly warnings are the right first step. If people start ignoring the signs and wandering onto the live minefields, we'll have to start thinking about audio warnings and fierce guards with pointed sticks. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: More review of current stm branch code
On 8/15/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote: On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote: > I wrote: [snip] > >It also does not allow .pmc files to overide the default idea of > >whether a vtable method is read-only. > > This remains unresolved though I'm not certain it should be allowed. > The hard part of doing it correctly is handling inheritance. It's an interface guarantee, and as such I think it's OK that it can't be overridden in a derived class. Agree? Er, when I first read that I thought you meant that with respect to the inheritance issue, but reading again I'm not sure. But, anyways, looking over pmc2c I found that doing it 'properly' was not too difficult, so I've done that (read/writeness is inherited by default and can be overridden). I provide the feature in the hope that people will think really hard before using it to violate interface guarantees. -- Charles Reiss
Re: More review of current stm branch code
On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote: > I wrote: > >The read-only variant generation currently does not handle NCI methods > >at all. There are number of implementation options; the best I can > >think of is to override findmethod (in the read-only type) to check > >for a property on the found method PMC that would indicates it writes > >(or vice-versa). > > This is done (w/ s/findmethod/find_method/ of course), returning PMCNULL > instead of a method that would write. (This prevents it from being called, > but doesn't yield helpful errors.) Yow, done already! Excellent. (Shoulda read the followup first.) > >It also does not allow .pmc files to overide the default idea of > >whether a vtable method is read-only. > > This remains unresolved though I'm not certain it should be allowed. > The hard part of doing it correctly is handling inheritance. It's an interface guarantee, and as such I think it's OK that it can't be overridden in a derived class. Agree? > >A bigger issue for automatic read-only variant generation is that MMD > >methods currently don't do any read-onlyness detection. (Sorry!) > > This is now fixed. Yow^2! Nice work. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: More review of current stm branch code
On Fri, Aug 11, 2006 at 04:38:59PM -0400, Charles Reiss wrote:
> On 8/10/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > /* XXX is it okay to combine flatten/slurpy into one flag? */
> >
> > The answer is "No": "flat" is an output flag, "slurpy_array" is an input
> > flag, and there's no guarantee that the input and output flags won't
> > conflict with each other. So I guess this means that something has to
> > change.
>
> I suppose trying to make '@' mean something different for signatures and
> for calls from C (as I have done) is a Bad Idea as long as the same code
> is used to parse the signatures in both cases. The easy solution is to
> choose a character other than '@' for one of the directions though I can't
> think of what might be most natural ('F' for flat?).
To provide a general ability to wrap any call from C, then you need to add
named parameter support too; flat arrays are _so_ Perl 5. Would '%' and 'N'
work for you? :-) (also see below)
> >MORE QUESTIONS
> > * The '@' character for native call signatures is new, and AFAICT is just
> > syntactic sugar, since the caller could do the array creation himself.
> > Could you explain what you would have to do if you didn't introduce this
> > feature? (I'm not necessarily against it, mind you, I just want to know
> > what the deal is.)
>
> It is just syntactic sugar. So, not using would be as you describe, having
> the (most likely PIR) caller construct the array manually. My use of this
> feature is only to allow naturally passing an arbitrary number of
> arguments to the subroutine that is first executed in a new thread, which
> I feel is quite convenient.
Well, as it happens, we've been wanting support for variadic PMC METHODs for
a Long Time. Since you're already introducing necessary infrastructure, are
you inclined to add some PMC METHOD syntactic sugar too, so that we can
conveniently define METHODs that accept arbitrary parameter lists? (This
is not a merge blocker, of course; just a wishlist item.)
> > * Another comment asks:
> >
> ># autogenerate for exotic types
> ># (XXX is this appropriate or do we want them to each
> ># be explicitly cleared to have the variant?)
> >
> > Well, that depends. Is there currently any way for a named METHOD to
> > specify whether it is :write, and if so, is this used? If so, then yes,
> > making an automatic ro variant is OK. If not, then I think we might
> > want such a thing...?
>
> The read-only variant generation currently does not handle NCI methods
> at all. There are number of implementation options; the best I can
> think of is to override findmethod (in the read-only type) to check
> for a property on the found method PMC that would indicates it writes
> (or vice-versa).
That's actually kind of neat; at least, it's clearly the least bad of all
the options I see.
The only minor downside IMO is that in order to get adequate speed we'll
need to dedicate an easy-to-see flag bit somewhere visible in the method PMC
to mean ":write", and there are only so many of those. But fast threading
is hardly a minor feature, so I don't mind that cost at all.
> A bigger issue for automatic read-only variant generation is that MMD
> methods currently don't do any read-onlyness detection. (Sorry!) (This is
> not quite as much as a problem as it may seem because things like String
> and Integer, being designed to allow subclassing, call vtable methods from
> their MMD methods to do any manipulation.)
Understood, agreed.
> As a stopgap solution, it would be easy to reverse the logic I have
> now and default to not generating a read-only version except when the
> .pmc file says it is okay instead of the other way around.
Well, this is still 0.4, not 1.0. If you can just tell us on the list what
we shouldn't do, so we can include it in the release notes, then I don't
mind having only partial protection. For obvious reasons, nobody's using
the thread support right now, so it won't break anything. ...Or will it?
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: More review of current stm branch code
I wrote:
[snip]
I suppose trying to make '@' mean something different for signatures and for
calls from C (as I have done) is a Bad Idea as long as the same code is used
to parse the signatures in both cases. The easy solution is to choose
a character
other than '@' for one of the directions though I can't think of what
might be most
natural ('F' for flat?).
I've separated it into 'F' (flatten for call from C) and '@' for now.
[snip]
The read-only variant generation currently does not handle NCI methods
at all. There are number of implementation options; the best I can
think of is to override findmethod (in the read-only type) to check
for a property on the found method PMC that would indicates it writes
(or vice-versa).
This is done (w/ s/findmethod/find_method/ of course), returning PMCNULL
instead of a method that would write. (This prevents it from being called,
but doesn't yield helpful errors.)
It also does not allow .pmc files to overide the default idea of
whether a vtable method is read-only.
This remains unresolved though I'm not certain it should be allowed.
The hard part of doing it correctly is handling inheritance.
A bigger issue for automatic read-only variant generation is that MMD
methods currently don't do any read-onlyness detection. (Sorry!)
This is now fixed.
[snip]
-- Charles Reiss
Re: More review of current stm branch code
On 8/10/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
More on the STM branch:
ANSWERS, FOR A CHANGE
* A comment asks:
/* XXX is it okay to combine flatten/slurpy into one flag? */
The answer is "No": "flat" is an output flag, "slurpy_array" is an input
flag, and there's no guarantee that the input and output flags won't
conflict with each other. So I guess this means that something has to
change.
I suppose trying to make '@' mean something different for signatures and for
calls from C (as I have done) is a Bad Idea as long as the same code is used
to parse the signatures in both cases. The easy solution is to choose
a character
other than '@' for one of the directions though I can't think of what
might be most
natural ('F' for flat?).
[one note moved later in this email]
MORE QUESTIONS
* The '@' character for native call signatures is new, and AFAICT is just
syntactic sugar, since the caller could do the array creation himself.
Could you explain what you would have to do if you didn't introduce this
feature? (I'm not necessarily against it, mind you, I just want to know
what the deal is.)
It is just syntactic sugar. So, not using would be as you describe, having the
(most likely PIR) caller construct the array manually. My use of this feature is
only to allow naturally passing an arbitrary number of arguments to
the subroutine that
is first executed in a new thread, which I feel is quite convenient.
It is, however,
not terribly important (and perhaps I shouldn't have spent time
implementing it), and
if deemed undeseriable, I would not suffer much penalty in removing it.
* Another comment asks:
# autogenerate for exotic types
# (XXX is this appropriate or do we want them to each
# be explicitly cleared to have the variant?)
Well, that depends. Is there currently any way for a named METHOD to
specify whether it is :write, and if so, is this used? If so, then yes,
making an automatic ro variant is OK. If not, then I think we might want
such a thing...?
The read-only variant generation currently does not handle NCI methods
at all. There are number of implementation options; the best I can
think of is to override findmethod (in the read-only type) to check
for a property on the found method PMC that would indicates it writes
(or vice-versa).
It also does not allow .pmc files to overide the default idea of
whether a vtable method is read-only.
A bigger issue for automatic read-only variant generation is that MMD
methods currently don't do any read-onlyness detection. (Sorry!) (This
is not quite as much as a problem as it may seem because things like
String and Integer, being designed to allow subclassing, call vtable
methods from their MMD methods to do any manipulation.)
As a stopgap solution, it would be easy to reverse the logic I have
now and default to not generating a read-only version except when the
.pmc file says it is okay instead of the other way around.
ANOTHER NAMING THING
* Please rename 'ro_variant' to something ending in '_vtable',
e.g. 'ro_variant_vtable', to make clear that it's not a class pointer
or type number.
Done (using suggested name).
-- Charles Reiss
More review of current stm branch code
More on the STM branch: ANSWERS, FOR A CHANGE * A comment asks: /* XXX is it okay to combine flatten/slurpy into one flag? */ The answer is "No": "flat" is an output flag, "slurpy_array" is an input flag, and there's no guarantee that the input and output flags won't conflict with each other. So I guess this means that something has to change. * Another comment asks: # autogenerate for exotic types # (XXX is this appropriate or do we want them to each # be explicitly cleared to have the variant?) Well, that depends. Is there currently any way for a named METHOD to specify whether it is :write, and if so, is this used? If so, then yes, making an automatic ro variant is OK. If not, then I think we might want such a thing...? MORE QUESTIONS * The '@' character for native call signatures is new, and AFAICT is just syntactic sugar, since the caller could do the array creation himself. Could you explain what you would have to do if you didn't introduce this feature? (I'm not necessarily against it, mind you, I just want to know what the deal is.) ANOTHER NAMING THING * Please rename 'ro_variant' to something ending in '_vtable', e.g. 'ro_variant_vtable', to make clear that it's not a class pointer or type number. -- Chip Salzenberg <[EMAIL PROTECTED]>
