Re: gEDA-user: file format (Re: Has anyone used SSOP28.fp)?

[Dave N6NZ <n6nz@xxxxxxxx>]

Dan McMahill wrote:
> note new thread and change to bottom posting!
> 
>  > On Thu, 2007-06-07 at 16:06 -0400, DJ Delorie wrote:
>  >>>> Shouldn't the file format be forward compatible with a warning?  if
>  >>>> an unknown parameter is introduced in the file format, pump out a
>  >>>> warning and continue?
>  >>> The problem is that pcb's file format is entirely defined by a yacc
>  >>> grammar.  I.e. the grammar says "expect FOO or BAR or GRILL here" and
>  >>> if you give it any other token, you get a syntax error.  A better
>  >>> file
>  >>> format would be something where the syntax is independent of the
>  >>> content, like what the menu resource uses, or (gak) XML.  Then we
>  >>> could parse the whole file into a data structure (all at once or
>  >>> piecemeal), and interpret (or not) the data we get.
>  >>>
>  >>> Perhaps we could change the parser to be content-agnostic, though.
>  >
> 
> 
>  > On Jun 7, 2007, at 2:18 PM, L.J.H. Timmerman wrote:
>  >
>  >> Hi DJ and all,
>  >>
>  >> First let's get this specified more in detail before this gets out of
>  >> hand.
>  >>
>  >> What sort of content should the parser be agnostic of ?
>  >>
>  >> Kind regards,
>  >>
>  >> Bert Timmerman.
>  >>
> 
> 
>> What I proposed is that,  we want to provide a parser that won't barf  
>> on properly formatted footprints that have newer features.
>>
>> We have Pin, element line, Pad other parts to the footprints,  lets  
>> say we add  SolderMaskOpening( parameters ) and SolderPasteBlob 
>> ( parameters )
>> An older version of PCB couldn't use those new definations   but,   
>> should it error out?
>>
>> lets say we add a Require field  that says that it needs something
>>
>>
>> lets add:
>> 	PolyPad ( parameters )
>> 	SolderPasteBlob( param )
>>
>>
>> Element( stuff )
>> (
>> 	Require( PolyPad )
>> 	Polypad( stuff )
>> )
>>
>>
>> would cause a pcb that understood forward compatible footprints to  
>> fail because the PolyPad element is unknown to it.
>>
>> but
>>
>> Element( stuff )
>> (
>> 	Pin( stuff )
>> 	Pad( stuff )
>> 	ElementLine( stuff )
>> 	SolderPasteBlob( stuff )
>> )
>>
>> would not cause a forward compatible pcb to fail loading the element,  
>> but would warn about SolderPasteBlob  not existing.
>>
>> Element( stuff )
>> (
>> 	Require( "SolderPasteBlob:Warning( Cannot properly create solder  
>> paste masks with this version of PCB\nSolderPasteBlob is not  
>> supported in your version of PCB please update if you use solder  
>> paste layers.\n):Disable(SolderPasteMask)")
>> 	Require("PolyPads:Error(Cannot make PolyPads With this version of  
>> PCB.\nThey are required for this footprint.  Please install Version  
>> 20080101 or later of PCB.\n))
> 
> there is a little bit of this type of warnings.  If you open a new .pcb 
> file in an old (but not too too old) pcb, it will tell you that the file 
> is too new for the pcb you have.
> 
>> 	PolyPad( stuff )
>> 	SolderPasteBlob( stuff )
>> )
>>
>> This footprint would fail on not having PolyPad support, but would  
>> only warn on not having solderMaskSupport.
>>
>>
>> This could also work for plugins,  as the plugin only be loaded when  
>> it is required.  thus allowing for more extensibility?
>>
>>
>> I hope this cleared up my thoughts, about forward compatibility.
>>
>> wikipedia has a nice entry on this... http://en.wikipedia.org/wiki/ 
>> Forward_compatible
>>
>> Steve
>>
> 
> 
> If we do any more sweeping change to the file format other than the 
> incremental changes which have taken place over many years, I'd really 
> rather see us move to the resource file format which is already in use 
> by pcb for menus and vendor drill/drc files.  The syntax isn't tied to 
> the content and we already have a self contained parser for it.
> 
> 
> -Dan
> 

Not being a dyed-in-the-wool pcb hacker, I'm not familiar with the 
resource format. I'll have to go look at that. But I *am* more than a 
little handy with flex and bison, and I can think of some possible 
simple ways to make the footprint parser "extension tolerant" that don't 
involve boiling the ocean, nor obsoleting everybody's footprints.

My first thought would be to have flex return an "unrecognized keyword" 
token, passing the spelling as a string value.  Then the parser could 
accept:

   UNREC_KEYWORD '(' valueList ')'

or some such, and toss it all in the bit bucket with a nice message.
So, as long as we expect extensions to look like:

keyword '(' valueList ')'
or
keyword '[' valueList ']'

we could easily create a parser that junked extensions politely.  (Of 
course, I haven't actually looked at the code...)

My own opinion on the XML question is that it would be a great format 
for interchange and archival storage of footprints, but there is no 
reason PCB should have to pull in an XML parser, nor any reason to make 
the 'working' footprint libraries so verbose.  It would be better to 
have an external tool that whipped the footprint.xml around a 
release-specific style sheet.  Having XML as an interchange format would 
open up a lot of options for simple footprint 
editors/checkers/translators since there are a lot of good XML tools around.

-dave


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user