[Kicad-developers] OCE and KiCad

[Cirilo Bernardo]

I have had an out-of-tree IGES/STEP 3D plugin based on OCE
for a few months now. I'd like to get this plugin into the main
branch but there are some OCE issues that need to be resolved
and which I'd need some help with:

1. Do we use only OCE or a choice of OCE or OpenCascade?

2. What is the availability of OCE/OpenCascade on the
different platforms and how do we ensure run-time linkage?
On Linux the run-time linkage is not a problem, but I don't
know how things work on OSX and Windows is a free-for-all
which may require us to build OCE for distribution to ensure
that everything works.

FreeCAD can use either OCE or OpenCascade so we can
use their FindOCE.cmake script as a starting point for
detecting OCE/OpenCascade.

I think Nick has managed to compile OCE with MSys2/MinGW
but I've had no luck.

If we have enough interested devs on OSX/Linux/Windows I
think we need to make up a small team to work on the OCE
issues so we can get the 3D plugin into KiCad. This is also
an important step towards realizing a STEP exporter.

I also expect other issues to pop up such as available
versions of OCE on different platforms/distributions
(some versions of OCE are actually unusable due to
fatal bugs) and various compiler issues (is c++11 supported
by the compiler or not, etc). This is why I created the OCE
plugin as a separate project rather than starting off as a
kicad branch.

Any comments/suggestions or devs who will volunteer to
be part of the team making this happen?

- 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

Re: [Kicad-developers] Stable release bug fixes.

[Michael Steinberg]

Hello Wayne,

Am 05.07.2016 um 17:14 schrieb Wayne Stambaugh:

While I'm on the subject @Michael, would you please back port your boost
context 1.61 patch?  I'm sure at some point in the not too distant
future, someone will try to build stable version 4 against boost 1.61.
After having spent the last few hours with building Kicad stable 4, I 
investigated the backporting. I fear I will be unable to backport 
boost::context 1.61 compatiblity to stable under the restriction of 
c++03, as the library specifies c++11 as minimum (it uses  
and  now f.e.). So I'm feeling a bit unfortunate. It might be 
possible to come up with a hack for this particular version using the 
detail namespace. I don't know if that's okay by the policy and it could 
break with any new version. It could be that it's less work than I fear, 
by simply retargeting the detail namespace, but I would only investigate 
if that's an option at all.


Michael


___
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] Trouble with bitmapped font

[Mário Luzeiro]

Hi Lorenzo,

I was about to comment, I have no single experience with shaders, but from what 
I understood from KiCad shaders, they are "automatic generated" (converted from 
text file to CPP file?) during build? cmake? time..

So what you describe looks to be that it was using the old shader (as it was 
reporting a miss uniform var) instead of  the new one.

That explains why clean & rebuild fixed the issue.

Regards,
Mario Luzeiro


From: Kicad-developers 
[kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
Lorenzo Marcantonio [l.marcanto...@cz-dynamic.it]
Sent: 05 July 2016 20:56
To: Kicad Developers
Subject: Re: [Kicad-developers] Trouble with bitmapped font

On Tue, Jul 05, 2016 at 09:21:05PM +0200, Lorenzo Marcantonio wrote:
> I fear that's yet another intel gpu issue :((

False alarm... *this time* was not because of my GPU suckitude :D

For some reason a full recompile fixed the thing.

AND the ugly text inconsitencies are gone! Woot!

Good work, keep going on with it. Next week will test the whole ordeal
on a six layers...

--
Lorenzo Marcantonio
Logos Srl

___
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] Trouble with bitmapped font

[Lorenzo Marcantonio]

On Tue, Jul 05, 2016 at 09:21:05PM +0200, Lorenzo Marcantonio wrote:
> I fear that's yet another intel gpu issue :((

False alarm... *this time* was not because of my GPU suckitude :D

For some reason a full recompile fixed the thing.

AND the ugly text inconsitencies are gone! Woot!

Good work, keep going on with it. Next week will test the whole ordeal
on a six layers...

-- 
Lorenzo Marcantonio
Logos Srl


smime.p7s
Description: S/MIME cryptographic 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 proposal v2] Fix bitset access outside boundaries in LSET::FmtHex()

[Michael Steinberg]

Same as before, but I missed "int" in a nested loop. I'm sorry for 
polluting the list, I should have checked better. Learning it the 
embarrassing way :(
>From 1d3167c53618b01d77d6d3fa9aea46d0da3e1ce0 Mon Sep 17 00:00:00 2001
From: decimad 
Date: Tue, 5 Jul 2016 19:16:55 +0200
Subject: [PATCH] Fix bitset access outside boundaries in LSET::FmtHex().
 Refactor Fmt and Parse a bit to make them look more alike. Use size_t for
 indices and sizes.

---
 common/lset.cpp   | 52 ++-
 include/layers_id_colors_and_visibility.h |  4 +--
 pcbnew/pcb_plot_params.cpp|  1 +
 3 files changed, 20 insertions(+), 37 deletions(-)

diff --git a/common/lset.cpp b/common/lset.cpp
index 4e4248d..51ea934 100644
--- a/common/lset.cpp
+++ b/common/lset.cpp
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -229,9 +230,7 @@ std::string LSET::FmtBin() const
 {
 std::string ret;
 
-int bit_count = size();
-
-for( int bit=0;  bit rend )
+/// @todo Even the old version parses "_" to a set of zeros.
+for( size_t bit = 0; bit < size() && index > 0; )
 {
-int cc = *rstart--;
+// parse in reverse order!
+unsigned int cc = aStart[--index];
 
 if( cc == '_' )
 continue;
 
-int nibble;
+unsigned int nibble;
 
 if( cc >= '0' && cc <= '9' )
 nibble = cc - '0';
@@ -310,21 +300,13 @@ int LSET::ParseHex( const char* aStart, int aCount )
 else
 break;
 
-int bit = nibble_ndx * 4;
-
-for( int ndx=0; bit( bit + 4, size() ); ++i )
+tmp.set( i, (nibble & (1 << (i & 3))) != 0 );
 
-if( bit >= bitcount )
-break;
-
-++nibble_ndx;
+bit += 4;
 }
 
-int byte_count = aStart + aCount - 1 - rstart;
-
-assert( byte_count >= 0 );
+size_t byte_count = aCount - index;
 
 if( byte_count > 0 )
 *this = tmp;
diff --git a/include/layers_id_colors_and_visibility.h b/include/layers_id_colors_and_visibility.h
index db72495..a59537c 100644
--- a/include/layers_id_colors_and_visibility.h
+++ b/include/layers_id_colors_and_visibility.h
@@ -365,9 +365,9 @@ public:
  * with those given in the input string.  Parsing stops at the first
  * non hex ASCII byte, except that marker bytes output from FmtHex are
  * not terminators.
- * @return int - number of bytes consumed
+ * @return size_t - number of bytes consumed
  */
-int ParseHex( const char* aStart, int aCount );
+size_t ParseHex( const char* aStart, size_t aCount );
 
 /**
  * Function FmtBin
diff --git a/pcbnew/pcb_plot_params.cpp b/pcbnew/pcb_plot_params.cpp
index ffcf96e..16104e0 100644
--- a/pcbnew/pcb_plot_params.cpp
+++ b/pcbnew/pcb_plot_params.cpp
@@ -369,6 +369,7 @@ void PCB_PLOT_PARAMS_PARSER::Parse( PCB_PLOT_PARAMS* aPcbPlotParams )
 else if( cur.find_first_of( "0x" ) == 0 )   // pretty ver. 4.
 {
 // skip the leading 2 0x bytes.
+assert( cur.size() >= 2 );  // implicit assumption now explicit.
 aPcbPlotParams->m_layerSelection.ParseHex( cur.c_str()+2, cur.size()-2 );
 }
 else
-- 
2.9.0.windows.1

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

[Kicad-developers] Trouble with bitmapped font

[Lorenzo Marcantonio]

I fear that's yet another intel gpu issue :((

After updating to a pcbnew with the new opengl bitmap font code it
doesn't work anymore. It says:

Unhandled exception class: St13runtime_error what: Could not find shader
uniform: fontTexture

stracing the thing (I tought it was some file missing...) I've seen it
looking for libtxc_dxtc (which I promply added); that wasn't it, still
faulting. Maybe it's some build issue, now I'm redoing a full
clean/cmake cycle to see if it get better.

The GPU is an Intel GM45/GMA X4500M, so it *should* work with OpenGL 2
or shader model 4. It crawled with complex boards but at least it worked:P
No idea on what is needed for the bitmapped text...

Any idea on how to troubleshoot the thing?

-- 
Lorenzo Marcantonio


smime.p7s
Description: S/MIME cryptographic 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 proposal] Fix bitset access outside boundaries in LSET::FmtHex()

[Michael Steinberg]

The current implementation of LSET::FmtHex would access bits outside the 
range of of the bitset. I combined the fix with a code refactorization 
that clears up things in my opinion, which of course is the one that 
does not count ;) A save/reload cycle in debug builds that would crash 
does not crash anymore and seems to leave the data intact. Also 
introduce size_t for sizes and indices.


>From 7c4238af4811a281288290dd229b9250d22e1fe9 Mon Sep 17 00:00:00 2001
From: decimad 
Date: Tue, 5 Jul 2016 19:16:55 +0200
Subject: [PATCH] Fix bitset access outside boundaries in LSET::FmtHex().
 Refactor Fmt and Parse a bit to make them look more alike. Use size_t for
 indices and sizes.

---
 common/lset.cpp   | 52 ++-
 include/layers_id_colors_and_visibility.h |  4 +--
 pcbnew/pcb_plot_params.cpp|  1 +
 3 files changed, 20 insertions(+), 37 deletions(-)

diff --git a/common/lset.cpp b/common/lset.cpp
index 4e4248d..2996feb 100644
--- a/common/lset.cpp
+++ b/common/lset.cpp
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -229,9 +230,7 @@ std::string LSET::FmtBin() const
 {
 std::string ret;
 
-int bit_count = size();
-
-for( int bit=0;  bit rend )
+/// @todo Even the old version parses "_" to a set of zeros.
+for( size_t bit = 0; bit < size() && index > 0; )
 {
-int cc = *rstart--;
+// parse in reverse order!
+unsigned int cc = aStart[--index];
 
 if( cc == '_' )
 continue;
 
-int nibble;
+unsigned int nibble;
 
 if( cc >= '0' && cc <= '9' )
 nibble = cc - '0';
@@ -310,21 +300,13 @@ int LSET::ParseHex( const char* aStart, int aCount )
 else
 break;
 
-int bit = nibble_ndx * 4;
-
-for( int ndx=0; bit( bit + 4, size() ); ++i )
+tmp.set( i, (nibble & (1 << (i & 3))) != 0 );
 
-if( bit >= bitcount )
-break;
-
-++nibble_ndx;
+bit += 4;
 }
 
-int byte_count = aStart + aCount - 1 - rstart;
-
-assert( byte_count >= 0 );
+size_t byte_count = aCount - index;
 
 if( byte_count > 0 )
 *this = tmp;
diff --git a/include/layers_id_colors_and_visibility.h b/include/layers_id_colors_and_visibility.h
index db72495..a59537c 100644
--- a/include/layers_id_colors_and_visibility.h
+++ b/include/layers_id_colors_and_visibility.h
@@ -365,9 +365,9 @@ public:
  * with those given in the input string.  Parsing stops at the first
  * non hex ASCII byte, except that marker bytes output from FmtHex are
  * not terminators.
- * @return int - number of bytes consumed
+ * @return size_t - number of bytes consumed
  */
-int ParseHex( const char* aStart, int aCount );
+size_t ParseHex( const char* aStart, size_t aCount );
 
 /**
  * Function FmtBin
diff --git a/pcbnew/pcb_plot_params.cpp b/pcbnew/pcb_plot_params.cpp
index ffcf96e..16104e0 100644
--- a/pcbnew/pcb_plot_params.cpp
+++ b/pcbnew/pcb_plot_params.cpp
@@ -369,6 +369,7 @@ void PCB_PLOT_PARAMS_PARSER::Parse( PCB_PLOT_PARAMS* aPcbPlotParams )
 else if( cur.find_first_of( "0x" ) == 0 )   // pretty ver. 4.
 {
 // skip the leading 2 0x bytes.
+assert( cur.size() >= 2 );  // implicit assumption now explicit.
 aPcbPlotParams->m_layerSelection.ParseHex( cur.c_str()+2, cur.size()-2 );
 }
 else
-- 
2.9.0.windows.1

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

[Kicad-developers] [PATCH] Add size_t to "common.h" and remove KIROUND in favor of constexpr.

[Michael Steinberg]

Add size_t to common.h for everyone to use. While touching that file 
also remove KIROUND macro and make the function constexpr replacing the 
compile-time functionality of the macro.
>From 18cc52ed083a4c76ed3a845a77f0167d76bd5534 Mon Sep 17 00:00:00 2001
From: decimad 
Date: Tue, 5 Jul 2016 19:09:37 +0200
Subject: [PATCH] Add size_t declaration to "common.h". Remove KIROUND. Make
 KiRound constexpr.

---
 include/common.h | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/include/common.h b/include/common.h
index a80c677..f3a90a8 100644
--- a/include/common.h
+++ b/include/common.h
@@ -32,9 +32,12 @@
 #ifndef INCLUDE__COMMON_H_
 #define INCLUDE__COMMON_H_
 
-#include 
+#include/// @todo Not used throughout this header, arguably doesn't belong here.
 #include 
 
+#include 
+using std::size_t;   // better be defensive.
+
 #include 
 #include 
 #include 
@@ -123,17 +126,12 @@ enum pseudokeys {
 
 #if !defined( DEBUG )
 
-/// KiROUND: a function so v is not evaluated twice.  Unfortunately, compiler
-/// is unable to pre-compute constants using this.
-static inline int KiROUND( double v )
+/// KiROUND: round double to integer, no argument range check in release build.
+constexpr int KiROUND( double v )
 {
-return int( v < 0 ? v - 0.5 : v + 0.5 );
+return static_cast( v < 0 ? v - 0.5 : v + 0.5 );
 }
 
-/// KIROUND: a macro so compiler can pre-compute constants.  Use this with compile
-/// time constants rather than the inline function above.
-#define KIROUND( v )int( (v) < 0 ? (v) - 0.5 : (v) + 0.5 )
-
 #else
 
 // DEBUG: KiROUND() is a macro to capture line and file, then calls this inline
@@ -154,9 +152,6 @@ static inline int kiRound_( double v, int line, const char* filename )
 
 #define KiROUND( v )kiRound_( v, __LINE__, __FILE__ )
 
-// in Debug build, use the overflow catcher since code size is immaterial
-#define KIROUND( v )KiROUND( v )
-
 #endif
 
 //
@@ -164,10 +159,10 @@ static inline int kiRound_( double v, int line, const char* filename )
 
 
 /// Convert mm to mils.
-inline int Mm2mils( double x ) { return KiROUND( x * 1000./25.4 ); }
+constexpr int Mm2mils( double x ) { return KiROUND( x * 1000./25.4 ); }
 
 /// Convert mils to mm.
-inline int Mils2mm( double x ) { return KiROUND( x * 25.4 / 1000. ); }
+constexpr int Mils2mm( double x ) { return KiROUND( x * 25.4 / 1000. ); }
 
 
 enum EDA_UNITS_T {
@@ -201,6 +196,7 @@ public:
 private:
 void setUserLocale( const char* aUserLocale );
 
+/// @todo Everybody includes  because if this implementation detail.
 // allow for nesting of LOCALE_IO instantiations
 static std::atomic m_c_count;
 
-- 
2.9.0.windows.1

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

Re: [Kicad-developers] git stable mirror

[Wayne Stambaugh]

I'm OK with this.  I just was on github and I didn't see any way to pull
from a different repo in the add new repo section of github.  Would the
person (I think it was Miguel) who set this up for the product branch
please create a mirror on github for the stable 4 branch?

Thanks,

Wayne

On 7/5/2016 12:20 PM, Michael Steinberg wrote:
> Hey,
> 
> would it be possible to add the stable branch to the git mirror as well?
> That would make my work much easier. Take this as a wishlist-item ;)
> 
> Michael
> 
> 
> ___
> 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] git stable mirror

[Michael Steinberg]

Hey,

would it be possible to add the stable branch to the git mirror as well? 
That would make my work much easier. Take this as a wishlist-item ;)


Michael


___
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] Stable release bug fixes.

[Chris Pavlina]

Patching against stable and then merging forward sounds like a much better
development strategy to me, I second this idea very much. :)

On Jul 5, 2016 11:16, "Wayne Stambaugh"  wrote:

> As the development branch diverges from the stable release branch, it is
> becoming difficult to merge patch commits from the development branch to
> the stable branch.  I don't have that kind of time to clean up, build,
> and test the merge conflicts.  The problem has gotten much worse since
> we've started to incorporate C++11 code.  I'm going ask that in the
> future, if a bug affects the both the stable release and development
> branches, please create a bug fix patch for the stable release branch
> and then attempt to merge it forward into the development branch and
> then send a separate patch for the development branch if it does not
> merge cleanly.  This will save me a lot of grief.  Please note, no C++11
> code is allowed in the stable branch.  Thank you in advance for your
> cooperation.
>
> While I'm on the subject @Michael, would you please back port your boost
> context 1.61 patch?  I'm sure at some point in the not too distant
> future, someone will try to build stable version 4 against boost 1.61.
>
> Thanks,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
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 for stable (4.02) version: PCBNEW crashes on loading a file exported from Gerbview

[Wayne Stambaugh]

Thanks JP.  I already merged the change when I saw the commit to the
product branch and it without any issues.

On 7/5/2016 11:23 AM, jp charras wrote:
> Hi Wayne,
> 
> Attached a patch to fix lp:1598809 issue.
> It is for stable branch, and built against rev 6290.
> 
> I committed this fix also in product branch.
> 
> Thanks.
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

[Kicad-developers] [PATCH] Fix for stable (4.02) version: PCBNEW crashes on loading a file exported from Gerbview

[jp charras]

Hi Wayne,

Attached a patch to fix lp:1598809 issue.
It is for stable branch, and built against rev 6290.

I committed this fix also in product branch.

Thanks.

-- 
Jean-Pierre CHARRAS
=== modified file 'pcbnew/files.cpp'
--- pcbnew/files.cpp2016-05-27 18:36:53 +
+++ pcbnew/files.cpp2016-07-05 15:10:40 +
@@ -571,8 +571,17 @@
 // Rebuild the new pad list (for drc and ratsnet control ...)
 GetBoard()->m_Status_Pcb = 0;
 
+// Set current netclass in use NETCLASS::Default always exists
+SetCurrentNetClass( NETCLASS::Default );
+
+// Rebuild list of nets (full ratsnest rebuild)
+{
+wxBusyCursor dummy;// Displays an Hourglass while building 
connectivity
+Compile_Ratsnest( NULL, true );
+GetBoard()->GetRatsnest()->ProcessBoard();
+}
+
 // Update info shown by the horizontal toolbars
-SetCurrentNetClass( NETCLASS::Default );
 ReFillLayerWidget();
 ReCreateLayerBox();
 
@@ -592,13 +601,6 @@
 // Display the loaded board:
 Zoom_Automatique( false );
 
-// Compile ratsnest and displays net info
-{
-wxBusyCursor dummy;// Displays an Hourglass while building 
connectivity
-Compile_Ratsnest( NULL, true );
-GetBoard()->GetRatsnest()->ProcessBoard();
-}
-
 SetMsgPanel( GetBoard() );
 
 // Refresh the 3D view, if any

___
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] Stable release bug fixes.

[Wayne Stambaugh]

As the development branch diverges from the stable release branch, it is
becoming difficult to merge patch commits from the development branch to
the stable branch.  I don't have that kind of time to clean up, build,
and test the merge conflicts.  The problem has gotten much worse since
we've started to incorporate C++11 code.  I'm going ask that in the
future, if a bug affects the both the stable release and development
branches, please create a bug fix patch for the stable release branch
and then attempt to merge it forward into the development branch and
then send a separate patch for the development branch if it does not
merge cleanly.  This will save me a lot of grief.  Please note, no C++11
code is allowed in the stable branch.  Thank you in advance for your
cooperation.

While I'm on the subject @Michael, would you please back port your boost
context 1.61 patch?  I'm sure at some point in the not too distant
future, someone will try to build stable version 4 against boost 1.61.

Thanks,

Wayne

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

Re: [Kicad-developers] Stable release 5 road map.

[easyw]

Maybe a better idea would be mention StepUp in the Pcbnew documentation
and just provide a link to your documentation.  This way you don't need
to maintain your documentation in two places.

perfect ...
I'm going to create a pull request
Thanks
Maurice


On 7/5/2016 2:17 PM, Wayne Stambaugh wrote:

On 7/5/2016 7:22 AM, easyw wrote:

I'm fine with this.  Please create pull request against the current
documentation.

I will


Maybe a better idea would be mention StepUp in the Pcbnew documentation
and just provide a link to your documentation.  This way you don't need
to maintain your documentation in two places.


I'm sure our doc devs would be happy to help you.  I'm
not sure which section of the documentation this should go into.  There
is a scripting section in the Pcbnew so that may work.

I don't know if that could be in something like
http://kicad-pcb.org/help/documentation/
external tools
   STEP external exporter tool
beside
   KiCost
as in the kicad-pcb site


I am fully aware of how KiCad StepUp works.  I use it myself and it
works very well.

thanks

I would prefer that we integrate the StepUp functionality into KiCad so
the user could just click export and save the model to their preferred
file format.

that would be an easier approach I would consider too
at the same time StepUp is offering many MCAD option (i.e. interference
checking etc) that are not available internally in ECAD environment


Initially would be just fine with STEP but if we use OCE
we should support all of the exporters that it provides at some point.

Consider that OCE is the FreeCAD MCAD kernel, so anything you can do in
OCE, you can do in FC
Moreover in FC you may test if your models are geometrically fine and
fully compliant with OCE kernel, before exporting or using them (that is
exactly what I did when I created the 3D MCAD library)
OCE kernel has some odd behavior (as many/all other commercial kernels
have), so it is useful to have a direct feedback in FreeCAD

Thanks
Maurice

On 7/5/2016 11:34 AM, Wayne Stambaugh wrote:

On 7/5/2016 5:23 AM, easyw wrote:

Hi Wayne,

I think it would be nice to have also a note on KiCad user manual about
the external kicad StepUp exporter.


I'm fine with this.  Please create pull request against the current
documentation.  I'm sure our doc devs would be happy to help you.  I'm
not sure which section of the documentation this should go into.  There
is a scripting section in the Pcbnew so that may work.



Please consider that to use this exporter, the users would need just a
stable version of FreCAD (>=0.15) and a single python file ...
Everything is based on an assembler macro that can assembly STEP/IGES 3D
models and the KiCad pcb board.
It can convert KiCad boards, with 3D wrl models, but it also support the
conversion if the board has directly STEP models inside using the new
OCE plugin.


I am fully aware of how KiCad StepUp works.  I use it myself and it
works very well.  However, the typical EDA user does not want or expect
to have to run an external script to generate the board/component model.
   I would prefer that we integrate the StepUp functionality into KiCad so
the user could just click export and save the model to their preferred
file format.  Initially would be just fine with STEP but if we use OCE
we should support all of the exporters that it provides at some point.

Cheers,

Wayne



I know that is an external solution to KiCad, but since one year from
its first public release, many people (more than 8500) have downloaded
and used it with very little issues.
Moreover it is usable also with KiCad 4.02 stable release, without any
need to build from source.
Please have a look at this small video, to see how easy is to convert a
KiCad board to STEP model
https://youtu.be/h6wMU3lE_sA
The demo project is a self contained KiCad project and can be tested
just out of the box... unique requirement is a recent version of FreeCAD
installed in Linux, Windows and OSX environments
https://sourceforge.net/projects/kicadstepup/files/latest/download

I have done also a quite big library of 3D parametric models that can be
used directly as KiCAD 3D libraries
https://github.com/easyw/kicad-3d-mcad-models

I would be very pleased if my exporter would get a mention on the KiCad
user manual as an external open source solution to MCAD conversion...

Please let me know if you may need any further details or info about
this MCAD exporter

Thank you
Maurice

On 7/5/2016 10:13 AM, Wayne Stambaugh wrote:

Funny you should ask Cirilo since your name came up about the 3D model
plugins.  The current road map version 5 is published as part of the
developer documentation which is available on the KiCad website.  In
the
road map there is mention of support for exporting to STEP and/or IGES.
Any chance that you could provide a plugin for either one of these or
both by FOSDEM 2017?  It would be a nice feature for users to directly
export boards and footprint models to a format that can be 

Re: [Kicad-developers] Stable release 5 road map.

[Wayne Stambaugh]

On 7/5/2016 7:22 AM, easyw wrote:
>> I'm fine with this.  Please create pull request against the current
>> documentation.
> I will

Maybe a better idea would be mention StepUp in the Pcbnew documentation
and just provide a link to your documentation.  This way you don't need
to maintain your documentation in two places.

>> I'm sure our doc devs would be happy to help you.  I'm
>> not sure which section of the documentation this should go into.  There
>> is a scripting section in the Pcbnew so that may work.
> I don't know if that could be in something like
> http://kicad-pcb.org/help/documentation/
>external tools
>   STEP external exporter tool
> beside
>   KiCost
> as in the kicad-pcb site
> 
>> I am fully aware of how KiCad StepUp works.  I use it myself and it
>> works very well.
> thanks
>> I would prefer that we integrate the StepUp functionality into KiCad so
>> the user could just click export and save the model to their preferred
>> file format.
> that would be an easier approach I would consider too
> at the same time StepUp is offering many MCAD option (i.e. interference
> checking etc) that are not available internally in ECAD environment
> 
>> Initially would be just fine with STEP but if we use OCE
>> we should support all of the exporters that it provides at some point.
> Consider that OCE is the FreeCAD MCAD kernel, so anything you can do in
> OCE, you can do in FC
> Moreover in FC you may test if your models are geometrically fine and
> fully compliant with OCE kernel, before exporting or using them (that is
> exactly what I did when I created the 3D MCAD library)
> OCE kernel has some odd behavior (as many/all other commercial kernels
> have), so it is useful to have a direct feedback in FreeCAD
> 
> Thanks
> Maurice
> 
> On 7/5/2016 11:34 AM, Wayne Stambaugh wrote:
>> On 7/5/2016 5:23 AM, easyw wrote:
>>> Hi Wayne,
>>>
>>> I think it would be nice to have also a note on KiCad user manual about
>>> the external kicad StepUp exporter.
>>
>> I'm fine with this.  Please create pull request against the current
>> documentation.  I'm sure our doc devs would be happy to help you.  I'm
>> not sure which section of the documentation this should go into.  There
>> is a scripting section in the Pcbnew so that may work.
>>
>>>
>>> Please consider that to use this exporter, the users would need just a
>>> stable version of FreCAD (>=0.15) and a single python file ...
>>> Everything is based on an assembler macro that can assembly STEP/IGES 3D
>>> models and the KiCad pcb board.
>>> It can convert KiCad boards, with 3D wrl models, but it also support the
>>> conversion if the board has directly STEP models inside using the new
>>> OCE plugin.
>>
>> I am fully aware of how KiCad StepUp works.  I use it myself and it
>> works very well.  However, the typical EDA user does not want or expect
>> to have to run an external script to generate the board/component model.
>>   I would prefer that we integrate the StepUp functionality into KiCad so
>> the user could just click export and save the model to their preferred
>> file format.  Initially would be just fine with STEP but if we use OCE
>> we should support all of the exporters that it provides at some point.
>>
>> Cheers,
>>
>> Wayne
>>
>>>
>>> I know that is an external solution to KiCad, but since one year from
>>> its first public release, many people (more than 8500) have downloaded
>>> and used it with very little issues.
>>> Moreover it is usable also with KiCad 4.02 stable release, without any
>>> need to build from source.
>>> Please have a look at this small video, to see how easy is to convert a
>>> KiCad board to STEP model
>>> https://youtu.be/h6wMU3lE_sA
>>> The demo project is a self contained KiCad project and can be tested
>>> just out of the box... unique requirement is a recent version of FreeCAD
>>> installed in Linux, Windows and OSX environments
>>> https://sourceforge.net/projects/kicadstepup/files/latest/download
>>>
>>> I have done also a quite big library of 3D parametric models that can be
>>> used directly as KiCAD 3D libraries
>>> https://github.com/easyw/kicad-3d-mcad-models
>>>
>>> I would be very pleased if my exporter would get a mention on the KiCad
>>> user manual as an external open source solution to MCAD conversion...
>>>
>>> Please let me know if you may need any further details or info about
>>> this MCAD exporter
>>>
>>> Thank you
>>> Maurice
>>>
>>> On 7/5/2016 10:13 AM, Wayne Stambaugh wrote:
 Funny you should ask Cirilo since your name came up about the 3D model
 plugins.  The current road map version 5 is published as part of the
 developer documentation which is available on the KiCad website.  In
 the
 road map there is mention of support for exporting to STEP and/or IGES.
 Any chance that you could provide a plugin for either one of these or
 both by FOSDEM 2017?  It would be a nice feature for users to directly
 export boards and footprint models to a format 

Re: [Kicad-developers] Stable release 5 road map.

[Simon Richter]

Hi,

On 05.07.2016 09:55, Wayne Stambaugh wrote:

> If you are
> working on new features that are not in the version 5 road map, please
> inform me of what you working on and whether or not it will be ready to
> release by FOSDEM 2017.

My current branches:

1. writeable pin table

This could happen before FOSDEM, but is blocked by something that could
be a wx bug (widget not being rendered in the table context). Since that
feature is pretty much isolated in a single file and nothing depends on
it, I'm just going to submit it when it's ready and you decide whether
it can go in.

2. net ties

That is to a large extent blocked by any refactoring work in eeschema,
and the UI/UX is not fully defined yet either -- which we should fix
while we're here, but it won't be ready until after FOSDEM.

   Simon



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

Re: [Kicad-developers] Stable release 5 road map.

[easyw]

I'm fine with this.  Please create pull request against the current
documentation.

I will

I'm sure our doc devs would be happy to help you.  I'm
not sure which section of the documentation this should go into.  There
is a scripting section in the Pcbnew so that may work.

I don't know if that could be in something like
http://kicad-pcb.org/help/documentation/
   external tools
  STEP external exporter tool
beside
  KiCost
as in the kicad-pcb site


I am fully aware of how KiCad StepUp works.  I use it myself and it
works very well.

thanks

I would prefer that we integrate the StepUp functionality into KiCad so
the user could just click export and save the model to their preferred
file format.

that would be an easier approach I would consider too
at the same time StepUp is offering many MCAD option (i.e. interference 
checking etc) that are not available internally in ECAD environment



Initially would be just fine with STEP but if we use OCE
we should support all of the exporters that it provides at some point.
Consider that OCE is the FreeCAD MCAD kernel, so anything you can do in 
OCE, you can do in FC
Moreover in FC you may test if your models are geometrically fine and 
fully compliant with OCE kernel, before exporting or using them (that is 
exactly what I did when I created the 3D MCAD library)
OCE kernel has some odd behavior (as many/all other commercial kernels 
have), so it is useful to have a direct feedback in FreeCAD


Thanks
Maurice

On 7/5/2016 11:34 AM, Wayne Stambaugh wrote:

On 7/5/2016 5:23 AM, easyw wrote:

Hi Wayne,

I think it would be nice to have also a note on KiCad user manual about
the external kicad StepUp exporter.


I'm fine with this.  Please create pull request against the current
documentation.  I'm sure our doc devs would be happy to help you.  I'm
not sure which section of the documentation this should go into.  There
is a scripting section in the Pcbnew so that may work.



Please consider that to use this exporter, the users would need just a
stable version of FreCAD (>=0.15) and a single python file ...
Everything is based on an assembler macro that can assembly STEP/IGES 3D
models and the KiCad pcb board.
It can convert KiCad boards, with 3D wrl models, but it also support the
conversion if the board has directly STEP models inside using the new
OCE plugin.


I am fully aware of how KiCad StepUp works.  I use it myself and it
works very well.  However, the typical EDA user does not want or expect
to have to run an external script to generate the board/component model.
  I would prefer that we integrate the StepUp functionality into KiCad so
the user could just click export and save the model to their preferred
file format.  Initially would be just fine with STEP but if we use OCE
we should support all of the exporters that it provides at some point.

Cheers,

Wayne



I know that is an external solution to KiCad, but since one year from
its first public release, many people (more than 8500) have downloaded
and used it with very little issues.
Moreover it is usable also with KiCad 4.02 stable release, without any
need to build from source.
Please have a look at this small video, to see how easy is to convert a
KiCad board to STEP model
https://youtu.be/h6wMU3lE_sA
The demo project is a self contained KiCad project and can be tested
just out of the box... unique requirement is a recent version of FreeCAD
installed in Linux, Windows and OSX environments
https://sourceforge.net/projects/kicadstepup/files/latest/download

I have done also a quite big library of 3D parametric models that can be
used directly as KiCAD 3D libraries
https://github.com/easyw/kicad-3d-mcad-models

I would be very pleased if my exporter would get a mention on the KiCad
user manual as an external open source solution to MCAD conversion...

Please let me know if you may need any further details or info about
this MCAD exporter

Thank you
Maurice

On 7/5/2016 10:13 AM, Wayne Stambaugh wrote:

Funny you should ask Cirilo since your name came up about the 3D model
plugins.  The current road map version 5 is published as part of the
developer documentation which is available on the KiCad website.  In the
road map there is mention of support for exporting to STEP and/or IGES.
Any chance that you could provide a plugin for either one of these or
both by FOSDEM 2017?  It would be a nice feature for users to directly
export boards and footprint models to a format that can be used directly
by FreeCAD and less than free CAD tools for mechanical design.  Maybe
you could get some help from Mario and Maurice.  If you don't think this
is possible, please let me know so I can update the road map.

Cheers,

Wayne

On 7/5/2016 4:07 AM, Cirilo Bernardo wrote:

Is there a pre-commit version somewhere where we can see what's
on the roadmap?

I want to work on a PCB API so that pcbnew importers/exporters
can be turned into plugins and I can add an MCAD exporter, but
given my free time and the size of the 

Re: [Kicad-developers] Stable release 5 road map.

[Wayne Stambaugh]

On 7/5/2016 5:23 AM, easyw wrote:
> Hi Wayne,
> 
> I think it would be nice to have also a note on KiCad user manual about
> the external kicad StepUp exporter.

I'm fine with this.  Please create pull request against the current
documentation.  I'm sure our doc devs would be happy to help you.  I'm
not sure which section of the documentation this should go into.  There
is a scripting section in the Pcbnew so that may work.

> 
> Please consider that to use this exporter, the users would need just a
> stable version of FreCAD (>=0.15) and a single python file ...
> Everything is based on an assembler macro that can assembly STEP/IGES 3D
> models and the KiCad pcb board.
> It can convert KiCad boards, with 3D wrl models, but it also support the
> conversion if the board has directly STEP models inside using the new
> OCE plugin.

I am fully aware of how KiCad StepUp works.  I use it myself and it
works very well.  However, the typical EDA user does not want or expect
to have to run an external script to generate the board/component model.
 I would prefer that we integrate the StepUp functionality into KiCad so
the user could just click export and save the model to their preferred
file format.  Initially would be just fine with STEP but if we use OCE
we should support all of the exporters that it provides at some point.

Cheers,

Wayne

> 
> I know that is an external solution to KiCad, but since one year from
> its first public release, many people (more than 8500) have downloaded
> and used it with very little issues.
> Moreover it is usable also with KiCad 4.02 stable release, without any
> need to build from source.
> Please have a look at this small video, to see how easy is to convert a
> KiCad board to STEP model
> https://youtu.be/h6wMU3lE_sA
> The demo project is a self contained KiCad project and can be tested
> just out of the box... unique requirement is a recent version of FreeCAD
> installed in Linux, Windows and OSX environments
> https://sourceforge.net/projects/kicadstepup/files/latest/download
> 
> I have done also a quite big library of 3D parametric models that can be
> used directly as KiCAD 3D libraries
> https://github.com/easyw/kicad-3d-mcad-models
> 
> I would be very pleased if my exporter would get a mention on the KiCad
> user manual as an external open source solution to MCAD conversion...
> 
> Please let me know if you may need any further details or info about
> this MCAD exporter
> 
> Thank you
> Maurice
> 
> On 7/5/2016 10:13 AM, Wayne Stambaugh wrote:
>> Funny you should ask Cirilo since your name came up about the 3D model
>> plugins.  The current road map version 5 is published as part of the
>> developer documentation which is available on the KiCad website.  In the
>> road map there is mention of support for exporting to STEP and/or IGES.
>> Any chance that you could provide a plugin for either one of these or
>> both by FOSDEM 2017?  It would be a nice feature for users to directly
>> export boards and footprint models to a format that can be used directly
>> by FreeCAD and less than free CAD tools for mechanical design.  Maybe
>> you could get some help from Mario and Maurice.  If you don't think this
>> is possible, please let me know so I can update the road map.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 7/5/2016 4:07 AM, Cirilo Bernardo wrote:
>>> Is there a pre-commit version somewhere where we can see what's
>>> on the roadmap?
>>>
>>> I want to work on a PCB API so that pcbnew importers/exporters
>>> can be turned into plugins and I can add an MCAD exporter, but
>>> given my free time and the size of the job I wouldn't expect it to
>>> be ready for FOSDEM 2017.
>>>
>>> - Cirilo
>>>
>>> On Tue, Jul 5, 2016 at 5:55 PM, Wayne Stambaugh >> > wrote:
>>>
>>>  I spent much of yesterday discussing and finalizing the stable
>>> version 5
>>>  road map with everyone here at CERN.  I will be committing the
>>> revised
>>>  road map soon.  Before I do, I want to make sure no one is
>>> working on
>>>  anything outside the road map that I do not know about.  If you are
>>>  working on new features that are not in the version 5 road map,
>>> please
>>>  inform me of what you working on and whether or not it will be
>>> ready to
>>>  release by FOSDEM 2017.  If it will not be ready by then, please
>>> do not
>>>  commit it to the product branch and keep your changes in you own
>>>  development branch until after I create the stable release 5
>>> branch on
>>>  launchpad.
>>>
>>>  Cheers,
>>>
>>>  Wayne
>>>
>>>  ___
>>>  Mailing list: https://launchpad.net/~kicad-developers
>>>  Post to : kicad-developers@lists.launchpad.net
>>>  
>>>  Unsubscribe : https://launchpad.net/~kicad-developers
>>>  More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> 

Re: [Kicad-developers] Stable release 5 road map.

[easyw]

Hi Wayne,

I think it would be nice to have also a note on KiCad user manual about 
the external kicad StepUp exporter.


Please consider that to use this exporter, the users would need just a 
stable version of FreCAD (>=0.15) and a single python file ...
Everything is based on an assembler macro that can assembly STEP/IGES 3D 
models and the KiCad pcb board.
It can convert KiCad boards, with 3D wrl models, but it also support the 
conversion if the board has directly STEP models inside using the new 
OCE plugin.


I know that is an external solution to KiCad, but since one year from 
its first public release, many people (more than 8500) have downloaded 
and used it with very little issues.
Moreover it is usable also with KiCad 4.02 stable release, without any 
need to build from source.
Please have a look at this small video, to see how easy is to convert a 
KiCad board to STEP model

https://youtu.be/h6wMU3lE_sA
The demo project is a self contained KiCad project and can be tested 
just out of the box... unique requirement is a recent version of FreeCAD 
installed in Linux, Windows and OSX environments

https://sourceforge.net/projects/kicadstepup/files/latest/download

I have done also a quite big library of 3D parametric models that can be 
used directly as KiCAD 3D libraries

https://github.com/easyw/kicad-3d-mcad-models

I would be very pleased if my exporter would get a mention on the KiCad 
user manual as an external open source solution to MCAD conversion...


Please let me know if you may need any further details or info about 
this MCAD exporter


Thank you
Maurice

On 7/5/2016 10:13 AM, Wayne Stambaugh wrote:

Funny you should ask Cirilo since your name came up about the 3D model
plugins.  The current road map version 5 is published as part of the
developer documentation which is available on the KiCad website.  In the
road map there is mention of support for exporting to STEP and/or IGES.
Any chance that you could provide a plugin for either one of these or
both by FOSDEM 2017?  It would be a nice feature for users to directly
export boards and footprint models to a format that can be used directly
by FreeCAD and less than free CAD tools for mechanical design.  Maybe
you could get some help from Mario and Maurice.  If you don't think this
is possible, please let me know so I can update the road map.

Cheers,

Wayne

On 7/5/2016 4:07 AM, Cirilo Bernardo wrote:

Is there a pre-commit version somewhere where we can see what's
on the roadmap?

I want to work on a PCB API so that pcbnew importers/exporters
can be turned into plugins and I can add an MCAD exporter, but
given my free time and the size of the job I wouldn't expect it to
be ready for FOSDEM 2017.

- Cirilo

On Tue, Jul 5, 2016 at 5:55 PM, Wayne Stambaugh > wrote:

 I spent much of yesterday discussing and finalizing the stable version 5
 road map with everyone here at CERN.  I will be committing the revised
 road map soon.  Before I do, I want to make sure no one is working on
 anything outside the road map that I do not know about.  If you are
 working on new features that are not in the version 5 road map, please
 inform me of what you working on and whether or not it will be ready to
 release by FOSDEM 2017.  If it will not be ready by then, please do not
 commit it to the product branch and keep your changes in you own
 development branch until after I create the stable release 5 branch on
 launchpad.

 Cheers,

 Wayne

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




___
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] Stable release 5 road map.

[Wayne Stambaugh]

Funny you should ask Cirilo since your name came up about the 3D model
plugins.  The current road map version 5 is published as part of the
developer documentation which is available on the KiCad website.  In the
road map there is mention of support for exporting to STEP and/or IGES.
Any chance that you could provide a plugin for either one of these or
both by FOSDEM 2017?  It would be a nice feature for users to directly
export boards and footprint models to a format that can be used directly
by FreeCAD and less than free CAD tools for mechanical design.  Maybe
you could get some help from Mario and Maurice.  If you don't think this
is possible, please let me know so I can update the road map.

Cheers,

Wayne

On 7/5/2016 4:07 AM, Cirilo Bernardo wrote:
> Is there a pre-commit version somewhere where we can see what's
> on the roadmap?
> 
> I want to work on a PCB API so that pcbnew importers/exporters
> can be turned into plugins and I can add an MCAD exporter, but
> given my free time and the size of the job I wouldn't expect it to
> be ready for FOSDEM 2017.
> 
> - Cirilo
> 
> On Tue, Jul 5, 2016 at 5:55 PM, Wayne Stambaugh  > wrote:
> 
> I spent much of yesterday discussing and finalizing the stable version 5
> road map with everyone here at CERN.  I will be committing the revised
> road map soon.  Before I do, I want to make sure no one is working on
> anything outside the road map that I do not know about.  If you are
> working on new features that are not in the version 5 road map, please
> inform me of what you working on and whether or not it will be ready to
> release by FOSDEM 2017.  If it will not be ready by then, please do not
> commit it to the product branch and keep your changes in you own
> development branch until after I create the stable release 5 branch on
> launchpad.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 

___
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] Stable release 5 road map.

[Cirilo Bernardo]

Is there a pre-commit version somewhere where we can see what's
on the roadmap?

I want to work on a PCB API so that pcbnew importers/exporters
can be turned into plugins and I can add an MCAD exporter, but
given my free time and the size of the job I wouldn't expect it to
be ready for FOSDEM 2017.

- Cirilo

On Tue, Jul 5, 2016 at 5:55 PM, Wayne Stambaugh 
wrote:

> I spent much of yesterday discussing and finalizing the stable version 5
> road map with everyone here at CERN.  I will be committing the revised
> road map soon.  Before I do, I want to make sure no one is working on
> anything outside the road map that I do not know about.  If you are
> working on new features that are not in the version 5 road map, please
> inform me of what you working on and whether or not it will be ready to
> release by FOSDEM 2017.  If it will not be ready by then, please do not
> commit it to the product branch and keep your changes in you own
> development branch until after I create the stable release 5 branch on
> launchpad.
>
> Cheers,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
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] Stable release 5 road map.

[Wayne Stambaugh]

I spent much of yesterday discussing and finalizing the stable version 5
road map with everyone here at CERN.  I will be committing the revised
road map soon.  Before I do, I want to make sure no one is working on
anything outside the road map that I do not know about.  If you are
working on new features that are not in the version 5 road map, please
inform me of what you working on and whether or not it will be ready to
release by FOSDEM 2017.  If it will not be ready by then, please do not
commit it to the product branch and keep your changes in you own
development branch until after I create the stable release 5 branch on
launchpad.

Cheers,

Wayne

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

Re: [Kicad-developers] Regarding [PATCH] refactor_profile.patch

[Simon Richter]

Hi,

On 05.07.2016 01:45, Michael Steinberg wrote:

> I was made aware that MinGW's implementation of std::chrono might be
> lacking, but my testbed is not including that yet, so I cannot
> double-check the implementation.

I've started a build on Jenkins, but it will take a while until the
system gets around to it. I really need to add more nodes.

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

[Marco Ciampa]

Just a heads-up. I will be away for vacation from 10/7 to 25/7 (or a
little more, I am not sure about it, sorry).

As usually I go on vacation almost without devices, apart from mobile and
kindle. Probably I will leave my laptop at home also this time. Also not
sure about it.

KiCad docs are under heavy revision, thanks to the new collaborators,
first of all evanshultz, if he has not an accont here he is in CC.

Lately I have added write permission on the kicad doc repo to an
additional couple of collaborators so it should be no problem for every
issue that may arise.

Best regards,

--


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
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