Re: [Kicad-developers] [PATCH] Re: SHAPE_LINE_CHAIN in swig?

[Nick Østergaard]

Hi Andrew

Seth already shared the build log.

tir. 31. jul. 2018 05.29 skrev Andrew Lutsenko :

> I just noticed that my patch was reverted with reference to a build
> failure with gcc 4.9.2
>
> Could you share the error messages too?
> Also curios which platform uses such ancient compiler. I tried msys2, it
> only has gcc back to 5.1 and even debian stable uses 6.3.
>
> I'm more than willing to put in the work to fix the issue but would like
> some pointers on how to replicate it, unless it's something I can easily
> figure out from error listing.
>
> Thanks,
> Andrew
>
> On Mon, Jul 30, 2018 at 9:58 AM Andrew Lutsenko 
> wrote:
>
>> Thank you Seth,
>>
>> Any chance this can be pushed to 5.0 branch too?
>>
>> > Keep in mind that the SWIG-based interface will (hopefully) be retired
>> soon in favor of a fully-abstracted KiCad scripting language.
>>
>> Oh. When that happens there hopefully will be a transition period to give
>> plugin writers a chance to migrate to this new language?
>> When you say fully-abstracted Kicad language, that means it's own syntax
>> and complete isolation from existing vast ecosystem of libraries that
>> python has?
>> Or is some interoperability planned?
>>
>> Regards,
>> Andrew
>>
>> On Mon, Jul 30, 2018 at 8:53 AM Seth Hillbrand 
>> wrote:
>>
>>> This compiles cleanly and does not appear to have negative side effects
>>> so I pushed it.  I made a small change to the boilerplate in math.i.
>>>
>>> Keep in mind that the SWIG-based interface will (hopefully) be retired
>>> soon in favor of a fully-abstracted KiCad scripting language.  But since
>>> that goal is still in the future, this patch may be useful in the interim.
>>>
>>> Thank you for your contribution to KiCad.
>>> -S
>>>
>>> Am Di., 24. Juli 2018 um 20:30 Uhr schrieb Andrew Lutsenko <
>>> anlutse...@gmail.com>:
>>>
 Hello,

 Can someone take a look at my patch please?
 It's my first so if I didn't submit it correctly please bear with me, I
 believe I did everything according to developers documentation.

 It would be great to see this in next release. Patch applies cleanly to
 both 5.0 branch and master.

 Regards,
 Andrew

 On Sun, Jul 22, 2018 at 6:05 PM Andrew Lutsenko 
 wrote:

> I figured it out, please see attached patch for the fix.
>
> On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko 
> wrote:
>
>> I tried adding this in kicad.i
>>
>> #include 
>> %include 
>>
>> It compiles and SHAPE_LINE_CHAIN type shows up in pcbnew.py
>>
>> But I need VECTOR2I as well to get the actual coordinates. However
>> adding math/vector2d.h header in a similar way leads to following
>> linking
>> error that I am not sure how to fix:
>>
>> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MINE[.refptr._ZN7VECTOR2IiE10ECOORD_MINE]+0x0):
>> undefined reference to `VECTOR2::ECOORD_MIN'
>> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MAXE[.refptr._ZN7VECTOR2IiE10ECOORD_MAXE]+0x0):
>> undefined reference to `VECTOR2::ECOORD_MAX'
>>
>> Can someone who understands swig help me figure this out?
>>
>> On Sat, Jul 21, 2018 at 12:36 PM Andrew Lutsenko <
>> anlutse...@gmail.com> wrote:
>>
>>> Hello Kicad team,
>>>
>>> I'm writing a pcbnew action plugin that needs to read footprint pad
>>> coordinates and shape.
>>> I had no trouble figuring out all shapes except for custom one. It is
>>> represented by SHAPE_POLY_SET which has a corresponding python type
>>> but to
>>> get actual vertex coordinates you have to either call one of
>>> Iterate()
>>> variants or get polygon outlines with Outline(). They both return
>>> objects
>>> (ITERATOR and SHAPE_LINE_CHAIN) that are pointers and have no useful
>>> attributes. As far as I understand they just don't have
>>> corresponding swig
>>> bindings so they are not exposed properly in python.
>>>
>>> Am I missing some obvious way to read custom pad polygon data in
>>> python?
>>>
>>> If not, what would it take to add that?
>>>
>>> I don't understand much about how swig configuration works but
>>> cursory
>>> glance at Kicad source suggests that there needs to be an import for
>>> shape_line_chain.h in common/swig/kicad.i, similar to shape_poly_set
>>> import.
>>>
>>> If you are curious about what the plugin does, here are some of it's
>>> results, generated from Kicad demos:
>>> http://plugindemo.bitballoon.com/1/
>>> http://plugindemo.bitballoon.com/2/

Re: [Kicad-developers] [PATCH] Re: SHAPE_LINE_CHAIN in swig?

[Andrew Lutsenko]

I just noticed that my patch was reverted with reference to a build failure
with gcc 4.9.2

Could you share the error messages too?
Also curios which platform uses such ancient compiler. I tried msys2, it
only has gcc back to 5.1 and even debian stable uses 6.3.

I'm more than willing to put in the work to fix the issue but would like
some pointers on how to replicate it, unless it's something I can easily
figure out from error listing.

Thanks,
Andrew

On Mon, Jul 30, 2018 at 9:58 AM Andrew Lutsenko 
wrote:

> Thank you Seth,
>
> Any chance this can be pushed to 5.0 branch too?
>
> > Keep in mind that the SWIG-based interface will (hopefully) be retired
> soon in favor of a fully-abstracted KiCad scripting language.
>
> Oh. When that happens there hopefully will be a transition period to give
> plugin writers a chance to migrate to this new language?
> When you say fully-abstracted Kicad language, that means it's own syntax
> and complete isolation from existing vast ecosystem of libraries that
> python has?
> Or is some interoperability planned?
>
> Regards,
> Andrew
>
> On Mon, Jul 30, 2018 at 8:53 AM Seth Hillbrand  wrote:
>
>> This compiles cleanly and does not appear to have negative side effects
>> so I pushed it.  I made a small change to the boilerplate in math.i.
>>
>> Keep in mind that the SWIG-based interface will (hopefully) be retired
>> soon in favor of a fully-abstracted KiCad scripting language.  But since
>> that goal is still in the future, this patch may be useful in the interim.
>>
>> Thank you for your contribution to KiCad.
>> -S
>>
>> Am Di., 24. Juli 2018 um 20:30 Uhr schrieb Andrew Lutsenko <
>> anlutse...@gmail.com>:
>>
>>> Hello,
>>>
>>> Can someone take a look at my patch please?
>>> It's my first so if I didn't submit it correctly please bear with me, I
>>> believe I did everything according to developers documentation.
>>>
>>> It would be great to see this in next release. Patch applies cleanly to
>>> both 5.0 branch and master.
>>>
>>> Regards,
>>> Andrew
>>>
>>> On Sun, Jul 22, 2018 at 6:05 PM Andrew Lutsenko 
>>> wrote:
>>>
 I figured it out, please see attached patch for the fix.

 On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko 
 wrote:

> I tried adding this in kicad.i
>
> #include 
> %include 
>
> It compiles and SHAPE_LINE_CHAIN type shows up in pcbnew.py
>
> But I need VECTOR2I as well to get the actual coordinates. However
> adding math/vector2d.h header in a similar way leads to following
> linking
> error that I am not sure how to fix:
>
> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MINE[.refptr._ZN7VECTOR2IiE10ECOORD_MINE]+0x0):
> undefined reference to `VECTOR2::ECOORD_MIN'
> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MAXE[.refptr._ZN7VECTOR2IiE10ECOORD_MAXE]+0x0):
> undefined reference to `VECTOR2::ECOORD_MAX'
>
> Can someone who understands swig help me figure this out?
>
> On Sat, Jul 21, 2018 at 12:36 PM Andrew Lutsenko 
> wrote:
>
>> Hello Kicad team,
>>
>> I'm writing a pcbnew action plugin that needs to read footprint pad
>> coordinates and shape.
>> I had no trouble figuring out all shapes except for custom one. It is
>> represented by SHAPE_POLY_SET which has a corresponding python type
>> but to
>> get actual vertex coordinates you have to either call one of Iterate()
>> variants or get polygon outlines with Outline(). They both return
>> objects
>> (ITERATOR and SHAPE_LINE_CHAIN) that are pointers and have no useful
>> attributes. As far as I understand they just don't have corresponding
>> swig
>> bindings so they are not exposed properly in python.
>>
>> Am I missing some obvious way to read custom pad polygon data in
>> python?
>>
>> If not, what would it take to add that?
>>
>> I don't understand much about how swig configuration works but cursory
>> glance at Kicad source suggests that there needs to be an import for
>> shape_line_chain.h in common/swig/kicad.i, similar to shape_poly_set
>> import.
>>
>> If you are curious about what the plugin does, here are some of it's
>> results, generated from Kicad demos:
>> http://plugindemo.bitballoon.com/1/
>> http://plugindemo.bitballoon.com/2/
>> http://plugindemo.bitballoon.com/3/
>>
>> #2 above has a solder bridge with custom shape pads that are not
>> rendered.
>> Links are short lived.
>>
>> Regards,
>> Andrew
>>
> ___
>>> 

Re: [Kicad-developers] Strange crashes

[Steven A. Falco]

Thanks for looking at it.  Regarding your first question, I've placed a copy of 
my build log in the same dropbox directory, named "build.log".

Regarding your second question, the gdb crash dump from the Copr nightly build 
looks about the same as the one from my local build.  Both builds fail with the 
same error.  I've placed both gdb logs in the dropbox directory, named 
"err-mine.log" and "err-nightly.log".

The cmake command used for my build is:

cmake \
-DKICAD_SCRIPTING=OFF \
-DKICAD_SCRIPTING_MODULES=OFF \
-DKICAD_SCRIPTING_WXPYTHON=OFF \
-DKICAD_SPICE=OFF \
-DKICAD_VERSION_EXTRA=%{release} \
-DwxWidgets_CONFIG_EXECUTABLE=%{_bindir}/%{wx_config} \
.

The type of build should default to "Release", according to CMakeLists.txt.  
The Fedora build tools add some options to the above command.  From the build 
log, the command expands to:

/usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON 
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include 
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
-DBUILD_SHARED_LIBS:BOOL=ON -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF 
-DKICAD_SCRIPTING_WXPYTHON=OFF -DKICAD_SPICE=OFF -DKICAD_VERSION_EXTRA=2.fc28 
-DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config .

wx-config reports its version as:

saf$ /usr/bin/wx-config --version-full
3.0.4.0

Please let me know any other info you need to help track this down.

Steve

On 07/30/2018 05:08 PM, Seth Hillbrand wrote:
> Hi Steve-
> 
> The assert is not triggering for me using Debian.  However, I note that this 
> is a wxWidgets assertion, which should be disabled for release builds.  Since 
> you did the packaging for Fedora, do you have a build log?  Alternatively, do 
> you see this assertion when running a local build?
> 
> -S
> 
> Am Mo., 30. Juli 2018 um 12:37 Uhr schrieb Steven A. Falco 
> mailto:stevenfa...@gmail.com>>:
> 
> I am using Fedora 28, and have just noticed a strange crash.  This 
> happens with 5.0.0 and also with the latest nightly (r13432-e750382e).
> 
> I've got to assume I'm doing something wrong, but I am baffled, so I want 
> to see what folks think.
> 
> I've attached a backtrace.  The way I cause this crash is to highlight a 
> part in the design here:
> 
> https://www.dropbox.com/sh/46lxxedoalq0sdm/AABTNAmVP7wKjbv3_4hBcdcoa?dl=0
> 
> I've attached several screenshots for reference.
> 
> In "highlighted.png" you can see the part I've selected - an Atmel micro. 
>  I type "E" to get the properties, and I wind up with a blank dialog as shown 
> in "blank_alert.png".  It is at that point that I did the backtrace.
> 
> This is with the fallback version of the modern toolset.  If I try to 
> switch to the accelerated toolset, I get an error that I need OpenGL 2.1 or 
> higher.  However, I think I have OpenGL 3.3.0:
> 
> saf# glxinfo | grep "OpenGL version"
> OpenGL version string: 3.3.0 NVIDIA 340.107
> 
> Here is the version info from my build of 5.0.0:
> 
> Application: kicad
> Version: 5.0.0-2.fc28, release build
> Libraries:
>     wxWidgets 3.0.4
>     libcurl/7.59.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 
> (+libidn2/2.0.4) libssh/0.7.5/openssl/zlib nghttp2/1.32.0
> Platform: Linux 4.17.9-200.fc28.x86_64 x86_64, 64 bit, Little endian, 
> wxGTK
> Build Info:
>     wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
>     Boost: 1.66.0
>     OpenCASCADE Community Edition: 6.9.1
>     Curl: 7.59.0
>     Compiler: GCC 8.1.1 with C++ ABI 1013
> 
> Build settings:
>     USE_WX_GRAPHICS_CONTEXT=OFF
>     USE_WX_OVERLAY=OFF
>     KICAD_SCRIPTING=OFF
>     KICAD_SCRIPTING_MODULES=OFF
>     KICAD_SCRIPTING_WXPYTHON=OFF
>     KICAD_SCRIPTING_ACTION_MENU=OFF
>     BUILD_GITHUB_PLUGIN=ON
>     KICAD_USE_OCE=ON
>     KICAD_USE_OCC=OFF
>     KICAD_SPICE=OFF
> 
> Please let me know what you think.  I'm mystified.
> 
>         Steve
> 
> ___
> 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] Rename lang_catalan and lang_chinese SVGs

[Mark Roszko]

Is KiCad still really doing language icons? Are we going to ignore how
offensive it is to mix up English with just the British flag and
Spanish with the flag of Spain when there is an entire continent of
countries speaking the language...
On Mon, Jul 30, 2018 at 5:57 PM Seth Hillbrand  wrote:
>
> Good catch!  Thanks John.
>
> Best-
> Seth
>
> Am Do., 26. Juli 2018 um 08:16 Uhr schrieb John Beard 
> :
>>
>> Hi,
>>
>> The SVGs for Catalan and Chinese did not match the XPM constant names,
>> so there were linking errors.
>>
>> I'm not sure how this hasn't been causing breakages since 7841f8a466,
>> but presumably it only breaks if you have MAINTAIN_PNGs on *and* clean
>> something in a way most people don't, as the old CPPs persist.
>>
>> Cheers,
>>
>> John
>> ___
>> 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



-- 
Mark

___
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] Rename lang_catalan and lang_chinese SVGs

[Seth Hillbrand]

​Good catch!  Thanks John.

Best-
Seth​

Am Do., 26. Juli 2018 um 08:16 Uhr schrieb John Beard <
john.j.be...@gmail.com>:

> Hi,
>
> The SVGs for Catalan and Chinese did not match the XPM constant names,
> so there were linking errors.
>
> I'm not sure how this hasn't been causing breakages since 7841f8a466,
> but presumably it only breaks if you have MAINTAIN_PNGs on *and* clean
> something in a way most people don't, as the old CPPs persist.
>
> Cheers,
>
> John
> ___
> 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] Strange crashes

[Seth Hillbrand]

Hi Steve-

The assert is not triggering for me using Debian.  However, I note that
this is a wxWidgets assertion, which should be disabled for release
builds.  Since you did the packaging for Fedora, do you have a build log?
Alternatively, do you see this assertion when running a local build?

-S

Am Mo., 30. Juli 2018 um 12:37 Uhr schrieb Steven A. Falco <
stevenfa...@gmail.com>:

> I am using Fedora 28, and have just noticed a strange crash.  This happens
> with 5.0.0 and also with the latest nightly (r13432-e750382e).
>
> I've got to assume I'm doing something wrong, but I am baffled, so I want
> to see what folks think.
>
> I've attached a backtrace.  The way I cause this crash is to highlight a
> part in the design here:
>
> https://www.dropbox.com/sh/46lxxedoalq0sdm/AABTNAmVP7wKjbv3_4hBcdcoa?dl=0
>
> I've attached several screenshots for reference.
>
> In "highlighted.png" you can see the part I've selected - an Atmel micro.
> I type "E" to get the properties, and I wind up with a blank dialog as
> shown in "blank_alert.png".  It is at that point that I did the backtrace.
>
> This is with the fallback version of the modern toolset.  If I try to
> switch to the accelerated toolset, I get an error that I need OpenGL 2.1 or
> higher.  However, I think I have OpenGL 3.3.0:
>
> saf# glxinfo | grep "OpenGL version"
> OpenGL version string: 3.3.0 NVIDIA 340.107
>
> Here is the version info from my build of 5.0.0:
>
> Application: kicad
> Version: 5.0.0-2.fc28, release build
> Libraries:
> wxWidgets 3.0.4
> libcurl/7.59.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2
> (+libidn2/2.0.4) libssh/0.7.5/openssl/zlib nghttp2/1.32.0
> Platform: Linux 4.17.9-200.fc28.x86_64 x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
> Boost: 1.66.0
> OpenCASCADE Community Edition: 6.9.1
> Curl: 7.59.0
> Compiler: GCC 8.1.1 with C++ ABI 1013
>
> Build settings:
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=OFF
> KICAD_SCRIPTING=OFF
> KICAD_SCRIPTING_MODULES=OFF
> KICAD_SCRIPTING_WXPYTHON=OFF
> KICAD_SCRIPTING_ACTION_MENU=OFF
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=ON
> KICAD_USE_OCC=OFF
> KICAD_SPICE=OFF
>
> Please let me know what you think.  I'm mystified.
>
> Steve
>
> ___
> 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] Strange crashes

[Steven A. Falco]

I am using Fedora 28, and have just noticed a strange crash.  This happens with 
5.0.0 and also with the latest nightly (r13432-e750382e).

I've got to assume I'm doing something wrong, but I am baffled, so I want to 
see what folks think.

I've attached a backtrace.  The way I cause this crash is to highlight a part 
in the design here:

https://www.dropbox.com/sh/46lxxedoalq0sdm/AABTNAmVP7wKjbv3_4hBcdcoa?dl=0

I've attached several screenshots for reference.

In "highlighted.png" you can see the part I've selected - an Atmel micro.  I 
type "E" to get the properties, and I wind up with a blank dialog as shown in 
"blank_alert.png".  It is at that point that I did the backtrace.

This is with the fallback version of the modern toolset.  If I try to switch to 
the accelerated toolset, I get an error that I need OpenGL 2.1 or higher.  
However, I think I have OpenGL 3.3.0:

saf# glxinfo | grep "OpenGL version"
OpenGL version string: 3.3.0 NVIDIA 340.107

Here is the version info from my build of 5.0.0:

Application: kicad
Version: 5.0.0-2.fc28, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.59.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 
(+libidn2/2.0.4) libssh/0.7.5/openssl/zlib nghttp2/1.32.0
Platform: Linux 4.17.9-200.fc28.x86_64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.66.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.59.0
Compiler: GCC 8.1.1 with C++ ABI 1013

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_ACTION_MENU=OFF
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=OFF

Please let me know what you think.  I'm mystified.

Steve

saf$ gdb kicad
GNU gdb (GDB) Fedora 8.1-23.fc28
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from kicad...Reading symbols from /home/sfalco/kicad...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Missing separate debuginfos, use: dnf debuginfo-install kicad-5.0.0-2.fc28.x86_64
(gdb) run
Starting program: /usr/bin/kicad 
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
15:09:57: Warning: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1012,wx containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1013,wx containers,compatible with 2.8).
15:09:57: Debug: Checking template path '/usr/share/kicad/template' exists
15:09:57: Debug: Checking template path '/home/sfalco/kicad/template' exists
Detaching after fork from child process 10285.
Detaching after fork from child process 10287.
Detaching after fork from child process 10289.
Detaching after fork from child process 10291.
Detaching after fork from child process 10293.
Detaching after fork from child process 10318.
Detaching after fork from child process 10337.
Detaching after fork from child process 10359.
[New Thread 0x7fffd7431700 (LWP 10384)]
[New Thread 0x7fffd6c30700 (LWP 10385)]
[New Thread 0x7fffd642f700 (LWP 10386)]
03:09:58 PM: Debug: FileWatcherReset: add '/home/sfalco/kicad/new_weather/main/main.pretty'

03:09:58 PM: Debug: FileWatcherReset: add '/home/sfalco/kicad/new_weather/main/gerbers'

03:09:58 PM: Debug: FileWatcherReset: add '/home/sfalco/kicad/new_weather/main/gerbers-10_percent'

03:09:58 PM: Debug: FileWatcherReset: add '/home/sfalco/kicad/new_weather/main/gerbers-20_percent'

03:09:58 PM: Debug: FileWatcherReset: add 

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

[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] Re: SHAPE_LINE_CHAIN in swig?

[Seth Hillbrand]

Hi Andrew-

Unfortunately your patch did not compile correctly in our qa system.  It
compiled for me (Linux/gcc 6) with only normal SWIG warnings but the qa
system uses a different setup and encountered an error.  You can view the
output here: http://ci.kicad-pcb.org/job/kicad-qa/4415/

I suspect the issue will be resolved with some additional %ignore wrappers
but haven't dug into it.  In the meantime, I've reverted the commit until
we can ensure it compiles with all systems.

On the higher-order plans, you can view one of the relevant threads here:
https://lists.launchpad.net/kicad-developers/msg36134.html  I believe
Thomas Pointhuber was thinking about developing that further in the near
future.  I'd recommend starting a new thread on the list to discuss this if
you are interested in contributing.

Best-
Seth



Am Mo., 30. Juli 2018 um 09:59 Uhr schrieb Andrew Lutsenko <
anlutse...@gmail.com>:

> Thank you Seth,
>
> Any chance this can be pushed to 5.0 branch too?
>
> > Keep in mind that the SWIG-based interface will (hopefully) be retired
> soon in favor of a fully-abstracted KiCad scripting language.
>
> Oh. When that happens there hopefully will be a transition period to give
> plugin writers a chance to migrate to this new language?
> When you say fully-abstracted Kicad language, that means it's own syntax
> and complete isolation from existing vast ecosystem of libraries that
> python has?
> Or is some interoperability planned?
>
> Regards,
> Andrew
>
> On Mon, Jul 30, 2018 at 8:53 AM Seth Hillbrand  wrote:
>
>> This compiles cleanly and does not appear to have negative side effects
>> so I pushed it.  I made a small change to the boilerplate in math.i.
>>
>> Keep in mind that the SWIG-based interface will (hopefully) be retired
>> soon in favor of a fully-abstracted KiCad scripting language.  But since
>> that goal is still in the future, this patch may be useful in the interim.
>>
>> Thank you for your contribution to KiCad.
>> -S
>>
>> Am Di., 24. Juli 2018 um 20:30 Uhr schrieb Andrew Lutsenko <
>> anlutse...@gmail.com>:
>>
>>> Hello,
>>>
>>> Can someone take a look at my patch please?
>>> It's my first so if I didn't submit it correctly please bear with me, I
>>> believe I did everything according to developers documentation.
>>>
>>> It would be great to see this in next release. Patch applies cleanly to
>>> both 5.0 branch and master.
>>>
>>> Regards,
>>> Andrew
>>>
>>> On Sun, Jul 22, 2018 at 6:05 PM Andrew Lutsenko 
>>> wrote:
>>>
 I figured it out, please see attached patch for the fix.

 On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko 
 wrote:

> I tried adding this in kicad.i
>
> #include 
> %include 
>
> It compiles and SHAPE_LINE_CHAIN type shows up in pcbnew.py
>
> But I need VECTOR2I as well to get the actual coordinates. However
> adding math/vector2d.h header in a similar way leads to following
> linking
> error that I am not sure how to fix:
>
> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MINE[.refptr._ZN7VECTOR2IiE10ECOORD_MINE]+0x0):
> undefined reference to `VECTOR2::ECOORD_MIN'
> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MAXE[.refptr._ZN7VECTOR2IiE10ECOORD_MAXE]+0x0):
> undefined reference to `VECTOR2::ECOORD_MAX'
>
> Can someone who understands swig help me figure this out?
>
> On Sat, Jul 21, 2018 at 12:36 PM Andrew Lutsenko 
> wrote:
>
>> Hello Kicad team,
>>
>> I'm writing a pcbnew action plugin that needs to read footprint pad
>> coordinates and shape.
>> I had no trouble figuring out all shapes except for custom one. It is
>> represented by SHAPE_POLY_SET which has a corresponding python type
>> but to
>> get actual vertex coordinates you have to either call one of Iterate()
>> variants or get polygon outlines with Outline(). They both return
>> objects
>> (ITERATOR and SHAPE_LINE_CHAIN) that are pointers and have no useful
>> attributes. As far as I understand they just don't have corresponding
>> swig
>> bindings so they are not exposed properly in python.
>>
>> Am I missing some obvious way to read custom pad polygon data in
>> python?
>>
>> If not, what would it take to add that?
>>
>> I don't understand much about how swig configuration works but cursory
>> glance at Kicad source suggests that there needs to be an import for
>> shape_line_chain.h in common/swig/kicad.i, similar to shape_poly_set
>> import.
>>
>> If you are curious about what the plugin does, here are some of it's
>> 

Re: [Kicad-developers] [PATCH] Re: SHAPE_LINE_CHAIN in swig?

[Andrew Lutsenko]

Thank you Seth,

Any chance this can be pushed to 5.0 branch too?

> Keep in mind that the SWIG-based interface will (hopefully) be retired
soon in favor of a fully-abstracted KiCad scripting language.

Oh. When that happens there hopefully will be a transition period to give
plugin writers a chance to migrate to this new language?
When you say fully-abstracted Kicad language, that means it's own syntax
and complete isolation from existing vast ecosystem of libraries that
python has?
Or is some interoperability planned?

Regards,
Andrew

On Mon, Jul 30, 2018 at 8:53 AM Seth Hillbrand  wrote:

> This compiles cleanly and does not appear to have negative side effects so
> I pushed it.  I made a small change to the boilerplate in math.i.
>
> Keep in mind that the SWIG-based interface will (hopefully) be retired
> soon in favor of a fully-abstracted KiCad scripting language.  But since
> that goal is still in the future, this patch may be useful in the interim.
>
> Thank you for your contribution to KiCad.
> -S
>
> Am Di., 24. Juli 2018 um 20:30 Uhr schrieb Andrew Lutsenko <
> anlutse...@gmail.com>:
>
>> Hello,
>>
>> Can someone take a look at my patch please?
>> It's my first so if I didn't submit it correctly please bear with me, I
>> believe I did everything according to developers documentation.
>>
>> It would be great to see this in next release. Patch applies cleanly to
>> both 5.0 branch and master.
>>
>> Regards,
>> Andrew
>>
>> On Sun, Jul 22, 2018 at 6:05 PM Andrew Lutsenko 
>> wrote:
>>
>>> I figured it out, please see attached patch for the fix.
>>>
>>> On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko 
>>> wrote:
>>>
 I tried adding this in kicad.i

 #include 
 %include 

 It compiles and SHAPE_LINE_CHAIN type shows up in pcbnew.py

 But I need VECTOR2I as well to get the actual coordinates. However
 adding math/vector2d.h header in a similar way leads to following
 linking
 error that I am not sure how to fix:

 D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MINE[.refptr._ZN7VECTOR2IiE10ECOORD_MINE]+0x0):
 undefined reference to `VECTOR2::ECOORD_MIN'
 D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MAXE[.refptr._ZN7VECTOR2IiE10ECOORD_MAXE]+0x0):
 undefined reference to `VECTOR2::ECOORD_MAX'

 Can someone who understands swig help me figure this out?

 On Sat, Jul 21, 2018 at 12:36 PM Andrew Lutsenko 
 wrote:

> Hello Kicad team,
>
> I'm writing a pcbnew action plugin that needs to read footprint pad
> coordinates and shape.
> I had no trouble figuring out all shapes except for custom one. It is
> represented by SHAPE_POLY_SET which has a corresponding python type
> but to
> get actual vertex coordinates you have to either call one of Iterate()
> variants or get polygon outlines with Outline(). They both return
> objects
> (ITERATOR and SHAPE_LINE_CHAIN) that are pointers and have no useful
> attributes. As far as I understand they just don't have corresponding
> swig
> bindings so they are not exposed properly in python.
>
> Am I missing some obvious way to read custom pad polygon data in
> python?
>
> If not, what would it take to add that?
>
> I don't understand much about how swig configuration works but cursory
> glance at Kicad source suggests that there needs to be an import for
> shape_line_chain.h in common/swig/kicad.i, similar to shape_poly_set
> import.
>
> If you are curious about what the plugin does, here are some of it's
> results, generated from Kicad demos:
> http://plugindemo.bitballoon.com/1/
> http://plugindemo.bitballoon.com/2/
> http://plugindemo.bitballoon.com/3/
>
> #2 above has a solder bridge with custom shape pads that are not
> rendered.
> Links are short lived.
>
> Regards,
> Andrew
>
 ___
>> 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] Import attributes and variants from eagle.

[Seth Hillbrand]

Hi Mark-

Generally looks good.  There are a few coding style issues and a couple
questions.  The coding style issues
- else on new line
- empty () should not have spaces
- blank line above if statements

Questions:
- Why are you storing unknown attributes?  Are these used for something?
- The boolean condition in loadInstance shouldn't be conditionally
assigning the variable.  While your code is correct as written, mixing
tests and assignments will make this difficult to maintain.  Can you adjust
the test for the attribute?

Lastly, it will be helpful if you can use `git format-patch` to create and
attach your patches.

Best-
Seth


Am Mo., 23. Juli 2018 um 09:23 Uhr schrieb Seth Hillbrand <
s...@hillbrand.org>:

> Thanks Mark, I'll be able to test this out next week.
>
> -S
>
> Am Mo., 23. Juli 2018 um 01:52 Uhr schrieb :
>
>> Hello Seth,
>>
>> As requested an example eagle project using variants.
>>
>> regards
>>
>> Mark.
>>
>
___
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] Re: SHAPE_LINE_CHAIN in swig?

[Seth Hillbrand]

This compiles cleanly and does not appear to have negative side effects so
I pushed it.  I made a small change to the boilerplate in math.i.

Keep in mind that the SWIG-based interface will (hopefully) be retired soon
in favor of a fully-abstracted KiCad scripting language.  But since that
goal is still in the future, this patch may be useful in the interim.

Thank you for your contribution to KiCad.
-S

Am Di., 24. Juli 2018 um 20:30 Uhr schrieb Andrew Lutsenko <
anlutse...@gmail.com>:

> Hello,
>
> Can someone take a look at my patch please?
> It's my first so if I didn't submit it correctly please bear with me, I
> believe I did everything according to developers documentation.
>
> It would be great to see this in next release. Patch applies cleanly to
> both 5.0 branch and master.
>
> Regards,
> Andrew
>
> On Sun, Jul 22, 2018 at 6:05 PM Andrew Lutsenko 
> wrote:
>
>> I figured it out, please see attached patch for the fix.
>>
>> On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko 
>> wrote:
>>
>>> I tried adding this in kicad.i
>>>
>>> #include 
>>> %include 
>>>
>>> It compiles and SHAPE_LINE_CHAIN type shows up in pcbnew.py
>>>
>>> But I need VECTOR2I as well to get the actual coordinates. However
>>> adding math/vector2d.h header in a similar way leads to following
>>> linking
>>> error that I am not sure how to fix:
>>>
>>> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MINE[.refptr._ZN7VECTOR2IiE10ECOORD_MINE]+0x0):
>>> undefined reference to `VECTOR2::ECOORD_MIN'
>>> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MAXE[.refptr._ZN7VECTOR2IiE10ECOORD_MAXE]+0x0):
>>> undefined reference to `VECTOR2::ECOORD_MAX'
>>>
>>> Can someone who understands swig help me figure this out?
>>>
>>> On Sat, Jul 21, 2018 at 12:36 PM Andrew Lutsenko 
>>> wrote:
>>>
 Hello Kicad team,

 I'm writing a pcbnew action plugin that needs to read footprint pad
 coordinates and shape.
 I had no trouble figuring out all shapes except for custom one. It is
 represented by SHAPE_POLY_SET which has a corresponding python type but
 to
 get actual vertex coordinates you have to either call one of Iterate()
 variants or get polygon outlines with Outline(). They both return
 objects
 (ITERATOR and SHAPE_LINE_CHAIN) that are pointers and have no useful
 attributes. As far as I understand they just don't have corresponding
 swig
 bindings so they are not exposed properly in python.

 Am I missing some obvious way to read custom pad polygon data in python?

 If not, what would it take to add that?

 I don't understand much about how swig configuration works but cursory
 glance at Kicad source suggests that there needs to be an import for
 shape_line_chain.h in common/swig/kicad.i, similar to shape_poly_set
 import.

 If you are curious about what the plugin does, here are some of it's
 results, generated from Kicad demos:
 http://plugindemo.bitballoon.com/1/
 http://plugindemo.bitballoon.com/2/
 http://plugindemo.bitballoon.com/3/

 #2 above has a solder bridge with custom shape pads that are not
 rendered.
 Links are short lived.

 Regards,
 Andrew

>>> ___
> 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: kicad-qa #4415

[Miguel Angel Ajo]

See 

Changes:

[hillbrand] Extend swig definitions to contain SHAPE_LINE_CHAIN and VECTOR2I

--
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 be0e44e2aea1302cf50dfd17fad4d893a9b61894 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f be0e44e2aea1302cf50dfd17fad4d893a9b61894
Commit message: "Extend swig definitions to contain SHAPE_LINE_CHAIN and 
VECTOR2I"
 > git rev-list --no-walk 619e13dc2d38aed2220d52b5a760204835a3847b # timeout=10
[kicad-qa] $ /bin/sh -xe /tmp/jenkins2452918942534919170.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+deb8u1) 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
-- 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%] [  0%] Built target netlist_lexer_source_files
Built target page_layout_lexer_source_files
Generating version string header
[  0%] Built target idf3
-- Using Git to determine build version string.
-- Found Git: /usr/bin/git (found version "2.1.4") 
[  0%] Built target lib_table_lexer_source_files
[  2%] [  2%] Built target kicad_3dsg
Built target pcb_lexer_source_files
[  5%] Built target gal
[  5%] -- Writing 
 file with 
version: (6.0.0-rc1-dev-203-gbe0e44e)
Built target pcb_plot_lexer_source_files
[  5%] Built target version_header
[  5%] Built target lib_dxf
[  5%] Built target specctra_lexer_source_files
[  5%] Built target polygon
[ 48%] Built target bitmaps
[ 54%] Built target pcbcommon
[ 55%] Built target pcad2kicadpcb
[ 61%] Built target 3d-viewer
[ 61%] Generating pcbnew_wrap.cxx, pcbnew.py
Scanning dependencies of target common
[ 61%] Building CXX object common/CMakeFiles/common.dir/build_version.cpp.o
:378: 
Warning 317: Specialization of non-template 'less'.
:253:
 Error: Syntax error in input(3).
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/build.make:95: recipe for target 
'pcbnew/pcbnew_wrap.cxx' failed
make[3]: *** [pcbnew/pcbnew_wrap.cxx] Error 1
CMakeFiles/Makefile2:1407: recipe for target 
'pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/all' failed
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs
Linking CXX static library libcommon.a
[ 76%] Built target common
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:610: recipe for target 'pcbnew_python_module' failed
make: *** [pcbnew_python_module] Error 2
Build step 

Re: [Kicad-developers] Patch to draw bitmaps in GAL canvases

[Tomasz Wlostowski]

On 30/07/18 11:14, jp charras wrote:
> Le 30/07/2018 à 00:29, Tomasz Wlostowski a écrit :
>> On 27/07/18 15:31, jp charras wrote:
>>> Le 27/07/2018 à 15:20, Tomasz Wlostowski a écrit :
>>>
>> Hi again,
>>
>> I've optimized the OpenGL bitmap drawing code (now it caches the bitmaps
>> and uses textures to draw them). Both mine and your patch are now in the
>> master branch.
>>
>> Thanks!
>> Tom
>>
> 
> 
> Thanks.
> 
> I have a strange behavior on OpenGL.
> 
> Some bitmaps (not all) are incorrectly drawn (both on Windows and Linux).
> I discovered bitmaps that are correctly drawn have a width multiple of 4.
> 
> Attached a bitmap incorrectly drawn by OpenGL, and a patch that fixes this 
> issue on my Windows install.
> 
> Have you encountered this issue (I had a look into glTexImage2D doc. 
> glTexImage2D can have some
> constraints, but I did not see this constraint)
> 

Hi JP,

Good catch, go ahead and merge it!

Cheers,
Tom

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

Re: [Kicad-developers] [RFC] Op-amp symbol icons

[Jeff Young]

Hi John,

Good find.  We should delete that one too.

With the new UI I’ve found some places where it would be nice to have footprint 
& symbol viewers available, but we’ve only the one icon (library with 
magnifying glass).  The library icon is almost totally gone anyway, so I think 
we should replace it with the opamp + magnifying glass and the footprint + 
magnifying glass.

Cheers,
Jeff.


> On 30 Jul 2018, at 10:05, John Beard  wrote:
> 
> While we're at it, new_cvpcb looks like it's also unused: it's built
> and listed in bitmaps.h, but nothing ever uses it.
> 
> Cheers,
> 
> John
> 
> On Sat, Jul 28, 2018 at 11:28 PM, Jeff Young  wrote:
>> No, looks like I just missed deleting it.
>> 
>>> On 28 Jul 2018, at 23:01, John Beard  wrote:
>>> 
>>> Hi Jeff,
>>> 
>>> Thanks for the heads up, makes life easier with fewer icons!
>>> 
>>> Looks like bitmaps_png/sources/edit_component.svg still exists,
>>> though. Is that intentional?
>>> 
>>> Cheers,
>>> 
>>> John
>>> 
>>> On Fri, Jul 27, 2018 at 11:39 AM, Jeff Young  wrote:
 Hi John,
 
 Just an update on the opamp icon list.  These icons:
 
 copycomponent.svg
 edit_component.svg
 edit_part.svg
 import_cmp_from_lib.svg
 save_part.svg
 save_part_in_mem.svg
 
 
 no longer exist.
 
 Cheers,
 Jeff.
 
 
 On 26 Jul 2018, at 09:33, Jeff Young  wrote:
 
 Hi John,
 
 Most other icons use a heavier pen width (see the DeMorgan symbols, pin
 graphics, etc.), which would favour the B column.
 
 I like the wider stance of the input pins in row 4.
 
 BTW, the new black-and-white 16x16 icons for the dialog buttons also suffer
 from slight blurryness.  I don’t know if they’re worth fixing or not, but 
 if
 you’re so inclined….
 
 Cheers,
 Jeff.
 
 
 On 25 Jul 2018, at 15:05, John Beard  wrote:
 
 Hi,
 
 The pixel alignment of the op-amp icons looks a bit fuzzy compared to
 the other newer icons. These are not the only misaligned icons, but
 they are a very prominent set of them.
 
 The problem is that both:
 
 1) The lines are not on the pixel grid
 2) The lines are not a whole number of pixels wide.
 
 If this *were* to be changed so horizontal lines are sharp, the icons
 have to be modified. However, going up to 2px or down to 1px line
 width changes the feel a bit.
 
 Attached are some options (for the full size op-amp icons at 26px). If
 a consensus or executive decision ever emerges, I will produce a patch
 for the op-amp icons in that style.
 
 Personally, my "vote" is 2A, or 5A for icons where the symbol is
 smaller, like "copycomponent".
 
 List of icons affected for reference:
 
 add_component.svg
 copycomponent.svg
 edit_cmp_symb_links.svg
 edit_comp_footprint.svg
 edit_comp_ref.svg
 edit_comp_value.svg
 edit_component.svg
 edit_part.svg
 export_part.svg
 field_properties.svg
 hidden_pin.svg
 icon_libedit.svg
 import_cmp_from_lib.svg
 import_part.svg
 libedit.svg
 new_component.svg
 new_cvpcb.svg
 part_properties.svg
 save_part.svg
 save_part_in_mem.svg
 
 Yours, bike-sheddingly,
 
 John
 ___
 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] Op-amp symbol icons

[John Beard]

Hi,

Here are 6a and 6b options, including the DeMorgan icons.

Cheers,

John

On Thu, Jul 26, 2018 at 5:40 PM, Jeff Young  wrote:
> I actually agree that 6a looks better on it’s own, but 6b matches the 
> DeMorgan icons better.
>
> (Of course we could always update those to match the opamp….)
>
> Cheers,
> Jeff.
>
>> On 26 Jul 2018, at 17:37, Wayne Stambaugh  wrote:
>>
>> Maybe it's my old eyes but 6a looks better to me.  6b seems a bit
>> crowded with the additional line thickness.  I can live with it either way.
>>
>> On 7/26/2018 5:26 AM, Jeff Young wrote:
>>> 6B is my new fave.
>>>

>>>
>>>
>>>
>>> ___
>>> 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] MacOS build issue with new geometry tests

[Maciej Sumiński]

Hi John,

Thanks for the patch. I have had the same problem compiling KiCad with
clang and I confirm that the proposed fix solves the problem, so I
merged it.

Cheers,
Orson

On 07/29/2018 05:34 PM, John Beard wrote:
> Hi Adam,
> 
> Sorry, this in my stuff - I though that was a way to get PI without
> having to guess the setting of _USE_MATH_DEFINES or do #ifdefs like at
> the top of dl_codes.h, but obviously not.
> 
> The attached patch might work, but I can't test on a Mac, so all I can
> say is "it builds for me and the tests pass". Specifically,
> _USE_MATH_DEFINES may need to be set for qa_geometry if not already.
> 
> Cheers,
> 
> John
> 
> 
> On Sun, Jul 29, 2018 at 1:38 PM, Adam Wolf
>  wrote:
>> Hi folks!
>>
>> There's a build failure on the new geometry test stuff with MacOS.
>>
>> qa/geometry/geom_test_utils.h:33:18: error: constexpr variable 'PI'
>> must be initialized by a constant expression
>> constexpr double PI = atan(1.0) * 4.0;
>> ^ ~~~
>> qa/geometry/geom_test_utils.h:33:23: note: non-constexpr function
>> 'atan' cannot be used in a constant expression
>> constexpr double PI = atan(1.0) * 4.0;
>>
>> There are a few others, all which look about the same.  I am on my way
>> out of town today so I don't have time to look for a solution, but a
>> user actually reported it to me due to using the new MacOS build
>> scripts! :D
>>
>> Adam Wolf
>>
>> ___
>> 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] Patch to draw bitmaps in GAL canvases

[jp charras]

Le 30/07/2018 à 00:29, Tomasz Wlostowski a écrit :
> On 27/07/18 15:31, jp charras wrote:
>> Le 27/07/2018 à 15:20, Tomasz Wlostowski a écrit :
>>
> Hi again,
> 
> I've optimized the OpenGL bitmap drawing code (now it caches the bitmaps
> and uses textures to draw them). Both mine and your patch are now in the
> master branch.
> 
> Thanks!
> Tom
> 


Thanks.

I have a strange behavior on OpenGL.

Some bitmaps (not all) are incorrectly drawn (both on Windows and Linux).
I discovered bitmaps that are correctly drawn have a width multiple of 4.

Attached a bitmap incorrectly drawn by OpenGL, and a patch that fixes this 
issue on my Windows install.

Have you encountered this issue (I had a look into glTexImage2D doc. 
glTexImage2D can have some
constraints, but I did not see this constraint)

-- 
Jean-Pierre CHARRAS
 common/gal/opengl/opengl_gal.cpp | 31 +++
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/common/gal/opengl/opengl_gal.cpp b/common/gal/opengl/opengl_gal.cpp
index a3f91a6a9..291b3a4dd 100644
--- a/common/gal/opengl/opengl_gal.cpp
+++ b/common/gal/opengl/opengl_gal.cpp
@@ -65,7 +65,7 @@ bool OPENGL_GAL::isBitmapFontLoaded = false;
 SHADER* OPENGL_GAL::shader = NULL;
 
 namespace KIGFX {
-class GL_BITMAP_CACHE 
+class GL_BITMAP_CACHE
 {
 public:
 GL_BITMAP_CACHE()
@@ -73,11 +73,11 @@ public:
 }
 
 ~GL_BITMAP_CACHE();
-   
+
 GLuint RequestBitmap( const BITMAP_BASE* aBitmap );
 
 private:
-
+
 struct CACHED_BITMAP
 {
 GLuint id;
@@ -85,8 +85,8 @@ private:
 };
 
 GLuint cacheBitmap( const BITMAP_BASE* aBitmap );
-
-std::map m_bitmaps;
+
+std::map m_bitmaps;
 };
 
 };
@@ -121,21 +121,28 @@ GLuint GL_BITMAP_CACHE::cacheBitmap( const BITMAP_BASE* 
aBitmap )
 bmp.w = aBitmap->GetSizePixels().x;
 bmp.h = aBitmap->GetSizePixels().y;
 
+// There are draw issues (incorrect rendering) with some w values.
+// It happens when the w value is not a multiple of 4
+// so we use only a sub image with a modified width
+bmp.w -= bmp.w % 4;
+
 GLuint textureID;
 glGenTextures(1, );
 
 uint8_t *buf = new uint8_t [ bmp.w * bmp.h * 3];
 auto imgData = const_cast( aBitmap )->GetImageData();
 
-for( int y=0; y < bmp.h; y++ )
-for( int x = 0; x < bmp.w;x++)
+for( int y = 0; y < bmp.h; y++ )
+{
+for( int x = 0; x < bmp.w; x++ )
 {
-auto *p = buf + ( bmp.w * y + x ) * 3;
+uint8_t *p = buf + ( bmp.w * y + x ) * 3;
 
 p[0] = imgData->GetRed( x, y );
 p[1] = imgData->GetGreen( x, y );
 p[2] = imgData->GetBlue( x, y );
 }
+}
 
 glBindTexture( GL_TEXTURE_2D, textureID );
 
@@ -998,7 +1005,7 @@ void OPENGL_GAL::DrawBitmap( const BITMAP_BASE& aBitmap )
 
 double w = aBitmap.GetSizePixels().x * pix_size_iu;
 double h = aBitmap.GetSizePixels().y * pix_size_iu;
-
+
 auto xform = currentManager->GetTransformation();
 
 glm::vec4 v0 = xform * glm::vec4( -w/2, -h/2, 0.0, 0.0 );
@@ -1016,7 +1023,7 @@ void OPENGL_GAL::DrawBitmap( const BITMAP_BASE& aBitmap )
 glEnable(GL_TEXTURE_2D);
 glActiveTexture( GL_TEXTURE0 );
 glBindTexture( GL_TEXTURE_2D, id );
-
+
 glBegin( GL_QUADS );
 glColor4f(1.0, 1.0, 1.0, 1.0);
 glTexCoord2f(0.0, 0.0);
@@ -1034,7 +1041,7 @@ void OPENGL_GAL::DrawBitmap( const BITMAP_BASE& aBitmap )
 
 SetTarget( oldTarget );
 glBindTexture( GL_TEXTURE_2D, 0 );
-
+
 glPopMatrix();
 }
 
@@ -1454,7 +1461,7 @@ void OPENGL_GAL::DeleteGroup( int aGroupNumber )
 void OPENGL_GAL::ClearCache()
 {
 bitmapCache.reset( new GL_BITMAP_CACHE );
-
+
 groups.clear();
 
 if( isInitialized )
___
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] Op-amp symbol icons

[John Beard]

While we're at it, new_cvpcb looks like it's also unused: it's built
and listed in bitmaps.h, but nothing ever uses it.

Cheers,

John

On Sat, Jul 28, 2018 at 11:28 PM, Jeff Young  wrote:
> No, looks like I just missed deleting it.
>
>> On 28 Jul 2018, at 23:01, John Beard  wrote:
>>
>> Hi Jeff,
>>
>> Thanks for the heads up, makes life easier with fewer icons!
>>
>> Looks like bitmaps_png/sources/edit_component.svg still exists,
>> though. Is that intentional?
>>
>> Cheers,
>>
>> John
>>
>> On Fri, Jul 27, 2018 at 11:39 AM, Jeff Young  wrote:
>>> Hi John,
>>>
>>> Just an update on the opamp icon list.  These icons:
>>>
>>> copycomponent.svg
>>> edit_component.svg
>>> edit_part.svg
>>> import_cmp_from_lib.svg
>>> save_part.svg
>>> save_part_in_mem.svg
>>>
>>>
>>> no longer exist.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> On 26 Jul 2018, at 09:33, Jeff Young  wrote:
>>>
>>> Hi John,
>>>
>>> Most other icons use a heavier pen width (see the DeMorgan symbols, pin
>>> graphics, etc.), which would favour the B column.
>>>
>>> I like the wider stance of the input pins in row 4.
>>>
>>> BTW, the new black-and-white 16x16 icons for the dialog buttons also suffer
>>> from slight blurryness.  I don’t know if they’re worth fixing or not, but if
>>> you’re so inclined….
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> On 25 Jul 2018, at 15:05, John Beard  wrote:
>>>
>>> Hi,
>>>
>>> The pixel alignment of the op-amp icons looks a bit fuzzy compared to
>>> the other newer icons. These are not the only misaligned icons, but
>>> they are a very prominent set of them.
>>>
>>> The problem is that both:
>>>
>>> 1) The lines are not on the pixel grid
>>> 2) The lines are not a whole number of pixels wide.
>>>
>>> If this *were* to be changed so horizontal lines are sharp, the icons
>>> have to be modified. However, going up to 2px or down to 1px line
>>> width changes the feel a bit.
>>>
>>> Attached are some options (for the full size op-amp icons at 26px). If
>>> a consensus or executive decision ever emerges, I will produce a patch
>>> for the op-amp icons in that style.
>>>
>>> Personally, my "vote" is 2A, or 5A for icons where the symbol is
>>> smaller, like "copycomponent".
>>>
>>> List of icons affected for reference:
>>>
>>> add_component.svg
>>> copycomponent.svg
>>> edit_cmp_symb_links.svg
>>> edit_comp_footprint.svg
>>> edit_comp_ref.svg
>>> edit_comp_value.svg
>>> edit_component.svg
>>> edit_part.svg
>>> export_part.svg
>>> field_properties.svg
>>> hidden_pin.svg
>>> icon_libedit.svg
>>> import_cmp_from_lib.svg
>>> import_part.svg
>>> libedit.svg
>>> new_component.svg
>>> new_cvpcb.svg
>>> part_properties.svg
>>> save_part.svg
>>> save_part_in_mem.svg
>>>
>>> Yours, bike-sheddingly,
>>>
>>> John
>>> ___
>>> 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