Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Tomasz Wlostowski]

On 10.10.2016 14:59, "Torsten Hüter" wrote:
> I'm guessing that Altium PCB using a special primitive for stitch vias
> as well.

Hi Torsten,

I don't think so (Altium 15 here). It just groups ordinary vias into an
union (another feature people have been asking for).

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Tomasz Wlostowski]

On 10.10.2016 14:16, Strontium wrote:
> On 10/10/16 19:43, Tomasz Wlostowski wrote:
>> On 10.10.2016 07:25, Strontium wrote:
>>> On 09/10/16 23:11, Wayne Stambaugh wrote:
>>>> On 10/8/2016 1:20 PM, Nox wrote:
>>>>
>>>> There is nothing here that has not been discussed before.  The reason
>>>> that freely assigning nets to vias has not been implemented is that
>>>> every implementation is a compromise.  If we allow random net naming of
>>>> vias, all manner of bad things can happen that are completely out of
>>>> the
>>>> control of kicad.  Instead of your wtf moment being some tracks and
>>>> vias
>>>> with no associated net being ripped up when you import a new netlist,
>>>> your wtf moment is a stack useless pcbs that you just spend money
>>>> on.  I
>>> Wayne, respectfully this is where I believe you have missed the point.
>>> If a designer assigns a net to a via, then THEY are responsible for the
>>> WTF moment.  IF Kicad rips up the nets the designer assigned to vias
>>> then KICAD is responsible for the WTF moment.  In one case the designer
>>> screwed up and in the other Kicad screwed the designer over.
>>>
>>> Its as simple as that.
>>>
>>> My original patch, posted many moons ago, fixed this problem neatly.  It
>>> did not allow a user to assign arbitrary nets, but if you plonked a via
>>> on a GND fill, it had a GND net, and that via would ALWAYS have a GND
>>> net until you did something explicitly to change it.
>> Don't shout man What if your board has more than two layers. For
>> instance, there's a full VCC plane on one internal layer and another
>> full GND plane on another internal layer? Which plane the via you place
>> would belong to if vias were to take their nets from copper fills?
>>
>> Cheers,
>> Tom
>>
> Hi Tom,
> 
> Its very simple, you place the via on the layer you want to stitch.
> Just like when you want to lay a track.

Aah, so the the net would be assigned right after the placement. I
perhaps misunderstood you. Looks OK for me.

Tom





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew - enable editing of associated net for tracks

[Tomasz Wlostowski]

On 10.10.2016 07:25, Strontium wrote:
> On 09/10/16 23:11, Wayne Stambaugh wrote:
>> On 10/8/2016 1:20 PM, Nox wrote:
>>
>> There is nothing here that has not been discussed before.  The reason
>> that freely assigning nets to vias has not been implemented is that
>> every implementation is a compromise.  If we allow random net naming of
>> vias, all manner of bad things can happen that are completely out of the
>> control of kicad.  Instead of your wtf moment being some tracks and vias
>> with no associated net being ripped up when you import a new netlist,
>> your wtf moment is a stack useless pcbs that you just spend money on.  I
> Wayne, respectfully this is where I believe you have missed the point. 
> If a designer assigns a net to a via, then THEY are responsible for the
> WTF moment.  IF Kicad rips up the nets the designer assigned to vias
> then KICAD is responsible for the WTF moment.  In one case the designer
> screwed up and in the other Kicad screwed the designer over.
> 
> Its as simple as that.
> 
> My original patch, posted many moons ago, fixed this problem neatly.  It
> did not allow a user to assign arbitrary nets, but if you plonked a via
> on a GND fill, it had a GND net, and that via would ALWAYS have a GND
> net until you did something explicitly to change it.  

Don't shout man What if your board has more than two layers. For
instance, there's a full VCC plane on one internal layer and another
full GND plane on another internal layer? Which plane the via you place
would belong to if vias were to take their nets from copper fills?

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] kicad promotion in help menu

[Tomasz Wlostowski]

On 06.10.2016 08:13, Cirilo Bernardo wrote:
> Hi folks,
> 
>  Any comments on this patch I proposed a few weeks ago?
> 
> https://lists.launchpad.net/kicad-developers/msg26412.html
> 
> The patch adds a menu item in the main menu Help list to launch the
> system's default browser and bring up the "Contribute to KiCad" page

I'm in for it! ;-)

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Spice simulator: need info about net names versus net number option

[Tomasz Wlostowski]

On 14.09.2016 10:24, jp charras wrote:
> Hi Orson, Tomasz:
> 
> Recently, I tried to remove a fully outdated spice option netlist: use net 
> numbers or net names.
> I am thinking it is not needed by spice simulators since 20 years.
> 
> But I saw it is still used in our spice simulator.
> This is very easy to change, but my question is:
> Is it a reason (calculation time or something else) to use net numbers 
> instead of net names in
> Kicad/ngspice simulator and which prevent me to use only net names (and 
> remove useless old code)?
> 
Hi Jean-Pierre,

I don't think we had any particular reason for choosing to use numbers
other than old habits. You can enable net names in spice netlists.

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Bezier curves in DRAWSEGMENT class

[Tomasz Wlostowski]

Hi all,

Looking at the sources of the DRAWSEGMENT class (with the hopes of
refactoring it a bit to enable arbitrary copper shapes), I noticed that
it supports Bezier curves. They are also supported by the file format
parser/writer. There's however no drawing tool for these. Is this some
outdated code that can be removed or do we plan to support Bezier curves
in PCBnew?

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] "Multichannel signed distance field" font rendering

[Tomasz Wlostowski]

On 10.09.2016 17:05, Michael Steinberg wrote:
> Hello there,
> 
> I've been working on trying to solve the blurred font issue in the
> OpenGL canvas. The current state of the work can be found in my branch
> "sdf" ( https://code.launchpad.net/~decimad/kicad/+git/kicad/+ref/sdf ).
> It uses a technique called "multichannel signed distance field" to
> recreate clear edges and corners in high zoom situations. The code is
> not polished for commiting yet! A motivational comparison screenshot
> before/after: https://s10.postimg.io/k00tnaax5/comparison.png
> 
> It would be great if brave members could test the branch to see if it
> runs well on different hardware levels and if you are happy with the
> visuals.

Hi Michael,

Just tried it. Works like a charm and looks beautiful. Many thanks!

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

[Tomasz Wlostowski]

On 07.09.2016 21:24, Wayne Stambaugh wrote:
> Tom,
> 
> I also forgot to mention there were tabs in the CMakeLists.txt file.
> 
Hi Wayne,

Here's a (hopefully) fixed version.

Cheers,
Tom

> Cheers,
> 
> Wayne
> 
> On 9/7/2016 12:17 PM, Tomasz Wlostowski wrote:
>> Hi,
>>
>> This patch adds possibility to build C++ tests for pcbnew, using
>> Boost.Test framework. I intended it primarily to make tests for the P,
>> which I used to develop out-of-tree before.
>>
>> Since Kicad's codebase is rather monolithic, testing/refactoring
>> anything drags in pretty much everything else in the code as a
>> dependency.  This causes long rebuild and linking times, which I find
>> very annoying. Also, while developing new features, most of the time is
>> spent linking pcbnew and clicking in the GUI to trigger the particular
>> feature.
>>
>> For that reason I decided to link all the test cases directly to the
>> _pcbnew_kiface library and skip pcbnew's dependency scanning when
>> building tests. I'm also preparing a bare PCB test window for verifying
>> interactive/graphical operations without rebuilding pcbnew as a whole app.
>>
>> I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
>> There's one trivial unit test included as an example. Let me know if
>> such solution would be acceptable.
>>
>> Cheers,
>> Tom
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

>From 287624c8bee0c6d3c05877c41533fc90b3ab2523 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= <tomasz.wlostow...@cern.ch>
Date: Wed, 7 Sep 2016 17:53:20 +0200
Subject: [PATCH] Initial support for unit tests in pcbnew using Boost.Test

---
 CMakeLists.txt   | 32 ++--
 pcbnew/CMakeLists.txt| 12 
 tests/CMakeLists.txt | 15 +++
 tests/pns/CMakeLists.txt |  3 +++
 tests/pns/test_node.cpp  | 21 +
 5 files changed, 73 insertions(+), 10 deletions(-)
 create mode 100644 tests/CMakeLists.txt
 create mode 100644 tests/pns/CMakeLists.txt
 create mode 100644 tests/pns/test_node.cpp

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bfeaac5..b3371f6 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -49,6 +49,9 @@ option( KICAD_USE_OCE
 "Build tools and plugins related to OpenCascade Community Edition (default OFF)"
 )
 
+option( KICAD_BUILD_TESTS
+"Builds C++ tests (default OFF)"
+)
 # when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
 # PYTHON_EXECUTABLE can be defined when invoking cmake
 # ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -69,10 +72,14 @@ option( KICAD_SPICE "Build Kicad with internal Spice simulator." OFF )
 set( KICAD_REPO_NAME "product" CACHE STRING "Name of the tree from which this build came." )
 
 
-# Global setting: exports are explicit
-set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
-set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
-
+# Global setting: exports are explicit by default
+if ( KICAD_BUILD_TESTS )
+set( CMAKE_CXX_VISIBILITY_PRESET "default" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN OFF )
+else()
+set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
+endif()
 
 # Global setting: build everything position independent
 set( CMAKE_POSITION_INDEPENDENT_CODE ON )
@@ -93,11 +100,13 @@ if( POLICY CMP0063 )
 cmake_policy( SET CMP0063 NEW )
 endif()
 else()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
-endif()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
+if( CMAKE_CXX_VISIBILITY_PRESET STREQUAL "hidden" )
+if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
+set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
+endif()
+if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
+set( CMAKE_CXX_FLAGS 

[Kicad-developers] [RFC] [PATCH] simple C++ tests

[Tomasz Wlostowski]

Hi,

This patch adds possibility to build C++ tests for pcbnew, using
Boost.Test framework. I intended it primarily to make tests for the P,
which I used to develop out-of-tree before.

Since Kicad's codebase is rather monolithic, testing/refactoring
anything drags in pretty much everything else in the code as a
dependency.  This causes long rebuild and linking times, which I find
very annoying. Also, while developing new features, most of the time is
spent linking pcbnew and clicking in the GUI to trigger the particular
feature.

For that reason I decided to link all the test cases directly to the
_pcbnew_kiface library and skip pcbnew's dependency scanning when
building tests. I'm also preparing a bare PCB test window for verifying
interactive/graphical operations without rebuilding pcbnew as a whole app.

I've attached the patch (set the KICAD_BUILD_TESTS=ON option to enable).
There's one trivial unit test included as an example. Let me know if
such solution would be acceptable.

Cheers,
Tom

>From fb308460da32cb7a30e66f0c114ac3a0a159ef60 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= 
Date: Wed, 7 Sep 2016 17:53:20 +0200
Subject: [PATCH] Initial support for unit tests in pcbnew using Boost.Test

---
 CMakeLists.txt   | 34 +++---
 pcbnew/CMakeLists.txt| 12 
 tests/CMakeLists.txt | 10 ++
 tests/pns/CMakeLists.txt |  3 +++
 tests/pns/test_node.cpp  | 21 +
 5 files changed, 69 insertions(+), 11 deletions(-)
 create mode 100644 tests/CMakeLists.txt
 create mode 100644 tests/pns/CMakeLists.txt
 create mode 100644 tests/pns/test_node.cpp

diff --git a/CMakeLists.txt b/CMakeLists.txt
index bfeaac5..0dbd735 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -49,6 +49,9 @@ option( KICAD_USE_OCE
 "Build tools and plugins related to OpenCascade Community Edition (default OFF)"
 )
 
+option( KICAD_BUILD_TESTS
+"Builds C++ tests (default OFF)"
+)
 # when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
 # PYTHON_EXECUTABLE can be defined when invoking cmake
 # ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -69,10 +72,14 @@ option( KICAD_SPICE "Build Kicad with internal Spice simulator." OFF )
 set( KICAD_REPO_NAME "product" CACHE STRING "Name of the tree from which this build came." )
 
 
-# Global setting: exports are explicit
-set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
-set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
-
+# Global setting: exports are explicit by default
+if ( KICAD_BUILD_TESTS )
+set( CMAKE_CXX_VISIBILITY_PRESET "default" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN OFF )
+else()
+set( CMAKE_CXX_VISIBILITY_PRESET "hidden" )
+set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
+endif()
 
 # Global setting: build everything position independent
 set( CMAKE_POSITION_INDEPENDENT_CODE ON )
@@ -93,12 +100,14 @@ if( POLICY CMP0063 )
 cmake_policy( SET CMP0063 NEW )
 endif()
 else()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
-endif()
-if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
-set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
-endif()
+if( CMAKE_CXX_VISIBILITY_PRESET STREQUAL "hidden" )
+		if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
+	set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
+		endif()
+		if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
+		set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
+		endif()
+	endif()
 endif()
 
 
@@ -503,7 +512,7 @@ find_package( Cairo 1.8.8 REQUIRED )
 #
 # Note: Prior to Boost 1.59, the Boost context library is not built when compiling on windows
 #   with GCC.  You must patch the Boost sources.
-find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread )
+find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread unit_test_framework )
 
 # Include MinGW resource compiler.
 include( MinGWResourceCompiler )
@@ -804,6 +813,9 @@ add_subdirectory( kicad )   # should follow pcbnew, eeschema
 add_subdirectory( tools )
 add_subdirectory( utils )
 add_subdirectory( qa )
+if ( KICAD_BUILD_TESTS )
+add_subdirectory( tests )
+endif()
 
 # Resources
 add_subdirectory( demos )
diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index c4aff51..5ce31a0 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -578,6 +578,18 @@ set_target_properties( pcbnew_kiface PROPERTIES
 SUFFIX  ${KIFACE_SUFFIX}
 )
 
+if ( KICAD_BUILD_TESTS )
+if ( UNIX )
+	add_custom_command(TARGET pcbnew_kiface POST_BUILD
+	 COMMAND ln -sf _pcbnew.kiface lib_pcbnew_kiface.so )
+else()
+	

[Kicad-developers] CMake visibility options question

[Tomasz Wlostowski]

Hi,

I'm trying to build the kiface DLLs with all symbols exported so that I
could link them to external test programs (e.g. P test cases).

AFAIK symbol visibility is normally controlled in CMake by through the
CMAKE_CXX_VISIBILITY_PRESET variable. However, the following code in the
CMakeLists.txt file forces the symbol visibility to hidden:

-- snip --

if( POLICY CMP0063 )
cmake_policy( GET CMP0063 VISIBILITY_POLICY )
if( VISIBILITY_POLICY STREQUAL NEW )
message( WARNING "Compatibility code for CMake < 3.3 can be
removed, search for CMP0063" )
else()
cmake_policy( SET CMP0063 NEW )
endif()
else()
if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY AND NOT APPLE )
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}
${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY}hidden" )
endif()
if( CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN AND NOT APPLE )
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}
${CMAKE_CXX_COMPILE_OPTIONS_VISIBILITY_INLINES_HIDDEN}" )
endif()
endif()

-- snip --

Could anybody explain what is this code for and if it's really needed
(or maybe it's buggy)?

As a side comment, is there any practical reason to link with
-fvisibility=hidden (maybe except the stable releases)?

Cheers,
Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] OCE plugin for 3D viewer

[Tomasz Wlostowski]

On 01.09.2016 10:30, Cirilo Bernardo wrote:
> Just a ping to remind devs of a branch introducing the OCE plugin:
> 
> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+merge/303513
> 
> Since the OCE plugin code must be activated with -DUSE_OCE=ON
> when configuring with CMake, I think it's safe to include this code. Having
> the code in the main base will make it easier for other volunteers to help
> sort out build and deployment issues of the OCE plugin on Windows and
> OSX.

Hi Cirilo,

I fully agree to merge the OCE plug-in code. Users have been desperately
asking for ages for STEP & IGES support in the 3d-viewer ;-)

@Wayne/@Orson: since this is optional, are there any obstacles for the
merge?

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] kicad

[Tomasz Wlostowski]

On 19.08.2016 18:46, Chris Pavlina wrote:
> This morning's PNS happy fun time:
> 
> https://misc.c4757p.com/track_hugging.mp4
> 
> Why is it so hard to get PNS to "hug" a trace like that? It seems to
> have trouble going around corners - it "snaps in" if I come up on an
> edge, but going around a corner it insists on sticking to the grid...

Hi Chris,

It's not very hard, but sharing your PCB design could help here
(including grid/clearance settings ;-)

Tom
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] DRC: do not close and reopen progress dialog

[Tomasz Wlostowski]

On 12.08.2016 15:22, Chris Pavlina wrote:
> - Netlist generation. I had a go at rewriting the algorithm for this
>   (it's O(n^3) and doesn't need to be...) but didn't get very far with
>   limited time.
Do you mean ratsnest?

Cheers,
T.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] DRC: do not close and reopen progress dialog

[Tomasz Wlostowski]

On 12.08.2016 02:32, Chris Pavlina wrote:
> I'm running into an extremely irritating UI bug with DRC on this big
> board - halfway through DRC, the progress dialog is torn down and
> reopened. DRC is taking two full minutes with this board, which means I
> invariably do something else while it runs


Hi Chris,

Could you send me your PCB? I'd be very glad to use it as a benchmark
for faster DRC algorithm in the future.

Cheers,
Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RAII for the PNS_ROUTER

[Tomasz Wlostowski]

On 04.08.2016 22:59, Michael Steinberg wrote:
> Hello all,
> 
> up to the most current version of the router code I could get hold of,
> it is leaking much memory (eventually resulting in std::bad_alloc) on
> iterative stuff like dragging. I was also made aware of bugs like
> "https://bugs.launchpad.net/kicad/+bug/1553804;. Now this stuff is a
> complex beast, and I'm nowhere any near fluent with it. But it's also
> very interesting to me algorithm-wise. I believe that the original devs
> at this point are the only ones that could really spot leaks and
> segfaults in it with a reasonable time effort, might be wrong though.
> 
> It is my experience though, that such bugs usually surface while
> transforming source code to a more rigid RAII source-style with clear
> and enforced ownership. I would be totally willing to fight myself
> through the sources, trying to transform it without change in behaviour,
> but getting that right will probably reveal misconceptions on my side
> and it will also touch a huge amount of lines in the end and take quite
> a while. I might even feel forced to ask people for support.
> 

Hi Michael,

I'm very glad that you want to tackle tackle the memory management
issues in the P code. When I started writing it, I didn't have a clear
idea of the router's design because I had never written a push-and-shove
router before... Also my C++ skills 3 years ago were probably a bit
worse, so there's a bit of technical debt in the code.

Just to start: the ownership rules go as follows:
- PNS_ITEM and derivatives are owned by a PNS_NODE they've been added
to. Calling PNS_NODE::Remove on an item does not release it's memory -
it has to be freed by the caller.
- PNS_LINE or PNS_JOINT never own PNS_ITEMs.
- PNS_NODEs that are not root (PNS_NODE::IsRoot() == false) belong to
the root PNS_NODE.
- world node (root) belongs to PNS_ROUTER.
- PNS_ROUTER and PNS_KICAD_IFACE belong to PNS_TOOL_BASE.
- PNS_ALGO_BASE derivatives belong to PNS_ROUTER.

The tricky bits are:
- node stack kept by the PNS_SHOVE algorithm for springback and their
interaction with PNS_OPTIMIZER. At some point I desperately wrote an
ugly "garbage collector" freeing all items allocated by PNS_SHOVE class
upon its destruction, later on I removed it and refactored the code a
bit but some leaks probably still remain.
- items passed outside the scope of the current algorithm (e.g. what
PNS_DRAGGER/PNS_SHOVE::Traces() returns for DisplayItems() ). I guess a
shared pointer might help here.

PS. I'm going to push patches to P tonight that fix some issues
reported on the bug tacker. You could start your work on top of these.

Many thanks again,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GAL cursor snap behavior

[Tomasz Wlostowski]

On 26.07.2016 22:35, Chris Pavlina wrote:
> ...maybe we should rethink the behavior of cursor-snapping in GAL a
> bit...
> 
> https://misc.c4757p.com/gal_snap_insanity.mp4
> 
> At best it's very distracting, at worst it can make it nearly impossible
> to select certain pads...
> 
Hi Chris,

I think it's time to make GAL respect the magnetic pads/tracks/none
settings in the preferences dialog and/or enable trace snapping only on
the current layer. Any other ideas?

Tom
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Integrated Simulator

[Tomasz Wlostowski]

On 22.07.2016 14:28, Chris Pavlina wrote:
> On Fri, Jul 22, 2016 at 10:54:27AM +0200, Tomasz Wlostowski wrote:
>> On 21.07.2016 23:16, Chris Pavlina wrote:
>>> Really, really nice! I made it do a thing! 
>>> https://misc.c4757p.com/kicad_sim.png
>>>
>>> I feel bad to provide a bug report on my very first communcation on
>>> this, but... found one: not sure if this sort of thing is actually
>>> standard SPICE or an LTspice extension, but I tried parameterizing a
>>> component value, setting a resistor's value to {R} - that sort of thing
>>> leads to irrecoverable lockups here.
>>>

Hi Chris,

Check with a debugger if it freezes inside ngspice yes_or_no() function
which prompts the user on the console whether to continue or not. It
seems you have an error in your circuit. NgSPICE DLL does not have all
communication channels redirected to the callback functions, some of
them include reporting problems with parametrizable components.

If this is the case, we should contact NGSpice team to fix this (or send
them a patch ;-)

Tom

PS. Could you upload the circuit that triggers the freeze?


>>
>> Hi Chris,
>>
>> Two quick questions:
>> - Do you have NGspice compiled with XSPICE support?
>> - Could you run eeschema with forced "C" locale?
> 
> Yup, ngspice has XSPICE support compiled in. Forcing C locale changes
> the behavior slightly but doesn't fix it:
> 
> With default locale (en_US.utf8), a simple circuit consisting of a
> voltage source V=12 and a resistor {R} with the parameter left
> unspecified freezes kicad completely (can only be quit by SIGTERM). With
> C locale, this doesn't seem to cause a freeze, but after attempting
> to specify that parameter by adding ".param R 12", *then* it freezes.
> 
>>
>> Tom
>>> On Thu, Jul 21, 2016 at 09:37:57PM +0200, Tomasz Wlostowski wrote:
>>>> Hi,
>>>>
>>>> As some of you have noticed, we've been working on a "secret" feature
>>>> during the hackathon at CERN. The feature we're talking about is an
>>>> integrated circuit simulator. Currently it features:
>>>> - Seamless integration into schematic editor,
>>>> - AC/Transient/DC sweep simulations,
>>>> - Voltage probing from the schematics,
>>>> - Live tuning of component values.
>>>>
>>>> A video demonstrating the capabilities of the new simulator is available
>>>> on Tom's YouTube channel [1].
>>>>
>>>> The code is currently available in the ngspice branch on Tom's GitHub
>>>> [2] for review & testing. It's a big feature, so we didn't want to push
>>>> it immediately to the product branch. We'll greatly appreciate your
>>>> feedback!
>>>>
>>>> The simulator uses ngspice [3] as the Spice kernel. We'd like to thank
>>>> ngspice developers for providing a DLL interface which made seamless
>>>> integration of ngspice into Kicad possible.
>>>>
>>>> In order to get started:
>>>> - install ngspice shared library (is not provided by many Linux distros,
>>>> Arch Linux is a known exception, so you might have to compile it from
>>>> the sources with --with-ngshared --enable-xspice options).  Windows
>>>> DLLs, msys2 PKGBUILD & binary packages (to be included soon in
>>>> the official msys2 repo, currently merged to
>>>> https://github.com/Alexpux/MINGW-packages/) & Linux script to build the
>>>> library are available at [4].
>>>> - compile eeschema with -DKICAD_SPICE=ON option,
>>>> - have a look at some examples in demos/simulation directory.
>>>>
>>>> Happy simulating,
>>>> Tom
>>>>
>>>> [1] https://youtu.be/A2_-hdRcf4U
>>>> [2] https://github.com/twlostow/kicad-dev/tree/ngspice
>>>> [3] http://ngspice.sourceforge.net/
>>>> [4] https://orson.net.pl/pub/libngspice
>>>>
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Integrated Simulator

[Tomasz Wlostowski]

On 22.07.2016 13:36, jp charras wrote:
> Le 22/07/2016 à 13:15, jp charras a écrit :
>> Le 22/07/2016 à 11:59, Tomasz Wlostowski a écrit :
>>> On 22.07.2016 11:56, Eldar Khayrullin wrote:
>>>> Note: can't find init file.
>>>
>>> This is the problem, ngspice can't find its internal init file. Did you
>>> install it in your system or just copied the DLL?
>>>
>>> Tom
>>>
>>
>> Because I have the same issue:
>>
>> I just copied the dll.
>>
>> What is the internal init file?
>> And where it should be copied.
>>
>> One cannot expect it is in a system folder, especially on windows.
>>
> 
> Hi Tom,
> 
> After more tests:
> 
> In all cases I have the message:
> Note: can't find init file.
> 
> However:
> * sallen_key does not work at all (as said previously)
> * laser_driver runs but gives the message:
> doAnalyses: Too many iterations without convergence
> run simulation(s) aborted
> * rectifier works!
> 
Hi JP,

You need the init files and XSPICE extensions. I'll provide an updated
Windows package.

Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Integrated Simulator

[Tomasz Wlostowski]

On 22.07.2016 11:56, Eldar Khayrullin wrote:
> Note: can't find init file.

This is the problem, ngspice can't find its internal init file. Did you
install it in your system or just copied the DLL?

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Integrated Simulator

[Tomasz Wlostowski]

On 22.07.2016 11:42, Эльдар Хайруллин wrote:
> To compile the libspice I use the script from your
> link https://orson.net.pl/pub/libngspice/linux/.
> 
Does it show an error "unable to execute init file" or something like this?

Tom
> Пятница, 22 июля 2016, 12:14 +03:00 от Tomasz Wlostowski
> <tomasz.wlostow...@cern.ch>:
> 
> On 22.07.2016 11:11, Eldar Khayrullin wrote:
> > Opening the sallen_key.sch with eeschema show in the log window:
> >
> > 1) Note: can't find init file.
> >
> > 2) Error: .include filename missing
> > If delete ".include diodes.lib" - OK.
> >
> > 3) Error on line 0 : a$poly$e.xu1.eos %vd [ xu1.53 xu1.98 ] %vd (
> xu1.3
> > 2 ) a$poly$e.xu1.eos
> 
> Hi Eldar,
> 
> Compile ngspice with --enable-xspice option.
> 
> Tom
> 
> > MIF-ERROR - unable to find definition of model a$poly$e.xu1.eos
> > Warning: Model issue on line 0 : .model a$poly$e.xu1.eos
> spice2poly coef
> > = [ 1.7e-3 1 ] ...
> > Unknown model type spice2poly - ignored
> > Error on line 0 : a$poly$e.xu1.eref1 %vd [ 4 0 5 0 ] %vd ( xu1.98 0 )
> > a$poly$e.xu1.eref1
> > MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref1
> > Warning: Model issue on line 0 : .model a$poly$e.xu1.eref1 spice2poly
> > coef = [ 0 0.5 0.5 ...
> > Unknown model type spice2poly - ignored
> > Error on line 0 : a$poly$e.xu1.eref2 %vd [ 2 0 3 0 ] %vd ( xu1.97 0 )
> > a$poly$e.xu1.eref2
> > MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref2
> > Warning: Model issue on line 0 : .model a$poly$e.xu1.eref2 spice2poly
> > coef = [ 0 0.5 0.5 ...
> > Unknown model type spice2poly - ignored
> > Error on line 0 : a$poly$e.xu1.eo3 %vd [ xu1.98 xu1.30 ] %vd ( 4
> xu1.42
> > ) a$poly$e.xu1.eo3
> > MIF-ERROR - unable to find definition of model a$poly$e.xu1.eo3
> > Warning: Model issue on line 0 : .model a$poly$e.xu1.eo3
> spice2poly coef
> > = [ 0.7175 0.5 ] ...
> > Unknown model type spice2poly - ignored
> > Error on line 0 : a$poly$e.xu1.eo4 %vd [ xu1.30 xu1.98 ] %vd (
> xu1.44 5
> > ) a$poly$e.xu1.eo4
> > MIF-ERROR - unable to find definition of model a$poly$e.xu1.eo4
> > Warning: Model issue on line 0 : .model a$poly$e.xu1.eo4
> spice2poly coef
> > = [ 0.7355 0.5 ] ...
> > Unknown model type spice2poly - ignored
> > Reducing trtol to 1 for xspice 'A' devices
> > Doing analysis at TEMP = 27,00 and TNOM = 27,00
> > Warning: vv1: has no value, DC 0 assumed
> > Reference value : 1,0e+00
> > No. of Data Rows : 61
> >
> > But the simulation and the tune and the probe work.
> > It will be nice to have the select of visibility of signals
> (checkbox).
> >
> >
> > В Четверг, 21 июл. 2016 в 10:37 , Tomasz Wlostowski
> > <tomasz.wlostow...@cern.ch <mailto:tomasz.wlostow...@cern.ch>>
> написал:
> >> Hi,
> 
> 
> 
> С уважением,
> Эльдар Хайруллин
> eldar.khayrul...@mail.ru


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Integrated Simulator

[Tomasz Wlostowski]

On 22.07.2016 11:11, Eldar Khayrullin wrote:
> Opening the sallen_key.sch with eeschema show in the log window:
> 
> 1) Note: can't find init file.
> 
> 2) Error: .include filename missing
> If delete ".include diodes.lib" - OK.
> 
> 3) Error on line 0 : a$poly$e.xu1.eos %vd [ xu1.53 xu1.98 ] %vd ( xu1.3
> 2 ) a$poly$e.xu1.eos

Hi Eldar,

Compile ngspice with --enable-xspice option.

Tom

> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eos
> Warning: Model issue on line 0 : .model a$poly$e.xu1.eos spice2poly coef
> = [ 1.7e-3 1 ] ...
> Unknown model type spice2poly - ignored
> Error on line 0 : a$poly$e.xu1.eref1 %vd [ 4 0 5 0 ] %vd ( xu1.98 0 )
> a$poly$e.xu1.eref1
> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref1
> Warning: Model issue on line 0 : .model a$poly$e.xu1.eref1 spice2poly
> coef = [ 0 0.5 0.5  ...
> Unknown model type spice2poly - ignored
> Error on line 0 : a$poly$e.xu1.eref2 %vd [ 2 0 3 0 ] %vd ( xu1.97 0 )
> a$poly$e.xu1.eref2
> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eref2
> Warning: Model issue on line 0 : .model a$poly$e.xu1.eref2 spice2poly
> coef = [ 0 0.5 0.5  ...
> Unknown model type spice2poly - ignored
> Error on line 0 : a$poly$e.xu1.eo3 %vd [ xu1.98 xu1.30 ] %vd ( 4 xu1.42
> ) a$poly$e.xu1.eo3
> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eo3
> Warning: Model issue on line 0 : .model a$poly$e.xu1.eo3 spice2poly coef
> = [ 0.7175 0.5 ] ...
> Unknown model type spice2poly - ignored
> Error on line 0 : a$poly$e.xu1.eo4 %vd [ xu1.30 xu1.98 ] %vd ( xu1.44 5
> ) a$poly$e.xu1.eo4
> MIF-ERROR - unable to find definition of model a$poly$e.xu1.eo4
> Warning: Model issue on line 0 : .model a$poly$e.xu1.eo4 spice2poly coef
> = [ 0.7355 0.5 ] ...
> Unknown model type spice2poly - ignored
> Reducing trtol to 1 for xspice 'A' devices
> Doing analysis at TEMP = 27,00 and TNOM = 27,00
> Warning: vv1: has no value, DC 0 assumed
>  Reference value :  1,0e+00
> No. of Data Rows : 61
> 
> But the simulation and the tune and the probe work.
> It will be nice to have the select of visibility of signals (checkbox).
> 
> 
> В Четверг, 21 июл. 2016 в 10:37 , Tomasz Wlostowski
> <tomasz.wlostow...@cern.ch> написал:
>> Hi, 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Integrated Simulator

[Tomasz Wlostowski]

On 21.07.2016 23:16, Chris Pavlina wrote:
> Really, really nice! I made it do a thing! 
> https://misc.c4757p.com/kicad_sim.png
> 
> I feel bad to provide a bug report on my very first communcation on
> this, but... found one: not sure if this sort of thing is actually
> standard SPICE or an LTspice extension, but I tried parameterizing a
> component value, setting a resistor's value to {R} - that sort of thing
> leads to irrecoverable lockups here.
> 

Hi Chris,

Two quick questions:
- Do you have NGspice compiled with XSPICE support?
- Could you run eeschema with forced "C" locale?

Tom
> On Thu, Jul 21, 2016 at 09:37:57PM +0200, Tomasz Wlostowski wrote:
>> Hi,
>>
>> As some of you have noticed, we've been working on a "secret" feature
>> during the hackathon at CERN. The feature we're talking about is an
>> integrated circuit simulator. Currently it features:
>> - Seamless integration into schematic editor,
>> - AC/Transient/DC sweep simulations,
>> - Voltage probing from the schematics,
>> - Live tuning of component values.
>>
>> A video demonstrating the capabilities of the new simulator is available
>> on Tom's YouTube channel [1].
>>
>> The code is currently available in the ngspice branch on Tom's GitHub
>> [2] for review & testing. It's a big feature, so we didn't want to push
>> it immediately to the product branch. We'll greatly appreciate your
>> feedback!
>>
>> The simulator uses ngspice [3] as the Spice kernel. We'd like to thank
>> ngspice developers for providing a DLL interface which made seamless
>> integration of ngspice into Kicad possible.
>>
>> In order to get started:
>> - install ngspice shared library (is not provided by many Linux distros,
>> Arch Linux is a known exception, so you might have to compile it from
>> the sources with --with-ngshared --enable-xspice options).  Windows
>> DLLs, msys2 PKGBUILD & binary packages (to be included soon in
>> the official msys2 repo, currently merged to
>> https://github.com/Alexpux/MINGW-packages/) & Linux script to build the
>> library are available at [4].
>> - compile eeschema with -DKICAD_SPICE=ON option,
>> - have a look at some examples in demos/simulation directory.
>>
>> Happy simulating,
>> Tom
>>
>> [1] https://youtu.be/A2_-hdRcf4U
>> [2] https://github.com/twlostow/kicad-dev/tree/ngspice
>> [3] http://ngspice.sourceforge.net/
>> [4] https://orson.net.pl/pub/libngspice
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Integrated Simulator

[Tomasz Wlostowski]

Hi,

As some of you have noticed, we've been working on a "secret" feature
during the hackathon at CERN. The feature we're talking about is an
integrated circuit simulator. Currently it features:
- Seamless integration into schematic editor,
- AC/Transient/DC sweep simulations,
- Voltage probing from the schematics,
- Live tuning of component values.

A video demonstrating the capabilities of the new simulator is available
on Tom's YouTube channel [1].

The code is currently available in the ngspice branch on Tom's GitHub
[2] for review & testing. It's a big feature, so we didn't want to push
it immediately to the product branch. We'll greatly appreciate your
feedback!

The simulator uses ngspice [3] as the Spice kernel. We'd like to thank
ngspice developers for providing a DLL interface which made seamless
integration of ngspice into Kicad possible.

In order to get started:
- install ngspice shared library (is not provided by many Linux distros,
Arch Linux is a known exception, so you might have to compile it from
the sources with --with-ngshared --enable-xspice options).  Windows
DLLs, msys2 PKGBUILD & binary packages (to be included soon in
the official msys2 repo, currently merged to
https://github.com/Alexpux/MINGW-packages/) & Linux script to build the
library are available at [4].
- compile eeschema with -DKICAD_SPICE=ON option,
- have a look at some examples in demos/simulation directory.

Happy simulating,
Tom

[1] https://youtu.be/A2_-hdRcf4U
[2] https://github.com/twlostow/kicad-dev/tree/ngspice
[3] http://ngspice.sourceforge.net/
[4] https://orson.net.pl/pub/libngspice

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew feature: Vias on Solder Mask Layers

[Tomasz Wlostowski]

On 12.06.2016 20:06, Prabhu Sammandam wrote:
> Hi Jean-Pierre,
> 
> Yes I accept. Why I am bothering is that, it is wasting the toner.
> 
> I need to take two prints and stack them to make the negative film.
> 
> For small PCB's its ok but for bigger PCB it is wasting so much of toner.
> 
Hi Cheng & Prabhu,

A simple trick:
- export as SVG/PDF
- import in inkscape
- apply mirror/registration marks/negative/crop whatever you want
- print

This is the method I had been using some years ago when I did most of my
PCB using toner transfer.

Couple of other tricks:
- you can do homemade vias using car windshield heater repair kit (the
stuff to repair broken heater wires in the windows of your car, Loctite
sells it for ~20$)
- (not tested myself) I've heard that sprinkling a mix of acetone and
isopropanol instead of transferring the toner to the PCB with heat
yields much higher quality PCBs (see [1] - in polish, google translate
should be more or less readable). Must test myself one day ;-)

Cheers,
Tom

[1] http://domwlesie.eu/moje-projekty/amatorskie-plytki-transfer-chemiczny/



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Boost 1.61.0

[Tomasz Wlostowski]

On 06.06.2016 02:41, Chris Pavlina wrote:
> A lot more about the API has changed than that. I'm trying to fix it, but this
> is the first time I've seen boost::context and I'm not sure I'll be able to 
> get
> it done in a timely manner. You should have a look at this. The return types
> and call signatures have totally changed.

Hi Chris,

I'll have a look.

Cheers,
Tom

> 
> On Sun, Jun 05, 2016 at 08:43:50PM +0200, Tomasz Wlostowski wrote:
>> On 05.06.2016 20:12, Chris Pavlina wrote:
>>> Uh, has anyone besides Nick and Simon seen this?
>>>
>>
>> Hi,
>>
>> I did.
>>
>> Boost devs changed the context api again.
>>
>> boost::fcontext_t is now in 
>>
>> Cheers,
>> Tom
>>
>>> On Sat, May 21, 2016 at 05:05:50PM +0200, Nick Østergaard wrote:
>>>> Hi
>>>>
>>>> Just a heads up, Boost 1.61.0 breaks the KiCad build.
>>>>
>>>> See https://bugs.launchpad.net/kicad/+bug/1584326
>>>>
>>>> Regards
>>>> Nick Østergaard
>>>>
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Boost 1.61.0

[Tomasz Wlostowski]

On 05.06.2016 20:12, Chris Pavlina wrote:
> Uh, has anyone besides Nick and Simon seen this?
> 

Hi,

I did.

Boost devs changed the context api again.

boost::fcontext_t is now in 

Cheers,
Tom

> On Sat, May 21, 2016 at 05:05:50PM +0200, Nick Østergaard wrote:
>> Hi
>>
>> Just a heads up, Boost 1.61.0 breaks the KiCad build.
>>
>> See https://bugs.launchpad.net/kicad/+bug/1584326
>>
>> Regards
>> Nick Østergaard
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] lost mipmaps after resume from suspend

[Tomasz Wlostowski]

On 22.05.2016 15:07, Mário Luzeiro wrote:
> Hi Orson,
> 
> I experienced that after I resume from suspend, the mipmaps get corrupted. 
> Only the main size texture looks ok.
> 
> A possible workarround for users is: never suspend and keep working on kicad!

Is this Linux? What graphics card?

Tom
> 
> Mario
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Accessing PNS settings

[Tomasz Wlostowski]

On 13.05.2016 03:45, Chris Pavlina wrote:
> Hi,
> 
> Excuse my unfamiliarity with the architecture of the PNS router - could 
> someone
> more familiar with it help me out and explain what the preferred way to
> access settings, like PNS_ROUTING_SETTINGS::CanViolateDRC, from contexts
> outside the routing tools is? I need a way to implement things like toolbar
> buttons (currently I'm looking at merging duplicate functionality like
> PNS_ROUTING_SETTINGS::CanViolateDrc and g_Drc_On), and I'm having trouble
> seeing a good way to get the data between the routing context and the GUI
> context.
> 
Hi Chris,

Quick solution:
- retrieve the routing tool:

ROUTER_TOOL* theRouter = static_cast( m_toolMgr->FindTool(
"pcbnew.InteractiveRouter" ) );


- retrieve the settings object

PNS_ROUTING_SETTINGS& settings = theRouter->PNSSettings();

Cheers,
Tom




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Tomasz Wlostowski]

On 09.05.2016 14:38, Wayne Stambaugh wrote:
> On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
>> On 04.05.2016 16:48, Wayne Stambaugh wrote:
>>> How are you saving this auto generate flag and width/length parameters
>>> in the schematic?  If you are using component fields or text that's
>>> fine.  However, please keep in mind that using component fields and text
>>> is for passing information to third party tools that are not part of
>>> kicad.  If we are going to support net ties and micro wave component
>>> generation, we should do that as part of KiCad proper rather than treat
>>> it like a third party tool which you are proposing. 
>>
>> Hi Wayne,
>>
>> I would store the microwave dimensions as key:value pairs, just like the
>> current schematic fields. I think microwave components will be best
>> handled by python scripting. These scripts should be IMHO permanently
>> included in Kicad distribution, not a 3rd party tool. I chose component
>> fields to pass the dimensions information because with every new exotic
>> shape (e.g. a Wilkinson power divider instead of a simple microstrip
>> line), we would need to add new tokens to the SCH file format and
>> netlist specification.
> 
> Hey Tom,
> 
> Would it be easier to provide a python script with a UI to input the
> dimensional information used to generate these complex microwave
> footprints and just associate them with a schematic symbol rather that
> trying to squeeze all of that dimensional information into a field?
> This may be more natural for the user to handle.  I understand the
> temptation to use fields to do this but I'm not sure this is the easiest
> path for users.  I just don't see users be comfortable with this in
> terms of usability.  Developers will have no issues with it but I'm
> trying to see this from a typical user's point of view.  It might be
> worth getting some feedback on the users forum.

Hi Wayne,

The tools I used in the past (Microwave Office/ADS) keeps all dimensions
in user-defined schematic symbol fields. AFAIK Qucs uses the same
philosophy. I think most microwave users are aware of this workflow. I
find it efficient because during the design/simulation phase I need very
often to change the dimensions of microstrip components. Running an
external script to update a footprint every time would be IMHO less
efficient and error prone.



> 
>>
>> For net ties, there's no schematic/netlist format changes, only PCB.
>>
>> I'm wondering how to handle the auto_generate flag. Maybe this one
>> justifies a separate file format entity connected to a checkbox in the
>> sch library editor and a text field specifying which plugin/script to run...
> 
> The only risk I see with using a field as an auto_generate flag is field
> namespace pollution.  If someone inadvertently uses the auto_generate
> field name, I image a bunch of script errors would be a bit confusing.
> This risk is low but it is something to consider.  My proposal would
> eliminate the need for an auto_generate flag.

How about keeping this flag outside the user-defined fields.
> 
>>
>>> I don't want the
>>> component fields and text used for kicad features.  If you want to
>>> provide this as an interim solution, I am OK with that.  However, you
>>> may be creating more work for yourself when we finally get around to
>>> supporting net ties and micro wave component generation as part of the
>>> schematic editor. 
>>
>> How do you see the role of the schematic editor in generation of
>> microwave components (in my proposal there's none)?
> 
> I agree.  I don't pretend to be a microwave expert but AFAIK most if not
> all microwave features are complex geometrical shapes which should be
> treated as footprints and associated with a schematic symbol.  I don't
> see why the schematic editor would need to know anything about microwave
> footprints other than possibly passing parametric information via a
> field to the board editor.

Sure. That's why I proposed to keep the parameters in user fields, as
there's so many microwave design technologies that it would be difficult
to standardize this as an internal Kicad feature. Moreover, the same
dimensions are needed both for simulation and PCB design (relying on the
netlist extracted from the schematics), so IMHO the schematic file is
the most logical place to store dimension information. We shouldn't also
forget about other uses of script-driven footprints (e.g. TouchSense
capacitive buttons/sliders, antennas, multilayer printed transformers),
which can use exactly the same technology.

Cheers,
Tom



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Dump zone geometry to files when filling

[Tomasz Wlostowski]

On 10.05.2016 23:41, Chris Pavlina wrote:
> In 6790 I removed the user option to "Dump zone geometry to files when
> filling"; Tom indicated that this was no longer necessary and could be 
> removed.
> 
> I left the *code*, however. I took the global flag out of pcbnew.h and 
> replaced
> it with a static const bool in the file where the actual dumping happens, to
> allow this to be switched back on in the future if absolutely necessary.
> 
> Particularly @ Tom: should the code be removed as well? How sure are we that
> we'll never need it again? If "mostly sure", I'd advocate for removing it; in
> the unlikely case that that changes we can drag it back out of the rev 
> history.
> If "kinda sure", maybe it can be left in.
> 
> What do you think?
> 

I would drop the option from the dialog, but leave the code and the
config file entry (so that it can be enabled by editing the config file
only). Zone filling algorithm still has some rare corner case bugs and
being able to see the intermediate steps of zone filling is a big aid in
fixing them.

Cheers,
Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] pcbnew preferences - cleanup before rework - collab

[Tomasz Wlostowski]

Hi Chris,

Just got back home after the weekend. I'll send my comments tomorrow morning.

Tom



Sent from my Samsung Galaxy smartphone.


 Original message 
From: Chris Pavlina 
Date: 08/05/2016 23:13 (GMT+01:00)
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] pcbnew preferences - cleanup before rework - 
collab

Thanks to the people who gave input on this before. I'm just going to point
this out one more time and see if I can get another wave of input, before
summarizing it and trying to get some changes made :)

https://misc.c4757p.com/pad/p/pcbnew-prefs

On Wed, May 04, 2016 at 04:37:53PM -0400, Chris Pavlina wrote:
> Hi,
>
> There's a *lot* of work to be done to tidy up preferences in pcbnew *before* I
> can properly reorganize them. I'm going to try something new, I've posted what
> I have so far on an open collaborative page and I'd love it if people could
> come add their input. Some of the questions I'm asking could use input from
> Wayne and possibly Tom, so if you guys get a chance... I'm not in a rush, I
> want to take time to think things through clearly before going in and messing
> stuff up.
>
> Please maintain my faith in humanity and don't just go crap on my document,
> I'll just find another way to bother you guys with it >:)
>
> https://misc.c4757p.com/pad/p/pcbnew-prefs
>
> Thanks!
>
> Chris

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Tomasz Wlostowski]

On 04.05.2016 16:48, Wayne Stambaugh wrote:
> How are you saving this auto generate flag and width/length parameters
> in the schematic?  If you are using component fields or text that's
> fine.  However, please keep in mind that using component fields and text
> is for passing information to third party tools that are not part of
> kicad.  If we are going to support net ties and micro wave component
> generation, we should do that as part of KiCad proper rather than treat
> it like a third party tool which you are proposing. 

Hi Wayne,

I would store the microwave dimensions as key:value pairs, just like the
current schematic fields. I think microwave components will be best
handled by python scripting. These scripts should be IMHO permanently
included in Kicad distribution, not a 3rd party tool. I chose component
fields to pass the dimensions information because with every new exotic
shape (e.g. a Wilkinson power divider instead of a simple microstrip
line), we would need to add new tokens to the SCH file format and
netlist specification.

For net ties, there's no schematic/netlist format changes, only PCB.

I'm wondering how to handle the auto_generate flag. Maybe this one
justifies a separate file format entity connected to a checkbox in the
sch library editor and a text field specifying which plugin/script to run...

> I don't want the
> component fields and text used for kicad features.  If you want to
> provide this as an interim solution, I am OK with that.  However, you
> may be creating more work for yourself when we finally get around to
> supporting net ties and micro wave component generation as part of the
> schematic editor. 

How do you see the role of the schematic editor in generation of
microwave components (in my proposal there's none)?

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Tomasz Wlostowski]

Hi all,

Recently there has been a lot of discussion on these features. Here's a
short proposal how we could hit all three birds with one stone:

Changes to SCH:
- none

Changes to netlist import:
- auto_generate flag for SCH components - when set, invokes a Python
script/C++ plugin which updates the PCB footprint of the component
depending on its SCH parameters (e.g. produces a microstrip footprint
based on Width/Length parameters defined on SCH).
- write some microwave component generator plugins (or port the existing
tools). Perhaps a good job for Python.

Changes to PCB:
1) Add two flags to each graphical primitive within a footprint:
- net_tie: DRC treats the primitive as non-conducting and doesn't throw
a short circuit error (see drawing A)
- net_inherit = pad_number: the primitive will take the net of the pad
with given pad_number (see drawing B)
2) Add new 'anchor' virtual pad type.
- indicates the point to attach a trace/via when routing the component.
- exists on a single copper layer.
- has no physical copper.
- has an optional direction vector which denotes how it can be connected
with a trace/other anchor pad (see drawing C)
- has a circular perimeter (maybe other shapes in the future if needed).
Objects intersecting the graphical primitive outside the anchor
perimeter are considered colliding by the DRC (see drawing D) even if
they have the same net.
3) modify .kicad_pcb/footprint formats to support the above:
- extend fp_* entities: net_tie & net_inherit flags
- extend pad entity: add anchor pad type, perimeter radius and direction
vector.
4) modify DRC to support the above (we can benefit from the work already
done by JP)


Advantages:
- microwave footprints generated straight from the schematics.
- net ties for free (since based on the same idea as microwave components)
- custom footprint copper shapes almost for free (costs one extra flag &
some changes in netlist importer)
- minimum changes to file formats & data structures.

The attached drawing shows use cases for all of the above and explains
the concept of anchors.

Looking forward to your feedback,
Tom


shapes.pdf
Description: video/flv
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net Ties

[Tomasz Wlostowski]

On 22.04.2016 15:23, Tomasz Wlostowski wrote:
> On 22.04.2016 15:11, Chris Pavlina wrote:
>> You've never seen an EDA package support net ties? Or seen them used to
>> separate logical power planes? Quite common, really...
> 
> Me too.

s/mee to/I'd really love to see this in Kicad too (I wanted to reply to
your second sentence Chris ;-)

Tom
> 
> IMHO it can be done without any changes on the eeschema side by adding a
> special component to the standard library (just like GND/power ports).
> PCBnew could interpret it as a zero-sized copper pad. Some DRC
> modifications would be needed to correctly take into account clearances
> of the nets connected by a tie.
> 
> Tom
>>
>> I'd _love_ to see proper net tie support in KiCad. :)
>>
>> On Fri, Apr 22, 2016 at 09:04:10AM -0400, Wayne Stambaugh wrote:
>>> On 4/20/2016 4:00 PM, Simon Richter wrote:
>>>> Hi,
>>>>
>>>> as wxWidgets is getting on my nerves with editing widgets in the pin
>>>> table not rendering properly, I've started on support for net ties.
>>>>
>>>> In the current iteration, they would be placed the same way as junctions.
>>>>
>>>> Rules:
>>>>
>>>>  - Any wire or pin connected to a net tie is in a separate net (unless
>>>> connected elsewhere).
>>>>  - The net tie maps to a pseudo-pad that all three nets need to be
>>>> connected to.
>>>>  - Connecting the nets there does not give a DRC error -- anywhere else
>>>> will.
>>>>  - The pseudo-pad can be placed on a regular pad if it is on one of the
>>>> nets connected to the net tie.
>>>>
>>>> Use cases:
>>>>
>>>>  - Analog and digital supply planes connected with a trace, but
>>>> otherwise separate
>>>
>>> I'm going to put my EE hat on and say that if you connect two power
>>> planes with a trace then they are the same plane no matter what you
>>> called them in your schematic.  A more typical solution in this case
>>> would be to physically separate them by some type of component or
>>> components.  Usually inductors or 0 ohm resistors (aka jumpers) are used
>>> in this situation depending on what you are trying to accomplish.
>>>
>>>>  - Current sense resistors between a supply rail and a load
>>>>  - Decoupling capacitors.
>>>
>>> I can see the decoupling capacitor use case where you want to tie a cap
>>> to a specific component power pin.
>>>
>>>>
>>>> I've added UI[1] and save support in eeschema already, still needs
>>>> mapping to the netlist and pcbnew support.
>>>
>>> Are you aware that changes to the current schematic file format are
>>> forbidden until we (I) finish implementing the new file format?  This
>>> was discussed fairly recently so everyone should be aware of this.  In
>>> any event, you should have gotten input from the development team before
>>> heading down this path.  This is good advice for any developer.  Even I
>>> solicit input on new features or large changes because other devs always
>>> seem to think of things I didn't.
>>>
>>> I don't have a strong opinion one way or the other about this feature.
>>> On the surface it does seem useful but I've never seen any EDA product
>>> support this so board designers may not understand why they would want
>>> to use it.  Any one else have any thoughts on this?  You may also want
>>> to check with the users to see if it's something that they would even use.
>>>
>>>>
>>>> There doesn't appear to be a real standard on how to represent net ties
>>>> in the schematic, though. A design note[2] from Linear Technologies uses
>>>> 45 degree angles on wires to make it look really intentional that the
>>>> wires should meet in the same spot, but that would be a major hassle
>>>> both to implement and use.
>>>>
>>>> For now I've gone with a larger dot, but that is very unintuitive.
>>>> Printing net names next to wires is difficult, because these are still
>>>> wires only. Numbers next to the wires might be doable, but confusing, so
>>>> if anyone has a good idea how to represent them, please speak up.
>>>
>>> How about a different color dot or a different shape.  A different shape
>>> may be better for users who are color blind.
>>>
>>>>
>>>>Simon
>>>>
>>>> [1] http://psi

Re: [Kicad-developers] Net Ties

[Tomasz Wlostowski]

On 22.04.2016 15:11, Chris Pavlina wrote:
> You've never seen an EDA package support net ties? Or seen them used to
> separate logical power planes? Quite common, really...

Me too.

IMHO it can be done without any changes on the eeschema side by adding a
special component to the standard library (just like GND/power ports).
PCBnew could interpret it as a zero-sized copper pad. Some DRC
modifications would be needed to correctly take into account clearances
of the nets connected by a tie.

Tom
> 
> I'd _love_ to see proper net tie support in KiCad. :)
> 
> On Fri, Apr 22, 2016 at 09:04:10AM -0400, Wayne Stambaugh wrote:
>> On 4/20/2016 4:00 PM, Simon Richter wrote:
>>> Hi,
>>>
>>> as wxWidgets is getting on my nerves with editing widgets in the pin
>>> table not rendering properly, I've started on support for net ties.
>>>
>>> In the current iteration, they would be placed the same way as junctions.
>>>
>>> Rules:
>>>
>>>  - Any wire or pin connected to a net tie is in a separate net (unless
>>> connected elsewhere).
>>>  - The net tie maps to a pseudo-pad that all three nets need to be
>>> connected to.
>>>  - Connecting the nets there does not give a DRC error -- anywhere else
>>> will.
>>>  - The pseudo-pad can be placed on a regular pad if it is on one of the
>>> nets connected to the net tie.
>>>
>>> Use cases:
>>>
>>>  - Analog and digital supply planes connected with a trace, but
>>> otherwise separate
>>
>> I'm going to put my EE hat on and say that if you connect two power
>> planes with a trace then they are the same plane no matter what you
>> called them in your schematic.  A more typical solution in this case
>> would be to physically separate them by some type of component or
>> components.  Usually inductors or 0 ohm resistors (aka jumpers) are used
>> in this situation depending on what you are trying to accomplish.
>>
>>>  - Current sense resistors between a supply rail and a load
>>>  - Decoupling capacitors.
>>
>> I can see the decoupling capacitor use case where you want to tie a cap
>> to a specific component power pin.
>>
>>>
>>> I've added UI[1] and save support in eeschema already, still needs
>>> mapping to the netlist and pcbnew support.
>>
>> Are you aware that changes to the current schematic file format are
>> forbidden until we (I) finish implementing the new file format?  This
>> was discussed fairly recently so everyone should be aware of this.  In
>> any event, you should have gotten input from the development team before
>> heading down this path.  This is good advice for any developer.  Even I
>> solicit input on new features or large changes because other devs always
>> seem to think of things I didn't.
>>
>> I don't have a strong opinion one way or the other about this feature.
>> On the surface it does seem useful but I've never seen any EDA product
>> support this so board designers may not understand why they would want
>> to use it.  Any one else have any thoughts on this?  You may also want
>> to check with the users to see if it's something that they would even use.
>>
>>>
>>> There doesn't appear to be a real standard on how to represent net ties
>>> in the schematic, though. A design note[2] from Linear Technologies uses
>>> 45 degree angles on wires to make it look really intentional that the
>>> wires should meet in the same spot, but that would be a major hassle
>>> both to implement and use.
>>>
>>> For now I've gone with a larger dot, but that is very unintuitive.
>>> Printing net names next to wires is difficult, because these are still
>>> wires only. Numbers next to the wires might be doable, but confusing, so
>>> if anyone has a good idea how to represent them, please speak up.
>>
>> How about a different color dot or a different shape.  A different shape
>> may be better for users who are color blind.
>>
>>>
>>>Simon
>>>
>>> [1] http://psi5.com/~geier/net-tie.ogv
>>> [2] http://cds.linear.com/docs/en/design-note/dn434f.pdf
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : 

Re: [Kicad-developers] dyn_cast

[Tomasz Wlostowski]

On 13.04.2016 18:38, Chris Pavlina wrote:
> I would argue - quite strongly! - that it doesn't matter if it's faster in an
> isolated test if it isn't used enough to actually affect the overall code
> speed. Was this ever profiled in situ? This sort of thing just causes 
> headaches
> when people misunderstand the usage and subtleties of the more limited
> "optimized" replacement. I find it hard to believe that we call dynamic_cast
> enough for it to be a performance issue.

Perhaps you're right, I'm not going to argue here.

>
> Also - *please* let me rename it. dynamic_cast vs dyn_cast is almost the
> _textboox_ example of poor naming. It's absolutely 100% non-obvious to someone
> reading code using the latter _why_ it was chosen, what its advantage is over
> the normal one, and whether it has any subtle issues that can cause bugs. At
> least it should be called something like dynamic_cast_fast so there's
> justification for its use in the actual code using it.

Go on with the renaming.

Tom

> 
> On Wed, Apr 13, 2016 at 06:34:28PM +0200, Tomasz Wlostowski wrote:
>> On 13.04.2016 18:19, Simon Richter wrote:
>>> Hi,
>>>
>>> On 13.04.2016 18:13, Chris Pavlina wrote:
>>>
>>>> What is the purpose of dyn_cast<> in include/core/typeinfo.h? Why don't we 
>>>> just
>>>> use dynamic_cast<>? And can we either replace the former with the latter, 
>>>> or
>>>> add a comment to the former explaining its purpose?
>>>
>>> It uses the parallel type system in EDA_ITEM rather than RTTI, so it
>>> works if RTTI is broken, e.g. when compiling with gcc 2.95.
>>>
>>
>> I wrote it inspired with Clang/LLVM design which uses a very similar
>> pattern. Sorry Simon, I didn't consider compatibility with gcc 2.95
>> would be of an advantage. My reasons were:
>>
>> 1) Much faster (code in the attachment):
>> - dynamic_cast<> : 9090437 usecs
>> - dyn_cast<> : 1832433 usecs (5x improvement)
>>
>> 2) Lightweight & compatible with existing Kicad type system.
>>
>> Cheers,
>> Tom
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] dyn_cast

[Tomasz Wlostowski]

On 13.04.2016 18:19, Simon Richter wrote:
> Hi,
> 
> On 13.04.2016 18:13, Chris Pavlina wrote:
> 
>> What is the purpose of dyn_cast<> in include/core/typeinfo.h? Why don't we 
>> just
>> use dynamic_cast<>? And can we either replace the former with the latter, or
>> add a comment to the former explaining its purpose?
> 
> It uses the parallel type system in EDA_ITEM rather than RTTI, so it
> works if RTTI is broken, e.g. when compiling with gcc 2.95.
> 

I wrote it inspired with Clang/LLVM design which uses a very similar
pattern. Sorry Simon, I didn't consider compatibility with gcc 2.95
would be of an advantage. My reasons were:

1) Much faster (code in the attachment):
- dynamic_cast<> : 9090437 usecs
- dyn_cast<> : 1832433 usecs (5x improvement)

2) Lightweight & compatible with existing Kicad type system.

Cheers,
Tom
#include 

#include "profile.h"
#include "typeinfo.h"

const int n_iter = 10;

const int id_base = 0;
const int id_derived = 1;


class Base {
public:
Base()
{
	m_type = id_base;
}

virtual ~Base() {};

static inline bool ClassOf( const Base* aItem )
{
return aItem && id_base == aItem->Type();
}

int Type() const
{
	return m_type;
}


protected:
int m_type;
int m_count;
};

class Derived : public Base {
public:
static inline bool ClassOf( const Base* aItem )
{
return aItem && id_derived == aItem->Type();
}

Derived()
{
	m_type = id_derived;
}

void DoSomething()
{
	m_count++;
}

};

main()
{
Base *b = new Derived();

prof_counter cnt;

prof_start();

for(int i = 0; i  (b);
	d->DoSomething();
}
prof_end();

printf("dynamic_cast<> : %d usecs\n", cnt.usecs());

prof_start();


for(int i = 0; i (b);
	d->DoSomething();
}

prof_end();
printf("dyn_cast<> : %d usecs\n", cnt.usecs());

}
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DIALOG_ORIENT_FOOTPRINTS

[Tomasz Wlostowski]

On 13.04.2016 11:35, Chris Pavlina wrote:
> Just rotate them first, then place. We don't need specific tools for
> every conceivable permutation of movements. Unless even more people come
> in saying they need this, or Wayne overrides me... I still don't think
> this needs to stay.

Hi Chris,

There's even a work package in the roadmap (property system & inspector
tool) for such 'rare' operations. Select a number of items, open a table
with common properties (e.g. x, y, locked, orientation, size) and set
the orientation to the desired value.

Cheers,
Tom




> 
> On Apr 13, 2016 02:16, "David Godfrey"  > wrote:
> 
> Hi Chris,
> 
> A rotation of the selection is not the same as a rotation of the
> individual components.
> Consider you already have the components roughly in a grid, and you need
> to rotate them by 20 degrees.
> Rotating the selection means you have to do major repositioning of every
> component to get them back in the correct area.
> 
> However rotating the components within the selection means they are
> still in about the right position, so only minor placement adjustments
> are required.
> These minor adjustments can likely be made using the align and
> distribute tools
> 
> I Agree half-implemented features are bad, better to update them and
> properly implement.
> 
> Regards
> David G
> 
> On 13/04/16 08:53, Chris Pavlina wrote:
> > GAL already has this. Block or multi select, Ctrl-M for "move
> exactly" (or use
> > the context menu), and type an angle. Just rotates the whole
> selection, then
> > you can place your rotated resistors.
> >
> > Considering legacy is on its way out, I'd rather not keep crusty old
> > half-implemented legacy features around to require maintenance.
> >
> >
> > On Wed, Apr 13, 2016 at 08:50:38AM +0800, David Godfrey wrote:
> >> Hmm,
> >>
> >> I'v not used it on Kicad but the ability to change the
> orientation of an
> >> arbitrary selection of footprints is something I've used many
> times in
> >> Altium.
> >>
> >> Ideally you want to be able to set an absolute orientation, and
> also a
> >> relative (to current) angle adjustment.
> >>
> >> This is especially useful when designing boards like LED matrices and
> >> wanting to put all resisters on a specific angle (eg: 21.3deg).
> >> You can then do an array alignment with the same outer limit you used
> >> for your LED alignment.
> >> Then move the group of resistors into position relative to the LED's.
> >>
> >> Now running your tracks becomes trivial.
> >>
> >> Without the ability to auto adjust the orientation on a selection of
> >> parts the job becomes long and tedious.
> >> Some of the PCB's I've done this on have over 1000 LED's and
> resistors,
> >> and generally you need to orient both the resistors and the LED's
> >>
> >> So in summary, I'd like to keep the ability to do this, but on a
> >> selection instead of globally.
> >> And being able to alter it as an absolute angle, or as a relative to
> >> current (prefix the new angle with + or - to get relative movement)
> >> would be beneficial.
> >>
> >> Regards
> >> David G
> >>
> >> On 13/04/16 06:40, Chris Pavlina wrote:
> >>> I wonder how many of you are even aware of
> DIALOG_ORIENT_FOOTPRINTS. It's
> >>> hidden in the Secret Menu in pcbnew (the spread-and-place) one,
> menu item
> >>> Orient All Footprints. The code hasn't been touched since 2010
> except a few
> >>> cleanups, and it seems really simplistic and useless to me. I
> was going to
> >>> upgrade it to floating-point angle entry like everything else,
> but
> >>>
> >>> Does _anybody_ even use this? It seems utterly useless. I have
> no idea when
> >>> you'd want to globally apply an orientation to footprints. Can I
> just tear it
> >>> out?  :P
> >>>
> >>
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> 
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : 

Re: [Kicad-developers] Question about const SHAPE_LINE_CHAIN Outline() const

[Tomasz Wlostowski]

On 04.04.2016 14:15, Maciej Sumiński wrote:
> On 04/04/2016 01:39 PM, jp charras wrote:
>> Sorry if you already sent me a response to this "old" message (first posted 
>> on feb 05)
>> but I did not remember this response.

Hi Jean-Pierre,

If you mean this code in your patch:

SHAPE_RECT::Outline()

- rv.Append( m_p0 );
-rv.Append( m_p0.x, m_p0.y + m_w );
-rv.Append( m_p0.x + m_h, m_p0.y + m_w );
-rv.Append( m_p0.x + m_h, m_p0.y );
+rv.Append( m_p0.x, m_p0.y + m_h );
+rv.Append( m_p0.x + m_w, m_p0.y + m_h );
+rv.Append( m_p0.x + m_w, m_p0.y );

It's OK - there was indeed a bug.

Speaking of the pads patch - I didn't have the time to review the whole
pads patch yet. I like very much the rounded rectangle pads, but IMHO
allowing any arbitrary pad shape (including non-convex shapes) is not
the best way to go. I would rather think about enabling graphical
primitives on copper layers and define how they get their nets (e.g.
inherit them from a given pad of the "parent" footprint). This would not
only deal with custom pad shapes but also enable things like parametric
microwave components.

I'll post a proposal & a review of the patch as soon as I can.

Tom

>>
>> It is annoying for the rounded rect pads which use this method.
>> (I currently use a fixed (modified) version in my patch)
>>
>> I can easily fix it, but I do not want to create bugs in pns router.
>>
>> Thanks.
>>
>>> Orson, Tomasz,
>>>
>>> I am thinking there is a bug in geometry/shape_rect.h:
>>> In
>>> const SHAPE_LINE_CHAIN Outline() const
>>>
>>> m_h and m_w look like they are swapped in calculations, and the outline
>>> is incorrect (assuming m_w is the X axis rect size (width), and m_h is
>>> the Y axis rect size (height)).
>>>
>>> Can you have a look at this?
>>>
>>> Thanks
> 
> Hi Jean-Pierre,
> 
> Just by looking at the code, I am quite positive that you are right in
> this matter, but Tom has to confirm it. He is absent today, so hopefully
> he will respond tomorrow.
> 
> Regards,
> Orson
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PNS rounding errors?

[Tomasz Wlostowski]

On 19.03.2016 19:11, Chris Pavlina wrote:
> Hey, just wondering about something. PNS has had slightly different rounding
> behavior than DRC since the beginning - when I use PNS heavily on a board, I
> usually have to decrease my clearance very slightly (say from 0.2mm to 
> 0.199mm)
> to make DRC pass. Is this a known issue among the devs working on GAL/PNS, and
> is there any plan to do something about it? I suppose it's probably quite
> difficult to make PNS perfectly emulate the behavior DRC uses - maybe we could
> do something like applying a very small error margin to the clearance in PNS 
> so
> it doesn't route things *exactly* to the clearance?
>

Hi Chris,

We know about it, the DRC calculates clearances in a completely
different way than P, so rounding errors are to be expected. Your idea
with applying a small margin looks OK to me. BTW - could you send me the
PCB design which shows most of P DRC errors?

Cheers,
Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Grid in pcbnew

[Tomasz Wlostowski]

On 01.03.2016 00:43, Tiger12506 wrote:
> Ok, thanks -- is it just on my machine that the colors aren't very 
> pronounced? Notice the difference (or apparent lack thereof) between "white" 
> for the ratsnest and darkest gray that isn't black for the grid...
> 
> I think I'm falling into the "liked the dots better" camp... haha

Dots are also coming to the GAL. Some people prefer lines, some other
dots, they will be selectable.

Tom

> 
> 
> On Tue, 1 Mar 2016 00:11:12 +0100
> Tomasz Wlostowski <tomasz.wlostow...@cern.ch> wrote:
> 
>> On 29.02.2016 23:55, Tiger12506 wrote:
>>> I follow the list and skim over every email. I seem to recall there were 
>>> some changes made to the grid in pcbnew due to an os x problem somewhat 
>>> recently.
>>>
>>> Attached I have an image from BZR 6601 running on Debian MATE that seems 
>>> extremely grid heavy to me. Is there any way to change this? I don't 
>>> remember it being this pronounced.
>>
>> Hi,
>>
>> You can change the grid color to a darker one (click on the color
>> indicator in the layer widget).
>>
>> Tom
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Grid in pcbnew

[Tomasz Wlostowski]

On 29.02.2016 23:55, Tiger12506 wrote:
> I follow the list and skim over every email. I seem to recall there were some 
> changes made to the grid in pcbnew due to an os x problem somewhat recently.
> 
> Attached I have an image from BZR 6601 running on Debian MATE that seems 
> extremely grid heavy to me. Is there any way to change this? I don't remember 
> it being this pronounced.

Hi,

You can change the grid color to a darker one (click on the color
indicator in the layer widget).

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pcbnew delete hot key behavior.

[Tomasz Wlostowski]

On 29.02.2016 20:41, Wayne Stambaugh wrote:
> At some point in our history, someone half way changed the default
> behavior of the delete hot key in pcbnew (legacy canvas).  There is a
> dubious albeit incomplete attempt to limit the delete hot key to the
> currently selected tool.  When did we decide to that and who made that
> decision?  This would explain why I cannot delete certain items when
> certain tools (track and footprint) are selected.  I thought we were
> working under the assumption having to constantly select the "correct"
> tool to delete (or any other hotkey function for that matter) items
> associated with that tool was not a good thing but rather a waste of
> time.  One of the things I've always hated about other EDA packages was
> the notion that I could only delete object if I had the tool for that
> object type selected.  I'm really not interested in repeating behavior
> in KiCad.  Does anyone really think limiting hot keys to the currently
> selected tool is a good idea?

Hi Wayne,

In my opinion, it's justified in some cases (such as being able to
quickly delete a track).

I checked the behaviour of the legacy canvas:
- when in track mode, it only allows deleting tracks
- when in footprint mode, it only allows deleting footprints
- when in zone mode, it doesn't delete anything.

The delete hotkey handler is called in all cases. I guess the problem
PCB_EDIT_FRAME::OnHotkeyDeleteItem(), although it hasn't been modified
since 2014.

Tom

PS. I'm working on adding similar functionality to the GAL - it's a bit
more complex, because the P has a separate data model that needs to be
synced up to the underlying BOARD object when a delete operation is
performed.


> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Question about track/via locking

[Tomasz Wlostowski]

Hi guys,

Does anybody here know if the 'locked' flag for tracks/vias affects
anything else than the Global Deletions tool? It seems so from the code:

pcbnew(master)$ find . -name "*.cpp" | xargs grep TRACK_LOCK
./attribut.cpp: *  TRACK_LOCKED   protection against global delete
./attribut.cpp:track->SetState( TRACK_LOCKED, Flag_On );
./attribut.cpp:Track->SetState( TRACK_LOCKED, Flag_On );
./attribut.cpp:/* Modify the flag TRACK_LOCKED according to Flag_On value,
./attribut.cpp:Track->SetState( TRACK_LOCKED, Flag_On );
./onrightclick.cpp:if( Track->GetState( TRACK_LOCKED ) )
./class_track.cpp:if( GetState( TRACK_LOCKED ) )
./class_track.cpp:if( stateBits & TRACK_LOCKED )
./class_track.cpp:ret << wxT( " | TRACK_LOCKED" );
./dialogs/dialog_global_deletion.cpp:track_mask_filter |=
TRACK_LOCKED;
./dialogs/dialog_global_deletion.cpp:if( (
track->GetState( TRACK_LOCKED | TRACK_AR ) & track_mask_filter ) != 0 )
./dialogs/dialog_global_deletion.cpp:if( (
track->GetState( TRACK_LOCKED | TRACK_AR ) == 0 ) &&

I'm asking because I'd like to add track/via locking feature to the GAL
and I'm also considering making P avoid (hug) locked tracks/vias.

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] New Feature: Touchpad Panning

[Tomasz Wlostowski]

On 20.02.2016 13:56, Bernhard Stegmaier wrote:
> Any plans/comments whether this one will get merged?

Hi Bernard,

I don't have a Mac, so I can't test the OSX changes myself, but as no
one among the OSX Kicad has complained for the last 2 weeks, I'd vote
for merging it...

Cheers,
Tom
> 
>> On 12.02.2016, at 20:38, Bernhard Stegmaier  wrote:
>>
>> Hi all,
>>
>> attached a patch to add a new feature “touchpad panning”.
>> When enabled, you can pan in x/y-direction by just using usual 2-finger 
>> touchpad gestures without shift/ctrl modifiers instead of scroll wheel zoom.
>>
>> It is particularly useful on OS X, because any Apple touchpad/mouse supports 
>> these 2-finger gestures (1-finger with MagicMouse). 
>> It makes KiCad behave more like any other regular OS X application and has 
>> been requested for some time by some/many OS X users.
>>
>> It is built on top of platform independent wxWidgets functions, so it should 
>> work also on any other platform and device supporting x/y mousewheel events 
>> and is not restricted to OS X.
>>
>> I added preference options to each application like the other pan/zoom 
>> options (and a menu entry for 3d-Viewer).
>> If disabled, panning/scrolling should work the same as without the patch.
>>
>> I tested it on
>> * OS X with touchpad, MagicMouse, MightMouse
>> * OS X with normal PC mouse
>> * Linux running inside a VirtualBox on OS X (debian testing with xfce 
>> desktop)
>>
>> I would be great if someone could test it on native Windows/Linux with a 
>> touchpad.
>> It should be OK, the only problem that I could imagine is that panning speed 
>> might have to be adapted (frequency/granularity of mousewheel events could 
>> be different between OS X and other platforms, there are already some 
>> platform specific adaptions in the code before the patch).
>>
>> Of course, any other feedback is also welcome!
>>
>> Note:
>> This patch contains the patch discussed in the other mail thread, which 
>> disables framerate throttling in GAL on OS X.
>>
>>
>> Regards,
>> Bernhard
>>
>> 
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Slow performance in pcbnew (PNS/GAL only) on high-fanout nets

[Tomasz Wlostowski]

On 31.01.2016 21:27, Andrew Zonenberg wrote:
> When working on a board with a lot of pads, terminating a trace on
> a high-fanout net results in a significant (a second or more) hang
> of the entire UI. I haven't yet attempted to figure out what part
> of the code this hang is in.
> 
> Steps to reproduce:
> 
> 1) Open a large board file in pcbnew (I'm testing with 
> http://thanatos.virtual.drawersteak.com/unlisted/marblewalrus-switch.kic
>
> 
ad_pcb)
> in GAL mode. The hang does not appear to be reproducible in
> legacy.
> 
> 2) Start drawing a track on a high-fanout net (GND is a good
> example)
> 
> 3) Performance should be normal when the track is started and
> during drawing, but when you click on a pad to terminate the track
> pcbnew hangs .
> 
> Anybody with PNS experience (Orson, Tomasz, etc) care to
> investigate thi s?

Hi Andrew,

Thanks for the report.

It's the ratsnest update, it can take a significant time for highly
fanouted nets - we're going to optimize it.

Tom

BTW. Nice project, are you designing some specialized Ethernet switch?


> 
> ___ Mailing list:
> https://launchpad.net/~kicad-developers Post to :
> kicad-developers@lists.launchpad.net Unsubscribe :
> https://launchpad.net/~kicad-developers More help   :
> https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC PATCH] Single-click board update, take 2.

[Tomasz Wlostowski]

On 29.01.2016 16:23, Chris Pavlina wrote:
> Okay, after testing this, I actually have two "bug reports", one that I
> consider fairly important, and one that's minor.
> 
> Important one: IMO there *needs* to be an option to only add or update
> components, not remove. Here's the list of suggested changes for a board where
> I manually added via stitching using a via "footprint" and the array tool:
> 
> https://misc.c4757p.com/nooo.png
> 
> I don't want to remove those!! It's not a 'standard' use case, perhaps, but
> it's still a regression, as I was previously able to make it keep those.

Hi Chris,

I wouldn't call it a regression. Stitching vias with single-pad
components is just a dirty hack we'll have to live with until we get a
new connection propagation algorithm. Until then, I agree we should have
an option preventing component removal.

> 
> Minor one: don't say "Netlist update successful!" in the list of _proposed_
> changes, it's a bit confusing as it seems to imply the changes have actually
> been made.

Good catch!

Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC PATCH] No more boost::context

[Tomasz Wlostowski]

On 23.01.2016 23:53, Wayne Stambaugh wrote:
>> I found the issue in Boost causing crashes on x86_64 windows builds.
>> > 
>> > Now I have no doubt why Windows Boost developers may have a very good
>> > reason to hate the x86 GNU assembler (well, not the tool itself but its
>> > infamous AT syntax). Look at the code below:
>> > 
>> > mov $0x8, %rcx
>> > mov 0x8, %rcx
>> > 
>> > Translated to a more human-readable form, these two lines mean:
>> > 
>> > mov rcx, 0x8
>> > mov rcx, qword [ds:0x8]
> Great catch!.  That is just too easy to overlook.
> 

Hi all,

I've filed bug reports & sent patches both to boost & MSYS2 maintainers.

Cheers,
T.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC PATCH] No more boost::context

[Tomasz Wlostowski]

On 23.01.2016 18:51, "Torsten Hüter" wrote:
> Hi Wayne,
> 
> for a short term solution also an older Boost version can be used for Windows 
> - or Tom's patch - it's at least not a blocker. 
> I'm guessing Tom could do more productive stuff :)
> 
> For the long term solution it's of course possible to drop the coroutines 
> completely and use the well known event-driven finite-state machines 
> (https://en.wikipedia.org/wiki/Event-driven_finite-state_machine) - I think 
> that's what you're meaning with the second suggestion. 
> 
> I can do this job, because I've implemented a lot of them in various 
> languages - but this needs more time and I'd have to touch more files. The 
> tool framework uses already an event system and most tools with coroutines 
> look to me simplistic (they have an init part, an event loop and some 
> finishing instructions).
> Makes of course only sense, if we have an agreement, would an example be 
> helpful?
> 
Hi guys,

I found the issue in Boost causing crashes on x86_64 windows builds.

Now I have no doubt why Windows Boost developers may have a very good
reason to hate the x86 GNU assembler (well, not the tool itself but its
infamous AT syntax). Look at the code below:

mov $0x8, %rcx
mov 0x8, %rcx

Translated to a more human-readable form, these two lines mean:

mov rcx, 0x8
mov rcx, qword [ds:0x8]

One dollar sign makes a huge difference... Perhaps somebody in boost
community just translated the MASM files to GAS without even testing them.

Patch in progress, I'll send it both to MSYS & Boost devs.

Cheers,
Tom




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Coroutines

[Tomasz Wlostowski]

On 21.01.2016 13:06, "Torsten Hüter" wrote:
> Hi,
>  
> Lorenzo:
>  
> Sorry, perhaps I've expressed it not correctly in my latest mail, I've just 
> written down my subjective impressions, while working on the code, that are 
> mostly rhetoric questions.
>  
>>> Stackless coroutines:
>>> -
>>>
>>> * Relative easy to handle, because based on switch()/case().
>>> * Safer, a wrong state causes only the exit of the coroutine but not a 
>>> crash.
>>> * Simple implementation
>>> Simple?!? Well, maybe implementing but maintaining is another thing...

Hi Torsten,

Many thanks for your work. I'm not particularly thrilled about stackless
coroutines for the reasons below:
- They would require a major rewrite of the tool code. If we were to
rewrite it, I'd rather drop coroutines completely.
- Performance is not an issue. The tools just handle UI events.
protothreads library was invented for asynchronous I/O, where
performance is critical. In Kicad, coroutines overhead is minimal.
- They are based on macros, which not only means strange-looking (not to
say ugly) code, but is also hard to debug.
- I can't agree that if something goes wrong, the stackless coroutine
will just exit, but a stackful one will crash. If there's a segfault,
you'll get a crash independently of the coroutine implementation.

Back to the original issue: Boost::context stopped working on MSYS2. The
reason is Boost developers don't want to use GNU assembler on Windows,
and the GNU asm port of the context switching functions is not the same
as the MASM one (since the authors have changed the context ABI at some
point). We shouldn't play cat and mouse with Boost devs by maintaining
MSYS patches that won't get accepted into official Boost tree.

I've been working recently on a library [1] derived from Boost::context,
but which can be easily added to any C++ project, as it consists only of
2 files (.h and .cpp), just like ClipperLib, which we successfully used
for processing polygons.

Libcontext contains all Boost::context switching functions converted to
inline assembly, with compiler and ABI detection. So far,
it has been tested on: i386/x86_64 Linux, Win32/Win64 (GCC) and OSX
(both 32 and 64-bit) - so all the platforms Kicad runs on are already
supported (I'll also enable ARM support - as soon as I have a working
test program a raspi). I think this should be sufficient for the
foreseeable future.

Best,
Tom

[1] https://github.com/twlostow/libcontext



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [RFC PATCH] No more boost::context

[Tomasz Wlostowski]

Hi,

This patch replaces boost::context with a small library called
libcontext (derived from boost::context sources). It drops the
dependency on boost for the cost of one additional header file and cpp
file (taking inspiration from ClipperLib).

I've tested the new context switching code on Linux, OSX (El Capitan) &
Windows (all OS 32-bit and 64-bit Intel). Supported compilers are GCC
and Clang.

Let me know if Kicad builds and works correctly on your platforms...

Cheers,
Tom
>From 8381f20118ea06a6ffdc9f8c93c8f78fbba6d8f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= <tomasz.wlostow...@cern.ch>
Date: Thu, 21 Jan 2016 14:29:29 +0100
Subject: [PATCH] tools: replace boost::context with libcontext

---
 CMakeLists.txt   |   2 +-
 common/CMakeLists.txt|   2 +
 common/system/libcontext.cpp | 536 +++
 include/system/libcontext.h  |  84 +++
 include/tool/coroutine.h |  27 +--
 5 files changed, 631 insertions(+), 20 deletions(-)
 create mode 100644 common/system/libcontext.cpp
 create mode 100644 include/system/libcontext.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f655f37..bea5039 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -460,7 +460,7 @@ find_package( Cairo 1.8.8 REQUIRED )
 #
 # Note: Prior to Boost 1.59, the Boost context library is not built when compiling on windows
 #   with GCC.  You must patch the Boost sources.
-find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread )
+find_package( Boost 1.54.0 REQUIRED COMPONENTS system thread )
 
 # Include MinGW resource compiler.
 include( MinGWResourceCompiler )
diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index 048ddf0..d45064c 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -271,6 +271,8 @@ endif()
 
 set( COMMON_SRCS
 ${COMMON_SRCS}
+system/libcontext.cpp
+
 kicad_curl/kicad_curl.cpp
 kicad_curl/kicad_curl_easy.cpp
 
diff --git a/common/system/libcontext.cpp b/common/system/libcontext.cpp
new file mode 100644
index 000..5f08bcb
--- /dev/null
+++ b/common/system/libcontext.cpp
@@ -0,0 +1,536 @@
+/*
+
+auto-generated file, do not modify!
+libcontext - a slightly more portable version of boost::context
+Copyright Martin Husemann 2013.
+Copyright Oliver Kowalke 2009.
+Copyright Sergue E. Leontiev 2013
+Copyright Thomas Sailer 2013.
+Minor modifications by Tomasz Wlostowski 2016.
+
+ Distributed under the Boost Software License, Version 1.0.
+  (See accompanying file LICENSE_1_0.txt or copy at
+http://www.boost.org/LICENSE_1_0.txt)
+
+*/
+#include 
+
+#if defined(LIBCONTEXT_PLATFORM_windows_i386) && defined(LIBCONTEXT_COMPILER_gcc)
+__asm (
+".text\n"
+".p2align 4,,15\n"
+".globl	_jump_fcontext\n"
+".def	_jump_fcontext;	.scl	2;	.type	32;	.endef\n"
+"_jump_fcontext:\n"
+"mov0x10(%esp),%ecx\n"
+"push   %ebp\n"
+"push   %ebx\n"
+"push   %esi\n"
+"push   %edi\n"
+"mov%fs:0x18,%edx\n"
+"mov(%edx),%eax\n"
+"push   %eax\n"
+"mov0x4(%edx),%eax\n"
+"push   %eax\n"
+"mov0x8(%edx),%eax\n"
+"push   %eax\n"
+"mov0xe0c(%edx),%eax\n"
+"push   %eax\n"
+"mov0x10(%edx),%eax\n"
+"push   %eax\n"
+"lea-0x8(%esp),%esp\n"
+"test   %ecx,%ecx\n"
+"je nxt1\n"
+"stmxcsr (%esp)\n"
+"fnstcw 0x4(%esp)\n"
+"nxt1:\n"
+"mov0x30(%esp),%eax\n"
+"mov%esp,(%eax)\n"
+"mov0x34(%esp),%edx\n"
+"mov0x38(%esp),%eax\n"
+"mov%edx,%esp\n"
+"test   %ecx,%ecx\n"
+"je nxt2\n"
+"ldmxcsr (%esp)\n"
+"fldcw  0x4(%esp)\n"
+"nxt2:\n"
+"lea0x8(%esp),%esp\n"
+"mov%fs:0x18,%edx\n"
+"pop%ecx\n"
+"mov%ecx,0x10(%edx)\n"
+"pop%ecx\n"
+"mov%ecx,0xe0c(%edx)\n"
+"pop%ecx\n"
+"mov%ecx,0x8(%edx)\n"
+"pop%ecx\n"
+"mov%ecx,0x4(%edx)\n"
+"pop%ecx\n"
+"mov%ecx,(%edx)\n"
+"pop%edi\n"
+"pop%esi\n"
+"pop%ebx\n"
+"pop%ebp\n"
+"pop%edx\n"
+"mov%eax,0x4(%esp)\n"
+"jmp*%edx\n"
+);
+
+#endif
+
+#if defined(LIBCONTEXT_PLATFORM_windows_i386) && defined(LIBCONTEXT_COMPILER_gcc)
+__asm (
+".text\n"
+".p2align 4,,15\n"
+".globl	_make_fcontext\n"
+".def	_make_fcontext;	.scl	2;	.type	32;	.end

Re: [Kicad-developers] [RFC PATCH] No more boost::context

[Tomasz Wlostowski]

On 21.01.2016 15:03, Chris Pavlina wrote:
> Hm, is this really something we want to get into? Nice to remove the 
> dependency, but when something breaks in the future, do we have any/many 
> developers who can support x86 assembly code?
> 

Concerning the support: I can do that, but there is absolutely nothing
to support. This library does just context switching and nothing else
and it contains no original code. In fact, it's generated from
boost::context by a script. It will never need an update unless:
- We decide to support a completely new HW platform. Porting anything
that boost::context already supports is trivial. I didn't include
MIPS/PPC/Sparc/ARM platform files because I couldn't test if they work.
- We change the compiler to something else than Clang/GCC.
- Intel changes the instruction set of their CPUs.

> I really think that if we're going to have to support this, it should be 
> something conceptually simpler, like an emulation of coroutines using a 
> set of threads and locks.

Have a look at the discussion between Lorenzo, Kristian and Torsten.
Emulating coroutines with threads can only bring more problems.

Cheers,
Tom


> 
> On Thu, Jan 21, 2016 at 02:42:05PM +0100, Tomasz Wlostowski wrote:
>> Hi,
>>
>> This patch replaces boost::context with a small library called
>> libcontext (derived from boost::context sources). It drops the
>> dependency on boost for the cost of one additional header file and cpp
>> file (taking inspiration from ClipperLib).
>>
>> I've tested the new context switching code on Linux, OSX (El Capitan) &
>> Windows (all OS 32-bit and 64-bit Intel). Supported compilers are GCC
>> and Clang.
>>
>> Let me know if Kicad builds and works correctly on your platforms...
>>
>> Cheers,
>> Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC PATCH] No more boost::context

[Tomasz Wlostowski]

On 21.01.2016 15:20, Lorenzo Marcantonio wrote:
> On Thu, Jan 21, 2016 at 09:03:59AM -0500, Chris Pavlina wrote:
>> Hm, is this really something we want to get into? Nice to remove
>> the dependency, but when something breaks in the future, do we
>> have any/many developers who can support x86 assembly code?
> 
> boost::context is broken anyway so either you wait for them to fix
> it or invent something different (see other coroutine thread...)

It's not completely broken. The GNU asm files for Windows are still
from an old version. When the Windows developer changed the context
structure layout, (s)he only updated the Microsoft asm files, so the
GNU ones are incompatible.

The goal of libcontext is to have the right version, everywhere,
without worrying about the installed boost version and the OS. In the
current coroutine code we currently have #ifdefs checking the boost
version because the API of the library was changed between 1.55 and
1.56...

Cheers,
Tom
> 
> 
> 
> ___ Mailing list:
> https://launchpad.net/~kicad-developers Post to :
> kicad-developers@lists.launchpad.net Unsubscribe :
> https://launchpad.net/~kicad-developers More help   :
> https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC PATCH] No more boost::context

[Tomasz Wlostowski]

On 21.01.2016 17:34, Simon Richter wrote:
> Hi,
> 
> Am 21.01.2016 um 14:42 schrieb Tomasz Wlostowski:
> 
>> I've tested the new context switching code on Linux, OSX (El
>> Capitan) & Windows (all OS 32-bit and 64-bit Intel). Supported
>> compilers are GCC and Clang.
> 
> Wouldn't that kill all non-Intel platforms? IIRC there are a number
> of people running KiCad on ARM based systems, and Debian will
> certainly complain if ten architectures are dropped.

Hi,

My intentions are very far from killing any platform (maybe except the
8051 ;-)

I don't mind including the rest of boost::context code in the new
library (ARM included) if somebody tests it on these platforms. It's
just a script-driven conversion, but the compiler/ABI detection code
must be written and tested. I'll try to build it for ARM and test on a
raspi as soon as I'll find some time.

Currently Kicad supports only Intel-based platforms and the patch is
intended to make them build reliably. What happens if Boost devs
decide to change the ABI of the context library once again, like they
did between 1.55 and 1.56? Should we #ifdef all our code to support
every Boost configuration on the planet?

We can't be responsible for every single build on every single
architecture and OS.

Regards,
Tom



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC PATCH] No more boost::context

[Tomasz Wlostowski]

On 21.01.2016 17:34, Simon Richter wrote:
> Hi,
> 

> IIRC there are a number of
> people running KiCad on ARM based systems, 

Patch for 32-bit ARM (tested on a raspberry pi) attached.

Tom

> 
>Simon
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

>From ea3a58c2a3f8ff4d59532992c06bf197d442c161 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= <tomasz.wlostow...@cern.ch>
Date: Thu, 21 Jan 2016 20:25:08 +0100
Subject: [PATCH] replaced boost::context with libcontext

---
 CMakeLists.txt   |   2 +-
 common/CMakeLists.txt|   2 +
 common/system/libcontext.cpp | 609 +++
 include/system/libcontext.h  |  85 ++
 include/tool/coroutine.h |  27 +-
 5 files changed, 705 insertions(+), 20 deletions(-)
 create mode 100644 common/system/libcontext.cpp
 create mode 100644 include/system/libcontext.h

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f655f37..bea5039 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -460,7 +460,7 @@ find_package( Cairo 1.8.8 REQUIRED )
 #
 # Note: Prior to Boost 1.59, the Boost context library is not built when compiling on windows
 #   with GCC.  You must patch the Boost sources.
-find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread )
+find_package( Boost 1.54.0 REQUIRED COMPONENTS system thread )
 
 # Include MinGW resource compiler.
 include( MinGWResourceCompiler )
diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index 048ddf0..d45064c 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -271,6 +271,8 @@ endif()
 
 set( COMMON_SRCS
 ${COMMON_SRCS}
+system/libcontext.cpp
+
 kicad_curl/kicad_curl.cpp
 kicad_curl/kicad_curl_easy.cpp
 
diff --git a/common/system/libcontext.cpp b/common/system/libcontext.cpp
new file mode 100644
index 000..f2ce880
--- /dev/null
+++ b/common/system/libcontext.cpp
@@ -0,0 +1,609 @@
+/*
+
+auto-generated file, do not modify!
+libcontext - a slightly more portable version of boost::context
+Copyright Martin Husemann 2013.
+Copyright Oliver Kowalke 2009.
+Copyright Sergue E. Leontiev 2013
+Copyright Thomas Sailer 2013.
+Minor modifications by Tomasz Wlostowski 2016.
+
+ Distributed under the Boost Software License, Version 1.0.
+  (See accompanying file LICENSE_1_0.txt or copy at
+http://www.boost.org/LICENSE_1_0.txt)
+
+*/
+#include 
+
+#if defined(LIBCONTEXT_PLATFORM_windows_i386) && defined(LIBCONTEXT_COMPILER_gcc)
+__asm (
+".text\n"
+".p2align 4,,15\n"
+".globl	_jump_fcontext\n"
+".def	_jump_fcontext;	.scl	2;	.type	32;	.endef\n"
+"_jump_fcontext:\n"
+"mov0x10(%esp),%ecx\n"
+"push   %ebp\n"
+"push   %ebx\n"
+"push   %esi\n"
+"push   %edi\n"
+"mov%fs:0x18,%edx\n"
+"mov(%edx),%eax\n"
+"push   %eax\n"
+"mov0x4(%edx),%eax\n"
+"push   %eax\n"
+"mov0x8(%edx),%eax\n"
+"push   %eax\n"
+"mov0xe0c(%edx),%eax\n"
+"push   %eax\n"
+"mov0x10(%edx),%eax\n"
+"push   %eax\n"
+"lea-0x8(%esp),%esp\n"
+"test   %ecx,%ecx\n"
+"je nxt1\n"
+"stmxcsr (%esp)\n"
+"fnstcw 0x4(%esp)\n"
+"nxt1:\n"
+"mov0x30(%esp),%eax\n"
+"mov%esp,(%eax)\n"
+"mov0x34(%esp),%edx\n"
+"mov0x38(%esp),%eax\n"
+"mov%edx,%esp\n"
+"test   %ecx,%ecx\n"
+"je nxt2\n"
+"ldmxcsr (%esp)\n"
+"fldcw  0x4(%esp)\n"
+"nxt2:\n"
+"lea0x8(%esp),%esp\n"
+"mov%fs:0x18,%edx\n"
+"pop%ecx\n"
+"mov%ecx,0x10(%edx)\n"
+"pop%ecx\n"
+"mov%ecx,0xe0c(%edx)\n"
+"pop%ecx\n"
+"mov%ecx,0x8(%edx)\n"
+"pop%ecx\n"
+"mov%ecx,0x4(%edx)\n"
+"pop%ecx\n"
+"mov%ecx,(%edx)\n"
+"pop%edi\n"
+"pop%esi\n"
+"pop%ebx\n"
+"pop%ebp\n"
+"pop%edx\n"
+"mov%eax,0x4(%esp)\n"
+"jmp*%edx\n"
+);
+
+#endif
+
+#if defined(LIBCONTEXT_PLATFORM_windows_i386) && defined(LIBCONTEXT_COMPILER_gcc)
+__asm (
+".text\n"
+".p2align 4,,15\n"
+".globl	_make_fcontext\n"
+".d

Re: [Kicad-developers] [RFC PATCH] Single-click board update, take 2.

[Tomasz Wlostowski]

On 21.01.2016 23:50, Nick Østergaard wrote:
> Hi Tomasz
> 
> This sounds promising, but I just have a small comment reading this. I
> have not yet tested the patces, and I won't have time until... maybe
> next week.
> 
> But is it your intention to use F9? That is currently assigned to the
> switch to legacy canvas in pcbnew.

Hi Nick,

We can choose any other hotkey ;)

Cheers,
T.
> 
> Nick
> 
> 2016-01-21 23:30 GMT+01:00 Tomasz Wlostowski <tomasz.wlostow...@cern.ch>:
>> Dear all,
>>
>> This patchset contains an updated version of the single-click SCH->PCB
>> update tool.
>>
>> The way it works is:
>> - press F9 (or select Tools->Update PCB From Schematics) in eeschema or
>> pcbnew
>> - a window with changes to be applied to PCB will appear
>> - you can check for errors/warnings/review what is going to be changed
>> - click "Perform PCB update" or press Enter to proceed (or cancel).
>> - netlist updates can be undone (Ctrl-Z restores PCB state after wrong
>> netlist load).
>>
>> The changes since the previous version are:
>> - automatic spreading of the new footprints outside board area,
>> - fixed undo-related crashes,
>> - the tool can be now invoked both from the schematics & PCB editor.
>> - pcbnew window is now automagically opened the first time user calls
>> for an update.
>>
>> Note it will only work when Kicad is opened in Project Manager mode.
>>
>> Thanks in advance for testing & comments,
>>
>> Cheers,
>> Tom
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Grid in GAL canvas

[Tomasz Wlostowski]

On 15.01.2016 00:50, Wayne Stambaugh wrote:
> On 1/14/2016 3:06 PM, Bernhard Stegmaier wrote:
>> Question for me is what happens to eeschema?
>> For pcbnew it is maybe just adding some missing things and polishing some 
>> other, but eeschema currently has nothing in that direction.
>> Anybody already working on that?
> 
> Implementing GAL and the new tool framework in Eeschema is coming as
> part of the current dev cycle.  It wont start until after I finish up
> with the Eeschema refactor.  Trust me when I tell you, to do so would
> not be a good idea.
> 
>>
>>
>> Regards,
>> Bernhard
>>
>>> On 14.01.2016, at 20:54, Chris Pavlina  wrote:
>>>
>>> Are we even still going to have legacy pcbnew at the next release? 
>>> What's the schedule for fully deprecating it?
> 
> It will not be deprecated until we have one for one feature parity
> between the canvases and we can get by without it on all supported
> platforms.  AFAIK, Tom is working on a wxDC gal implementation which
> should eliminate the second part.  If this happens before the next
> release, then there is no reason to continue to support the legacy canvas.
> 
Hi,

So, the wxdc GAL is progressing, although I'm a bit stuck now with layer
ordering (in OpenGL you have Z-buffer for free, in wxDC it's a bit more
tricky to draw stuff in order and avoid sorting).

The new version will also support 'flipped' PCB mode (editing a PCB
laying upside down - quite useful for placing the component on the
bottom side of the board). I'm also simplifying the VIEW_ITEM interface
and the making the updates of the view less invasive.

Cheers,
Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC PATCH] Rounded rectangle pads

[Tomasz Wlostowski]

On 15.01.2016 21:02, jp charras wrote:
> Le 14/01/2016 01:39, Cirilo Bernardo a écrit :
>> On Tue, Jan 12, 2016 at 10:06 AM, Mathias Grimmberger 
>> wrote:
> 
> <>
> 
>> I'd like to implement arbitrary pad shapes but this requires a functional 2D
>> geometry kernel first. I'm starting on one but I may have nothing to
>> demonstrate
> 
> There is already a geometry kernel in Kicad: Have a look at
> include/geometry before writing anything.

Hi JP & Cirilo,

Indeed, there is a lightweight geometry kernel, used by the P It can
do collision detection really fast - this means improvement of the DRC &
connectivity checking too. Instead of writing a new kernel, we should
focus on adding features to the existing one. What's currently missing:
- arc support (SHAPE_ARC)
- efficient indexing of large polygons (generating convex partitions and
indexing convex polygons with smaller overlap).

With these two features, we can have arbitrary pad shapes, teardrops,
improved connectivity calculation (= stitching vias) and much faster DRC.

Cheers,
Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] wxDC GAL (Re: Grid in GAL canvas)

[Tomasz Wlostowski]

On 15.01.2016 20:44, "Torsten Hüter" wrote:
> Hi,
>  
> Are we even still going to have legacy pcbnew at the next release?
> What's the schedule for fully deprecating it?
>>>
>>> It will not be deprecated until we have one for one feature parity
>>> between the canvases and we can get by without it on all supported
>>> platforms. AFAIK, Tom is working on a wxDC gal implementation which
>>> should eliminate the second part. If this happens before the next
>>> release, then there is no reason to continue to support the legacy canvas.
>  
> Is this a new decision? I thought that wxDC is not that much interesting, 
> because it usesis deprecated functions and is problematic on some platforms.
> 
> I did an wxDC implementation, this was my last work on the GAL and then Orson 
> continued it and he should know this implementation.
> 
Hi Torsten,

Our development is based on your wxDC code. Many thanks for it.

Cairo is unbearably slow also because it tries to mimic openGL behaviour
(for instance, transparency and Z-buffering, so that overlapping
trace/pad corners are not brightened). This is for free in OpenGL, but
very expensive in Cairo. We'll also check how much speedup we'll get by
disabling these features in Cairo.

Another issue is, that Cairo - as used in the GAL - renders to a memory
surface, which means a purely software renderer. wxDC can benefit from
HW 2D acceleration, at least on some platforms.

Cheers,
Tom


> You can find the code here:
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/kicad-gal/files/head:/gal/wxdc/
> 
> Funny that this is almost 4 years old :)
> 
> That could be helpful for Tom.
> 
> Thanks,
> Torsten
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Grid in GAL canvas

[Tomasz Wlostowski]

On 14.01.2016 20:14, Chris Pavlina wrote:
> Carefully, and with a nice Thank You note to whoever chose to use the 
> middle button on those :>

I also find it quite counter-intuitive. We could at least add context
menu with a 'choose color' option.

T.

> 
> On Thu, Jan 14, 2016 at 08:15:26PM +0100, Bernhard Stegmaier wrote:
>> How do I middle click on OSX (without a non-Apple mouse that has 3 buttons…)?
>>
>>> On 14 Jan 2016, at 20:14, Simon Wells <swel...@gmail.com> wrote:
>>>
>>> middle click?
>>>
>>> On Fri, Jan 15, 2016 at 8:12 AM, Bernhard Stegmaier 
>>> <stegma...@sw-systems.de <mailto:stegma...@sw-systems.de>> wrote:
>>> How do you change at all?
>>>
>>> In the “Visibles” toolbar with Render=>Grid by clicking on the small button?
>>> 
>>>
>>> Nothing happens when I click there… but not only for grid, but also all the 
>>> other buttons...
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>>> On 14 Jan 2016, at 20:04, Chris Pavlina <pavlina.ch...@gmail.com 
>>>> <mailto:pavlina.ch...@gmail.com>> wrote:
>>>>
>>>> Tom, there's a minor bug with the grid color - I'd fix it myself, but 
>>>> I'm not familiar with the GAL stuff yet and don't want to go breaking 
>>>> anything. When you change the grid color while GAL is active, the grid 
>>>> doesn't refresh until you change the zoom level. I assume fixing that is 
>>>> as simple as sticking a refresh call of some sort in the right place?
>>>>
>>>>
>>>> On Thu, Jan 14, 2016 at 08:00:32PM +0100, Tomasz Wlostowski wrote:
>>>>> On 14.01.2016 19:57, Bernhard Stegmaier wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I know, I am difficult… :)
>>>>>>
>>>>>> In GAL canvas grid was almost invisible up to now.
>>>>>>
>>>>>> With one of the last commit it obviously respects grid color which it
>>>>>> didn’t before… yes, it is very visible now:
>>>>>>
>>>>>
>>>>> Hi Bernhard,
>>>>>
>>>>> I fixed this aside fixing another grid-related issue in the GAL canvas.
>>>>> You can use the darkest colors if the grid is too bright :)
>>>>>
>>>>>> I have seen in the code that a “dot” grid (using small rectangles) seems
>>>>>> to be implemented… any special reasons why this is not used?
>>>>> None - just nobody thought about it, until now.
>>>>>
>>>>>> Should this maybe get a configuration option?
>>>>>
>>>>> Sure.
>>>>>
>>>>> Regards,
>>>>> Tom
>>>>>
>>>>> ___
>>>>> Mailing list: https://launchpad.net/~kicad-developers 
>>>>> <https://launchpad.net/~kicad-developers>
>>>>> Post to : kicad-developers@lists.launchpad.net 
>>>>> <mailto:kicad-developers@lists.launchpad.net>
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>>>> <https://launchpad.net/~kicad-developers>
>>>>> More help   : https://help.launchpad.net/ListHelp 
>>>>> <https://help.launchpad.net/ListHelp>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to : kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>>>
>>>
>>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Grid in GAL canvas

[Tomasz Wlostowski]

On 14.01.2016 19:57, Bernhard Stegmaier wrote:
> Hi,
> 
> I know, I am difficult… :)
> 
> In GAL canvas grid was almost invisible up to now.
> 
> With one of the last commit it obviously respects grid color which it
> didn’t before… yes, it is very visible now:
> 

Hi Bernhard,

I fixed this aside fixing another grid-related issue in the GAL canvas.
You can use the darkest colors if the grid is too bright :)

> I have seen in the code that a “dot” grid (using small rectangles) seems
> to be implemented… any special reasons why this is not used?
None - just nobody thought about it, until now.

> Should this maybe get a configuration option?

Sure.

Regards,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] automatic zone merging - question?

[Tomasz Wlostowski]

On 12.01.2016 17:31, Chris Pavlina wrote:
> TBH I've never personally needed overlapping zones of the same net, 
> layer, and priority myself, though - I'm sure if I ever encountered such 
> a need, I'd find it very annoying. ;)

Hi Chris,

I often need overlapping zones for complex split planes (Kicad doesn't
support them ... yet), because it's easier to edit/modify multiple
smaller pieces rather than a big plane spanning entire board. It's a
matter of taste, though.

I noticed, however, that if a zone is connected to another zone, but not
any pad/track/via, it is not filled (= pcbnew doesn't see it's connected
to any pin). Maybe this is the 1st reason why pcbnew automatically
merges all overlapping zones?

> 
> Perhaps a mode to select the behavior would be useful. Most graphics 
> applications have this for things like selections - drawing a selection 
> can usually replace, add to, or subtract from the existing selection. 
> Something like that for zones could be very useful, IMO, and it's a 
> familiar UI element to anyone who's done graphics editing.

For the moment, GAL canvas lets the user merge multiple zones upon
request (select a number of zones, R-click->Zones->Merge Zones).

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] automatic zone merging - question?

[Tomasz Wlostowski]

Hi,

When one draws a copper zone over another zone (with the same net, and
the same layer), the two zones are automagically merged in the default
canvas. This is sometimes not desired - at least by me (example:
repeated layout blocks with overlapping zones). Is there a non-obvious
reason why Kicad works this way (related to insulated copper island
removal/connectivity/DRC algorithms)?

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] libcurl github race condition

[Tomasz Wlostowski]

On 11.01.2016 01:49, Mark Roszko wrote:
> My proposed solution:
> 
> 2. Add a "update progress" UI, its completely stupid that when you
> open CVPCB that it silently tries to update your 30+ libraries in the
> background with no indication. This is really bad on users on bad
> connections.

If I may add my 5 cents: why check for updates every time a footprint is
needed?

Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Coroutines

[Tomasz Wlostowski]

On 04.01.2016 15:07, Mark Roszko wrote:
>> My offer would be to test an alternative implementation, to drop another 
>> Boost dependency and build upon a standard library foundation.
>> pthreads is not standard library <.<
> 

Hi Mark & Torsten,

Feel free to test any implementation you like (personally I would try
with setjmp() first). I don't have much time to work on this issue (I'm
busy these days adding a reasonably fast wxDC support to the GAL canvas...).

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] interactive router documentation

[Tomasz Wlostowski]

On 22.12.2015 18:44, Nick Østergaard wrote:
> It was moved to the doc a long time ago. No one removed it from the
> source repo. See
> http://docs.kicad-pcb.org/en/pcbnew.html#_interactive_router

Hi guys,

The doc is quite outdated and it doesn't include the newest features
(diff pairs & length tuned traces). I can't work on it for the moment.
If someone is willing to update it earlier than I could, I'd be very
grateful ;-)

Tom

> 
> IIRC
> 
> 2015-12-22 18:42 GMT+01:00 Marco Ciampa :
>> In
>>
>> Documentation/interactive_router
>>
>> there is a little doc about the interactive router.
>>
>> Is it duplicated in the docs?
>> If not, why not move it to the docs?
>>
>> Regards,
>>
>> --
>>
>>
>> Marco Ciampa
>>
>> I know a joke about UDP, but you might not get it.
>>
>> ++
>> | GNU/Linux User  #78271 |
>> | FSFE fellow   #364 |
>> ++
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Build failed in Jenkins: KiCad (Linux, all options, Debug) #978

[Tomasz Wlostowski]

On 21.12.2015 12:55, Miguel Angel Ajo wrote:
> :2237: 
> fatal error: error writing to /tmp/ccnWCU8r.s: No space left on device

Hi Miguel,

Looks like the hard drive on your machine is full ;)

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [rfc] actual sexpression parsing

[Tomasz Wlostowski]

On 18.12.2015 15:46, Edwin van den Oetelaar wrote:
> Concerning changing the format of the PCB file again...
> Making a new binary file format is a big NO NO NO (screaming) in my book.

Hi Edwin,

Don't worry, we are not going to change the format :)

> I want to be able to edit it with VIM if needed.

See, this is my point :) Why implement a new feature in pcbnew (so that
everybody can use it) if you can edit the .kicad_pcb with VIM...

Best,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [rfc] actual sexpression parsing

[Tomasz Wlostowski]

On 18.12.2015 13:55, Mark Roszko wrote:
> Writing a new state machine for every single list and every single
> file over and over again is the part I have problems with. There
> should be a single state machine that takes the tokens and gives you a
> list. Not 500 over the whole codebase.

Hi Mark,

May I add my 5 cents to this discussion...

- My only big concern with the current parser so far is the lexer code
generation done by CMake. I'm not a big fan of making scripts that
produce code which then gets compiled...

Anyway, since we got here, I have a devilish idea: why a text format at
all? Of course we are not going to change the format again (we have a
lot of more exciting things to do ;-), but to point out a few reasons:

- PCB files (as opposed to netlists) represent graphical objects. For
someone looking at a PCB file with a text editor, it's just meaningless
numbers. Diffs look equally horrible (just look at a diff between two
.kicad_pcb files after moving a couple of traces in P mode).

- binary formats are generally easier to parse (unless someone made it
deliberately difficult - but it's not our case). We could just serialize
objects directly to a binary file, along with some version info (think
of Google's protobuf). This would also let us implement introspection
(e.g. a property editor tool) for no extra cost.

- Our s-expr format needs a custom parser (correct me if I'm wrong),
which contradicts the idea that generic text formats (e.g. json/lisp
s-expr, even lua/python arrays) need no dedicated parsers.

- Last but not least (and surely not least controversial): file format
that is easy to hand-edit enables people to hack scripts that do stuff
that Kicad is currently missing. This is an advantage for some (perhaps
more advanced) users who can work around missing features this way, but
is it really beneficial for Kicad as a complete PCB design tool? If the
easiest way is to hack a PCB file with a perl script/text editor, what
motivation is left to implement the missing feature in Kicad?

Cheers,
Tom



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Reorganize eeschema options a bit

[Tomasz Wlostowski]

On 18.12.2015 18:16, Chris Pavlina wrote:
> Related to my previous mail, as it would add an option or two - Wayne 
> suggested, and I agree, that the eeschema options dialog is getting 
> stuffed. I suggested that I kind of wanted to rework the options system 
> as a whole, but that's a big project, and organizing them has to come 
> first anyway.
> 
> I can easily rearrange them, into multiple tabs; it shouldn't take more 
> than an hour or so - nice quick change. How's this for a proposed tree 
> of options? Each page will then be subdivided into simple groups of 
> three or four options.
> 
> - General
> - Undo and Save
> - Auto-save time interval
> - Maximum undo items
> - Interface
> - Center and warp cursor on zoom
> - Use middle mouse button to pan
> - Limit panning to scroll size
> - Pan while moving object
> - Component management
> - Use wildcards in component chooser (see previous RFC ;)
> - Display
> - Show page limits
> - Grid size
> - Bus thickness
> - Line thickness
> - Part ID notation
> - Editing
> - Repeat items
> - Horizontal pitch of repeated items
> - Vertical pitch of repeated items
> - Increment of repeated labels
> - Field autoplacement
> - Automatically place component fields
> - Allow field autoplace to change justification
> - Always align autoplaced fields to the 50 mil grid
> - Default field names
> 
> - REMOVED as they already exist elsewhere
> - Show hidden pins (on toolbar)
> - Measurement units (on toolbar)
> - Show grid (on toolbar)
> - Restrict buses and wires to H and V orientation
> 
^
Hi Chris,

I wouldn't remove anything that is accessible from the toolbars. In the
future, we plan to go for wxAUI and make the toolbars optional and
configurable by the user. IMHO all configuration options must be present
somewhere (preferably at the most logical locations) in the options dialog.

Cheers,
Tom
> 
> --
> Chris
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [RFC] Wildcard and/or regex support in the component chooser

[Tomasz Wlostowski]

On 18.12.2015 19:25, Jon Evans wrote:
> Here's a quick example using an open-source JavaScript library and a
> list of some XMEGA parts I copied from digikey :-)
> https://jsfiddle.net/o7ms290j/embedded/result/


Wow, that's cool. Does anyone know a similar thing in C++?

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Tomasz Wlostowski]

On 15.12.2015 16:52, Wayne Stambaugh wrote:
> Sorry I didn't respond to this sooner but I've been busy.  I'm not
> thrilled with this idea.  I know it solves the immediate problem but it
> is an incomplete solution.

Hi Wayne,

I surely agree that changing just the net propagation algorithm is not
enough, but I'm not sure adding support for free vias needs to go as far
as changing the file format. Neither Eagle nor Altium (as far as I know)
have a special notion of a free via. In the latter, any via or trace (or
a free track) will retain its net unless:
- the net is removed from the netlist,
- new netcode is propagated from a pad through traces or vias and there
is no conflict (= more than 1 netcode hitting the item after propagation).
If the via is placed by the 'via' tool, it can also inherit its net from
the underlying zone, but only if there's no net conflict. I believe this
is more or less the behaviour of Steven's patch.

So IMHO, the minimum changes are:
- keep the file format unmodified.
- update the net propagation algorithm.
- update the DRC to always report tracks/vias not connected to any pad
(must take zone connections into account). Same for the 'cleanup' algorithm.
- update orphan filled area removal code to take stitching vias into
account.
- add a via placement tool (quite trivial, like MODULE_TOOLS::PlacePad
in the module editor)
- update the existing GAL track/via properties dialog to allow assigning
nets.
- add Ben's RF patches & update array tool ;)

None of these changes has impact on the file format/data model, so
hopefully they should not break anything and can be done incrementally.

Cheers,
Tom

  I would rather we do a complete free via
> implementation and not introduce a stop gap measure into Pcbnew.  We've
> discussed the idea of incorporating free vias many times in the past.
> Since we are in a new development cycle, now is the time to revisit
> this.  At a minimum this should include the following:
> 
> 1) Board file format support for free vias.  Do we need to add any new
> tokens to the board file format and where do we want to put the free
> vias in the board file?  We need to define what capabilities our free
> vias require and plan accordingly.  This will be a file format change so
> we need to consider this carefully.
> 
> 2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for
> adding and editing free vias.  Our array tool could come in handy here.
> 
> 3) Update DRC to handle free vias.
> 
> 4) Verify support code still works.  I'm guessing we wont need to change
> our plotting, printing, and/or export code since we already support
> through hole, micro, and blind/buried vias (are there any other types of
> vias?).
> 
> Please consider this instead of quick fixes.  This is one of the reasons
> the KiCad code base is so crufty.  We need to start doing a better job
> of looking at the big picture.
> 
> Cheers,
> 
> Wayne
> 
> On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote:
>> On 14.12.2015 14:40, Strontium wrote:
>>> Hi Thomas,
>>>
>>> I considered this, but tracking zones is non trivial.
>>>
>>> For example, imagine the stackup:
>>>
>>> GND
>>> VCC
>>> GND
>>> VCC
>>>
>>> A Through Via, from top to bottom could be connected validly connected
>>> to either GND or VCC.
>>>
>>> Once the net is removed from the via by the reassignment pass, there is
>>> no longer any information left to tell kicad which pair of zones was
>>> connected by the via.
>>
>> Indeed, in case of such a conflict retaining the via's net is IMHO the
>> only good solution.
>>
>>>
>>> The approach I suggest will fix this problem, because it just wont
>>> change the net for those vias.  It wont consider if there is a zone or
>>> not, it just says "hey, you gave it the GND net, so i will leave it as
>>> GND."
>>
>> It also seems Altium is managing via's nets this way. I would vote for
>> merging the patch.
>>
>> Cheers,
>> Tom
>>
>>>
>>>
>>> On 14/12/15 21:21, Tomasz Wlostowski wrote:
>>>> On 12.12.2015 02:41, Strontium wrote:
>>>>> This change should not break or modify any current behaviour, EXCEPT to
>>>>> retain the nets of tracks/vias which Kicad is otherwise incapable of
>>>>> determining automatically.
>>>> Hi Steven,
>>>>
>>>> Thanks for the patch, it also (partially) fixes the via stitching issue
>>>> many people have been complaining about. The origin of the problem is
>>>> that the net propagation code does not take zones into account - so

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Tomasz Wlostowski]

On 15.12.2015 19:09, jp charras wrote:
> Le 15/12/2015 18:44, Tomasz Wlostowski a écrit :
>> On 15.12.2015 16:52, Wayne Stambaugh wrote:
>>> Sorry I didn't respond to this sooner but I've been busy.  I'm not
>>> thrilled with this idea.  I know it solves the immediate problem but it
>>> is an incomplete solution.
>>
>> Hi Wayne,
>>
>> I surely agree that changing just the net propagation algorithm is not
>> enough, but I'm not sure adding support for free vias needs to go as far
>> as changing the file format. Neither Eagle nor Altium (as far as I know)
>> have a special notion of a free via. In the latter, any via or trace (or
>> a free track) will retain its net unless:
>> - the net is removed from the netlist,
>> - new netcode is propagated from a pad through traces or vias and there
>> is no conflict (= more than 1 netcode hitting the item after propagation).
>> If the via is placed by the 'via' tool, it can also inherit its net from
>> the underlying zone, but only if there's no net conflict. I believe this
>> is more or less the behaviour of Steven's patch.
>>
>> So IMHO, the minimum changes are:
>> - keep the file format unmodified.
>> - update the net propagation algorithm.
>> - update the DRC to always report tracks/vias not connected to any pad
>> (must take zone connections into account). Same for the 'cleanup' algorithm.
>> - update orphan filled area removal code to take stitching vias into
>> account.
>> - add a via placement tool (quite trivial, like MODULE_TOOLS::PlacePad
>> in the module editor)
>> - update the existing GAL track/via properties dialog to allow assigning
>> nets.
>> - add Ben's RF patches & update array tool ;)
>>
>> None of these changes has impact on the file format/data model, so
>> hopefully they should not break anything and can be done incrementally.
>>
>> Cheers,
>> Tom
> 
> Stitching vias must be added, but also removed and edited (size, drill,
> net name..) all in once.
> Therefore they need a "link" (for instance a time stamp) to be removed
> 
> A good via placement tool in not "quite trivial", but feasible, obvioulsy.
> 
> The first work is not write code, but define how vias stitching are
> managed (are they a group, and/or items inside a parent polygon like a
> zone ...)

Hi Jean-Pierre,

I didn't mean any special vias for stitching purposes, but simply
allowing the user to draw lone vias and make them retain their nets.
This is a feature many people have been asking for and currently use
workarounds like [1] to achieve it.

Cheers,
Tom

[1]. https://forum.kicad.info/t/protip-nicer-via-stitching/1103

> 
>>
>>   I would rather we do a complete free via
>>> implementation and not introduce a stop gap measure into Pcbnew.  We've
>>> discussed the idea of incorporating free vias many times in the past.
>>> Since we are in a new development cycle, now is the time to revisit
>>> this.  At a minimum this should include the following:
>>>
>>> 1) Board file format support for free vias.  Do we need to add any new
>>> tokens to the board file format and where do we want to put the free
>>> vias in the board file?  We need to define what capabilities our free
>>> vias require and plan accordingly.  This will be a file format change so
>>> we need to consider this carefully.
>>>
>>> 2) Editing tools (menu entries, toolbars, hot keys, dialogs, etc.) for
>>> adding and editing free vias.  Our array tool could come in handy here.
>>>
>>> 3) Update DRC to handle free vias.
>>>
>>> 4) Verify support code still works.  I'm guessing we wont need to change
>>> our plotting, printing, and/or export code since we already support
>>> through hole, micro, and blind/buried vias (are there any other types of
>>> vias?).
>>>
>>> Please consider this instead of quick fixes.  This is one of the reasons
>>> the KiCad code base is so crufty.  We need to start doing a better job
>>> of looking at the big picture.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 12/14/2015 9:26 AM, Tomasz Wlostowski wrote:
>>>> On 14.12.2015 14:40, Strontium wrote:
>>>>> Hi Thomas,
>>>>>
>>>>> I considered this, but tracking zones is non trivial.
>>>>>
>>>>> For example, imagine the stackup:
>>>>>
>>>>> GND
>>>>> VCC
>>>>> GND
>>>>> VCC
>>>>>
>>>>> A Throug

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Tomasz Wlostowski]

On 12.12.2015 02:41, Strontium wrote:
> This change should not break or modify any current behaviour, EXCEPT to
> retain the nets of tracks/vias which Kicad is otherwise incapable of
> determining automatically.

Hi Steven,

Thanks for the patch, it also (partially) fixes the via stitching issue
many people have been complaining about. The origin of the problem is
that the net propagation code does not take zones into account - so a
via that is not connected to any pad with a chain of tracks is treated
as disconnected.

Adding zone support in the net calculation code should AFAIK fix this
for good, but it may also require enhancing the DRC (so that it will
report every object with no pad connection) and the 'clean tracks'
tool code.

Regards,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

[Tomasz Wlostowski]

On 14.12.2015 14:40, Strontium wrote:
> Hi Thomas,
> 
> I considered this, but tracking zones is non trivial.
> 
> For example, imagine the stackup:
> 
> GND
> VCC
> GND
> VCC
> 
> A Through Via, from top to bottom could be connected validly connected
> to either GND or VCC.
> 
> Once the net is removed from the via by the reassignment pass, there is
> no longer any information left to tell kicad which pair of zones was
> connected by the via.

Indeed, in case of such a conflict retaining the via's net is IMHO the
only good solution.

> 
> The approach I suggest will fix this problem, because it just wont
> change the net for those vias.  It wont consider if there is a zone or
> not, it just says "hey, you gave it the GND net, so i will leave it as
> GND."

It also seems Altium is managing via's nets this way. I would vote for
merging the patch.

Cheers,
Tom

> 
> 
> On 14/12/15 21:21, Tomasz Wlostowski wrote:
>> On 12.12.2015 02:41, Strontium wrote:
>>> This change should not break or modify any current behaviour, EXCEPT to
>>> retain the nets of tracks/vias which Kicad is otherwise incapable of
>>> determining automatically.
>> Hi Steven,
>>
>> Thanks for the patch, it also (partially) fixes the via stitching issue
>> many people have been complaining about. The origin of the problem is
>> that the net propagation code does not take zones into account - so a
>> via that is not connected to any pad with a chain of tracks is treated
>> as disconnected.
>>
>> Adding zone support in the net calculation code should AFAIK fix this
>> for good, but it may also require enhancing the DRC (so that it will
>> report every object with no pad connection) and the 'clean tracks'
>> tool code.
>>
>> Regards,
>> Tom
>>
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Segfault in PNS on BZR 6317

[Tomasz Wlostowski]

On 17.11.2015 20:07, Andrew Zonenberg wrote:
> Hi,
> 
> I'm getting crashes in the PNS on latest BZR in both debug and release
> builds.
> 
Hi Wayne,

Patch for the segfault in the attachment. There are also two more bugfixes:
#1514081: recalculation of the ratsnest after drawing a zone in the GAL
#1514126: performance improvement in zone processing code (it was using
too much strict simplification)

Cheers,
Tom

>From 42b43b3b9b037c8ffaaf94868889d97d0081831e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= 
Date: Wed, 18 Nov 2015 10:40:16 +0100
Subject: [PATCH 1/3] router: fixed segfault caused by invalidation of the end
 item by PNS_LINE_PLACER::UpdateSizes()

---
 pcbnew/router/pns_line_placer.cpp |  4 
 pcbnew/router/pns_router.cpp  |  5 -
 pcbnew/router/pns_router.h|  4 
 pcbnew/router/router_tool.cpp | 10 ++
 pcbnew/router/router_tool.h   |  2 +-
 5 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/pcbnew/router/pns_line_placer.cpp b/pcbnew/router/pns_line_placer.cpp
index 96aa6de..7f4efb4 100644
--- a/pcbnew/router/pns_line_placer.cpp
+++ b/pcbnew/router/pns_line_placer.cpp
@@ -87,9 +87,6 @@ bool PNS_LINE_PLACER::ToggleVia( bool aEnabled )
 if( !aEnabled )
 m_head.RemoveVia();
 
-if( !m_idle )
-Move( m_currentEnd, NULL );
-
 return true;
 }
 
@@ -1021,7 +1018,6 @@ void PNS_LINE_PLACER::UpdateSizes( const PNS_SIZES_SETTINGS& aSizes )
 if( !m_idle )
 {
 initPlacement( m_splitSeg );
-Move ( m_currentEnd, NULL );
 }
 }
 
diff --git a/pcbnew/router/pns_router.cpp b/pcbnew/router/pns_router.cpp
index af940da..6f64f96 100644
--- a/pcbnew/router/pns_router.cpp
+++ b/pcbnew/router/pns_router.cpp
@@ -458,7 +458,6 @@ PNS_ROUTER::PNS_ROUTER()
 m_showInterSteps = false;
 m_snapshotIter = 0;
 m_view = NULL;
-m_currentEndItem = NULL;
 m_snappingEnabled  = false;
 m_violation = false;
 m_gridHelper = NULL;
@@ -646,7 +645,6 @@ bool PNS_ROUTER::StartRouting( const VECTOR2I& aP, PNS_ITEM* aStartItem, int aLa
 return false;
 
 m_currentEnd = aP;
-m_currentEndItem = NULL;
 m_state = ROUTE_TRACK;
 return rv;
 }
@@ -724,7 +722,6 @@ void PNS_ROUTER::DisplayDebugPoint( const VECTOR2I aPos, int aType )
 void PNS_ROUTER::Move( const VECTOR2I& aP, PNS_ITEM* endItem )
 {
 m_currentEnd = aP;
-m_currentEndItem = endItem;
 
 switch( m_state )
 {
@@ -827,7 +824,6 @@ void PNS_ROUTER::UpdateSizes ( const PNS_SIZES_SETTINGS& aSizes )
 if( m_state == ROUTE_TRACK)
 {
 m_placer->UpdateSizes( m_sizes );
-movePlacing( m_currentEnd, m_currentEndItem );
 }
 }
 
@@ -997,7 +993,6 @@ void PNS_ROUTER::FlipPosture()
 if( m_state == ROUTE_TRACK )
 {
 m_placer->FlipPosture();
-movePlacing ( m_currentEnd, m_currentEndItem );
 }
 }
 
diff --git a/pcbnew/router/pns_router.h b/pcbnew/router/pns_router.h
index 0541dec..4bc4bc3 100644
--- a/pcbnew/router/pns_router.h
+++ b/pcbnew/router/pns_router.h
@@ -263,13 +263,9 @@ private:
 KIGFX::VIEW* m_view;
 KIGFX::VIEW_GROUP* m_previewItems;
 
-PNS_ITEM* m_currentEndItem;
-
 bool m_snappingEnabled;
 bool m_violation;
 
-// optHoverItem m_startItem, m_endItem;
-
 PNS_ROUTING_SETTINGS m_settings;
 PNS_PCBNEW_CLEARANCE_FUNC* m_clearanceFunc;
 
diff --git a/pcbnew/router/router_tool.cpp b/pcbnew/router/router_tool.cpp
index 4b610a3..387e03c 100644
--- a/pcbnew/router/router_tool.cpp
+++ b/pcbnew/router/router_tool.cpp
@@ -382,7 +382,7 @@ void ROUTER_TOOL::switchLayerOnViaPlacement()
 }
 
 
-bool ROUTER_TOOL::onViaCommand( VIATYPE_T aType )
+bool ROUTER_TOOL::onViaCommand( TOOL_EVENT& aEvent, VIATYPE_T aType )
 {
 BOARD_DESIGN_SETTINGS& bds = m_board->GetDesignSettings();
 
@@ -475,6 +475,8 @@ bool ROUTER_TOOL::onViaCommand( VIATYPE_T aType )
 m_router->UpdateSizes( sizes );
 m_router->ToggleViaPlacement();
 
+updateEndItem( aEvent );
+
 m_router->Move( m_endSnapPoint, m_endItem );// refresh
 
 return false;
@@ -576,15 +578,15 @@ void ROUTER_TOOL::performRouting()
 }
 else if( evt->IsAction( _PlaceThroughVia ) )
 {
-onViaCommand( VIA_THROUGH );
+onViaCommand( *evt, VIA_THROUGH );
 }
 else if( evt->IsAction( _PlaceBlindVia ) )
 {
-onViaCommand( VIA_BLIND_BURIED );
+onViaCommand( *evt, VIA_BLIND_BURIED );
 }
 else if( evt->IsAction( _PlaceMicroVia ) )
 {
-onViaCommand( VIA_MICROVIA );
+onViaCommand( *evt, VIA_MICROVIA );
 }
 else if( evt->IsAction( _SwitchPosture ) )
 {
diff --git a/pcbnew/router/router_tool.h b/pcbnew/router/router_tool.h
index 08f2f84..c1bd1a2 100644
--- a/pcbnew/router/router_tool.h
+++ b/pcbnew/router/router_tool.h
@@ -54,7 +54,7 @@ private:
 
 int getStartLayer( const PNS_ITEM* aItem );

Re: [Kicad-developers] cached_container and memory management: sometimes run out of memory.

[Tomasz Wlostowski]

On 16.11.2015 08:52, jp charras wrote:
> Here is my question:
> Is it possible to keep the largest allocated block during the session,
> without frequently allocating intermediate blocks, to avoid the memory
> fragmentation in to smaller blocks ?
> And is it possible to reduce or optimize this size ?
> 
> (currently, I cannot edit wrs.kicad_pcb on W7 32 bits more than 5 minutes)
Hi Jean-Pierre,

I think it's possible, but I would like to consult this with Orson (he's
still away from CERN and coming back on Monday).

Best,
Tom



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] poly2tri

[Tomasz Wlostowski]

On 13.11.2015 20:49, jp charras wrote:
> Le 12/11/2015 20:52, Mark Roszko a écrit :
>> Woops, my bad. They were going to remove poly2tri when removing 
>> boost::polygon
>>
>> On Thu, Nov 12, 2015 at 2:50 PM, Mark Roszko  wrote:
>>> From what I can recall, poly2tri was intended as the replacement for
>>> boost::polygon.
>>>
>>> On Thu, Nov 12, 2015 at 2:37 PM, Mário Luzeiro  wrote:
 Hello all,

 I notice that there is a poly2tri library in polygon/poly2tri/ folder of 
 kicad but it is not used.
 I would like to use it in the 3d render (instead of using the openGL uggly 
 tesselator)
 Are you plan to keep the poly2tri there? It will help me :)

 Mario "KammutierSpule" Luzeiro
> 
> CERN guys have added this lib, but I don't know if it was used.
> 
> It is a small lib, and if you need to use it, I do not see any problem.
> 
Hi,

I've added it initially for Delaunay triangulation (used in ratsnest
calculation), but later on Orson decided to use another lib (halfedge)
for that purpose. The other purpose is keeping convex/triangulated
partitions of filled zones/keepouts (for future DRC checks and P
keepout support).

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Plans for (OpenGL-/Cairo-/Default-) canvases after stable?

[Tomasz Wlostowski]

On 08.11.2015 22:43, Bernhard Stegmaier wrote:
> is there any roadmap/plan for how to go on with the three canvases in pcbnew 
> after the stable release?

Hi Bernhard,

Yes, there is a plan. In short:
- Port the remaining features of the "legacy" canvas such as component
auto-placement or delete-track-while-routing to the GAL. We'll
appreciate any help with assembling a list of features still missing in
the GAL canvases.
- Improve the speed of the Cairo renderer so it's fast enough at least
for an Arduino-sized board.
- Drop the legacy canvas before the next stable release.

Regards,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] memory leak in meander placer [was: RC2]

[Tomasz Wlostowski]

On 07.11.2015 21:41, Wayne Stambaugh wrote:
 And speaking of pns, there is still CID 106401 where
 PNS_MEANDERED_LINE::MeanderSegment can memory leak.

Here's a patch for that.

Cheers,
T.
>From cd30ed5522dcced484ad6b0a80a0c35e1171c957 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= 
Date: Mon, 9 Nov 2015 10:19:31 +0100
Subject: [PATCH] router: fixed memory leak in the meander placer

---
 pcbnew/router/pns_meander.cpp | 31 ---
 pcbnew/router/pns_meander.h   |  5 +
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/pcbnew/router/pns_meander.cpp b/pcbnew/router/pns_meander.cpp
index 5bca9bb..6739401 100644
--- a/pcbnew/router/pns_meander.cpp
+++ b/pcbnew/router/pns_meander.cpp
@@ -61,11 +61,12 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
 
 do
 {
-PNS_MEANDER_SHAPE* m = new PNS_MEANDER_SHAPE( m_placer, m_width, m_dual );
-m->SetBaselineOffset( m_baselineOffset );
-m->SetBaseIndex( aBaseIndex );
+PNS_MEANDER_SHAPE m( m_placer, m_width, m_dual );
 
-double thr = (double) m->spacing();
+m.SetBaselineOffset( m_baselineOffset );
+m.SetBaseIndex( aBaseIndex );
+
+double thr = (double) m.spacing();
 
 bool fail = false;
 double remaining = base_len - ( m_last - aBase.A ).EuclideanNorm();
@@ -79,10 +80,10 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
 {
 for( int i = 0; i < 2; i++ )
 {
-if ( m->Fit( MT_CHECK_START, aBase, m_last, i ) )
+if ( m.Fit( MT_CHECK_START, aBase, m_last, i ) )
 {
 turning = true;
-AddMeander( m );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
 side = !i;
 started = true;
 break;
@@ -95,9 +96,9 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
 
 for( int i = 0; i < 2; i++ )
 {
-if ( m->Fit ( MT_SINGLE, aBase, m_last, i ) )
+if ( m.Fit ( MT_SINGLE, aBase, m_last, i ) )
 {
-AddMeander( m );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
 fail = false;
 started = false;
 side = !i;
@@ -106,17 +107,17 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
 }
 }
 } else {
-bool rv = m->Fit( MT_CHECK_FINISH, aBase, m_last, side );
+bool rv = m.Fit( MT_CHECK_FINISH, aBase, m_last, side );
 
 if( rv )
 {
-m->Fit( MT_TURN, aBase, m_last, side );
-AddMeander( m );
+m.Fit( MT_TURN, aBase, m_last, side );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
 started = true;
 } else {
-m->Fit( MT_FINISH, aBase, m_last, side );
+m.Fit( MT_FINISH, aBase, m_last, side );
 started = false;
-AddMeander( m );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
 turning = false;
 }
 
@@ -124,9 +125,9 @@ void PNS_MEANDERED_LINE::MeanderSegment( const SEG& aBase, int aBaseIndex )
 }
 } else if( started )
 {
-bool rv = m->Fit( MT_FINISH, aBase, m_last, side );
+bool rv = m.Fit( MT_FINISH, aBase, m_last, side );
 if( rv )
-AddMeander( m );
+AddMeander( new PNS_MEANDER_SHAPE( m ) );
 
 break;
 
diff --git a/pcbnew/router/pns_meander.h b/pcbnew/router/pns_meander.h
index 88fb2cc..5d1ae51 100644
--- a/pcbnew/router/pns_meander.h
+++ b/pcbnew/router/pns_meander.h
@@ -416,6 +416,11 @@ public:
 m_baselineOffset = 0;
 }
 
+~PNS_MEANDERED_LINE()
+{
+Clear();
+}
+
 /**
  * Function AddCorner()
  *
-- 
1.9.1

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Turning Off printf("H-net %d\n", aHead.Net()) ?

[Tomasz Wlostowski]

On 03.11.2015 15:30, Joseph Chen wrote:
> I recently started seeing lots of lines of printed texts on the terminal
> where kicad is started in Linux, and a quick grep shows the following
> line does the printouts:
> 
> pcbnew/router/pns_line_placer.cpp:1046:printf("H-net %d\n",
> aHead.Net());
> 
Sure, I missed this one...

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] RC2 blockers?

[Tomasz Wlostowski]

On 03.11.2015 20:13, Javier Serrano wrote:
> On Tue, Nov 3, 2015 at 12:39 AM, Wayne Stambaugh  wrote:
>> Yes.  The P router still has a serious segfault issue.  I've talked to
>> Tom about it and he is working on it.  As soon as the fixes are
>> committed, I will be rolling out rc2.  I'm hoping it will be soon.
> 
> Last time I saw Orson and Tom we were in Australia and they both
> looked like they could really use a few days/weeks of vacation. They
> stayed there and I am back in Geneva. I will talk with them when they
> are back, which is the 9th for Tom and the 17th for Orson.

Hi guys,

Here's an updated version of the patch. Wayne, if you haven't committed
the one I've sent you previously, please take this one. It also fixes
one more issue and removes the pritnfs() reported by Joseph. Sorry it
took so long.

Greetings from AU
Tom


> 
> Cheers,
> 
> Javier
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

>From 42f067b8b45aef8826cee8bcf6c1957f295a813b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= 
Date: Tue, 3 Nov 2015 20:21:02 +1000
Subject: [PATCH] Multiple fixes for the P router: - invalidate end item
 after changing layers / ortho mode (fixes a rare segfault) - fixed hidden
 database corrpution in auto-track-width causing assertion fail in pushVia()
 or segfault in release builds. - respect grid when snapping to segments  
   - fixed cursor issue when dragging is invoked from the context menu

---
 pcbnew/router/pns_line_placer.cpp| 11 +--
 pcbnew/router/pns_router.cpp |  6 --
 pcbnew/router/pns_router.h   | 10 --
 pcbnew/router/pns_shove.cpp  |  7 +++
 pcbnew/router/pns_sizes_settings.cpp |  4 +++-
 pcbnew/router/pns_tool_base.cpp  | 11 +++
 pcbnew/router/pns_tool_base.h|  3 +++
 pcbnew/router/router_tool.cpp| 15 +++
 pcbnew/tools/grid_helper.cpp | 37 
 pcbnew/tools/grid_helper.h   |  4 
 10 files changed, 89 insertions(+), 19 deletions(-)

diff --git a/pcbnew/router/pns_line_placer.cpp b/pcbnew/router/pns_line_placer.cpp
index bdc2970..5ff7977 100644
--- a/pcbnew/router/pns_line_placer.cpp
+++ b/pcbnew/router/pns_line_placer.cpp
@@ -952,6 +952,7 @@ void PNS_LINE_PLACER::removeLoops( PNS_NODE* aNode, PNS_LINE& aLatest )
 if ( aLatest.CLine().CPoint( 0 ) == aLatest.CLine().CPoint( -1 ) )
 return;
 
+std::set toErase;
 aNode->Add( , true );
 
 for( int s = 0; s < aLatest.LinkCount(); s++ )
@@ -979,13 +980,16 @@ void PNS_LINE_PLACER::removeLoops( PNS_NODE* aNode, PNS_LINE& aLatest )
 
 if( !( line.ContainsSegment( seg ) ) && line.SegmentCount() )
 {
-aNode->Remove(  );
+BOOST_FOREACH( PNS_SEGMENT *ss, *line.LinkedSegments() )
+toErase.insert(ss);
 removedCount++;
 }
 }
 
 TRACE( 0, "total segs removed: %d/%d\n", removedCount % total );
 }
+BOOST_FOREACH( PNS_SEGMENT *s, toErase )
+aNode->Remove (s);
 
 aNode->Remove(  );
 }
@@ -1034,17 +1038,12 @@ void PNS_LINE_PLACER::updateLeadingRatLine()
 void PNS_LINE_PLACER::SetOrthoMode( bool aOrthoMode )
 {
 m_orthoMode = aOrthoMode;
-
-if( !m_idle )
-Move( m_currentEnd, NULL );
 }
 
 bool PNS_LINE_PLACER::buildInitialLine( const VECTOR2I& aP, PNS_LINE& aHead )
 {
 SHAPE_LINE_CHAIN l;
 
-printf("H-net %d\n", aHead.Net());
-
 if( m_p_start == aP )
 {
 l.Clear();
diff --git a/pcbnew/router/pns_router.cpp b/pcbnew/router/pns_router.cpp
index 8526a64..fd7d911 100644
--- a/pcbnew/router/pns_router.cpp
+++ b/pcbnew/router/pns_router.cpp
@@ -35,6 +35,8 @@
 #include 
 #include 
 
+#include 
+
 #include "trace.h"
 #include "pns_node.h"
 #include "pns_line_placer.h"
@@ -572,8 +574,8 @@ const VECTOR2I PNS_ROUTER::SnapToItem( PNS_ITEM* aItem, VECTOR2I aP, bool& aSpli
 anchor = s.B;
 else
 {
-anchor = s.NearestPoint( aP );
-aSplitsSegment = true;
+anchor = m_gridHelper->AlignToSegment ( aP, s );
+aSplitsSegment = (anchor != s.A && anchor != s.B );
 }
 
 break;
diff --git a/pcbnew/router/pns_router.h b/pcbnew/router/pns_router.h
index 05be228..0541dec 100644
--- a/pcbnew/router/pns_router.h
+++ b/pcbnew/router/pns_router.h
@@ -40,6 +40,7 @@ class BOARD_ITEM;
 class D_PAD;
 class TRACK;
 class VIA;
+class GRID_HELPER;
 class PNS_NODE;
 class PNS_DIFF_PAIR_PLACER;
 class PNS_PLACEMENT_ALGO;
@@ -106,7 +107,6 @@ public:
 
 void StopRouting();
 
-
 int GetClearance( const PNS_ITEM* aA, const PNS_ITEM* aB ) const;
 
 PNS_NODE* 

Re: [Kicad-developers] Regression & performance testing

[Tomasz Wlostowski]

On 12.10.2015 19:47, Markus Hitter wrote:
> 
> As I'm shortly before providing my first commit I wonder what the
> testing procedures are to make sure a patch doesn't unintentionally
> break something else. Is there a recommended / required procedure?
> 
Hi Markus,

There's not much progress on regression tests side. Miguel was working
on a python-driven test suite.

> The other question is, what is the recommended procedure to roughly
> measure graphics performance? For example, Cairo canvas vs. software
> OpenGL canvas. Simply load larger and larger layouts until it feels slow?
> 
There's a simple timer measuring the frame render time. Compile Kicad in
debug mode and add -DPROFILE to build options.

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Found the source of Intel GPU suckitude in OpenGL

[Tomasz Wlostowski]

On 11.10.2015 14:03, Lorenzo Marcantonio wrote:
> CAN'T THEY DO A FSCKING WORKING GPU without having to hack the drivers
> to get them installed?!

Lorenzo, if you know better how to do a GPU, maybe you should apply for
a job at Intel and teach them?

T.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Found the source of Intel GPU suckitude in OpenGL

[Tomasz Wlostowski]

On 11.10.2015 14:21, Lorenzo Marcantonio wrote:
> On Sun, Oct 11, 2015 at 02:08:39PM +0200, Tomasz Wlostowski wrote:
> 
>> Lorenzo, if you know better how to do a GPU, maybe you should apply for
>> a job at Intel and teach them?
> 
> At least if your HW is 1.4 capable don't export the support for 2.0 and
> fake the rest in software...
> 
> YES I know that in OpenGL that's actually completely legal... a
> 'conforming' implementation could be even 100% software (like the Mesa
> baseline) and export the 4.0 API and work like a drunk snail and still
> nobody could complain about that.
> 

That's sad, but we can't do much about it except making a fast software
renderer or optimize the Cairo one...

It's on our list for after-the-stable-release, and we'd greatly
appreciate help here.

Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] No blueprint discussions?

[Tomasz Wlostowski]

On 09.10.2015 13:27, Markus Hitter wrote:
> Hello all,
> 
> I'm new to this list and there are apparently no searchable list
> archives, so I hope it's not too much to simply ask.
> 
> 
Hi Markus,

Usability is a major concern for us. Kicad has a lot UI quirks that made
it look and feel radically different from other tools and discouraged
new users from joining us.

We created an UI improvement blueprint page [1] and we encourage you to
contribute to this proposal.

> In search of best practices I currently read a lot of documentation and
> also visit forums. One pretty obvious thing is that the learning curve
> for editing is apparently high. Behaviour of the Cairo canvas differ
> substantially from the OpenGL canvas and neither of them is in alignment
> with human interface guidelines of the respective OS platform. This
> leads to confusion, even experienced users miss procedures as simple >
deleting a track:
>
> https://forum.kicad.info/t/kicad-opengl-is-painful-to-use/1262/27


The GL canvas is a work in progress and it's missing some features, and
some others are not polished up yet - that's why we are keeping the old
canvas for the moment.

Track deletion is of course supported, but it works more like in
mainstream software - select the item and press Delete. I think the main
complaint was that deletion doesn't work while the "Route" tool is
active - you need to exit the router tool by pressing Esc to
select/move/delete items. This behaviour is not our invention, we just
followed the practice of other big SW packages (MS Office,
Corel/Inkscape, Altium, Cadence). It can surely cause confusion of old
Kicad users - and we will probably enable the legacy behaviour as an
option, as soon as the stable release is out.


Best,
Tom

[1] http://www.ohwr.org/projects/cern-kicad/wiki/UI_improvements



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Push shove router documentation.

[Tomasz Wlostowski]

On 30.09.2015 15:18, Wayne Stambaugh wrote:
> There was a question
> https://answers.launchpad.net/kicad/+question/271926 posted and I was
> going to add the link to the diff pair routing documentation when I
> discovered that is it no where to be found in the Pcbnew manual.  I
> thought there was documentation written for the diff pair router.

Hi Wayne,

Mea maxima culpa. The documentation will be done before the stable.

Cheers,
Tom.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] FW: Export to ODB++

[Tomasz Wlostowski]

On 12.09.2015 18:04, Chris Pavlina wrote:
> Not GPL-compatible because the restriction would apply to anyone making
> a derivative of KiCad as well. The only way I can see to do this is a
> clean-room reverse engineering, which does not appear to be feasible.

Use plugins. The ODB++/IPC-2581 ones could be kept outside mainline
Kicad if we would ensure they can be easily installed by a non-programmer.

- my 5 cents,
Tom



> 
> On Sep 10, 2015 12:48 PM, "Mark Roszko"  > wrote:
> 
> Nope, you don't have to advertise for Mentor Graphics
> 
> Here are the terms:
> 
> 4. PROMOTION.
> 
> Participant agrees to promote the integration between the ODB++ Format
> and the Participant Products by: (i) joining the ODB++ Solutions
> Alliance as a “solutions development partnering” member, via the ODB++
> Website, including providing a quote about Participant’s ODB++ Format
> implementation for use in Mentor Graphics’ promotional materials and
> on the ODB++ Website; (ii) allowing Mentor Graphics to use
> Participant’s logo in Mentor Graphics promotional materials and on the
> ODB++ Website; (iii) including a brief factual statement on the ODB++
> Format implementation in Participant’s promotional materials and a
> link from Participant’s website to the ODB++ Website; (iv) making a
> visible acknowledgement in the Participant’s Products (user-interface
> and documentation) of the support received from Mentor Graphics under
> this Agreement for the implementation of the ODB++ Format; and (v)
> agreeing to the publication by Mentor Graphics of the existence of
> Participant’s membership in the ODB++ Solutions Alliance.
> 
> 
> 
> 
> I highly doubt Altium and Cadence (both large EDA developers) would be
> supporting ODB++ if they have to advertise their competitor. Its just
> really slapping the logo on the supported products page for ODB++ and
> some marketing FUD for ODB++ because they really want it to take off
> for some reason.
> http://www.odb-sa.com/partners/
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DXF export broken?

[Tomasz Wlostowski]

On 09.09.2015 15:58, Wayne Stambaugh wrote:
> This board is exposing all kinds of issues.  First vrml export, now the
> DXF plots are wrong.  I know I've plotted dxfs for similar shaped boards
> in the past.  I don't know if it's this board in particular or something
> has been changed in the dxf plotter.  Could someone with experience with
> the dxf plotter please take look at this?  I'm a bit busy to look at it
> myself.
> 

Hi Wayne,

I'm the one to blame: the bug was caused by a stupid typo during
de-boostization which went unnoticed since it affects only DXF export. I
also fixed handling polygons with holes in DXF. Patch attached.

Cheers,
Tom
>From ea5ec8534dc78519f043fc5b40c3316e1ffeb50e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= 
Date: Wed, 9 Sep 2015 16:32:14 +0200
Subject: [PATCH 2/2] PlotLayerOutlines: fixed typo causing incorrect DXF
 output, added support for holes

---
 pcbnew/plot_board_layers.cpp | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/pcbnew/plot_board_layers.cpp b/pcbnew/plot_board_layers.cpp
index 364d40f..b79280f 100644
--- a/pcbnew/plot_board_layers.cpp
+++ b/pcbnew/plot_board_layers.cpp
@@ -566,17 +566,21 @@ void PlotLayerOutlines( BOARD* aBoard, PLOTTER* aPlotter,
 // Now we have one or more basic polygons: plot each polygon
 for( int ii = 0; ii < outlines.OutlineCount(); ii++ )
 {
-cornerList.clear();
-const SHAPE_LINE_CHAIN& path = outlines.COutline( ii );
+for(int kk = 0; kk <= outlines.HoleCount (ii); kk++ )
+{
+cornerList.clear();
+const SHAPE_LINE_CHAIN& path = (kk == 0) ? outlines.COutline( ii ) : outlines.CHole( ii, kk - 1 );
+
+for( int jj = 0; jj < path.PointCount(); jj++ )
+cornerList.push_back( wxPoint( path.CPoint( jj ).x , path.CPoint( jj ).y ) );
 
-for( int jj = 0; jj < path.PointCount(); jj++ )
-cornerList.push_back( wxPoint( path.CPoint( jj ).x , path.CPoint( jj ).x ) );
 
-// Ensure the polygon is closed
-if( cornerList[0] != cornerList[cornerList.size() - 1] )
-cornerList.push_back( cornerList[0] );
+// Ensure the polygon is closed
+if( cornerList[0] != cornerList[cornerList.size() - 1] )
+cornerList.push_back( cornerList[0] );
 
-aPlotter->PlotPoly( cornerList, NO_FILL );
+aPlotter->PlotPoly( cornerList, NO_FILL );
+}
 }
 
 // Plot pad holes
-- 
1.9.1

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad annoyances and niggles

[Tomasz Wlostowski]

On 06.09.2015 05:59, timofonic timofonic wrote:
> I have some suggestions and ideas after stable release. Sorry if I
> explain them wrong, I hope not!
> 
> - Why KiCad depends on a practically dead project such as FreeRoute?
> It's taken down by Zuken and even adds Java as a dependency, that's a
> major annoyance.
It's sad that FreeRouting is the only open source autorouter offering
decent quality...

> * What about a similar plugin approach such as the defunct qautorouter?
> * C-PCB looks promising too, maybe this developer would like some
> support our contribute to KiCad in some way.
I don't understand why some people rely so much on autorouters. None of
professional PCB designers that I know (including myself) uses an
autorouter...

> 
> - What about remove *ALL* legacy code (in the UI stuff only?) and have
> GAL only? Then remove cruft, debug, add missing features, optimizing and
> provide some kind of faster software rendering.
We'll get there, one day.

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] UI and usability enhancement

[Tomasz Wlostowski]

On 31.08.2015 17:23, Mário Luzeiro wrote:
> Good work on that list!
> 
> I just give an quick overlook on that, I think one thing was not mentioned 
> was the consistency on the edition of parameters.
> (For example the way that you insert a value of some type (ex a diameter, or 
> a position) is different depending of the function/dialog.)
> One thing that maybe kicad could also implement is a "parameter table" 
> edition. I saw already some EDAs that implement it that way, also, it is easy 
> to first develop a table or tree and just enter manually the values.
> Something like this:
> http://fossies.org/linux/wxWidgets/docs/doxygen/images/appear-propertygrid-gtk.png

Hi,


@Attila: Great to have you here, I see our lists of annoyances in Kicad
are pretty much the same. I've never taken the effort to write them
down, though... Thanks for doing this painful job :)

If there's one point that I find missing: redo the menu structure. Each
function the program provides must be in the menu, in a logical
position. A newcomer should be able to discover all functions of the
program just by browsing through the menus. Unfortunately this is not
the case - take the component spread/auto-placement tool as an example.

@Mario: It's been for a long time on our to-do list [1], point 14
(Introspection & properties, inspector tool).

@both: don't forget that some of the improvements that look simple (
retaining nets for vias/traces, property editor or undo while drawing a
trace) require some substantial rework of PCBnew internals (e.g.
redesign of the net propagation algorithm or refactoring the BOARD class
to add properites/observers).

Cheers,
Tom

[1] http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages

> 
> It is not very "user (good looking) friendly" but for other advanced users 
> can be a faster way to edit the options. (Also, it should be easier to match 
> an options table and create a configuration table ui automatically )
> 
> My 2 cents.
> Mario Luzeiro
> 
> From: Kicad-developers 
> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
> Attila Kinali [att...@kinali.ch]
> Sent: 31 August 2015 16:15
> To: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] UI and usability enhancement
> 
> On Wed, 12 Aug 2015 00:09:06 +0200
> Attila Kinali  wrote:
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] proposed future changes for 3D model handling

[Tomasz Wlostowski]

On 28.08.2015 11:39, LordBlick wrote:
 In response to a message written on 28.08.2015, 08:28, from Cirilo
 Bernardo:
 especially if we initially use OpenCascade to implement it.
 I must protest against such tendencies to implement OpenCascade.
 That stuff has different Licence, and forces anyone, who wants to build
 from source to register!
 
Then do a bit of googling before you protest:

https://github.com/tpaviot/oce

Tom



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] proposed future changes for 3D model handling

[Tomasz Wlostowski]

On 28.08.2015 14:01, Mário Luzeiro wrote:

 I agree with that too :) Every time I need to build it takes a lot (special 
 in debug mode). Maybe something to do in the future roadmap..


Do you build the libc or the X server every time you build Kicad? Just
think of OCC as just every other system library... Plus, there are
pre-compiled versions.

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] No more boost::polygon in Kicad

[Tomasz Wlostowski]

On 23.08.2015 21:59, Mário Luzeiro wrote:
 Hello Tomasz,
 
 I made some additions to the shape_poly_set library. I appreciate if
 you can have a look in the additions and if you agree with that to
 commit it to trunk. There are no changes related with current used
 source in the trunk so should be no problem ( I am just using it in
 my branch at the moment)
Hi Mario,

Thanks from the patch. Wayne, could you commit it?
 
 I implemented the HoleCount function but I had a little difficult
 to understand it in the beginning so you may want give more attention
 in that one.

It's OK.

 
 I fix a little error in the Function booleanOp documentation header. 
 Also I was looking for the propose of the aFastMode ( JP added it
 related with 3d viewer? to make it faster ), I was thinking that (in
 my case) it is important the really mean of the result of the
 aFastMode (i.e: weak or strictly polygon) so maybe we should name
 it by the real propose?

Feel free to change that too and send a patch.

Cheers,
Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] No more boost::polygon in Kicad

[Tomasz Wlostowski]

On 21.08.2015 23:15, Mário Luzeiro wrote:
 Hi Tomasz, all,
 
 after remove boost, I also noted that you remove ExportTo functions.
 Are there any way (already implemented) that I can export to a 
 ClipperLib::Paths ?

Hi Mario,

SHAPE_POLY_SET internally uses ClipperLib::Paths. Please don't use this
structure directly in Kicad code, if there's any missing functionality,
extend SHAPE_POLY_SET instead. It will save us time in the future if
we'll decide to go for yet another polygon library (or use a bit of one
and a bit of another).

Tom


 
 Mario
 
 From: Kicad-developers 
 [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
 Tomasz Wlostowski [tomasz.wlostow...@cern.ch]
 Sent: 13 July 2015 23:46
 To: Kicad Developers
 Subject: [Kicad-developers] [PATCH] No more boost::polygon in Kicad
 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Stackup heights and length tuning PoC

[Tomasz Wlostowski]

On 20.08.2015 16:29, Jeppe Johansen wrote:
 Hi,
 
 I've been working on adding support for entering stackup information and
 using that info when length tuning traces.
 
 Some screenshots:
 http://j-software.dk/kicad/thickness.png
 http://j-software.dk/kicad/length.png
 
 Patch here(warning, back up any .kicad_pcb files before you save. The
 format is changed to include layer heights):
 http://j-software.dk/kicad/kicad_stackup.patch
 
 Getting it into the meander placer required a bit of hacking to process
 vias and find all segments connecting to it. That part is a bit ugly,
 but it works. Also the length calculation is duplicated for each tool
 variant. Unifying those in a single place would be great. For now my
 patch only modifies the single trace length tuner. 

Hi Jeppe,

Thanks for the patch.

I'm not sure if we should define separate layers for cores/prepregs,
though. How are they going to be stored in .kicad_pcb file? What if
there is more than one layer of dielectric between each two adjacent
layers? Maybe a new dialog for defining the complete stackup (including
dielectric factors, losses, etc) would be a better idea?

Regards,
Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Stitching vias

[Tomasz Wlostowski]

On 30.07.2015 10:45, Mikk Leini wrote:
 So the idea of implementing manual vias does not interfere with script.
 I uploaded a demo of what i have right now:
 https://youtu.be/c4uwaKJOkO4
 
 It doesn't need to go into main tree right now but it's so obvious
 feature missing from KiCad that it should be done one day soon.

I agree it's an important feature but it's not that simple to implement.
What happens to the nets of your vias (unless you've fixed it) after
reloading the netlist?

Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DLL export of PNS_TOOL_BASE

[Tomasz Wlostowski]

On 28.07.2015 02:47, Simon Richter wrote:
 Hi,
 
 the MSVC build complains:
 
 pcbnew\router\pns_tool_base.h(37) : warning C4275: non
 dll-interface class 'TOOL_INTERACTIVE' used as base for
 dll-interface class 'PNS_TOOL_BASE' 
 include\tool/tool_interactive.h(35) : see declaration of
 'TOOL_INTERACTIVE' pcbnew\router\pns_tool_base.h(36) : see
 declaration of 'PNS_TOOL_BASE'
 
 I can see the point here -- if the base class is not exported, any 
 functions not overridden in the derived class cannot be imported if
 the class is used through the DLL interface.
 
 Is the PNS router actually meant to be used via a DLL interface
 though, or can the DLL export for PNS_TOOL_BASE and derived classes
 be dropped?
 
 If it is, shouldn't the TOOL_INTERACTIVE and TOOL_BASE classes be 
 exported as well?

Hi Simon,

It's for my internal testing (I build PS as a separate DLL).

Tom
 
 Simon
 
 
 
 ___ Mailing list:
 https://launchpad.net/~kicad-developers Post to :
 kicad-developers@lists.launchpad.net Unsubscribe :
 https://launchpad.net/~kicad-developers More help   :
 https://help.launchpad.net/ListHelp
 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PCB reading Net list formace

[Tomasz Wlostowski]

On 24.07.2015 16:44, Lorenzo Marcantonio wrote:
 On Fri, 24 Jul 2015 16:42:04 +0200,
 Tomasz Wlostowski wrote:
 In a recent commit (the one for single-click update) I've fixed this
 problem - now the HTML panel is built in lazy mode. Patch attached.
 
 Probably that's the massive slowdown I've seen since the new 'coloured'
 log box was added... the gray lines are quite unreadable, too :P

They are intended to be less visible, as they contain some auxillary
messages. Maybe the color could darker, though...
 
 Is really necessary to use an html box instead of something like a
 listbox? Seems overkill for that application...

Lorenzo, I don't want to argue about that, since last time we discussed
something graphics- or UI- related, you were saying that OpenGL is an
overkill...

Nonetheless, I've fixed the slowdown, just forgot the patch was a part
of a larger patch set that has not been merged yet.

Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PCB reading Net list formace

[Tomasz Wlostowski]

On 24.07.2015 16:20, jp charras wrote:
 I'll have a look at this dialog.

In a recent commit (the one for single-click update) I've fixed this
problem - now the HTML panel is built in lazy mode. Patch attached.

Tom
From 7c021220fe1e4501befd645df35ab315a21878dd Mon Sep 17 00:00:00 2001
From: Tomasz Wlostowski tomasz.wlostow...@cern.ch
Date: Fri, 10 Jul 2015 13:47:46 +0200
Subject: [PATCH 1/5] lazy rendering mode for HTML reporter widget (improves
 speed for large reports)

---
 common/dialogs/wx_html_report_panel.cpp  | 32 ++--
 common/dialogs/wx_html_report_panel.h| 18 
 common/dialogs/wx_html_report_panel_base.cpp |  7 +++---
 common/dialogs/wx_html_report_panel_base.fbp |  4 ++--
 common/dialogs/wx_html_report_panel_base.h   |  1 +
 common/reporter.cpp  | 17 +++
 include/reporter.h   | 18 
 7 files changed, 89 insertions(+), 8 deletions(-)

diff --git a/common/dialogs/wx_html_report_panel.cpp b/common/dialogs/wx_html_report_panel.cpp
index 42d884f..3c7b4d1 100644
--- a/common/dialogs/wx_html_report_panel.cpp
+++ b/common/dialogs/wx_html_report_panel.cpp
@@ -32,7 +32,8 @@ WX_HTML_REPORT_PANEL::WX_HTML_REPORT_PANEL( wxWindow*  parent,
 WX_HTML_REPORT_PANEL_BASE( parent, id, pos, size, style ),
 m_reporter( this ),
 m_severities( -1 ),
-m_showAll( true )
+m_showAll( true ),
+m_lazyUpdate( false )
 {
 syncCheckboxes();
 m_htmlView-SetPage( addHeader(  ) );
@@ -57,7 +58,26 @@ void WX_HTML_REPORT_PANEL::Report( const wxString aText, REPORTER::SEVERITY aSe
 line.severity = aSeverity;
 
 m_report.push_back( line );
-m_htmlView-AppendToPage( generateHtml( line ) );
+
+m_html += generateHtml( line );
+
+if( !m_lazyUpdate )
+{
+m_htmlView-AppendToPage( generateHtml( line ) );
+scrollToBottom();
+}
+}
+
+
+void WX_HTML_REPORT_PANEL::SetLazyUpdate( bool aLazyUpdate )
+{
+m_lazyUpdate = aLazyUpdate;
+}
+
+
+void WX_HTML_REPORT_PANEL::Flush()
+{
+m_htmlView-SetPage( m_html );
 scrollToBottom();
 }
 
@@ -65,6 +85,7 @@ void WX_HTML_REPORT_PANEL::Report( const wxString aText, REPORTER::SEVERITY aSe
 void WX_HTML_REPORT_PANEL::scrollToBottom()
 {
 int x, y, xUnit, yUnit;
+
 m_htmlView-GetVirtualSize( x, y );
 m_htmlView-GetScrollPixelsPerUnit( xUnit, yUnit );
 m_htmlView-Scroll( 0, y / yUnit );
@@ -242,5 +263,12 @@ void WX_HTML_REPORT_PANEL::onBtnSaveToFile( wxCommandEvent event )
 
 void WX_HTML_REPORT_PANEL::Clear()
 {
+m_html.clear();
 m_report.clear();
 }
+
+
+void WX_HTML_REPORT_PANEL::SetLabel( const wxString aLabel )
+{
+m_box-GetStaticBox()-SetLabel( aLabel );
+}
diff --git a/common/dialogs/wx_html_report_panel.h b/common/dialogs/wx_html_report_panel.h
index 953a49b..d0216c6 100644
--- a/common/dialogs/wx_html_report_panel.h
+++ b/common/dialogs/wx_html_report_panel.h
@@ -55,6 +55,20 @@ public:
 /// clears the report panel
 void Clear();
 
+/// sets the frame label
+void SetLabel( const wxString aLabel );
+
+void SetLazyUpdate( bool aLazyUpdate );
+
+void Flush();
+
+void SetVisibleSeverities( int aSeverities )
+{
+m_showAll = false;
+m_severities = aSeverities;
+syncCheckboxes();
+}
+
 private:
 struct REPORT_LINE
 {
@@ -91,6 +105,10 @@ private:
 
 /// show all messages flag (overrides m_severities)
 bool m_showAll;
+
+wxString m_html;
+
+bool m_lazyUpdate;
 };
 
 #endif //__WX_HTML_REPORT_PANEL_H__
diff --git a/common/dialogs/wx_html_report_panel_base.cpp b/common/dialogs/wx_html_report_panel_base.cpp
index fc47a8d..80be22c 100644
--- a/common/dialogs/wx_html_report_panel_base.cpp
+++ b/common/dialogs/wx_html_report_panel_base.cpp
@@ -11,8 +11,7 @@
 
 WX_HTML_REPORT_PANEL_BASE::WX_HTML_REPORT_PANEL_BASE( wxWindow* parent, wxWindowID id, const wxPoint pos, const wxSize size, long style ) : wxPanel( parent, id, pos, size, style )
 {
-	wxStaticBoxSizer* sbSizer3;
-	sbSizer3 = new wxStaticBoxSizer( new wxStaticBox( this, wxID_ANY, wxT(Messages:) ), wxVERTICAL );
+	m_box = new wxStaticBoxSizer( new wxStaticBox( this, wxID_ANY, wxT(Messages:) ), wxVERTICAL );
 	
 	wxFlexGridSizer* fgSizer4;
 	fgSizer4 = new wxFlexGridSizer( 2, 1, 0, 0 );
@@ -67,10 +66,10 @@ WX_HTML_REPORT_PANEL_BASE::WX_HTML_REPORT_PANEL_BASE( wxWindow* parent, wxWindow
 	fgSizer4-Add( fgSizer3, 1, wxEXPAND, 5 );
 	
 	
-	sbSizer3-Add( fgSizer4, 1, wxEXPAND|wxALL, 5 );
+	m_box-Add( fgSizer4, 1, wxEXPAND|wxALL, 5 );
 	
 	
-	this-SetSizer( sbSizer3 );
+	this-SetSizer( m_box );
 	this-Layout();
 	
 	// Connect Events
diff --git a/common/dialogs/wx_html_report_panel_base.fbp b/common/dialogs/wx_html_report_panel_base.fbp
index 0dc2fc1..f707d9d 100644
--- a/common/dialogs/wx_html_report_panel_base.fbp
+++ b/common/dialogs/wx_html_report_panel_base.fbp
@@ -82,9 +82,9 @@
 property name=idwxID_ANY/property