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

[Dan McMahill <dan@xxxxxxxxxxxx>]

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


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