Re: [Kicad-developers] RTree implementation

[Seth Hillbrand]

Am 2018-10-23 15:36, schrieb Wayne Stambaugh:

On 10/23/2018 3:01 PM, Seth Hillbrand wrote:

Am 2018-10-23 14:44, schrieb Wayne Stambaugh:

I attempted to test this and ran into a dead end.  I was running into 
an

out of memory error attempting to load the pcbnew.kiface with a full
debug build so I had to build with -DBUILD_SMALL_DEBUG_FILES=ON to 
even
run pcbnew.  I followed your steps above and when I attempted to 
import

the video demo netlist, kicad crashed spectacularly.


Thanks Wayne!  That's the fault I was concerned about.  If you rebuild
with -DCMAKE_CXX_FLAGS="-O2 -ffloat-store" and the same other options,
does the crash resolve?

-S


It doesn't crash with -ffloat-store enabled.  I didn't do any further
testing so I cannot say anything about it's robustness but it seems 
like

a workable solution.


OK, I've pushed this to both master and 5.0.  Let me know if anyone sees 
any issues as a result.


Simon, I'm not sure what the equivalent flag for MSVC is, or even if 
this affects the MSVC builds.  Any thoughts on this would be 
appreciated.


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

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

[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] [PATCH] Fuzzable PCB parsing test harness

[Adam Wolf]

The Mac build was broken last night, a rebuild this morning didn't help,
but I'll trigger another one now and see how it goes.

Thanks folks!

On Tue, Oct 23, 2018, 5:44 PM Wayne Stambaugh  wrote:

> Fixes the linux build.  Yeah!!
>
> On 10/23/18 6:37 PM, Seth Hillbrand wrote:
> > Am 2018-10-23 17:48, schrieb Jeff Young:
> >>> … Let's just hope the macos build doesn't choke.
> >>
> >> He he.  And it did. :)
> >>
> >> I think I fixed it but someone might want to check that I didn’t do
> >> something stupid.
> >>
> >>
> https://git.launchpad.net/kicad/commit/?id=4061f1cce3b177ceca894fd2f01e0eedd928273b
> >>
> >
> > Just needed a little tweak
> >
> > 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

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

[Miguel Angel Ajo]

See 


Changes:

[jeff] Fix build issue on OSX.

[hillbrand] Prevent excess precision errors on 32-bit builds

--
[...truncated 145.92 KB...]
[ 85%] Built target qa_utils
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_dxf/dialog_dxf_import_base.cpp.o
[ 85%] Built target kicad
Scanning dependencies of target idf2vrml
[ 85%] Building CXX object utils/idftools/CMakeFiles/idf2vrml.dir/idf2vrml.cpp.o
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_dxf/dxf2brd_items.cpp.o
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/autorouter/rect_placement/rect_placement.cpp.o
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/autorouter/spread_footprints.cpp.o
[ 85%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/hierarch.cpp.o
[ 85%] Linking CXX executable idf2vrml
[ 85%] Built target idf2vrml
Scanning dependencies of target kicad-ogltest
[ 85%] Building CXX object 
utils/kicad-ogltest/CMakeFiles/kicad-ogltest.dir/kicad-ogltest.cpp.o
Scanning dependencies of target qa_common
[ 85%] Building CXX object qa/common/CMakeFiles/qa_common.dir/common_mocks.cpp.o
[ 85%] Building CXX object qa/common/CMakeFiles/qa_common.dir/test_module.cpp.o
[ 85%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/highlight_connection.cpp.o
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/autorouter/ar_autoplacer.cpp.o
[ 85%] Building CXX object 
qa/common/CMakeFiles/qa_common.dir/test_hotkey_store.cpp.o
[ 85%] Linking CXX executable kicad-ogltest
[ 85%] Built target kicad-ogltest
Scanning dependencies of target qa_pcb_parse_input
[ 85%] Building CXX object 
qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/__/qa_utils/mocks.cpp.o
[ 85%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/hotkeys.cpp.o
[ 85%] Building CXX object qa/common/CMakeFiles/qa_common.dir/test_utf8.cpp.o
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/autorouter/ar_matrix.cpp.o
[ 85%] Building CXX object 
qa/common/CMakeFiles/qa_common.dir/geometry/test_fillet.cpp.o
[ 85%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/lib_arc.cpp.o
[ 85%] Linking CXX executable qa_common
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/autorouter/autoplacer_tool.cpp.o
[ 85%] Building CXX object 
qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/main.cpp.o
[ 85%] Built target qa_common
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/action_plugin.cpp.o
[ 85%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_bezier.cpp.o
:88:1:
 error: cannot convert 'const wxStringCharType* {aka const wchar_t*}' to 'const 
char*' in initialization
 };
 ^
:88:1:
 error: cannot convert 'const wxStringCharType* {aka const wchar_t*}' to 'const 
char*' in initialization
:88:1:
 error: cannot convert 'const wxStringCharType* {aka const wchar_t*}' to 'const 
char*' in initialization
qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/build.make:86: recipe for 
target 'qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/main.cpp.o' failed
make[2]: *** [qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/main.cpp.o] 
Error 1
CMakeFiles/Makefile2:3400: recipe for target 
'qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/all' failed
make[1]: *** [qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/append_board_to_current.cpp.o
[ 85%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_circle.cpp.o
[ 85%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/array_creator.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/attribut.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/block.cpp.o
[ 86%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_collectors.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/block_footprint_editor.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/board_netlist_updater.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/build_BOM_from_board.cpp.o
[ 86%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_draw_item.cpp.o
[ 86%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_field.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/connect.cpp.o
[ 86%] Building CXX object 

Re: [Kicad-developers] [PATCH] Fuzzable PCB parsing test harness

[Wayne Stambaugh]

Fixes the linux build.  Yeah!!

On 10/23/18 6:37 PM, Seth Hillbrand wrote:

Am 2018-10-23 17:48, schrieb Jeff Young:

… Let's just hope the macos build doesn't choke.


He he.  And it did. :)

I think I fixed it but someone might want to check that I didn’t do
something stupid.

https://git.launchpad.net/kicad/commit/?id=4061f1cce3b177ceca894fd2f01e0eedd928273b 



Just needed a little tweak

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

Re: [Kicad-developers] [PATCH] Fuzzable PCB parsing test harness

[Seth Hillbrand]

Am 2018-10-23 17:48, schrieb Jeff Young:

… Let's just hope the macos build doesn't choke.


He he.  And it did. :)

I think I fixed it but someone might want to check that I didn’t do
something stupid.

https://git.launchpad.net/kicad/commit/?id=4061f1cce3b177ceca894fd2f01e0eedd928273b


Just needed a little tweak

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

Re: [Kicad-developers] [PATCH] Fuzzable PCB parsing test harness

[Wayne Stambaugh]

On 10/23/18 5:48 PM, Jeff Young wrote:

 > … Let's just hope the macos build doesn't choke.

He he.  And it did. :)

I think I fixed it but someone might want to check that I didn’t do 
something stupid.


https://git.launchpad.net/kicad/commit/?id=4061f1cce3b177ceca894fd2f01e0eedd928273b

Cheers,
Jeff.


Nope!  I'm getting this on my linux build:

/home/wayne/src/kicad-trunk/qa/pcb_parse_input/main.cpp:88:1: error: 
cannot convert ‘const wxStringCharType* {aka const wchar_t*}’ to ‘const 
char*’ in initialization

 };
 ^
/home/wayne/src/kicad-trunk/qa/pcb_parse_input/main.cpp:88:1: error: 
cannot convert ‘const wxStringCharType* {aka const wchar_t*}’ to ‘const 
char*’ in initialization
/home/wayne/src/kicad-trunk/qa/pcb_parse_input/main.cpp:88:1: error: 
cannot convert ‘const wxStringCharType* {aka const wchar_t*}’ to ‘const 
char*’ in initialization
qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/build.make:86: 
recipe for target 
'qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/main.cpp.o' failed
make[2]: *** 
[qa/pcb_parse_input/CMakeFiles/qa_pcb_parse_input.dir/main.cpp.o] E





On 22 Oct 2018, at 18:32, Wayne Stambaugh > wrote:


No problem.  I have gone through this exercise a few times myself.
Let's just hope the macos build doesn't choke.

On 10/22/2018 1:30 PM, John Beard wrote:

Thanks, Wayne! Sorry for all the drama with it. Hopefully I can learn
from it for the libcommon tests.

Cheers,

John
On Mon, Oct 22, 2018 at 6:14 PM Wayne Stambaugh > wrote:


It's merged.  Thanks John.

On 10/22/2018 1:09 PM, John Beard wrote:

Hi Wayne,

Hurray!

No extras needed, this should be ready to merge. There are additional
things we can do to enable testing of PLUGINs as opposed to the PCB
parser, but this at least provides the base to build on. This commit
is self-contained and includes the fuzzing documentation.

Cheers,

John
On Mon, Oct 22, 2018 at 5:45 PM Wayne Stambaugh 
mailto:stambau...@gmail.com>> wrote:


Hey John,

Finally!  That was easy.  I'm guessing this is ready to merge or is
there anything else that needs to be done?

Cheers,

Wayne

On 10/22/2018 12:19 PM, John Beard wrote:

Hi Wayne,

Hmm, didn't expect that to be an issue! Try a ToStdString() for size?

Cheers,

John
On Mon, Oct 22, 2018 at 2:39 PM Wayne Stambaugh 
mailto:stambau...@gmail.com>> wrote:


Hey John,

You not giving up on this are you ;).  I builds fine for mingw32 and
passes all of the tests.  However, the mingw64 build fails with:

C:/msys64/home/wstambaugh/src/kicad-trunk/qa/pcb_parse_input/main.cpp:
In function 'int main(int, char**)':
C:/msys64/home/wstambaugh/src/kicad-trunk/qa/pcb_parse_input/main.cpp:148:32:
error: call of overloaded 'open(const wxString&)' is ambiguous
fin.open( filename );
   ^
In file included from
C:/msys64/home/wstambaugh/src/kicad-trunk/qa/qa_utils/stdstream_line_reader.h:32,
from
C:/msys64/home/wstambaugh/src/kicad-trunk/qa/pcb_parse_input/main.cpp:32:
C:/msys64/mingw64/include/c++/8.2.0/fstream:653:7: note: candidate:
'void std::basic_ifstream<_CharT, _Traits>::open(const char*,
std::ios_base::openmode) [with _CharT = char; _Traits =
std::char_traits; std::ios_base::openmode = 
std::_Ios_Openmode]'
  open(const char* __s, ios_base::openmode __mode = 
ios_base::in)

  ^~~~
C:/msys64/mingw64/include/c++/8.2.0/fstream:673:7: note: candidate:
'void std::basic_ifstream<_CharT, _Traits>::open(const wchar_t*,
std::ios_base::openmode) [with _CharT = char; _Traits =
std::char_traits; std::ios_base::openmode = 
std::_Ios_Openmode]'
  open(const wchar_t* __s, ios_base::openmode __mode = 
ios_base::in)

  ^~~~

On 10/22/2018 4:57 AM, John Beard wrote:

Hi Wayne,

Since I'm out of better ideas and can't replicate the link 
failure on
Jenkins, here's a patch that uses the long list from 
pcb_test_window.
Presumably it's there for some reason, though there is no 
comment or

Git log clue that I can see.

Could you see if that works for you?

Cheers,

John
On Fri, Oct 19, 2018 at 12:09 PM John Beard 
mailto:john.j.be...@gmail.com>> wrote:


Hi Wayne,

That's pretty odd, the incantations are practically the same.

The only other difference between this and the other pcb-based
programs is this line:

   add_dependencies( pnsrouter pcbcommon pcad2kicadpcb
${GITHUB_PLUGIN_LIBRARIES} )

Which I can't really see making the difference (I think it's 
there for

a header dependency).

And the very long target_link_libraries list that lists 
everything 4
times and then a bit more. I thing replicating that long list 
might

fix it, but it doesn't seem very tidy. The list from test_window:

polygon pnsrouter common pcbcommon bitmaps polygon pnsrouter
common pcbcommon bitmaps polygon pnsrouter common pcbcommon 
bitmaps
polygon pnsrouter common pcbcommon 3d-viewer bitmaps gal 
pcad2kicadpcb

common

Cheers,

John
On Thu, Oct 18, 2018 at 2:22 PM Wayne Stambaugh 

Re: [Kicad-developers] [PATCH] Fuzzable PCB parsing test harness

[Jeff Young]

> … Let's just hope the macos build doesn't choke.

He he.  And it did. :)

I think I fixed it but someone might want to check that I didn’t do something 
stupid.

https://git.launchpad.net/kicad/commit/?id=4061f1cce3b177ceca894fd2f01e0eedd928273b
 


Cheers,
Jeff.


> On 22 Oct 2018, at 18:32, Wayne Stambaugh  wrote:
> 
> No problem.  I have gone through this exercise a few times myself.
> Let's just hope the macos build doesn't choke.
> 
> On 10/22/2018 1:30 PM, John Beard wrote:
>> Thanks, Wayne! Sorry for all the drama with it. Hopefully I can learn
>> from it for the libcommon tests.
>> 
>> Cheers,
>> 
>> John
>> On Mon, Oct 22, 2018 at 6:14 PM Wayne Stambaugh  wrote:
>>> 
>>> It's merged.  Thanks John.
>>> 
>>> On 10/22/2018 1:09 PM, John Beard wrote:
 Hi Wayne,
 
 Hurray!
 
 No extras needed, this should be ready to merge. There are additional
 things we can do to enable testing of PLUGINs as opposed to the PCB
 parser, but this at least provides the base to build on. This commit
 is self-contained and includes the fuzzing documentation.
 
 Cheers,
 
 John
 On Mon, Oct 22, 2018 at 5:45 PM Wayne Stambaugh  
 wrote:
> 
> Hey John,
> 
> Finally!  That was easy.  I'm guessing this is ready to merge or is
> there anything else that needs to be done?
> 
> Cheers,
> 
> Wayne
> 
> On 10/22/2018 12:19 PM, John Beard wrote:
>> Hi Wayne,
>> 
>> Hmm, didn't expect that to be an issue! Try a ToStdString() for size?
>> 
>> Cheers,
>> 
>> John
>> On Mon, Oct 22, 2018 at 2:39 PM Wayne Stambaugh  
>> wrote:
>>> 
>>> Hey John,
>>> 
>>> You not giving up on this are you ;).  I builds fine for mingw32 and
>>> passes all of the tests.  However, the mingw64 build fails with:
>>> 
>>> C:/msys64/home/wstambaugh/src/kicad-trunk/qa/pcb_parse_input/main.cpp:
>>> In function 'int main(int, char**)':
>>> C:/msys64/home/wstambaugh/src/kicad-trunk/qa/pcb_parse_input/main.cpp:148:32:
>>> error: call of overloaded 'open(const wxString&)' is ambiguous
>>> fin.open( filename );
>>>^
>>> In file included from
>>> C:/msys64/home/wstambaugh/src/kicad-trunk/qa/qa_utils/stdstream_line_reader.h:32,
>>> from
>>> C:/msys64/home/wstambaugh/src/kicad-trunk/qa/pcb_parse_input/main.cpp:32:
>>> C:/msys64/mingw64/include/c++/8.2.0/fstream:653:7: note: candidate:
>>> 'void std::basic_ifstream<_CharT, _Traits>::open(const char*,
>>> std::ios_base::openmode) [with _CharT = char; _Traits =
>>> std::char_traits; std::ios_base::openmode = std::_Ios_Openmode]'
>>>   open(const char* __s, ios_base::openmode __mode = ios_base::in)
>>>   ^~~~
>>> C:/msys64/mingw64/include/c++/8.2.0/fstream:673:7: note: candidate:
>>> 'void std::basic_ifstream<_CharT, _Traits>::open(const wchar_t*,
>>> std::ios_base::openmode) [with _CharT = char; _Traits =
>>> std::char_traits; std::ios_base::openmode = std::_Ios_Openmode]'
>>>   open(const wchar_t* __s, ios_base::openmode __mode = ios_base::in)
>>>   ^~~~
>>> 
>>> On 10/22/2018 4:57 AM, John Beard wrote:
 Hi Wayne,
 
 Since I'm out of better ideas and can't replicate the link failure on
 Jenkins, here's a patch that uses the long list from pcb_test_window.
 Presumably it's there for some reason, though there is no comment or
 Git log clue that I can see.
 
 Could you see if that works for you?
 
 Cheers,
 
 John
 On Fri, Oct 19, 2018 at 12:09 PM John Beard  
 wrote:
> 
> Hi Wayne,
> 
> That's pretty odd, the incantations are practically the same.
> 
> The only other difference between this and the other pcb-based
> programs is this line:
> 
>add_dependencies( pnsrouter pcbcommon pcad2kicadpcb
> ${GITHUB_PLUGIN_LIBRARIES} )
> 
> Which I can't really see making the difference (I think it's there for
> a header dependency).
> 
> And the very long target_link_libraries list that lists everything 4
> times and then a bit more. I thing replicating that long list might
> fix it, but it doesn't seem very tidy. The list from test_window:
> 
> polygon pnsrouter common pcbcommon bitmaps polygon pnsrouter
> common pcbcommon bitmaps polygon pnsrouter common pcbcommon bitmaps
> polygon pnsrouter common pcbcommon 3d-viewer bitmaps gal pcad2kicadpcb
> common
> 
> Cheers,
> 
> John
> On Thu, Oct 18, 2018 at 2:22 PM Wayne Stambaugh 
>  wrote:
>> 
>> Hey John,
>> 

Re: [Kicad-developers] RTree implementation

[Wayne Stambaugh]

On 10/23/2018 3:01 PM, Seth Hillbrand wrote:
> Am 2018-10-23 14:44, schrieb Wayne Stambaugh:
> 
>> I attempted to test this and ran into a dead end.  I was running into an
>> out of memory error attempting to load the pcbnew.kiface with a full
>> debug build so I had to build with -DBUILD_SMALL_DEBUG_FILES=ON to even
>> run pcbnew.  I followed your steps above and when I attempted to import
>> the video demo netlist, kicad crashed spectacularly.
> 
> Thanks Wayne!  That's the fault I was concerned about.  If you rebuild
> with -DCMAKE_CXX_FLAGS="-O2 -ffloat-store" and the same other options,
> does the crash resolve?
> 
> -S

It doesn't crash with -ffloat-store enabled.  I didn't do any further
testing so I cannot say anything about it's robustness but it seems like
a workable solution.

___
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] RTree implementation

[Seth Hillbrand]

Am 2018-10-23 14:44, schrieb Wayne Stambaugh:

I attempted to test this and ran into a dead end.  I was running into 
an

out of memory error attempting to load the pcbnew.kiface with a full
debug build so I had to build with -DBUILD_SMALL_DEBUG_FILES=ON to even
run pcbnew.  I followed your steps above and when I attempted to import
the video demo netlist, kicad crashed spectacularly.


Thanks Wayne!  That's the fault I was concerned about.  If you rebuild 
with -DCMAKE_CXX_FLAGS="-O2 -ffloat-store" and the same other options, 
does the crash resolve?


-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

Re: [Kicad-developers] RTree implementation

[Wayne Stambaugh]

On 10/23/2018 12:09 PM, Seth Hillbrand wrote:
> Am 2018-10-22 18:33, schrieb Seth Hillbrand:
>> Given that this would be a change _only_ for the 32-bit compiles, this
>> may be acceptable.  Also, I haven't seen any MSW reports of this
>> issue, so I'm inclined to limit the change to linux only.
> 
> An addendum here:  We don't see this issue other than on Debian because
> most builds set the -DNDEBUG flag on release builds.  Debian turns it
> off, which enables this assert.
> 
> However, the bug is only triggered when we also compile with -O2 or
> higher, which in our default CMake files, is only set with the -DNDEBUG
> flag.
> 
> Could one of our Windows devs with a 32-bit platform test this?  You can
> do this by setting -DCMAKE_CXX_FLAGS="-O2" and -DCMAKE_BUILD_TYPE=Debug
> 
> Then, open the demos/video folder and run pcbnew.  Select the whole
> board and delete it.  Then do a netlist import of the video.net file. 
> This should trigger the assert if your system is susceptible to this
> bug.  If it is, we'll want to add this flag to the windows 32 bit builds
> as well.
> 
> Thanks-
> Seth

I attempted to test this and ran into a dead end.  I was running into an
out of memory error attempting to load the pcbnew.kiface with a full
debug build so I had to build with -DBUILD_SMALL_DEBUG_FILES=ON to even
run pcbnew.  I followed your steps above and when I attempted to import
the video demo netlist, kicad crashed spectacularly.  I was attempting
this on 64 bit windows.  I no longer have access to any 32 windows
systems so I don't know if that is a factor or not.  My normal 32 bit
release builds work fine.

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

Re: [Kicad-developers] Net ties and copper DRC

[Seth Hillbrand]

Am 2018-10-23 13:45, schrieb mdoes...@xs4all.nl:

Ignoring clearances in a footprint sound scary to me.  Doing 1kV
designs I want the clearances checked, so Ik know I've chosen the wrong
footprint. How about creating special pin names xxx_nettie just like
the special netnames for differential pairs?


Hi Mark-

This is the current 5.0 behavior, so nothing is changing in this 
respect.


The issue is that users have designed boards with 5.0 and the 5.0 nettie 
libraries.  We do not want 5.1 to change things in a way that causes 
existing boards to fail DRC.


-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

Re: [Kicad-developers] Net ties and copper DRC

[mdoesbur]

Hello Seth,

I never even knew this feature existed. So basically copper which is
not a pad is ignored during DRC?  That's fine, you should not do that
unless you're doing something weird.

regards,

Mark.

Seth Hillbrand  wrote:

Hi Mark-

This is the current 5.0 behavior, so nothing is changing in this 
respect.

The issue is that users have designed boards with 5.0 and the 5.0 
nettie 
libraries.  We do not want 5.1 to change things in a way that causes 
existing boards to fail DRC.

-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

Re: [Kicad-developers] Net ties and copper DRC

[Wayne Stambaugh]

Mark,

This only applies to a single footprint with graphical items on on
copper layers.  Clearances to all other copper not belonging to the
footprint will be checked.  This is not a common use of graphical
objects on footprint copper layers and was only done as a work around
because we don't have a formal net tie feature.

Adding a special net tie symbol naming scheme is a new feature which is
forbidden for 5.1 development and would be a complete waste of time
since we are going to implement net ties properly in version 6.  Version
5.1 is only to fix the wxwdigets/gtk3 and wxPython/gtk3 mess on newer
linux distros.  I would have rather not done a 5.1 release the current
situation hasn't really given us a much of a choice.  Version 5.1 will
not have any new features compared to 5.0.

Cheers,

Wayne

On 10/23/2018 1:45 PM, mdoes...@xs4all.nl wrote:
> Ignoring clearances in a footprint sound scary to me.  Doing 1kV
> designs I want the clearances checked, so Ik know I've chosen the wrong
> footprint. How about creating special pin names xxx_nettie just like
> the special netnames for differential pairs?
> 
> regards,
> 
> Mark.
> 
> Seth Hillbrand  wrote:
> 
>   Hi Jeff-
> 
>   What about just avoiding DRC between footprint graphic items and the 
>   other items in the same footprint?  That would avoid the file format 
>   change while keeping the purpose of the DRC (mostly).
> 
>   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

Re: [Kicad-developers] Net ties and copper DRC

[mdoesbur]

Ignoring clearances in a footprint sound scary to me.  Doing 1kV
designs I want the clearances checked, so Ik know I've chosen the wrong
footprint. How about creating special pin names xxx_nettie just like
the special netnames for differential pairs?

regards,

Mark.

Seth Hillbrand  wrote:

Hi Jeff-

What about just avoiding DRC between footprint graphic items and the 
other items in the same footprint?  That would avoid the file format 
change while keeping the purpose of the DRC (mostly).

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

Re: [Kicad-developers] RTree implementation

[Seth Hillbrand]

Am 2018-10-22 18:33, schrieb Seth Hillbrand:

Given that this would be a change _only_ for the 32-bit compiles, this
may be acceptable.  Also, I haven't seen any MSW reports of this
issue, so I'm inclined to limit the change to linux only.


An addendum here:  We don't see this issue other than on Debian because 
most builds set the -DNDEBUG flag on release builds.  Debian turns it 
off, which enables this assert.


However, the bug is only triggered when we also compile with -O2 or 
higher, which in our default CMake files, is only set with the -DNDEBUG 
flag.


Could one of our Windows devs with a 32-bit platform test this?  You can 
do this by setting -DCMAKE_CXX_FLAGS="-O2" and -DCMAKE_BUILD_TYPE=Debug


Then, open the demos/video folder and run pcbnew.  Select the whole 
board and delete it.  Then do a netlist import of the video.net file.  
This should trigger the assert if your system is susceptible to this 
bug.  If it is, we'll want to add this flag to the windows 32 bit builds 
as well.


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

Re: [Kicad-developers] Net ties and copper DRC

[José Ignacio]

If possible this would solve the problem quite elegantly for the time
being. +1

On Tue, Oct 23, 2018 at 8:54 AM Jeff Young  wrote:

> Hi Seth and Wayne,
>
> I had considered and discarded having DRC ignore copper graphics in
> footprints.  But the “same footprint” test didn’t occur to me, and I think
> it's just enough to make it work.
>
> Cheers,
> Jeff.
>
>
> On 23 Oct 2018, at 14:38, Wayne Stambaugh  wrote:
>
> On 10/23/2018 9:05 AM, Seth Hillbrand wrote:
>
> Am 2018-10-23 08:10, schrieb Jeff Young:
>
> So I broke our net-ties work-around when I added DRC for copper
> graphic items.
>
> I plan to add a IS_NET_TIE flag to graphic items to fix it.  (This
> appears compatible with the net tie discussions of yore on the email
> list.)  There will be a checkbox in Graphic Item Properties to set it.
>
> Question: add checkbox only to graphic items in a footprint, or to all?
>
> Any other issues you see?
>
> Thanks,
> Jeff.
>
> Note: we save the STATUS_FLAGS as an integer in the file, so while
> this constitutes a file-format change of sorts (an additional bit
> might be set), it’s fully backwards-compatible.
>
>
> Hi Jeff-
>
> What about just avoiding DRC between footprint graphic items and the
> other items in the same footprint?  That would avoid the file format
> change while keeping the purpose of the DRC (mostly).
>
>
> I like this solution better than using the status bits for something
> that really should be change in the footprint file format.  The status
> bits were really mean to be transient when editing objects.  I regret
> actually saving them in the new board file format.  It was a relic left
> over from the legacy board file format.  Hind sight is always 20/20.
>
>
> 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

Re: [Kicad-developers] Net ties and copper DRC

[Simon Richter]

Hi,

On 10/23/2018 02:10 PM, Jeff Young wrote:

> I plan to add a IS_NET_TIE flag to graphic items to fix it.  (This appears 
> compatible with the net tie discussions of yore on the email list.)  There 
> will be a checkbox in Graphic Item Properties to set it.

I'd like to make these obsolete as soon as possible, but I will
definitely need schema and PCB format changes for that, so definitely
not in the 5.x cycle.

   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] [RFC] wxPhoenix support

[Maciej Sumiński]

I have briefly tested the branch with Phoenix/Python3/GTK3 and
wxPython/Python2/GTK3 on Linux - no problems observed so far. Well done,
thank you Thomas!

Cheers,
Orson

On 10/23/18 3:56 PM, Thomas Pointhuber wrote:
> Hi Wayne,
> 
> The console crash is already fixed in the merge request:
> https://code.launchpad.net/~pointhi/kicad/+git/kicad/+merge/357605
> 
> Regards,
> Thomas
> 
> Am 22.10.18 um 18:36 schrieb Wayne Stambaugh:
>> Hey Thomas,
>>
>> I looked over you merge request and it changes seem fine.  I still need
>> to test it but until the console crash issue is resolved, I will not
>> approve the patch.  Hopefully someone can help you out with the mutex
>> locking issue.
>>
>> Cheers,
>>
>> Wayne



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

[Maciej Sumiński]

On 10/23/18 3:00 PM, Seth Hillbrand wrote:
> The issues were asserts, missing icons and a crash on exit.  I tracked
> it down to a wx module that was loaded by pip in my user cache from when
> I was testing gtk3 builds.  Yay, python.  Removing it cleared all issues.

Indeed it sounds like gtk2/gtk3 conflict, but I have good news: I fixed
the mirrored title block printing. I have also changed CMakeLists.txt,
so now it selects the same toolkit for wxWidgets and wxPython. When
scripting is disabled and only wxWidgets is linked then the default
toolkit is used. Now the problems caused by gtk2/gtk3 conflicts should
be gone. I think there is only one GTK3-specific issue left [1].

I have not pushed my changes yet, as there are two patches hanging in
the air that touch the same area that I have modified: one from Wayne to
verify wxPython.h, second one from Thomas Pointhuber to support Phoenix.
I came last to the party, so I am willing to rebase my changes once the
other changes are applied.

> We can currently choose the wx version we link against using
> -DwxWidgets_CONFIG_OPTIONS="--toolkit=gtk2".  I'd prefer to retain that
> ability rather than having Cmake try to figure it out.  Maybe we make
> that option more user-friendly?

Do you mean a CMake flag? I have nothing against it.

Cheers,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1786515



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] Net ties and copper DRC

[Wayne Stambaugh]

Hey Jeff,

This should "work" as long as we are opertating under the assumption
that copper overlap from different nets within a footprint is what the
footprint designer intended.  I know this may not always be the case but
until we add support for this in our board file, it might be the best
solution until we start on v6.

Cheers,

Wayne

On 10/23/2018 9:53 AM, Jeff Young wrote:
> Hi Seth and Wayne,
> 
> I had considered and discarded having DRC ignore copper graphics in
> footprints.  But the “same footprint” test didn’t occur to me, and I
> think it's just enough to make it work.
> 
> Cheers,
> Jeff.
> 
> 
>> On 23 Oct 2018, at 14:38, Wayne Stambaugh > > wrote:
>>
>> On 10/23/2018 9:05 AM, Seth Hillbrand wrote:
>>> Am 2018-10-23 08:10, schrieb Jeff Young:
 So I broke our net-ties work-around when I added DRC for copper
 graphic items.

 I plan to add a IS_NET_TIE flag to graphic items to fix it.  (This
 appears compatible with the net tie discussions of yore on the email
 list.)  There will be a checkbox in Graphic Item Properties to set it.

 Question: add checkbox only to graphic items in a footprint, or to all?

 Any other issues you see?

 Thanks,
 Jeff.

 Note: we save the STATUS_FLAGS as an integer in the file, so while
 this constitutes a file-format change of sorts (an additional bit
 might be set), it’s fully backwards-compatible.
>>>
>>> Hi Jeff-
>>>
>>> What about just avoiding DRC between footprint graphic items and the
>>> other items in the same footprint?  That would avoid the file format
>>> change while keeping the purpose of the DRC (mostly).
>>
>> I like this solution better than using the status bits for something
>> that really should be change in the footprint file format.  The status
>> bits were really mean to be transient when editing objects.  I regret
>> actually saving them in the new board file format.  It was a relic left
>> over from the legacy board file format.  Hind sight is always 20/20.
>>
>>>
>>> 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

Re: [Kicad-developers] [RFC] wxPhoenix support

[Thomas Pointhuber]

Hi Wayne,

The console crash is already fixed in the merge request:
https://code.launchpad.net/~pointhi/kicad/+git/kicad/+merge/357605

Regards,
Thomas

Am 22.10.18 um 18:36 schrieb Wayne Stambaugh:
> Hey Thomas,
> 
> I looked over you merge request and it changes seem fine.  I still need
> to test it but until the console crash issue is resolved, I will not
> approve the patch.  Hopefully someone can help you out with the mutex
> locking issue.
> 
> Cheers,
> 
> Wayne



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] Net ties and copper DRC

[Jeff Young]

Hi Seth and Wayne,

I had considered and discarded having DRC ignore copper graphics in footprints. 
 But the “same footprint” test didn’t occur to me, and I think it's just enough 
to make it work.

Cheers,
Jeff.


> On 23 Oct 2018, at 14:38, Wayne Stambaugh  wrote:
> 
> On 10/23/2018 9:05 AM, Seth Hillbrand wrote:
>> Am 2018-10-23 08:10, schrieb Jeff Young:
>>> So I broke our net-ties work-around when I added DRC for copper
>>> graphic items.
>>> 
>>> I plan to add a IS_NET_TIE flag to graphic items to fix it.  (This
>>> appears compatible with the net tie discussions of yore on the email
>>> list.)  There will be a checkbox in Graphic Item Properties to set it.
>>> 
>>> Question: add checkbox only to graphic items in a footprint, or to all?
>>> 
>>> Any other issues you see?
>>> 
>>> Thanks,
>>> Jeff.
>>> 
>>> Note: we save the STATUS_FLAGS as an integer in the file, so while
>>> this constitutes a file-format change of sorts (an additional bit
>>> might be set), it’s fully backwards-compatible.
>> 
>> Hi Jeff-
>> 
>> What about just avoiding DRC between footprint graphic items and the
>> other items in the same footprint?  That would avoid the file format
>> change while keeping the purpose of the DRC (mostly).
> 
> I like this solution better than using the status bits for something
> that really should be change in the footprint file format.  The status
> bits were really mean to be transient when editing objects.  I regret
> actually saving them in the new board file format.  It was a relic left
> over from the legacy board file format.  Hind sight is always 20/20.
> 
>> 
>> 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

Re: [Kicad-developers] Net ties and copper DRC

[Seth Hillbrand]

Am 2018-10-23 08:10, schrieb Jeff Young:
So I broke our net-ties work-around when I added DRC for copper graphic 
items.


I plan to add a IS_NET_TIE flag to graphic items to fix it.  (This
appears compatible with the net tie discussions of yore on the email
list.)  There will be a checkbox in Graphic Item Properties to set it.

Question: add checkbox only to graphic items in a footprint, or to all?

Any other issues you see?

Thanks,
Jeff.

Note: we save the STATUS_FLAGS as an integer in the file, so while
this constitutes a file-format change of sorts (an additional bit
might be set), it’s fully backwards-compatible.


Hi Jeff-

What about just avoiding DRC between footprint graphic items and the 
other items in the same footprint?  That would avoid the file format 
change while keeping the purpose of the DRC (mostly).


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

Re: [Kicad-developers] 5.1

[Seth Hillbrand]

Am 2018-10-23 03:08, schrieb Maciej Sumiński:

Hi Seth,

On 10/22/18 11:50 PM, Seth Hillbrand wrote:

Hi Orson-

This looks very nice.  It works well for me with scripting off on 
Debian
Stretch.  I had some issues with scripting on that I haven't 
encountered
with the master branch but I suspect that this is a gtk2/3 issue 
because

I can't see any scripting-related changes in the branch.


What are the issues? I agree that most likely culprit is gtk2/3 mix, 
but

I would rather be sure that I have not broken anything else. Since now
we are not bound to gtk2 anymore, I will add a patch to link KiCad
against wxWidgets version delivered with wxPython.


The issues were asserts, missing icons and a crash on exit.  I tracked 
it down to a wx module that was loaded by pip in my user cache from when 
I was testing gtk3 builds.  Yay, python.  Removing it cleared all 
issues.


We can currently choose the wx version we link against using 
-DwxWidgets_CONFIG_OPTIONS="--toolkit=gtk2".  I'd prefer to retain that 
ability rather than having Cmake try to figure it out.  Maybe we make 
that option more user-friendly?


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

[Kicad-developers] Net ties and copper DRC

[Jeff Young]

So I broke our net-ties work-around when I added DRC for copper graphic items.

I plan to add a IS_NET_TIE flag to graphic items to fix it.  (This appears 
compatible with the net tie discussions of yore on the email list.)  There will 
be a checkbox in Graphic Item Properties to set it.

Question: add checkbox only to graphic items in a footprint, or to all?

Any other issues you see?

Thanks,
Jeff.

Note: we save the STATUS_FLAGS as an integer in the file, so while this 
constitutes a file-format change of sorts (an additional bit might be set), 
it’s fully backwards-compatible.
___
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] 5.1

[Maciej Sumiński]

Hi Seth,

On 10/22/18 11:50 PM, Seth Hillbrand wrote:
> Hi Orson-
> 
> This looks very nice.  It works well for me with scripting off on Debian
> Stretch.  I had some issues with scripting on that I haven't encountered
> with the master branch but I suspect that this is a gtk2/3 issue because
> I can't see any scripting-related changes in the branch.

What are the issues? I agree that most likely culprit is gtk2/3 mix, but
I would rather be sure that I have not broken anything else. Since now
we are not bound to gtk2 anymore, I will add a patch to link KiCad
against wxWidgets version delivered with wxPython.

> BTW, the WorldUnitLength fix is a good bug find!  Does that need
> updating in Eeschema GAL as well?

You are right, I will update the constant as now bitmaps in eeschema are
not scaled correctly. IMHO the bug was not that serious, it has been
there since the GAL origin and I am sure we still would not have noticed
if GAL::DrawBitmap() had not referred to GAL canvas DPI.

Cheers,
Orson

> -S




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