Hi,
On 21.12.2015 08:35, Lorenzo Marcantonio wrote:
> After this I'm *not* advocating a binary format, there would be no
> advantage for it in pcbnew. There are no performance restraints in
> either speed or space for kicad files so just use whatever is easier for
> you to manage (i.e.
Hi David
This discussion about binary formats was just a side comment from
someone, this is off topic. Please use your energy on something
usefull, like commenting on Roszko's patch instead. Which is about
making am more sane sexpr parser than we have in KiCad at the moment.
Please try to be
Hi,
I don't often post here, but I will add my ~30 years of experience
with binary file formats.
THEY ARE EVIL EVIL THINGS !!
They tend to be extremely fragile, any change and something is
likely to break.
They require parsers that suck to
On Fri, Dec 18, 2015 at 12:00:58AM -0500, Mark Roszko wrote:
> is just extremely silly and extra work compared to generate SEXPR
> trees in memory like SEXPR represents in the first place. God forbid
> you accidentally format that double wrong.
D'oh you actually want a full in-memory tree
On Thu, Dec 17, 2015 at 11:49:31PM -0500, Chris Pavlina wrote:
> Dude. The way it's stored currently is horrible - it's not congruent to
> the structure of the file! The s-expr file is supposed to be a tree
> structure, why is the binary data stored broken into multiple objects
> like that?
On Thu, Dec 17, 2015 at 10:32:10PM -0500, Mark Roszko wrote:
> So awhile back, Wayne said to use sexpr for something I wanted to do.
> Then I looked at the sexpr parsing and said NOPE.
OK, being a lisper and having read the dragon book here's my view on the
subject:
1) the parser isn't actually
>You take the BNF form, process it and write the corresponding state machine.
>It's not VB6, it's a state machine :D
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
On Fri, Dec 18, 2015 at 07:55:07AM -0500, 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
On Fri, Dec 18, 2015 at 3:49 PM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:
> On 18.12.2015 15:46, Edwin van den Oetelaar wrote:
> > Concerning changing the format of the PCB file again...
> > Making a new binary file format is a big NO NO NO (screaming) in my book.
>
> Hi Edwin,
>
>
On Fri, Dec 18, 2015 at 10:40:44AM -0500, Mark Roszko wrote:
> Simply trying to make parsing simple and easy of sexpr. No file format
> change required.
Still keep proposing mandatory quotes for strings :D completely backward
compatible.
> Yes we need a parser especially with some of our
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
On 18.12.2015 15:46, Edwin van den Oetelaar wrote:
> Concerning changing the format of the PCB file again...
> Making a new binary file format is a big NO NO NO (screaming) in my book.
Hi Edwin,
Don't worry, we are not going to change the format :)
> I want to be able to edit it with VIM if
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
So any actual comments on what I did in the commit I linked originally
in the first email?
>Still keep proposing mandatory quotes for strings :D completely backward
compatible.
Well yeamy generator class does that all the time. Unless you
define a symbol explicitly, all strings are always
O god, your email is just going to start a chain of rage about
changing the format.
Not trying to do that folks, please rage in another thread if you want
to reply to him on that.
Simply trying to make parsing simple and easy of sexpr. No file format
change required.
> Our s-expr format needs
Mark,
I haven't had time to look at your commit so I'm not going to comment on
that until I do. I don't know when I'll have time as I have a lot of
stuff to do and I'm traveling over the holidays so my review time will
be limited. In the mean time I will comment on some of the things I've
read
I just saw this:
http://i.imgur.com/H8VxD3Z.png
storing a bitmap as hex values.
Next proposal item to add: storing binary data(bitmaps) as base64
quoted strings like every other browser, application and tool.
___
Mailing list:
Dude. The way it's stored currently is horrible - it's not congruent to
the structure of the file! The s-expr file is supposed to be a tree
structure, why is the binary data stored broken into multiple objects
like that? It's yet another facet of the parsing nightmare we have.
If you're going
>Not disagreeing with you on this one, but I would have to question why...
Did you skip the why section?
Because we are supposed to have a standard file parser and reader that
is maintainable. What there is a micro-optimization obsessed VB6
parser. There's a keyword enum pre-generation that
Ok. I see. Sorry for the noise.
Not sure how storing base64 would help.
Namely file size savings and sanity. Instead of all those ridiculous X
number of hex bytes on each line split with spaces, you have a single
quoted entry that's a base64ed.
And you can actually manually edit that, god
It's not the base64 that's important, it's the structure. You can pick
whatever encoding you like, base64 is just very common as a relatively
dense but still text-safe one.
On Fri, Dec 18, 2015 at 12:06:25AM -0500, tiger12506 wrote:
> Ok. I see. Sorry for the noise.
>
>
> Not sure how storing
21 matches
Mail list logo
