X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <5691606E.3070008@iee.org>
Date: Sat, 09 Jan 2016 19:33:02 +0000
From: "M. J. Everitt (m DOT j DOT everitt AT iee DOT org) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] (features: layers stack, padstack/vias)
References: <1512221837 DOT AA25291 AT ivan DOT Harhan DOT ORG> <CACwWb3CcsYJ9KgDFAa5pZqDzfTewhvbuatbxoKUp6PtHRCoa+w AT mail DOT gmail DOT com> <20160106133049 DOT 5A0E9809D79B AT turkos DOT aspodata DOT se> <CACwWb3Cyk4yLwt3=V1Mu5C4RieOQEjYH3ej5MXZSNnLPbshqDg AT mail DOT gmail DOT com> <20160106143629 DOT 4D39D809D79B AT turkos DOT aspodata DOT se> <CACwWb3BXbnQXs+DwVVzmC8DrhwOYxPgVyUhZTPL9bM9cJbHimw AT mail DOT gmail DOT com> <20160106164022 DOT D0D4E809D79B AT turkos DOT aspodata DOT se> <20160106180912 DOT 42ddf4079d91384f206b7c35 AT gmail DOT com> <20160106191433 DOT 5dc5cb59 AT jive DOT levalinux DOT org> <20160106202817 DOT 56197b2c539d426a1b724c9e AT gmail DOT com> <568E09ED DOT 1080508 AT m0n5t3r DOT info> <CACwWb3AhSh-+NNu--bVMGZBfjaoA+hHg7gbXnoyNv3oMq=e17g AT mail DOT gmail DOT com> <568E6354 DOT 80302 AT m0n5t3r DOT info> <20160108002640 DOT 03233b24 AT jive DOT levalinux DOT org> <20160108175259 DOT 127a3f073616758434f7edff AT gmail DOT com> <20160109020345 DOT 1e07cb84 AT jive> <CAC4O8c-nqs2+9rgsD-Gsks-wSmJ1eCkJ9PFMi3XqMrYE2FO3Ew AT mail DOT gmail DOT com> <20160109112851 DOT 1129dc38 AT wind DOT levalinux DOT org> <CAC4O8c_tFOOXCA5ABEMuSU8BnXMZWauV+uJYy-TJO7nJYBS9+A AT mail DOT gmail DOT com>
In-Reply-To: <CAC4O8c_tFOOXCA5ABEMuSU8BnXMZWauV+uJYy-TJO7nJYBS9+A@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------070504020702060308040104"
X-Provags-ID: V03:K0:4pD5dd36S/qIrQdpa1CyBRr0RUQ8C67B2usqpSmNkiKqZ4vLfJ+
aGA3LTwKoTsPUEjju8U8yCzvEUCrRyuTwBkNGQ1MqpbtMM4gR63ujVCDIEObBo+lZGH5/HG
471YICCPTijD9pv7KvvyQp3NpUAf3S5LkI7DQlwwQ/fBMf1WKm9Bjed2vclQkNN91dKJ2az
RmkRy3CPz8bZO9PPoBKfg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:26Nk4eAij+Y=:bcN1jkKSre7OtTPZtQS3qO
4hlHGK/pxrx+ihZsSsFOB5HY1xJrXRMx5C0ppTwsZund4BucVwG//RLkO7x6+HOB1PHkjqr2o
Za1zrg2UoTO9bKli44R1ui7HfSRwJK+hhJh4Jw8Ut6fOkdrnRkvHYQP0p4T+7VK20z2bHoiOg
SnqT4m0P085zY2KTB8LRLqISS5B7r1ArIUq3R2ir6FxFnprgNO3DGsTuDAGJ9LPDRZscNWqSG
vR2W2QVd3yG0asSjgc+zYTob5edCV3aRV2noHNTglHeqHsHpGDQ+/LfhJqXT0TVpziwVw+bhP
Fj1ep7ik8AV1/TInAhqJiEKQ6fFujvMvKLm2HuQIWiQW/ypNZ7bfeADKmGXPg/WFBiI8XF0IL
0sTI89P/XT/MHWUB/Tql2SQX76cofiMfbPEhQLA1NQ9htinDAPSah20C533xA6ft5jwrY/KLF
NRA/1EPfzzHPaOUq/S7OET+IeuVdL3BT1Ro3yqY2wdompqPIRRIl7Ge59wjmpXMSC93ZEYT1w
ha3iRIw7/jFrBkjwMjksDLRCxvEqqwskaetzsp8wXSBomq+kRgBzkUfNBLFU5g3itMSR/Fpoi
sI0f30CD8THDCT23RZdufrT8IOukTMxGFAKxFIh/HhJUEn+SAf4SrMFt9UwohKjO4lJt3PqS6
GxyHvCzTwy9xWlkwRE6qWaMfkgIOnZ8OUv9QGVhYwbVdv6rsWYU/916bpnDAdgurdDwtIxjKK
9I+fgoNtSD4HEjzY
Reply-To: geda-user AT delorie DOT com
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--