X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <56934B59.8040500@iee.org>
Date: Mon, 11 Jan 2016 06:27:37 +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] A new PCB file format - modular system
References: <5692CBD5 DOT 3020101 AT prochac DOT sk> <CAC4O8c8iQnuy2L8QG=absBhnUTuVRj-jJyVNhoqeSiPmiT0gWw AT mail DOT gmail DOT com>
In-Reply-To: <CAC4O8c8iQnuy2L8QG=absBhnUTuVRj-jJyVNhoqeSiPmiT0gWw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------080103070207030304080008"
X-Provags-ID: V03:K0:Zt9ouakCiic1VxDmFemrlGWBOUDL26QQAYByw4f4zGbv8bhsK0+
 lcXozRDZ/CyJil5b8j+xk5z+8+GWw+cEQx2On/ldAn8g22oUkrPsmQHBG4TsCy5I/VVY8Me
 GUys0n6Az/U2C4UPJupIrrOS/qk20KRP2B45sQKjKZ+wFbMf25xAjSm4kEp9b7uHZUuFVWn
 Lc4jwwZXXh1jvC9OIuPiA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:47w8H2dS56o=:ltCNf7wI4UF/xcLH43mwjG
 5uPfRdG7jqRunUL8tvGHYsdrjVaL/RRixXiPh1NMOS4u8nWun2tWCEIe4xtzXXADaGB8gmHWl
 IF3nCyNvkxq8olI0+oOvbMVdjJRz5nKQMBZ4/NSlxXkrOaIJd6HTAMkr5pxraAa1/wHilQei9
 jwx8rE6HGvbkRbGFB0Z5QbPvjOxjUFpB2fTT36uwPIDcdAkhdPvP6jR6yA2zODq8JC1PeLhjS
 E/xmS6U/SwYusHIocoqNi8X7LfVW1jo+xkJsq0Pfm5N8to4Nuy4upjC1OZIWJkfRDKOYN5EGD
 cityWXKkO/dFb6/Tqb/UfLYD2HCjg/W0D+XoYM7/nlKt/I3YlHI9Orhai2FEG7Gj9AQsJ4MWZ
 WW8/3LkTMuwadPEFypurdlSHkw52DfQNfu3Y068pbM45fufZaOWcfUxjU4TSa4qJailphveHx
 M79KKXPEcvs2F/dlpTfPmxA9hRNT7hSN9jaLWjWDdyvBxj+tbookyxVVeAa2RH+DsEUTe6pbh
 Kvkf6ZHND0P9kMfAwrwC0ko1p05I2hiPhEDeDHjlDDcp/sVnQYy1+1qNNzUeAgxpps2DPhVIp
 HRzc/qU8knosQoSOlx8WSjt57dHdx3JskX4OYvl5BquwLvG5+cYQiDXrDHnO6WIUcXp3Kn4ib
 HL5wsH6SmDXGwTRJIfNQN/NtbpczjRNodqs8kn/+3B0/+NoThDZpativ/JqDgVs8OEDccI0MS
 Z+sBdhnW+BoeJLIA
Reply-To: geda-user AT delorie DOT com

This is a multi-part message in MIME format.
--------------080103070207030304080008
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


On 10/01/16 23:05, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] wrote:
>
> On Sun, Jan 10, 2016 at 12:23 PM, Milan Prochac (milan AT prochac DOT sk
> <mailto:milan AT prochac DOT sk>) [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:
>
>     After reading long discussions about the new PCB file format I
>     tried to implement support for multiple file  formats.
>
>     You can download it here:
>     http://static.bastl.sk/pcb/Modular-file-formats.gz It is also
>     available on launchpad: https://bugs.launchpad.net/pcb/+bug/1532611
>
>     The patch implements modular system to support multiple PCB file
>     formats. Attached is also the template of the file-format plugin
>     with instructions.
>
>     The patch is not too big, but it touches various parts of PCB, so
>     it is possible that some corner cases are not handled properly.
>     Comments and bug reports are welcome.
>
>     The modular system utilizes existing plugin system; new type of
>     plugin is added to support various file formats. This approach
>     allows implementation of additional file formats as independent
>     shared library with minimal effort. The whole implementation of
>     new file format is reduced to serialization and de-serialization
>     of PCBType data structure, no PCB tweaking is necessary. The
>     template with instructions is provided, as mentioned above.
>
>     - modular system is available for all layout operations (Load,
>     Save, Save As, Load to buffer, Revert, auto-backup); the element
>     operations will be added later.
>     - action "SaveTo(LayoutAs..." was extended by 3rd argument,
>     specifying file format; if omitted, current (or default) format is
>     used
>     - GUI (GTK only at the moment) was adjusted to allow select file
>     format; for "save" operations it specifies desired format, for
>     "open" operations it is used as filter
>     - file format is detected automatically by modular framework
>     - the versioning system (based on PCB file version #defines) is
>     available - each plugin should confirm it's capability to save
>     data of required version (like 20110603); if not, the file format
>     cannot be used
>     - load-only and save-only formats are supported. If save-only
>     format is used, the layout is not marked as "saved".
>     - the current PCB format is converted to built-in plugin.
>
>     With this enhancement it should be very easy to implement new file
>     formats. If more of them will be available, the most successful
>     can become new standard PCB format and - hopefully -  the data
>     model modifications will be not blocked by hard-to-extend file
>     format anymore...
>
>
> Wow seems really promising.  What surprises me is that it looks like
> you were able to do everything with PCBType.  I don't remember the
> gruesome details now but last time I tried to make the existing parser
> work independent of pcb I ended up with the impression that PCBType
> didn't reflect everything that goes in pcb files -- close but not
> quite everything.  IIRC this manifested as seg faults from global
> (non-PCBType) data that wasn't  ready for the parser to stuff things
> into it when the parser ran out of pcb main() context.  Maybe it
> doesn't matter with the plugin approach you're using, I'm not sure. 
> But I would caution that PCBType might not reflect everything.
>
> Do you have a git account yet?  I'd really like to get this into git
> and start playing with it ASAP but it should probably go in your git
> home at the moment since you're likely to want to tweak it more.
>
> Britton
>
>  
>
>
>     Regards
>     Milan
>
>
I have to add my "well done and thanks"  to Milan's efforts. As Britton
says, it would be good to let this into the hands of the
alpha-tester-developers so we can see how it works, and poke it to see
if it breaks, and if there are indeed any limitations.

I'm a little intrigued as to how the geda development workflow is
operating, as I see lots of references to 'home's which should be
accessible forks of the main git repo (which is, of course, perfectly
possible via git). Is there any gitweb or other front-end where anyone
can easily make a comparison between user forks (and their respective
development branches) and merge into their own forks to evaluate? Or is
this presently just done via git command-line or personal utility
scripts, etc.

Because I'm currently limited to the tarballs of releases, I don't
presently have access to some of the "new" "features" you guys are
referring to, and it's my intention to fix a special "ebuild" for gentoo
soon(tm) to clone the main git repo for users to get "bleeding-edge"
(although, by the sounds of it .. not-very-bleeding, and not-very-edge)
copies of the project to play with.

I certainly look forward to seeing what you guys are up to, and testing
it with some of the projects I'm working on too.
Regards,

Michael.

--------------080103070207030304080008
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 10/01/16 23:05, 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:CAC4O8c8iQnuy2L8QG=absBhnUTuVRj-jJyVNhoqeSiPmiT0gWw AT mail DOT gmail DOT com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div class="gmail_extra">
          <div class="gmail_quote">On Sun, Jan 10, 2016 at 12:23 PM,
            Milan Prochac (<a moz-do-not-send="true"
              href="mailto:milan AT prochac DOT sk">milan AT prochac DOT sk</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:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">After
              reading long discussions about the new PCB file format I
              tried to implement support for multiple file  formats.<br>
              <br>
              You can download it here: <a moz-do-not-send="true"
                href="http://static.bastl.sk/pcb/Modular-file-formats.gz"
                rel="noreferrer" target="_blank">http://static.bastl.sk/pcb/Modular-file-formats.gz</a>
              It is also available on launchpad: <a
                moz-do-not-send="true"
                href="https://bugs.launchpad.net/pcb/+bug/1532611"
                rel="noreferrer" target="_blank">https://bugs.launchpad.net/pcb/+bug/1532611</a><br>
              <br>
              The patch implements modular system to support multiple
              PCB file formats. Attached is also the template of the
              file-format plugin with instructions.<br>
              <br>
              The patch is not too big, but it touches various parts of
              PCB, so it is possible that some corner cases are not
              handled properly. Comments and bug reports are welcome.<br>
              <br>
              The modular system utilizes existing plugin system; new
              type of plugin is added to support various file formats.
              This approach allows implementation of additional file
              formats as independent shared library with minimal effort.
              The whole implementation of new file format is reduced to
              serialization and de-serialization of PCBType data
              structure, no PCB tweaking is necessary. The template with
              instructions is provided, as mentioned above.<br>
              <br>
              - modular system is available for all layout operations
              (Load, Save, Save As, Load to buffer, Revert,
              auto-backup); the element operations will be added later.<br>
              - action "SaveTo(LayoutAs..." was extended by 3rd
              argument, specifying file format; if omitted, current (or
              default) format is used<br>
              - GUI (GTK only at the moment) was adjusted to allow
              select file format; for "save" operations it specifies
              desired format, for "open" operations it is used as filter<br>
              - file format is detected automatically by modular
              framework<br>
              - the versioning system (based on PCB file version
              #defines) is available - each plugin should confirm it's
              capability to save data of required version (like
              20110603); if not, the file format cannot be used<br>
              - load-only and save-only formats are supported. If
              save-only format is used, the layout is not marked as
              "saved".<br>
              - the current PCB format is converted to built-in plugin.<br>
              <br>
              With this enhancement it should be very easy to implement
              new file formats. If more of them will be available, the
              most successful can become new standard PCB format and -
              hopefully -  the data model modifications will be not
              blocked by hard-to-extend file format anymore...<br>
            </blockquote>
            <div><br>
            </div>
            <div>
              <div>Wow seems really promising.  What surprises me is
                that it looks like you were able to do everything with
                PCBType.  I don't remember the gruesome details now but
                last time I tried to make the existing parser work
                independent of pcb I ended up with the impression that
                PCBType didn't reflect everything that goes in pcb files
                -- close but not quite everything.  IIRC this manifested
                as seg faults from global (non-PCBType) data that wasn't
                 ready for the parser to stuff things into it when the
                parser ran out of pcb main() context.  Maybe it doesn't
                matter with the plugin approach you're using, I'm not
                sure.  But I would caution that PCBType might not
                reflect everything.</div>
              <div><br>
              </div>
              <div>Do you have a git account yet?  I'd really like to
                get this into git and start playing with it ASAP but it
                should probably go in your git home at the moment since
                you're likely to want to tweak it more.</div>
              <div><br>
              </div>
              <div>Britton</div>
            </div>
            <div><br>
            </div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
              Regards<span class=""><font color="#888888"><br>
                  Milan<br>
                </font></span></blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    I have to add my "well done and thanks"  to Milan's efforts. As
    Britton says, it would be good to let this into the hands of the
    alpha-tester-developers so we can see how it works, and poke it to
    see if it breaks, and if there are indeed any limitations.<br>
    <br>
    I'm a little intrigued as to how the geda development workflow is
    operating, as I see lots of references to 'home's which should be
    accessible forks of the main git repo (which is, of course,
    perfectly possible via git). Is there any gitweb or other front-end
    where anyone can easily make a comparison between user forks (and
    their respective development branches) and merge into their own
    forks to evaluate? Or is this presently just done via git
    command-line or personal utility scripts, etc.<br>
    <br>
    Because I'm currently limited to the tarballs of releases, I don't
    presently have access to some of the "new" "features" you guys are
    referring to, and it's my intention to fix a special "ebuild" for
    gentoo soon(tm) to clone the main git repo for users to get
    "bleeding-edge" (although, by the sounds of it .. not-very-bleeding,
    and not-very-edge) copies of the project to play with.<br>
    <br>
    I certainly look forward to seeing what you guys are up to, and
    testing it with some of the projects I'm working on too.<br>
    Regards,<br>
    <br>
    Michael.<br>
  </body>
</html>

--------------080103070207030304080008--