Re: [Kicad-developers] build error on macos on 5.1 branch

[Adam Wolf]

Thanks!

On Thu, Jul 11, 2019, 2:36 PM Seth Hillbrand  wrote:

> Ah, I see Jeff fixed up my commit for OSX in the master branch.  I've
> cherry-picked his fix for 5.1.  Let me know if it doesn't fix it.
>
> Best-
> Seth
>
> On 2019-07-11 13:59, Adam Wolf wrote:
> > Builds at at 044b4a6d4 on master went through fine.
> >
> > Adam
> >
> > On Thu, Jul 11, 2019 at 11:04 AM Seth Hillbrand 
> > wrote:
> >>
> >> Hi Adam-
> >>
> >> This looks like the result of a cherry-pick I did the other day.  Do
> >> you
> >> get this error in the master branch as well?
> >>
> >> -S
> >>
> >> On 2019-07-11 11:55, Adam Wolf wrote:
> >> > Hi folks!
> >> >
> >> > Running into a build error on my macOS jobs for 5.1:
> >> >
> >> > I'm adding what I think is the appropriate message...
> >> >
> >> >
> >> > 05:46:01 default: [ 69%] Building CXX object
> >> >
> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_gfx/graphics_import_mgr.cpp.o
> >> > 05:46:04 default: In file included from
> >> >
> /vagrant/build/kicad/src/kicad/pcbnew/import_gfx/graphics_import_mgr.cpp:27:
> >> > 05:46:04 default:
> >> > /vagrant/build/kicad/src/kicad/pcbnew/import_gfx/dxf_import_plugin.h:
> >> > 05:46:04 default: 151:16:
> >> > 05:46:04 default: error: no matching constructor for
> >> > initialization of 'wxArrayString'
> >> > 05:46:04 default: return wxArrayString( 1,
> >> > formatWildcardExt( "dxf" ) );
> >> > 05:46:04 default:^
> >> > ~
> >> > 05:46:04 default:
> >> > /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:54:
> >> > 05:46:04 default: 5: note: candidate constructor not viable: no
> >> > known conversion from 'wxString' to 'const char **' for 2nd argument
> >> > 05:46:04 default:
> >> > 05:46:04 default: wxArrayString(size_t sz, const char** a);
> >> > 05:46:04 default: ^
> >> > 05:46:04 default:
> >> > /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:55:5:
> >> > 05:46:04 default: note: candidate constructor not viable: no known
> >> > conversion from 'wxString' to 'const wchar_t **' for 2nd argument
> >> > 05:46:04 default: wxArrayString(size_t sz, const wchar_t** a);
> >> > 05:46:04 default: ^
> >> > 05:46:04 default:
> >> > /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:56
> >> > 05:46:04 default: :
> >> > 05:46:04 default: 5: note: candidate constructor not viable: no
> >> > known conversion from 'wxString' to 'const wxString *' for 2nd
> >> > argument
> >> > 05:46:04 default: wxArrayString(size_t sz, const wxString* a);
> >> > 05:46:04 default: ^
> >> > 05:46:04 default:
> >> > /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:53:5:
> >> > 05:46:04 default: note: candidate constructor not viable: requires
> >> > single argument 'a', but 2 arguments were provided
> >> > 05:46:04 default: wxArrayString(const wxArrayString& a) :
> >> > wxArrayStringBase(a) { }
> >> > 05:46:04 default: ^
> >> > 05:46:04 default:
> >> > /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:52:5: note
> >> > 05:46:04 default: : candidate constructor not viable: requires 0
> >> > arguments, but 2 were provided
> >> > 05:46:04 default: wxArrayString() { }
> >> > 05:46:04 default: ^
> >> > 05:46:04 default: In file included from
> >> >
> /vagrant/build/kicad/src/kicad/pcbnew/import_gfx/graphics_import_mgr.cpp:28:
> >> > 05:46:04 default:
> >> >
> /vagrant/build/kicad/src/kicad/pcbnew/import_gfx/svg_import_plugin.h:49:16:
> >> > error: no matching constructor for initialization of 'wxArrayString'
> >> > 05:46:04 default: return wxArrayString( 1,
> >> > formatWildcardExt( "svg" ) );
> >> > 05:46:04 default:^
> >> > ~
> >> > 05:46:04 default:
> >> > /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:54:5: note:
> >> > candidate constructor not viable: no known conversion from 'wxString'
> >> > to 'const char **' for 2nd argument
> >> > 05:46:04 default: wxArrayString(size_t sz, const char** a);
> >> > 05:46:04 default:
> >> > 05:46:04 default: ^
> >> > 05:46:04 default:
> >> > /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:55:5:
> >> > 05:46:04 default: note: candidate constructor not viable: no known
> >> > conversion from 'wxString' to 'const wchar_t **' for 2nd argument
> >> > 05:46:04 default: wxArrayString(size_t sz, const wchar_t** a);
> >> > 05:46:04 default: ^
> >> > 05:46:04 default:
> >> > /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:56:
> >> > 05:46:04 default: 5: note:
> >> > 05:46:04 default: candidate constructor not viable: no known
> >> > conversion from 'wxString' to 'const wxString *' for 2nd argument
> >> > 05:46:04 default: wxArrayString(size_t sz, const wxString* a);
> >> > 05:46:04 default:
> >> > 05:46:04 default: ^
> >> > 

Re: [Kicad-developers] build error on macos on 5.1 branch

[Seth Hillbrand]

Ah, I see Jeff fixed up my commit for OSX in the master branch.  I've 
cherry-picked his fix for 5.1.  Let me know if it doesn't fix it.


Best-
Seth

On 2019-07-11 13:59, Adam Wolf wrote:

Builds at at 044b4a6d4 on master went through fine.

Adam

On Thu, Jul 11, 2019 at 11:04 AM Seth Hillbrand  
wrote:


Hi Adam-

This looks like the result of a cherry-pick I did the other day.  Do 
you

get this error in the master branch as well?

-S

On 2019-07-11 11:55, Adam Wolf wrote:
> Hi folks!
>
> Running into a build error on my macOS jobs for 5.1:
>
> I'm adding what I think is the appropriate message...
>
>
> 05:46:01 default: [ 69%] Building CXX object
> 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_gfx/graphics_import_mgr.cpp.o
> 05:46:04 default: In file included from
> /vagrant/build/kicad/src/kicad/pcbnew/import_gfx/graphics_import_mgr.cpp:27:
> 05:46:04 default:
> /vagrant/build/kicad/src/kicad/pcbnew/import_gfx/dxf_import_plugin.h:
> 05:46:04 default: 151:16:
> 05:46:04 default: error: no matching constructor for
> initialization of 'wxArrayString'
> 05:46:04 default: return wxArrayString( 1,
> formatWildcardExt( "dxf" ) );
> 05:46:04 default:^
> ~
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:54:
> 05:46:04 default: 5: note: candidate constructor not viable: no
> known conversion from 'wxString' to 'const char **' for 2nd argument
> 05:46:04 default:
> 05:46:04 default: wxArrayString(size_t sz, const char** a);
> 05:46:04 default: ^
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:55:5:
> 05:46:04 default: note: candidate constructor not viable: no known
> conversion from 'wxString' to 'const wchar_t **' for 2nd argument
> 05:46:04 default: wxArrayString(size_t sz, const wchar_t** a);
> 05:46:04 default: ^
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:56
> 05:46:04 default: :
> 05:46:04 default: 5: note: candidate constructor not viable: no
> known conversion from 'wxString' to 'const wxString *' for 2nd
> argument
> 05:46:04 default: wxArrayString(size_t sz, const wxString* a);
> 05:46:04 default: ^
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:53:5:
> 05:46:04 default: note: candidate constructor not viable: requires
> single argument 'a', but 2 arguments were provided
> 05:46:04 default: wxArrayString(const wxArrayString& a) :
> wxArrayStringBase(a) { }
> 05:46:04 default: ^
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:52:5: note
> 05:46:04 default: : candidate constructor not viable: requires 0
> arguments, but 2 were provided
> 05:46:04 default: wxArrayString() { }
> 05:46:04 default: ^
> 05:46:04 default: In file included from
> /vagrant/build/kicad/src/kicad/pcbnew/import_gfx/graphics_import_mgr.cpp:28:
> 05:46:04 default:
> /vagrant/build/kicad/src/kicad/pcbnew/import_gfx/svg_import_plugin.h:49:16:
> error: no matching constructor for initialization of 'wxArrayString'
> 05:46:04 default: return wxArrayString( 1,
> formatWildcardExt( "svg" ) );
> 05:46:04 default:^
> ~
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:54:5: note:
> candidate constructor not viable: no known conversion from 'wxString'
> to 'const char **' for 2nd argument
> 05:46:04 default: wxArrayString(size_t sz, const char** a);
> 05:46:04 default:
> 05:46:04 default: ^
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:55:5:
> 05:46:04 default: note: candidate constructor not viable: no known
> conversion from 'wxString' to 'const wchar_t **' for 2nd argument
> 05:46:04 default: wxArrayString(size_t sz, const wchar_t** a);
> 05:46:04 default: ^
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:56:
> 05:46:04 default: 5: note:
> 05:46:04 default: candidate constructor not viable: no known
> conversion from 'wxString' to 'const wxString *' for 2nd argument
> 05:46:04 default: wxArrayString(size_t sz, const wxString* a);
> 05:46:04 default:
> 05:46:04 default: ^
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h
> 05:46:04 default: :53:5:
> 05:46:04 default:  note: candidate constructor not viable:
> requires single argument 'a', but 2 arguments were provided
> 05:46:04 default: wxArrayString(const wxArrayString& a) :
> wxArrayStringBase(a) { }
> 05:46:04 default: ^
> 05:46:04 default:
> /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:
> 05:46:04 default: 52:5
> 05:46:04 default: : note
> 05:46:04 default: : candidate constructor not viable: 

Re: [Kicad-developers] [PATCH] Crash Reporter

[Nick Østergaard]

@Tomasz Wlostowski  I just found that it looks like someone has
uploaded a wxwidgets 3.1 pkgbuild for the mingw-packages for msys2, I
could try to build and and rebuild your branch for windows.

https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-wxWidgets3.1/PKGBUILD

On Tue, 9 Jul 2019 at 14:09, Wayne Stambaugh  wrote:
>
> Tom,
>
> On 7/9/19 2:41 AM, Tomasz Wlostowski wrote:
> > On 06/07/2019 21:10, Ian McInerney wrote:
> >> Tom,
> >>
> >> Not to pile on the questions, but does the linux stack trace support
> >> exist in the entire 3.0.x line, or how far back does it go? Currently,
> >> the minimum version searched by cmake is 3.0.0, and some major linux
> >> distros only have 3.0.2 (Debian Stable, EPEL6/7, and Ubuntu 16.04 to
> >> name a few).
> >
> > Hi,
> >
> > Under liunx stack trace works fine in 3.0.2. Under Windows it's not
> > implemented at all (unless using a crazy hack self-exception-raising
> > hack that works only under MSVC).
> >
> > I can work this around by having our own Windows stack walker - after
> > all the whole purpose  of the crash reporter was easy debug reports for
> > Windows users. Under Linux everyone knows how to use a debugger,
> > otherwise it's impossible to work ;-)
> I'm assuming that you mean that you are going to pull the
> wxDebugReporter code from the 3.1 branch of wxWidgets which can be
> removed once wxWidgets 3.2 becomes the default.  If it's any more than
> that, I would rather wait until 3.2 is available.
>
> >
> > Tom
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
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 v2 0/8] MSVC Build

[Nick Østergaard]

It looks like people are happy with the patches, can we get them
merged so they don't get lost and we don't need to rebase them locally
all the time?

On Fri, 5 Jul 2019 at 19:01, Simon Richter  wrote:
>
> Hi,
>
> On Fri, Jul 05, 2019 at 06:24:45PM +0200, Tomasz Wlostowski wrote:
>
> > > I can't test the Windows functionality but this doesn't appear to break
> > > anything on Linux.
>
> > I'm ok with Simon's patches. Can give them a try on MSVC, but I'm pretty
> > confident they will work already.
>
> These are tested on Linux (with "git rebase -x make", so individual commits
> compile on their own) and Windows with MSYS2 and MSVC through Jenkins. I
> can't test MacOS.
>
> > @Simon: Now that we'll be supporting MSVC, should we put a 'MSVC
> > precompiled library kit' somewhere on Kicad webpage to spare people the
> > hassle of finding the right version on Jenkins?
>
> Yes, can do. I'm going to investigate vcpkg as well, since it has cmake
> integration, so it reduces to "tell vcpkg that we need these packages, and
> tell cmake to talk to vcpkg". My initial experiments were promising, it
> seems to be missing oce and ngspice, and I'm unsure about the status of
> wxpython, but everything else seems to be there.
>
>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] Arc Adjustment proposal

[easyw]

Don't get me wrong... I don't say KiCad has not to be improved.

I just say that complex mechanical objects have to be designed and 
checked in a mechanical environment.


And that is exactly what we have done with the KiCAd libraries...
Most of footprints are designed using scripts and are checked using a 
mechanical sw.


I agree that a new user should find a decent drawing editor, but when 
he/she gets experienced, the right direction is toward a MCAD/ECAD 
collaboration.


All commercial ECADs do it already, even with the entry level products.
So mechanical collaboration should be strongly suggested IMO.

Maurice


On 07/11/2019 6:51 PM, Jon Evans wrote:

I strongly disagree with this mindset.
It feels like saying that because KiCad is currently bad at something, it
should always be bad at something and users should just use a different
tool because KiCad will never be good at it.
If we have the developer interest to make KiCad good at drawing things, why
not do so?
It doesn't help that the available FOSS MCAD tools are (in my opinion) much
less capable relative to their commercial competitors than KiCad is
relative to commercial ECAD tools.

-Jon

On Thu, Jul 11, 2019 at 12:16 PM easyw  wrote:



On 07/11/2019 5:17 PM, Jeff Young wrote:


Here’s a footprint I drew recently which was made much harder by Kicad’s

focus on arc centre points:




This is exactly an example that should be done in a mechanical CAD and
imported later in KiCAD (i.e. as DXF).

Complex mechanical object should be addressed with mechanical CAD, not
ECAD.


___
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] Arc Adjustment proposal

[Jon Evans]

I strongly disagree with this mindset.
It feels like saying that because KiCad is currently bad at something, it
should always be bad at something and users should just use a different
tool because KiCad will never be good at it.
If we have the developer interest to make KiCad good at drawing things, why
not do so?
It doesn't help that the available FOSS MCAD tools are (in my opinion) much
less capable relative to their commercial competitors than KiCad is
relative to commercial ECAD tools.

-Jon

On Thu, Jul 11, 2019 at 12:16 PM easyw  wrote:

>
> On 07/11/2019 5:17 PM, Jeff Young wrote:
> >
> > Here’s a footprint I drew recently which was made much harder by Kicad’s
> focus on arc centre points:
> >
>
> This is exactly an example that should be done in a mechanical CAD and
> imported later in KiCAD (i.e. as DXF).
>
> Complex mechanical object should be addressed with mechanical CAD, not
> ECAD.
>
>
> ___
> 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] Arc Adjustment proposal

[Dino Ghilardi]

On 11/07/19 18:16, easyw wrote:


On 07/11/2019 5:17 PM, Jeff Young wrote:


Here’s a footprint I drew recently which was made much harder by 
Kicad’s focus on arc centre points:




This is exactly an example that should be done in a mechanical CAD and 
imported later in KiCAD (i.e. as DXF).


Complex mechanical object should be addressed with mechanical CAD, not 
ECAD.




I agree, but that implies that the gui who uses kicad for electronics 
also needs to have (and learn) a mechanical cad and this is not always 
true (the world is full of different people with different backgrounds).


If you are starting using kicad and you never used a mechanical cad the 
time you need to learn it will be more than the time needed to struggle 
with the limited 2D-lines/arcs capabilities of kicad.


Also the fact that there is not a dxf export in footprint editor does 
not help going back and forth between the two cads.


Of course, as you say, an experienced user, with knowledge of both 
electronic and mechanic (2D and 3D) cads will use the right tool for the 
right work and do it efficiently, but a new user (or a student) that 
starts from the electronic cad would just say "I was not able to do it, 
the tool is too limited, no good cad" and leave kicad.


Cheers,
Dino.

___
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] Arc Adjustment proposal

[Jeff Young]

If you’re going to do everything in DXF, why have drawing tools at all?

(And by corollary, if you’re going to have drawing tools then make them 
suitable for the task at hand.)

Cheers,
Jeff.


> On 11 Jul 2019, at 17:16, easyw  wrote:
> 
> 
> On 07/11/2019 5:17 PM, Jeff Young wrote:
>> Here’s a footprint I drew recently which was made much harder by Kicad’s 
>> focus on arc centre points:
> 
> This is exactly an example that should be done in a mechanical CAD and 
> imported later in KiCAD (i.e. as DXF).
> 
> Complex mechanical object should be addressed with mechanical CAD, not ECAD.
> 


___
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] Arc Adjustment proposal

[easyw]

On 07/11/2019 5:17 PM, Jeff Young wrote:


Here’s a footprint I drew recently which was made much harder by Kicad’s focus 
on arc centre points:



This is exactly an example that should be done in a mechanical CAD and 
imported later in KiCAD (i.e. as DXF).


Complex mechanical object should be addressed with mechanical CAD, not ECAD.


___
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] build error on macos on 5.1 branch

[Seth Hillbrand]

Hi Adam-

This looks like the result of a cherry-pick I did the other day.  Do you 
get this error in the master branch as well?


-S

On 2019-07-11 11:55, Adam Wolf wrote:

Hi folks!

Running into a build error on my macOS jobs for 5.1:

I'm adding what I think is the appropriate message...


05:46:01 default: [ 69%] Building CXX object
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_gfx/graphics_import_mgr.cpp.o
05:46:04 default: In file included from
/vagrant/build/kicad/src/kicad/pcbnew/import_gfx/graphics_import_mgr.cpp:27:
05:46:04 default:
/vagrant/build/kicad/src/kicad/pcbnew/import_gfx/dxf_import_plugin.h:
05:46:04 default: 151:16:
05:46:04 default: error: no matching constructor for
initialization of 'wxArrayString'
05:46:04 default: return wxArrayString( 1,
formatWildcardExt( "dxf" ) );
05:46:04 default:^
~
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:54:
05:46:04 default: 5: note: candidate constructor not viable: no
known conversion from 'wxString' to 'const char **' for 2nd argument
05:46:04 default:
05:46:04 default: wxArrayString(size_t sz, const char** a);
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:55:5:
05:46:04 default: note: candidate constructor not viable: no known
conversion from 'wxString' to 'const wchar_t **' for 2nd argument
05:46:04 default: wxArrayString(size_t sz, const wchar_t** a);
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:56
05:46:04 default: :
05:46:04 default: 5: note: candidate constructor not viable: no
known conversion from 'wxString' to 'const wxString *' for 2nd
argument
05:46:04 default: wxArrayString(size_t sz, const wxString* a);
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:53:5:
05:46:04 default: note: candidate constructor not viable: requires
single argument 'a', but 2 arguments were provided
05:46:04 default: wxArrayString(const wxArrayString& a) :
wxArrayStringBase(a) { }
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:52:5: note
05:46:04 default: : candidate constructor not viable: requires 0
arguments, but 2 were provided
05:46:04 default: wxArrayString() { }
05:46:04 default: ^
05:46:04 default: In file included from
/vagrant/build/kicad/src/kicad/pcbnew/import_gfx/graphics_import_mgr.cpp:28:
05:46:04 default:
/vagrant/build/kicad/src/kicad/pcbnew/import_gfx/svg_import_plugin.h:49:16:
error: no matching constructor for initialization of 'wxArrayString'
05:46:04 default: return wxArrayString( 1,
formatWildcardExt( "svg" ) );
05:46:04 default:^
~
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:54:5: note:
candidate constructor not viable: no known conversion from 'wxString'
to 'const char **' for 2nd argument
05:46:04 default: wxArrayString(size_t sz, const char** a);
05:46:04 default:
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:55:5:
05:46:04 default: note: candidate constructor not viable: no known
conversion from 'wxString' to 'const wchar_t **' for 2nd argument
05:46:04 default: wxArrayString(size_t sz, const wchar_t** a);
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:56:
05:46:04 default: 5: note:
05:46:04 default: candidate constructor not viable: no known
conversion from 'wxString' to 'const wxString *' for 2nd argument
05:46:04 default: wxArrayString(size_t sz, const wxString* a);
05:46:04 default:
05:46:04 default: ^
05:46:04 default: 
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h

05:46:04 default: :53:5:
05:46:04 default:  note: candidate constructor not viable:
requires single argument 'a', but 2 arguments were provided
05:46:04 default: wxArrayString(const wxArrayString& a) :
wxArrayStringBase(a) { }
05:46:04 default: ^
05:46:04 default: 
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:

05:46:04 default: 52:5
05:46:04 default: : note
05:46:04 default: : candidate constructor not viable: requires 0
arguments, but 2 were provided
05:46:04 default: wxArrayString() { }
05:46:04 default: ^
05:46:05 default: 2 errors generated.
05:46:05 default: make[6]: ***
[pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_gfx/graphics_import_mgr.cpp.o]
Error 1
05:46:05 default: make[5]: ***
[pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/all] Error 2
05:46:05 default: make[4]: *** [all] Error 2

Thanks folks!

___
Mailing 

[Kicad-developers] build error on macos on 5.1 branch

[Adam Wolf]

Hi folks!

Running into a build error on my macOS jobs for 5.1:

I'm adding what I think is the appropriate message...


05:46:01 default: [ 69%] Building CXX object
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_gfx/graphics_import_mgr.cpp.o
05:46:04 default: In file included from
/vagrant/build/kicad/src/kicad/pcbnew/import_gfx/graphics_import_mgr.cpp:27:
05:46:04 default:
/vagrant/build/kicad/src/kicad/pcbnew/import_gfx/dxf_import_plugin.h:
05:46:04 default: 151:16:
05:46:04 default: error: no matching constructor for
initialization of 'wxArrayString'
05:46:04 default: return wxArrayString( 1,
formatWildcardExt( "dxf" ) );
05:46:04 default:^
~
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:54:
05:46:04 default: 5: note: candidate constructor not viable: no
known conversion from 'wxString' to 'const char **' for 2nd argument
05:46:04 default:
05:46:04 default: wxArrayString(size_t sz, const char** a);
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:55:5:
05:46:04 default: note: candidate constructor not viable: no known
conversion from 'wxString' to 'const wchar_t **' for 2nd argument
05:46:04 default: wxArrayString(size_t sz, const wchar_t** a);
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:56
05:46:04 default: :
05:46:04 default: 5: note: candidate constructor not viable: no
known conversion from 'wxString' to 'const wxString *' for 2nd
argument
05:46:04 default: wxArrayString(size_t sz, const wxString* a);
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:53:5:
05:46:04 default: note: candidate constructor not viable: requires
single argument 'a', but 2 arguments were provided
05:46:04 default: wxArrayString(const wxArrayString& a) :
wxArrayStringBase(a) { }
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:52:5: note
05:46:04 default: : candidate constructor not viable: requires 0
arguments, but 2 were provided
05:46:04 default: wxArrayString() { }
05:46:04 default: ^
05:46:04 default: In file included from
/vagrant/build/kicad/src/kicad/pcbnew/import_gfx/graphics_import_mgr.cpp:28:
05:46:04 default:
/vagrant/build/kicad/src/kicad/pcbnew/import_gfx/svg_import_plugin.h:49:16:
error: no matching constructor for initialization of 'wxArrayString'
05:46:04 default: return wxArrayString( 1,
formatWildcardExt( "svg" ) );
05:46:04 default:^
~
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:54:5: note:
candidate constructor not viable: no known conversion from 'wxString'
to 'const char **' for 2nd argument
05:46:04 default: wxArrayString(size_t sz, const char** a);
05:46:04 default:
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:55:5:
05:46:04 default: note: candidate constructor not viable: no known
conversion from 'wxString' to 'const wchar_t **' for 2nd argument
05:46:04 default: wxArrayString(size_t sz, const wchar_t** a);
05:46:04 default: ^
05:46:04 default:
/vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:56:
05:46:04 default: 5: note:
05:46:04 default: candidate constructor not viable: no known
conversion from 'wxString' to 'const wxString *' for 2nd argument
05:46:04 default: wxArrayString(size_t sz, const wxString* a);
05:46:04 default:
05:46:04 default: ^
05:46:04 default: /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h
05:46:04 default: :53:5:
05:46:04 default:  note: candidate constructor not viable:
requires single argument 'a', but 2 arguments were provided
05:46:04 default: wxArrayString(const wxArrayString& a) :
wxArrayStringBase(a) { }
05:46:04 default: ^
05:46:04 default: /vagrant/build/wxwidgets-dest/include/wx-3.0/wx/arrstr.h:
05:46:04 default: 52:5
05:46:04 default: : note
05:46:04 default: : candidate constructor not viable: requires 0
arguments, but 2 were provided
05:46:04 default: wxArrayString() { }
05:46:04 default: ^
05:46:05 default: 2 errors generated.
05:46:05 default: make[6]: ***
[pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_gfx/graphics_import_mgr.cpp.o]
Error 1
05:46:05 default: make[5]: ***
[pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/all] Error 2
05:46:05 default: make[4]: *** [all] Error 2

Thanks folks!

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

Re: [Kicad-developers] Arc Adjustment proposal

[Jeff Young]

Here’s a footprint I drew recently which was made much harder by Kicad’s focus 
on arc centre points:



> On 11 Jul 2019, at 15:46, Eeli Kaikkonen  wrote:
> 
> 
> 
> to 11. heinäk. 2019 klo 15.43 easyw (ea...@katamail.com 
> ) kirjoitti:
> 
> On 07/11/2019 1:21 PM, Dino Ghilardi wrote:
> > On 11/07/19 12:26, easyw wrote:
> > then your fashion design should use a proper CAD to design the board, 
> > and the EDGE should then imported inside KiCAD i.e. from a svg or a 
> > dxf file or handled directly with FreeCAD.
> >
> > Yes, he should... but he won't: (he's not under my control).
> 
> I don't get your user case...
> 
> I realized even before you (easyw) wrote that I was partly wrong about the 
> relative importance of different features of arc. But I have lately been 
> exposed to a workflow quite similar to what Dino told about. And he's exactly 
> right - "should do" and "do" are two different things. In small companies 
> fighting for their life you don't have the luxury of having dedicated 
> "fashion designer" and people use what they can and do what they can. I won't 
> go into details here to save myself and some other people from embarrassment; 
> for example I won't mention STL as intermediate format.
> 
> I don't blame KiCad at all for not supporting suboptimal design workflows but 
> it would be good if it would support all use cases. This is of course only 
> tangential for the discussion about the file format, but maybe it can at 
> least give something "FYI" to the developers. What Tom said is very 
> interesting. The new UI and backend may make current feature wishes 
> fullfilled or unnecessary.
> 
> Eeli Kaikkonen
> ___
> 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] Arc Adjustment proposal

[Eeli Kaikkonen]

to 11. heinäk. 2019 klo 15.43 easyw (ea...@katamail.com) kirjoitti:

>
> On 07/11/2019 1:21 PM, Dino Ghilardi wrote:
> > On 11/07/19 12:26, easyw wrote:
> > then your fashion design should use a proper CAD to design the board,
> > and the EDGE should then imported inside KiCAD i.e. from a svg or a
> > dxf file or handled directly with FreeCAD.
> >
> > Yes, he should... but he won't: (he's not under my control).
>
> I don't get your user case...
>

I realized even before you (easyw) wrote that I was partly wrong about the
relative importance of different features of arc. But I have lately been
exposed to a workflow quite similar to what Dino told about. And he's
exactly right - "should do" and "do" are two different things. In small
companies fighting for their life you don't have the luxury of having
dedicated "fashion designer" and people use what they can and do what they
can. I won't go into details here to save myself and some other people from
embarrassment; for example I won't mention STL as intermediate format.

I don't blame KiCad at all for not supporting suboptimal design workflows
but it would be good if it would support all use cases. This is of course
only tangential for the discussion about the file format, but maybe it can
at least give something "FYI" to the developers. What Tom said is very
interesting. The new UI and backend may make current feature wishes
fullfilled or unnecessary.

Eeli Kaikkonen
___
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] Arc Adjustment proposal

[Dino Ghilardi]

On 11/07/19 14:42, easyw wrote:>
> On 07/11/2019 1:21 PM, Dino Ghilardi wrote:
>> On 11/07/19 12:26, easyw wrote:
>> then your fashion design should use a proper CAD to design the board,
>> and the EDGE should then imported inside KiCAD i.e. from a svg or a
>> dxf file or handled directly with FreeCAD.
>>
>> Yes, he should... but he won't: (he's not under my control).
>
> I don't get your user case...
> are you receiving
> 1) a KiCAD pcb board from your fashion designer
> or
> 2) the enclosure for your board, coming from the fashion designer
> or
> 3) the outline of the pcb in external format
>
> The 1) is quite a weird case... your fashion designer should us
> mechanical sw to define the board outlines
>
> The 2) case is totally on your control...
> you need to use a mechanical sw to create pcb outline fitting your
> enclosure
>
> The same for the 3) case, you can fix the file before importing inside
> kicad.
>
> Please have a search for "ECAD MCAD Collaboration" for a deeper insight

I know there is a better or "correct" way do do anything, but in my 
opinion the question is not how a user gets to the trouble situation, or 
how to workaround it re-doing part of his work, but how the software 
helps to fix it when the problem is found: the easier is to get out of 
troubles, the better is the software (at least from the user's point of 
view). ...but now we are going a little bit off-topic.



now...back to the main topic:

Also I like the Tomasz point of view to store
"start/end/midpoint and the set of
CS arc input parameters which have been specified by the user"

It has the advantage that the stored parameters are just what the user 
wanted when the arc was created, also the arc-properties dialog could be 
modified in order to be able to enter center-start-angle or three-points 
arc (I'd like to have that).
Also probably makes the implementation of a "three-point-arc" tool 
easier, making easy to have the three points on grid.


Cheers, Dino.


___
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] Arc Adjustment proposal

[Seth Hillbrand]

Hi Tom-

On 2019-07-11 08:52, Tomasz Wlostowski wrote:

As I've been working on the Constraint Solver for a while, I'd like to
add my 5 cents too. The solver allows to define arcs in different ways:
- center/angles/radius
- start/end point (tangential to adjacent lines/arcs)

The input parameters to the CS is some subset of the above. The outputs
are start/end/midpoint, which define the geometry of an arc for other
processes (plotting/drawing/etc.). In order to derive the arc from its
definition based radius/angles, I need that radius and angles to be
stored in the file too - for example calculating the radius back and
forth from endpoints/midpoint would accumulate rounding errors.

What would you say about storing the start/end/midpoint and the set of
CS arc input parameters which have been specified by the user?


I prefer to avoid extra parameters if we can as it makes editing by hand 
much harder.  But if we need them, I'm not opposed.  I'm not certain, 
however, how we keep the parameter relation under affine transformation 
as someone needs to drive the other.  It feels like we lose the relation 
during computation and not during storage.  What am I missing?


Best-
Seth

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

Re: [Kicad-developers] Arc Adjustment proposal

[Tomasz Wlostowski]

On 10/07/2019 19:25, Seth Hillbrand wrote:
> 
> Proposed solution: I would like to adjust the pcbnew file format and
> internal SHAPE_ARC, DRAWSEGMENT arc and EDGE_MODULE arc to use a single
> format consisting of start point, mid point and end point.  Mid point
> here is defined as the point along the arc that is at the half-angle of
> the full arc.
> 

Hi Seth,

As I've been working on the Constraint Solver for a while, I'd like to
add my 5 cents too. The solver allows to define arcs in different ways:
- center/angles/radius
- start/end point (tangential to adjacent lines/arcs)

The input parameters to the CS is some subset of the above. The outputs
are start/end/midpoint, which define the geometry of an arc for other
processes (plotting/drawing/etc.). In order to derive the arc from its
definition based radius/angles, I need that radius and angles to be
stored in the file too - for example calculating the radius back and
forth from endpoints/midpoint would accumulate rounding errors.

What would you say about storing the start/end/midpoint and the set of
CS arc input parameters which have been specified by the user?

Tom



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

Re: [Kicad-developers] Arc Adjustment proposal

[easyw]

On 07/11/2019 1:21 PM, Dino Ghilardi wrote:

On 11/07/19 12:26, easyw wrote:
then your fashion design should use a proper CAD to design the board, 
and the EDGE should then imported inside KiCAD i.e. from a svg or a 
dxf file or handled directly with FreeCAD.


Yes, he should... but he won't: (he's not under my control).


I don't get your user case...
are you receiving
1) a KiCAD pcb board from your fashion designer
or
2) the enclosure for your board, coming from the fashion designer
or
3) the outline of the pcb in external format

The 1) is quite a weird case... your fashion designer should us 
mechanical sw to define the board outlines


The 2) case is totally on your control...
you need to use a mechanical sw to create pcb outline fitting your enclosure

The same for the 3) case, you can fix the file before importing inside 
kicad.


Please have a search for "ECAD MCAD Collaboration" for a deeper insight

___
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] Arc Adjustment proposal

[Dino Ghilardi]

On 11/07/19 12:26, easyw wrote:

On 07/11/2019 12:05 PM, Dino Ghilardi wrote:

My two cents...

Unfortunatly some times the centers are anchors of the board, other 
times they are not: when the external case is designed by a "fashon 
designer" and you have to put your electronics inside, the board 
outlines can be quite weird, not (totally) under our control and the 
centers of the board outline arcs are not always anchor points. The 
problem is that both the approaches make sense in some situations: 
sometimes you like an "exact" center, some others you like "exact" 
endpoints.


then your fashion design should use a proper CAD to design the board, 
and the EDGE should then imported inside KiCAD i.e. from a svg or a dxf 
file or handled directly with FreeCAD.




Yes, he should... but he won't: (he's not under my control).



There is a Snap option in KiCAD to make an end of a segment snapping to 
a selected end point.

You can do this by holding the Alt key while moved an end point.




Works well with segments, but when snapping to join two arcs it works 
only when moving one of the ending points (the other does not change the 
radius), so it becomes a little bit tricky.


Cheers,
Dino.

___
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] Arc Adjustment proposal

[easyw]

On 07/11/2019 12:05 PM, Dino Ghilardi wrote:

My two cents...

Unfortunatly some times the centers are anchors of the board, other 
times they are not: when the external case is designed by a "fashon 
designer" and you have to put your electronics inside, the board 
outlines can be quite weird, not (totally) under our control and the 
centers of the board outline arcs are not always anchor points. The 
problem is that both the approaches make sense in some situations: 
sometimes you like an "exact" center, some others you like "exact" 
endpoints.


then your fashion design should use a proper CAD to design the board, 
and the EDGE should then imported inside KiCAD i.e. from a svg or a dxf 
file or handled directly with FreeCAD.



Personnally I ran into the "endpoint" problem for some board edges, 
since to close the perimeter of the board for a step export, the arc 
start/endpoint need to be exact, while having an exact arc center was 
not so important (considering also the resolution used in kicad and the 
mechanical tolerances of the real word, an error of some nm in the 
center position should not be a problem).


There is a Snap option in KiCAD to make an end of a segment snapping to 
a selected end point.

You can do this by holding the Alt key while moved an end point.





___
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] Arc Adjustment proposal

[Dino Ghilardi]

On 07/10/2019 10:52 PM, Eeli Kaikkonen wrote:> For what it's worth, in 
normal graphical arcs (especially in edge cuts) the

two endpoints (or start and end) are usually important, the centerpoint
isn't.


This is not true. Generally for mechanical concerns, you should start 
exactly from the centers, which are the anchors of your board.
If you start your design with mechanical constraints in mind, your board 
will not have EdgeCuts issues.




My two cents...

Unfortunatly some times the centers are anchors of the board, other 
times they are not: when the external case is designed by a "fashon 
designer" and you have to put your electronics inside, the board 
outlines can be quite weird, not (totally) under our control and the 
centers of the board outline arcs are not always anchor points. The 
problem is that both the approaches make sense in some situations: 
sometimes you like an "exact" center, some others you like "exact" 
endpoints.


Personnally I ran into the "endpoint" problem for some board edges, 
since to close the perimeter of the board for a step export, the arc 
start/endpoint need to be exact, while having an exact arc center was 
not so important (considering also the resolution used in kicad and the 
mechanical tolerances of the real word, an error of some nm in the 
center position should not be a problem).


From a user point of view anything helps in having closed board 
outlines when using arbitrary arcs gets my +1 (no matter if this is a 
new internal arc data structure or a new "trim" tool to close two 
selected edges/arc).


Cheers, Dino.











___
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] Arc Adjustment proposal

[easyw]

On 07/10/2019 9:02 PM, Wayne Stambaugh wrote:

Don't forget, this will impact all import from and export to 3rd party
file formats so it's not going to be a trivial change.

Wayne


Then it could be introduced an extra way to define arcs only for tracks, 
leaving the previous definition unaltered for drawings and edges.

The pcb format would be changed only if used Arc tracks in the board.

On 07/10/2019 7:25 PM, Seth Hillbrand wrote:> I'd like to adjust how our 
arcs are handled and stored.  This is part of
the arc tracks work package but is sufficiently tangential that I think 
it bears checking before I implement.


Problem: Arcs are stored in the pcbnew file using center, start point 
and arc angle.  This leaves the end point of the arc subject to rounding 
errors.  This causes problems in STEP export as well as (for the arc 
tracks) connectivity issues as dragging requires point matching, not 
just copper overlap.


The issue on edge STEP export (board edge not closed) is related to the 
following:


On 07/10/2019 10:52 PM, Eeli Kaikkonen wrote:> For what it's worth, in 
normal graphical arcs (especially in edge cuts) the

two endpoints (or start and end) are usually important, the centerpoint
isn't.


This is not true. Generally for mechanical concerns, you should start 
exactly from the centers, which are the anchors of your board.
If you start your design with mechanical constraints in mind, your board 
will not have EdgeCuts issues.


___
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