[Kicad-developers] [PATCH 1/6] Add missing include

[Simon Richter]

---
 common/geometry/shape_poly_set.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/common/geometry/shape_poly_set.cpp b/common/geometry/shape_poly_set.cpp
index c11cf047c..7c0d2f38f 100644
--- a/common/geometry/shape_poly_set.cpp
+++ b/common/geometry/shape_poly_set.cpp
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
___
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 6/6] Pass -DBOOST_TEST_DYN_LINK to all parts of test

[Simon Richter]

---
 eeschema/qa/CMakeLists.txt  | 3 +++
 eeschema/qa/test_module.cpp | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/eeschema/qa/CMakeLists.txt b/eeschema/qa/CMakeLists.txt
index f11329f35..fb99b8613 100644
--- a/eeschema/qa/CMakeLists.txt
+++ b/eeschema/qa/CMakeLists.txt
@@ -34,6 +34,9 @@ add_executable( qa_eagle_plugin
 test_basic.cpp
 )
 
+target_compile_definitions( qa_eagle_plugin
+PRIVATE -DBOOST_TEST_DYN_LINK )
+
 add_dependencies( qa_eagle_plugin common eeschema_kiface )
 
 target_link_libraries( qa_eagle_plugin
diff --git a/eeschema/qa/test_module.cpp b/eeschema/qa/test_module.cpp
index 69417ab09..50b04dd59 100644
--- a/eeschema/qa/test_module.cpp
+++ b/eeschema/qa/test_module.cpp
@@ -26,7 +26,6 @@
  * Main file for the schematic eagle plugin tests to be compiled
  */
 
-#define BOOST_TEST_DYN_LINK
 #define BOOST_TEST_MODULE "Schematic Eagle plugin"
 
 #include 
___
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 3/6] Avoid initialization from non-constexpr

[Simon Richter]

In-class initializers for "static const" class members must be constexpr,
however std::string is only "static const" itself and cannot be used
without compiler extensions.
---
 include/utf8.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/utf8.h b/include/utf8.h
index 26c467f0d..e78e8fd09 100644
--- a/include/utf8.h
+++ b/include/utf8.h
@@ -145,7 +145,9 @@ public:
 return (UTF8&) *this;
 }
 
-static const std::string::size_type npos = std::string::npos;
+// std::string::npos is not constexpr, so we can't use it in an
+// initializer.
+static constexpr std::string::size_type npos = -1;
 
 UTF8& operator=( const wxString& o );
 
___
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 5/6] Link pcb_test_window with /SUBSYSTEM:WINDOWS

[Simon Richter]

This is required for wx apps.
---
 qa/pcb_test_window/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qa/pcb_test_window/CMakeLists.txt b/qa/pcb_test_window/CMakeLists.txt
index c312ce62d..f3a83bc47 100644
--- a/qa/pcb_test_window/CMakeLists.txt
+++ b/qa/pcb_test_window/CMakeLists.txt
@@ -33,7 +33,7 @@ endif()
 
 add_dependencies( pnsrouter pcbcommon pcad2kicadpcb ${GITHUB_PLUGIN_LIBRARIES} )
 
-add_executable(test_window
+add_executable(test_window WIN32
   test.cpp
   ../common/pcb_test_frame.cpp
   ../common/mocks.cpp
___
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 4/6] Avoid C-style array member init (illegal in C++)

[Simon Richter]

This is not part of the C++ language, and only supported in some compilers.
---
 common/common_plotDXF_functions.cpp | 26 ++
 eeschema/sch_line.cpp   | 21 ++---
 include/class_plotter.h |  1 -
 3 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/common/common_plotDXF_functions.cpp b/common/common_plotDXF_functions.cpp
index d66631539..8807591a2 100644
--- a/common/common_plotDXF_functions.cpp
+++ b/common/common_plotDXF_functions.cpp
@@ -94,18 +94,20 @@ static const struct
 { "YELLOW4",2 }
 };
 
-/**
- * Line types in the boilerplate DXF header.  The
- * element indices correspond to the eeschema line
- * types.
- */
-static const char *dxf_lines[] =
+
+static const char* getDXFLineType( PlotDashType aType )
 {
-[ PLOTDASHTYPE_SOLID ]   = "CONTINUOUS",
-[ PLOTDASHTYPE_DASH ]= "DASHED",
-[ PLOTDASHTYPE_DOT ] = "DOTTED",
-[ PLOTDASHTYPE_DASHDOT ] = "DASHDOT"
-};
+switch( aType )
+{
+case PLOTDASHTYPE_SOLID:return "CONTINUOUS";
+case PLOTDASHTYPE_DASH: return "DASHED";
+case PLOTDASHTYPE_DOT:  return "DOTTED";
+case PLOTDASHTYPE_DASHDOT:  return "DASHDOT";
+}
+
+wxFAIL_MSG( "Unhandled PlotDashType" );
+return "CONTINUOUS";
+}
 
 
 // A helper function to create a color name acceptable in DXF files
@@ -565,7 +567,7 @@ void DXF_PLOTTER::PenTo( const wxPoint& pos, char plume )
 wxASSERT( m_currentLineType >= 0 && m_currentLineType < 4 );
 // DXF LINE
 wxString cname = getDXFColorName( m_currentColor );
-const char *lname = dxf_lines[ m_currentLineType ];
+const char *lname = getDXFLineType( (PlotDashType) m_currentLineType );
 fprintf( outputFile, "0\nLINE\n8\n%s\n6\n%s\n10\n%g\n20\n%g\n11\n%g\n21\n%g\n",
  TO_UTF8( cname ), lname,
  pen_lastpos_dev.x, pen_lastpos_dev.y, pos_dev.x, pos_dev.y );
diff --git a/eeschema/sch_line.cpp b/eeschema/sch_line.cpp
index bd1deef88..61e5128ed 100644
--- a/eeschema/sch_line.cpp
+++ b/eeschema/sch_line.cpp
@@ -42,13 +42,20 @@
 
 #include 
 
-const enum wxPenStyle SCH_LINE::PenStyle[] =
+
+static wxPenStyle getwxPenStyle( PlotDashType aType )
 {
-[PLOTDASHTYPE_SOLID] = wxPENSTYLE_SOLID,
-[PLOTDASHTYPE_DASH] = wxPENSTYLE_SHORT_DASH,
-[PLOTDASHTYPE_DOT] = wxPENSTYLE_DOT,
-[PLOTDASHTYPE_DASHDOT] = wxPENSTYLE_DOT_DASH
-};
+switch( aType )
+{
+case PLOTDASHTYPE_SOLID:return wxPENSTYLE_SOLID;
+case PLOTDASHTYPE_DASH: return wxPENSTYLE_SHORT_DASH;
+case PLOTDASHTYPE_DOT:  return wxPENSTYLE_DOT;
+case PLOTDASHTYPE_DASHDOT:  return wxPENSTYLE_DOT_DASH;
+}
+
+wxFAIL_MSG( "Unhandled PlotDashType" );
+return wxPENSTYLE_SOLID;
+}
 
 
 SCH_LINE::SCH_LINE( const wxPoint& pos, int layer ) :
@@ -321,7 +328,7 @@ void SCH_LINE::Draw( EDA_DRAW_PANEL* panel, wxDC* DC, const wxPoint& offset,
 end += offset;
 
 GRLine( panel->GetClipBox(), DC, start.x, start.y, end.x, end.y, width, color,
-PenStyle[ GetLineStyle() ] );
+getwxPenStyle( (PlotDashType) GetLineStyle() ) );
 
 if( m_startIsDangling )
 DrawDanglingSymbol( panel, DC, start, color );
diff --git a/include/class_plotter.h b/include/class_plotter.h
index e84db08aa..e86fd4fec 100644
--- a/include/class_plotter.h
+++ b/include/class_plotter.h
@@ -85,7 +85,6 @@ enum PlotDashType {
 PLOTDASHTYPE_DASH,
 PLOTDASHTYPE_DOT,
 PLOTDASHTYPE_DASHDOT,
-PLOTDASHTYPE_COUNT,
 };
 
 /**
___
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 0/6] A few compatibility fixes

[Simon Richter]

Hi,

these are a few things that cause build errors on MSVC, where gcc accepts
invalid code. Most of them are obvious.

The pcb_test_window executable needs to be linked with /SUBSYSTEM:WINDOWS
on Windows because it is a GUI app, which uses different startup code than
a console application.

The Boost.Test issue is a double definition of several symbols because some
objects expect that they need to bring their own definition, while others
link the shared library instead. Either is fine, but mixing is not allowed
(but ELF linking silently overrides symbols from shared libraries).

   Simon

Simon Richter (6):
  Add missing include
  Avoid nonstandard variable length array
  Avoid initialization from non-constexpr
  Avoid C-style array member init (illegal in C++)
  Link pcb_test_window with /SUBSYSTEM:WINDOWS
  Pass -DBOOST_TEST_DYN_LINK to all parts of test

 common/common_plotDXF_functions.cpp| 26 --
 common/geometry/shape_poly_set.cpp |  5 +++--
 eeschema/qa/CMakeLists.txt |  3 +++
 eeschema/qa/test_module.cpp|  1 -
 eeschema/sch_line.cpp  | 21 +++--
 include/class_plotter.h|  1 -
 include/utf8.h |  4 +++-
 qa/pcb_test_window/CMakeLists.txt  |  2 +-
 .../test_polygon_triangulation.cpp |  6 ++---
 9 files changed, 41 insertions(+), 28 deletions(-)

-- 
2.11.0

___
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 2/6] Avoid nonstandard variable length array

[Simon Richter]

---
 common/geometry/shape_poly_set.cpp  | 4 ++--
 qa/polygon_triangulation/test_polygon_triangulation.cpp | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/common/geometry/shape_poly_set.cpp b/common/geometry/shape_poly_set.cpp
index 7c0d2f38f..ff2ad8742 100644
--- a/common/geometry/shape_poly_set.cpp
+++ b/common/geometry/shape_poly_set.cpp
@@ -942,7 +942,7 @@ void SHAPE_POLY_SET::unfractureSingle( SHAPE_POLY_SET::POLYGON& aPoly )
 auto lc = aPoly[0];
 lc.Simplify();
 
-EDGE_LIST_ENTRY edgeList[ lc.SegmentCount() ];
+auto edgeList = std::make_unique( lc.SegmentCount() );
 
 for( int i = 0; i < lc.SegmentCount(); i++ )
 {
@@ -1004,7 +1004,7 @@ void SHAPE_POLY_SET::unfractureSingle( SHAPE_POLY_SET::POLYGON& aPoly )
 queue.insert( [i] );
 }
 
-EDGE_LIST_ENTRY* edgeBuf[ lc.SegmentCount() ];
+auto edgeBuf = std::make_unique( lc.SegmentCount() );
 
 int n = 0;
 int outline = -1;
diff --git a/qa/polygon_triangulation/test_polygon_triangulation.cpp b/qa/polygon_triangulation/test_polygon_triangulation.cpp
index c23af207d..432a323a1 100644
--- a/qa/polygon_triangulation/test_polygon_triangulation.cpp
+++ b/qa/polygon_triangulation/test_polygon_triangulation.cpp
@@ -33,7 +33,7 @@
 #include 
 
 #include 
-
+#include 
 
 
 void unfracture( SHAPE_POLY_SET::POLYGON* aPoly, SHAPE_POLY_SET::POLYGON* aResult )
@@ -88,7 +88,7 @@ void unfracture( SHAPE_POLY_SET::POLYGON* aPoly, SHAPE_POLY_SET::POLYGON* aResul
 auto lc = (*aPoly)[0];
 lc.Simplify();
 
-EDGE_LIST_ENTRY edgeList[ lc.SegmentCount() ];
+auto edgeList = std::make_unique( lc.SegmentCount() );
 
 for(int i = 0; i < lc.SegmentCount(); i++)
 {
@@ -149,7 +149,7 @@ void unfracture( SHAPE_POLY_SET::POLYGON* aPoly, SHAPE_POLY_SET::POLYGON* aResul
 //printf("Skip %d\n", i);
 }
 
-EDGE_LIST_ENTRY* edgeBuf[ lc.SegmentCount() ];
+auto edgeBuf = std::make_unique( lc.SegmentCount() );
 
 int n = 0;
 int outline = -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

[Kicad-developers] Official gestures support in wxWidgets master

[Bernhard Stegmaier]

Hi all,

I just saw that official support for gestures has arrived in wxWidgets master.
I don’t yet know if this is in any way compatible with the private patches 
(pinch-to-zoom for macOS) and touchpad panning that we currently use.

I just wanted to let you know that I will start working on adapting to that 
changes.
If anybody else starts to work on that, please let me know that we don’t do it 
twice.

Since wxWidgets master isn’t officially supported, I guess no one will be 
working on it anyway… :)


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

Re: [Kicad-developers] [PATCH] Component table view initial columns sizing

[Bernhard Stegmaier]

Wayne,No problem… never used it before, but always good to learn something new… :)Attached.Regards,Bernhard

0001-Fix-initial-sizing-of-Fields-table-columns-in-compon.patch
Description: Binary data
On 5. Dec 2017, at 20:47, Wayne Stambaugh  wrote:Bernhard,Please resend the patch using `git format-patch`.  This makes it a loteasier to apply patches and push to master if they are ready to go.Thanks,WayneOn 12/5/2017 2:16 PM, Bernhard Stegmaier wrote:Wayne,I created it just by directing a “git show” to a file.I could apply it to master using “patch -p1 < xxx.patch”.Of course, I can also try to use “git formal-patch” and resend…Regards,BernhardOn 5. Dec 2017, at 19:45, Wayne Stambaugh > wrote:Bernhard,I just tried to merge this patch using `git am` and I'm getting thiserror:fatal: empty ident name (for <>) not allowedIt looks like you didn't create this patch using `git format-patch`and/or you do not have your user name and/or user email set in your gitconfig.Cheers,WayneTOn 12/5/2017 8:02 AM, Bernhard Stegmaier wrote:Hi,attached patch fixes initial sizing of “Fields” table columns ofcomponent table view.Only tested on macOS.Please check also on Linux/Windows as I removed some IMHOunneeded/duplicate Update() (and other) calls.Before:After:Regards,Bernhard___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore 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] Component table view initial columns sizing

[Wayne Stambaugh]

Bernhard,

Please resend the patch using `git format-patch`.  This makes it a lot
easier to apply patches and push to master if they are ready to go.

Thanks,

Wayne

On 12/5/2017 2:16 PM, Bernhard Stegmaier wrote:
> Wayne,
> 
> I created it just by directing a “git show” to a file.
> I could apply it to master using “patch -p1 < xxx.patch”.
> Of course, I can also try to use “git formal-patch” and resend…
> 
> 
> Regards,
> Bernhard
> 
>> On 5. Dec 2017, at 19:45, Wayne Stambaugh > > wrote:
>>
>> Bernhard,
>>
>> I just tried to merge this patch using `git am` and I'm getting this
>> error:
>>
>> fatal: empty ident name (for <>) not allowed
>>
>> It looks like you didn't create this patch using `git format-patch`
>> and/or you do not have your user name and/or user email set in your git
>> config.
>>
>> Cheers,
>>
>> Wayne
>>
>> T
>> On 12/5/2017 8:02 AM, Bernhard Stegmaier wrote:
>>> Hi,
>>>
>>> attached patch fixes initial sizing of “Fields” table columns of
>>> component table view.
>>>
>>> Only tested on macOS.
>>> Please check also on Linux/Windows as I removed some IMHO
>>> unneeded/duplicate Update() (and other) calls.
>>>
>>> Before:
>>>
>>>
>>>
>>>
>>>
>>> After:
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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] [PATCH] Component table view initial columns sizing

[Bernhard Stegmaier]

Wayne,

I created it just by directing a “git show” to a file.
I could apply it to master using “patch -p1 < xxx.patch”.
Of course, I can also try to use “git formal-patch” and resend…


Regards,
Bernhard

> On 5. Dec 2017, at 19:45, Wayne Stambaugh  wrote:
> 
> Bernhard,
> 
> I just tried to merge this patch using `git am` and I'm getting this error:
> 
> fatal: empty ident name (for <>) not allowed
> 
> It looks like you didn't create this patch using `git format-patch`
> and/or you do not have your user name and/or user email set in your git
> config.
> 
> Cheers,
> 
> Wayne
> 
> T
> On 12/5/2017 8:02 AM, Bernhard Stegmaier wrote:
>> Hi,
>> 
>> attached patch fixes initial sizing of “Fields” table columns of component 
>> table view.
>> 
>> Only tested on macOS.
>> Please check also on Linux/Windows as I removed some IMHO unneeded/duplicate 
>> Update() (and other) calls.
>> 
>> Before:
>> 
>> 
>> 
>> 
>> 
>> After:
>> 
>> 
>> 
>> 
>> 
>> 
>> 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] [PATCH] Component table view initial columns sizing

[Wayne Stambaugh]

Bernhard,

I just tried to merge this patch using `git am` and I'm getting this error:

fatal: empty ident name (for <>) not allowed

It looks like you didn't create this patch using `git format-patch`
and/or you do not have your user name and/or user email set in your git
config.

Cheers,

Wayne

T
On 12/5/2017 8:02 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> attached patch fixes initial sizing of “Fields” table columns of component 
> table view.
> 
> Only tested on macOS.
> Please check also on Linux/Windows as I removed some IMHO unneeded/duplicate 
> Update() (and other) calls.
> 
> Before:
> 
> 
> 
> 
> 
> After:
> 
> 
> 
> 
> 
> 
> 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

Re: [Kicad-developers] [PATCH] Fix artifacts on touchpad scroll (fixes lp:1735669)

[Wayne Stambaugh]

I tested this patch on my antiquated laptop and it seems fine on Windows
7 pro but I'm not sure the touchpad behavior is correct so it would be
nice if someone with a modern windows laptop could test this before I
commit it.

Cheers,

Wayne

On 12/4/2017 7:45 PM, Seth Hillbrand wrote:
> ​This fixes artifacts remaining on the screen when touchpad scrolling is
> enabled.
> https://bugs.launchpad.net/kicad/+bug/1735669
> 
> The attached patch is tested on MacOS and Linux.  Could someone with a
> Windows laptop check that the performance of touchpad scrolling is not
> affected?
> 
> Thanks!
> Seth
> 
> 
> ___
> 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] Component table view initial columns sizing

[Bernhard Stegmaier]

Hi Simon,

> On 5. Dec 2017, at 14:37, Simon Richter  wrote:
> 
> Unrelated to your patch: does it make sense to perhaps share some of the
> grouping code between this and the component pin table?

First: I didn’t write that piece of code and I only had a very quick look into 
the table model code.
Just from GUI it looks similar (swap “pin" with “device"), so this could make 
sense.

However, I don’t know if it is worth the effort.
At the end, tailoring some small generic piece of code for the common model to 
both different tables/data might be more effort.
Maybe it would be a nice software design exercise… :)


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

Re: [Kicad-developers] Simulator towards 5.0

[Simon Richter]

Hi,

On 05.12.2017 17:30, Maciej Sumiński wrote:

> When you build a program, do you always go through its build manual or
> do you start with 'cmake .. && make'? I think there is no point
> enforcing an optional dependency. Another good solution would be to
> autodetect libngspice and enable the simulator if it is available.

With my packaging hat on: please don't. It is really annoying to find
out that a build dependency changed when users complain about entire
features going missing.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Simulator towards 5.0

[Kristoffer Ödmark]

This patch changes the default build values in cmake, and adds an 
instruction on how to disable the the spice simulator in the cmake error.


 -Kristoffer

On 12/05/2017 05:30 PM, Maciej Sumiński wrote:

When you build a program, do you always go through its build manual or
do you start with 'cmake .. && make'? I think there is no point
enforcing an optional dependency. Another good solution would be to
autodetect libngspice and enable the simulator if it is available.

On 12/05/2017 05:18 PM, Nick Østergaard wrote:

Isn't it good enough to mention it under the KiCad Build Configuration
Options in the devdocs as it is already?


2017-12-05 16:56 GMT+01:00 Maciej Sumiński :


If everyone agrees that Spice simulator should be enabled by default,
then please display a note saying it is optional and might be disabled
for cases when it is not found by CMake.

Regards,
Orson

On 12/05/2017 03:47 PM, Nick Østergaard wrote:

If they are not available for some reason the packager for that platform
can disable the feature until he figures out how to support the feature.

I don't really see the rationale in having supported features be enabled
explicitly.

2017-12-05 15:33 GMT+01:00 Wayne Stambaugh :


Can we guarantee that these build dependencies are available on all
platforms?  I'm primarily think of BSD devs.  For the windows, macos,
and linux devs there are no issues.

On 12/5/2017 9:28 AM, Nick Østergaard wrote:

I would personally also like to see these options enabled by default.

It

makes it easier for a packager to be convinced what options to

enable...

:)


2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
>:

 I checked the default package in Ubuntu ppa through a friend.

Indeed

 all of this is enabled.

 Here I attach a small patch that changes the default compile-flags
 to the ones in the released packages. Its a small fix and it doesnt
 add or remove anything really, just a changes how a default build
 for a novice will look, maybe it will reduce some initial confusion
 for someone.

 - Kristoffer

 On 12/04/2017 10:19 PM, Nick Østergaard wrote:



 Den 4. dec. 2017 18.50  skrev "kristoffer
 Ödmark" 
 >>:



 On 2017-12-04 15:22, Tomasz Wlostowski wrote:

 Kristoffer,

 You're very welcome to specify how you'd like to have

the

 Spice-related
 fields organized - but remember it's not only the
 integrated ngspice
 simulator that relies on them. People have been
 exporting PSpice
 netlists from Kicad for a while and AFAIR netlist

export

 depends on
 these particular fields.

 Okay, My suggestions:

 1. Enable the spice simulator by default and start shipping
 it with
 windows nightlies. This way we will find much more bugs.
 Because I
 doubt everyone is running with the simulator on even on
 nightlies.
 Same goes for the OCE and step stuff. This I see as a must
 to get a
 smoother v5 transition for most users, even those moving

from v4

 stable to v5 stable without ever trying nightlies.


 Everything should be enabled for the windows nightlies. It has
 been when the OCE stuff and ngspice stuff was merged. If it not
 it is a bug.


 2. Parse the "value" field and reference in the simulator

to

 get the
 basic primitives. like Resistor and Capactiors, inductors
 etc, based
 on the first Letter in the Reference. We already have
 name-dependent
 functions for the differential-pair so having this here,

and


 3. Move the Spice_Netlist_Enabled field to a new right-side
 toggle
 menu to select between "Spice and PCB, Spice Only, PCB
 only", so one
 can specify if the item should be added to both the PCB and

the

 Spice netlist, or only one of them, by default I guess both
 should
 be enabled.

 4. When the Spice_Model field is selected, the button "Edit
 Spice
 Model" should be shown under there, instead of always on

the

 left
 side. Just to be more like the other fields.

 5. Add context-menu entries and toolbar buttons for the
 simulator
 interface.

 This would make the simulator seem like its a part of kicad
 and not
 only a strange addon that is just hackishly attached to
 kicad with
   

Re: [Kicad-developers] Simulator towards 5.0

[Nick Østergaard]

But it would also fail to build if you did not install wx.

Den 5. dec. 2017 5.21 PM skrev "Kevin Cozens" :

On 2017-12-05 09:05 AM, Kristoffer Ödmark wrote:

> Here I attach a small patch that changes the default compile-flags to the
> ones in the released packages.
>

Enabling SPICE support by default will break my build unless I turn it off.

Seeing a recent message about SPICE support I wanted to have a look at the
feature. I found out I needed to install ngspice. I then found out that the
copy of ngspice available in the standard repos for Linux Mint doesn't
include the lib file needed to compile and link KiCad with SPICE support.

-- 
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick


___
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] Python: time_t needs mapping; tentative patch

[Henner Zeller]

Alright, here is a reworked patch that includes the ideas discussed here

  - Where we used to use time_t in the functions that deal with
timestamps, this is now done with a new typedef timestamp_t that makes
sure the c++ side and swigged Python side agree on the type.
  - this typedef is now in common.h, close to the declaration of
GetNewTimeStamp()
  - The type of this type is 'long' as this makes sure that it is at
least 32 bits. Trying to use something like int32_t did not work well
with swig that seems to be more comfortable by default with the
standard types (but some local Swig expert might know how to do this)

Cheers,
  Henner.


timestamp-type.patch.gz
Description: GNU Zip compressed data
___
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] Simulator towards 5.0

[Kristoffer Ödmark]

I always try to build the package that everyone else is running, and no 
I do not consult the build manual until i have to. That is also why I 
have only tested the simulator that will now be inside v5.


Since we are in feature freeze, and the simulator will be part of kicad. 
I think that the standard build should reflect the packaged kicad.


I do agree that a message that it can be disabled is ok though.

-Kristoffer

On 12/05/2017 05:30 PM, Maciej Sumiński wrote:

When you build a program, do you always go through its build manual or
do you start with 'cmake .. && make'? I think there is no point
enforcing an optional dependency. Another good solution would be to
autodetect libngspice and enable the simulator if it is available.

On 12/05/2017 05:18 PM, Nick Østergaard wrote:

Isn't it good enough to mention it under the KiCad Build Configuration
Options in the devdocs as it is already?


2017-12-05 16:56 GMT+01:00 Maciej Sumiński :


If everyone agrees that Spice simulator should be enabled by default,
then please display a note saying it is optional and might be disabled
for cases when it is not found by CMake.

Regards,
Orson

On 12/05/2017 03:47 PM, Nick Østergaard wrote:

If they are not available for some reason the packager for that platform
can disable the feature until he figures out how to support the feature.

I don't really see the rationale in having supported features be enabled
explicitly.

2017-12-05 15:33 GMT+01:00 Wayne Stambaugh :


Can we guarantee that these build dependencies are available on all
platforms?  I'm primarily think of BSD devs.  For the windows, macos,
and linux devs there are no issues.

On 12/5/2017 9:28 AM, Nick Østergaard wrote:

I would personally also like to see these options enabled by default.

It

makes it easier for a packager to be convinced what options to

enable...

:)


2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
>:

 I checked the default package in Ubuntu ppa through a friend.

Indeed

 all of this is enabled.

 Here I attach a small patch that changes the default compile-flags
 to the ones in the released packages. Its a small fix and it doesnt
 add or remove anything really, just a changes how a default build
 for a novice will look, maybe it will reduce some initial confusion
 for someone.

 - Kristoffer

 On 12/04/2017 10:19 PM, Nick Østergaard wrote:



 Den 4. dec. 2017 18.50  skrev "kristoffer
 Ödmark" 
 >>:



 On 2017-12-04 15:22, Tomasz Wlostowski wrote:

 Kristoffer,

 You're very welcome to specify how you'd like to have

the

 Spice-related
 fields organized - but remember it's not only the
 integrated ngspice
 simulator that relies on them. People have been
 exporting PSpice
 netlists from Kicad for a while and AFAIR netlist

export

 depends on
 these particular fields.

 Okay, My suggestions:

 1. Enable the spice simulator by default and start shipping
 it with
 windows nightlies. This way we will find much more bugs.
 Because I
 doubt everyone is running with the simulator on even on
 nightlies.
 Same goes for the OCE and step stuff. This I see as a must
 to get a
 smoother v5 transition for most users, even those moving

from v4

 stable to v5 stable without ever trying nightlies.


 Everything should be enabled for the windows nightlies. It has
 been when the OCE stuff and ngspice stuff was merged. If it not
 it is a bug.


 2. Parse the "value" field and reference in the simulator

to

 get the
 basic primitives. like Resistor and Capactiors, inductors
 etc, based
 on the first Letter in the Reference. We already have
 name-dependent
 functions for the differential-pair so having this here,

and


 3. Move the Spice_Netlist_Enabled field to a new right-side
 toggle
 menu to select between "Spice and PCB, Spice Only, PCB
 only", so one
 can specify if the item should be added to both the PCB and

the

 Spice netlist, or only one of them, by default I guess both
 should
 be enabled.

 4. When the Spice_Model field is selected, the button "Edit
 Spice
 Model" should be shown under there, instead of always on

the

 left
 side. Just to be more like the other fields.

 5. Add context-menu 

Re: [Kicad-developers] Simulator towards 5.0

[Maciej Sumiński]

When you build a program, do you always go through its build manual or
do you start with 'cmake .. && make'? I think there is no point
enforcing an optional dependency. Another good solution would be to
autodetect libngspice and enable the simulator if it is available.

On 12/05/2017 05:18 PM, Nick Østergaard wrote:
> Isn't it good enough to mention it under the KiCad Build Configuration
> Options in the devdocs as it is already?
> 
> 
> 2017-12-05 16:56 GMT+01:00 Maciej Sumiński :
> 
>> If everyone agrees that Spice simulator should be enabled by default,
>> then please display a note saying it is optional and might be disabled
>> for cases when it is not found by CMake.
>>
>> Regards,
>> Orson
>>
>> On 12/05/2017 03:47 PM, Nick Østergaard wrote:
>>> If they are not available for some reason the packager for that platform
>>> can disable the feature until he figures out how to support the feature.
>>>
>>> I don't really see the rationale in having supported features be enabled
>>> explicitly.
>>>
>>> 2017-12-05 15:33 GMT+01:00 Wayne Stambaugh :
>>>
 Can we guarantee that these build dependencies are available on all
 platforms?  I'm primarily think of BSD devs.  For the windows, macos,
 and linux devs there are no issues.

 On 12/5/2017 9:28 AM, Nick Østergaard wrote:
> I would personally also like to see these options enabled by default.
>> It
> makes it easier for a packager to be convinced what options to
>> enable...
 :)
>
> 2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
> >:
>
> I checked the default package in Ubuntu ppa through a friend.
>> Indeed
> all of this is enabled.
>
> Here I attach a small patch that changes the default compile-flags
> to the ones in the released packages. Its a small fix and it doesnt
> add or remove anything really, just a changes how a default build
> for a novice will look, maybe it will reduce some initial confusion
> for someone.
>
> - Kristoffer
>
> On 12/04/2017 10:19 PM, Nick Østergaard wrote:
>
>
>
> Den 4. dec. 2017 18.50  skrev "kristoffer
> Ödmark"  
>  >>:
>
>
>
> On 2017-12-04 15:22, Tomasz Wlostowski wrote:
>
> Kristoffer,
>
> You're very welcome to specify how you'd like to have
>> the
> Spice-related
> fields organized - but remember it's not only the
> integrated ngspice
> simulator that relies on them. People have been
> exporting PSpice
> netlists from Kicad for a while and AFAIR netlist
>> export
> depends on
> these particular fields.
>
> Okay, My suggestions:
>
> 1. Enable the spice simulator by default and start shipping
> it with
> windows nightlies. This way we will find much more bugs.
> Because I
> doubt everyone is running with the simulator on even on
> nightlies.
> Same goes for the OCE and step stuff. This I see as a must
> to get a
> smoother v5 transition for most users, even those moving
 from v4
> stable to v5 stable without ever trying nightlies.
>
>
> Everything should be enabled for the windows nightlies. It has
> been when the OCE stuff and ngspice stuff was merged. If it not
> it is a bug.
>
>
> 2. Parse the "value" field and reference in the simulator
>> to
> get the
> basic primitives. like Resistor and Capactiors, inductors
> etc, based
> on the first Letter in the Reference. We already have
> name-dependent
> functions for the differential-pair so having this here,
>> and
>
> 3. Move the Spice_Netlist_Enabled field to a new right-side
> toggle
> menu to select between "Spice and PCB, Spice Only, PCB
> only", so one
> can specify if the item should be added to both the PCB and
 the
> Spice netlist, or only one of them, by default I guess both
> should
> be enabled.
>
> 4. When the Spice_Model field is selected, the button "Edit
> Spice
> Model" should be shown under there, instead of always on
>> the
> left
> side. Just to be more like 

Re: [Kicad-developers] Fwd: Questions on BOARD_COMMIT

[Maciej Sumiński]

Hi Miles,

On 12/04/2017 09:23 AM, miles mccoo wrote:
>> Is there a document the explains Board commit? An email thread about it
> 
>>> perhaps?
>>
>> There are some comments in include/commit.h. Perhaps it should be extended.
>>
>>
> Yes, I think so. A small description of how this class is intended to be
> used. First do this as setup, then make some changes, if doing this kind of
> change, call these methods, if you're making these other kinds of changes,
> do this other stuff. Finally call push. After that you should see x,y, and
> z in the GUI...

Sounds reasonable, I will expand the description.

> I see that board_commit constructor takes either a frame or a pcb_tool.
> it's not obvious to me what a pcb_tool does.

I think the best way to follow KiCad's code is to have the Doxygen
documentation [1], it helps a lot understanding  the code.

>>> It seems to me that the broad purpose of BOARD_COMMIT (I'll call it BC)
>> is
>>> to handle the details for undo. When changing a wire,module,pad,... you
>>> tell BC what you're doing. Undo then magically happens. Another side
>> effect
>>> is that the canvas is redrawn when needed.
>>
>> Think about the BOARD_COMMIT as of the observer pattern. You make a
>> change to an observed object and create a commit to notify the observers
>> about the change and its kind.
>>
>>
> The observers are all hardcoded in the push method, yes? I'm used to
> subscription based.

True, probably it would be better to have the subscription based type.
It has been done quickly to resolve the GAL vs legacy synchronization.
There are cases when the observers need to run in a particular order
(e.g. you want to delete the object as the last step when it is removed,
otherwise other observers will get a stale pointer).

>>> 1) There will be cases when a utility/command developer doesn't care
>> about
>>> undo. They just want to make their changes and if the result is not
>>> desired, just revert. This would be particularly true for automated,
>> final
>>> processing. One that comes to mind is a teardrop generator
>>> > pt-adds-and-deletes-teardrops-to-a-pcb-v0-3-3/3388>
>>
>> Have a look at COMMIT::Revert() method, it does exactly what you are
>> asking for. You can gather all changes using COMMIT and then either
>> Push() or Revert(), depending on whether you want them to be applied or
>> not.
>>
>>
> 
> Looking around, I found the GAL->DisplayBoard method. The Revert and Push
> methods mentioned above still require me to know/remember what changed.
> 
> 
> 
>>> *Will BC update still work if you don't tell it about any changes?* I ask
>>> because BC was given as a better way to redraw the canvas
>>
>> No, BC handles only the changes it is notified about. If you want, you
>> can fully refresh state of all observers that would have been notified
>> by BC, but I think it is not very efficient.
>>
> 
> 
> perhaps something the python abstraction layer could do it track changes
> and pass them along to the BC.

Good idea, but I do not have any simple idea how to achieve this.

>>> 2) I see there are a bunch of Add, Remove,... functions that a script
>> would
>>> need to call. *Why don't the relevant objects just make these calls when
>>> they are changed? *Then the code for undo is handled once and developers
>>> can forget about it.
>>
>> Because you need to update view, connectivity and undo buffer. We would
>> like to keep actions decoupled from the model and it is a way of doing so.
>>
> 
> Perhaps allow these observers to subscribe to changes? When a module, pad,
> track,... changes, it can call a Add/Remove/... method of whatever
> observers registered themselves.
> 
> I guess I'm just repeating my same comment. It just seems like doing this
> code in (# classes)*(# methods/class) = 10*10 places = a couple hundred
> maybe. After that, you never worry about it again.
> 
> Compare that to #commands * # places each command makes a change to the
> model. Yet another thing to think about when developing an edit command.

Sure, but think about a few things:
- Do you want to trigger all observers on every intermediate step when
dragging an item? I assume 'no', then how do you handle this?
- How do you handle actions that affect more than one item, but should
be grouped to one undo entry?
- If you want to cancel an action, does it mean you need to explicitly
create a copy of the modified item before the modification?

> 
> 
> 
> 
>>> 3) I see there are pre and post modify methods. (ie Remove and Removed)
>> *What's
>>> the difference?* Why use one over the other?
>>
>> Remove() does the removal action for you, Removed() only notifies the
>> observers that an item has been removed and you clean up the object.
>>
>>
> I guess I gave a bad example.  There's Modify and Modified. To
> search/replace your answer:
> 
> Modify() does the modify action for you. Modified() only notifiies the
> observers that an item has been modified and you 

[Kicad-developers] Jenkins build is back to normal : linux-kicad-full-gcc-head #2590

[Miguel Angel Ajo]

See 



___
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] Simulator towards 5.0

[Kevin Cozens]

On 2017-12-05 09:05 AM, Kristoffer Ödmark wrote:
Here I attach a small patch that changes the default compile-flags to the 
ones in the released packages.


Enabling SPICE support by default will break my build unless I turn it off.

Seeing a recent message about SPICE support I wanted to have a look at the 
feature. I found out I needed to install ngspice. I then found out that the 
copy of ngspice available in the standard repos for Linux Mint doesn't 
include the lib file needed to compile and link KiCad with SPICE support.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick

___
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] Simulator towards 5.0

[Nick Østergaard]

Isn't it good enough to mention it under the KiCad Build Configuration
Options in the devdocs as it is already?


2017-12-05 16:56 GMT+01:00 Maciej Sumiński :

> If everyone agrees that Spice simulator should be enabled by default,
> then please display a note saying it is optional and might be disabled
> for cases when it is not found by CMake.
>
> Regards,
> Orson
>
> On 12/05/2017 03:47 PM, Nick Østergaard wrote:
> > If they are not available for some reason the packager for that platform
> > can disable the feature until he figures out how to support the feature.
> >
> > I don't really see the rationale in having supported features be enabled
> > explicitly.
> >
> > 2017-12-05 15:33 GMT+01:00 Wayne Stambaugh :
> >
> >> Can we guarantee that these build dependencies are available on all
> >> platforms?  I'm primarily think of BSD devs.  For the windows, macos,
> >> and linux devs there are no issues.
> >>
> >> On 12/5/2017 9:28 AM, Nick Østergaard wrote:
> >>> I would personally also like to see these options enabled by default.
> It
> >>> makes it easier for a packager to be convinced what options to
> enable...
> >> :)
> >>>
> >>> 2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
> >>> >:
> >>>
> >>> I checked the default package in Ubuntu ppa through a friend.
> Indeed
> >>> all of this is enabled.
> >>>
> >>> Here I attach a small patch that changes the default compile-flags
> >>> to the ones in the released packages. Its a small fix and it doesnt
> >>> add or remove anything really, just a changes how a default build
> >>> for a novice will look, maybe it will reduce some initial confusion
> >>> for someone.
> >>>
> >>> - Kristoffer
> >>>
> >>> On 12/04/2017 10:19 PM, Nick Østergaard wrote:
> >>>
> >>>
> >>>
> >>> Den 4. dec. 2017 18.50  skrev "kristoffer
> >>> Ödmark"  >>> 
> >>>  >>> >>:
> >>>
> >>>
> >>>
> >>> On 2017-12-04 15:22, Tomasz Wlostowski wrote:
> >>>
> >>> Kristoffer,
> >>>
> >>> You're very welcome to specify how you'd like to have
> the
> >>> Spice-related
> >>> fields organized - but remember it's not only the
> >>> integrated ngspice
> >>> simulator that relies on them. People have been
> >>> exporting PSpice
> >>> netlists from Kicad for a while and AFAIR netlist
> export
> >>> depends on
> >>> these particular fields.
> >>>
> >>> Okay, My suggestions:
> >>>
> >>> 1. Enable the spice simulator by default and start shipping
> >>> it with
> >>> windows nightlies. This way we will find much more bugs.
> >>> Because I
> >>> doubt everyone is running with the simulator on even on
> >>> nightlies.
> >>> Same goes for the OCE and step stuff. This I see as a must
> >>> to get a
> >>> smoother v5 transition for most users, even those moving
> >> from v4
> >>> stable to v5 stable without ever trying nightlies.
> >>>
> >>>
> >>> Everything should be enabled for the windows nightlies. It has
> >>> been when the OCE stuff and ngspice stuff was merged. If it not
> >>> it is a bug.
> >>>
> >>>
> >>> 2. Parse the "value" field and reference in the simulator
> to
> >>> get the
> >>> basic primitives. like Resistor and Capactiors, inductors
> >>> etc, based
> >>> on the first Letter in the Reference. We already have
> >>> name-dependent
> >>> functions for the differential-pair so having this here,
> and
> >>>
> >>> 3. Move the Spice_Netlist_Enabled field to a new right-side
> >>> toggle
> >>> menu to select between "Spice and PCB, Spice Only, PCB
> >>> only", so one
> >>> can specify if the item should be added to both the PCB and
> >> the
> >>> Spice netlist, or only one of them, by default I guess both
> >>> should
> >>> be enabled.
> >>>
> >>> 4. When the Spice_Model field is selected, the button "Edit
> >>> Spice
> >>> Model" should be shown under there, instead of always on
> the
> >>> left
> >>> side. Just to be more like the other fields.
> >>>
> >>> 5. Add context-menu entries and toolbar buttons for the
> >>> simulator
> >>> interface.
> >>>
> >>> This would make the simulator seem like its a part of kicad
> >>> and not
> >>> only a strange addon that is just hackishly attached to
> >>> 

[Kicad-developers] Jenkins build is back to normal : kicad-qa #3120

[Miguel Angel Ajo]

See 


___
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] Simulator towards 5.0

[Maciej Sumiński]

If everyone agrees that Spice simulator should be enabled by default,
then please display a note saying it is optional and might be disabled
for cases when it is not found by CMake.

Regards,
Orson

On 12/05/2017 03:47 PM, Nick Østergaard wrote:
> If they are not available for some reason the packager for that platform
> can disable the feature until he figures out how to support the feature.
> 
> I don't really see the rationale in having supported features be enabled
> explicitly.
> 
> 2017-12-05 15:33 GMT+01:00 Wayne Stambaugh :
> 
>> Can we guarantee that these build dependencies are available on all
>> platforms?  I'm primarily think of BSD devs.  For the windows, macos,
>> and linux devs there are no issues.
>>
>> On 12/5/2017 9:28 AM, Nick Østergaard wrote:
>>> I would personally also like to see these options enabled by default. It
>>> makes it easier for a packager to be convinced what options to enable...
>> :)
>>>
>>> 2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
>>> >:
>>>
>>> I checked the default package in Ubuntu ppa through a friend. Indeed
>>> all of this is enabled.
>>>
>>> Here I attach a small patch that changes the default compile-flags
>>> to the ones in the released packages. Its a small fix and it doesnt
>>> add or remove anything really, just a changes how a default build
>>> for a novice will look, maybe it will reduce some initial confusion
>>> for someone.
>>>
>>> - Kristoffer
>>>
>>> On 12/04/2017 10:19 PM, Nick Østergaard wrote:
>>>
>>>
>>>
>>> Den 4. dec. 2017 18.50  skrev "kristoffer
>>> Ödmark" >> 
>>> >> >>:
>>>
>>>
>>>
>>> On 2017-12-04 15:22, Tomasz Wlostowski wrote:
>>>
>>> Kristoffer,
>>>
>>> You're very welcome to specify how you'd like to have the
>>> Spice-related
>>> fields organized - but remember it's not only the
>>> integrated ngspice
>>> simulator that relies on them. People have been
>>> exporting PSpice
>>> netlists from Kicad for a while and AFAIR netlist export
>>> depends on
>>> these particular fields.
>>>
>>> Okay, My suggestions:
>>>
>>> 1. Enable the spice simulator by default and start shipping
>>> it with
>>> windows nightlies. This way we will find much more bugs.
>>> Because I
>>> doubt everyone is running with the simulator on even on
>>> nightlies.
>>> Same goes for the OCE and step stuff. This I see as a must
>>> to get a
>>> smoother v5 transition for most users, even those moving
>> from v4
>>> stable to v5 stable without ever trying nightlies.
>>>
>>>
>>> Everything should be enabled for the windows nightlies. It has
>>> been when the OCE stuff and ngspice stuff was merged. If it not
>>> it is a bug.
>>>
>>>
>>> 2. Parse the "value" field and reference in the simulator to
>>> get the
>>> basic primitives. like Resistor and Capactiors, inductors
>>> etc, based
>>> on the first Letter in the Reference. We already have
>>> name-dependent
>>> functions for the differential-pair so having this here, and
>>>
>>> 3. Move the Spice_Netlist_Enabled field to a new right-side
>>> toggle
>>> menu to select between "Spice and PCB, Spice Only, PCB
>>> only", so one
>>> can specify if the item should be added to both the PCB and
>> the
>>> Spice netlist, or only one of them, by default I guess both
>>> should
>>> be enabled.
>>>
>>> 4. When the Spice_Model field is selected, the button "Edit
>>> Spice
>>> Model" should be shown under there, instead of always on the
>>> left
>>> side. Just to be more like the other fields.
>>>
>>> 5. Add context-menu entries and toolbar buttons for the
>>> simulator
>>> interface.
>>>
>>> This would make the simulator seem like its a part of kicad
>>> and not
>>> only a strange addon that is just hackishly attached to
>>> kicad with
>>> duct-tape. Dont get me wrong, Its an awesome feature, and
>>> works well
>>> it just looks like an outsider when using it currently.
>>>
>>>
>>>
>>> As for the polishing up before the V5, there's several
>>> tasks to do:
>>> - update the pspice.lib library (it doesn't follow the
>>> KLC) and make
>>> sure all Spice 

Re: [Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #2589

[Henner Zeller]

b

On 5 December 2017 at 07:25, Miguel Angel Ajo  wrote:
> See 
> 
>
> Changes:
>
> [tomasz.wlostowski] pcbnew: Optimized zone filling algorithm.
>
> [tomasz.wlostowski] SHAPE_FILE_IO: default constructor outputs to stdout
>
> [tomasz.wlostowski] SHAPE_POLY_SET: fix empty triangulation bug
>
> [tomasz.wlostowski] pcbnew: made TransformShapeWithClearanceToPolygon virtual
>
> [tomasz.wlostowski] Sample tool for generating board geometyr as polygons
>
> [tomasz.wlostowski] PCB_TOOL: added convenience methods for accessing current 
> SELECTION
>
> [tomasz.wlostowski] POINT_EDITOR: migrate to ZONE_FILLER class
>
> [tomasz.wlostowski] pcbnew: factored out ZONE_FILLER to a separate file
>
> [tomasz.wlostowski] pcbnew: removed unused files
>
> [tomasz.wlostowski] pcbnew: Optimized zone filling algorithm: code cleanup
>
> [tomasz.wlostowski] pcbnew: made zone filling algorithm thread-safe. - moved 
> zone filling
>
> [tomasz.wlostowski] WX_PROGRESS_REPORTER: fix assert warnings
>
> [tomasz.wlostowski] WX_PROGRESS_REPORTER: fixed windows build error
>
> [tomasz.wlostowski] pcbnew: now PROGRESS_REPORTER should work in 
> multi-threaded context
>
> [tomasz.wlostowski] poly2tri: fixed some warnings
>
> --
> [...truncated 152.74 KB...]
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_lib_table_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_lib_table.cpp.o
> [ 88%] Built target eeschema_kiface
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_plugin_options_base.cpp.o
> Scanning dependencies of target eeschema
> [ 88%] Building CXX object 
> eeschema/CMakeFiles/eeschema.dir/__/common/single_top.cpp.o
> [ 88%] Building CXX object 
> eeschema/CMakeFiles/eeschema.dir/__/common/pgm_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_plugin_options.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_freeroute_exchange.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_freeroute_exchange_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gencad_export_options.cpp.o
> [ 88%] Linking CXX executable eeschema
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gendrill.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gendrill_base.cpp.o
> [ 88%] Built target eeschema
> Scanning dependencies of target qa_eagle_plugin
> [ 88%] Building CXX object 
> eeschema/qa/CMakeFiles/qa_eagle_plugin.dir/test_module.cpp.o
> [ 88%] Building CXX object 
> eeschema/qa/CMakeFiles/qa_eagle_plugin.dir/test_basic.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gen_module_position_file_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_general_options.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_general_options_BoardEditor_base.cpp.o
> [ 88%] Linking CXX executable qa_eagle_plugin
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_get_footprint_by_name_base.cpp.o
> [ 88%] Built target qa_eagle_plugin
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_edit_tracks_and_vias.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_edit_tracks_and_vias_base.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_modules_fields_edition.cpp.o
> [ 88%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_modules_fields_edition_base.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_pads_edition_base.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_pads_edition.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_items_options.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_items_options_base.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_item_properties.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_item_properties_base.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_item_properties_for_Modedit.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_deletion.cpp.o
> [ 89%] Building CXX object 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_deletion_base.cpp.o
> [ 89%] Building CXX 

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #2589

[Miguel Angel Ajo]

See 


Changes:

[tomasz.wlostowski] pcbnew: Optimized zone filling algorithm.

[tomasz.wlostowski] SHAPE_FILE_IO: default constructor outputs to stdout

[tomasz.wlostowski] SHAPE_POLY_SET: fix empty triangulation bug

[tomasz.wlostowski] pcbnew: made TransformShapeWithClearanceToPolygon virtual

[tomasz.wlostowski] Sample tool for generating board geometyr as polygons

[tomasz.wlostowski] PCB_TOOL: added convenience methods for accessing current 
SELECTION

[tomasz.wlostowski] POINT_EDITOR: migrate to ZONE_FILLER class

[tomasz.wlostowski] pcbnew: factored out ZONE_FILLER to a separate file

[tomasz.wlostowski] pcbnew: removed unused files

[tomasz.wlostowski] pcbnew: Optimized zone filling algorithm: code cleanup

[tomasz.wlostowski] pcbnew: made zone filling algorithm thread-safe. - moved 
zone filling

[tomasz.wlostowski] WX_PROGRESS_REPORTER: fix assert warnings

[tomasz.wlostowski] WX_PROGRESS_REPORTER: fixed windows build error

[tomasz.wlostowski] pcbnew: now PROGRESS_REPORTER should work in multi-threaded 
context

[tomasz.wlostowski] poly2tri: fixed some warnings

--
[...truncated 152.74 KB...]
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_lib_table_base.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_lib_table.cpp.o
[ 88%] Built target eeschema_kiface
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_plugin_options_base.cpp.o
Scanning dependencies of target eeschema
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema.dir/__/common/single_top.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema.dir/__/common/pgm_base.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_fp_plugin_options.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_freeroute_exchange.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_freeroute_exchange_base.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gencad_export_options.cpp.o
[ 88%] Linking CXX executable eeschema
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gendrill.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gendrill_base.cpp.o
[ 88%] Built target eeschema
Scanning dependencies of target qa_eagle_plugin
[ 88%] Building CXX object 
eeschema/qa/CMakeFiles/qa_eagle_plugin.dir/test_module.cpp.o
[ 88%] Building CXX object 
eeschema/qa/CMakeFiles/qa_eagle_plugin.dir/test_basic.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_gen_module_position_file_base.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_general_options.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_general_options_BoardEditor_base.cpp.o
[ 88%] Linking CXX executable qa_eagle_plugin
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_get_footprint_by_name_base.cpp.o
[ 88%] Built target qa_eagle_plugin
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_edit_tracks_and_vias.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_edit_tracks_and_vias_base.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_modules_fields_edition.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_modules_fields_edition_base.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_pads_edition_base.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_pads_edition.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_items_options.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_items_options_base.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_item_properties.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_item_properties_base.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_graphic_item_properties_for_Modedit.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_deletion.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_global_deletion_base.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_keepout_area_properties.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_keepout_area_properties_base.cpp.o
[ 89%] Building CXX object 

Re: [Kicad-developers] Zone filling & display speed improvements

[Henner Zeller]

On 5 December 2017 at 06:02, Tomasz Wlostowski
 wrote:
> On 05/12/17 08:55, jp charras wrote:
>> Le 05/12/2017 à 01:41, Tomasz Wlostowski a écrit :
>>> Hi guys,
>>>
>>> Now it should work fine - the filling algorithm was not thread safe and
>>> apparently wxProgressDialog can't be invoked from non-main thread.
>>>
>>> Check out the updated branch.
>>>
>>> Thanks!
>>> Tom
>>>
>>
>> Hi Tom,
>>
>> It works fine for me.
>> And on my 4 cores computer, the speedup is really impressive!
>>
>> Thanks.
>>
>
> Hi guys,
>
> Thanks for testing, I just merged it to the master.

There is still the left-over method RemoveInsulatedCopperIslands()
declaration that is otherwise never defined or used; so this needs to
be done:


--- a/pcbnew/class_zone.h
+++ b/pcbnew/class_zone.h
@@ -151,13 +151,6 @@ public:

int GetClearance( BOARD_CONNECTED_ITEM* aItem = NULL ) const override;

-/**
- * Function RemoveInsulatedCopperIslands
- * Remove insulated copper islands found in m_FilledPolysList.
- * @param aPcb = the board to analyze
- */
-void RemoveInsulatedCopperIslands( BOARD* aPcb );
-
/**
 * Function IsOnCopperLayer
 * @return true if this zone is on a copper layer, false if on a
technical layer


(This will prevent the scripting from compiling as Swig is generating
stub-code from the header but then complains while linking that it
does not exist).

-h

>
> 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] Signal integrity simulation within Kicad

[Jon Evans]

Hi Andreas,

For (1), I will defer to others who know more about this, I seem to
remember a conversation about this a while ago on the mailing list, with
the conclusion being that it is indeed hard to be notified when BOARD
changes, and fixing this could be a bit of work.

For (2), the PCB_BASE_FRAME methods are for the legacy canvas, so I
wouldn't worry about implementing your feature there if I were you, since
it will eventually be removed.
The RATSNEST_VIEWITEM is what is used on the GAL (OpenGL/Cairo) canvases.

Regarding the layer, you could use LAYER_GP_OVERLAY for prototyping, but
you are right that (at the moment) you can't add layers at runtime.
If you think that all of the simulation outputs can be drawn with a single
graphics layer, I think it is perfectly reasonable for you to expand the
enum with another layer definition.
You could use this new layer for your triangle mesh drawing, and then use
LAYER_GP_OVERLAY if you wanted to add any annotations to the graphics
perhaps? (meaning: measurements, etc, as is done with the RULER_ITEM)

-Jon

On Tue, Dec 5, 2017 at 9:42 AM, Andreas Buhr  wrote:

> Dear Kicad developers,
>
> I am browsing the Kicad source code to get an idea how to integrate a
> simulation tool.
>
> I'd like the following:
>
> 1. The plugin should be informed whenever something changes. It would be
> great to get a bounding box of the change.
> 2. The plugin should be able to draw on the canvas. I'd like to register
> a new layer (for example to show the triangle mesh). The user should
> then be able to enable/disable this layer.
>
> These two requirements are in some sense similar to the requirements of
> "ratsnest", so I followed "ratsnest" through the code.
>
> Concerning (1):
> I got the impression that it is not easy to be informed about all
> changes in a BOARD. Is this correct?
>
> Concerning (2):
> And I got the impression that there is not one way to draw to the
> canvas. I found two drawing methods for ratsnest, one in PCB_BASE_FRAME,
> the other in RATSNEST_VIEWITEM::ViewDraw. Is it necessary to implement
> two drawing methods for each feature?
>
> And it seems that the layers are organized in an enum (GAL_LAYER_ID), so
> adding a layer at runtime seems impossible without larger infrastructure
> changes. Is this correct?
>
> What would you propose? How can a plugin be informed about all changes
> to the board? And how could a plugin draw on the canvas?
>
> thanks a lot in advance,
> Cheers,
> Andreas
>
>
> On 11/30/2017 12:18 AM, Wayne Stambaugh wrote:
> > Hi Andreas,
> >
> > Per our previous conversation, if you want to write your solver in C++,
> > then I would prefer that you do it as part of a solver plugin rather
> > than a command event handler in Pcbnew.  I image there would be other
> > uses for a solver plugin object such as a thermal mapping solver which
> > has been proposed in the past.  The other option would be to use the
> > Python action object and write the entire solver in Python rather than
> > C++.  That may make your life a bit easier.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 11/29/2017 01:09 PM, Andreas Buhr wrote:
> >> Dear Kicad developers,
> >>
> >> I'm new to Kicad development. Maybe you could give me some starting
> tips?
> >>
> >> I am a 5th year PhD student at the university of Münster in Germany,
> >> website:
> >> https://www.uni-muenster.de/AMM/en/ohlberger/team/andreas_buhr.shtml
> >>
> >> I am doing mathematical research targeted at developing solvers for 3D
> >> Maxwell's equations in highly complex structures, such as PCBs. While
> >> being in an early stage, the goal is to develop a signal integrity
> >> solver which does a full-wave simulation of the electromagnetic fields
> >> and calculates S-parameters within a very short time.
> >>
> >> I would love to develop and test my algorithms within KiCad.
> >>
> >> The input which my solver needs would be an array of polygons,
> >> representing the copper-filled areas on each layer.
> >> I then want to create a 2D triangle mesh and based on that a 3D prism
> >> mesh for finite element analysis.
> >>
> >> What would you recommend? How to I get polygons, representing the copper
> >> filled areas of each layer?
> >> I do have some experience developing C++.
> >>
> >> thanks a lot in advance,
> >> best regards,
> >>
> >> Andreas
> >>
> >>
> >>
> >> ___
> >> 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] Simulator towards 5.0

[Kristoffer Ödmark]

I dont see why they should not be able to disable these options in that 
case, I dont think we should adapt our builds for the majority to suit 
the needs of the minority.


- Kristoffer

On 12/05/2017 03:33 PM, Wayne Stambaugh wrote:

Can we guarantee that these build dependencies are available on all
platforms?  I'm primarily think of BSD devs.  For the windows, macos,
and linux devs there are no issues.

On 12/5/2017 9:28 AM, Nick Østergaard wrote:

I would personally also like to see these options enabled by default. It
makes it easier for a packager to be convinced what options to enable... :)

2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
>:

 I checked the default package in Ubuntu ppa through a friend. Indeed
 all of this is enabled.

 Here I attach a small patch that changes the default compile-flags
 to the ones in the released packages. Its a small fix and it doesnt
 add or remove anything really, just a changes how a default build
 for a novice will look, maybe it will reduce some initial confusion
 for someone.

 - Kristoffer

 On 12/04/2017 10:19 PM, Nick Østergaard wrote:



 Den 4. dec. 2017 18.50  skrev "kristoffer
 Ödmark" 
 >>:



     On 2017-12-04 15:22, Tomasz Wlostowski wrote:

         Kristoffer,

         You're very welcome to specify how you'd like to have the
         Spice-related
         fields organized - but remember it's not only the
 integrated ngspice
         simulator that relies on them. People have been
 exporting PSpice
         netlists from Kicad for a while and AFAIR netlist export
 depends on
         these particular fields.

     Okay, My suggestions:

     1. Enable the spice simulator by default and start shipping
 it with
     windows nightlies. This way we will find much more bugs.
 Because I
     doubt everyone is running with the simulator on even on
 nightlies.
     Same goes for the OCE and step stuff. This I see as a must
 to get a
     smoother v5 transition for most users, even those moving from v4
     stable to v5 stable without ever trying nightlies.


 Everything should be enabled for the windows nightlies. It has
 been when the OCE stuff and ngspice stuff was merged. If it not
 it is a bug.


     2. Parse the "value" field and reference in the simulator to
 get the
     basic primitives. like Resistor and Capactiors, inductors
 etc, based
     on the first Letter in the Reference. We already have
 name-dependent
     functions for the differential-pair so having this here, and

     3. Move the Spice_Netlist_Enabled field to a new right-side
 toggle
     menu to select between "Spice and PCB, Spice Only, PCB
 only", so one
     can specify if the item should be added to both the PCB and the
     Spice netlist, or only one of them, by default I guess both
 should
     be enabled.

     4. When the Spice_Model field is selected, the button "Edit
 Spice
     Model" should be shown under there, instead of always on the
 left
     side. Just to be more like the other fields.

     5. Add context-menu entries and toolbar buttons for the
 simulator
     interface.

     This would make the simulator seem like its a part of kicad
 and not
     only a strange addon that is just hackishly attached to
 kicad with
     duct-tape. Dont get me wrong, Its an awesome feature, and
 works well
     it just looks like an outsider when using it currently.



         As for the polishing up before the V5, there's several
 tasks to do:
         - update the pspice.lib library (it doesn't follow the
 KLC) and make
         sure all Spice devices are in there.
         - fix quirks in the plot component (wxMathPlot).
         - document and make a few example designs (I can help
 with this
         point).

         Cheers,
         Tom



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

Re: [Kicad-developers] Simulator towards 5.0

[Nick Østergaard]

If they are not available for some reason the packager for that platform
can disable the feature until he figures out how to support the feature.

I don't really see the rationale in having supported features be enabled
explicitly.

2017-12-05 15:33 GMT+01:00 Wayne Stambaugh :

> Can we guarantee that these build dependencies are available on all
> platforms?  I'm primarily think of BSD devs.  For the windows, macos,
> and linux devs there are no issues.
>
> On 12/5/2017 9:28 AM, Nick Østergaard wrote:
> > I would personally also like to see these options enabled by default. It
> > makes it easier for a packager to be convinced what options to enable...
> :)
> >
> > 2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
> > >:
> >
> > I checked the default package in Ubuntu ppa through a friend. Indeed
> > all of this is enabled.
> >
> > Here I attach a small patch that changes the default compile-flags
> > to the ones in the released packages. Its a small fix and it doesnt
> > add or remove anything really, just a changes how a default build
> > for a novice will look, maybe it will reduce some initial confusion
> > for someone.
> >
> > - Kristoffer
> >
> > On 12/04/2017 10:19 PM, Nick Østergaard wrote:
> >
> >
> >
> > Den 4. dec. 2017 18.50  skrev "kristoffer
> > Ödmark"  > 
> >  > >>:
> >
> >
> >
> > On 2017-12-04 15:22, Tomasz Wlostowski wrote:
> >
> > Kristoffer,
> >
> > You're very welcome to specify how you'd like to have the
> > Spice-related
> > fields organized - but remember it's not only the
> > integrated ngspice
> > simulator that relies on them. People have been
> > exporting PSpice
> > netlists from Kicad for a while and AFAIR netlist export
> > depends on
> > these particular fields.
> >
> > Okay, My suggestions:
> >
> > 1. Enable the spice simulator by default and start shipping
> > it with
> > windows nightlies. This way we will find much more bugs.
> > Because I
> > doubt everyone is running with the simulator on even on
> > nightlies.
> > Same goes for the OCE and step stuff. This I see as a must
> > to get a
> > smoother v5 transition for most users, even those moving
> from v4
> > stable to v5 stable without ever trying nightlies.
> >
> >
> > Everything should be enabled for the windows nightlies. It has
> > been when the OCE stuff and ngspice stuff was merged. If it not
> > it is a bug.
> >
> >
> > 2. Parse the "value" field and reference in the simulator to
> > get the
> > basic primitives. like Resistor and Capactiors, inductors
> > etc, based
> > on the first Letter in the Reference. We already have
> > name-dependent
> > functions for the differential-pair so having this here, and
> >
> > 3. Move the Spice_Netlist_Enabled field to a new right-side
> > toggle
> > menu to select between "Spice and PCB, Spice Only, PCB
> > only", so one
> > can specify if the item should be added to both the PCB and
> the
> > Spice netlist, or only one of them, by default I guess both
> > should
> > be enabled.
> >
> > 4. When the Spice_Model field is selected, the button "Edit
> > Spice
> > Model" should be shown under there, instead of always on the
> > left
> > side. Just to be more like the other fields.
> >
> > 5. Add context-menu entries and toolbar buttons for the
> > simulator
> > interface.
> >
> > This would make the simulator seem like its a part of kicad
> > and not
> > only a strange addon that is just hackishly attached to
> > kicad with
> > duct-tape. Dont get me wrong, Its an awesome feature, and
> > works well
> > it just looks like an outsider when using it currently.
> >
> >
> >
> > As for the polishing up before the V5, there's several
> > tasks to do:
> > - update the pspice.lib library (it doesn't follow the
> > KLC) and make
> > sure all Spice devices are in there.
> > - fix quirks in the plot component (wxMathPlot).
> > - document and make a few example designs (I can help
> > with this
> > point).
> >
> > Cheers,
> > Tom
> >

Re: [Kicad-developers] Signal integrity simulation within Kicad

[Andreas Buhr]

Dear Kicad developers,

I am browsing the Kicad source code to get an idea how to integrate a
simulation tool.

I'd like the following:

1. The plugin should be informed whenever something changes. It would be
great to get a bounding box of the change.
2. The plugin should be able to draw on the canvas. I'd like to register
a new layer (for example to show the triangle mesh). The user should
then be able to enable/disable this layer.

These two requirements are in some sense similar to the requirements of
"ratsnest", so I followed "ratsnest" through the code.

Concerning (1):
I got the impression that it is not easy to be informed about all
changes in a BOARD. Is this correct?

Concerning (2):
And I got the impression that there is not one way to draw to the
canvas. I found two drawing methods for ratsnest, one in PCB_BASE_FRAME,
the other in RATSNEST_VIEWITEM::ViewDraw. Is it necessary to implement
two drawing methods for each feature?

And it seems that the layers are organized in an enum (GAL_LAYER_ID), so
adding a layer at runtime seems impossible without larger infrastructure
changes. Is this correct?

What would you propose? How can a plugin be informed about all changes
to the board? And how could a plugin draw on the canvas?

thanks a lot in advance,
Cheers,
Andreas


On 11/30/2017 12:18 AM, Wayne Stambaugh wrote:
> Hi Andreas,
> 
> Per our previous conversation, if you want to write your solver in C++,
> then I would prefer that you do it as part of a solver plugin rather
> than a command event handler in Pcbnew.  I image there would be other
> uses for a solver plugin object such as a thermal mapping solver which
> has been proposed in the past.  The other option would be to use the
> Python action object and write the entire solver in Python rather than
> C++.  That may make your life a bit easier.
> 
> Cheers,
> 
> Wayne
> 
> On 11/29/2017 01:09 PM, Andreas Buhr wrote:
>> Dear Kicad developers,
>>
>> I'm new to Kicad development. Maybe you could give me some starting tips?
>>
>> I am a 5th year PhD student at the university of Münster in Germany,
>> website:
>> https://www.uni-muenster.de/AMM/en/ohlberger/team/andreas_buhr.shtml
>>
>> I am doing mathematical research targeted at developing solvers for 3D
>> Maxwell's equations in highly complex structures, such as PCBs. While
>> being in an early stage, the goal is to develop a signal integrity
>> solver which does a full-wave simulation of the electromagnetic fields
>> and calculates S-parameters within a very short time.
>>
>> I would love to develop and test my algorithms within KiCad.
>>
>> The input which my solver needs would be an array of polygons,
>> representing the copper-filled areas on each layer.
>> I then want to create a 2D triangle mesh and based on that a 3D prism
>> mesh for finite element analysis.
>>
>> What would you recommend? How to I get polygons, representing the copper
>> filled areas of each layer?
>> I do have some experience developing C++.
>>
>> thanks a lot in advance,
>> best regards,
>>
>> Andreas
>>
>>
>>
>> ___
>> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Simulator towards 5.0

[Wayne Stambaugh]

Can we guarantee that these build dependencies are available on all
platforms?  I'm primarily think of BSD devs.  For the windows, macos,
and linux devs there are no issues.

On 12/5/2017 9:28 AM, Nick Østergaard wrote:
> I would personally also like to see these options enabled by default. It
> makes it easier for a packager to be convinced what options to enable... :)
> 
> 2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
> >:
> 
> I checked the default package in Ubuntu ppa through a friend. Indeed
> all of this is enabled.
> 
> Here I attach a small patch that changes the default compile-flags
> to the ones in the released packages. Its a small fix and it doesnt
> add or remove anything really, just a changes how a default build
> for a novice will look, maybe it will reduce some initial confusion
> for someone.
> 
> - Kristoffer
> 
> On 12/04/2017 10:19 PM, Nick Østergaard wrote:
> 
> 
> 
> Den 4. dec. 2017 18.50  skrev "kristoffer
> Ödmark"  
>  >>:
> 
> 
> 
>     On 2017-12-04 15:22, Tomasz Wlostowski wrote:
> 
>         Kristoffer,
> 
>         You're very welcome to specify how you'd like to have the
>         Spice-related
>         fields organized - but remember it's not only the
> integrated ngspice
>         simulator that relies on them. People have been
> exporting PSpice
>         netlists from Kicad for a while and AFAIR netlist export
> depends on
>         these particular fields.
> 
>     Okay, My suggestions:
> 
>     1. Enable the spice simulator by default and start shipping
> it with
>     windows nightlies. This way we will find much more bugs.
> Because I
>     doubt everyone is running with the simulator on even on
> nightlies.
>     Same goes for the OCE and step stuff. This I see as a must
> to get a
>     smoother v5 transition for most users, even those moving from v4
>     stable to v5 stable without ever trying nightlies.
> 
> 
> Everything should be enabled for the windows nightlies. It has
> been when the OCE stuff and ngspice stuff was merged. If it not
> it is a bug.
> 
> 
>     2. Parse the "value" field and reference in the simulator to
> get the
>     basic primitives. like Resistor and Capactiors, inductors
> etc, based
>     on the first Letter in the Reference. We already have
> name-dependent
>     functions for the differential-pair so having this here, and
> 
>     3. Move the Spice_Netlist_Enabled field to a new right-side
> toggle
>     menu to select between "Spice and PCB, Spice Only, PCB
> only", so one
>     can specify if the item should be added to both the PCB and the
>     Spice netlist, or only one of them, by default I guess both
> should
>     be enabled.
> 
>     4. When the Spice_Model field is selected, the button "Edit
> Spice
>     Model" should be shown under there, instead of always on the
> left
>     side. Just to be more like the other fields.
> 
>     5. Add context-menu entries and toolbar buttons for the
> simulator
>     interface.
> 
>     This would make the simulator seem like its a part of kicad
> and not
>     only a strange addon that is just hackishly attached to
> kicad with
>     duct-tape. Dont get me wrong, Its an awesome feature, and
> works well
>     it just looks like an outsider when using it currently.
> 
> 
> 
>         As for the polishing up before the V5, there's several
> tasks to do:
>         - update the pspice.lib library (it doesn't follow the
> KLC) and make
>         sure all Spice devices are in there.
>         - fix quirks in the plot component (wxMathPlot).
>         - document and make a few example designs (I can help
> with this
>         point).
> 
>         Cheers,
>         Tom
> 
> 
> 
>     ___
>     Mailing list: https://launchpad.net/~kicad-developers
> 
>      >
>     Post to     : kicad-developers@lists.launchpad.net
> 
>      

Re: [Kicad-developers] Simulator towards 5.0

[Nick Østergaard]

I would personally also like to see these options enabled by default. It
makes it easier for a packager to be convinced what options to enable... :)

2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark :

> I checked the default package in Ubuntu ppa through a friend. Indeed all
> of this is enabled.
>
> Here I attach a small patch that changes the default compile-flags to the
> ones in the released packages. Its a small fix and it doesnt add or remove
> anything really, just a changes how a default build for a novice will look,
> maybe it will reduce some initial confusion for someone.
>
> - Kristoffer
>
> On 12/04/2017 10:19 PM, Nick Østergaard wrote:
>
>>
>>
>> Den 4. dec. 2017 18.50 skrev "kristoffer Ödmark" <
>> kristofferodmar...@gmail.com >:
>>
>>
>>
>> On 2017-12-04 15:22, Tomasz Wlostowski wrote:
>>
>> Kristoffer,
>>
>> You're very welcome to specify how you'd like to have the
>> Spice-related
>> fields organized - but remember it's not only the integrated
>> ngspice
>> simulator that relies on them. People have been exporting PSpice
>> netlists from Kicad for a while and AFAIR netlist export depends
>> on
>> these particular fields.
>>
>> Okay, My suggestions:
>>
>> 1. Enable the spice simulator by default and start shipping it with
>> windows nightlies. This way we will find much more bugs. Because I
>> doubt everyone is running with the simulator on even on nightlies.
>> Same goes for the OCE and step stuff. This I see as a must to get a
>> smoother v5 transition for most users, even those moving from v4
>> stable to v5 stable without ever trying nightlies.
>>
>>
>> Everything should be enabled for the windows nightlies. It has been when
>> the OCE stuff and ngspice stuff was merged. If it not it is a bug.
>>
>>
>> 2. Parse the "value" field and reference in the simulator to get the
>> basic primitives. like Resistor and Capactiors, inductors etc, based
>> on the first Letter in the Reference. We already have name-dependent
>> functions for the differential-pair so having this here, and
>>
>> 3. Move the Spice_Netlist_Enabled field to a new right-side toggle
>> menu to select between "Spice and PCB, Spice Only, PCB only", so one
>> can specify if the item should be added to both the PCB and the
>> Spice netlist, or only one of them, by default I guess both should
>> be enabled.
>>
>> 4. When the Spice_Model field is selected, the button "Edit Spice
>> Model" should be shown under there, instead of always on the left
>> side. Just to be more like the other fields.
>>
>> 5. Add context-menu entries and toolbar buttons for the simulator
>> interface.
>>
>> This would make the simulator seem like its a part of kicad and not
>> only a strange addon that is just hackishly attached to kicad with
>> duct-tape. Dont get me wrong, Its an awesome feature, and works well
>> it just looks like an outsider when using it currently.
>>
>>
>>
>> As for the polishing up before the V5, there's several tasks to
>> do:
>> - update the pspice.lib library (it doesn't follow the KLC) and
>> make
>> sure all Spice devices are in there.
>> - fix quirks in the plot component (wxMathPlot).
>> - document and make a few example designs (I can help with this
>> point).
>>
>> 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] Zone filling & display speed improvements

[Simon Richter]

Hi,

On 05.12.2017 15:17, Wayne Stambaugh wrote:

> One less pop up window is a good thing.  I like the status bar idea but
> unless you can get it done quickly I would prefer to make this part of
> version 6.  We should be focusing on bug fixing for the stable 5 release.

If the status bar is part of the main window, people will expect it to
be non-modal. For that to happen, we need to change a lot of things
internally — this is desirable, but definitely outside the scope of v5.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Build failed in Jenkins: kicad-qa #3119

[Miguel Angel Ajo]

See 

Changes:

[tomasz.wlostowski] pcbnew: Optimized zone filling algorithm.

[tomasz.wlostowski] SHAPE_FILE_IO: default constructor outputs to stdout

[tomasz.wlostowski] SHAPE_POLY_SET: fix empty triangulation bug

[tomasz.wlostowski] pcbnew: made TransformShapeWithClearanceToPolygon virtual

[tomasz.wlostowski] Sample tool for generating board geometyr as polygons

[tomasz.wlostowski] PCB_TOOL: added convenience methods for accessing current 
SELECTION

[tomasz.wlostowski] POINT_EDITOR: migrate to ZONE_FILLER class

[tomasz.wlostowski] pcbnew: factored out ZONE_FILLER to a separate file

[tomasz.wlostowski] pcbnew: removed unused files

[tomasz.wlostowski] pcbnew: Optimized zone filling algorithm: code cleanup

[tomasz.wlostowski] pcbnew: made zone filling algorithm thread-safe. - moved 
zone filling

[tomasz.wlostowski] WX_PROGRESS_REPORTER: fix assert warnings

[tomasz.wlostowski] WX_PROGRESS_REPORTER: fixed windows build error

[tomasz.wlostowski] pcbnew: now PROGRESS_REPORTER should work in multi-threaded 
context

[tomasz.wlostowski] poly2tri: fixed some warnings

--
[...truncated 64.51 KB...]
:838:10: 
warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 auto selection = m_selectionTool->RequestSelection( SELECTION_DELETABLE | 
SELECTION_SANITIZE_PADS );
  ^
: In member 
function ‘int EDIT_TOOL::MoveExact(const TOOL_EVENT&)’:
:875:17: 
warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 const auto& selection = m_selectionTool->RequestSelection();
 ^
: In member 
function ‘int EDIT_TOOL::Duplicate(const TOOL_EVENT&)’:
:930:17: 
warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 const auto& selection = m_selectionTool->RequestSelection( 
SELECTION_DELETABLE | SELECTION_SANITIZE_PADS );
 ^
: In member 
function ‘int EDIT_TOOL::CreateArray(const TOOL_EVENT&)’:
:1074:17: 
warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 const auto& selection = m_selectionTool->RequestSelection();
 ^
: In member 
function ‘int EDIT_TOOL::ExchangeFootprints(const TOOL_EVENT&)’:
:1090:17: 
warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 const auto& selection = m_selectionTool->RequestSelection();
 ^
: In member 
function ‘int EDIT_TOOL::MeasureTool(const TOOL_EVENT&)’:
:1122:11: 
warning: declaration of ‘view’ shadows a member of 'this' [-Wshadow]
 auto& view = *getView();
   ^
:1123:11: 
warning: declaration of ‘controls’ shadows a member of 'this' [-Wshadow]
 auto& controls = *getViewControls();
   ^
: In member 
function ‘int EDIT_TOOL::editFootprintInFpEditor(const TOOL_EVENT&)’:
:1266:17: 
warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 const auto& selection = m_selectionTool->RequestSelection();
 ^
: In member 
function ‘int EDIT_TOOL::copyToClipboard(const TOOL_EVENT&)’:
:1331:15: 
warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 SELECTION selection = m_selectionTool->RequestSelection();
   ^
: In member 
function ‘T* EDIT_TOOL::uniqueSelected()’:
:1362:11: 
warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 auto& selection = m_selectionTool->RequestSelection( SELECTION_DEFAULT );
   ^
: In 
instantiation of ‘T* EDIT_TOOL::uniqueSelected() [with T = TRACK]’:
:336:42:   
required from here

Re: [Kicad-developers] Zone filling & display speed improvements

[Wayne Stambaugh]

On 12/5/2017 9:06 AM, Tomasz Wlostowski wrote:
> On 05/12/17 13:10, Oliver Walters wrote:
>> Could the filling progress be displayed in the lower statusbar instead
>> of a popup window?
> 
> Great idea, if:
> - someone codes it :-)
> - other progress dialogs are migrated to the new progress bar for
> consistency.
> 
> Tom
> 

One less pop up window is a good thing.  I like the status bar idea but
unless you can get it done quickly I would prefer to make this part of
version 6.  We should be focusing on bug fixing for the stable 5 release.

Wayne

___
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] Zone filling & display speed improvements

[Wayne Stambaugh]

On 12/4/2017 10:48 PM, Henner Zeller wrote:
> On 4 December 2017 at 16:41, Tomasz Wlostowski
>  wrote:
>> On 04/12/17 15:43, Henner Zeller wrote:
>>> On 4 December 2017 at 06:31, Tomasz Wlostowski
>>>  wrote:
 On 04/12/17 02:05, Henner Zeller wrote:
> On 2 December 2017 at 10:11, Henner Zeller  wrote:
>> On 1 December 2017 at 08:12, Tomasz Wlostowski
>>  wrote:
>>> On 29/11/17 16:10, jp charras wrote:
 I am using a few board in Kicad demos: interf_u, video, pic_programmer.

 Also, filled areas are no shown in OpenGL, but are shown in Cairo 
 canvas.
>>>
>>> Hi all,
>>>
>>> The branch [1] contains a set of improvements in the zone filling
>>> algorithm. It's several times faster than in the current master branch.
>>>
>>> I'd like to merge it soon and move on to fixing P issues pending for
>>> the V5 - I'll greatly appreciate testing and feedback!
>>
>> Hi Tom,
>>
>> I'll compile your branch hopefully later this weekend for testing.
>> If you need another board for testing, I am currently having a board
>> that takes annoying several seconds to fill the zones in head KiCad,
>> which hence might be interesting test case:

 Hi Henner,

 What OS did you build for?
>>>
>>> This was on Debian testing on a x86_64 machine.
>>> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
>>>
>>> -h
>>
>> Hi guys,
>>
>> Now it should work fine - the filling algorithm was not thread safe and
>> apparently wxProgressDialog can't be invoked from non-main thread.
>>
>> Check out the updated branch.
> 
> Thanks Tom!
> 
> Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
> have not seen any crashes anymore.
> 
> There is a leftover method mentioned in pcbnew/class_zone.h:
>   void RemoveInsulatedCopperIslands()
> .. which is not used/implemented so should be removed from the header.
> 
> One thing I noticed: since it is sooo fast now, the progress-popup is
> actually quite annoying as it just briefly blinks up and vanishes
> again (at least for the board I was testing it with). Maybe it should
> only show up if the operation is still ongoing after a second and less
> than 50% is done at that time ?
> 
> Another thought: if zone filling can be that fast, maybe we should
> only store zone outlines in the *.kicad_pcb file, not the
> (filled_polygon ...) that are now also stored. It is cheap to just
> recreate them when loading the file.> Backround: This can save a lot of disk 
> space as the filled polygons
> tend to create a lot of points and tend to completely change with tiny
> changes to other elements on the board, such as a moved via. This
> means that version control has to store huge changes every time and it
> is hard to see what actual changes are happening just looking at the
> diff (I like to inspect diffs before checking something in, and this
> makes it hard. Also it makes it hard to git merge kicad-pcbs).
> Downside is, that everyone loading a file has to pay the extra cost to
> create the zones (e.g. gerber generation). Maybe it could be a
> heuristic to not store the filled polygons if recreating it takes less
> than a second or so.

I'm opposed to this idea.  What would happen the next time the zone
filling algorithm is changed?  You would most likely produce different
zone filling which would effectively result in a different board.  This
a huge no-no in production environments where once a board is released,
the expectation is that output plots do not change.  Changes in the
polygon generation could result in boards that worked fine with the
previous filling algorithm but not with the new algorithm.  Refilling
zones on board load is just asking for trouble.

> 
> Cheers,
>   Henner.
> 
>>
>> Thanks!
>> 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] Zone filling & display speed improvements

[Tomasz Wlostowski]

On 05/12/17 13:10, Oliver Walters wrote:
> Could the filling progress be displayed in the lower statusbar instead
> of a popup window?

Great idea, if:
- someone codes it :-)
- other progress dialogs are migrated to the new progress bar for
consistency.

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] Zone filling & display speed improvements

[Tomasz Wlostowski]

On 05/12/17 04:48, Henner Zeller wrote:
> Thanks Tom!
> 
> Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
> have not seen any crashes anymore.
> 
> There is a leftover method mentioned in pcbnew/class_zone.h:
>   void RemoveInsulatedCopperIslands()
> .. which is not used/implemented so should be removed from the header.
> 
> One thing I noticed: since it is sooo fast now, the progress-popup is
> actually quite annoying as it just briefly blinks up and vanishes
> again (at least for the board I was testing it with). Maybe it should
> only show up if the operation is still ongoing after a second and less
> than 50% is done at that time ?
> 
> Another thought: if zone filling can be that fast, maybe we should
> only store zone outlines in the *.kicad_pcb file, not the
> (filled_polygon ...) that are now also stored. It is cheap to just
> recreate them when loading the file.
> Backround: This can save a lot of disk space as the filled polygons
> tend to create a lot of points and tend to completely change with tiny
> changes to other elements on the board, such as a moved via. This
> means that version control has to store huge changes every time and it
> is hard to see what actual changes are happening just looking at the
> diff (I like to inspect diffs before checking something in, and this
> makes it hard. Also it makes it hard to git merge kicad-pcbs).
> Downside is, that everyone loading a file has to pay the extra cost to
> create the zones (e.g. gerber generation). Maybe it could be a
> heuristic to not store the filled polygons if recreating it takes less
> than a second or so.

Hi Henner,

I wouldn't change the file format for such purpose (I'm opposed to using
textual diff for graphical files, like PCBs). Also I don't think these
days saving a few megabytes is worth it.

Concerning the heuristics - It's a good idea, but for the moment I have
a ton of P issues to fix before the V5 goes out. Also I'm a bit
discouraged to write any GUI code after many failed attempts to update a
wxProgressDialog from an OpenMP context.

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] Simulator towards 5.0

[Kristoffer Ödmark]

I checked the default package in Ubuntu ppa through a friend. Indeed all 
of this is enabled.


Here I attach a small patch that changes the default compile-flags to 
the ones in the released packages. Its a small fix and it doesnt add or 
remove anything really, just a changes how a default build for a novice 
will look, maybe it will reduce some initial confusion for someone.


- Kristoffer

On 12/04/2017 10:19 PM, Nick Østergaard wrote:



Den 4. dec. 2017 18.50 skrev "kristoffer Ödmark" 
>:




On 2017-12-04 15:22, Tomasz Wlostowski wrote:

Kristoffer,

You're very welcome to specify how you'd like to have the
Spice-related
fields organized - but remember it's not only the integrated ngspice
simulator that relies on them. People have been exporting PSpice
netlists from Kicad for a while and AFAIR netlist export depends on
these particular fields.

Okay, My suggestions:

1. Enable the spice simulator by default and start shipping it with
windows nightlies. This way we will find much more bugs. Because I
doubt everyone is running with the simulator on even on nightlies.
Same goes for the OCE and step stuff. This I see as a must to get a
smoother v5 transition for most users, even those moving from v4
stable to v5 stable without ever trying nightlies.


Everything should be enabled for the windows nightlies. It has been when 
the OCE stuff and ngspice stuff was merged. If it not it is a bug.



2. Parse the "value" field and reference in the simulator to get the
basic primitives. like Resistor and Capactiors, inductors etc, based
on the first Letter in the Reference. We already have name-dependent
functions for the differential-pair so having this here, and

3. Move the Spice_Netlist_Enabled field to a new right-side toggle
menu to select between "Spice and PCB, Spice Only, PCB only", so one
can specify if the item should be added to both the PCB and the
Spice netlist, or only one of them, by default I guess both should
be enabled.

4. When the Spice_Model field is selected, the button "Edit Spice
Model" should be shown under there, instead of always on the left
side. Just to be more like the other fields.

5. Add context-menu entries and toolbar buttons for the simulator
interface.

This would make the simulator seem like its a part of kicad and not
only a strange addon that is just hackishly attached to kicad with
duct-tape. Dont get me wrong, Its an awesome feature, and works well
it just looks like an outsider when using it currently.



As for the polishing up before the V5, there's several tasks to do:
- update the pspice.lib library (it doesn't follow the KLC) and make
sure all Spice devices are in there.
- fix quirks in the plot component (wxMathPlot).
- document and make a few example designs (I can help with this
point).

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



>From ec962a3bb445573b546b90e539643d1f328d016e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristoffer=20=C3=96dmark?= 
Date: Tue, 5 Dec 2017 14:33:10 +0100
Subject: [PATCH] Changed default compile-flags to match released packages

---
 CMakeLists.txt | 20 ++--
 Documentation/development/compiling.md | 12 ++--
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index c70a34237..bff065eb0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -54,24 +54,24 @@ option( USE_WX_OVERLAY
 "Use wxOverlay: Always ON for MAC (default OFF).  Warning, this is experimental" )
 
 option( KICAD_SCRIPTING
-"Build the Python scripting support inside KiCad binaries (default OFF)."
-)
+"Build the Python scripting support inside KiCad binaries (default ON)."
+ON )
 
 option( KICAD_SCRIPTING_MODULES
 "Build native portion of the pcbnew Python module: _pcbnew.{pyd,so} for OS command line use of Python."
-)
+ON )
 
 option( KICAD_SCRIPTING_WXPYTHON
-"Build wxPython implementation for wx interface building in Python and py.shell (default OFF)."
-)
+"Build wxPython implementation for wx interface building in Python and py.shell (default ON)."
+ON )
 
 option( KICAD_SCRIPTING_ACTION_MENU
-"Build a tools menu with registred python plugins: actions plugins (default OFF)."
-)
+

Re: [Kicad-developers] Zone filling & display speed improvements

[Tomasz Wlostowski]

On 05/12/17 08:55, jp charras wrote:
> Le 05/12/2017 à 01:41, Tomasz Wlostowski a écrit :
>> Hi guys,
>>
>> Now it should work fine - the filling algorithm was not thread safe and
>> apparently wxProgressDialog can't be invoked from non-main thread.
>>
>> Check out the updated branch.
>>
>> Thanks!
>> Tom
>>
> 
> Hi Tom,
> 
> It works fine for me.
> And on my 4 cores computer, the speedup is really impressive!
> 
> Thanks.
> 

Hi guys,

Thanks for testing, I just merged it to the master.

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] Component table view initial columns sizing

[Simon Richter]

Hi Bernhard,

On 05.12.2017 14:02, Bernhard Stegmaier wrote:

> attached patch fixes initial sizing of “Fields” table columns of component 
> table view.

Unrelated to your patch: does it make sense to perhaps share some of the
grouping code between this and the component pin table?

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Set modified flag on new sheets

[Wayne Stambaugh]

Patch merged.

Thanks,

Wayne

On 12/4/2017 4:48 PM, Seth Hillbrand wrote:
> ​The attached patch fixes https://bugs.launchpad.net/kicad/+bug/1736054
> 
> Newly created sheets should have their modified flags set so that they
> are considered "unsaved" until they are successfully written to disk.
> 
> -S​
> 
> 
> 
> ___
> 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] Eeschema wire/bus selection logic

[Wayne Stambaugh]

I merged your patch.

Thanks,

Wayne

On 12/4/2017 10:26 AM, Seth Hillbrand wrote:
> No worries.  Here's the patch rebased to current master.
> 
> -S
> 
> On Mon, Dec 4, 2017 at 5:01 AM, Wayne Stambaugh  > wrote:
> 
> Seth,
> 
> I thought I merged all of your wire/bus patches.  I cannot find this one
> in my inbox.  Please resend this patch when you get a chance.
> 
> Thanks,
> 
> Wayne
> 
> On 12/3/2017 10:57 PM, Seth Hillbrand wrote:
> > Gentle ping.
> >
> > Wayne, this is the wire-drag fix you requested last week.
> >
> > -Seth
> >
> > On Thu, Nov 30, 2017 at 6:53 PM, Jon Evans  
> > >> wrote:
> >
> >     Gave this a shot, I like this logic, thanks!
> >
> >     On Thu, Nov 30, 2017 at 8:55 PM, Seth Hillbrand
> >     
> >>
> wrote:
> >
> >         ​Attached is a patch to correct the wire/bus connection
> logic. 
> >         Currently, Eeschema will register wires and busses as being
> >         connected if their endpoints touch.  They will drag
> together and
> >         their endpoints will not show the "unconnected" symbols.
> >
> >         The attached patch implements the following logic.  The
> logic is
> >         largely based on how I like to work with entries, so please
> >         shout if you feel this is backwards somehow.
> >         ​
> >         Dragging:
> >             - busses and bus-bus entries drag each other when
> connected
> >         at endpoints
> >             - wires and wire-bus entries drag each other when
> connected
> >         at endpoints
> >             - entries do not drag wires or busses when connected
> to wire
> >         middles
> >             - wire-bus entries do not drag busses
> >             
> >         Connections:
> >             - bus-bus entries connect busses to busses but not wires
> >             - wire-bus entries connect wires to busses but not wire to
> >         wires or busses to busses
> >         ​
> >         ​Best-
> >         Seth​
> >
> >
> >         ___
> >         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 : 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] Zone filling & display speed improvements

[Oliver Walters]

Tom,

Could the filling progress be displayed in the lower statusbar instead of a
popup window?

On Tue, Dec 5, 2017 at 2:48 PM, Henner Zeller  wrote:

> On 4 December 2017 at 16:41, Tomasz Wlostowski
>  wrote:
> > On 04/12/17 15:43, Henner Zeller wrote:
> >> On 4 December 2017 at 06:31, Tomasz Wlostowski
> >>  wrote:
> >>> On 04/12/17 02:05, Henner Zeller wrote:
>  On 2 December 2017 at 10:11, Henner Zeller  wrote:
> > On 1 December 2017 at 08:12, Tomasz Wlostowski
> >  wrote:
> >> On 29/11/17 16:10, jp charras wrote:
> >>> I am using a few board in Kicad demos: interf_u, video,
> pic_programmer.
> >>>
> >>> Also, filled areas are no shown in OpenGL, but are shown in Cairo
> canvas.
> >>
> >> Hi all,
> >>
> >> The branch [1] contains a set of improvements in the zone filling
> >> algorithm. It's several times faster than in the current master
> branch.
> >>
> >> I'd like to merge it soon and move on to fixing P issues pending
> for
> >> the V5 - I'll greatly appreciate testing and feedback!
> >
> > Hi Tom,
> >
> > I'll compile your branch hopefully later this weekend for testing.
> > If you need another board for testing, I am currently having a board
> > that takes annoying several seconds to fill the zones in head KiCad,
> > which hence might be interesting test case:
> >>>
> >>> Hi Henner,
> >>>
> >>> What OS did you build for?
> >>
> >> This was on Debian testing on a x86_64 machine.
> >> g++ 7.2.0, Cairo: 1.15.8, boost 1.62.0
> >>
> >> -h
> >
> > Hi guys,
> >
> > Now it should work fine - the filling algorithm was not thread safe and
> > apparently wxProgressDialog can't be invoked from non-main thread.
> >
> > Check out the updated branch.
>
> Thanks Tom!
>
> Nice, the [tom-faster-zones-dec01] branch works well and very fast. I
> have not seen any crashes anymore.
>
> There is a leftover method mentioned in pcbnew/class_zone.h:
>   void RemoveInsulatedCopperIslands()
> .. which is not used/implemented so should be removed from the header.
>
> One thing I noticed: since it is sooo fast now, the progress-popup is
> actually quite annoying as it just briefly blinks up and vanishes
> again (at least for the board I was testing it with). Maybe it should
> only show up if the operation is still ongoing after a second and less
> than 50% is done at that time ?
>
> Another thought: if zone filling can be that fast, maybe we should
> only store zone outlines in the *.kicad_pcb file, not the
> (filled_polygon ...) that are now also stored. It is cheap to just
> recreate them when loading the file.
> Backround: This can save a lot of disk space as the filled polygons
> tend to create a lot of points and tend to completely change with tiny
> changes to other elements on the board, such as a moved via. This
> means that version control has to store huge changes every time and it
> is hard to see what actual changes are happening just looking at the
> diff (I like to inspect diffs before checking something in, and this
> makes it hard. Also it makes it hard to git merge kicad-pcbs).
> Downside is, that everyone loading a file has to pay the extra cost to
> create the zones (e.g. gerber generation). Maybe it could be a
> heuristic to not store the filled polygons if recreating it takes less
> than a second or so.
>
> Cheers,
>   Henner.
>
> >
> > Thanks!
> > 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] Zone filling & display speed improvements

[Heikki Pulkkinen]

Hi,

Glad to hear, that my idea of parallel zone filling is working.


Regards

Heikki


On Tue, Dec 5, 2017 at 9:55 AM, jp charras  wrote:

> Le 05/12/2017 à 01:41, Tomasz Wlostowski a écrit :
> > Hi guys,
> >
> > Now it should work fine - the filling algorithm was not thread safe and
> > apparently wxProgressDialog can't be invoked from non-main thread.
> >
> > Check out the updated branch.
> >
> > Thanks!
> > Tom
> >
>
> Hi Tom,
>
> It works fine for me.
> And on my 4 cores computer, the speedup is really impressive!
>
> Thanks.
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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