kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/24/2012 2:56 PM, Dick Hollenbeck wrote:
> On 10/24/2012 01:29 PM, Dick Hollenbeck wrote:
> > On 10/24/2012 11:09 AM, Wayne Stambaugh wrote:
> > > On 10/24/2012 10:28 AM, Dick Hollenbeck wrote:
> > > > On 10/23/2012 03:53 PM, Wayne Stambaugh wrote:
> > > > > On 10/23/2012 9:44 AM, Dick Hollenbeck wrote:
> > > > > > On 10/22/2012 08:44 PM, Wayne Stambaugh wrote:
> > > > > > > Dick,
> > > > > > >
> > > > > > > I figured out what the problem is.  To be honest, I'm not sure how the
> > > > > > > library cache loader didn't fail.  When a NULL BOARD item is passed to
> > > > > > > the PCB_PARSER constructor, no layer look up table is created.  When you
> > > > > > > attempt to parse the module input, the layer checking algorithm
> > > > > > > complains that the layer is indeed not there.  The solution is to
> > > > > > > populate the layer look up table with the default layer values using
> > > > > > > BOARD::GetDefaultLayerName().
> > > > > > That sounds exactly like what I had in mind.  Then after that constructor, if a board is
> > > > > > present it could overwrite entries in that same hashtable I guess.
> > > > > I was actually thinking about using a static member hash table to store
> > > > > the default table.
> > > > Why?
> > > >
> > > > It's the same amount of code, yet is requires more memory space and reduces program
> > > > startup time.
> > > >
> > > > I don't see the advantage.  Plus this won't cover the case where there is a roque yet
> > > > valid layername in a board.
> > > >
> > > > I'd go with the constructor approach, then only have to do straight line
> > > > hashtable lookups.
> > > The memory use should be fairly minimal as the hash table is nothing
> > > more than a wxString used to look up a LAYER object where the maximum
> > > number of layer objects is currently 32.  No start up penalty would be
> > > incurred.  The default layer look up table would be populated at run
> > > time the first time is needed.  Since the default layer table is fixed
> > > (unlike the board layer table which can have user defined names), it
> > > only needs to be populated once.  My thinking on this was not have to
> > > recreate the exact same layer look up table for every new instance of
> > > PCB_PARSER which when loading the new footprint library would occur for
> > > each footprint file in the library.  If you think the memory hit is more
> > > detrimental than the performance hit for recreating the table for every
> > > instance of PCB_PARSER, I'm wouldn't be opposed to populating the
> > > current look up table with the default layers in the constructor of
> > > PCB_PARSER.
> >
> > No mention was made of my concern for rogue layernames, but I think I understand your
> > concerns fully now.
> >
> > Its going to be easier for me to just fix this.
> >
> > Thanks for your pointers.
> >
> > The conversation is taking longer than the coding would.
> >
> >
> > Dick
>
>
> Now moved to mailing list....
>
>
> I've been keeping the door open to installing a hashtable into DSNLEXER for keyword lookup.
>
> Instantiating PCB_PARSER for each footprint makes this worrisome, as loading a keyword
> hashtable is even a larger task than what we've been talking about.
>
> So I put in a PCB_PARSER that lives as long as the PCB_IO does by making it a member.
>
> PCB_PARSER::init() is now the logical place to load m_layerTable with default layer names.
>
> You were correct about finding those laying around not already translated.   :)
>
> Thanks again,
>
> Dick

Dick,

Thanks for fixing this.  I apologize for not being as responsive as 
usual but I've been up to my eyeballs at work today.

Thanks,

Wayne