kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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.

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

Attachment: eeschema_part_sexpr_format_EN.odt
Description: application/vnd.oasis.opendocument.text