Simon,
I'm ready to push this patch set. I'm assuming this is the same changes
as the merge request. If not please let me know.
Cheers,
Wayne
On 7/4/2019 12:05 PM, Simon Richter wrote:
> Hi,
>
> another attempt at getting the MSVC patchset merged. :)
>
> The mails with the patches are for
Hi Seth,
That change was intentional. The worry is that we could be sending our zone
performance to hell without noticing. By making the default CHOP_ACUTE_CORNERS
we can fix things that should be rounded, and other things will be performant.
However, I can see that it does sort of depend on
Replying to myself here... :)
I found the issue. The polygon rounding default was changed for
inflate/deflate parameters. This changes many, many things in pcbnew
from clearance to gerbers.
I've reset the default to rounding as it was before. The option for
changing individual calls
Thanks Simon. I pushed a fix for this that partially reverts the commit
1a7cef2950a89959e76dc7b5de259b3b022a7f2e to fix the issue.
-Seth
On 2019-07-15 06:55, Simon Richter wrote:
Hi,
we have a failing test, consistent on all tested platforms:
[Error] - check common.holeyPolySet.Collide(
Simon,
On 7/12/2019 4:00 PM, Simon Richter wrote:
> Hi Wayne,
>
>> I have to apply the patches, build, and test. I should be able to get
>> to it over the weekend. My only comment is on patch #1. I would have
>> preferred that we implemented the missing boost pointer container object
>> clone
One of the recent changes seems to have broken the rectangle rounding.
Currently, all rounded rectangles are 90° corners for all operations
Launchpad bug tracker is down (again), so no bug report atm.
-S
___
Mailing list:
Whoops! Excuse me while I go face-palm...
Thanks for checking this.
-Seth
On 2019-07-16 10:38, Jeff Young wrote:
Hi Seth,
We’re not adding that curve; it’s in the Eagle file:
rank="2">
On 16 Jul 2019, at 13:43, Seth Hillbrand wrote:
Hi Jeff-
That one was the Due reference
Hi,
"GCC has full support for the previous revision of the C++ standard,
which was published in 2014." [gcc official documentation]
gcc documentation also reports that gcc6 supports c++14, excluding the
"Clarifying memory allocation" language feature.
If you are interested in it, a list of
Hi Seth,
We’re not adding that curve; it’s in the Eagle file:
> On 16 Jul 2019, at 13:43, Seth Hillbrand wrote:
>
> Hi Jeff-
>
> That one was the Due reference design [1] but for me it happens on all Eagle
> zones.
>
> -Seth
>
> [1]
Hi,
On Tue, Jul 16, 2019 at 03:24:14PM +0100, Jeff Young wrote:
> I assume gcc 6 is still new enough to support C++14?
It didn't complain about -std=g++14, so the answer is a resounding "maybe".
Simon
___
Mailing list:
Ahh, cool.
I assume gcc 6 is still new enough to support C++14?
Cheers,
Jeff.
> On 16 Jul 2019, at 15:20, Simon Richter wrote:
>
> Hi Jeff,
>
> On Tue, Jul 16, 2019 at 03:13:43PM +0100, Jeff Young wrote:
>
>> Wow. I thought gcc was a “real” compiler. ;)
>
> To be fair, that is gcc 6 only,
Hi Jeff,
On Tue, Jul 16, 2019 at 03:13:43PM +0100, Jeff Young wrote:
> Wow. I thought gcc was a “real” compiler. ;)
To be fair, that is gcc 6 only, which is in Debian oldstable (so we need to
support it for a year or so still). gcc 7 doesn't have that problem.
Simon
Wow. I thought gcc was a “real” compiler. ;)
Change pushed. It’ll probably fix it, but then lldb handled it fine to start
with so I can’t be sure.
Cheers,
Jeff.
> On 16 Jul 2019, at 14:57, Dino Ghilardi wrote:
>
> I see that too (linux - Debian 9.9), same error got from line 455.
>
> I
This causes an error
lvalue required as unary '&' operand
when compiling with ancient gcc. Declaring it static in addition to
constexpr works around the problem.
---
eeschema/tools/sch_editor_control.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
I see that too (linux - Debian 9.9), same error got from line 455.
I tried also a "git clean -fx" and a clean build to see if it was from
an auto-generated file, but the problem persists, also using cmake to
re-generate everygthing.
--
Hi Jeff-
That one was the Due reference design [1] but for me it happens on all
Eagle zones.
-Seth
[1] https://content.arduino.cc/assets/DUE-reference.zip
On 2019-07-16 08:16, Jeff Young wrote:
Hi Seth,
I’m not seeing the same behaviour. Could you send me the Eagle file
you were using
Hi Seth,
I’m not seeing the same behaviour. Could you send me the Eagle file you were
using for that screen-shot?
Thanks,
Jeff.
> On 16 Jul 2019, at 12:47, Jeff Young wrote:
>
> Actually, something fishy is going on with the MiterLimit. It should be
> rounding the fill, but not the
Actually, something fishy is going on with the MiterLimit. It should be
rounding the fill, but not the outline (even in strategy (a))….
> On 16 Jul 2019, at 10:12, Jeff Young wrote:
>
> We need to go to strategy (b) to fix that (use the zone’s fillet radius to
> round the corners).
>
> I’ll
Le 16/07/2019 à 12:00, Nick Østergaard a écrit :
> Without speculating too much about the subject, I would expect it to
> be case sensitive. Having stuff case insensitive other than in a
> search box seem like trouble to me.
I agree with Nick:
Label comparison is case sensitive, therefore I am
It looks like some of the errors are related to the lexer stuff. Can
you try to rebase your branch to latest master?
On Tue, 16 Jul 2019 at 13:00, Nick Østergaard wrote:
>
> @Tomasz Wlostowski I am trying to build against wx3.1, but I get
> build errors, please review the build log:
>
>
@Tomasz Wlostowski I am trying to build against wx3.1, but I get
build errors, please review the build log:
https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/465/console
On Tue, 16 Jul 2019 at 12:37, Nick Østergaard wrote:
>
> Hmm, ok, I guess you mean the -may27 one.. it seem to
Hmm, ok, I guess you mean the -may27 one.. it seem to have never commits.
https://github.com/twlostow/kicad-dev/tree/tom-crash-reporter-may27
On Tue, 16 Jul 2019 at 11:08, Tomasz Wlostowski
wrote:
>
> On 15/07/2019 14:43, Nick Østergaard wrote:
> > Remind me, is this feature still in a seperate
Hello Devs,
Currently I see this error on master:
/var/lib/jenkins/workspace/linux-kicad-head/src/eeschema/tools/sch_editor_control.cpp:
In lambda function:
/var/lib/jenkins/workspace/linux-kicad-head/src/eeschema/tools/sch_editor_control.cpp:496:92:
error: lvalue required as unary '&' operand
Without speculating too much about the subject, I would expect it to
be case sensitive. Having stuff case insensitive other than in a
search box seem like trouble to me.
On Tue, 16 Jul 2019 at 11:43, Tomasz Wlostowski
wrote:
>
> Hi,
>
> I have design with a multi-row connector with pins labeled
Hi,
I have design with a multi-row connector with pins labeled BGA-style
(a1, a2, etc.). I noticed the footprint for the same symbol in my
library has the pad names in uppercase (A1, A2) and so the netlister
doesn't connect these pins.
Is this the expected behaviour or should we make the pin/pad
We need to go to strategy (b) to fix that (use the zone’s fillet radius to
round the corners).
I’ll look into it….
> On 16 Jul 2019, at 02:37, Seth Hillbrand wrote:
>
> Hi Jeff-
>
> I just checked a couple of Eagle boards and the imports are now slightly
> problematic. See the attached
On 15/07/2019 14:43, Nick Østergaard wrote:
> Remind me, is this feature still in a seperate branch to master, or
> how is it enabled?
IIRC it's still tom-crash-reporter on my github and it's enabled in
CMake config (KICAD_CRASH_REPORTER=yes).
T.
>
> On Thu, 11 Jul 2019 at 21:08, Nick
Well, relatively speaking, KiCad has been releasing at a breakneck pace
lately :)
On Mon, Jul 15, 2019 at 11:51 AM Wayne Stambaugh
wrote:
> Oops, sorry about that. Should read 5.1.3.
>
> On 7/15/2019 12:50 PM, Steven A. Falco wrote:
> > On 7/15/19 12:26 PM, Wayne Stambaugh wrote:
> >> Were do
28 matches
Mail list logo
