kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/08/2014 02:44 AM, Lorenzo Marcantonio wrote:
> On Thu, May 08, 2014 at 02:12:59AM -0500, Dick Hollenbeck wrote:
>> But again, working from the property_tree directly is suitable for only a minority of
>> situations, and when its not suitable, this means copying.  But either copying or
>> navigating the property tree are both way slower than what we are doing now.
> 
> You just expressed properly what I meant with 'uneasy' in my previous
> post. C++ just is not designed to work this way IMHO
> 


Not sure why you think the discussion pertains to the programming language.  python, Java,
C++, C all have both SAX and DOM parsers for XML.  XML is a noisy s-expression basically.

The discussion also does not involve garbage collection.  Don't know why that enters into
it.  If the most useful data structure to your program is a struct or class consisting of
integers, strings and floats, then having a tree that is pure text fields is not optimal.

Try using fp-lib-table.for-eagle

in its entirety sometime.  Loading all the footprints in the eagle library takes way more
than what we get hit with using recursive descent (analogous to SAX).  Some of that is
because XML is noisier than s-expression, so the signal to noise ratio is lower in XML.
But the lion's share is because the SAX type parser is faster than the DOM type (used in
the eagle_plugin).

You can relax the grammer in the parser, that is another technique.  But trying to
anticipate future needs because you don't want to run the compiler seems goofey to me.

If being able to upgrade for free is not good enough, maybe you can negotiate with future
developers that they will have to pay you any time you have to upgrade.  Would that then
be fair?

The whole discussion seems silly to me.  We already have *backwards* compatibility, and
always have had.  That is important.  Future proofing will only tie the hands of
developers, and you don't want to do that.  Of course if it really bothers somebody
enough, they can submit the last patch KiCad will ever need, at any time, and it will
likely get accepted.





> And you simply can't compare the property trees in wx/whatever with
> a cons-based structure...really different things (also: C++ doesn't have
> a good GC)
>