Blog on Sweet parser: I am as excited as ever about this work. The next two weekends I will be mostly tied up and you will not see a lot of progress.
Roadmap: I am toying with the idea of keeping the Sweet foundations, up through LIB_TABLE and LIB interfaces, as a separate DLL/DSO. And then later building on top of that with a new EESCHEMA. This is just a possibility, not a commitment. The motivation for this design would be to: 1) allow the interface to be tool agnostic. 2) allow the interface to be clearly defined enough to allow it to also be language agnostic. In this regard, we have C++ inherently, but I also am playing with the idea of tying in Python at this point before going much higher up in the architecture. The Sweet foundations would give you the ability to both Parse() and Format(), do round tripping, do inheritance, remote part retrieval, saving, on top of the LIB and LIB_TABLE interfaces. Then by bringing Python in at this point, it becomes possible to script the generation of PARTs. Or to do a Python graphical editor that knows about inheritance and remote part retrieval. I have no intentions of doing such an editor in Python, only enabling it, by coining a clearly defined API and foundation. Of course the LIB interface then allows *saving* of PARTs for cases where there are LIB_SINKs, or a Python program could simply do its own storage management of the Sweet strings. But in this way the inheritance mechanism is brought into Python through the common C++ work that is already done. This may slow things down a little, but it gives us a better base moving forward, and enhances the likelihood that Sweet will have legs. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp