Re: [Kicad-developers] PATCH: IDF tools

2016-03-21 Thread Chris Pavlina 
Committed in r6637. Thank you.

On Mon, Mar 21, 2016 at 09:35:42PM +1100, Cirilo Bernardo wrote:
> The attached patch makes the following changes to the IDF
> tool 'dxf2idf':
> 
> 1. DXF units are now correctly scaled to mm
> 2. Polylines are now supported
> 3. LWPolylines are now supported
> 
> - 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] OSX version support

2016-03-21 Thread Adam Wolf 
It would be nice to move to 10.9 SDK for the current development work, for
speed/security reasons.  I can keep the 10.7 SDK around for the stable
builds for any new 4 series stable releases.

OTOH, I don't mind keeping them around--until someone complains that they
stopped working. The only real problem I have with keeping 10.7 and 10.8
support around is that I don't know anyone who wants to keep a 10.7 or 10.8
system around for us to do testing on, if anyone has problems with it.

Adam Wolf
Cofounder and Engineer
W&L


On Mon, Mar 21, 2016 at 4:49 PM, Simon Wells  wrote:

> Currently the website states OSX 10.7 through 10.11 supported.
>
> 10.7 - unsupported by apple since october 2014
> 10.8 - unsupported by apple since september 2015
>
> These are currently still supported due to using a 10.7 SDK for building.
>
> The main issue i see a problem with still "supporting" these operating
> systems is it allows people to file bugs that may only be applicable
> on an operating system that none of the osx devs have so will be
> unable to fix.
>
> We really have 2 options for this
>
> 1) remove the claim to support 10.7/10.8 from the website and any
> other places. This would allow us to mark any bugs as won't fix due to
> lack of developer resources (if it only applies to osx 10.7/8)
> 2) move to the 10.9 SDK therefore completely dropping support for 10.7/10.8
>
> Due to the 10.7/8 SDK no longer being updated there may also be
> security issues with continuing to use the SDK.
>
> As 4.0 was released in late 2015 that could be marked as the last
> version to support 10.7/8 and any more point releases of it can still
> be built to support 10.7/10.8 if Adam won't have any problems doing
> this.
>
> OSX 10.9 Mavericks was released in October 2013 and is down to
> security updates only with the current OSX being 10.11
>
> If there are any devs still using 10.7/8 please speak up including
> reasons for still using 10.7/8
>
> thanks
>
> Simon
>
> ___
> 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] Trouble with BOM plugin execution on Windows

2016-03-21 Thread Chris Pavlina 
Yes, ! is a valid file name character on at /least/ Linux, therefore this is 
broken.

On Mon, Mar 21, 2016 at 07:00:02PM -0400, Wayne Stambaugh wrote:
> Using ! is not going to be intuitive for most users.  This may make
> sense for developers who are used to cryptic symbols and identifiers but
> the typical user isn't going to get this.  Isn't ! a valid file name
> character on Linux?  I don't think this solution is user friendly so I'm
> standing by my original proposal.
> 
> On 3/19/2016 3:26 PM, Константин Барановский wrote:
> > bom_gen_tool.exe --option1 --option2 %I %O --show_console
> > 
> > Command line looks like all options is pushed to bom_gen_tool.exe and
> > not obvious that --show_console used to wxExecute.
> > For me it less intuitive than "!" symbol at beginning of the command line. 
> > 
> > 2016-03-19 16:23 GMT+02:00 jp charras  > >:
> > 
> > Le 18/03/2016 22:17, Константин Барановский a écrit :
> > > Parameter like --show-console will be passed to bom generator 
> > (bom_tool.exe
> > > in example), but we need tell wxExecute to run command with flag
> > > wxEXEC_SHOW_CONSOLE. And I propose "!" sign at begining of the 
> > command line
> > > to indicate that it must be run with that flag, it may be checked 
> > like it
> > > done with pythonw in bom_pythonw_exec.patch.
> > 
> > This is our code.
> > This command line is analyzed by Kicad (to expand %I and others).
> > A specific option can be filtered and set a wxExecute option like
> > wxEXEC_SHOW_CONSOLE (or some other).
> > 
> > >
> > > 2016-03-18 21:46 GMT+02:00 jp charras  > >:
> > >
> > >> Le 18/03/2016 19:11, Константин Барановский a écrit :
> > >>> What if realize it through the command line of the BOM plugin in
> > the next
> > >>> way :
> > >>> "bom_tool.exe %I %O" - execute and hide window (by default);
> > >>> "!bom_tool.exe %I %O" - execute and show window.
> > >>> Yes, it is not intuitive, but it is rare case and, I think, is
> > >> acceptable.
> > >>> What do you think?
> > >>
> > >> Why to reinvent the wheel?
> > >>
> > >> there are more usual ways to force an option.
> > >> for instance, in command line executables, an option is usually
> > called
> > >> by something like:
> > >> --show_console
> > >>
> > >> Whatever the option, do not forget to update the on help line
> > called by
> > >> the help button in dialog.
> > >>
> > >>>
> > >>> 2016-03-18 18:02 GMT+02:00 Wayne Stambaugh  > >:
> > >>>
> >  I don't think setting the wxEXEC_SHOW_CONSOLE for a single
> > executable
> >  name (in the case of your patch pythonw(.exe)) is a good idea.  The
> >  problem I foresee is someone will want launch executables X, Y,
> > and Z
> >  and soon this code would spiral out of control.  I would rather
> > not add
> >  pet behavior patches and come up with a more robust solution. 
> > A better
> >  patch would be to add an option to the BOM generator dialog to
> > always
> >  show the console for a given BOM generator configuration.  This
> > way you
> >  can use any executable and configure accordingly.
> > >>
> > >>
> > >>
> > >> --
> > >> 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
> > >>
> > >
> > 
> > 
> > --
> > 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

___
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 BOM plugin execution on Windows

2016-03-21 Thread Wayne Stambaugh 
Using ! is not going to be intuitive for most users.  This may make
sense for developers who are used to cryptic symbols and identifiers but
the typical user isn't going to get this.  Isn't ! a valid file name
character on Linux?  I don't think this solution is user friendly so I'm
standing by my original proposal.

On 3/19/2016 3:26 PM, Константин Барановский wrote:
> bom_gen_tool.exe --option1 --option2 %I %O --show_console
> 
> Command line looks like all options is pushed to bom_gen_tool.exe and
> not obvious that --show_console used to wxExecute.
> For me it less intuitive than "!" symbol at beginning of the command line. 
> 
> 2016-03-19 16:23 GMT+02:00 jp charras  >:
> 
> Le 18/03/2016 22:17, Константин Барановский a écrit :
> > Parameter like --show-console will be passed to bom generator 
> (bom_tool.exe
> > in example), but we need tell wxExecute to run command with flag
> > wxEXEC_SHOW_CONSOLE. And I propose "!" sign at begining of the command 
> line
> > to indicate that it must be run with that flag, it may be checked like 
> it
> > done with pythonw in bom_pythonw_exec.patch.
> 
> This is our code.
> This command line is analyzed by Kicad (to expand %I and others).
> A specific option can be filtered and set a wxExecute option like
> wxEXEC_SHOW_CONSOLE (or some other).
> 
> >
> > 2016-03-18 21:46 GMT+02:00 jp charras  >:
> >
> >> Le 18/03/2016 19:11, Константин Барановский a écrit :
> >>> What if realize it through the command line of the BOM plugin in
> the next
> >>> way :
> >>> "bom_tool.exe %I %O" - execute and hide window (by default);
> >>> "!bom_tool.exe %I %O" - execute and show window.
> >>> Yes, it is not intuitive, but it is rare case and, I think, is
> >> acceptable.
> >>> What do you think?
> >>
> >> Why to reinvent the wheel?
> >>
> >> there are more usual ways to force an option.
> >> for instance, in command line executables, an option is usually
> called
> >> by something like:
> >> --show_console
> >>
> >> Whatever the option, do not forget to update the on help line
> called by
> >> the help button in dialog.
> >>
> >>>
> >>> 2016-03-18 18:02 GMT+02:00 Wayne Stambaugh  >:
> >>>
>  I don't think setting the wxEXEC_SHOW_CONSOLE for a single
> executable
>  name (in the case of your patch pythonw(.exe)) is a good idea.  The
>  problem I foresee is someone will want launch executables X, Y,
> and Z
>  and soon this code would spiral out of control.  I would rather
> not add
>  pet behavior patches and come up with a more robust solution. 
> A better
>  patch would be to add an option to the BOM generator dialog to
> always
>  show the console for a given BOM generator configuration.  This
> way you
>  can use any executable and configure accordingly.
> >>
> >>
> >>
> >> --
> >> 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
> >>
> >
> 
> 
> --
> 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] OSX version support

2016-03-21 Thread Simon Wells 
Currently the website states OSX 10.7 through 10.11 supported.

10.7 - unsupported by apple since october 2014
10.8 - unsupported by apple since september 2015

These are currently still supported due to using a 10.7 SDK for building.

The main issue i see a problem with still "supporting" these operating
systems is it allows people to file bugs that may only be applicable
on an operating system that none of the osx devs have so will be
unable to fix.

We really have 2 options for this

1) remove the claim to support 10.7/10.8 from the website and any
other places. This would allow us to mark any bugs as won't fix due to
lack of developer resources (if it only applies to osx 10.7/8)
2) move to the 10.9 SDK therefore completely dropping support for 10.7/10.8

Due to the 10.7/8 SDK no longer being updated there may also be
security issues with continuing to use the SDK.

As 4.0 was released in late 2015 that could be marked as the last
version to support 10.7/8 and any more point releases of it can still
be built to support 10.7/10.8 if Adam won't have any problems doing
this.

OSX 10.9 Mavericks was released in October 2013 and is down to
security updates only with the current OSX being 10.11

If there are any devs still using 10.7/8 please speak up including
reasons for still using 10.7/8

thanks

Simon

___
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-03-21 Thread Wayne Stambaugh 
While I agree with you in principal, I have a feeling that we will loose
some dev branch testers by doing this.  How many is hard to say but
development branch testers are a valuable resource.  They tend to find
things that developers miss.

On 3/21/2016 3:38 PM, Chris Pavlina wrote:
> 16.04 LTS will be released in April. Personally I think we should be free to
> stop supporting 14.04 Geriatric Giraffe already in the development branch - 
> why
> should a devel branch of kicad support non-devel branches of Ubuntu? KiCad
> stable runs on Ubuntu "stable" (LTS). But I seem to be in the minority. At 
> this
> point though, I really don't see a problem with breaking free of 14.04 and
> targeting the upcoming 16.04. It's a devel branch for chrissakes ;)
> 
> 
> On Mon, Mar 21, 2016 at 08:33:00PM +0100, jp charras wrote:
>> Le 21/03/2016 20:13, Nick Østergaard a écrit :
>>> 2016-03-21 20:10 GMT+01:00 jp charras :
 Le 21/03/2016 19:54, Nick Østergaard a écrit :
> 2016-03-21 19:52 GMT+01:00 jp charras :
>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
>>> Going, going, gone!  Since I haven't gotten any objections, I committed
>>> the patch to enable C++11.  Thanks Simon for the patch but be prepared
>>> for the grumbling. :)
>>>
>>
>> On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
>> compiling pcbnewPYTHON_wrap.cxx.
>
> I guess this is because wxpython is missing on 14.04.

 No.
 I am able to build Kicad with option -DKICAD_SCRIPTING_WXPYTHON=ON.
 The issue is not related to wxpython.
 I also have this issue when I use only the option -DKICAD_SCRIPTING=ON.
 This issue exists *only* when option -std=c++11 or -std=gnu++11 is used.
>>>
>>> Lets just ignore this since 14.04 is end of life in august 2016 and
>>> use our effort on kicad moving forward.
>>>
>>
>> AFAIK, in august 2016, Ubuntu 16.xx LTS will be available.
>> It is not yet available.
>> Ubuntu 14.04 LTS is the latest LTS version.
>>
>> However, as I said, Kicad without python support is build-able.
>>
>>
>> -- 
>> 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
> 

___
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-03-21 Thread jp charras 



Le 21/03/2016 20:38, Chris Pavlina a écrit :

16.04 LTS will be released in April. Personally I think we should be free to
stop supporting 14.04 Geriatric Giraffe already in the development branch - why
should a devel branch of kicad support non-devel branches of Ubuntu? KiCad
stable runs on Ubuntu "stable" (LTS). But I seem to be in the minority. At this
point though, I really don't see a problem with breaking free of 14.04 and
targeting the upcoming 16.04. It's a devel branch for chrissakes ;)




I have no problem to target the upcoming 16.04.
I'll switch to 16.04 as soon as it is available.

And I previously said, I fully agree with c11 option support.

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] [PATCH] Enable C++11

2016-03-21 Thread Chris Pavlina 
16.04 LTS will be released in April. Personally I think we should be free to
stop supporting 14.04 Geriatric Giraffe already in the development branch - why
should a devel branch of kicad support non-devel branches of Ubuntu? KiCad
stable runs on Ubuntu "stable" (LTS). But I seem to be in the minority. At this
point though, I really don't see a problem with breaking free of 14.04 and
targeting the upcoming 16.04. It's a devel branch for chrissakes ;)


On Mon, Mar 21, 2016 at 08:33:00PM +0100, jp charras wrote:
> Le 21/03/2016 20:13, Nick Østergaard a écrit :
> > 2016-03-21 20:10 GMT+01:00 jp charras :
> >> Le 21/03/2016 19:54, Nick Østergaard a écrit :
> >>> 2016-03-21 19:52 GMT+01:00 jp charras :
>  Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
> > Going, going, gone!  Since I haven't gotten any objections, I committed
> > the patch to enable C++11.  Thanks Simon for the patch but be prepared
> > for the grumbling. :)
> >
> 
>  On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
>  compiling pcbnewPYTHON_wrap.cxx.
> >>>
> >>> I guess this is because wxpython is missing on 14.04.
> >>
> >> No.
> >> I am able to build Kicad with option -DKICAD_SCRIPTING_WXPYTHON=ON.
> >> The issue is not related to wxpython.
> >> I also have this issue when I use only the option -DKICAD_SCRIPTING=ON.
> >> This issue exists *only* when option -std=c++11 or -std=gnu++11 is used.
> > 
> > Lets just ignore this since 14.04 is end of life in august 2016 and
> > use our effort on kicad moving forward.
> > 
> 
> AFAIK, in august 2016, Ubuntu 16.xx LTS will be available.
> It is not yet available.
> Ubuntu 14.04 LTS is the latest LTS version.
> 
> However, as I said, Kicad without python support is build-able.
> 
> 
> -- 
> 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

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

2016-03-21 Thread jp charras 
Le 21/03/2016 20:28, Chris Pavlina a écrit :
> Are we sure this isn't the issue where cmake forgets to rebuild
> pcbnewPYTHON_wrap.cxx? I've been having that issue about once every couple
> weeks for a while, just delete it and rebuild :P
> 

Yes, I used a fresh build folder, and tried more than once, from scratch.


-- 
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] [PATCH] Enable C++11

2016-03-21 Thread jp charras 
Le 21/03/2016 20:13, Nick Østergaard a écrit :
> 2016-03-21 20:10 GMT+01:00 jp charras :
>> Le 21/03/2016 19:54, Nick Østergaard a écrit :
>>> 2016-03-21 19:52 GMT+01:00 jp charras :
 Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
> Going, going, gone!  Since I haven't gotten any objections, I committed
> the patch to enable C++11.  Thanks Simon for the patch but be prepared
> for the grumbling. :)
>

 On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
 compiling pcbnewPYTHON_wrap.cxx.
>>>
>>> I guess this is because wxpython is missing on 14.04.
>>
>> No.
>> I am able to build Kicad with option -DKICAD_SCRIPTING_WXPYTHON=ON.
>> The issue is not related to wxpython.
>> I also have this issue when I use only the option -DKICAD_SCRIPTING=ON.
>> This issue exists *only* when option -std=c++11 or -std=gnu++11 is used.
> 
> Lets just ignore this since 14.04 is end of life in august 2016 and
> use our effort on kicad moving forward.
> 

AFAIK, in august 2016, Ubuntu 16.xx LTS will be available.
It is not yet available.
Ubuntu 14.04 LTS is the latest LTS version.

However, as I said, Kicad without python support is build-able.


-- 
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] [PATCH] Enable C++11

2016-03-21 Thread jp charras 
Le 21/03/2016 20:11, Wayne Stambaugh a écrit :
> On 3/21/2016 3:10 PM, jp charras wrote:
>> Le 21/03/2016 19:54, Nick Østergaard a écrit :
>>> 2016-03-21 19:52 GMT+01:00 jp charras :
 Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
> Going, going, gone!  Since I haven't gotten any objections, I committed
> the patch to enable C++11.  Thanks Simon for the patch but be prepared
> for the grumbling. :)
>

 On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
 compiling pcbnewPYTHON_wrap.cxx.
>>>
>>> I guess this is because wxpython is missing on 14.04.
>>
>> No.
>> I am able to build Kicad with option -DKICAD_SCRIPTING_WXPYTHON=ON.
>> The issue is not related to wxpython.
>> I also have this issue when I use only the option -DKICAD_SCRIPTING=ON.
>> This issue exists *only* when option -std=c++11 or -std=gnu++11 is used.
> 
> It looks like swig is creating some code that C++11 doesn't like.  What
> version of swig are you using?  I'm using 3.0.6 on windows msys2 builds.

I have no problem on msys2 32bits.
Moreover, I believe gnu++11 is the default option on msys2.
The issue is only on Ubuntu.

I am also thinking to a swig issue.
On Ubuntu, swig is 2.0.11.


-- 
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] [PATCH] Enable C++11

2016-03-21 Thread Chris Pavlina 
Are we sure this isn't the issue where cmake forgets to rebuild
pcbnewPYTHON_wrap.cxx? I've been having that issue about once every couple
weeks for a while, just delete it and rebuild :P

On Mon, Mar 21, 2016 at 08:13:48PM +0100, Nick Østergaard wrote:
> 2016-03-21 20:10 GMT+01:00 jp charras :
> > Le 21/03/2016 19:54, Nick Østergaard a écrit :
> >> 2016-03-21 19:52 GMT+01:00 jp charras :
> >>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
>  Going, going, gone!  Since I haven't gotten any objections, I committed
>  the patch to enable C++11.  Thanks Simon for the patch but be prepared
>  for the grumbling. :)
> 
> >>>
> >>> On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
> >>> compiling pcbnewPYTHON_wrap.cxx.
> >>
> >> I guess this is because wxpython is missing on 14.04.
> >
> > No.
> > I am able to build Kicad with option -DKICAD_SCRIPTING_WXPYTHON=ON.
> > The issue is not related to wxpython.
> > I also have this issue when I use only the option -DKICAD_SCRIPTING=ON.
> > This issue exists *only* when option -std=c++11 or -std=gnu++11 is used.
> 
> Lets just ignore this since 14.04 is end of life in august 2016 and
> use our effort on kicad moving forward.
> 
> >>
> >>> With no python support, Kicad itself compiles without any problem.
> >>> but with python support, I have the attached error.
> >>>
> >>> I am not especially motivated to fix it, and I do not have a lot of
> >>> experience about swig. Each test takes *a bunch of* time.
> >>>
> >>> If someone has an idea about a fix and can help, he is welcome!
> >>>
> >>> Despite of this issue, I am thinking using C++11 features is a good idea.
> >>>
> >>> --
> >>> 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
> >>>
> >>
> >
> >
> > --
> > 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

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

2016-03-21 Thread Nick Østergaard 
2016-03-21 20:10 GMT+01:00 jp charras :
> Le 21/03/2016 19:54, Nick Østergaard a écrit :
>> 2016-03-21 19:52 GMT+01:00 jp charras :
>>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
 Going, going, gone!  Since I haven't gotten any objections, I committed
 the patch to enable C++11.  Thanks Simon for the patch but be prepared
 for the grumbling. :)

>>>
>>> On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
>>> compiling pcbnewPYTHON_wrap.cxx.
>>
>> I guess this is because wxpython is missing on 14.04.
>
> No.
> I am able to build Kicad with option -DKICAD_SCRIPTING_WXPYTHON=ON.
> The issue is not related to wxpython.
> I also have this issue when I use only the option -DKICAD_SCRIPTING=ON.
> This issue exists *only* when option -std=c++11 or -std=gnu++11 is used.

Lets just ignore this since 14.04 is end of life in august 2016 and
use our effort on kicad moving forward.

>>
>>> With no python support, Kicad itself compiles without any problem.
>>> but with python support, I have the attached error.
>>>
>>> I am not especially motivated to fix it, and I do not have a lot of
>>> experience about swig. Each test takes *a bunch of* time.
>>>
>>> If someone has an idea about a fix and can help, he is welcome!
>>>
>>> Despite of this issue, I am thinking using C++11 features is a good idea.
>>>
>>> --
>>> 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
>>>
>>
>
>
> --
> 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] [PATCH] Enable C++11

2016-03-21 Thread Wayne Stambaugh 
On 3/21/2016 3:10 PM, jp charras wrote:
> Le 21/03/2016 19:54, Nick Østergaard a écrit :
>> 2016-03-21 19:52 GMT+01:00 jp charras :
>>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
 Going, going, gone!  Since I haven't gotten any objections, I committed
 the patch to enable C++11.  Thanks Simon for the patch but be prepared
 for the grumbling. :)

>>>
>>> On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
>>> compiling pcbnewPYTHON_wrap.cxx.
>>
>> I guess this is because wxpython is missing on 14.04.
> 
> No.
> I am able to build Kicad with option -DKICAD_SCRIPTING_WXPYTHON=ON.
> The issue is not related to wxpython.
> I also have this issue when I use only the option -DKICAD_SCRIPTING=ON.
> This issue exists *only* when option -std=c++11 or -std=gnu++11 is used.

It looks like swig is creating some code that C++11 doesn't like.  What
version of swig are you using?  I'm using 3.0.6 on windows msys2 builds.

> 
>>
>>> With no python support, Kicad itself compiles without any problem.
>>> but with python support, I have the attached error.
>>>
>>> I am not especially motivated to fix it, and I do not have a lot of
>>> experience about swig. Each test takes *a bunch of* time.
>>>
>>> If someone has an idea about a fix and can help, he is welcome!
>>>
>>> Despite of this issue, I am thinking using C++11 features is a good idea.
>>>
>>> --
>>> 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

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

2016-03-21 Thread Nick Østergaard 
2016-03-21 19:54 GMT+01:00 Nick Østergaard :
> 2016-03-21 19:52 GMT+01:00 jp charras :
>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
>>> Going, going, gone!  Since I haven't gotten any objections, I committed
>>> the patch to enable C++11.  Thanks Simon for the patch but be prepared
>>> for the grumbling. :)
>>>
>>
>> On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
>> compiling pcbnewPYTHON_wrap.cxx.
>
> I guess this is because wxpython is missing on 14.04.
>
>> With no python support, Kicad itself compiles without any problem.
>> but with python support, I have the attached error.
>>
>> I am not especially motivated to fix it, and I do not have a lot of
>> experience about swig. Each test takes *a bunch of* time.
>>
>> If someone has an idea about a fix and can help, he is welcome!

You can probably use the PPA at
https://launchpad.net/~adamwolf/+archive/ubuntu/kicad-trusty-backports

>> Despite of this issue, I am thinking using C++11 features is a good idea.
>>
>> --
>> 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

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

2016-03-21 Thread jp charras 
Le 21/03/2016 19:54, Nick Østergaard a écrit :
> 2016-03-21 19:52 GMT+01:00 jp charras :
>> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
>>> Going, going, gone!  Since I haven't gotten any objections, I committed
>>> the patch to enable C++11.  Thanks Simon for the patch but be prepared
>>> for the grumbling. :)
>>>
>>
>> On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
>> compiling pcbnewPYTHON_wrap.cxx.
> 
> I guess this is because wxpython is missing on 14.04.

No.
I am able to build Kicad with option -DKICAD_SCRIPTING_WXPYTHON=ON.
The issue is not related to wxpython.
I also have this issue when I use only the option -DKICAD_SCRIPTING=ON.
This issue exists *only* when option -std=c++11 or -std=gnu++11 is used.

> 
>> With no python support, Kicad itself compiles without any problem.
>> but with python support, I have the attached error.
>>
>> I am not especially motivated to fix it, and I do not have a lot of
>> experience about swig. Each test takes *a bunch of* time.
>>
>> If someone has an idea about a fix and can help, he is welcome!
>>
>> Despite of this issue, I am thinking using C++11 features is a good idea.
>>
>> --
>> 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
>>
> 


-- 
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] [PATCH] Enable C++11

2016-03-21 Thread Nick Østergaard 
2016-03-21 19:52 GMT+01:00 jp charras :
> Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
>> Going, going, gone!  Since I haven't gotten any objections, I committed
>> the patch to enable C++11.  Thanks Simon for the patch but be prepared
>> for the grumbling. :)
>>
>
> On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
> compiling pcbnewPYTHON_wrap.cxx.

I guess this is because wxpython is missing on 14.04.

> With no python support, Kicad itself compiles without any problem.
> but with python support, I have the attached error.
>
> I am not especially motivated to fix it, and I do not have a lot of
> experience about swig. Each test takes *a bunch of* time.
>
> If someone has an idea about a fix and can help, he is welcome!
>
> Despite of this issue, I am thinking using C++11 features is a good idea.
>
> --
> 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

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

2016-03-21 Thread jp charras 
Le 21/03/2016 16:13, Wayne Stambaugh a écrit :
> Going, going, gone!  Since I haven't gotten any objections, I committed
> the patch to enable C++11.  Thanks Simon for the patch but be prepared
> for the grumbling. :)
> 

On Ubuntu 14.04 LTS - 64 bits (with latest update) I have an issue when
compiling pcbnewPYTHON_wrap.cxx.

With no python support, Kicad itself compiles without any problem.
but with python support, I have the attached error.

I am not especially motivated to fix it, and I do not have a lot of
experience about swig. Each test takes *a bunch of* time.

If someone has an idea about a fix and can help, he is welcome!

Despite of this issue, I am thinking using C++11 features is a good idea.

-- 
Jean-Pierre CHARRAS
Scanning dependencies of target pcbnew_kiface
/home/jpc/kicad-launchpad/testing/Build/Release_gtk2/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:
 In function 'PyObject* _wrap_str_utf8_Map_erase__SWIG_2(PyObject*, PyObject*)':
/home/jpc/kicad-launchpad/testing/Build/Release_gtk2/pcbnew/scripting/pcbnewPYTHON_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/jpc/kicad-launchpad/testing/Build/Release_gtk2/pcbnew/scripting/pcbnewPYTHON_wrap.cxx:29887:26:
 note: candidates are:
In file included from /usr/include/c++/4.8/map:61:0,
 from 
/home/jpc/kicad-launchpad/testing/Build/Release_gtk2/pcbnew/scripting/pcbnewPYTHON_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> >}'
Application: kicad
Version: (2016-03-21 BZR 6636)-product, release build
Libraries: wxWidgets 3.0.2
   libcurl/7.35.0 GnuTLS/2.12.23 zlib/1.2.8 libidn/1.28 librtmp/2.3
Platform: Linux 3.13.0-83-generic x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.54.0
Curl: 7.35.0
KiCad - Compiler: GCC 4.8.4 with C++ ABI 1002
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
  USE_WX_OVERLAY=OFF
  KICAD_SCRIPTING=OFF
  KICAD_SCRIPTING_MODULES=OFF
  KICAD_SCRIPTING_WXPYTHON=OFF
  USE_FP_LIB_TABLE=HARD_CODED_ON
  BUILD_GITHUB_PLUGIN=ON
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://lau

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

2016-03-21 Thread Wayne Stambaugh 
We should hold off on using any c++11 specific code for a while just in
case we have to remove this patch.  If we make it a month without having
to pull the patch, then we can start using c++11 stuff.

On 3/21/2016 11:27 AM, Chris Pavlina wrote:
> Someone should probably ask - apologies if someone already did: Do you have a
> policy in mind for using C++11 features in new patches? It may be prudent to
> let the patch settle for a few days just to make sure nobody else has build
> trouble before we start making it harder to back out.
> 
> On Mon, Mar 21, 2016 at 11:13:26AM -0400, Wayne Stambaugh wrote:
>> Going, going, gone!  Since I haven't gotten any objections, I committed
>> the patch to enable C++11.  Thanks Simon for the patch but be prepared
>> for the grumbling. :)
>>
>> On 3/18/2016 3:42 PM, Wayne Stambaugh wrote:
>>> I tested this on my Debian testing and it seemed fine.  It is 2016 after
>>> all so I guess it's time to jump into the C++11 waters if there are no
>>> objections.  I figure we'll be good to roll out C++14 in 2019 or 2020. :).
>>>
>>> On 3/18/2016 12:08 AM, Simon Richter wrote:
 Hi Wayne,

 On 17.03.2016 20:35, Wayne Stambaugh wrote:

> @Simon, when cmake is < 3.1 you set the -std-c++11 flag for gcc and
> clang instead of the -gnu-c++11.  This seems to be an issue that should
> be addressed.  Maybe this is what is breaking @Mark's builds.  I would
> feel more comfortable if we figure this out before I commit the patch.

 It works for me on Debian jessie, with cmake 3.0.2 and gcc 4.9.2, and on
 Ubunty trusty with cmake 2.8.12.2 and gcc 4.8.2.

 On Ubuntu trusty, wxPython 3.0 is not available as far as I can see, so
 that build was without scripting support.

Simon



 ___
 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] [PATCH] Enable C++11

2016-03-21 Thread Chris Pavlina 
Someone should probably ask - apologies if someone already did: Do you have a
policy in mind for using C++11 features in new patches? It may be prudent to
let the patch settle for a few days just to make sure nobody else has build
trouble before we start making it harder to back out.

On Mon, Mar 21, 2016 at 11:13:26AM -0400, Wayne Stambaugh wrote:
> Going, going, gone!  Since I haven't gotten any objections, I committed
> the patch to enable C++11.  Thanks Simon for the patch but be prepared
> for the grumbling. :)
> 
> On 3/18/2016 3:42 PM, Wayne Stambaugh wrote:
> > I tested this on my Debian testing and it seemed fine.  It is 2016 after
> > all so I guess it's time to jump into the C++11 waters if there are no
> > objections.  I figure we'll be good to roll out C++14 in 2019 or 2020. :).
> > 
> > On 3/18/2016 12:08 AM, Simon Richter wrote:
> >> Hi Wayne,
> >>
> >> On 17.03.2016 20:35, Wayne Stambaugh wrote:
> >>
> >>> @Simon, when cmake is < 3.1 you set the -std-c++11 flag for gcc and
> >>> clang instead of the -gnu-c++11.  This seems to be an issue that should
> >>> be addressed.  Maybe this is what is breaking @Mark's builds.  I would
> >>> feel more comfortable if we figure this out before I commit the patch.
> >>
> >> It works for me on Debian jessie, with cmake 3.0.2 and gcc 4.9.2, and on
> >> Ubunty trusty with cmake 2.8.12.2 and gcc 4.8.2.
> >>
> >> On Ubuntu trusty, wxPython 3.0 is not available as far as I can see, so
> >> that build was without scripting support.
> >>
> >>Simon
> >>
> >>
> >>
> >> ___
> >> 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] [PATCH] Enable C++11

2016-03-21 Thread Wayne Stambaugh 
Going, going, gone!  Since I haven't gotten any objections, I committed
the patch to enable C++11.  Thanks Simon for the patch but be prepared
for the grumbling. :)

On 3/18/2016 3:42 PM, Wayne Stambaugh wrote:
> I tested this on my Debian testing and it seemed fine.  It is 2016 after
> all so I guess it's time to jump into the C++11 waters if there are no
> objections.  I figure we'll be good to roll out C++14 in 2019 or 2020. :).
> 
> On 3/18/2016 12:08 AM, Simon Richter wrote:
>> Hi Wayne,
>>
>> On 17.03.2016 20:35, Wayne Stambaugh wrote:
>>
>>> @Simon, when cmake is < 3.1 you set the -std-c++11 flag for gcc and
>>> clang instead of the -gnu-c++11.  This seems to be an issue that should
>>> be addressed.  Maybe this is what is breaking @Mark's builds.  I would
>>> feel more comfortable if we figure this out before I commit the patch.
>>
>> It works for me on Debian jessie, with cmake 3.0.2 and gcc 4.9.2, and on
>> Ubunty trusty with cmake 2.8.12.2 and gcc 4.8.2.
>>
>> On Ubuntu trusty, wxPython 3.0 is not available as far as I can see, so
>> that build was without scripting support.
>>
>>Simon
>>
>>
>>
>> ___
>> 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] kicad StepUp nice MCAD renderings

2016-03-21 Thread easyw 

Hi David,

I was interested to see that mounting screws aren't included though.

that is a rendering that a kicad StepUp user shared at the kicad info
forum, but you are right ...
I also include screws on my kicad project both for bom and for
collisions checking.

It saves on time when purchasing, and building.

After I switched to MCAD side using my StepUp tools, everything has
become easier, even modeling or get models from manufacturers using STEP
as source
MCAD model is also a must in exchanging data with third parties

Regards
Maurice


On 21/03/2016 07.30, David Godfrey wrote:

Hi Maurice,

That is a VERY nice render.

I was interested to see that mounting screws aren't included though.

I've been including mounting screws as a schematic + pcb element for
 years now. It means they don't get missed on the bom, and as a side
effect they are visible  in a render.

Another advantage is you can have the correct hole size and keepout
areas in place for the screw, and never need to worry that you will
have issues at build time.

Generally I include all parts of a build in the schematic + pcb,
including enclosure, screws, standoffs, etc It saves on time when
purchasing, and building. Especially if you are handing a design to a
build house for turnkey delivery

Regards David G

On 20/03/16 06:43, easyw wrote:

Hi, thanks to an other happy user of my kicad StepUp tools, I'm
glad to share this nice rendering made in PTC Creo (ProE) after
having exported multiple kicad boards and parts with FreeCAD and
kicad StepUp tools to STEP and assembled them in mechanical 3D
environment

I'm attaching the picture that can be found at kicad forum
https://forum.kicad.info/t/how-to-share-step-3d-model-with-all-the-components-on-the-pcb-too/2542/12


http://photos.xavimages.co.uk/photos/i-x8ghdWk/0/O/i-x8ghdWk.jpg

this is a nice example of ECAD MCAD co-design and collaboration in
 kicad with an artistic touch for realistic rendering ...

Maurice


___ 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

[Kicad-developers] PATCH: IDF tools

2016-03-21 Thread Cirilo Bernardo 
The attached patch makes the following changes to the IDF
tool 'dxf2idf':

1. DXF units are now correctly scaled to mm
2. Polylines are now supported
3. LWPolylines are now supported

- Cirilo
=== modified file 'utils/idftools/dxf2idf.cpp'
--- utils/idftools/dxf2idf.cpp	2014-02-05 09:27:21 +
+++ utils/idftools/dxf2idf.cpp	2016-03-21 10:16:01 +
@@ -29,6 +29,13 @@
 // differences in angle smaller than MIN_ANG are considered equal
 #define MIN_ANG (0.01)
 
+// min and max bulge bracketing min. arc before transition to line segment
+// and max. arc limit
+// MIN_BULGE = 0.002 ~0.45 degrees
+// MAX_BULGE = 2000  ~89.97 degrees
+#define MIN_BULGE 0.002
+#define MAX_BULGE 2000.0
+
 DXF2IDF::~DXF2IDF()
 {
 while( !lines.empty() )
@@ -60,22 +67,12 @@
 {
 IDF_POINT p1, p2;
 
-p1.x = data.basePoint.x;
-p1.y = data.basePoint.y;
-p2.x = data.secPoint.x;
-p2.y = data.secPoint.y;
-
-IDF_SEGMENT* seg = new IDF_SEGMENT( p1, p2 );
-
-if( !seg )
-{
-std::cerr << "* FAULT: could not add a linear segment to the outline\n";
-}
-else
-{
-lines.push_back( seg );
-}
-
+p1.x = data.basePoint.x * m_scale;
+p1.y = data.basePoint.y * m_scale;
+p2.x = data.secPoint.x * m_scale;
+p2.y = data.secPoint.y * m_scale;
+
+insertLine( p1, p2 );
 return;
 }
 
@@ -84,22 +81,16 @@
 {
 IDF_POINT p1, p2;
 
-p1.x = data.basePoint.x;
-p1.y = data.basePoint.y;
+p1.x = data.basePoint.x * m_scale;
+p1.y = data.basePoint.y * m_scale;
 
-p2.x = p1.x + data.radious;
+p2.x = p1.x + data.radious * m_scale;
 p2.y = p1.y;
 
 IDF_SEGMENT* seg = new IDF_SEGMENT( p1, p2, 360, true );
 
-if( !seg )
-{
-std::cerr << "* FAULT: could not add a linear segment to the outline\n";
-}
-else
-{
+if( seg )
 lines.push_back( seg );
-}
 
 return;
 }
@@ -109,8 +100,8 @@
 {
 IDF_POINT p1, p2;
 
-p1.x = data.basePoint.x;
-p1.y = data.basePoint.y;
+p1.x = data.basePoint.x * m_scale;
+p1.y = data.basePoint.y * m_scale;
 
 // note: DXF circles always run CCW
 double ea = data.endangle;
@@ -118,21 +109,15 @@
 while( ea < data.staangle )
 ea += M_PI;
 
-p2.x = p1.x + cos( data.staangle ) * data.radious;
-p2.y = p1.y + sin( data.staangle ) * data.radious;
+p2.x = p1.x + cos( data.staangle ) * data.radious * m_scale;
+p2.y = p1.y + sin( data.staangle ) * data.radious * m_scale;
 
 double angle = ( ea - data.staangle ) * 180.0 / M_PI;
 
 IDF_SEGMENT* seg = new IDF_SEGMENT( p1, p2, angle, true );
 
-if( !seg )
-{
-std::cerr << "* FAULT: could not add a linear segment to the outline\n";
-}
-else
-{
+if( seg )
 lines.push_back( seg );
-}
 
 return;
 }
@@ -290,3 +275,186 @@
 
 return true;
 }
+
+
+void DXF2IDF::addHeader( const DRW_Header* data )
+{
+std::map::const_iterator it;
+m_scale = 1.0; // assume no scale factor
+
+for( it = data->vars.begin(); it != data->vars.end(); ++it )
+{
+std::string key = ( (*it).first ).c_str();
+
+if( key == "$INSUNITS" )
+{
+DRW_Variant* var = (*it).second;
+
+switch( var->content.i )
+{
+case 1: // inches
+m_scale = 25.4;
+break;
+
+case 2: // feet
+m_scale = 304.8;
+break;
+
+case 5: // centimeters
+m_scale = 10.0;
+break;
+
+case 6: // meters
+m_scale = 1000.0;
+break;
+
+case 8: // microinches
+m_scale = 2.54e-5;
+break;
+
+case 9: // mils
+m_scale = 0.0254;
+break;
+
+case 10:// yards
+m_scale = 914.4;
+break;
+
+case 11:// Angstroms
+m_scale = 1.0e-7;
+break;
+
+case 12:// nanometers
+m_scale = 1.0e-6;
+break;
+
+case 13:// micrometers
+m_scale = 1.0e-3;
+break;
+
+case 14:// decimeters
+m_scale = 100.0;
+break;
+
+default:
+// use the default of 1.0 for:
+// 0: Unspecified Units
+// 4: mm
+// 3: miles
+// 7: kilometers
+// 15: decameters
+// 16: hectometers
+// 17: gigameters
+// 18: AU
+// 19: lightyears
+// 20: parsecs
+break;
+}
+}
+}
+}
+
+
+void DXF