geda-developers team mailing list archive

[Dan McMahill <dan@xxxxxxxxxxxx>]

On 4/2/2012 2:03 PM, Andrew Poelstra wrote:
> 
> Hey all,
> 
> 
> This summer, if I have time, I'm thinking about writing a utility
> that can read/write all of pcb's file formats back to 2004 (or as
> far as seems feasible), convert between them, do compatibility
> checks, better syntax checks, etc.

The parser in pcb reads all formats already.  The writing code is in a
totally different file and always uses the newest.

> I have a few design goals:
> 
>   1. Have a separate parser/writer for each format version (using the
>      FileVersion[] field to decide which one when reading).

I'm fairly certain I added FileVersion[] in relatively recent history so
you can't rely on this.  In addition, pcb can actually read a file which
is mixed in format.   In other words, you can have a bunch of elements
defined where each uses a different format and pcb can read them.  This
actually isn't just a theoretical thing since it is somewhat common for
foot print libraries to have a mix of formats.


FWIW, the original intent I had for FileVersion was for pcb to be able
to detect that the file contains something which is too new for it to
read.  So for the last, I dunno, 5 years or so (random guess) each pcb
release knows about the newest FileVersion[] it can deal with.  So if
you use an old pcb to open a new file, you'll get a message saying
something like "this file was saved in a version of pcb which is too
new.  You need at least version X".  The question about if this is the
correct thing to do (as opposed to just dropping unknown things) is
perhaps open to debate, but this is what FileVersion[] was designed for.

You could, in theory write some code which can write out what ever the
newest format used by FileVersion == some version.  That would give you
the ability to at least partially save a design in a format that older
pcb's can read.  Be aware of course that data will almost certainly be lost.

>   3. Have a usable API so that other software (say, the web-interface
>      guy or maybe even pcb itself) can use it eventually.

that would be nice.  It would certainly be nice to have there more or
less be one true parser for .pcb files so that there is only one set of
code to maintain.  Also the documentation for the file format is
embedded in the parser code right now by way of specially formatted
comments.  That has gone a long ways towards keeping the manual accurate
and up to date.

>      
>   4. Be solid. Speed is not so much a concern. Things that ARE a concern:
>      reliability, code documentation, testing, proper memory usage.
>      For this reason, bison is probably unsuitable, but we'll see.
> 

bison seems to do fairly well in code documentation right now and I
don't know of memory issues.  The response to a garbage input or just an
unknown input could certainly be improved.


> As far as languages go, I'm looking at D. It is link-compatible with C,
> has a good OO model, has pre/post conditions built in, is very Doxygen
> friendly, and will manage memory for you. It has had a pretty unstable
> history, but it looks like version 2 is here to stay, and compilers are
> showing up in mainstream distributions.
>

While I *hate* "my language is more suited than yours" discussions
almost as much as "xml is better" discussions... how much will the use
of D be a barrier to users?  I'm thinking of the user without system
admin privs who just wants to download the code and compile it.  On any
sort of posix system there is likely to be a C compiler.  I'm guessing D
is almost always going to be an extra add on.  There is also the barrier
to code contribution.  I guess I'm saying that me personally, I'd rather
bring up the rear of language adoption.

> 
> Does anyone have thoughts or comments?

This could be a useful project.  You'll want to spend some time looking
both at the manual and the existing bison parser I think to fully
understand what the file format is.  Like I said, the mixed format means
FileVersion really doesn't quite do what you want.

Good luck!

-Dan

p.s. It has been long enough since I've contributed that you should
really only take my comments as providing historical context, not making
an sort of moving forward policy.