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

Wayne,

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.

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


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.

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.

Thanks,


Dick