If cypress created a Linux release for their tools I would gladly go back
to Linux. Last job was STM32 which had decent Linux support (not through
ST) and I forgot how much "fun" Windows can be.
Again sorry for the distraction.
On Tue, Apr 17, 2018, 6:51 PM Jeff Young wrote:
> It gets points fo
It gets points for one of the stranger ephemera I’ve seen, anyway….
> On 17 Apr 2018, at 23:37, Michael McCormack wrote:
>
> I tried deleting the path from the module, no change to the results.
>
> I in installed Kicad and reinstalled, out works in all cases - I give up, I
> really should s
I tried deleting the path from the module, no change to the results.
I in installed Kicad and reinstalled, out works in all cases - I give up, I
really should stick to Linux. I apologize for wasting everyone's time I
something that we an obvious gift of Windows.
Thanks and sorry
Mike
On Tue, Ap
If I open the board with pcbnew as a separate task, the hole is there; if I
open the board from the kicad project, the hole is not.
Could it be the path back to the schematic is corrupt and therefore opening
the board as part of the project doesn't show the hole?
On Tue, Apr 17, 2018 at 11:50 AM,
Patches merged. Thanks again, Simon!
> On 17 Apr 2018, at 15:19, Simon Richter wrote:
>
> ---
> common/trace_helpers.cpp | 544 +++
> include/trace_helpers.h | 230 ++--
> 2 files changed, 387 insertions(+), 387 deletions(-)
>
> <0004-
Hi Darrell,
Give a holler if you run into questions.
Cheers,
Jeff.
> On 17 Apr 2018, at 17:16, Darrell Harmon
> wrote:
>
> I'm going to make an attempt at a complete patch. It may be a while
> before I get time and I'll have to spend some time learning about Kicad
> internals.
>
> Darrell H
I'm going to make an attempt at a complete patch. It may be a while
before I get time and I'll have to spend some time learning about Kicad
internals.
Darrell Harmon
On Mon, 2018-04-16 at 11:58 -0700, Seth Hillbrand wrote:
> Hi Darrell-
>
> Please see https://bugs.launchpad.net/kicad/+bug/146696
I edited the pcb file with a text editor, moving the module around to other
locations in the file did not fix the problem, moving the pad to other
places on the board also did nothing.
On Tue, Apr 17, 2018 at 8:07 AM, Michael McCormack wrote:
> I have not had any similar problems on other boards
There is no need to reassign these.
---
common/trace_helpers.cpp | 20 ++--
include/trace_helpers.h | 20 ++--
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/common/trace_helpers.cpp b/common/trace_helpers.cpp
index bf5244cf9..5379980fc 100644
--
There was already a string definition that wasn't used, so it's obvious
that was intended.
---
eeschema/lib_pin.cpp | 1 +
eeschema/sch_component.cpp | 2 ++
eeschema/sch_field.cpp | 1 +
eeschema/sch_item_struct.h | 10 --
eeschema/sch_sheet.cpp | 1 +
eeschema/sch_shee
Go ahead and merge the changes. I didn't see anything that was a show
stopper. It was just some housekeeping on my part before tagging rc2
that Simon found some minor issues. Sorry I didn't reply sooner but I'm
in the process of migrating to my new work computer. Hopefully by the
end of the day
---
common/trace_helpers.cpp | 544 +++
include/trace_helpers.h | 230 ++--
2 files changed, 387 insertions(+), 387 deletions(-)
diff --git a/common/trace_helpers.cpp b/common/trace_helpers.cpp
index 5379980fc..5b6ea28a5 100644
--- a/co
Declaration and definition of trace strings differed in constness.
---
common/trace_helpers.cpp | 2 ++
include/trace_helpers.h | 18 +-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/common/trace_helpers.cpp b/common/trace_helpers.cpp
index 8779bf64f..bf5244cf9
Hi,
> Ah wait, no. These make no sense in 5.0, because they are fixes for>
> 81843c37, which isn't in 5.0.
Okay, I definitely need more coffee. Of course when I checked that
commit isn't in origin/5.0, because that branch got deleted ages ago,
which I only noticed when I wanted to set up an MSVC
Hmmm… appears they’re out-of-date. Can you rebase them?
> On 17 Apr 2018, at 15:15, Jeff Young wrote:
>
> Wayne’s change is in master, so it’s going to end up in 5.0.
>
> I’ll go ahead and merge your patches there too. Thanks!
>
>
>> On 17 Apr 2018, at 14:58, Simon Richter wrote:
>>
>> Hi
Wayne’s change is in master, so it’s going to end up in 5.0.
I’ll go ahead and merge your patches there too. Thanks!
> On 17 Apr 2018, at 14:58, Simon Richter wrote:
>
> Hi,
>
> On 17.04.2018 15:54, Simon Richter wrote:
>
>> IMO, these are trivial and should also go into 5.0. The code as is
Hi,
On 17.04.2018 15:54, Simon Richter wrote:
> IMO, these are trivial and should also go into 5.0. The code as is
> compiles because gcc doesn't detect the error. MSVC encodes the type of
> data objects and the return types of functions in the mangled symbol, so
> mismatching declaration and def
Hi Jeff,
On 17.04.2018 15:33, Jeff Young wrote:
> Shall I merge these into 6.0? (They aren’t required for 5.0 are they?)
IMO, these are trivial and should also go into 5.0. The code as is
compiles because gcc doesn't detect the error. MSVC encodes the type of
data objects and the return types o
Hi Simon,
Shall I merge these into 6.0? (They aren’t required for 5.0 are they?)
Cheers,
Jeff.
> On 17 Apr 2018, at 12:20, Simon Richter wrote:
>
> ---
> common/trace_helpers.cpp | 544 +++
> include/trace_helpers.h | 230 ++--
> 2 f
I have not had any similar problems on other boards. It used to be visible
when the hole was in the upper right corner. I moved it out of the way when
I made the big cut in that corner and forgot about it (and I guess it
disappeared so you can understand the forgetting.)
I had serious trouble clos
On 17/04/18 13:28, jp charras wrote:
Le 17/04/2018 à 13:15, Rene Pöschl a écrit :
If i understand it correctly, kicad 5 will offer a check for courtyard
violations.
Does this check come with requirements with regards to the courtyard layer?
In particular: Does the polygon that describes the c
There was already a string definition that wasn't used, so it's obvious
that was intended.
---
eeschema/lib_pin.cpp | 1 +
eeschema/sch_component.cpp | 2 ++
eeschema/sch_field.cpp | 1 +
eeschema/sch_item_struct.h | 10 --
eeschema/sch_sheet.cpp | 1 +
eeschema/sch_shee
Le 17/04/2018 à 13:15, Rene Pöschl a écrit :
> If i understand it correctly, kicad 5 will offer a check for courtyard
> violations.
>
> Does this check come with requirements with regards to the courtyard layer?
>
> In particular: Does the polygon that describes the courtyard need to be
> close
---
common/trace_helpers.cpp | 544 +++
include/trace_helpers.h | 230 ++--
2 files changed, 387 insertions(+), 387 deletions(-)
diff --git a/common/trace_helpers.cpp b/common/trace_helpers.cpp
index 5379980fc..5b6ea28a5 100644
--- a/co
There is no need to reassign these.
---
common/trace_helpers.cpp | 20 ++--
include/trace_helpers.h | 20 ++--
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/common/trace_helpers.cpp b/common/trace_helpers.cpp
index bf5244cf9..5379980fc 100644
--
Declaration and definition of trace strings differed in constness.
---
common/trace_helpers.cpp | 2 ++
include/trace_helpers.h | 18 +-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/common/trace_helpers.cpp b/common/trace_helpers.cpp
index 8779bf64f..bf5244cf9
If i understand it correctly, kicad 5 will offer a check for courtyard
violations.
Does this check come with requirements with regards to the courtyard layer?
In particular: Does the polygon that describes the courtyard need to be
closed? If not how much tolerance is allowed?
Are arcs and ci
Hi Michael,
Are you sure that the file you have sent to the list is the same file
you are openning in pcbnew?
It could be possible you have 2 copies of the same file in different
folders.
I can see the hole in stable and nightly versions, like anyone else but you.
Sorry I can help with a sol
Turned out to either be not as bad as I thought, or most of the work will be in
fixing my 6.0 tree. Either way, I merged it into master.
Should fix:
https://bugs.launchpad.net/kicad/+bug/1749287
https://bugs.launchpad.net/kicad/+bug/1737361
https://bugs.launchpad.net/kicad/+bug/1759756
https://
Do you see this bug on any other boards? If you edit the board in a text
editor to move the mounting hole, is it still invisible?
I can’t figure out why we can’t reproduce this….
> On 17 Apr 2018, at 11:40, Michael McCormack wrote:
>
> I never tried to change setting on the routers, still, n
I never tried to change setting on the routers, still, no better with this
bug regardless.
On Apr 17, 2018 6:23 AM, "Jeff Young" wrote:
Hi Michael,
Odd.
FWIW, if you set the interactive router to “Highlight Collisions” mode it
will put you in the driver’s seat. (I think it then acts more like
Le 17/04/2018 à 00:52, Mário Luzeiro a écrit :
> Hi JP,
>
> since your last commit:
> https://github.com/KiCad/kicad-source-mirror/commit/8fcdc4f6c3fb7c10b4088de11d15d95c4345f9d3
>
> this file also needs to be fixed by adding the GR_KB_SHIFT +
> https://github.com/KiCad/kicad-source-mirror/blob/9
Hi Michael,
Odd.
FWIW, if you set the interactive router to “Highlight Collisions” mode it will
put you in the driver’s seat. (I think it then acts more like Default,
although it’s been so long since I’ve used Default I can’t remember exactly.)
Cheers,
Jeff.
> On 17 Apr 2018, at 11:14, Mi
Hi Michael,
You appear to be in Legacy graphics mode (probably still called “Default” in
4.0.7). Have you tried OpenGL or Cairo graphics mode? (Note that the modes
also change the toolsets, and are a big step up over the default/legacy
toolset.)
Cheers,
Jeff.
> On 17 Apr 2018, at 10:45, Mi
Le 17/04/2018 à 04:41, Jon Evans a écrit :
> I have confirmed that there are no technical challenges with the migration
> plan proposed by Orson.
> I made some quick test code that automatically performs the migration
> silently (i.e. by choosing a
> label randomly from the available ones to keep
Le 17/04/2018 à 03:42, Steven A. Falco a écrit :
> I tried opening the board under Fedora Linux with Kicad 4.0.7 using pcbnew in
> stand-alone mode, and the hole is visible, as shown in the attached
> screen-shot.
>
> Steve
>
> On 04/16/2018 09:30 PM, Jon Evans wrote:
>> I tested on Ubunt
36 matches
Mail list logo
