On 7/7/2016 9:45 AM, jp charras wrote: > Le 07/07/2016 à 15:12, Wayne Stambaugh a écrit : >> On 7/7/2016 7:30 AM, jp charras wrote: >>> 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. >>> >>> >> >> I just committed r6971 which should fix the crash when the schematic >> fails to load properly, the parsing issues with version 1 schematic >> files, and hopefully the osx build issue. Please test it out when you >> get a chance. >> >> Thanks >> >> Wayne >> > > r6971 works fine. > > Perhaps, during code refactoring, you could replace std::auto_ptr (deprecated > in c++11) by > std::unique_ptr. > > Thanks. >
I'm working on the output formatter now so I'll replace them in the next commit. I'm still stuck in pre C++11 mode. :) _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
