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. -- Mailing list: https://launchpad.net/~geda-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~geda-developers More help : https://help.launchpad.net/ListHelp
