kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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 <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
>>>>>>>