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]" 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> <20160106133049 DOT 5A0E9809D79B AT turkos DOT aspodata DOT se> <20160106143629 DOT 4D39D809D79B AT turkos DOT aspodata DOT se> <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> <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> <20160109112851 DOT 1129dc38 AT wind DOT levalinux DOT org> In-Reply-To: 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 > ) [via 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 > ]"

> 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

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) [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.

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--