kicad-developers team mailing list archive
Mailing list archive
Re: [Bug 1069765] [NEW] Module scale is altered after export and reimport
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:
>>>>> 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
>>>> 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.
>> 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
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.