delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/09/14:33:12

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>
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">&lt;<a moz-do-not-send="true"
                href="mailto:geda-user AT delorie DOT com" target="_blank">geda-user AT delorie DOT com</a>&gt;</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>]"
                &lt;<a moz-do-not-send="true"
                  href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>&gt;
                wrote:<br>
                <br>
                &gt; The way to think about YAML/JSON is as portable
                text-based<br>
                &gt; serialization formats for the couple most popular
                datatypes that get<br>
                &gt; built into modern languages, in particular arrays,
                hashes, and scalar<br>
                &gt; values (basically numbers and strings).  JSON
                doesn't support native<br>
                &gt; (non-tree) references so you have to add your own
                id field if what<br>
                &gt; you want to refer to doesn't have already have a
                unique name.  YAML<br>
                &gt; does.  JSON is much more common but unfortunately
                also more noisy.<br>
                &gt; Some people like the noise because they don't trust
                any<br>
                &gt; 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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019