Mail Archives: geda-user/2016/01/09/14:14:25
--047d7b5d497668705c0528eb824c
Content-Type: text/plain; charset=UTF-8
On Sat, Jan 9, 2016 at 1:28 AM, Kovacs Levente (leventelist AT gmail DOT com) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> On Fri, 8 Jan 2016 20:15:24 -0900
> "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <
> geda-user AT delorie DOT com> wrote:
>
> > The way to think about YAML/JSON is as portable text-based
> > serialization formats for the couple most popular datatypes that get
> > built into modern languages, in particular arrays, hashes, and scalar
> > values (basically numbers and strings). JSON doesn't support native
> > (non-tree) references so you have to add your own id field if what
> > you want to refer to doesn't have already have a unique name. YAML
> > does. JSON is much more common but unfortunately also more noisy.
> > Some people like the noise because they don't trust any
> > whitespace-based approach (bad experiences with make).
>
> Ok. I try to express my data model in YAML. The only problem is that I
> don't
> have any experience in YAML, but hopefully I catch up some in the weekend.
>
> Then we might write a library that is able to read write gpcb object
> to/from
> either YAML or SQL. It might be double work, but we can make performance
> tests
> at the end.
>
> So could we first think about an API? So we might work together parallel.
> For
> example, you implement the API in current pcb, and I write the file
> handler?
>
> I think the first step would be to implement the current capability of pcb,
> and later, when the infrastructure is there, we can fiddle with the GUI and
> other logic.
>
Yes. First the existing parser needs to get separated from the innards of
pcb. As things stand now there's no single data structure that corresponds
one-to-one with the format. Once this is done other equivalent formats
could be implemented.
People are understandably skeptical about whether something like this will
be useful, so it shouldn't be viewed as *the* pcb format. It's just going
to be something pcb can export and read.
> Another idea came in my mind to separate the exporter HIDs from the main
> pcb.
> For example, the gerber exporter would be a separate piece of program
> (using
> shared libraries).
>
I haven't looked at how export works yet so I don't know about this. But I
think there's some consensus that moving things like this from apps (pcb,
gschem) to libgeda is generally a good idea.
Britton
--047d7b5d497668705c0528eb824c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jan 9, 2016 at 1:28 AM, Kovacs Levente (<a href=3D"mailto:leven=
telist AT gmail DOT com">leventelist AT gmail DOT com</a>) [via <a href=3D"mailto:geda-us=
er AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"><<a href=3D=
"mailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Fri=
, 8 Jan 2016 20:15:24 -0900<br>
"Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gmail DOT com">britton.ker=
in AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT d=
elorie.com</a>]" <<a href=3D"mailto:geda-user AT delorie DOT com">geda-use=
r AT delorie DOT com</a>> wrote:<br>
<br>
> The way to think about YAML/JSON is as portable text-based<br>
> serialization formats for the couple most popular datatypes that get<b=
r>
> built into modern languages, in particular arrays, hashes, and scalar<=
br>
> values (basically numbers and strings).=C2=A0 JSON doesn't support=
native<br>
> (non-tree) references so you have to add your own id field if what<br>
> you want to refer to doesn't have already have a unique name.=C2=
=A0 YAML<br>
> does.=C2=A0 JSON is much more common but unfortunately also more noisy=
.<br>
> Some people like the noise because they don't trust any<br>
> whitespace-based approach (bad experiences with make).<br>
<br>
</span>Ok. I try to express my data model in YAML. The only problem is that=
I don't<br>
have any experience in YAML, but hopefully I catch up some in the weekend.<=
br>
<br>
Then we might write a library that is able to read write gpcb object to/fro=
m<br>
either YAML or SQL. It might be double work, but we can make performance te=
sts<br>
at the end.<br>
<br>
So could we first think about an API? So we might work together parallel. F=
or<br>
example, you implement the API in current pcb, and I write the file handler=
?<br>
<br>
I think the first step would be to implement the current capability of pcb,=
<br>
and later, when the infrastructure is there, we can fiddle with the GUI and=
<br>
other logic.<br></blockquote><div><br></div><div style=3D"">Yes.=C2=A0 Firs=
t the existing parser needs to get separated from the innards of pcb.=C2=A0=
As things stand now there's no single data structure that corresponds =
one-to-one with the format.=C2=A0 Once this is done other equivalent format=
s could be implemented.</div><div style=3D""><br></div><div style=3D"">Peop=
le are understandably skeptical about whether something like this will be u=
seful, so it shouldn't be viewed as *the* pcb format.=C2=A0 It's ju=
st going to be something pcb can export and read.=C2=A0</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
Another idea came in my mind to separate the exporter HIDs from the main pc=
b.<br>
For example, the gerber exporter would be a separate piece of program (usin=
g<br>
shared libraries).<br></blockquote><div><br></div><div style=3D"">I haven&#=
39;t looked at how export works yet so I don't know about this.=C2=A0 B=
ut I think there's some consensus that moving things like this from app=
s (pcb, gschem) to libgeda is generally a good idea.</div><div>=C2=A0</div>=
<div style=3D"">Britton</div><div><br></div></div></div></div>
--047d7b5d497668705c0528eb824c--
- Raw text -