kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/25/2011 08:02 PM, Wayne Stambaugh wrote:
> On 3/25/2011 4:42 PM, Dick Hollenbeck wrote:
>> -------------------------
>>> When it comes to coding, we should be careful not to allow the schematic
>>> editor to go beyond the bounds of the public Sweet API.  This should be
>>> possible to enforce by keeping the sweet stuff as a separate DLL.
>> I still think the best way forward will be to have a LIB_SOURCE that simply
>> reads old lib files and provides PARTs through the LIB_SOURCE API, which
>> inherently means generating a sweet string for each part, on the fly.  This
>> provides a good model for any other type of library conversion facility.
> Great idea.  This is one of the things I've been thinking about as well.
>  Converting the existing libraries can always be done with external
> conversion tools written in other languages like Python but asking user
> to convert libraries this way is not very practical.

There is a swig binding that I started.  This means python or some other
language could be used to output SWEET strings, or read them, by calling
into the C++ work.

The SWIG work is not current with all the latest C++ changes, when I get all
the parsing and formatting done, I'll go back and bring the SWIG interface
up to current.



>> As soon as I am done with the sweet parser, I will be doing all the Format()
>> functions which is the reverse of the Parse() operation, and from this code,
>> given that we can Format() into a STRING_FORMATTER, means we can generate
>> Sweet strings from the C++ structures.  These building blocks can be put
>> into any "converting" type of LIB_SOURCE.

Here is the output from the PART::Format() function using the shell script
generated
input test data run through the test program 'test_sch_lib_table':


(part tigers/ears/rev10
  (reference U?
    (effects (at 12 13)(font (size 0.7 1))(visible yes)))
  (value 22)
  (footprint SM0805)
  (datasheet http://favorite.pdf)
  (model Airplane)
  (property mWatts 12
    (effects (at 1 34)(font (size 0.5 1) italic bold)(visible no)))
  (keywords batcave einstein varistor)
  (line (line_width 1.5)
    (pts (xy 12 13)(xy 12 20)))
  (rectangle (start 4 5)(end 6 8)(line_width 2.3)(fill transparent))
  (circle (center 1 0)(radius 5)(line_width 2.1))
  (arc (pos 22 33)(radius 12)(start 2 4)(end 13 33)(line_width 2.3)(fill
filled))
  (bezier (line_width 2)
    (pts (xy 0 1)(xy 2 4)))
  (text "This is some text"
    (at 23 23)(justify left bottom)(visible yes)(fill filled)(font arial
(size 0.8 1.2)))
  (pin output line (at 7 8)(length 2)(visible yes)
    (signal "#WE" (font (size 0.9 1.1) bold)(visible yes))
    (padname A23 (font (size 0.9 1.1) italic bold)(visible yes)))
  (pin input line (at 8 8 0)(length 2)(visible yes)
    (signal "#WAIT" (font (size 0.9 1.1) bold)(visible yes))
    (padname A24 (font (size 0.9 1.1) italic bold)(visible yes)))
)


If anything looks long winded (overly verbose), the next couple of weeks
would be a good time to make those 11th hour changes.

'line_width' as a keyword name, seems a bit long to me, but its a minor deal.

Overall, hopefully it still looks sweet.