Mail Archives: geda-user/2016/01/09/14:33:12
This is a multi-part message in MIME format.
--------------070504020702060308040104
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
On 09/01/16 19:14, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
>
>
> On Sat, Jan 9, 2016 at 1:28 AM, Kovacs Levente (leventelist AT gmail DOT com
> <mailto:leventelist AT gmail DOT com>) [via geda-user AT delorie DOT com
> <mailto:geda-user AT delorie DOT com>] <geda-user AT delorie DOT com
> <mailto: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
> <mailto:britton DOT kerin AT gmail DOT com>) [via geda-user AT delorie DOT com
> <mailto:geda-user AT delorie DOT com>]" <geda-user AT delorie DOT com
> <mailto: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.
Sounds like a plan to me!
>
>
> 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
>
Modular code is always good .. and makes easy to rip-apart/re-write/add
bits as appropriate.
MJE
--------------070504020702060308040104
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 09/01/16 19:14, Britton Kerin
(<a class="moz-txt-link-abbreviated" href="mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>) [via <a class="moz-txt-link-abbreviated" href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wrote:<br>
</div>
<blockquote
cite="mid:CAC4O8c_tFOOXCA5ABEMuSU8BnXMZWauV+uJYy-TJO7nJYBS9+A AT mail DOT gmail DOT com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Jan 9, 2016 at 1:28 AM,
Kovacs Levente (<a moz-do-not-send="true"
href="mailto:leventelist AT gmail DOT com">leventelist AT gmail DOT com</a>)
[via <a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com" target="_blank">geda-user AT delorie DOT com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On Fri, 8 Jan 2016 20:15:24 -0900<br>
"Britton Kerin (<a moz-do-not-send="true"
href="mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>)
[via <a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]"
<<a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user 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<br>
> built into modern languages, in particular arrays,
hashes, and scalar<br>
> values (basically numbers and strings). 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. YAML<br>
> does. 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/from<br>
either YAML or SQL. It might be double work, but we can
make performance tests<br>
at the end.<br>
<br>
So could we first think about an API? So we might work
together parallel. For<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="">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.</div>
<div style=""><br>
</div>
<div style="">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. <br>
</div>
</div>
</div>
</div>
</blockquote>
Sounds like a plan to me!<br>
<blockquote
cite="mid:CAC4O8c_tFOOXCA5ABEMuSU8BnXMZWauV+uJYy-TJO7nJYBS9+A AT mail DOT gmail DOT com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Â </div>
<blockquote class="gmail_quote" style="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 pcb.<br>
For example, the gerber exporter would be a separate piece
of program (using<br>
shared libraries).<br>
</blockquote>
<div><br>
</div>
<div style="">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.</div>
<div>Â </div>
<div style="">Britton</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
Modular code is always good .. and makes easy to
rip-apart/re-write/add bits as appropriate.<br>
<br>
MJE<br>
</body>
</html>
--------------070504020702060308040104--
- Raw text -