Re: [ptp-dev] Problem with creating enumerated attribute definitions?

["Randy M. Roberts" <rsqrd@xxxxxxxx>]

I'm against getting rid of the EnumeratedAttribute.  I see no
harm in keeping it around.  It has better type-safety than
StringSetAttribute.  So what if you can't create one on the
fly?  They are still very useful from within the Java code.

I'll use the less type-safe version when forced to, and the
more type-safe version when I'm able.

R^2

On Wed, 2007-06-20 at 15:29 -0600, Greg Watson wrote:
> I found some other bugs in this code. Please test and let me know if  
> it's ok now.
> 
> I discussed the attribute types with Randy. The reason he added  
> StringSetAttributeDefinition was that an  
> EnumeratedAttributeDefinition maps to an existing (Java) enumerated  
> type. Since there is no existing enumerated type when you create an  
> enumerated attribute definition from the proxy end, its not possible  
> to use this type. A StringSetAttributeDefinition has similar  
> characteristics to an EnumeratedAttributeDefinition, it is just not  
> backed by a real enumerated type.
> 
> I'm not sure I like the idea of having some attribute definition  
> types that can't be created from the proxy end, and would like to  
> consider merging these back together. We will lose some functionality  
> from the EnumeratedAttributeDefinition since it won't be a real  
> enumerated type any more, but I'm not sure this will be a big  
> problem. Do you have any thoughts one way or the other?
> 
> Greg
> 
> On Jun 20, 2007, at 2:06 PM, Dave Wootton wrote:
> 
> > Greg
> > Yes, that is what I am doing.
> > Dave
> >
> >
> >
> > Greg Watson <g.watson@xxxxxxxxxxxx>
> > Sent by: ptp-dev-bounces@xxxxxxxxxxx
> > 06/20/2007 02:24 PM
> > Please respond to
> > Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> >
> >
> > To
> > Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> > cc
> >
> > Subject
> > Re: [ptp-dev] Problem with creating enumerated attribute definitions?
> >
> >
> >
> >
> >
> >
> > Just to clarify, you are creating an enumerated attribute definition
> > (using an ATTR_DEF event) that has only one value, and that is
> > causing a NPE?
> >
> > I think that should be allowed, so it sounds like a bug. In fact, I
> > think you should be able to have an enumerated attribute definition
> > with no values (not sure what use it would be, but it should be
> > allowed at least).
> >
> > I'll check out the code you mentioned...
> >
> > Greg
> >
> > On Jun 20, 2007, at 11:39 AM, Dave Wootton wrote:
> >
> >> Greg
> >> I found what I think may be another bug with enumerated attribute
> >> definitions, although in this case, I might be abusing the concept
> >> of an
> >> enuerated attribute.
> >>
> >> I am trying to remove coding of specific values related to attributes
> >> defined by my proxy from my implementation of
> >> AbstractRMLaunchConfigurationDynamicTab. I have this working fine for
> >> default attribute values, and by use of enumerated attribute
> >> definitions,
> >> I have this working for attributes where I have a boolean selection
> >> such
> >> as yes/no. I realized I could build on this and use enumerated
> >> attribute
> >> definitions to specify the set of allowable selections that get
> >> added to a
> >> Combo box, and now have that working, except :-) for one attribute,
> >> where
> >> I have an editable Combo box where the user makes a choice of the
> >> single
> >> enumeration ('max') or types in a number to specify the value. For
> >> this
> >> one case, the enumerated attribute definition value set has only one
> >> value, which kind of stretches the concept of enumeration.
> >>
> >> The problem is that code near AbstractProxyRuntimeSystem line 832
> >> does
> >> not accept an event with only a single enumeration value, and line  
> >> 842
> >> fires a RuntimeMessageEvent. This goes somewhere, and I end up
> >> getting a
> >> null pointer exception.
> >>
> >> I can code around this by including a dummy enumeration value, like
> >> '???'
> >> and having the code which creates the Combo box ignore the '???' when
> >> adding items to the combo box, but I wanted to get your opinion  
> >> first.
> >>
> >> Dave
> >>
> >>
> >>
> >> Greg Watson <g.watson@xxxxxxxxxxxx>
> >> Sent by: ptp-dev-bounces@xxxxxxxxxxx
> >> 06/20/2007 11:25 AM
> >> Please respond to
> >> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> >>
> >>
> >> To
> >> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> >> cc
> >>
> >> Subject
> >> Re: [ptp-dev] Problem with creating enumerated attribute definitions?
> >>
> >>
> >>
> >>
> >>
> >>
> >> Agreed. It seems like they're both bugs. Hopefully Randy might be
> >> able to shed some light on this.
> >>
> >> Greg
> >>
> >> On Jun 20, 2007, at 8:45 AM, Dave Wootton wrote:
> >>
> >>> Greg
> >>> I was more concerned with the problem of not picking up the 2nd
> >>> enumeration value from the enumeration attribute definition event  
> >>> the
> >>> proxy sent to the front end than I was with getting a
> >>> StringSetAttributeDefinition object generated by the front end
> >>> instead of
> >>> the EnumeratedAttributeDefinition object that I was expecting to
> >>> get. I
> >>> agree that getting back a StringSetAttributionDefinition object back
> >>> instead or an EnumeratedAttributeDefinition object is likely a bug.
> >>> Dave
> >>>
> >>>
> >>>
> >>> Greg Watson <g.watson@xxxxxxxxxxxx>
> >>> Sent by: ptp-dev-bounces@xxxxxxxxxxx
> >>> 06/19/2007 04:13 PM
> >>> Please respond to
> >>> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> >>>
> >>>
> >>> To
> >>> Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
> >>> cc
> >>>
> >>> Subject
> >>> Re: [ptp-dev] Problem with creating enumerated attribute  
> >>> definitions?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Dave,
> >>>
> >>> You're so polite. It's highly likely to be a bug. If you're sending
> >>> an ENUMERATED attribute type, then that's what you should get, not a
> >>> StringSetAttribute.
> >>>
> >>> The StringSetAttribute is a new one on me. Anyone know what this is
> >>> for? How does it differ from an ArrayAttribute?
> >>>
> >>> Greg
> >>>
> >>>
> >>> On Jun 19, 2007, at 10:42 AM, Dave Wootton wrote:
> >>>
> >>>> I've made a change to my proxy to send enumerated attribute
> >>>> definition
> >>>> events to the front end. My intent is to use these attribute
> >>>> definitions
> >>>> to set the labels on a pair or radio buttons representing a boolean
> >>>> option. I've created a function in my proxy that sends the event to
> >>>> the
> >>>> front end in what I believe is the correct format <1, <n>, <id>,
> >>>> ENUMERATED, <short_name> <long_name> <default> <attr> <attr> ...>
> >>>> where
> >>>> <n> is the number of following tokens (5 + number of enumerations)
> >>>>
> >>>> I did have a problem where even though I was sending across 2
> >>>> enumerations, the StringSetAttributeDefinition that gets created
> >>>> has only
> >>>> the first enumeration. I found a line of code in
> >>>> AbstractProxyRuntimeSystem line 832 which read 'if (pos < end) {'
> >>>> which
> >>>> was resulting in picking up only the first enumeration. If I
> >>>> changed the
> >>>> '<' to '<=' then I get a StringSetAttributeDefinition with the two
> >>>> enumeration values.
> >>>>
> >>>> This is in the latest PTP code, since I updated my code this
> >>>> morning.
> >>>>
> >>>> Is this a problem with the AbstractProxyRuntimeSystem code, or have
> >>>> I done
> >>>> something wrong in my proxy?
> >>>>
> >>>> Also, when I send across an enumeration attribute definition, is it
> >>>> supposed to result in the creation of a  
> >>>> StringSetAttributeDefinition
> >>>> object? I was expecting to see an EnumerationAttributeDefinition
> >>>> object
> >>>> created, but when I got a class cast exception based on that
> >>>> assumtion, I
> >>>> tracked down the code where the StringSetAttributeDefinition was
> >>>> created.
> >>>>
> >>>> Generation of an EnumerationAttributeDefinition or a
> >>>> StringSetAttributeDefinition is fine either way. Leaving the code
> >>>> as-is
> >>>> means I don't have to get the attribute definition and then create
> >>>> a dummy
> >>>> attribute to get the value, but that's not frequently called code
> >>>> so isn't
> >>>> a big deal.
> >>>> Dave
> >>>> _______________________________________________
> >>>> ptp-dev mailing list
> >>>> ptp-dev@xxxxxxxxxxx
> >>>> https://dev.eclipse.org/mailman/listinfo/ptp-dev
> >>>>
> >>>
> >>> _______________________________________________
> >>> ptp-dev mailing list
> >>> ptp-dev@xxxxxxxxxxx
> >>> https://dev.eclipse.org/mailman/listinfo/ptp-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> ptp-dev mailing list
> >>> ptp-dev@xxxxxxxxxxx
> >>> https://dev.eclipse.org/mailman/listinfo/ptp-dev
> >>>
> >>
> >> _______________________________________________
> >> ptp-dev mailing list
> >> ptp-dev@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/ptp-dev
> >>
> >>
> >> _______________________________________________
> >> ptp-dev mailing list
> >> ptp-dev@xxxxxxxxxxx
> >> https://dev.eclipse.org/mailman/listinfo/ptp-dev
> >>
> >
> > _______________________________________________
> > ptp-dev mailing list
> > ptp-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ptp-dev
> >
> >
> > _______________________________________________
> > ptp-dev mailing list
> > ptp-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/ptp-dev
> >
> 
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev