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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
