kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/25/2010 02:06 AM, Dick Hollenbeck wrote:
>   
>> Maybe another thing is to split it complete from the kicad core. So
>> create a real library written in ISO C++ so people who want to write
>> plugins and language bindings will be more happy than the hacked code
>> to read and write files in the current codebase. Because if you find
>> some software which can do something with the kicad file formats they
>> all write their own parsers/handlers and that is a bit of a pain to
>> keep the other people updated for the new upcomming file format(s).
>> Also if you dont use any existing library be used in your library like
>> wxwidgets it is portable to everywhere and also for people who want
>> something different than wxwidgets like Qt/Gtkmm etcetera. Than you
>> will see much more tools and utilities than now.
>>
>> Maybe you should have a look how dxflib and podofo pdf library. Then
>> are very powerfull libraries and very consistent with names and
>> classes. In my opionion this is a pre for a new file format
>> reader/writer.
>>
>> Kind regards,
>> Jerry Jacobs
>>
>>   
>>     
>
>
> I have also favored this idea for years, and it goes like this:
>
>
> PLAN A:
> ======
> Ideally, long term, the file 1) reading, 2) writing and 3) ram
> data-tree, could be done in a *.DLL/*.so file that is then dynamically
> linked to from upper UI code, even for the eeschema executable. 
>
> The shared foundation code (*.DLL/*.so) would avoid all UI code.  In
> fact if you had to link it against wxwidgets for anything but wxString,
> you probably missed the described design target.  Any need to
> communicate errors up to a UI layer could be done with exceptions, and
> those could be caught and dealt with in the main executable.
>
> To enforce this during the coding phase, I would probaby not even use
> wxString, just to avoid linking to wxWidgets at all.  Then at the end
> switch over to wxString once the DLL was known to be free of any UI
> code.  The transition would be done by a reassigned typedef or mapping
> class back to wxString.  I think to handle text in a way compatible
> between the two coding realms (UI-less library, and upper application),
> you have to have a common string class.
>
>
> There are a number of questions with this plan:
>
> 1) Written in C++, can you create a layer for each language binding to
> the languages that you want?  (I would not help write it in C, nor would
> I ever want anything to do with it if it were written in C.)
>
> 2) Does this expand the API to the point of huge, because you have to
> expose models of all objects contained in the data-tree for all
> supported languages.
>
> 3) Can you avoid C for the most part and still do the language bindings,
> limiting C's presence to very few source modules?
>
>
>
> On balance I think the problems that this PLAN A solves are getting
> smaller, and so we have to look back at the original problems and
> re-measure them in the face of the new file formats.  So let's talk
> about PLAN B.
>
>
>
> PLAN B:
> ======
> We recognize that with a new set of DSN grammars, we might as well be
> talking about something very analogous to XML, but nicer looking and
> with no distinction between elements and attributes.  Most languages
> deal best with XML on their own terms, they have parsers and data trees
> in the language, optimized for the language.  It would not be very hard
> to duplicate the generic functionality of DSNLEXER in say python or Java
> or Perl or Groovy.  In fact there will be a number of *.keywords files
> laying around that could be directly imported into a generic DSN
> lexer/parser written in a target scripting language.
>
> In summary, plan B is to push the work into each target scripting
> language, but with full recognition that with the new file formats this
> work is now *significantly* reduced and subject to much code sharing
> across the various grammars.  In some cases a common parser could be
> used to parse any DSN grammar, in the same way that an XML parser can
> parse any XML file without knowing the grammar.  It just creates a tree
> of named elements.  An element needs to hold a list of other elements
> and also of name value pairs.
>
> This is all made possible by gravitating to the DSN file format (with
> unique grammar per file purpose). 
>
> ============
>
> In summary, my current thinking is that the problem that PLAN A would
> have solved is now smaller with the new DSN formats.  So small in fact,
> that it is not worth the work to do PLAN A.  PLAN B becomes the path of
> lessor resistance and greater ultimate usability within the target
> scripting language.
>
> Having said that, there are some ideas under PLAN A above that could be
> used to write (rewrite?) the C++ classes, speaking now of the separation
> of UI code, without going all the way of creating a shared library out
> of them.
>
>
> Dick
>
>   


Seems that file format that we have been referring to as DSN for lack of
a better description, is being referred to as S-expressions by others.

Certainly there can be subtle variations on syntax, especially with
respect to quoted string handling, or embedded comments, but we seem to
be in good company in any case.


http://pypi.python.org/pypi/sexpy

actually here is the tar file:

http://pypi.python.org/packages/source/s/sexpy/sexpy-0.1.tar.gz#md5=af8bdee5946a190e20132701d3eeea32

This is one of 3 libraries that I have found for python.  This one uses
recursion, is class oriented, and throws exceptions on error with a line
number I believe.  So it meets the requirements I can think of it and at
first glance is the best of the 3 I've found, but this was not a
rigorous comparison.

Any one interested is invited to start running some tests using it.  I
wonder if it could load a large specctra SES or DSN file.

Most everything seems to be in parser.py

Dick