On Tue, Mar 4, 2014 at 1:59 PM, Zubin Mithra <zubin.mit...@gmail.com> wrote:
> Hey Philippe,
>
>> Just curious, why would you use call_one? and arg1,arg2 v.s using lists?
>
> I was just wondering if information related to the call sequence might
> be useful. In quite a few languages, JSON data directly maps to
> dictionary representations(eg:- Python) -- but upon doing that we'd
> lose information about the sequence in which the calls occurred once
> we create a dictionary from the JSON. In such cases having explicit
> information about the order might be useful.
JSON is a spec so you should not care about how it is interpreted in a
given language.
JSON has arrays that are ordered lists and objects that are unordered
name/value mappings.
So when you need an ordered sequence, use an array, please do not make
up a map name to track ordering.
If you have name/values mapping and need ordering, wrap that in an array.
>> FWIW the above would not be valid JSON.
>> What about something like:
>> [
>> {"fnname": "open",
>> "args": ["/usr/lib/locale/UTF-8/LC_CTYPE", "O_RDONLY|O_CLOEXEC"],
>> "ret": "-1"
>> }
>> ]
>
> Cool stuff, thank you!
>
>>
>> or possibly (not sure which form I like best) using a more compact
>> entirely and positional list of lists:
>> [
>> "open",
>> "-1",
>> [
>> "/usr/lib/locale/UTF-8/LC_CTYPE",
>> "O_RDONLY|O_CLOEXEC"
>> ]
>> ]
>>
>>> Of course, this above example is oversimplified(And I'm not sure thats
>>> the best way to manage quoting to be honest, I'll put in some more
>>> thought).
>
> I think I like the first one better, I think it looks cleaner(open to
> suggestions of course!).
I do not know which one is better yet but a simpler array without
made-up names when they do not exist feels much cleaner and less
verbose to me, and does not affect the structure nor the readability.
Being somewhat compact is not something nice to have but a feature
when tracing IMHO both in terms of time and space.
>> I think that in the case of a JSON output, double quoting paths would
>> not be desirable and paths should be returned a simple JSON string
>
> Cool stuff, makes sense.
>
>>
>>> In cases where a struct is passed as an argument, as in the case of a
>>> bind call we have,
>>> bind(3, {sa_family=AF_INET, sin_port=htons(7171),
>>> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
>>>
>>> We could have "arg2" set to "{sa_family=AF_INET, sin_port=htons(7171),
>>> sin_addr=inet_addr("0.0.0.0")}" but I feel it defeats the purpose as
>>> parsing output itself would be more painful. Perhaps something like
>>> the following would be nice.
>>>
>>> {
>>> "call_thirteen" : {
>>> "fnname" = "bind",
>>> "arg1" = "3",
>>> "arg2" : {
>>> "sa_family" : "AF_INET",
>>> "sin_port" : "htons(7171)",
>>> "sin_addr" : "inet_addr("0.0.0.0")"
>>> },
>>> "ret" = "-1"
>>> }
>>> }
>>
>> This makes sense but same comment as above: why not using a combo of
>> objects and arrays (using JSON speak)?
>> and why not structuring everything that can be?
>> ie something along these lines?
>> [
>> {
>> "fnname": "bind",
>> "args": [
>> "3",
>> {
>> "sa_family": "AF_INET",
>> "sin_port": {
>> "htons": "7171"
>> },
>> "sin_addr": {
>> "inet_addr": "0.0.0.0"
>> }
>> }
>> ],
>> "ret": "-1"
>> }
>> ]
>
> If the call information being added makes sense, it would look
> something as follows, I believe :-
>
> '{"call_one": [{"fnname": "bind", "ret": "-1", "args": ["3",
> {"sin_port": {"htons": "7171"}, "sin_addr": {"inet_addr": "0.0.0.0"},
> "sa_family": "AF_INET"}]}]}'
As I said above adding call_one does not make sense and is rather
ugly. Use arrays/list not maps/objects for sequences.
The top level construct should therefore be a list [] not a map.
Where you need a sequence, use a list. And use a map only when needed.
Do not make up names.
--
Philippe Ombredanne
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
