[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] Problem with creating enumerated attribute definitions?
|
Greg
I downloaded the latest code and it works fine for me.
I would prefer to keep StringSetAttribute in some form. The reason I tried
using EnumeratedAttributes in the first place was to try to move as much
hard coding of allowable attribute values and ranges as I could out of the
gui code and keep that information in the proxy. Part of the justification
is that I'm trying to have a single GUI class that works with AIX and
Linux as well as PE with and without LL, where some allowable attribute
values change for each permutation.
If the work to make EnumeratedAttributes work correctly means that the gui
code must contain a Java enumeration type and that the definition event
sent by the proxy for the enumerated attribute needs to reference that
Java enumeration type, then that means I need to define enumeration types
in my gui code, essentially moving the implementation specifics back into
gui code.
I'm currently using enumerated attributes for two things
1) To set the text for the radio button pairs correspodning to attributes
where the user must make a boolean selection (yes/no, dedicated/shared,
etc). When I build the attributes to send back to the proxy in a run
command, I get the attribute value by calling getText() for the selected
radio button (that might get me into trouble if we ever have to worry
about language translation issues)
2) For Combo boxes where I specify the set of values to be loaded into the
combo box dropdown at widget initialization. When the user makes a choice
for an editable combobox, I validate the user's choice against the
attribute definition as part of the validation.
Maybe the solution, if there is a use for an enumerated attribute that can
use a predefined Java enumeration, is to fix up the EnumeratedAttribute
implementation and keep the StringSetAttribute, maybe adding a STRINGSET
(or other name) event that the proxy can generate.
Dave
Greg Watson <g.watson@xxxxxxxxxxxx>
Sent by: ptp-dev-bounces@xxxxxxxxxxx
06/20/2007 06:48 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?
Maybe that's the way to get around it. Rather than use StringSet, we
could map it to a pre-defined enumerated type in the RM-specific
implementation. Any idea how this would work? It sounds like we'd
need another interface defined to make this happen.
I would like to see StringSet go in any case, for three reasons:
1. It's confusing (to me anyway).
2. It's not an enumerated type, but that's what the protocol specifies.
3. I don't think we should have attribute types that can't be created
by the proxy.
Greg
On Jun 20, 2007, at 4:12 PM, Randy M. Roberts wrote:
> BTW, there is no reason why you can't create the
> EnumeratedAttributeDefinition from the proxy end if it's an agreed
> upon Java Enum.
>
> Let's say that some LSF want-to-be has a concept of priority,
> and has defined the following Java Enum,
>
> public enum Priority {
> HIGH,
> MEDIUM,
> NICE,
> VERY_NICE
> }.
>
> I could extend the proxy, for the want-to-be, to recognize a new
> parameter that says to create an attribute or attribute definition
> using
> this particular enum.
>
> Why would you want to modify all of the code that currently uses
> the EnumeratedAttribute? It would be an unnecessary code change that
> will only do more harm (type-safety) than good.
>
> Regards,
> 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
>
> _______________________________________________
> 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
