kicad-developers team mailing list archive
Mailing list archive
Re: Sweet parser
On 12/30/2010 2:35 PM, Dick Hollenbeck wrote:
> On 12/30/2010 12:18 PM, Wayne Stambaugh wrote:
>> On 12/29/2010 9:06 PM, Dick Hollenbeck wrote:
>>> You had said that you would want to write the Sweet parser.
>>> Wayne's World:
>>> I now have all the /new infrastructure in place to load Sweet strings driven
>>> by test
>>> program test_sch_lib_table. If you were to mostly confine yourself to
>>> basically that one
>>> function, PART::Parse() for now, we could now work in parallel without
>>> stepping on each other.
>>> Steps to get a build of test_sch_lib_table working:
>>> 1) Generate the test input data by running script
>>> Edit it as wanted, understand the script.
>>> 2) $ cd <kicad>/new
>>> 3) $ mkdir build
>>> 4) $ cd build
>>> 5) $ cmake -DCMAKE_BUILD_TYPE=Debug ../
>>> 6) $ make
>>> 7) $ ./test_sch_lib_table
>>> The int main() function is in sch_lib_table.cpp.
>>> You can and should edit the (lib_table ) element to point to a different,
>>> more permanent directory than tmp.
>>> Coordinate this with an edit to make-dir-lib-source-test-data.sh.
>>> The currently loaded part is "meparts:tigers/ears/rev10" at line 410 of
>>> You can edit the file tigers/ears.part.rev10 with a text editor and build up
>>> your input for the parser.
>>> If you need more help or don't want to do this anymore, please let me know.
>>> I have raced to get to this point, and will be going back over some things
>>> that need better robustness either way, especially in the area of error
>>> reporting, not so much functionality.
>> I've just started looking over what you've done yesterday and I'm still
>> trying to wrap my head around it. I will have some time over the next
>> few days but it will likely be a while before I can finish the task. If
>> it's something you can knock quickly, I would not be offended if you did it.
>> I have attached the latest sweet specification which includes the name
>> hint and router pin and swap flags that we discussed before Christmas.
>> I'm not terribly thrilled about using route as part of the token name.
>> It seems a bit restrictive. There may be other tools that could take
>> advantage of pin and/or gate swapping. Maybe hint_pin_swap would be
>> more flexible and descriptive than route_pin_swap.
>>> sch_part.h has the new "contains" field we talked about, along with PB() and
>>> PartBits. You should even be able to write Inherits() as you get to that
>>> point. Inherits() will only ever be called from Parse().
>> Were you thinking about creating new objects for all of the library part
>> drawable items or reusing the existing ones? I was hoping to reuse the
>> existing ones to ease migration to the new format and avoid creating an
>> external tool to convert existing libraries. I was thinking about
>> overriding the Save method for the library and all the LIB_ITEM objects
>> and adding a compile time option to the library editor to save the
>> libraries to the new format. That would give us some complete libraries
>> to work with.
> This last paragraph makes me curious about something, and whether we are on
> the same page as to the degree to which this new API affects EESCHEMA.
> Really this whole discussion is about an API, and Sweet is literally part of
> the API because it is what is returned from the API.
I think I have a decent understanding of how the API interfaces with
EESchema. I can see how the classes fit together to create the part
library API. I guess I'm thinking of what happens after the part library
API is loaded by EESchema. How do the parts get drawn? Where are the
arcs, circles, lines, etc. objects that are part of a SCH_PART reside?
We already have these objects that are fairly robust if less than
optimally designed (I'm working on that). Maybe I'm thinking too far
ahead or am missing something.
> Although you COULD augment existing EESCHEMA to write Sweet files, it
> becomes nothing more than a conversion program at that point (but perhaps a
> decent conversion program).
I think that is something most users will want. Using a script or
external program to convert from the current file format is something
most users will frown upon.
> Old EESCHEMA will not be able to use the new API because:
> The API owns all the PARTs, it only lets the schematic reference them within
> the LIB cache. And then there is the parts list. So EESCHEMA will need to
> be rewritten in effect, at least 60% of it.
I order for this to happen we will need to start defining the new
schematic file format. I don't think mixing the existing file format
with sweet would get rather ugly. I can start putting together a
preliminary schematic file specification over the next month or so.
> This is my perspective. (And any time we talk about augmenting the existing
> code, I will begin to wonder why, I will question why.)
> Basically email is starting to suck for this. We may need to open up an IRC
> or use skype if it gets any more involved.
I have neither a Skype nor an IRC account but it won't take long to
create one or both. If (when?) we get to that point, let me know which
medium you prefer and I will get it set up.