date:20160405

Re: [Kicad-developers] a few minor issues in code

2016-04-05 Thread jp charras

Le 04/04/2016 22:56, Cirilo Bernardo a écrit :
> Hi folks,
> 
>  While working on adding a dummy board with footprint to the 3D file
> selector preview,
> I ran across a few issues:
> 
> 1. in 3d-viewer/3d_aux.cpp L59 - L84 there seems to be a cut/paste problem.
> In the "if( m_MatRotation.y )" and "if( m_MatRotation.z )" blocks the
> rotation
> used is m_MatRotation.x.  I have no idea how this affects the operation of
> the
> code thogh.

This is a bug (cut/paste problem).
As Mario said, it was not noticed because it is not used

> 
> 2. class_eda_rect.h is missing "#include ".  If I include that
> header
> without previously including gdicmn.h I get a compile error.
> 
> - Cirilo

Yes, it is missing "#include ".
It was not noticed because most of time class_eda_rect.h is used through the 
base_struct.h file

-- 
Jean-Pierre CHARRAS

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

[Kicad-developers] Merging 3d_initial_merge branch.

2016-04-05 Thread jp charras

Hi, Cirilo.

We (Wayne and me) are willing to merge your 3d_initial_merge branch.

It looks good for now, and adds very good features.

Could you run cppcheck on you code (the 3d-viewer and others new folders)?
(see http://cppcheck.sourceforge.net)
cppcheck is fast, very easy to install and use (just run cppcheck on a given 
folder).

It is no as powerful as Coverity, but it is very helpful especially for a first 
basic analysis
before Coverity is run.

Especially, not initialized members and 3 errors (I am thinking related to 
"delete" versus
"delete[]") must be fixed (but some others could be fixed).
not initialized members create a lot of warning with Coverity, and are 
potential issues, so I am
thinking initializing them is good, even when it is not really needed.

Also there are some not used variables detected by the compiler.

Thanks for your work.

-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] Merging 3d_initial_merge branch.

2016-04-05 Thread Cirilo Bernardo

Thanks Jean-Pierre, Wayne.

 I'll work on this and report when I've done as requested and cleaned up.

- Cirilo


On Tue, Apr 5, 2016 at 6:02 PM, jp charras  wrote:

> Hi, Cirilo.
>
> We (Wayne and me) are willing to merge your 3d_initial_merge branch.
>
> It looks good for now, and adds very good features.
>
> Could you run cppcheck on you code (the 3d-viewer and others new folders)?
> (see http://cppcheck.sourceforge.net)
> cppcheck is fast, very easy to install and use (just run cppcheck on a
> given folder).
>
> It is no as powerful as Coverity, but it is very helpful especially for a
> first basic analysis
> before Coverity is run.
>
> Especially, not initialized members and 3 errors (I am thinking related to
> "delete" versus
> "delete[]") must be fixed (but some others could be fixed).
> not initialized members create a lot of warning with Coverity, and are
> potential issues, so I am
> thinking initializing them is good, even when it is not really needed.
>
> Also there are some not used variables detected by the compiler.
>
> Thanks for your work.
>
> --
> Jean-Pierre CHARRAS
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Merging 3d_initial_merge branch.

2016-04-05 Thread Cirilo Bernardo

Hi Jean-Pierre, Wayne,

 I've run cppcheck and fixed a number of issues:
1. ensured "delete [] X" where "delete X" was accidentally used
2. ensured variable initialization
3. fixed a number of errors and warnings reported by cppcheck
(most of those warnings were in fact errors)

There are still quite a few "variable not used" warnings but those
are in code contributed by Mario so I have left them alone for now.

cppcheck reports a number of "(error, inconclusive)" but I have
checked to make sure that those are in fact not errors and that
the program has actually performed appropriate checks.

All changes have been committed to r6558.  I hope all goes
smoothly and we can start to get more feedback on this new
3D plugin system.

- Cirilo

On Tue, Apr 5, 2016 at 6:02 PM, jp charras  wrote:

> Hi, Cirilo.
>
> We (Wayne and me) are willing to merge your 3d_initial_merge branch.
>
> It looks good for now, and adds very good features.
>
> Could you run cppcheck on you code (the 3d-viewer and others new folders)?
> (see http://cppcheck.sourceforge.net)
> cppcheck is fast, very easy to install and use (just run cppcheck on a
> given folder).
>
> It is no as powerful as Coverity, but it is very helpful especially for a
> first basic analysis
> before Coverity is run.
>
> Especially, not initialized members and 3 errors (I am thinking related to
> "delete" versus
> "delete[]") must be fixed (but some others could be fixed).
> not initialized members create a lot of warning with Coverity, and are
> potential issues, so I am
> thinking initializing them is good, even when it is not really needed.
>
> Also there are some not used variables detected by the compiler.
>
> Thanks for your work.
>
> --
> Jean-Pierre CHARRAS
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Merging 3d_initial_merge branch.

2016-04-05 Thread Mário Luzeiro

Hi all,

Thanks for the ccpcheck suggestion JP, that was something I was looking for 
some time...
(I found already a bug with that!)

"There are still quite a few "variable not used" warnings but those
are in code contributed by Mario so I have left them alone for now."

I am running this also in my branch and found that issues.
I am not sure why but they are false positives, I guess it is the way the 
structures are constructed, example:

GLM_ALIGNED_STRUCT(CLASS_ALIGNMENT) RAY

is uses a define GLM_ALIGNED_STRUCT from GLM library.
probably cppcheck is not able to resolve this define in a proper way.

Any suggestions?

Mario


From: Kicad-developers 
[kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
Cirilo Bernardo [cirilo.berna...@gmail.com]
Sent: 05 April 2016 11:45
To: jp charras
Cc: KiCad Developers
Subject: Re: [Kicad-developers] Merging 3d_initial_merge branch.

Hi Jean-Pierre, Wayne,

 I've run cppcheck and fixed a number of issues:
1. ensured "delete [] X" where "delete X" was accidentally used
2. ensured variable initialization
3. fixed a number of errors and warnings reported by cppcheck
(most of those warnings were in fact errors)

There are still quite a few "variable not used" warnings but those
are in code contributed by Mario so I have left them alone for now.

cppcheck reports a number of "(error, inconclusive)" but I have
checked to make sure that those are in fact not errors and that
the program has actually performed appropriate checks.

All changes have been committed to r6558.  I hope all goes
smoothly and we can start to get more feedback on this new
3D plugin system.

- Cirilo


On Tue, Apr 5, 2016 at 6:02 PM, jp charras 
mailto:jp.char...@wanadoo.fr>> wrote:
Hi, Cirilo.

We (Wayne and me) are willing to merge your 3d_initial_merge branch.

It looks good for now, and adds very good features.

Could you run cppcheck on you code (the 3d-viewer and others new folders)?
(see http://cppcheck.sourceforge.net)
cppcheck is fast, very easy to install and use (just run cppcheck on a given 
folder).

It is no as powerful as Coverity, but it is very helpful especially for a first 
basic analysis
before Coverity is run.

Especially, not initialized members and 3 errors (I am thinking related to 
"delete" versus
"delete[]") must be fixed (but some others could be fixed).
not initialized members create a lot of warning with Coverity, and are 
potential issues, so I am
thinking initializing them is good, even when it is not really needed.

Also there are some not used variables detected by the compiler.

Thanks for your work.

--
Jean-Pierre CHARRAS


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

Re: [Kicad-developers] Merging 3d_initial_merge branch.

2016-04-05 Thread jp charras

Le 05/04/2016 13:23, Mário Luzeiro a écrit :
> Hi all,
> 
> Thanks for the ccpcheck suggestion JP, that was something I was looking for 
> some time...
> (I found already a bug with that!)
> 
> "There are still quite a few "variable not used" warnings but those
> are in code contributed by Mario so I have left them alone for now."
> 
> I am running this also in my branch and found that issues.
> I am not sure why but they are false positives, I guess it is the way the 
> structures are constructed, example:
> 
> GLM_ALIGNED_STRUCT(CLASS_ALIGNMENT) RAY
> 
> is uses a define GLM_ALIGNED_STRUCT from GLM library.
> probably cppcheck is not able to resolve this define in a proper way.
> 
> Any suggestions?
> 
> Mario


Cppcheck, like all static analyzers, is useful to find some errors and mistakes.

However, it is not usually possible (and perhaps not good) to fix all "errors" 
find by a static
analyzer.
There are always false positive or issues detected by the detected which cannot 
really happen due to
the logic of the code.

Just, be sure remaining errors or warnings are acceptable (false positive),
and actual errors and warnings are fixed.

> 
> 
> From: Kicad-developers 
> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
> Cirilo Bernardo [cirilo.berna...@gmail.com]
> Sent: 05 April 2016 11:45
> To: jp charras
> Cc: KiCad Developers
> Subject: Re: [Kicad-developers] Merging 3d_initial_merge branch.
> 
> Hi Jean-Pierre, Wayne,
> 
>  I've run cppcheck and fixed a number of issues:
> 1. ensured "delete [] X" where "delete X" was accidentally used
> 2. ensured variable initialization
> 3. fixed a number of errors and warnings reported by cppcheck
> (most of those warnings were in fact errors)
> 
> There are still quite a few "variable not used" warnings but those
> are in code contributed by Mario so I have left them alone for now.
> 
> cppcheck reports a number of "(error, inconclusive)" but I have
> checked to make sure that those are in fact not errors and that
> the program has actually performed appropriate checks.
> 
> All changes have been committed to r6558.  I hope all goes
> smoothly and we can start to get more feedback on this new
> 3D plugin system.
> 
> - Cirilo
> 
> 
> On Tue, Apr 5, 2016 at 6:02 PM, jp charras 
> mailto:jp.char...@wanadoo.fr>> wrote:
> Hi, Cirilo.
> 
> We (Wayne and me) are willing to merge your 3d_initial_merge branch.
> 
> It looks good for now, and adds very good features.
> 
> Could you run cppcheck on you code (the 3d-viewer and others new folders)?
> (see http://cppcheck.sourceforge.net)
> cppcheck is fast, very easy to install and use (just run cppcheck on a given 
> folder).
> 
> It is no as powerful as Coverity, but it is very helpful especially for a 
> first basic analysis
> before Coverity is run.
> 
> Especially, not initialized members and 3 errors (I am thinking related to 
> "delete" versus
> "delete[]") must be fixed (but some others could be fixed).
> not initialized members create a lot of warning with Coverity, and are 
> potential issues, so I am
> thinking initializing them is good, even when it is not really needed.
> 
> Also there are some not used variables detected by the compiler.
> 
> Thanks for your work.
> 
> --
> Jean-Pierre CHARRAS


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] Merging 3d_initial_merge branch.

2016-04-05 Thread Eldar Khayrullin

Hello. Look at gcc option "-fsanitize=" too.  
![](https://link.nylas.com/open/ac7n0u7eu8cj6vjow9ajimqdr/58d3f403faeb4e22ac36
f827cb89bd7d)

> On апр 5 2016, at 2:45 дня, jp charras  wrote:  

>

> Le 05/04/2016 13:23, Mário Luzeiro a écrit :  
> Hi all,  
>  
> Thanks for the ccpcheck suggestion JP, that was something I was looking
for some time...  
> (I found already a bug with that!)  
>  
> "There are still quite a few "variable not used" warnings but those  
> are in code contributed by Mario so I have left them alone for now."  
>  
> I am running this also in my branch and found that issues.  
> I am not sure why but they are false positives, I guess it is the way the
structures are constructed, example:  
>  
> GLM_ALIGNED_STRUCT(CLASS_ALIGNMENT) RAY  
>  
> is uses a define GLM_ALIGNED_STRUCT from GLM library.  
> probably cppcheck is not able to resolve this define in a proper way.  
>  
> Any suggestions?  
>  
> Mario

>

>  
Cppcheck, like all static analyzers, is useful to find some errors and
mistakes.

>

> However, it is not usually possible (and perhaps not good) to fix all
"errors" find by a static  
analyzer.  
There are always false positive or issues detected by the detected which
cannot really happen due to  
the logic of the code.

>

> Just, be sure remaining errors or warnings are acceptable (false positive),  
and actual errors and warnings are fixed.

>

> >  
>   
> From: Kicad-developers [kicad-developers-
bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of Cirilo Bernardo
[cirilo.berna...@gmail.com]  
> Sent: 05 April 2016 11:45  
> To: jp charras  
> Cc: KiCad Developers  
> Subject: Re: [Kicad-developers] Merging 3d_initial_merge branch.  
>  
> Hi Jean-Pierre, Wayne,  
>  
> I've run cppcheck and fixed a number of issues:  
> 1\. ensured "delete [] X" where "delete X" was accidentally used  
> 2\. ensured variable initialization  
> 3\. fixed a number of errors and warnings reported by cppcheck  
> (most of those warnings were in fact errors)  
>  
> There are still quite a few "variable not used" warnings but those  
> are in code contributed by Mario so I have left them alone for now.  
>  
> cppcheck reports a number of "(error, inconclusive)" but I have  
> checked to make sure that those are in fact not errors and that  
> the program has actually performed appropriate checks.  
>  
> All changes have been committed to r6558. I hope all goes  
> smoothly and we can start to get more feedback on this new  
> 3D plugin system.  
>  
> \- Cirilo  
>  
>  
> On Tue, Apr 5, 2016 at 6:02 PM, jp charras
>; wrote:  
> Hi, Cirilo.  
>  
> We (Wayne and me) are willing to merge your 3d_initial_merge branch.  
>  
> It looks good for now, and adds very good features.  
>  
> Could you run cppcheck on you code (the 3d-viewer and others new
folders)?  
> (see   
> cppcheck is fast, very easy to install and use (just run cppcheck on a
given folder).  
>  
> It is no as powerful as Coverity, but it is very helpful especially for a
first basic analysis  
> before Coverity is run.  
>  
> Especially, not initialized members and 3 errors (I am thinking related
to "delete" versus  
> "delete[]") must be fixed (but some others could be fixed).  
> not initialized members create a lot of warning with Coverity, and are
potential issues, so I am  
> thinking initializing them is good, even when it is not really needed.  
>  
> Also there are some not used variables detected by the compiler.  
>  
> Thanks for your work.  
>  
> \--  
> Jean-Pierre CHARRAS

>

>  
\--  
Jean-Pierre CHARRAS

>

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

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

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

2016-04-05 Thread Miguel Angel Ajo

See 

Changes:

[jean-pierre charras] Merge 3d_initial_merge branch

--
[...truncated 620 lines...]
:73: 
Warning 509: as it is shadowed by UTF8::UTF8(std::string const &).
:73: 
Warning 509: Overloaded method UTF8::UTF8(std::string const &) effectively 
ignored,
:64: 
Warning 509: as it is shadowed by UTF8::UTF8(char const *).
:64: 
Warning 509: Overloaded method UTF8::UTF8(char const *) effectively ignored,
:73: 
Warning 509: as it is shadowed by UTF8::UTF8(std::string const &).
[ 61%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/dialogs/dialog_rescue_each.cpp.o
[ 61%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/cvpcb_mainframe.cpp.o
[ 61%] Generating pcbnew_wrap.cxx, pcbnew.py
[ 61%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/edit_component_in_schematic.cpp.o
../polygon/PolyLine.h:119: Warning 389: operator[] ignored (consider using 
%extend)
:209: 
Warning 325: Nested class not currently supported (uni_iter ignored)
io_mgr.h:517: Warning 325: Nested class not currently supported (RELEASER 
ignored)
:161:
 Warning 401: Nothing known about base class 'KIGFX::VIEW_ITEM'. Ignored.
:187:
 Warning 401: Nothing known about base class 'BASE_SET'. Ignored.
[ 61%] Building CXX object cvpcb/CMakeFiles/cvpcb_kiface.dir/menubar.cpp.o
swig_import_helper fixed for 

:73: 
Warning 509: Overloaded method UTF8::UTF8(std::string const &) effectively 
ignored,
:64: 
Warning 509: as it is shadowed by UTF8::UTF8(char const *).
:64: 
Warning 509: Overloaded method UTF8::UTF8(char const *) effectively ignored,
:73: 
Warning 509: as it is shadowed by UTF8::UTF8(std::string const &).
[ 61%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/eeschema.cpp.o
[ 61%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/readwrite_dlgs.cpp.o
[ 61%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/eeschema_config.cpp.o
swig_import_helper fixed for 

[ 61%] Building CXX object cvpcb/CMakeFiles/cvpcb_kiface.dir/tool_cvpcb.cpp.o
[ 61%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/files-io.cpp.o
[ 61%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/dialog_config_equfiles.cpp.o
Scanning dependencies of target pcbnew_kiface
[ 61%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/find.cpp.o
[ 61%] Building CXX object pcbnew/CMakeFiles/pcbnew_kiface.dir/pcbnew.cpp.o
[ 61%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/dialogs/dialog_fp_lib_table.cpp.o
[ 61%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/getpart.cpp.o
Scanning dependencies of target _pcbnew
[ 61%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/modview_frame.cpp.o
[ 61%] Building CXX object 
pcbnew/CMakeFiles/_pcbnew.dir/scripting/pcbnewPYTHON_wrap.cxx.o
[ 61%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/component_tree_search_container.cpp.o
[ 61%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/dialogs/dialog_fp_plugin_options.cpp.o
[ 61%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/libarch.cpp.o
[ 61%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/dialogs/wizard_add_fplib.cpp.o
[ 61%] Building CXX object pcbnew/CMakeFiles/pcbnew_kiface.dir/pcbframe.cpp.o
[ 61%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/libedit.cpp.o
Linking CXX shared module _cvpcb.kiface
[ 61%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/block_module_editor.cpp.o
[ 61%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/libeditframe.cpp.o
[ 61%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/libedit_plot_component.cpp.o
[ 61%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/build_BOM_from_board.cpp.o
[ 61%] [ 61%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_export.cpp.o
Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface.dir/class_pcb_layer_widget.cpp

Re: [Kicad-developers] Merging 3d_initial_merge branch.

2016-04-05 Thread jp charras

Hi, Cirilo.

I merged your branch in rev 6664.
Thanks for all this work.

-- 
Jean-Pierre CHARRAS

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

[Kicad-developers] RES: [PATCH] new feature, value and reference with angle in PCB

2016-04-05 Thread Pereira, Patrick

Hello,

Some corrections to this path.

Best regards.

De: Chris Pavlina [pavlina.ch...@gmail.com]
Enviado: quinta-feira, 31 de março de 2016 19:03
Para: Pereira, Patrick
Cc: kicad-developers@lists.launchpad.net
Assunto: Re: [Kicad-developers] [PATCH] new feature, value and reference with 
angle in PCB

I like this, but I have a few comments to make.

1. Don't edit the dialogs/*base.cpp files - as they say at the top:

> C++ code generated with wxFormBuilder (version mumble mumble, mumble)
> PLEASE DO "NOT" EDIT THIS FILE!

No matter how tempting it may be to remove the quotes around "NOT" ;) The next
time someone edits the .fbp original, your edits will be lost.

2. There's a bug, if I set a text to Angled, then edit it again, the
Orientation is back to Vertical in the dialog.

3. We should either call it something other than "Angled", or actually allow
arbitrary (non-45deg) angles. It's a bit misleading, I was looking for the
entry field to type in my angle...

4. There may be quite a few places in the code that assume 90 degree
increments, as we've been restricted to that for years. This will have to be
tested pretty thoroughly.

All in all though, I've always thought it was pretty stupid to be limited this
way (in particular, I often want to put text on H and V even if a part itself
is angled), and I'm hugely in favor of this once it's cleaned up a bit and
tested.

On Thu, Mar 31, 2016 at 09:05:01PM +, Pereira, Patrick wrote:
> Hi,
>
> With this patch it'll be possible to use angled text.
>
> Best regards.

From 6a15371286a61996992644171094251568dd6aef Mon Sep 17 00:00:00 2001
From: "Patrick J.P" 
Date: Tue, 5 Apr 2016 19:21:05 -0300
Subject: [PATCH 1/1] Text and Values with -900,+900 range

Now it's possible to use -900,+900 range values in rotation options

Signed-off-by: Patrick J.P 
---
 include/eda_text.h  |   1 -
 pcbnew/class_text_mod.cpp   |   7 +-
 pcbnew/dialogs/dialog_edit_module_text.cpp  | 113 +++-
 pcbnew/dialogs/dialog_edit_module_text.h|   1 +
 pcbnew/dialogs/dialog_edit_module_text_base.cpp | 146 ++---
 pcbnew/dialogs/dialog_edit_module_text_base.fbp | 757 +++-
 pcbnew/dialogs/dialog_edit_module_text_base.h   |  19 +-
 7 files changed, 685 insertions(+), 359 deletions(-)

diff --git a/include/eda_text.h b/include/eda_text.h
index cd14c46..5a0e48b 100644
--- a/include/eda_text.h
+++ b/include/eda_text.h
@@ -135,7 +135,6 @@ public:
 
 void SetOrientation( double aOrientation )
 {
-NORMALIZE_ANGLE_POS( aOrientation );
 m_Orient = aOrientation;
 }
 double GetOrientation() const  { return m_Orient; }
diff --git a/pcbnew/class_text_mod.cpp b/pcbnew/class_text_mod.cpp
index 09cd57a..005cefe 100644
--- a/pcbnew/class_text_mod.cpp
+++ b/pcbnew/class_text_mod.cpp
@@ -340,12 +340,13 @@ double TEXTE_MODULE::GetDrawRotation() const
 if( module )
 rotation += module->GetOrientation();
 
-NORMALIZE_ANGLE_POS( rotation );
-
-// For angle = 0 .. 180 deg
+// For angle = -90 .. 90 deg
 while( rotation > 900 )
 rotation -= 1800;
 
+while( rotation < -900 )
+rotation += 1800;
+
 return rotation;
 }
 
diff --git a/pcbnew/dialogs/dialog_edit_module_text.cpp b/pcbnew/dialogs/dialog_edit_module_text.cpp
index 03ecc1f..a5346d0 100644
--- a/pcbnew/dialogs/dialog_edit_module_text.cpp
+++ b/pcbnew/dialogs/dialog_edit_module_text.cpp
@@ -159,6 +159,34 @@ void DialogEditModuleText::initDlg( )
 if( !m_currentText->IsVisible() )
 m_Show->SetSelection( 1 );
 
+bool select = false;
+switch( int( m_currentText->GetOrientation() ) )
+{
+case 0:
+m_Orient->SetSelection( 0 );
+break;
+
+case 900:
+case -2700:
+m_Orient->SetSelection( 1 );
+break;
+
+case -900:
+case 2700:
+m_Orient->SetSelection( 2 );
+break;
+
+default:
+m_Orient->SetSelection( 3 );
+select = true;
+break;
+}
+
+wxString msg2;
+msg2 << m_currentText->GetOrientation();
+m_OrientValue->SetValue( msg2 );
+m_OrientValue->Enable( select );
+
 // Configure the layers list selector
 if( !m_parent->GetBoard()->IsLayerEnabled( m_currentText->GetLayer() ) )
 // Footprints are built outside the current board, so items cann be
@@ -178,6 +206,30 @@ void DialogEditModuleText::initDlg( )
 }
 }
 
+void DialogEditModuleText::ModuleOrientEvent( wxCommandEvent& event )
+{
+switch( m_Orient->GetSelection() )
+{
+case 0:
+m_OrientValue->Enable( false );
+m_OrientValue->SetValue( wxT( "0" ) );
+break;
+
+case 1:
+m_OrientValue->Enable( false );
+m_OrientValue->SetValue( wxT( "900" ) );
+break;
+
+case 2:
+m_OrientValue->Enable( false );
+m_OrientValue->SetValue( wxT( "-900" ) );
+break;
+
+default:
+m_Orien

[Kicad-developers] PATCH: fix segfault in python scripting caused by new 3D code

2016-04-05 Thread Cirilo Bernardo

The attached patch ensures the S3D_MASTER class does not cause
a segfault in pcbnew when used from Python scripting.

The issue is due to an "extern KIWAY* TheKiway" which was exposed
to allow S3D_MASTER to use the new resolver to handle 3D filenames.
Unfortunately TheKiway cannot be assigned a value until a window is
created which implements Kiway. The change introduced by this
patch should not alter the behavior of S3D_MASTER compared to
the behavior before the 3D merge.

The extern variable is only there to support S3D_MASTER which in
turn is there to support the current 3DViewer. In the planned software
structure the rather complex S3D_MASTER class is replaced with
a simple struct which only holds the model name and position/
orientation/scale data as stored in the PCB file; since the replacement
does not perform filename resolution there is no need to expose the
Kiway. For example in Mario's branch we removed the extern and
S3D_MASTER class many months ago.

- Cirilo
=== modified file '3d-viewer/3d_class.cpp'
--- 3d-viewer/3d_class.cpp	2015-12-09 05:43:30 +
+++ 3d-viewer/3d_class.cpp	2016-04-05 22:51:29 +
@@ -141,8 +141,11 @@
 else
 m_Shape3DFullFilename = m_Shape3DName;
 
-m_Shape3DFullFilename = TheKiway->Prj().Get3DCacheManager()->GetResolver()
-->ResolvePath( m_Shape3DFullFilename );
+if( NULL != TheKiway )
+{
+m_Shape3DFullFilename = TheKiway->Prj().Get3DCacheManager()->GetResolver()
+->ResolvePath( m_Shape3DFullFilename );
+}
 
 return;
 }

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

Re: [Kicad-developers] PATCH: fix segfault in python scripting caused by new 3D code

2016-04-05 Thread Chris Pavlina

Committed in rev 6665. Thank you.

On Wed, Apr 06, 2016 at 09:10:23AM +1000, Cirilo Bernardo wrote:
> The attached patch ensures the S3D_MASTER class does not cause
> a segfault in pcbnew when used from Python scripting.
> 
> The issue is due to an "extern KIWAY* TheKiway" which was exposed
> to allow S3D_MASTER to use the new resolver to handle 3D filenames.
> Unfortunately TheKiway cannot be assigned a value until a window is
> created which implements Kiway. The change introduced by this
> patch should not alter the behavior of S3D_MASTER compared to
> the behavior before the 3D merge.
> 
> The extern variable is only there to support S3D_MASTER which in
> turn is there to support the current 3DViewer. In the planned software
> structure the rather complex S3D_MASTER class is replaced with
> a simple struct which only holds the model name and position/
> orientation/scale data as stored in the PCB file; since the replacement
> does not perform filename resolution there is no need to expose the
> Kiway. For example in Mario's branch we removed the extern and
> S3D_MASTER class many months ago.
> 
> - Cirilo


___
Mailing list: https://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 : KiCad (Linux, all options, Debug) #1230

2016-04-05 Thread 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] RES: [PATCH] new feature, value and reference with angle in PCB

2016-04-05 Thread Chris Pavlina

Okay, I like this a lot more now.

I'm going to run my own build with this patch for a little while to make sure
nothing else comes up. If not, and nobody else minds, I'll accept it.

The dialog looks a little bit off to me - there's some extra padding on the
right that shouldn't be there by default. I'll have a look at that myself
later, though if you know what the issue is I'd happily accept a fix :)

On Tue, Apr 05, 2016 at 10:26:08PM +, Pereira, Patrick wrote:
> Hello,
> 
> Some corrections to this path.
> 
> Best regards.
> 
> De: Chris Pavlina [pavlina.ch...@gmail.com]
> Enviado: quinta-feira, 31 de março de 2016 19:03
> Para: Pereira, Patrick
> Cc: kicad-developers@lists.launchpad.net
> Assunto: Re: [Kicad-developers] [PATCH] new feature, value and reference with 
> angle in PCB
> 
> I like this, but I have a few comments to make.
> 
> 1. Don't edit the dialogs/*base.cpp files - as they say at the top:
> 
> > C++ code generated with wxFormBuilder (version mumble mumble, mumble)
> > PLEASE DO "NOT" EDIT THIS FILE!
> 
> No matter how tempting it may be to remove the quotes around "NOT" ;) The next
> time someone edits the .fbp original, your edits will be lost.
> 
> 2. There's a bug, if I set a text to Angled, then edit it again, the
> Orientation is back to Vertical in the dialog.
> 
> 3. We should either call it something other than "Angled", or actually allow
> arbitrary (non-45deg) angles. It's a bit misleading, I was looking for the
> entry field to type in my angle...
> 
> 4. There may be quite a few places in the code that assume 90 degree
> increments, as we've been restricted to that for years. This will have to be
> tested pretty thoroughly.
> 
> All in all though, I've always thought it was pretty stupid to be limited this
> way (in particular, I often want to put text on H and V even if a part itself
> is angled), and I'm hugely in favor of this once it's cleaned up a bit and
> tested.
> 
> On Thu, Mar 31, 2016 at 09:05:01PM +, Pereira, Patrick wrote:
> > Hi,
> >
> > With this patch it'll be possible to use angled text.
> >
> > Best regards.
> 


___
Mailing list: https://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] swig/scripting breakage?

2016-04-05 Thread Mark Roszko

So I believe the C++11 enabling broke this but I really haven't had
the time to look into it.
This is from the server I use purely for coverity builds. Its
basically "clean' (no development junk).


mroszko@ip-XXX:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.4 LTS
Release:14.04
Codename:   trusty




mroszko@ip-XXX:~$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4





/home/mroszko/kicad/pcbnew/pcbnew_wrap.cxx: In function ‘PyObject*
_wrap_str_utf8_Map_erase__SWIG_2(PyObject*, PyObject*)’:
/home/mroszko/kicad/pcbnew/pcbnew_wrap.cxx:29887:26: error: no
matching function for call to ‘std::map, UTF8,
std::less >, std::allocator, UTF8> >
>::erase(SwigValueWrapper, UTF8> > >&,
SwigValueWrapper, UTF8> > >&)’
   (arg1)->erase(arg2,arg3);
  ^
/home/mroszko/kicad/pcbnew/pcbnew_wrap.cxx:29887:26: note: candidates are:
In file included from /usr/include/c++/4.8/map:61:0,
 from /home/mroszko/kicad/pcbnew/pcbnew_wrap.cxx:4981:
/usr/include/c++/4.8/bits/stl_map.h:690:7: note: std::map<_Key, _Tp,
_Compare, _Alloc>::iterator std::map<_Key, _Tp, _Compare,
_Alloc>::erase(std::map<_Key, _Tp, _Compare, _Alloc>::const_iterator)
[with _Key = std::basic_string; _Tp = UTF8; _Compare =
std::less >; _Alloc =
std::allocator, UTF8> >;
std::map<_Key, _Tp, _Compare, _Alloc>::iterator =
std::_Rb_tree_iterator, UTF8>
>; std::map<_Key, _Tp, _Compare, _Alloc>::const_iterator =
std::_Rb_tree_const_iterator,
UTF8> >]
   erase(const_iterator __position)
   ^
/usr/include/c++/4.8/bits/stl_map.h:690:7: note:   candidate expects 1
argument, 2 provided
/usr/include/c++/4.8/bits/stl_map.h:696:7: note: std::map<_Key, _Tp,
_Compare, _Alloc>::iterator std::map<_Key, _Tp, _Compare,
_Alloc>::erase(std::map<_Key, _Tp, _Compare, _Alloc>::iterator) [with
_Key = std::basic_string; _Tp = UTF8; _Compare =
std::less >; _Alloc =
std::allocator, UTF8> >;
std::map<_Key, _Tp, _Compare, _Alloc>::iterator =
std::_Rb_tree_iterator, UTF8>
>]
   erase(iterator __position)
   ^
/usr/include/c++/4.8/bits/stl_map.h:696:7: note:   candidate expects 1
argument, 2 provided
/usr/include/c++/4.8/bits/stl_map.h:726:7: note: std::map<_Key, _Tp,
_Compare, _Alloc>::size_type std::map<_Key, _Tp, _Compare,
_Alloc>::erase(const key_type&) [with _Key = std::basic_string;
_Tp = UTF8; _Compare = std::less >; _Alloc =
std::allocator, UTF8> >;
std::map<_Key, _Tp, _Compare, _Alloc>::size_type = long unsigned int;
std::map<_Key, _Tp, _Compare, _Alloc>::key_type =
std::basic_string]

   erase(const key_type& __x)
   ^
/usr/include/c++/4.8/bits/stl_map.h:726:7: note:   candidate expects 1
argument, 2 provided
/usr/include/c++/4.8/bits/stl_map.h:746:7: note: std::map<_Key, _Tp,
_Compare, _Alloc>::iterator std::map<_Key, _Tp, _Compare,
_Alloc>::erase(std::map<_Key, _Tp, _Compare, _Alloc>::const_iterator,
std::map<_Key, _Tp, _Compare, _Alloc>::const_iterator) [with _Key =
std::basic_string; _Tp = UTF8; _Compare =
std::less >; _Alloc =
std::allocator, UTF8> >;
std::map<_Key, _Tp, _Compare, _Alloc>::iterator =
std::_Rb_tree_iterator, UTF8>
>; std::map<_Key, _Tp, _Compare, _Alloc>::const_iterator =
std::_Rb_tree_const_iterator,
UTF8> >]
   erase(const_iterator __first, const_iterator __last)
   ^
/usr/include/c++/4.8/bits/stl_map.h:746:7: note:   no known conversion
for argument 1 from
‘SwigValueWrapper, UTF8> > >’ to
‘std::map, UTF8,
std::less >, std::allocator, UTF8> > >::const_iterator {aka
std::_Rb_tree_const_iterator,
UTF8> >}’
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/pcbnew_wrap.cxx.o] Error 1
make[1]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2


Anyone have any thoughts?

I am probably going to disable scripting for now.

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

[Kicad-developers] RFC: out-of-tree plugin builds

2016-04-05 Thread Cirilo Bernardo

With the recent merge of the 3D plugin work we must now address
some new issues which have come about due to the introduction
of plugins and a shared library (kicad_3dsg). In particular, users
who wish to create out-of-tree plugins will now need to find the vital
kicad headers and necessary shared libraries (at the moment only
kicad_3dsg).

For the 3D plugins and kicad_3dsg all of the necessary header files
have been placed in the include/plugins directory. At the moment
there are no CMake instructions to install header files since I wanted
some feedback on the options and their effects of in-tree source code.

I think the best place to install the headers would be within
${SOME_SYSTEM_PATH}/include/kicad and subdirectories
within (at the moment only plugins/ and its subdirs). We will need to
provide a FindKicad.cmake file or an appropriate CMake package
file to discover these headers and the associated libraries.

What I am not so certain of is the expected behavior of the
find script:

Option1: Kicad_INCLUDE_DIR is set to:
${SOME_SYSTEM_PATH}/include/kicad
This would require no changes to the kicad source since
the kicad headers use the form "plugins/whatever" to include
headers related to the plugin system. However, some people
might argue that it's not clear that we're thinking of kicad
plugins and might prefer:

Option2: Kicad_INCLUDE_DIR is set to:
${SOME_SYSTEM_PATH}/include
This would require the following changes to headers and
directory structure:
a. headers change from using #include "plugins/whatever" to
#include "kicad/plugins/whatever"
b. move the directory include/plugins to include/kicad/plugins
-- however I'm not so comfortable having a 'kicad' directory
within the main branch's "include" dir.

Some thought has to go into what KiCad may be like in the
future - will we have more shared libraries, will we have only
plugin-related shared libs and headers or is it possible we
will have others. For example if we were certain that we
will only have plugin headers then we can install headers to
${SOME_SYSTEM_PATH}/include/kicad-plugins and
the include/plugins directory can simply be changed to
include/kicad-plugins and appropriate changes made to
existing headers and in-tree code.

Any comments/suggestions?

PS: Some tutorial code is largely written but is awkward
because of this situation where kicad does not (yet) install
headers. I plan to clean it up and push to the documentation
repository as soon as these last issues are addressed.

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

[Kicad-developers] [PATCH] Drop dependency on mm_malloc.h

2016-04-05 Thread Simon Richter

Hi,

apparently, the only mention of the string "mm_malloc" in the entire
codebase is this include, so there should be no ill effects from dropping
it.

   Simon

Simon Richter (1):
  Drop dependency on 

 include/plugins/3dapi/xv3d_types.h | 1 -
 1 file changed, 1 deletion(-)

-- 
2.1.4

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

[Kicad-developers] [PATCH] Drop dependency on

2016-04-05 Thread Simon Richter


This appears to be unused.
---
 include/plugins/3dapi/xv3d_types.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/plugins/3dapi/xv3d_types.h b/include/plugins/3dapi/xv3d_types.h
index 630d057..43222d6 100644
--- a/include/plugins/3dapi/xv3d_types.h
+++ b/include/plugins/3dapi/xv3d_types.h
@@ -37,7 +37,6 @@
 
 #include 
 #include 
-#include 
 
 typedef glm::uvec2  SFVEC2UI;
 typedef glm::ivec2  SFVEC2I;
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Enable C++11

2016-04-05 Thread Simon Richter


This enables C++11 support, if either CMake is sufficiently new to have
this feature built in, or the compiler is supported by the workaround code
(gcc or clang).
---
 CMakeLists.txt | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 071dae6..c8f7bb0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -82,6 +82,11 @@ set( CMAKE_VISIBILITY_INLINES_HIDDEN ON )
 set( CMAKE_POSITION_INDEPENDENT_CODE ON )
 
 
+# Global setting: Use C++11
+set(CMAKE_CXX_STANDARD 11)
+set(CMAKE_CXX_STANDARD_REQUIRED ON)
+
+
 # CMP0063: CMake < 3.3 does not handle hidden visibility for static libraries,
 # and 3.3 is backwards compatible when the minimum version is smaller than 3.3.
 if( POLICY CMP0063 )
@@ -129,6 +134,24 @@ include( PerformFeatureChecks )
 perform_feature_checks()
 
 
+# Workaround: CMake < 3.1 does not support CMAKE_CXX_STANDARD
+if( NOT CMAKE_MINIMUM_REQUIRED_VERSION VERSION_LESS 3.1 )
+message( FATAL_ERROR "Remove compatibility code" )
+endif()
+
+if( CMAKE_VERSION VERSION_LESS 3.1 AND ( CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang" ) )
+include(CheckCXXCompilerFlag)
+
+CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)
+
+if(COMPILER_SUPPORTS_CXX11)
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
+else()
+message(STATUS "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support. Please use a different C++ compiler.")
+endif()
+endif()
+
+
 #
 # Set flags for GCC, or treat llvm as GCC
 #
___
Mailing list: https://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] Enable C++11

2016-04-05 Thread Simon Richter

Hi,

On 06.04.2016 05:19, Simon Richter wrote:

> This enables C++11 support, if either CMake is sufficiently new to have
> this feature built in, or the compiler is supported by the workaround code
> (gcc or clang).

Meh, that patch was still in the temp dir where I stage mails before
sending. As C++11 support is already there, please ignore :/

   Simon




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

[Kicad-developers] [PATCH 0/2] Two small portability patches

2016-04-05 Thread Simon Richter

Hi,

these should be fairly obvious:

 - all Windows platforms use declspec(dllexport)
 - MSVC does not set a symbol called "MSVC"
 - use wxFileName to access the FS rather than POSIX

   Simon

Simon Richter (2):
  Fix condition for Windows-style DLL export
  Make file test more portable

 3d-viewer/3d_cache/3d_cache.cpp   | 8 +---
 include/plugins/3dapi/ifsg_defs.h | 2 +-
 2 files changed, 2 insertions(+), 8 deletions(-)

-- 
2.1.4

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

[Kicad-developers] [PATCH 2/2] Make file test more portable

2016-04-05 Thread Simon Richter

---
 3d-viewer/3d_cache/3d_cache.cpp | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/3d-viewer/3d_cache/3d_cache.cpp b/3d-viewer/3d_cache/3d_cache.cpp
index e69d923..697ac5e 100644
--- a/3d-viewer/3d_cache/3d_cache.cpp
+++ b/3d-viewer/3d_cache/3d_cache.cpp
@@ -514,13 +514,7 @@ bool S3D_CACHE::saveCacheData( S3D_CACHE_ENTRY* aCacheItem )
 
 if( wxFileName::Exists( fname ) )
 {
-// determine if the file is a regular file
-struct stat info;
-
-if( stat( fname.ToUTF8(), &info ) )
-return false;
-
-if( !S_ISREG( info.st_mode ) )
+if( !wxFileName::FileExists( fname ) )
 {
 wxString errmsg = _( "path exists but is not a regular file" );
 wxLogTrace( MASK_3D_CACHE, " * [3D model] %s '%s'\n", errmsg.ToUTF8(),
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH 1/2] Fix condition for Windows-style DLL export

2016-04-05 Thread Simon Richter

---
 include/plugins/3dapi/ifsg_defs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/plugins/3dapi/ifsg_defs.h b/include/plugins/3dapi/ifsg_defs.h
index 0523bf1..d0fd56d 100644
--- a/include/plugins/3dapi/ifsg_defs.h
+++ b/include/plugins/3dapi/ifsg_defs.h
@@ -31,7 +31,7 @@
 #ifndef IFSG_DEFS_H
 #define IFSG_DEFS_H
 
-#if defined(__MINGW32__) || defined( MSVC )
+#if defined(_WIN32)
 #define APIEXPORT __declspec(dllexport)
 #define APIIMPORT __declspec(dllimport)
 #define APILOCAL
___
Mailing list: https://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] a few minor issues in code

[Kicad-developers] Merging 3d_initial_merge branch.

Re: [Kicad-developers] Merging 3d_initial_merge branch.

Re: [Kicad-developers] Merging 3d_initial_merge branch.

Re: [Kicad-developers] Merging 3d_initial_merge branch.

Re: [Kicad-developers] Merging 3d_initial_merge branch.

Re: [Kicad-developers] Merging 3d_initial_merge branch.

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

Re: [Kicad-developers] Merging 3d_initial_merge branch.

[Kicad-developers] RES: [PATCH] new feature, value and reference with angle in PCB

[Kicad-developers] PATCH: fix segfault in python scripting caused by new 3D code

Re: [Kicad-developers] PATCH: fix segfault in python scripting caused by new 3D code

[Kicad-developers] Jenkins build is back to normal : KiCad (Linux, all options, Debug) #1230

Re: [Kicad-developers] RES: [PATCH] new feature, value and reference with angle in PCB

[Kicad-developers] swig/scripting breakage?

[Kicad-developers] RFC: out-of-tree plugin builds

[Kicad-developers] [PATCH] Drop dependency on mm_malloc.h

[Kicad-developers] [PATCH] Drop dependency on

[Kicad-developers] [PATCH] Enable C++11

Re: [Kicad-developers] [PATCH] Enable C++11

[Kicad-developers] [PATCH 0/2] Two small portability patches

[Kicad-developers] [PATCH 2/2] Make file test more portable

[Kicad-developers] [PATCH 1/2] Fix condition for Windows-style DLL export

23 matches

Site Navigation

Mail list logo

Footer information