Re: [Kicad-developers] KiCad 5 RC1 fails to build on mips, powerpc and ppc64el due undeclared initializer LIBCONTEXT_CALL_CONVENTION

[Carsten Schoenert]

Am 09.03.2018 um 07:45 schrieb Carsten Schoenert:
...
> I can try to fix this on a Debian porter box but I've no clues if it is
> enough to simply add more define lines like the existing ones. Can
> someone of the more experienced devs give me an advise please as using a
> porterbox is always a bit of extra work and will of course also need
> extra free time (I'm currently lacking of course). Thanks!

A side note, the Debian wiki has an overview about the various of the
architecture specific things, so also the arch related pre-defined
compiler macros.

https://wiki.debian.org/ArchitectureSpecificsMemo#Summary

-- 
Regards
Carsten Schoenert

___
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] KiCad 5 RC1 fails to build on mips, powerpc and ppc64el due undeclared initializer LIBCONTEXT_CALL_CONVENTION

[Carsten Schoenert]

Hi,

I uploaded a prepared version KiCad 5.0.0-rc1 to Debian experimental a
few days ago. Due the adding of new binary packages my upload was needed
tp go through the NEW queue. Last night it got accepted by the FTP
masters and was moving over to the buildd's [1] for the experimental
release. The buildd machines started to build the package for the
various platforms.

The platforms mips, powerpc and ppc64el fails to build because of an
issue on the same file. There may be more platforms with this issue due
a not created initializer.

> cd "/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/debian/build/common" && /usr/bin/c++  
> -DHAVE_STDINT_H -DKICAD_SCRIPTING -DKICAD_SCRIPTING_MODULES 
> -DKICAD_SCRIPTING_WXPYTHON -DKICAD_USE_OCE -DUSE_OPENMP -DWXUSINGDLL 
> -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
> -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/include" 
> -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/common/." -isystem 
> /usr/lib/powerpc-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem 
> /usr/include/wx-3.0 -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/common/./dialogs" 
> -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/common/./widgets" 
> -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/common/./dialog_about" 
> -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/powerpc-linux-gnu 
> -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/common/../3d-viewer" 
> -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/common/../pcbnew" 
> -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/common/../polygon" 
> -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/debian/build" -I/usr/include/python2.7 
> -I"/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/scripting"  -Wall -g -O2 
> -fdebug-prefix-map=/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wsuggest-override -Wno-unused-local-typedefs 
> -Wno-strict-aliasing -fopenmp -pthread -Wshadow -fPIC -fvisibility=hidden 
> -fvisibility-inlines-hidden   -std=gnu++11 -o 
> CMakeFiles/common.dir/system/libcontext.cpp.o -c 
> "/«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/common/system/libcontext.cpp"
> In file included from 
> /«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/common/system/libcontext.cpp:16:0:
> /«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/include/system/libcontext.h:82:37: error: 
> expected initializer before 'jump_fcontext'
>  intptr_t LIBCONTEXT_CALL_CONVENTION jump_fcontext( fcontext_t* ofc, 
> fcontext_t nfc,
>  ^
> /«BUILDDIR»/kicad-5.0.0~rc1+dfsg1/include/system/libcontext.h:84:39: error: 
> expected initializer before 'make_fcontext'
>  fcontext_t LIBCONTEXT_CALL_CONVENTION make_fcontext( void* sp, size_t size,
>^
> make[4]: *** [common/CMakeFiles/common.dir/build.make:3411: 
> common/CMakeFiles/common.dir/system/libcontext.cpp.o] Error 1

Looking into include/system/libcontext.h the reason for this is quite
obvious. The initializer LIBCONTEXT_CALL_CONVENTION isn't set up on
these platforms.

>  25 #if defined(__GNUC__) || defined(__APPLE__) || defined(__FreeBSD__)
>  26 
>  27 #define LIBCONTEXT_COMPILER_gcc
>  28 
>  29 #if defined(__linux__) || defined(__FreeBSD__)
>  30 #if defined(__x86_64__) || defined(__amd64__)
>  31 #define LIBCONTEXT_PLATFORM_linux_x86_64
>  32 #define LIBCONTEXT_CALL_CONVENTION
>  33 #elif __i386__
>  34 #define LIBCONTEXT_PLATFORM_linux_i386
>  35 #define LIBCONTEXT_CALL_CONVENTION
>  36 #elif __arm__
>  37 #define LIBCONTEXT_PLATFORM_linux_arm32
>  38 #define LIBCONTEXT_CALL_CONVENTION
>  39 #elif __aarch64__
>  40 #define LIBCONTEXT_PLATFORM_linux_arm64
>  41 #define LIBCONTEXT_CALL_CONVENTION
>  42 #endif

I can try to fix this on a Debian porter box but I've no clues if it is
enough to simply add more define lines like the existing ones. Can
someone of the more experienced devs give me an advise please as using a
porterbox is always a bit of extra work and will of course also need
extra free time (I'm currently lacking of course). Thanks!

PS: The build issue on armel is probably related to a missing '-mfpu=vfp
-msoft-float' option or similar, I will try to reproduce this on one of
my cubieboards. If someone has a quicker solution I'm also happy to try
this out.

[1] https://buildd.debian.org/status/package.php?p=kicad=experimental

-- 
Regards
Carsten Schoenert
___
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 #3744

[Miguel Angel Ajo]

See 

Changes:

[jon] SVG Plotter: Handle edge-case arc and circle drawing

--
Started by an SCM change
Building remotely on debian8 (clang gcc linux) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://github.com/KiCad/kicad-source-mirror.git # timeout=10
Fetching upstream changes from https://github.com/KiCad/kicad-source-mirror.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/KiCad/kicad-source-mirror.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 9c62792245d12e397053e8896f3b2e3f5bdd10e4 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 9c62792245d12e397053e8896f3b2e3f5bdd10e4
Commit message: "SVG Plotter: Handle edge-case arc and circle drawing"
 > git rev-list --no-walk 921e68107b3f7e1e2f92055c940aa9163d2e6b1e # timeout=10
[kicad-qa] $ /bin/sh -xe /tmp/jenkins7506047632792370716.sh
+ cmake --version
cmake version 3.0.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
+ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ git --version
git version 2.1.4
+ OPTS= -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
+ [ -d passed-qa ]
+ [ -d build ]
+ cd build
+ /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
-- Kicad install dir: 
-- Check for installed GLEW -- found
-- Boost version: 1.55.0
-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/dist-packages
-- wxPython version 3.0 found.
-- S3DSG version: 2.0.0
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Configuring done
-- Generating done
-- Build files have been written to: 

+ echo CMAKE exit code is 0
CMAKE exit code is 0
+ rm -f pcbnew/pcbnewPYTHON_wrap.cxx
+ env
+ grep -q ^MAKEJOBS=
+ echo The MAKEJOBS variable is empty
The MAKEJOBS variable is empty
+ JOBS=4
+ make -j4 pcbnew_python_module
[  0%] [  0%] Built target lib_table_lexer_source_files
Generating version string header
[  0%] Built target idf3
-- Using Git to determine build version string.
[  0%] Built target page_layout_lexer_source_files
-- Found Git: /usr/bin/git (found version "2.1.4") 
[  0%] Built target netlist_lexer_source_files
[  0%] Built target pcb_plot_lexer_source_files
-- Writing 
 file with 
version: (5.0.0-rc2-dev-154-g9c62792)
[  0%] [  0%] Built target version_header
Built target pcb_lexer_source_files
[  0%] Built target lib_dxf
[  2%] Built target gal
[  5%] Built target kicad_3dsg
[  5%] Built target specctra_lexer_source_files
[  5%] Built target polygon
[ 49%] Built target bitmaps
[ 54%] Built target pcbcommon
[ 56%] Built target pcad2kicadpcb
[ 61%] Built target 3d-viewer
Scanning dependencies of target common
[ 61%] [ 61%] Building CXX object 
common/CMakeFiles/common.dir/plotters/SVG_plotter.cpp.o
Building CXX object common/CMakeFiles/common.dir/build_version.cpp.o
[ 83%] Built target pcbnew_kiface_objects
Linking CXX static library libcommon.a
/usr/bin/ranlib: libcommon.a: No space left on device
common/CMakeFiles/common.dir/build.make:4343: recipe for target 
'common/libcommon.a' failed
make[3]: *** [common/libcommon.a] Error 1
CMakeFiles/Makefile2:240: recipe for target 'common/CMakeFiles/common.dir/all' 
failed
make[2]: *** [common/CMakeFiles/common.dir/all] Error 2
CMakeFiles/Makefile2:1501: recipe for target 
'pcbnew/CMakeFiles/pcbnew_python_module.dir/rule' failed
make[1]: *** [pcbnew/CMakeFiles/pcbnew_python_module.dir/rule] Error 2
Makefile:600: recipe for target 'pcbnew_python_module' failed
make: *** [pcbnew_python_module] Error 2
Build step 'Execute shell' marked build as failure

___
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 #3743

[Miguel Angel Ajo]

See 

Changes:

[jon] OpenGL: Make circle/arc drawing match Cairo for some edge cases

--
Started by an SCM change
Building remotely on debian8 (clang gcc linux) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://github.com/KiCad/kicad-source-mirror.git # timeout=10
Fetching upstream changes from https://github.com/KiCad/kicad-source-mirror.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/KiCad/kicad-source-mirror.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 921e68107b3f7e1e2f92055c940aa9163d2e6b1e 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 921e68107b3f7e1e2f92055c940aa9163d2e6b1e
Commit message: "OpenGL: Make circle/arc drawing match Cairo for some edge 
cases"
 > git rev-list --no-walk d88425d0e865e06c8e5fac77b37b435675b6 # timeout=10
[kicad-qa] $ /bin/sh -xe /tmp/jenkins7804807194260668801.sh
+ cmake --version
cmake version 3.0.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
+ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ git --version
git version 2.1.4
+ OPTS= -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
+ [ -d passed-qa ]
+ [ -d build ]
+ cd build
+ /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
-- Kicad install dir: 
-- Check for installed GLEW -- found
-- Boost version: 1.55.0
-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/dist-packages
-- wxPython version 3.0 found.
-- S3DSG version: 2.0.0
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Configuring done
-- Generating done
-- Build files have been written to: 

+ echo CMAKE exit code is 0
CMAKE exit code is 0
+ rm -f pcbnew/pcbnewPYTHON_wrap.cxx
+ env
+ grep -q ^MAKEJOBS=
+ echo The MAKEJOBS variable is empty
The MAKEJOBS variable is empty
+ JOBS=4
+ make -j4 pcbnew_python_module
[  0%] [  0%] Built target lib_table_lexer_source_files
Generating version string header
[  0%] Built target idf3
[  0%] [  0%] Built target page_layout_lexer_source_files
Built target netlist_lexer_source_files
-- Using Git to determine build version string.
-- Found Git: /usr/bin/git (found version "2.1.4") 
[  0%] Built target pcb_lexer_source_files
[  0%] Built target pcb_plot_lexer_source_files
-- Writing 
 file with 
version: (5.0.0-rc2-dev-153-g921e681)
[  0%] Built target version_header
Scanning dependencies of target gal
[  0%] Built target lib_dxf
[  2%] Built target kicad_3dsg
[  2%] Building CXX object common/CMakeFiles/gal.dir/gal/opengl/opengl_gal.cpp.o
[  2%] Built target specctra_lexer_source_files
[ 46%] Built target bitmaps
[ 46%] Building CXX object 
common/CMakeFiles/gal.dir/gal/opengl/gl_builtin_shaders.cpp.o
[ 46%] Built target polygon
[ 52%] Built target pcbcommon
[ 53%] Built target pcad2kicadpcb
[ 74%] Built target pcbnew_kiface_objects
Linking CXX static library libgal.a
[ 77%] Built target gal
[ 83%] Built target 3d-viewer
Scanning dependencies of target common
[ 83%] Building CXX object common/CMakeFiles/common.dir/build_version.cpp.o
Linking CXX static library libcommon.a
/usr/bin/ranlib: libcommon.a: No space left on device
common/CMakeFiles/common.dir/build.make:4343: recipe for target 
'common/libcommon.a' failed
make[3]: *** [common/libcommon.a] Error 1
CMakeFiles/Makefile2:240: recipe for target 'common/CMakeFiles/common.dir/all' 
failed
make[2]: *** [common/CMakeFiles/common.dir/all] Error 2
CMakeFiles/Makefile2:1501: recipe for target 
'pcbnew/CMakeFiles/pcbnew_python_module.dir/rule' failed
make[1]: *** [pcbnew/CMakeFiles/pcbnew_python_module.dir/rule] Error 2
Makefile:600: recipe for target 'pcbnew_python_module' failed
make: *** [pcbnew_python_module] Error 2
Build step 'Execute shell' marked build as failure

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

Re: [Kicad-developers] [PATCH] - Symbol Table Reference column fix

[hauptmech]

Oops, gotta set git diff to highlight that. Thanks!

On 9/03/18 15:00, Jon Evans wrote:
Works for me, although your comments have tabs instead of spaces in 
front.  I fixed this and committed your patch.  Thanks!


On Thu, Mar 8, 2018 at 8:49 PM, hauptmech > wrote:


https://bugs.launchpad.net/kicad/+bug/1753330


___
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] - Symbol Table Reference column fix

[Jon Evans]

Works for me, although your comments have tabs instead of spaces in front.
I fixed this and committed your patch.  Thanks!

On Thu, Mar 8, 2018 at 8:49 PM, hauptmech  wrote:

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

[Kicad-developers] [PATCH] Add ERC checks for conflicting multi-unit pins

[Jon Evans]

Relating to https://bugs.launchpad.net/kicad/+bug/1680638

I figured Wayne and perhaps some others would like to check this out before
merging to make sure it properly addresses the problem.

-Jon
From 210eae84bd55854323939f179abe2c8927fe020c Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Thu, 8 Mar 2018 20:52:03 -0500
Subject: [PATCH 2/2] Add ERC check in component editor for conflicting
 multi-unit pins

Fixes: lp:1680638
* https://bugs.launchpad.net/kicad/+bug/1680638
---
 eeschema/pinedit.cpp | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/eeschema/pinedit.cpp b/eeschema/pinedit.cpp
index a6279..ff39bcff2 100644
--- a/eeschema/pinedit.cpp
+++ b/eeschema/pinedit.cpp
@@ -722,8 +722,7 @@ void LIB_EDIT_FRAME::OnCheckComponent( wxCommandEvent& event )
 LIB_PIN* pin  = pinList[ii - 1];
 
 if( pin->GetNumber() != curr_pin->GetNumber()
-|| pin->GetConvert() != curr_pin->GetConvert()
-|| pin->GetUnit() != curr_pin->GetUnit() )
+|| pin->GetConvert() != curr_pin->GetConvert() )
 continue;
 
 dup_error++;
@@ -746,7 +745,9 @@ void LIB_EDIT_FRAME::OnCheckComponent( wxCommandEvent& event )
 
 if( part->GetUnitCount() > 1 )
 {
-msg += wxString::Format( _( " in symbol %c" ), 'A' + curr_pin->GetUnit() - 1 );
+msg += wxString::Format( _( " in units %c and %c" ),
+ 'A' + curr_pin->GetUnit() - 1,
+ 'A' + pin->GetUnit() - 1 );
 }
 
 if( m_showDeMorgan )
-- 
2.14.1

From e5b4a1d07a5b3dff305c90a7d17995010a0d9d24 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Thu, 8 Mar 2018 20:42:06 -0500
Subject: [PATCH 1/2] Add ERC check for conflicting pins on multi-unit
 components

Fixes: lp:1680638
* https://bugs.launchpad.net/kicad/+bug/1680638
---
 eeschema/dialogs/dialog_erc.cpp |  3 +++
 eeschema/drc_erc_item.cpp   |  2 ++
 eeschema/erc.cpp| 60 +
 eeschema/erc.h  | 12 +
 4 files changed, 77 insertions(+)

diff --git a/eeschema/dialogs/dialog_erc.cpp b/eeschema/dialogs/dialog_erc.cpp
index 4a257a443..2bd1540dd 100644
--- a/eeschema/dialogs/dialog_erc.cpp
+++ b/eeschema/dialogs/dialog_erc.cpp
@@ -482,6 +482,9 @@ void DIALOG_ERC::TestErc( REPORTER& aReporter )
  */
 TestMultiunitFootprints( sheets );
 
+// Test multi-unit components for conflicting pin numbers
+TestMultiunitPinConflicts( sheets );
+
 std::unique_ptr objectsConnectedList( m_parent->BuildNetListBase() );
 
 // Reset the connection type indicator
diff --git a/eeschema/drc_erc_item.cpp b/eeschema/drc_erc_item.cpp
index 15a893cca..9739a07cf 100644
--- a/eeschema/drc_erc_item.cpp
+++ b/eeschema/drc_erc_item.cpp
@@ -60,6 +60,8 @@ wxString DRC_ITEM::GetErrorText() const
 return wxString( _("Global labels are similar (lower/upper case difference only)") );
 case ERCE_DIFFERENT_UNIT_FP:
 return wxString( _("Different footprint assigned in another unit of the same component") );
+case ERCE_DIFFERENT_UNIT_PIN:
+return wxString( _( "Conflicting pin in another unit of the same component" ) );
 
 default:
 wxFAIL_MSG( "Missing ERC error description" );
diff --git a/eeschema/erc.cpp b/eeschema/erc.cpp
index 8fdee6f15..4ad86da06 100644
--- a/eeschema/erc.cpp
+++ b/eeschema/erc.cpp
@@ -28,6 +28,7 @@
  * @brief Electrical Rules Check implementation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -291,6 +292,65 @@ int TestMultiunitFootprints( SCH_SHEET_LIST& aSheetList )
 }
 
 
+int TestMultiunitPinConflicts( SCH_SHEET_LIST& aSheetList )
+{
+int errors = 0;
+std::map footprints;
+SCH_MULTI_UNIT_REFERENCE_MAP refMap;
+aSheetList.GetMultiUnitComponents( refMap, true );
+
+for( auto& component : refMap )
+{
+auto& refList = component.second;
+
+if( refList.GetCount() == 0 )
+{
+wxFAIL;   // it should not happen
+continue;
+}
+
+std::unordered_set seen_pins;
+
+for( unsigned i = 0; i < component.second.GetCount(); ++i )
+{
+SCH_REFERENCE& ref = refList.GetItem( i );
+SCH_COMPONENT* cmp = ref.GetComp();
+SCH_SHEET_PATH sheetPath = ref.GetSheetPath();
+
+std::vector pins;
+cmp->GetPins( pins );
+
+for( auto pin : pins )
+{
+if( seen_pins.find( pin->GetNumber() ) != seen_pins.end() )
+{
+wxString unitName = cmp->GetRef(  )
++ LIB_PART::SubReference( cmp->GetUnit(), false );
+
+SCH_MARKER* marker = new SCH_MARKER();
+
+marker->SetTimeStamp( GetNewTimeStamp() );
+marker->SetData( ERCE_DIFFERENT_UNIT_FP, cmp->GetPosition(),

[Kicad-developers] [PATCH] - Symbol Table Reference column fix

[hauptmech]

https://bugs.launchpad.net/kicad/+bug/1753330
From 5094bf1e3f38ea7f67e7adf79c7bf7c4ab3b2114 Mon Sep 17 00:00:00 2001
From: hauptmech 
Date: Fri, 9 Mar 2018 14:44:20 +1300
Subject: [PATCH] Use fixed width on first Symbol Table column
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.16.2"

This is a multi-part message in MIME format.
--2.16.2
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


Autosize when the reference field is a list of all components was too long.

Fixes: lp:1753330
https://bugs.launchpad.net/kicad/+bug/1753330
---
 eeschema/dialogs/dialog_fields_editor_global.cpp | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)


--2.16.2
Content-Type: text/x-patch; name="0001-Use-fixed-width-on-first-Symbol-Table-column.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Use-fixed-width-on-first-Symbol-Table-column.patch"

diff --git a/eeschema/dialogs/dialog_fields_editor_global.cpp b/eeschema/dialogs/dialog_fields_editor_global.cpp
index a5b679eae..2d630bb78 100644
--- a/eeschema/dialogs/dialog_fields_editor_global.cpp
+++ b/eeschema/dialogs/dialog_fields_editor_global.cpp
@@ -84,8 +84,16 @@ DIALOG_FIELDS_EDITOR_GLOBAL::DIALOG_FIELDS_EDITOR_GLOBAL( SCH_EDIT_FRAME* parent
 sortColumn->SetWidth( wxCOL_WIDTH_AUTOSIZE );
 sortColumn->SetResizeable( false );
 
+
+	// Reference column is either single reference or a list of references.
+	// Autosize can fill the window in the case of a list so use a fixed width.
+	// wxCOL_WIDTH_DEFAULT is wxDVC_DEFAULT_WIDTH on all platforms and too small.
+auto refcol = m_bomView->GetColumn( 0 );
+refcol->SetWidth( wxDVC_DEFAULT_WIDTH * 2 );
+refcol->SetResizeable( true );
+
 // Set default column widths for BOM table
-for( unsigned int ii = 0; ii < m_bomView->GetColumnCount(); ii++ )
+for( unsigned int ii = 1; ii < m_bomView->GetColumnCount(); ii++ )
 {
 auto col = m_bomView->GetColumn( ii );
 

--2.16.2--


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

Re: [Kicad-developers] [RFC] Dynamic text in schematic and board.

[Jon Evans]

I think option A is a good feature to add across schematic and layout. A
macro substitution system for text is very handy especially as we introduce
a better object properties system.

For example, it would be nice if we could assign arbitrary properties to
the project as a whole, as well as each schematic  sheet. Then, you can
refer to these properties in text fields. Useful for schematic templates
and other things like that.

B is also good.  In Altium you can show/hide any properties of an object,
which seamlessly creates a "linked" text object as you describe when you
choose "show".  This is a really nice system.

-Jon


On Thu, Mar 8, 2018, 16:39 Russell Oliver  wrote:

> As a follow up to the road map discussion I saw a forum post asking if it
> was possible to display the net name of a pad on the silkscreen or other
> layers much like the value or reference fields.
>
> While a simple implementation would be to create a text item directly
> linked to each pad that could be enabled, and shows the link to the
> relevant pad,  I think a more generic approach would be great to have.
>
> I propose that either or both of these options for version 7.
>
> a) standalone text items are processed as a template.  A domain specific
> language would be designed to allow for references to items as direct text
> substitutions. The implementation, scope and style of this DSL will need to
> be workshopped and would like your comments on.
>
> b) linked text (annotations) showing a graphical link (like the blue line
> of values and reference ) A text item is created as a link to another item,
> for which the text is derived from a list of properties of that item. This
> would include such things as values, references, custom symbol and
> footprint fields, sizes, positions, net names, net codes.
>
> I'm almost certain this would require the updated Schematic object in
> eeschema, but might already be achievable in pcbnew given its current
> architecture, but that's more of a guess than anything.
>
> Any thoughts, guidance or critiques would be appreciated.
>
> Kind Regards
> Russell
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Proposed roadmap changes

[jp charras]

Le 08/03/2018 à 19:02, Ouabache Designworks a écrit :
> 
> 
> On Thu, Mar 8, 2018 at 9:47 AM, Jon Evans  > wrote:
> 
> Netlist export is a key feature of every schematic editor. So is 
> multi-sheet support. These
> aren't random extra features, they are a normal part of any modern 
> schematic editor. 
> 
> 
> 
> Yes they are necessary features. My argument is that they have little to do 
> with the core mission of
> putting graphical objects on the screen and probably would not share much 
> code with
> the rest of the program. If you add this into the main program then it only 
> makes it bigger and more
> complex. I alway go  for the simpler and cleaner approach.  Calling the 
> netlister is more
> of a design management task than a schematic editor one so it should go into 
> the Design Manager program.
> 
> John Eaton

"they have little to do with the core mission..."
This is false.
A internal netlister is mandatory in a schematic design tool at least because 
it is the key for ERC
and net highlight.
An especially for net highlight, it must be *very* fast.

-- 
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

Re: [Kicad-developers] Selection filtering, and other missing GAL functionality

[Andrzej Wolski]

Legacy-like selection filter is already present in GAL: after selecting 
- right click and choose Select -> Filter Selection.


Andrzej

W dniu 2018-03-07 o 23:20, Jon Evans pisze:

Hi all,

As part of preparing a new 6.0 roadmap, I want to make sure we have 
all functionality that only exists in Legacy mode captured on 
Launchpad so we don't forget about it.  José just reminded me that 
Legacy mode in PcbNew has some selection filtering features that don't 
exist in GAL, so selection filtering is one case where I don't think 
we currently have a launchpad bug (or at least it's not easily 
searchable or tagged with missing-gal-tool).


Are there others besides this? (and printing, obviously)
Some stuff about polygon behavior I think?

-Jon


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



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

Re: [Kicad-developers] Proposed roadmap changes

[Ouabache Designworks]

On Thu, Mar 8, 2018 at 9:47 AM, Jon Evans  wrote:

> Netlist export is a key feature of every schematic editor. So is
> multi-sheet support. These aren't random extra features, they are a normal
> part of any modern schematic editor.
>
>

Yes they are necessary features. My argument is that they have little to do
with the core mission of putting graphical objects on the screen and
probably would not share much code with
the rest of the program. If you add this into the main program then it only
makes it bigger and more complex. I alway go  for the simpler and cleaner
approach.  Calling the netlister is more
of a design management task than a schematic editor one so it should go
into the Design Manager program.

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

Re: [Kicad-developers] Proposed roadmap changes

[Tomasz Wlostowski]

On 08/03/18 18:45, Ouabache Designworks wrote:
> 
> 
> On Thu, Mar 8, 2018 at 9:21 AM, Tomasz Wlostowski
> > wrote:
> 
> 
> Please, give me a single argument what benefits Kicad would get by
> having a netlist generator as a separate program. I also asked you for
> an example of a successful graphical editing application following 'the
> unix way', but so far you've not answered my question. Does this mean
> that there isn't any?
> 
> Tom
> 
> 
> 
> EEschema is a schematic editor. You give it a schematic file, it edits
> that file and you save it. Nice simple tool.
> 
> Now you  want to tack on netlist exporting. Thats fine as long as the
> entire design is in one file but what do you do when you have a
> multisheet design?  Now you need a top sheet that contains the file
> names for all the other sheets. You have to parse out all those names,
> read those files into memory, interconnect them with the existing
> connections before writing out the netlist.  All this has nothing to do
> with editing schematics and should not be included in EEschema.

I don't see any problem with the way it's done today with multiple
sheets. The netlister starts with the root sheet and loads sub-sheets
when necessary. Making a netlist is so essential for PCB design that in
most modern packages (Kicad V5 included) it's not even visible to the user.

Imagine an audio workstation program requiring an external command line
tool just to mix down all the tracks and produce and MP3 file. Find me a
musician who would like to use it :)

> 
> 
> 
> To answer your question: I am not aware of any popular graphics editors
> that do strictly follow the unix way.

Me neither. The unix way was defined in early '70s, so it works well for
things that were invented in '70s: shell interpreters or compilers (not
all of them). If it worked well for graphical software, we would have
tons of proprietary applications following the unix principles with
crowds of happy users.


Tom

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

Re: [Kicad-developers] Proposed roadmap changes

[Jon Evans]

Netlist export is a key feature of every schematic editor. So is
multi-sheet support. These aren't random extra features, they are a normal
part of any modern schematic editor.

On Thu, Mar 8, 2018, 12:45 Ouabache Designworks  wrote:

>
>
> On Thu, Mar 8, 2018 at 9:21 AM, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
>
>>
>> Please, give me a single argument what benefits Kicad would get by
>> having a netlist generator as a separate program. I also asked you for
>> an example of a successful graphical editing application following 'the
>> unix way', but so far you've not answered my question. Does this mean
>> that there isn't any?
>>
>> Tom
>>
>>
>>
> EEschema is a schematic editor. You give it a schematic file, it edits
> that file and you save it. Nice simple tool.
>
> Now you  want to tack on netlist exporting. Thats fine as long as the
> entire design is in one file but what do you do when you have a multisheet
> design?  Now you need a top sheet that contains the file names for all the
> other sheets. You have to parse out all those names,
> read those files into memory, interconnect them with the existing
> connections before writing out the netlist.  All this has nothing to do
> with editing schematics and should not be included in EEschema.
>
>
>
> To answer your question: I am not aware of any popular graphics editors
> that do strictly follow the unix way.
>
>
> John Eaton
>
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Proposed roadmap changes

[Ouabache Designworks]

On Thu, Mar 8, 2018 at 9:21 AM, Tomasz Wlostowski  wrote:

>
> Please, give me a single argument what benefits Kicad would get by
> having a netlist generator as a separate program. I also asked you for
> an example of a successful graphical editing application following 'the
> unix way', but so far you've not answered my question. Does this mean
> that there isn't any?
>
> Tom
>
>
>
EEschema is a schematic editor. You give it a schematic file, it edits that
file and you save it. Nice simple tool.

Now you  want to tack on netlist exporting. Thats fine as long as the
entire design is in one file but what do you do when you have a multisheet
design?  Now you need a top sheet that contains the file names for all the
other sheets. You have to parse out all those names,
read those files into memory, interconnect them with the existing
connections before writing out the netlist.  All this has nothing to do
with editing schematics and should not be included in EEschema.



To answer your question: I am not aware of any popular graphics editors
that do strictly follow the unix way.


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

Re: [Kicad-developers] Proposed roadmap changes

[Ouabache Designworks]

On Thu, Mar 8, 2018 at 8:26 AM, Andy Peters  wrote:

>
> > On Mar 7, 2018, at 9:22 PM, Ouabache Designworks 
> wrote:
> >
> >
> > If you are doing a PCB with a FPGA on it then you really want that FPGA
> designer to be using kicad to design their padring. Kicad could fill this
> niche and it would make your job a lot easier.
>
> If only it was that simple. FPGA (and to some extent, microcontroller) pin
> swapping during layout is a holy grail. The problem is that it’s not as
> simple as it seems. The layout person cannot arbitrarily assign pinouts
> without understanding the specific chip I/O architecture and rules and also
> understanding the FPGA design. Our layout guy is literally on the other
> side of a low wall from me, and I hear his cursing about pin selection all
> the time!
>
>
Andy,

All of these are good points and they fall into what I call "Engineering
notes". A schematic alone is not enough information to layout a PCB. The
design engineer must also include a long list of engineering requirements
that must be meet in order for the board to actually
work. Most of these involve Signal Integrity ,EMI,ESD,Power and timing.

Kicad need to develop a language so that the design engineer can enter
these notes in a machine readable format that is passed to the Layout
programs DRC tests.



An obvious house rule is one we have at the day job: before a PCB is
> released, the FPGA tools are run on the design to ensure that you don’t get
> timing screw-ups and you don’t have illegal pin locations. The problem, of
> course, is that you need to have enough of the FPGA design done before you
> can do that, and there’s always someone with a schedule demanding that the
> board be sent out for fab before you’ve even started simulating your design.
>
>
This is opposite of the problem that we have with ASICs. The ASIC usually
leads the board development by at least one year so you might have to
design the padring before the board design team has even been staffed. This
is why you want your IC designers to be
able to do a partial design with only the major chips to find obvious
problems.

You could create a fpga design with no logic but the correct I/O pads that
toggled at the correct rates. That would let you test out your board before
the real design was ready and could even do your JTAG board testing.

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

Re: [Kicad-developers] Proposed roadmap changes

[Tomasz Wlostowski]

On 08/03/18 03:21, Ouabache Designworks wrote:
> 
> What happens if you edit a schematic, export the netlist and are
> interrupted before you can save the schematic? 

I guess in this case a crash happens sometime after the netlist export
if the user can't save the schematic anymore... Which is bad whether
it's done unix-style or not.

In Kicad, the ultimate netlist is stored in the schematic. The net
indices in PCB are derived from the schematic. Netlist is just an
intermediate file, or in the newer Kicad versions, a variable in the memory.

Please, give me a single argument what benefits Kicad would get by
having a netlist generator as a separate program. I also asked you for
an example of a successful graphical editing application following 'the
unix way', but so far you've not answered my question. Does this mean
that there isn't any?

Tom



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

Re: [Kicad-developers] Proposed roadmap changes

[Andy Peters]

On Mar 8, 2018, at 9:21 AM, Ouabache Designworks  wrote:
> 
> Why don't we run PCB layout on the schematic file and let it call the 
> netlister program every time it runs. This is a simpler process flow with 
> fewer cases where you make the user jump through hoops to get something done.

This makes a ton of sense. When working on a layout, it must match the 
schematic. 

(In the past, we had a rule. When a layout is complete, generate a new netlist 
from the schematic and import it into the layout. If layout reports no changes 
are necessary, the two are in sync and all is well.)

The netlist is just ephemeral, anyway; once it is imported into the layout it’s 
no longer necessary. The netlist is a vestige of the days when PCB CAD packages 
were a collection of disparate programs.

But … 

This action should be one way, that is, changes in the schematic should not 
force an automatic update of the layout. Consider: you made some updates to the 
schematic, and you’d like your colleagues to review it before you commit to it. 
They look at it, make suggestions, which might include not making the changes. 
If the layout automagically updated from your unreviewed changes, then you’d 
have to undo those changes in the layout.

This means that when you open the layout, it can notice that the schematic has 
changed and ask the user if it should be updated to sync with those changes. 
Because the answer might well be no, I am not ready to do that yet. Maybe you 
just want to look at the layout as it is, for whatever reason.

-a
___
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] Selection filtering, and other missing GAL functionality

[Kliment (Future Bits)]

Global spread and place?

On 07.03.2018 23:20, Jon Evans wrote:
> Hi all,
> 
> As part of preparing a new 6.0 roadmap, I want to make sure we have all
> functionality that only exists in Legacy mode captured on Launchpad so
> we don't forget about it.  José just reminded me that Legacy mode in
> PcbNew has some selection filtering features that don't exist in GAL, so
> selection filtering is one case where I don't think we currently have a
> launchpad bug (or at least it's not easily searchable or tagged with
> missing-gal-tool).
> 
> Are there others besides this? (and printing, obviously)
> Some stuff about polygon behavior I think?
> 
> -Jon
> 
> 
> ___
> 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] Deletion in plugins causing trouble

[Wayne Stambaugh]

As a short term fix, I'll allow this patch to prevent the segfaults.
However, I do not want to continue to allowing these types of ad hoc
fixes.  We should take Dick's suggestion and look at what other projects
are doing.  We cannot be the only project wrestling with this issue.

On 3/8/2018 3:59 AM, Maciej Sumiński wrote:
> In my opinion #3 is acceptable. It does not require any extra changes in
> the existing scripts and it fixes the problem until we come up with a
> better scripting interface. If nobody has objections, I am going to
> commit the patch.
> 
> Regards,
> Orson
> 
> On 03/06/2018 10:02 AM, miles mccoo wrote:
>> Thanks all for your replies.
>>
>> I like the plugin mechanism. It does some nice things for python folks.
>> Refresh, undo, garbage collection (I think). I want to see it succeed.
>>
>> From reading Orson's mail, I think I wasn't entirely clear, so let me try
>> to fix that first.
>>
>>
>> The plugin mechanism tries to track the changes of a python plugin. In the
>> c++ world, developers are expected to inform BOARD_COMMIT that something
>> has changed. The plugin infrastructure does this for you. One could compare
>> it to garbage collection. My interpretation of how this is done is simple:
>> before a plugin runs, make a list of all design objects. zones, tracks,
>> modules, nets... after the plugin completes, do a "diff".
>>
>> This is mostly fine with the exception of removed items.
>>
>> The problem with removed items is how do you do a diff on a deleted, memory
>> managed, cleaned up object? Perhaps that memory now contains a different
>> kind of object. Perhaps it's been reallocated to a similar object as before.
>>
>>
>>
>> *as it stands now, any plugin that removes items from a board item
>> container will likely fail*. It's not quite a crash, but it has a similar
>> feel to the user.
>>
>>
>>
>> Solutions. I can think of four.
>>
>> solution 1. Why is the plugin mechanism in the business of tracking
>> changes? Shouldn't BOARD_COMMIT just magically happen whenever a c++
>> instance is modified. I brought this up in a previous thread[1] and various
>> reasons were given why this isn't desirable.
>>
>> solution 2. Same as #1 except BC magic only happens on python API calls.
>> The plugin mechanism would no longer do diffs. Just add BC checkpoints.
>> This is probably a lot of work. I might be willing to do this work but it
>> would take time. [2]
>>
>> solution 3. easy to implement. turn off deletion on calls to remove if
>> currently running a plugin
>>
>>- plugin gets a boolean: isPluginActive. set/unset around the call to
>>actual python run code.
>>- add pcbnew.isPluginActive() to python api. (I could imagine this could
>>have other uses)
>>- the remove code looks at isPluginActive to decide whether to set
>>isown. (that code is actually python, not swig)
>>
>> I have #3 implemented and my plugins no longer crash. *See attached patch
>> for if folks agree it is an acceptable stopgap.*
>>
>> solution 4. probably not the direction I would go but a way to enable
>> python memory management and do the plugin diff thing. Basically, give each
>> object some sort of unique id. (could be useful for other things). In
>> addition to holding a list of object pointers, plugin infrastructure would
>> hold a list of object ids.
>>
>>
>> *Given the ease with which a plugin can hit this issue and given how long
>> it would take to get #2 right, I guess I'm recommending the changes of that
>> attached patch for #3.*
>>
>> Miles
>>
>> [1] https://lists.launchpad.net/kicad-developers/msg32063.html
>> [2] I think my personal opinion is that #1 is superior over #2. Python
>> people shouldn't have to care but why is it that c++ should or want to?
>> Yes, I read the arguments from the previous thread but I'm not convinced.
>> I'm also just a kicad spectator, so there's a lot I don't know.
>>
>>
>>
>>
>>
>> On Fri, Mar 2, 2018 at 2:47 PM, Wayne Stambaugh 
>> wrote:
>>
>>> LOL, I just replied to Miles.  Thanks Orson for helping out!
>>>
>>> On 3/2/2018 8:36 AM, Maciej Sumiński wrote:
 Hi Miles,

 I suppose the silence in the thread indicates there are not many
 developers knowing the Python scripting interface inside out. Since you
 are both studying the scripting interface and developing own scripts, it
 is quite possible you are the most competent person to give us an advice
 on how to proceed. See some comments below, but I am neither a Python
 script developer nor a scripting interface maintainer, so I might be
 lacking some basic knowledge here.

 On 02/28/2018 05:12 PM, miles mccoo wrote:
> So I'm plugin-ifying my python scripts (the mechanism is awesome). One
>>> of
> the plugins deletes some stuff and that is causing trouble.
>
>
>
> I'm not sure how to fix the root cause. Hence this mail.
>
>
>
> The plugin just deletes Edge.Cuts[1]:
> for d in 

Re: [Kicad-developers] Proposed roadmap changes

[Andy Peters]

> On Mar 7, 2018, at 9:22 PM, Ouabache Designworks  wrote:
> 
> 
> If you are doing a PCB with a FPGA on it then you really want that FPGA 
> designer to be using kicad to design their padring. Kicad could fill this 
> niche and it would make your job a lot easier.

If only it was that simple. FPGA (and to some extent, microcontroller) pin 
swapping during layout is a holy grail. The problem is that it’s not as simple 
as it seems. The layout person cannot arbitrarily assign pinouts without 
understanding the specific chip I/O architecture and rules and also 
understanding the FPGA design. Our layout guy is literally on the other side of 
a low wall from me, and I hear his cursing about pin selection all the time!

Some examples of why this is not so straightforward.

a) The obvious one is clock inputs. They have to be on specific pins if one 
wants the best routing from the pin to the internal clock buffer, and if one 
wants to take advantage of advanced clocking features (DLLs, PLLs, input 
delays).

b) FPGAs have rules about differential pairs. Pins on specific banks are 
differential inputs or outputs only, pins on other banks can be both. Some have 
internal termination on certain pairs, others don’t. Bank I/O voltage is 
important, so you can’t move the pair to another bank with a different supply.

c) Mind the bank supplies for your signals. You can’t put a 3.3 V signal on a 
2.5 V bank. The schematic and layout tools don’t have a “net type” attribute 
that says, “This is an LVCMOS33 signal” which would bark at you if you tried to 
connect it to a pin that had an LVCMOS25 type attribute. It would be great if 
such a feature existed. 

d) Regional clock inputs require that all of the things that might use that 
clock be constrained to be in the clock region — and the region and the I/O 
bank don’t necessarily map to each other. And the layout person might not 
realize that a pin even needs to be in a specific region. And how would he know 
that a specific pin is in the right region?

e) Lattice MachXO2 (to use a recent example) has limitations on the total 
output current for pins on a bank. It’s not straightforward. The good news is 
that their fitter tool complains if the bank is overloaded. The less good news 
is that there’s no obvious way to communicate that information to the layout. 
Schematic and layout don’t know about pin loading, for example. While pin 
loading could be (and in some high-end schematic tools, is) part of the DRC, 
this particular Lattice constraint would need to have some code that does the 
test.

f) Specialist features such as gigabit serializers and deserializers, memory 
interfaces, and the like, simply cannot be swapped.

An obvious house rule is one we have at the day job: before a PCB is released, 
the FPGA tools are run on the design to ensure that you don’t get timing 
screw-ups and you don’t have illegal pin locations. The problem, of course, is 
that you need to have enough of the FPGA design done before you can do that, 
and there’s always someone with a schedule demanding that the board be sent out 
for fab before you’ve even started simulating your design.

So if we’re talking pie-in-the-sky wish-list: Kicad should have a plug-in that 
can read and parse FPGA constraint files and “know” the FPGA symbol pin names 
and attributes. And after the swapping, which will automatically update the 
schematic, and which has ERC of some sort enforced, Kicad will update the 
constraint file with the new pin assignments.

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

Re: [Kicad-developers] Proposed roadmap changes

[Ouabache Designworks]

On Wed, Mar 7, 2018 at 11:59 PM, Russell Oliver 
wrote:

> From what I am reading John your call for acting on the files on disk
> instead of memory is a call for a clear demarcation of actions that need to
> be irrevocable and require the project data to be consistent.
>
> In my opinion this doesn't necessarily require separate programs, just
> consistent checks on the current state of the project and its data. A check
> and dialog box to force the user to save the all schematic sheets before
> exporting the netlist might be sufficient.
>
> Likewise saving the pcb after changing say a selected footprint or
> changing the reference or value of a component, would force a back
> annotation of the schematic which would also be saved. A change would not
> be allowed to persist without it being consistently applied across the
> project.
>
>
>
>
True, You can simply check for unsaved changes and refuse to export the
netlist until after the user saves the schematic. But what do you do if
they save the schematic but do not export the netlist? Pcb layout will see
that the netlist file is older than the
schematic and this means it might be out of date. Do you refuse to do the
layout until the user goes back and corrects it? Do you run a netlist
program and fix it without telling the user? You give the user the option
to export a netlist or not but if they don't
then you won't let them continue until they do. No wonder people hate
computers.



Why don't we run PCB layout on the schematic file and let it call the
netlister program every time it runs. This is a simpler process flow with
fewer cases where you make the user jump through hoops to get something
done.

John Eaton
___
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] Selection filtering, and other missing GAL functionality

[easyw]

it would be possible to add 'Vias' to selection filtering?
That would be useful for deleting a Via stitching zone, without touching 
tracks


Thx

On 03/08/2018 12:03 AM, Tomasz Wlostowski wrote:

On 07/03/18 23:59, Jeff Young wrote:

Drag Footprint.


Working on that :)

Don't expect miracles, but basic P footprint dragging should be in
early V6.

Tom



On 7 Mar 2018, at 22:20, Jon Evans  wrote:

Hi all,

As part of preparing a new 6.0 roadmap, I want to make sure we have all 
functionality that only exists in Legacy mode captured on Launchpad so we don't 
forget about it.  José just reminded me that Legacy mode in PcbNew has some 
selection filtering features that don't exist in GAL, so selection filtering is 
one case where I don't think we currently have a launchpad bug (or at least 
it's not easily searchable or tagged with missing-gal-tool).

Are there others besides this? (and printing, obviously)
Some stuff about polygon behavior I think?

-Jon
___
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] Board Edge clearance problem

[Nick Østergaard]

I guess this is about https://bugs.launchpad.net/kicad/+bug/1753904

2018-03-08 14:27 GMT+01:00 Strontium :

> On 07/03/18 18:25, Tomasz Wlostowski wrote:
>
>> On 07/03/18 06:34, Strontium wrote:
>>
>>> My second "show stopper" bug for me, using V5 RC2
>>>
>>> I also reported this in the bug tracker, again sorry for the double up.
>>>
>>> I was trying to layout a board, but Kicad is refusing to let me lay
>>> tracks or vias in close proximity to the board edge.  Its highlighting
>>> the edge, and ignoring any command to drop the via or track segment.
>>>
>>> Two questions:
>>
>> - what's the default track clearance in your design?
>> - could you send us (in private) the board file?
>>
>> Tom
>>
>> Hi Tom,
>
> I just was preparing to send the board, and tested again, and it seems in
> todays update of the nightly PPA the behaviour has changed.  Its no longer
> doing what I reported. So, it would appear that its problem solved.
>
> If you still need me to send the board, let me know.  My clearance is
> 0.1524, for everything. And my edge cut is 0.1mm.
>
> Steven
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Proposed roadmap changes

[Chris Gammell]

>
> Are these users professional users who are using KiCad at there day job
> and is there any way to confirm this?
>

It's self reporting, but their email domains, LinkedIn profiles and product
listings seem to bear it out


> I am currently surveying that group and will be returning with some
> > recommendations. I'm also asking if they would be interested in telling
> > their stories to the development team when asked as part of the survey.
>
> Thank you for gathering this information rather than having 40 users
> bombarding the developers mailing list.  I appreciate the effort in
> putting this information together.  I'm willing to listen to user
> experience once v5 is out.  I am swamped at the moment and I don't want
> users feel that they don't have my full attention.
>

No problem! I used to do product management and I recall the competing
interests of what individual voices want vs what is good for the project vs
what needs to be fixed in the immediate future from an infrastructure
perspective. I'm super excited about v5 (and beyond) and I'm happy to help
coordinate community efforts however I can.

If there are other groups we should target on a community feedback level
(hobbyist, academic, enterprise) and people would be interested in heading
up those kinds of groups, I'd be happy to coordinate, either through email
lists or the user forum.

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

Re: [Kicad-developers] Board Edge clearance problem

[Strontium]

On 07/03/18 18:25, Tomasz Wlostowski wrote:

On 07/03/18 06:34, Strontium wrote:

My second "show stopper" bug for me, using V5 RC2

I also reported this in the bug tracker, again sorry for the double up.

I was trying to layout a board, but Kicad is refusing to let me lay
tracks or vias in close proximity to the board edge.  Its highlighting
the edge, and ignoring any command to drop the via or track segment.


Two questions:

- what's the default track clearance in your design?
- could you send us (in private) the board file?

Tom


Hi Tom,

I just was preparing to send the board, and tested again, and it seems 
in todays update of the nightly PPA the behaviour has changed.  Its no 
longer doing what I reported. So, it would appear that its problem solved.


If you still need me to send the board, let me know.  My clearance is 
0.1524, for everything. And my edge cut is 0.1mm.


Steven


___
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] Deletion in plugins causing trouble

[Maciej Sumiński]

In my opinion #3 is acceptable. It does not require any extra changes in
the existing scripts and it fixes the problem until we come up with a
better scripting interface. If nobody has objections, I am going to
commit the patch.

Regards,
Orson

On 03/06/2018 10:02 AM, miles mccoo wrote:
> Thanks all for your replies.
> 
> I like the plugin mechanism. It does some nice things for python folks.
> Refresh, undo, garbage collection (I think). I want to see it succeed.
> 
> From reading Orson's mail, I think I wasn't entirely clear, so let me try
> to fix that first.
> 
> 
> The plugin mechanism tries to track the changes of a python plugin. In the
> c++ world, developers are expected to inform BOARD_COMMIT that something
> has changed. The plugin infrastructure does this for you. One could compare
> it to garbage collection. My interpretation of how this is done is simple:
> before a plugin runs, make a list of all design objects. zones, tracks,
> modules, nets... after the plugin completes, do a "diff".
> 
> This is mostly fine with the exception of removed items.
> 
> The problem with removed items is how do you do a diff on a deleted, memory
> managed, cleaned up object? Perhaps that memory now contains a different
> kind of object. Perhaps it's been reallocated to a similar object as before.
> 
> 
> 
> *as it stands now, any plugin that removes items from a board item
> container will likely fail*. It's not quite a crash, but it has a similar
> feel to the user.
> 
> 
> 
> Solutions. I can think of four.
> 
> solution 1. Why is the plugin mechanism in the business of tracking
> changes? Shouldn't BOARD_COMMIT just magically happen whenever a c++
> instance is modified. I brought this up in a previous thread[1] and various
> reasons were given why this isn't desirable.
> 
> solution 2. Same as #1 except BC magic only happens on python API calls.
> The plugin mechanism would no longer do diffs. Just add BC checkpoints.
> This is probably a lot of work. I might be willing to do this work but it
> would take time. [2]
> 
> solution 3. easy to implement. turn off deletion on calls to remove if
> currently running a plugin
> 
>- plugin gets a boolean: isPluginActive. set/unset around the call to
>actual python run code.
>- add pcbnew.isPluginActive() to python api. (I could imagine this could
>have other uses)
>- the remove code looks at isPluginActive to decide whether to set
>isown. (that code is actually python, not swig)
> 
> I have #3 implemented and my plugins no longer crash. *See attached patch
> for if folks agree it is an acceptable stopgap.*
> 
> solution 4. probably not the direction I would go but a way to enable
> python memory management and do the plugin diff thing. Basically, give each
> object some sort of unique id. (could be useful for other things). In
> addition to holding a list of object pointers, plugin infrastructure would
> hold a list of object ids.
> 
> 
> *Given the ease with which a plugin can hit this issue and given how long
> it would take to get #2 right, I guess I'm recommending the changes of that
> attached patch for #3.*
> 
> Miles
> 
> [1] https://lists.launchpad.net/kicad-developers/msg32063.html
> [2] I think my personal opinion is that #1 is superior over #2. Python
> people shouldn't have to care but why is it that c++ should or want to?
> Yes, I read the arguments from the previous thread but I'm not convinced.
> I'm also just a kicad spectator, so there's a lot I don't know.
> 
> 
> 
> 
> 
> On Fri, Mar 2, 2018 at 2:47 PM, Wayne Stambaugh 
> wrote:
> 
>> LOL, I just replied to Miles.  Thanks Orson for helping out!
>>
>> On 3/2/2018 8:36 AM, Maciej Sumiński wrote:
>>> Hi Miles,
>>>
>>> I suppose the silence in the thread indicates there are not many
>>> developers knowing the Python scripting interface inside out. Since you
>>> are both studying the scripting interface and developing own scripts, it
>>> is quite possible you are the most competent person to give us an advice
>>> on how to proceed. See some comments below, but I am neither a Python
>>> script developer nor a scripting interface maintainer, so I might be
>>> lacking some basic knowledge here.
>>>
>>> On 02/28/2018 05:12 PM, miles mccoo wrote:
 So I'm plugin-ifying my python scripts (the mechanism is awesome). One
>> of
 the plugins deletes some stuff and that is causing trouble.



 I'm not sure how to fix the root cause. Hence this mail.



 The plugin just deletes Edge.Cuts[1]:
 for d in board.GetDrawings():
 if (d.GetLayerName() == 'Edge.Cuts'):
 board.Remove(d)



 in board_item_container.i, I see this (with stuff deleted):
 %rename(RemoveNative)BOARD_ITEM_CONTAINER::Remove;
 def Remove(self,item):
 self.RemoveNative(item)
 item.thisown=1


 Setting thisown tells, python "you own it". Delete it when you're 

Re: [Kicad-developers] Handling invalid characters in symbol/component LIB_IDs

[Maciej Sumiński]

On 03/06/2018 07:34 PM, Wayne Stambaugh wrote:
> Orson,
> 
> On 3/6/2018 8:55 AM, Maciej Sumiński wrote:
>> I am trying to find a reasonable way to handle symbol and components
>> with invalid characters in their LIB_IDs (see bug report #1752419 [1]).
>> While now it is impossible to create such LIB_IDs, we need to handle
>> documents that had been created before the restriction was introduced.
>>
>> LIB_IDs in SCH_COMPONENTS will have illegal characters replaced on load,
>> but it is not the case for LIB_{PART,ALIAS} classes. Due to that:
>>
>> - Symbol-component links are broken (e.g. component with LIB_ID
>> 'Test/Name' will change to 'Test_Name', but the corresponding LIB_PART
>> will remain 'Test/Name'.
>>
>> - It is impossible to place/edit such symbols.
>>
>> The simplest solution is to process LIB_{PART,ALIAS} LIB_IDs in the same
>> way as id done for SCH_COMPONENTs, so they become valid names that match
>> SCH_COMPONENTs using them (see the attached patches). There are two
>> drawbacks:
> 
> I would prefer to keep the behavior consistent with what is done with
> the SCH_COMPONENT LIB_ID renaming.  I know it's less than elegant but we
> are going to just have to take our medicine until we transition over to
> the new file format.

That is what I am thinking as well, so I have coded it this way in the
patches.

>> - Changing names that user had previously assigned, which might be
>> annoying if LIB_IDs are used e.g. to create BOMs. Personally I would use
>> the value field that accepts all characters for this purpose.
> 
> Can LIB_IDs be used in BOMs?  That would be an odd way to do it but I
> suppose you could.  Typically the contents of the value field is used
> for BOM output not the symbol name.
> 
>>
>> - Naming conflicts may occur (e.g. both 'Test/Name' and 'Test:Name' will
>> be changed to 'Test_Name', but I believe it is a rare case.
> 
> I just used a simple counter to append digits to the end of the name in
> the case of name conflicts in the remapping code so a similar approach
> here would not be out of line.

Good point, implemented and pushed to the master branch.

Cheers,
Orson

>> Any thoughts? I believe a more elegant solution will be implemented once
>> the new schematic file format is ready.
> 
> The current behavior is just going to last during v5.  Once the new
> schematic file format is done and the LIB_ID parser and formatter
> support escaping the / and : characters, we should be able to use any
> character (except for control characters) in LIB_IDs.
> 
>>
>> Cheers,
>> Orson
>>
>> 1. https://bugs.launchpad.net/kicad/+bug/1752419
>>
>>
>>
>> ___
>> 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] Proposed roadmap changes

[Russell Oliver]

>From what I am reading John your call for acting on the files on disk
instead of memory is a call for a clear demarcation of actions that need to
be irrevocable and require the project data to be consistent.

In my opinion this doesn't necessarily require separate programs, just
consistent checks on the current state of the project and its data. A check
and dialog box to force the user to save the all schematic sheets before
exporting the netlist might be sufficient.

Likewise saving the pcb after changing say a selected footprint or changing
the reference or value of a component, would force a back annotation of the
schematic which would also be saved. A change would not be allowed to
persist without it being consistently applied across the project.






On Thu, 8 Mar 2018 15:22 Ouabache Designworks,  wrote:

>
>
> On Wed, Mar 7, 2018 at 8:01 PM, José Ignacio 
> wrote:
>
>> The separate program issue is just an implementation detail. The main
>> thing that Kicad is headed for is the refactoring slated for the 6.0 dev
>> cycle. The cleaner data structure foundation and subsequent decoupling of
>> the logic from the UI classes will allow all sorts of automation that are
>> currently very hard or impossible. The vision that was set since over 5
>> years ago was for Kicad to present a library-like interface to the outside
>> world. It kind of does now on PCBnew only, but things are slowly improving
>> as things get refactored and legacy code gets phased out.
>>
>> I honestly think the last thing Kicad needs right now is a chance of
>> direction, I speak as a user that has been using Kicad professionally for
>> just over 2 years now, working on dozens of PCB projects over that time.
>> The developments in the past few years have been nothing but awesome for a
>> project with Kicad's resources. We just need to be patient, or try to help
>> out in a constructive manner.
>>
>> Over the past couple years I have been using the dev version in
>> production to take advantage of the new features (dealing with
>> versions/instability was a small price to pay for me), I also helped a
>> little bit (as time allowed) with the occasional patch or grumpy bug
>> report. I'd like to thank everyone that has worked on the project so far;
>> It basically has made it possible for me to make a living doing what I
>> enjoy, and I really hope the project can retain the momentum it has built
>> up in the past few months, it just keeps getting better!
>>
>> Thanks,
>> Jose
>>
>>
>>
>
> Nothing that I am asking for is a change of direction. Instead of calling
> a function that operates on data in memory you call a program that operates
> on the same data in the file system.
> You see the same menu pick either way. This will fit in with the
> refactoring.
>
> If you are doing a PCB with a FPGA on it then you really want that FPGA
> designer to be using kicad to design their padring. Kicad could fill this
> niche and it would make your job a lot
> easier.
>
> John Eaton
>
>
> ___
> 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