kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 12/30/2010 12:18 PM, Wayne Stambaugh wrote:
> On 12/29/2010 9:06 PM, Dick Hollenbeck wrote:
>> Wayne,
>>
>> 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
>> make-dir-lib-source-test-data.sh
>> 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
>> sch_lib_table.cpp.
>>
>> 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.

Thanks.  In light of the fact that I only have a tight time slot to work on
this, another few days, I wonder if it would be a good idea for me to just
do the basic parser, cherry picking the important items such as:

1) inheritance.
2) basic drawables

probably not pins for lack of time, and the object action enhancements can
be done by you later, since that requires having paid more attention during
earlier conversations, than I did.

For the next 2 hours or so I am rethinking the exception bucket a little
bit, so up at the UI we can get precise information on all problems.  That
has been my driver since day one, and I don't want to go further until the
foundation is rock solid.  If something goes wrong, you should be able to
tell, where, why, and what.


>> 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.

The new PART class will have a Format() function.  I think it would be
easiest to create a new front end to new PART, say an alternative parser
that reads the old parts.  It could even be made into a formal LIB_SOURCE,
one which would dynamically convert old parts to the new API.

In any case, I think it would be prudent to push all the old data though a
new PART object, just to make sure it is convertible, then use the new
PART::Format() function to output it, say back to a new library source, for
which a person could even use DIR_LIB_SINK to do that.

By tying a LIB_SOURCE to a non-matching LIB_SINK, you effectively get a
conversion program, if you simply iterate over all parts.   Well that
sounded better than it will be, only because there is only one LIB_SINK
planned by me, DIR_LIB_SINK, but that is probably all we need initially. 
You can stuff a subversion repo from the dir tree behind DIR_LIB_SOURCE, so
that one will never get written.


Dick



>> The Parse() function is in sch_part.cpp, and I just took it far enough get
>> you a playground.  I am here to help.
> I noticed there are not any SCH_PART member(s) to place the drawable
> objects into.  Did you have something particular in mind or is this TBD?
>
> Thanks for all the hard work.
>
> Wayne
>
>> Thanks!
>>
>> Dick
>>
>> Copying the mailing list too.
>>
>>
>>