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.
