Hi Jose,
Good catch. Thank you for the patch, I have just committed it.
Regards,
Orson
On 03/07/2017 06:59 AM, José Ignacio Romero wrote:
> When colors were changed to COLOR4D, the original semi-transparent
> colors were lost, making things hard to see in multilayer boards
> without hitting { ma
Hi Julius,
I apologize it has taken me so long to reply. In fact, your patch made
me investigate the problem, as I felt preventing track dragging is a
cure for the symptoms, but not for the cause.
Recently I have made a few changes to the code, and now PNS should not
crash anymore. If this is not
Hi,
Attached patch fixes polylines in GAL: they were drawn always closed
in OpenGL and always open in Cairo.
I think the code could stand a refactor in this area and try to move
the logic into GAL, rather thn duplicating in each implementaiton.
However, since CAIRO_GAL uses the same code for poly
I just tested origin/master and the problem can still be reproduced.
I'm not entirely sure which changes you are referring to.
My patch also does not prevent track dragging, it just breaks the
*routing* coroutine out of its loop, which I would think you have to do
one way or another to avoid t
Is there any objection to applying this patch in its current form? Note
that all it prevents is users accidentally joining pins that are already
invisible AND non-connect.
Cheers,
Oliver
On Wed, Feb 8, 2017 at 11:05 PM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:
> Urgh, patch attach
You are right, I have misinterpreted the issue. With you patch applied
everything works fine. Thank you for your contribution to KiCad.
Regards,
Orson
On 03/07/2017 01:20 PM, Julius Schmidt wrote:
> I just tested origin/master and the problem can still be reproduced.
>
> I'm not entirely sure wh
Hi John,
Thank you for fixing the problem. I have just committed your patch.
Cheers,
Orson
On 03/07/2017 01:11 PM, John Beard wrote:
> Hi,
>
> Attached patch fixes polylines in GAL: they were drawn always closed
> in OpenGL and always open in Cairo.
>
> I think the code could stand a refactor
I have recently noticed some very strange libedit behaviour, where
performing an action on a pin at a given location performs the same action
on all pins at that same location.
Consider the following examples, where two pins are located in the same x,y
position:
Example A - Edit Pin
- Place two p
As an extra note to Example B in the above comment, deleting a pin also
deletes any pins in other units (for multi-unit symbols) that are in the
same location.
On Wed, Mar 8, 2017 at 12:04 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:
> I have recently noticed some very strange libe
Hi,
The attached patch removes boost::context dependency by introducing a
single-file libcontext that automatically detects the compiler &
platform and provides a stable API, contrary to the Boost libs. If you
have some spare time, please test it, in particular on Windows and OSX.
I verified the
Looks good! Wish I had time to test it on OSX or Windows. I'm sure you
know already but it seems to work perfectly on Linux/x86_64 :)
On Tue, Mar 07, 2017 at 02:36:03PM +0100, Tomasz Wlostowski wrote:
> Hi,
>
> The attached patch removes boost::context dependency by introducing a
> single-file li
Cirilo,
Just to be sure I have this correct, I need to apply this patch to the
master branch and build oce with the previous patch you sent correct?
What I intend to do is apply this patch and add the mingw-oce patch to
our patches folder.
@Orson, didn't you create the oce PKGBUILD file for the
Yep, I should have had the tarball uploaded already. I created it last
night. I will sign and upload it tonight.
On 3/7/2017 1:59 AM, Nick Østergaard wrote:
> Yeah, that is fine. I just wanted to make sure since it was not
> created. Ideally it should be created when the tag is made. I will add
Oliver,
Is there any possibility that this will break existing schematic
netlists? I'm assuming this patch only prevents the user from
generating new invisible/no-connect connections.
Is anyone else opposed to this?
Cheers,
Wayne
On 3/7/2017 7:33 AM, Oliver Walters wrote:
> Is there any objec
On 07.03.2017 15:07, Oliver Walters wrote:
As an extra note to Example B in the above comment, deleting a pin also deletes
any pins in other units (for multi-unit symbols) that are in the same location.
This bug appears again and again every year or two.
--
Regards,
Sergey A. Borshch
In aperture-circle-flash-with_hole.gbr, one of the holes should be square.
They are all drawn as circular in 4.x as well as in master, but now
correctly drawn with square hole in my branch.
In apertures_rotated_and_arcs_in_tracks.gbr, some weird artifacts show up
in 4.x in Linux, but I can't repro
How thoroughly? I can build it on macOS and poke around a bit, but I
don't have time to spend a day doing layout with it right now.
On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote:
> It needs to be tested on osx before we commit the patch.
>
> On 3/7/2017 9:24 AM, Maciej Sumiński
It needs to be tested on osx before we commit the patch.
On 3/7/2017 9:24 AM, Maciej Sumiński wrote:
> Brief testing with Win7 x86_64 gives positive results. I really hope
> this is the end of the boost::context nightmare.
>
> Cheers,
> Orson
>
> On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote:
Brief testing with Win7 x86_64 gives positive results. I really hope
this is the end of the boost::context nightmare.
Cheers,
Orson
On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote:
> Hi,
>
> The attached patch removes boost::context dependency by introducing a
> single-file libcontext that autom
2017-03-07 14:40 GMT+01:00 Wayne Stambaugh :
> Cirilo,
>
> Just to be sure I have this correct, I need to apply this patch to the
> master branch and build oce with the previous patch you sent correct?
> What I intend to do is apply this patch and add the mingw-oce patch to
> our patches folder.
>
I'm thinking a valid build and a quick check that the P&S router doesn't
crash should be adequate.
On 3/7/2017 9:32 AM, Chris Pavlina wrote:
> How thoroughly? I can build it on macOS and poke around a bit, but I
> don't have time to spend a day doing layout with it right now.
>
>
> On Tue, Mar 0
On 3/5/2017 3:48 PM, John Beard wrote:
> Hi Wayne,
>
> Thanks for taking a look!
>
> On Mon, Mar 6, 2017 at 3:24 AM, Wayne Stambaugh wrote:
>>
>> It is perfectly acceptable to have an empty global library table and
>> always use the project library table for defining footprint libraries so
>> th
On 3/7/2017 9:35 AM, Nick Østergaard wrote:
> 2017-03-07 14:40 GMT+01:00 Wayne Stambaugh :
>> Cirilo,
>>
>> Just to be sure I have this correct, I need to apply this patch to the
>> master branch and build oce with the previous patch you sent correct?
>> What I intend to do is apply this patch and
Tested, works fine.
By the way, the following commit breaks the build on macOS, and probably
also Linux+clang. I had to revert it to get a successful build:
commit d1550b0cdb990ba1f4f32220e110f8ff6331a5f1
Author: Maciej Suminski
Date: Mon Mar 6 11:41:06 2017 +0100
Renamed VIEW_CONTROLS::S
Thanks for testing this.
I'm surprised the autobuilders didn't flag the build error. Please file
a bug report against this so it doesn't get lost in the mailing list churn.
On 3/7/2017 10:15 AM, Chris Pavlina wrote:
> Tested, works fine.
>
> By the way, the following commit breaks the build on
I use Linux+clang (3.9) and here the compiler does not complain. What is
the error message? Does it really build if you revert only this
particular commit?
Cheers,
Orson
On 03/07/2017 04:15 PM, Chris Pavlina wrote:
> Tested, works fine.
>
> By the way, the following commit breaks the build on ma
On Tue, Mar 07, 2017 at 04:35:44PM +0100, Maciej Sumiński wrote:
> I use Linux+clang (3.9) and here the compiler does not complain. What is
> the error message?
Error dump attached.
> Does it really build if you revert only this
> particular commit?
I also reverted the one directly after it beca
I just tested the 32 bit build on win64 so I'm going to commit this if
there are no objections.
On 3/7/2017 10:15 AM, Chris Pavlina wrote:
> Tested, works fine.
>
> By the way, the following commit breaks the build on macOS, and probably
> also Linux+clang. I had to revert it to get a successful
Thank you Chris, now it should build fine on OSX as well. I really love
compilers screaming so much about such minor things.
Regards,
Orson
On 03/07/2017 04:51 PM, Chris Pavlina wrote:
> On Tue, Mar 07, 2017 at 04:35:44PM +0100, Maciej Sumiński wrote:
>> I use Linux+clang (3.9) and here the compi
Lol, it's a pretty major thing if you look at what std::deque was trying
to do...I don't see any way for the compiler to resolve this with the
implementation of std::deque it was using ;)
Thanks for the quick fix.
On Tue, Mar 07, 2017 at 05:24:14PM +0100, Maciej Sumiński wrote:
> Thank you Chris,
Hi,
Am 07.03.2017 um 07:07 schrieb Cirilo Bernardo:
> The sole difference with the previous patch is that kicad2step.cpp
> was modified to replace:
> wxIMPLEMENT_APP_CONSOLE( KICAD2MCAD );
> with
> wxIMPLEMENT_APP( KICAD2MCAD );
On Windows proper, this means that stdin/stdout/stderr are unava
I realize what was the problem. What I meant is the verbosity of the
error message that could be shortened to 'incomplete type information',
but perhaps a lengthy explanation is sometimes necessary.
On 03/07/2017 05:26 PM, Chris Pavlina wrote:
> Lol, it's a pretty major thing if you look at what s
C++ error messages are _awful_, really.
OT: I wish the language/compiler had a mode to declare certain classes
and templates "opaque", where the compiler would only provide error
messages up to the point where you interact with an object and not
messages from inside it.
Alternatively I'd love a w
Thanks for the patch. I changed the commit message to link a bug report
against boost 1.63 which this patch resolves and pushed it to the master
branch.
Hopefully this will be the last of the libcontext issues but it seems to
me that we've had this conversation before. ;)
On 3/7/2017 8:36 AM, To
I'm currently dealing with this bug:
https://bugs.launchpad.net/kicad/+bug/1670705
Under certain conditions (which I really have not been able to
identify), wx stops firing paint events for certain widgets, only under
Ubuntu Unity. The same exact system switched to GNOME does not have the
issue.
Hi,
Am 07.03.2017 um 14:36 schrieb Tomasz Wlostowski:
> The attached patch removes boost::context dependency by introducing a
> single-file libcontext that automatically detects the compiler &
> platform and provides a stable API, contrary to the Boost libs. If you
> have some spare time, please
On Tue, Mar 07, 2017 at 08:04:17PM +0100, Simon Richter wrote:
> Hi,
>
> Am 07.03.2017 um 14:36 schrieb Tomasz Wlostowski:
>
> > The attached patch removes boost::context dependency by introducing a
> > single-file libcontext that automatically detects the compiler &
> > platform and provides a s
Bleh, found it. Misuse of Freeze()/Thaw().
On Tue, Mar 07, 2017 at 12:39:24PM -0500, Chris Pavlina wrote:
> I'm currently dealing with this bug:
> https://bugs.launchpad.net/kicad/+bug/1670705
>
> Under certain conditions (which I really have not been able to
> identify), wx stops firing paint ev
Congrats. :)
2017-03-07 20:13 GMT+01:00 Chris Pavlina :
> Bleh, found it. Misuse of Freeze()/Thaw().
>
> On Tue, Mar 07, 2017 at 12:39:24PM -0500, Chris Pavlina wrote:
>> I'm currently dealing with this bug:
>> https://bugs.launchpad.net/kicad/+bug/1670705
>>
>> Under certain conditions (which I r
On Wed, Mar 8, 2017 at 12:40 AM, Wayne Stambaugh wrote:
> Cirilo,
>
> Just to be sure I have this correct, I need to apply this patch to the
> master branch and build oce with the previous patch you sent correct?
> What I intend to do is apply this patch and add the mingw-oce patch to
> our patch
On 07.03.2017 20:04, Simon Richter wrote:
> Debian is definitely unhappy when packages drop release architectures,
If someone from Debian who actually has a PPC/sparc machine writes
*here* willing to help us with testing, I have nothing against adding
PPC support.
Tom
___
Attached is a small patch that addresses two usability issues in the label
editor in eeschema:
1. Set wxTextCtrl flag wxTE_RICH so that pressing Ctrl+Backspace deletes an
entire word, rather than inserting a strange character
2. Add numeric validation to the text size field
label-editor.patch
De
Hi Maciej,
I couldn't help notice the descriptions in this email thread to
resemble https://bugs.launchpad.net/kicad/+bug/1657226
Could you check if the the issue fixed here might be present in 4.0.4 or 4.0.5?
Nick
2017-03-07 13:58 GMT+01:00 Maciej Sumiński :
> You are right, I have misinterpre
Hi all,
This patch adds the ability for GAL to draw axes when drawing the grid.
Right now this is only going to be used for GerbView.
Best,
Jon
From 384c6e7ca96421645f69976f695e52733b424469 Mon Sep 17 00:00:00 2001
From: Jon Evans
Date: Tue, 7 Mar 2017 21:33:19 -0500
Subject: [PATCH] Add setting
44 matches
Mail list logo
