kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

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 <pavlina.chris@xxxxxxxxx> 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" <d.cary+2012@xxxxxxxx> 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
> >>>>>>>>>> <pavlina.chris@xxxxxxxxx>
> >>>>>>>>>>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>>>>>>>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Mailing list: https://launchpad.net/~kicad-developers
> >>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>

diff --git a/include/richio.h b/include/richio.h
index d532157..86d72b2 100644
--- a/include/richio.h
+++ b/include/richio.h
@@ -192,7 +192,7 @@ struct PARSE_ERROR : public IO_ERROR
                const char* aInputLine,
                int aLineNumber, int aByteIndex );
 
-    ~PARSE_ERROR() throw ( /*none*/ ){}
+    virtual ~PARSE_ERROR() throw ( /*none*/ ){}
 
 protected:
     PARSE_ERROR(): IO_ERROR() {}
@@ -228,6 +228,8 @@ struct FUTURE_FORMAT_ERROR : public PARSE_ERROR
         byteIndex = aParseError.byteIndex;
         inputLine = aParseError.inputLine;
     }
+
+    ~FUTURE_FORMAT_ERROR() throw () {}
 };