kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 07/07/2016 à 11:55, Wayne Stambaugh a écrit :
> On 7/6/2016 11:10 AM, jp charras wrote:
>> Le 06/07/2016 à 15:53, Wayne Stambaugh a écrit :
>>> On 7/6/2016 8:01 AM, jp charras wrote:
>>>> Le 06/07/2016 à 11:23, Wayne Stambaugh a écrit :
>>>>> I just committed the initial schematic I/O plugin code.  It only
>>>>> supports the schematic file parsing at the moment but soon it should
>>>>> support schematic output formatting.  Symbol library loading and saving
>>>>> will follow shortly there after.  By default, the new is built but it is
>>>>> not used.  The current code is used in the default build config.  I
>>>>> created a new build config option USE_SCH_IO_MANAGER to enable using the
>>>>> plugin.  Set -DUSE_SCH_IO_MANAGER=ON in your config to enable it.  I've
>>>>> been using round tripping (parse the file with the new parser and saving
>>>>> to a new file with the current formatter and comparing the result) to
>>>>> test the parser and I get identical files for every schematic except for
>>>>> the interf_u demo (see below) so I feel pretty good about it's
>>>>> stability.  You also get the added benefit of knowing where in the file
>>>>> a parser error occurs.  One major difference is that if a parse error
>>>>> occurs, the schematic will not continue to load the schematic.  I never
>>>>> really liked that design in current parser.  The current parser is
>>>>> syntactically very loose.  I wrote the new parser to be much more strict
>>>>> so there coud be some issues on older schematics.  I tested some demo
>>>>> schematic files from product branch r800 and they parsed fine but I'm
>>>>> sure there will be a few that do not.  I would appreciate help from the
>>>>> devs with testing this.  Particularly if you have any really old
>>>>> schematic files laying around.  If you find any that fail, please send
>>>>> them to me so I can fix the parser.
>>>>>
>>>>> For some reason, either the current parser or the output formatter for
>>>>> the BITMAP object is broken.  At first I thought it was my new parser
>>>>> but I tested the existing code and the bug is there as well.  You can
>>>>> test this by opening eeschema in the stand alone mode, open the
>>>>> interf_u.sch file, save the file to a new name, and do a diff between
>>>>> the two files and you will see that the last byte of the bitmap data has
>>>>> changed.  This also happens in the stable release.  I couldn't see any
>>>>> visible difference in the bitmaps but it's still a bit odd and should be
>>>>> fixed at some point.
>>>>>
>>>>> Package devs, please continue to build packages as you currently do.
>>>>> Once the new plugin code is complete and tested, I will make it the
>>>>> default config.  Many thanks in advance for the help.  Hopefully it's
>>>>> not too buggy. :)
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Wayne
>>>>
>>>> Good work Wayne!
>>>>
>>>> Are you compiling Kicad in debug mode?
>>>> In release mode there is a repetitive issue in sch_legacy_plugin.cpp:
>>>> for instance in ::loadWire() you are using:
>>>>     wxASSERT( strCompare( "Wire", line, &line ) );
>>>>
>>>> It works certainly fine in debug mode, but in release mode
>>>> strCompare( "Wire", line, &line )
>>>> is never executed (not compiled) at least on W7 32 bits, but I am thinking this is not platform
>>>> dependent.
>>>>
>>>> a "invalid wire definition" error is shown and Eeschema crashes.
>>>>
>>>> Sorry,
>>>>
>>>
>>> I just committed the fix for this.  Please test it when you get a chance.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>
>> Thanks.
>> It works now in release mode.
>>
>> However, like previously, Eeschema crashes when something incorrect is encountered in a sch file,
>> after the error message is displayed.
>>
>> Also, (very) old .sch files are not read.
>> Attached a very old file (I have older files).
>>
>> The reason is the fact the plugin expects too many parameters for texts (or fields)
>> Old files do not have as many parameters (justification, style) as now.
>> For the legacy plugin, these parameters must be considered optional.
>>
>> Thanks,
>>
> 
> JP,
> 
> I've fixed most of the issues with the parsing the very old schematic
> files and in the process I think I have found bug in the current
> SCH_TEXT parser.  When I open the file you sent (seuil.sch), save it to
> a new file, and then compare the results I found that all the SCH_TEXT
> objects that were defined as GLabel types were converted to HLabel
> types.  Is this supposed to happen?
> 
> Wayne
> 

Yes, this is correct.

In seuil.sch, there are only HLabel (it is a sub-sheet).
In very old sch files (sch version 1), the current global labels did not exist.
Only since version 2, there are global and hierarchical labels.
in files version 1, a "hierarchical" label has its type set as "GLabel" in .sch files.


-- 
Jean-Pierre CHARRAS