On Thu, Mar 6, 2014 at 8:01 PM, Philippe Ombredanne <pombreda...@nexb.com> wrote: > 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.
Good point, yes, I agree. > > >>> 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. Indeed, I hadn't considered that. > >>> 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. Perfect, sounds good to me! I'll modify my GSoC proposal to reflect these changes, thank you! Thanks! zm ------------------------------------------------------------------------------ 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