Simon, Thanks. I think commit r6971 should resolve this. Please let me know if it doesn't.
Thanks, Wayne On 7/6/2016 11:35 AM, Simon Wells wrote: > hey wayne, > > http://pastebin.com/EVgdXHuf on osx > > On Thu, Jul 7, 2016 at 3:21 AM, Wayne Stambaugh <[email protected]> wrote: >> 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, >>> >> >> Thanks for the file to test. I expected that there would be some old >> files that would be problematic. I'll take a look at this tomorrow. >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
