X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WSadoqUPlI7KakU/5uH3om2YlW+f3+TPdMfOGlg5Rxk=; b=dekjVkszoP2/8goIlIomOCzIiLzulK9781YdN0L3/UU4v/EqxIo+kQWqfPUvB83dV7 10AsCDuTKH0T2bzmmuDD2jcjTnKNvr5awq4tfwPq7m5hEFxEGKlYfFabSHVL4mXfiuMo TggZ3sRFYl1u+arKI/Lhx1d2EjHlFqiVAZnpXHQiB08lqItDyusLuK6I7eEIMjt+JGpm ogmZseNRPDFiOEwKyq3dMJ8SRl/aUwrCP3N/EBaeGo1DAndaNvkdtXM24QbFXHnYtJND GX9cHpeTTY+HqcDg/4/S7Sdc3fcY1P/vFu5blTofy2ONcNRMciYiQPAFhssQP19v0DCF Omdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=WSadoqUPlI7KakU/5uH3om2YlW+f3+TPdMfOGlg5Rxk=; b=m/3O6QLjBVihkkoh7XZRn1M54K5B4vx/NW4xXcW53Y5MXbV/OWyP0GO9Q7kkVONcz3 9aov6wOYiPoyqMeBkuE41d/rvvQoYmy1zkxCCD/hRCXdXZMK4xr610CFTmTZqI6VcPMJ A08LwFvD+i1ZMLP+MKNfwYqNnFjx+tlNplFCznAzIHfe6jT1TVYODWWTQWjqARydHsHn stz+amSaBLePoESi/gurKOZv8VMk8nc9pU/LVLpnohXAI7Moe2CojMHQwyeY4Gd02ey4 FQZlwjit7zumneJnd/UhQP+PgwcPnHD34AQqX1NDb7zBF2dQ+mpFiEBcjddPB5LjJbVk a2jA== X-Gm-Message-State: AG10YOTs0UsygTVFQdWuBWYgwB5bvHCqhYe2sWL/l2ASdad4G04CWvBsBSa0B7f3RycFtxyfBFsotElD7VwFEg== MIME-Version: 1.0 X-Received: by 10.28.92.195 with SMTP id q186mr844414wmb.37.1454467419685; Tue, 02 Feb 2016 18:43:39 -0800 (PST) Date: Tue, 2 Feb 2016 17:43:39 -0900 Message-ID: Subject: [geda-user] Possible file format sample, questions, YAML vs JSON, etc. From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 Reply-To: geda-user AT delorie DOT com I got YAML emission going. Yay! Sort of. As I've said previously I'm intending to use something like this at least as part of an effort to communicate with Stefan's toporouter implementation and for my own scripts when I want to do more that just patsubst values. I don't intend to try to force it on anyone, but of course it would be gratifying if others found it useful, so I'm soliciting input. I'd also like to note that format questions are mostly orthogonal to data model questions, and I'm currently not trying to address the latter at all. A new format might help with incremental changes to the data model, since they could be expressed more easily and backward compatability at least with all scripts using the format interface could be guaranteed, but that's the extent of the connection. A sample of how it looks in .pcb and .ypcb form: http://brittonkerin.com/demo_files/foo.pcb http://brittonkerin.com/demo_files/foo.ypcb A couple things like unit output still have to be dropped into place but it gives the idea. As usual there are some dissapointments and tradeoffs discovered along the way. I'm open to input on how to handle these: * The current format imposes (largely arbitrary) orders on top-level and object field sets. Script language hashes don't, and tend to output YAML/JSON representations using a lexicographic order. This means that the order of fields as emitted by pcb is different that what a script spits back out. Options: 1. Don't care. There will be a huge false delta between a pcb-edited file and a script-modified one, but for any given project the last step before a commit is likely to be always one or the other anyway, and it's trivial to use either pcb (perhaps in batch mode) or a no-op script to force a particular representation. 2. Change pcb emission order to match the key sort order used by scripts. I don't know if different script modules all use the same order, though they probably do. 3. Emit everything as sequences of hashes of one element. This adds some noise to the format and makes for a map() hassle on the script language side to get as usable a data structure. * YAML eschews noisy superfluous [ { ", but for e.g. empty arrays a [] is required to avoid an ambiguity. This is easily managable if you know about it, but it bothers me because a gotcha like this does make the claim that life will get harder for people using e.g. sed somewhat true. JSON just brute-forces everything with always-present [{, so doesn't have this issue. * The state of the YAML community overall. The libyaml library is extremely clean, well documented and worked perfectly (on error handling too), but it's auther is MIA. The YAML list is disturbingly quiet: I got responses but not many. The small sample code bug I found on the web page didn't get fixed or draw a response when reported. * Script language coverage of YAML vs JSON. YAML coverage looks like this: http://www.yaml.org/ JSON coverage looks like this (scroll down): http://www.json.org/ What I've sadly concluded is that it would probably be better to go with JSON, like the rest of the world. If everyone wanted YAML instead for the cleanliness I could be convinced, since it's a much prettier effort overall IMO. I'm uncomfortable arguing for it given all the above, however. Switching to JSON would be easy. One question in this case is which JSON C library would be best to use. I looked through all the options and YAJL, cson, parson, and frozen all looked like reasonable candidates. I'd welcome input if anyone has experience with any of these.