kicad-developers team mailing list archive

[Edwin van den Oetelaar <oetelaar.automatisering@xxxxxxxxx>]

Concerning changing the format of the PCB file again...

Just my $0.02 ...

I have been lurking on this list for years now...

Making a new binary file format is a big NO NO NO (screaming) in my book.

I want to be able to edit it with VIM if needed.
I personally do not care if the format is s-expression or Json or XML as
long as it can be read and changed by humans and text editors and parsers.
This was one of the reasons to leave all these proprietary binary formats
behind and start using KiCad.
I see no reason why parsing a text based format can not work, possibly it
is less work to fix any issues than to start all over again with yet
another file format
(like there are not enough file formats in the PCB industry already)

Just make the thing work as designed now, do not start another project
which brings nothing but trouble.

Thanks for listening,
Edwin van den Oetelaar




On Fri, Dec 18, 2015 at 3:23 PM, Tomasz Wlostowski <
tomasz.wlostowski@xxxxxxx> wrote:
>
> On 18.12.2015 13:55, Mark Roszko wrote:
> > Writing a new state machine for every single list and every single
> > file over and over again is the part I have problems with. There
> > should be a single state machine that takes the tokens and gives you a
> > list. Not 500 over the whole codebase.
>
> Hi Mark,
>
> May I add my 5 cents to this discussion...
>
> - My only big concern with the current parser so far is the lexer code
> generation done by CMake. I'm not a big fan of making scripts that
> produce code which then gets compiled...
>
> Anyway, since we got here, I have a devilish idea: why a text format at
> all? Of course we are not going to change the format again (we have a
> lot of more exciting things to do ;-), but to point out a few reasons:
>
> - PCB files (as opposed to netlists) represent graphical objects. For
> someone looking at a PCB file with a text editor, it's just meaningless
> numbers. Diffs look equally horrible (just look at a diff between two
> .kicad_pcb files after moving a couple of traces in P&S mode).
>
> - binary formats are generally easier to parse (unless someone made it
> deliberately difficult - but it's not our case). We could just serialize
> objects directly to a binary file, along with some version info (think
> of Google's protobuf). This would also let us implement introspection
> (e.g. a property editor tool) for no extra cost.
>
> - Our s-expr format needs a custom parser (correct me if I'm wrong),
> which contradicts the idea that generic text formats (e.g. json/lisp
> s-expr, even lua/python arrays) need no dedicated parsers.
>
> - Last but not least (and surely not least controversial): file format
> that is easy to hand-edit enables people to hack scripts that do stuff
> that Kicad is currently missing. This is an advantage for some (perhaps
> more advanced) users who can work around missing features this way, but
> is it really beneficial for Kicad as a complete PCB design tool? If the
> easiest way is to hack a PCB file with a perl script/text editor, what
> motivation is left to implement the missing feature in Kicad?
>
> Cheers,
> Tom
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp