Re: [tcf-dev] Context-query tid parameter issue

["Tepavich, Scott" <scott.tepavich@xxxxxxxxxxxxx>]

> To use again your example with Linux PID, 2/ is stated under the assumption that it is valid 
> for the user to enter an hexadecimal value for the PID when everywhere else the PID 
> is shown as a decimal.

I think this misses the entire point.  What does it matter if the user feels decimal/hexadecimal/binary/octal/other is more natural?  This should not matter in regards to the underlying implementation.  As long as the user enters the value in a well adopted freeform format, the value should be kept and displayed for the user consumption.

I'm sorry for the spam to all, and will cease on this thread.  My initial point was numerical values being passed in are not being handled in a freeform fashion, and I did not infer the reason why through the code.  I already received my answer, and will address this issue in another way that is more acceptable to the community.

> As long as the properties type can't be requested by the client from the agent, 
> I'm afraid you will have to keep some formatting rules for each property value in the client.

That brings in a whole separate set of issue.

Thank you -
Scott

-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Christophe Augier
Sent: Friday, September 21, 2012 10:12 AM
To: tcf-dev@xxxxxxxxxxx
Subject: Re: [tcf-dev] Context-query tid parameter issue

> 2.) Update each comparator and inject the logic to handle hex and decimal values for each.

To use again your example with Linux PID, 2/ is stated under the assumption that it is valid for the user to enter an hexadecimal value for the PID when everywhere else the PID is shown as a decimal. Even worse, the service implementing the comparator may actually see the PID as a string and not a number and therefore doesn't event convert it to a number but instead uses strncmp().

As long as the properties type can't be requested by the client from the agent, I'm afraid you will have to keep some formatting rules for each property value in the client.

- Christophe

>
> My previous suggestion/request just seemed simpler.
>
> Thanks -
> Scott
>
> -----Original Message-----
> From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] 
> On Behalf Of Christophe Augier
> Sent: Friday, September 21, 2012 9:06 AM
> To: tcf-dev@xxxxxxxxxxx
> Subject: Re: [tcf-dev] Context-query tid parameter issue
>
> Hi Scott,
>
> why don't you simply use double quotes all the time around your property value? From the service point of view, the property is either a number, a boolean or a string. This is used for parsing the context query but in the end the context query comparator function receives a string. So this is up to the service implementing the comparator to parse the property value.
>
> - Christophe
>
> On 9/21/2012 5:42 PM, Tepavich, Scott wrote:
>> When originally adding context query support for breakpoints, we only 
>> tested against Linux.  Part of the query allows for the user to enter 
>> a TID or PID for context filtering of the underlying OS attribute.
>> This worked perfectly due to the nature that Linux supports decimal 
>> formatting of these fields.
>>
>> Recently we attempted to test this same workflow for another RTOS.
>> This OS supports hexadecimal TID and PID values, and this form is 
>> more natural for the user in this environment.  When these values are 
>> placed in the context-query string and sent to the agent, the
>> parse_context_query() routine down in the agent returns an error 
>> (since it's expecting a decimal value).
>>
>> The interface defined for setting the context query, attempts to 
>> allow the user to compose/edit the string by hand.  If we attempt to 
>> solve the problem in the client, we would need to parse the string 
>> when the user has completed entering their text, and convert the hex into decimal.
>> Either that or return an error to the user stating that hexadecimal 
>> is not a valid form.
>>
>> The latter is not a solution.  The former is problematic when 
>> re-fetching the defined query for the user.  The values in the string 
>> would be stored as decimal values, and the client would not have 
>> enough criteria to choose which form to display to the user.  A "view 
>> as hex | decimal" option could be inserted, but this can be 
>> problematic where there are multiple numeric fields and each is 
>> typically viewed in different forms.
>>
>> This could be solved more simply, if we allowed a freeform expression 
>> of numerical values as (at a minimum) decimal or hexadecimal for 
>> context queries.  I pose the question if it would be acceptable if I 
>> updated the context query parser to allow for this?  I think I 
>> already know the answer, but feel compelled to ask...
>>
>> Thanks for your time -
>>
>> Scott
>>
>>
>>
>> _______________________________________________
>> tcf-dev mailing list
>> tcf-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/tcf-dev
>>
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/tcf-dev
> _______________________________________________
> tcf-dev mailing list
> tcf-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/tcf-dev
>
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/tcf-dev