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:	<CAC4O8c_-VaWshx+kQt4tse3DU2V=73OV-G+thwKabgW9cGt7TQ@mail.gmail.com>
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]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
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.

- Raw text -