Thanks. That fixed it. On 5/2/2016 3:22 PM, Chris Pavlina wrote: > Oops. No, that's not just an issue of which compilers accept it, that's dodgy > and gcc 5.3 and clang should have yelled at me too... > > Apply the attached patch on top of the original one, should clean it up. Sorry > about that. > > On Mon, May 02, 2016 at 03:00:17PM -0400, Wayne Stambaugh wrote: >> I can't buy a break today. Your patch is failing on mingw32/msys1 for >> the virtual dtor throw specifier being too loose. This is probably fine >> on c++ 0x11 with newer gcc version but it kills gcc 4.7.2 even though it >> is supposed to have c++ support. Here is the compile error message: >> >> In file included from C:/src/kicad/product/include/base_struct.h:39:0, >> from c:/src/kicad/product/common/dlist.cpp:28: >> C:/src/kicad/product/include/richio.h:212:8: error: looser throw >> specifier for 'virtual FUTURE_FORMAT_ERROR::~FUTURE_FORMAT_ERROR()' >> C:/src/kicad/product/include/richio.h:195:5: error: overriding >> 'virtual PARSE_ERROR::~PARSE_ERROR() throw ()' >> >> I'll run my msys2 builds for now but I would like kicad to build on gcc >> 4.7 at a minimum so when you get a chance please update the dtor >> inheritance issue. >> >> Thanks, >> >> Wayne >> >> On 5/2/2016 12:34 PM, Chris Pavlina wrote: >>> Wayne, >>> >>> The patch includes a minor refactoring of a function that ended up not being >>> necessary in the end - originally my code made changes to it that were hard >>> without refactoring, but I ended up reworking my code and didn't need that >>> function anymore. I didn't revert the refactoring, as it worked well and was >>> cleaner. However, if you notice any issues with >>> FOOTPRINT_EDIT_FRAME::Import_Module(), >>> let me know, I will revert the changes and send you an updated patch. >>> >>> On Mon, May 02, 2016 at 11:46:34AM -0400, Wayne Stambaugh wrote: >>>> Chris, >>>> >>>> Give me some time to test your patch. I will apply it to all of my >>>> systems and test it to make sure it doesn't break anything. >>>> >>>> Thanks, >>>> >>>> Wayne >>>> >>>> On 5/1/2016 6:59 PM, Chris Pavlina wrote: >>>>> Followed up on this question in a separate mail. >>>>> >>>>> Patch is attached. Please have a good look over it, if it's going to >>>>> stable I >>>>> don't want to be the only one who's had a look :) >>>>> >>>>> On Sat, Apr 30, 2016 at 07:57:36PM -0400, Chris Pavlina wrote: >>>>>> I'm very close to finished - I'll take some time to fully test and >>>>>> review the >>>>>> patch to ensure it's ready for a commit to stable, though - will submit >>>>>> tomorrow. >>>>>> >>>>>> I have a question. Currently, when loading a full library as opposed to a >>>>>> single footprint, we silently ignore errors and just do not load >>>>>> footprints >>>>>> that have syntax issues. This of course means that format versioning >>>>>> won't >>>>>> really work for these. The user will never see the hint about their >>>>>> version >>>>>> being old. >>>>>> >>>>>> Should I: >>>>>> 1) Leave it as is. (please say no please say no please say no) >>>>>> 2) Make an exception for the version-too-new case. >>>>>> 3) Change this and *do* display these errors, in all cases. >>>>>> >>>>>> On Fri, Apr 29, 2016 at 09:24:19AM -0400, Wayne Stambaugh wrote: >>>>>>> Thanks for the update. I've been holding off on releasing 4.0.3 for >>>>>>> this. I apologize for my absence over the last week or so. I've been >>>>>>> really busy at work and got sick on top of that so my motivation to >>>>>>> spend what little free time I had working on KiCad was low. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Wayne >>>>>>> >>>>>>> On 4/28/2016 2:38 PM, Chris Pavlina wrote: >>>>>>>> Just a quick ping to reassure y'all I'm still working on this - been >>>>>>>> caught >>>>>>>> up in other things a bit the last couple weeks. I've got a nearly >>>>>>>> working >>>>>>>> implementation here. >>>>>>>> >>>>>>>> On Tue, Apr 12, 2016 at 12:22:48PM -0400, Wayne Stambaugh wrote: >>>>>>>>> I doubt this going to be a big issue. Since the new board file format >>>>>>>>> was implemented over fours years ago there have been a handful of >>>>>>>>> changes. I think we're going to be OK with just the date code. >>>>>>>>> >>>>>>>>> On 4/12/2016 12:06 PM, Chris Pavlina wrote: >>>>>>>>>> Let's just not do more than one format change in a single day... I >>>>>>>>>> think that >>>>>>>>>> would be a beneficial decision for project stability as well... >>>>>>>>>> >>>>>>>>>> On Tue, Apr 12, 2016 at 05:26:27PM +0200, Timofonic wrote: >>>>>>>>>>> Despite my very limited knowledge, I like the simple approach. >>>>>>>>>>> >>>>>>>>>>> What about using letters if more than one format change is done? >>>>>>>>>>> >>>>>>>>>>> 20160412A, 20160412B, 20160412C... >>>>>>>>>>> >>>>>>>>>>> On April 12, 2016 2:30:23 PM CEST, Chris Pavlina >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> Honestly I don't see the advantage to using Semantic Versioning >>>>>>>>>>>> for an >>>>>>>>>>>> internal file format version... and using 2016.04.12 instead of >>>>>>>>>>>> 20160412 >>>>>>>>>>>> just seems like an exercise in making the parser more complicated. >>>>>>>>>>>> Could >>>>>>>>>>>> you explain *why* this would be a good thing? >>>>>>>>>>>> On Apr 12, 2016 1:51 AM, "David Cary" <[email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Please at least consider Semantic Versioning ( http://semver.org/ >>>>>>>>>>>>> ). >>>>>>>>>>>>> And I recommend that if you figure out any way to improve on >>>>>>>>>>>>> SemVer, >>>>>>>>>>>>> please speak up so maybe the next version of SemVer can >>>>>>>>>>>>> incorporate >>>>>>>>>>>>> those improvements. >>>>>>>>>>>>> >>>>>>>>>>>>> I have enjoyed the discussion of new features and various ideas >>>>>>>>>>>>> for >>>>>>>>>>>>> versioning, and I encourage you to discuss them further. >>>>>>>>>>>>> >>>>>>>>>>>>> I am happy that the native KiCad file formats already avoid many >>>>>>>>>>>>> problems mentioned in >>>>>>>>>>>>> "Designing File Formats" >>>>>>>>>>>>> http://www.fadden.com/tech/file-formats.html >>>>>>>>>>>>> . >>>>>>>>>>>>> Are there any remaining recommendations in that essay that maybe >>>>>>>>>>>>> we >>>>>>>>>>>>> should include in future versions of KiCad file formats? >>>>>>>>>>>>> >>>>>>>>>>>>> If hypothetically we did use Semantic Versioning, >>>>>>>>>>>>> would it be better to do (a) or (b)?: >>>>>>>>>>>>> (a) have a single KiCad version number that KiCad writes into >>>>>>>>>>>>> every >>>>>>>>>>>>> new file it creates, or >>>>>>>>>>>>> (b) have a separate and independent version number for each part >>>>>>>>>>>>> of >>>>>>>>>>>>> KiCad -- the Eeschema version number written into new schematic >>>>>>>>>>>> files, >>>>>>>>>>>>> a separate Pcbnew version number written into new footprint and >>>>>>>>>>>>> PCB >>>>>>>>>>>>> layout files, etc. >>>>>>>>>>>>> >>>>>>>>>>>>> (How many independent version numbers could option (b) require?) >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Apr 7, 2016 at 1:04 PM, Chris Pavlina >>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> What about using the date the change was made as a "version >>>>>>>>>>>> number"? Can >>>>>>>>>>>>>> integerize it like 20160407 for example. This allows easy >>>>>>>>>>>>> cross-referencing of >>>>>>>>>>>>>> a format version with the revision that it was made in, and is >>>>>>>>>>>>> guaranteed to >>>>>>>>>>>>>> increase monotonically if you use a YMD format :) >>>>>>>>>>>>> >>>>>>>>>>>>> I agree with Wayne that it's more meaningful than most version >>>>>>>>>>>> strings. >>>>>>>>>>>>> >>>>>>>>>>>>> My understanding is that "integerized date" without punctuation is >>>>>>>>>>>>> more commonly known as the "ISO 8601 date basic format". >>>>>>>>>>>>> >>>>>>>>>>>>> Recently I've been putting a date like that on the silkscreen of >>>>>>>>>>>>> my >>>>>>>>>>>>> PCBs. (I use the "ISO 8601 date extended format" like 2016-04-07, >>>>>>>>>>>>> the >>>>>>>>>>>>> format produced by the KiCad "%D" format symbol). >>>>>>>>>>>>> >>>>>>>>>>>>> Is it possible to combine that with Semantic versioning, getting >>>>>>>>>>>>> something like 2016.04.07 ? >>>>>>>>>>>>> (This assumes we won't make a breaking change in the file format >>>>>>>>>>>>> more >>>>>>>>>>>>> than once a year -- optimistic? :-) >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> David Cary >>>>>>>>>>>>> +1(918)813-2279 >>>>>>>>>>>>> http://OpenCircuits.com/ >>>>>>>>>>>>> http://david.carybros.com/ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>>>> Post to : [email protected] >>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Enviado desde mi dispositivo Android con K-9 Mail. Por favor >>>>>>>>>>> disculpa mi brevedad. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
