On 5/10/2016 2:17 PM, Chris Pavlina wrote:
> I don't think there is anything that can be done about that. If the file was
> made by a later version, there's no way I can think of to distinguish a true
> error from a new feature. Personally, I think the combination of (later
> version
> + new featu
I don't think there is anything that can be done about that. If the file was
made by a later version, there's no way I can think of to distinguish a true
error from a new feature. Personally, I think the combination of (later version
+ new feature) is much more likely than (later version + file err
Chris,
I finally got a chance to test this patch. I couldn't find any issues
with it. The only thing that could be confusing to the user is if the
board parser fails for a legitimate error, recommending an upgrade may
be misleading. I'm not sure there is much you can do about that. If
it's rea
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
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
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 incl
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
Chris,
I'm not opposed to addressing this. I prefer option 3 but implementing
that may prove to be a monumental undertaking given the current
footprint loading code. This is something we should think about very
carefully.
Cheers,
Wayne
On 4/30/2016 7:57 PM, Chris Pavlina wrote:
> I'm very clo
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
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 ful
Resent to the list (damm it list reply config...)
- Forwarded message from Marco Ciampa -
Date: Sun, 1 May 2016 10:16:02 +0200
From: Marco Ciampa
To: Chris Pavlina
Subject: Re: [Kicad-developers] New pcbnew features and versioning
User-Agent: Mutt/1.5.21 (2010-09-15)
On Sat, Apr 30
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
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
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 f
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
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 i
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
wrote:
>Honestly I don't see the advantage to using Semantic Versioning for an
>
Hey David,
Thanks. Being concise is a matter of necessity. I don't have enough
free time to write long responses and I don't want anyone on the
development to have to guess what I'm thinking.
Cheers,
Wayne
On 4/11/2016 8:40 PM, David Godfrey wrote:
> Hi Wayne,
>
> Nice concise response and g
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
Hi Wayne,
Nice concise response and good direction, exactly what is needed from a
Project Leader.
Regards
David G
On 12/04/16 07:32, Wayne Stambaugh wrote:
> I'm going to put on my project leader hat and try to respond to all of
> the issues discussed thus far rather than reply to each concern
>
I'm going to put on my project leader hat and try to respond to all of
the issues discussed thus far rather than reply to each concern
individually. I'll start off by saying that many of you are going to
disagree with me but I'm OK with that. At the end of the day, I'm
responsible for the code th
Hi All,
On 11/04/16 07:37, Wayne Stambaugh wrote:
> Let's slow down and think about this a bit. I'm not sure that this is
> the best way to resolve this. Let me chew on it a bit and I will get
> back to you. I've been busy today so hopefully by tomorrow I'll have an
> answer.
Wayne,
Off the cuf
Let's slow down and think about this a bit. I'm not sure that this is
the best way to resolve this. Let me chew on it a bit and I will get
back to you. I've been busy today so hopefully by tomorrow I'll have an
answer.
Thanks,
Wayne
On 4/10/2016 12:36 PM, jp charras wrote:
> Le 10/04/2016 16:
Most users have a concern about their data, the program is not important
as their data. So maybe only information for users will be enough. There
could be a list where all changes in files can be listed. Often I using
LO as reference because of their success
(https://wiki.documentfoundation.org
Le 10/04/2016 16:11, Chris Pavlina a écrit :
> I like the idea. It'll take some work to implement properly, though. I can
> start working on it, but it will likely be at least a week before I have
> anything.
Thanks you to make me very happy ...
>
> On Sun, Apr 10, 2016 at 04:05:42PM +0200, jp c
I like the idea. It'll take some work to implement properly, though. I can
start working on it, but it will likely be at least a week before I have
anything.
On Sun, Apr 10, 2016 at 04:05:42PM +0200, jp charras wrote:
> Le 10/04/2016 15:31, Chris Pavlina a écrit :
> > So - would you be happy with
Le 10/04/2016 15:31, Chris Pavlina a écrit :
> So - would you be happy with me just changing that to a warning that can be
> clicked through instead of an error, and rewriting the message a bit to agree?
>
I'll be more happy.
But I'll be really very happy if a dynamic version numbering is also a
You seem to be confusing backward and forward compatibility...
no
just read my comments from the first mail ...
I always ask to have the ability to save a board with a back release nbr
from the new release, if there is not new features on it
... anyway just do what you care
cheers
On 10/04/
On Sun, Apr 10, 2016 at 03:30:15PM +0200, easyw wrote:
> >From what I've seen of the forums, the users complain about _everything_, I
> >don't think it's necessarily our job to minimize complaints. ;)
> so this is as I thought... users point of view don't count so much
>
> >4022 is _old_. If you'
So - would you be happy with me just changing that to a warning that can be
clicked through instead of an error, and rewriting the message a bit to agree?
On Sun, Apr 10, 2016 at 03:17:17PM +0200, jp charras wrote:
> Le 10/04/2016 02:49, Chris Pavlina a écrit :
> > Possible to implement, of course
From what I've seen of the forums, the users complain about _everything_, I
don't think it's necessarily our job to minimize complaints. ;)
so this is as I thought... users point of view don't count so much
4022 is _old_. If you're still using it, upgrade.
I was pointing out the case of 4022..
Le 10/04/2016 02:49, Chris Pavlina a écrit :
> Possible to implement, of course, but that could get rather messy as the
> parser
> has to be taught to ignore things it doesn't recognize, which is not exactly
> easy given the context-sensitive nature of our kinda-sorta-pseudo-parser
> implementatio
the problem is you are dealing with potentially very close tolerance.
and numerous other issues that if htere is a compatibility possibility
we will probably get people saying that compatibility breaks their
design. There comes a point where it just has to be dealt with, a save
with compatibility c
>From what I've seen of the forums, the users complain about _everything_, I
don't think it's necessarily our job to minimize complaints. ;)
4022 is _old_. If you're still using it, upgrade. If you're still running
Ubuntu 320BC.06 and it doesn't run, upgrade that too. :P
On Sun, Apr 10, 2016 at 0
I don't really see much reason to care if 4.0 can emit board files 4022 can
read.
4022 was considered STABLE for very long time, many users didn't want to
move from there for long time...
Now the 4.0 is the 'new stable' release and a lot of users will not
switch to the new for long time (till n
The upgrade from 4022 to 4.0 wasn't as smooth as it could have been, no. But
tbh I don't really see much reason to care if 4.0 can emit board files 4022 can
read. Upgrade to 4.0. It's KiCad, not Altium, it's free. You can upgrade.
Now, if 4022 emits files 4.0 can't read, that's a separate problem,
This gets filed under "things said by people who haven't seen what'd be necessary to
implement that" ;)
This gets filed under "things said by people who cares about what user's
need in a real production world"
If you don't care about what happened with the 4022 vs new stable for
users, then
This gets filed under "things said by people who haven't seen what'd be
necessary to implement that" ;)
On Sun, Apr 10, 2016 at 10:23:22AM +0200, easyw wrote:
> I think there should be an option to export a new board version to previous
> version, eventually warning on what could be lost if the fi
I think there should be an option to export a new board version to
previous version, eventually warning on what could be lost if the file
contains some new features...
that is a standard feature in most sw, to allow a better collaborative
environment
Maurice
On 10/04/2016 02.49, Chris Pavlina
Possible to implement, of course, but that could get rather messy as the parser
has to be taught to ignore things it doesn't recognize, which is not exactly
easy given the context-sensitive nature of our kinda-sorta-pseudo-parser
implementation...
I don't see the problem with refusing. It ensures
Chris,
I looked at this patch and I thought you were going to add a check to
warn the user that the board file may not load. Your patch will refuse
to load any previous versions even if the file does not contain any new
features. I'm not sure flat out rejecting newer board versions is a
good ide
I have not read the patch, but my apparent comments about this inline.
2016-04-09 17:42 GMT+02:00 Chris Pavlina :
> Here's a patch that checks the PCB file format version against the currently
> supported one, and displays a message explaining the situation if the PCB file
> is too recent. I assum
Here's a patch that checks the PCB file format version against the currently
supported one, and displays a message explaining the situation if the PCB file
is too recent. I assumed MMDD format for the version. Message looks like
this:
KiCad was unable to open this file, as it was created w
If there are more than one commit in a given day, add a lower case alpha to the
timestamp
like 20160407, then 20160407a, then 20160407b, and so on.
Just my $0.02
Jean-Paul
N1JPL
> On Apr 7, 2016, at 2:13 PM, Wayne Stambaugh wrote:
>
> I like it. It's more meaningful than an integer. The onl
In case of emergency we can just delay a change by one day ;)
On Thu, Apr 07, 2016 at 02:13:04PM -0400, Wayne Stambaugh wrote:
> I like it. It's more meaningful than an integer. The only time that
> doesn't work is when there is more than one feature change per day.
> Given that we have never ma
I like it. It's more meaningful than an integer. The only time that
doesn't work is when there is more than one feature change per day.
Given that we have never made more than one file format change on a
single day, I think we are safe. :)
On 4/7/2016 2:04 PM, Chris Pavlina wrote:
> What about u
Le 07/04/2016 20:04, Chris Pavlina a écrit :
> 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 monotoni
I like the date idea, gEDA PCB uses that too
On Thu, Apr 7, 2016 at 1:04 PM, Chris Pavlina 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 i
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 :)
On Thu, Apr 07, 201
Le 07/04/2016 18:42, Chris Pavlina a écrit :
> On Thu, Apr 07, 2016 at 06:36:40PM +0200, jp charras wrote:
>> Le 07/04/2016 17:52, Wayne Stambaugh a écrit :
>>> On 4/7/2016 9:47 AM, Chris Pavlina wrote:
Hi all,
I'm targeting this email primarily at Wayne as versioning and release
>>
On Thu, Apr 07, 2016 at 06:36:40PM +0200, jp charras wrote:
> Le 07/04/2016 17:52, Wayne Stambaugh a écrit :
> > On 4/7/2016 9:47 AM, Chris Pavlina wrote:
> >> Hi all,
> >>
> >> I'm targeting this email primarily at Wayne as versioning and release
> >> policy is
> >> involved.
> >>
> >> We've got
Le 07/04/2016 17:52, Wayne Stambaugh a écrit :
> On 4/7/2016 9:47 AM, Chris Pavlina wrote:
>> Hi all,
>>
>> I'm targeting this email primarily at Wayne as versioning and release policy
>> is
>> involved.
>>
>> We've got a bit of a problem right now. We're currently adding features to
>> the
>> pc
Personally I'm in favor of bumping the version with every feature. I can't see
it getting too annoying on the development branch, as people who use that
generally keep it up to date anyway - and I think it's sane to require them to.
Either use a release, or use development head. :)
On Thu, Apr 07,
On Thu, Apr 07, 2016 at 11:30:18AM -0400, Chris Pavlina wrote:
> I think you misunderstand my suggestion, then. What I want to push into a
> minor
> release is a check to make sure the version is valid - nothing that changes
> the
> format. I want the minor release to start checking the version,
On 4/7/2016 9:47 AM, Chris Pavlina wrote:
> Hi all,
>
> I'm targeting this email primarily at Wayne as versioning and release policy
> is
> involved.
>
> We've got a bit of a problem right now. We're currently adding features to the
> pcbnew format - JP just merged rounded-rect pads and has a pa
I think you misunderstand my suggestion, then. What I want to push into a minor
release is a check to make sure the version is valid - nothing that changes the
format. I want the minor release to start checking the version, so that when we
put out the major release later (which *does* add things to
On Thu, Apr 07, 2016 at 11:01:26AM -0400, Chris Pavlina wrote:
> I'm not sure what you mean by that.
>
> On Thu, Apr 07, 2016 at 04:52:52PM +0200, Marco Ciampa wrote:
> > On Thu, Apr 07, 2016 at 09:47:41AM -0400, Chris Pavlina wrote:
> > [...]
> > > Thoughts?
> >
> > I am not a dev. I KNOW.
> >
I'm not sure what you mean by that.
On Thu, Apr 07, 2016 at 04:52:52PM +0200, Marco Ciampa wrote:
> On Thu, Apr 07, 2016 at 09:47:41AM -0400, Chris Pavlina wrote:
> [...]
> > Thoughts?
>
> I am not a dev. I KNOW.
>
> But... such a change (file and footprint format change) IMHO is not apt
> to (o
On Thu, Apr 07, 2016 at 09:47:41AM -0400, Chris Pavlina wrote:
[...]
> Thoughts?
I am not a dev. I KNOW.
But... such a change (file and footprint format change) IMHO is not apt
to (only) a minor version change...
--
Marco Ciampa
I know a joke about UDP, but you might not get it.
Good point about the footprint files. I'll prepare a patch within a couple days.
On Thu, Apr 07, 2016 at 04:35:05PM +0200, jp charras wrote:
> Le 07/04/2016 15:47, Chris Pavlina a écrit :
> > Hi all,
> >
> > I'm targeting this email primarily at Wayne as versioning and release
> > policy is
> >
Le 07/04/2016 15:47, Chris Pavlina a écrit :
> Hi all,
>
> I'm targeting this email primarily at Wayne as versioning and release policy
> is
> involved.
>
> We've got a bit of a problem right now. We're currently adding features to the
> pcbnew format - JP just merged rounded-rect pads and has a
Hi all,
I'm targeting this email primarily at Wayne as versioning and release policy is
involved.
We've got a bit of a problem right now. We're currently adding features to the
pcbnew format - JP just merged rounded-rect pads and has a patch in development
for custom pads, and I'm looking at a pa
62 matches
Mail list logo
