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

[Eugene Tarassov <eugene.tarassov@xxxxxxxxxx>]

I agree with Christophe.
Passing PID/TID as a string allows the agent to choose best suitable parser/comparator for each debug context.
And there is no real need to parse the value on the client side.
Eugene

-----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


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.