[Kicad-developers] [PATCH] Handle STEP export properly on MacOS when launched from standalone pcbnew.

[Adam Wolf]

Hi folks!

This patch is meant to fix a crash Seth found when exporting STEP from
standalone pcbnew on macOS.

Thanks!  My apologies for having this so late in the cycle.  this is
going to be an amazing release for everyone, especially macOS users!

Adam Wolf


0001-Handle-STEP-export-properly-on-MacOS-when-launched-f.patch
Description: Binary data
___
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] Janitor needs a kick

[Seth Hillbrand]

I don't think it was my formatting but the last two patches to master seem
to have stuck the Janitor in a loop.

Anyone have time to reset it?

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] ngspice-28 for KiCad

[Holger Vogt]

Yes, Carsten started working on the debian packaging (see 
https://sourceforge.net/p/ngspice/mailman/message/36332769/)



Holger



Am 12.06.2018 um 21:46 schrieb José Ignacio:
That is great news! Is debian packaging underway for testing now that 
it is DFSG compliant?


On Tue, Jun 12, 2018 at 2:29 PM, Holger Vogt > wrote:


Dear developers,


ngspice-28 is available. Please check if this can be part of the
new KiCad release.


Major advances:

ngspice-28 reads device libs with PSPICE syntax (no more manual
tweaking of device vendors' device libraries)

All licenses involved are DFSG compatible (no more mixing of free
and unfree software in Debian etc.).

A power device model VDMOS is available

pkg-config is generated


I have made some successful tests with recent KiCad nightly on
Windows using the demos delivered by KiCad.


Holger


ngspice maintainer


___
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] The KiCad 5 Polish menu

[Marco Ciampa]

On Sun, Mar 11, 2018 at 09:25:47PM +0100, Krzysztof Kawa wrote:
> Good evening
> 
> Attached, I am sending files of the Polish menu to KiCad 5. The translation
> is now approximately 80% complete.
> 
> Regards
> Chris

Committed thanks, but next time do a git format-patch!

-- 


Marco Ciampa

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



 GNU/Linux User #78271
 FSFE fellow #364




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

Re: [Kicad-developers] ngspice-28 for KiCad

[Carsten Schoenert]

Hi,

Am 12.06.2018 um 21:46 schrieb José Ignacio:
> That is great news! Is debian packaging underway for testing now that it
> is DFSG compliant?

yes, for a long time already. :)
But now that ngspice upstream is completely DFSG compatible it's even
easier to do an update of the ngspice package and move this from
non-free to main.

Thanks again to Holger and all people which are involved to make this
happen!

Together with a friend of mine, which is also a Debian Developer, we did
some final hacking on the updated package of ngspice with some small
autopkgtest and did have found a small issue on the upstream package, at
least we think it is. :)
But nothing dramatically that would prevent further action.

So in short, I think I can do a initial upload of a updated package of
ngspice over the weekend. But then this will need to go through the
Debian NEW queue before it's usable in unstable or testing later.

-- 
Regards
Carsten Schoenert

___
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] ngspice-28 for KiCad

[José Ignacio]

That is great news! Is debian packaging underway for testing now that it is
DFSG compliant?

On Tue, Jun 12, 2018 at 2:29 PM, Holger Vogt  wrote:

> Dear developers,
>
>
> ngspice-28 is available. Please check if this can be part of the new KiCad
> release.
>
>
> Major advances:
>
> ngspice-28 reads device libs with PSPICE syntax (no more manual tweaking
> of device vendors' device libraries)
>
> All licenses involved are DFSG compatible (no more mixing of free and
> unfree software in Debian etc.).
>
> A power device model VDMOS is available
>
> pkg-config is generated
>
>
> I have made some successful tests with recent KiCad nightly on Windows
> using the demos delivered by KiCad.
>
>
> Holger
>
>
> ngspice maintainer
>
>
> ___
> 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] ngspice-28 for KiCad

[Holger Vogt]

Dear developers,


ngspice-28 is available. Please check if this can be part of the new 
KiCad release.



Major advances:

ngspice-28 reads device libs with PSPICE syntax (no more manual tweaking 
of device vendors' device libraries)


All licenses involved are DFSG compatible (no more mixing of free and 
unfree software in Debian etc.).


A power device model VDMOS is available

pkg-config is generated


I have made some successful tests with recent KiCad nightly on Windows 
using the demos delivered by KiCad.



Holger


ngspice maintainer


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

Re: [Kicad-developers] Stable release update.

[Tomasz Wlostowski]

On 12/06/18 16:18, John Beard wrote:
> Hi Wayne,
> 
> Great news!
> 
> I have one suggestion for a currently-un-milestoned bug that I'd (partly
> selfishly) really like to see fixed for v5:
> https://bugs.launchpad.net/kicad/+bug/1518694
> 
> This is the one where you can't shift posture when routing to a pad in
> the PNS router. It's certainly not a critical bug, and can be worked
> around by routing "backwards". However, if it's an easy fix (I'm trying
> to find it, but I don't know anything about the router code, so I have
> so far only managed to add a ton of trace and confuse myself), it would
> be shame IMO to leave it in for release. It's something that pretty much
> all users of the PNS router would run into almost as soon as they try to
> use it. If it's a harder fix or introduces unacceptably risky changes to
> the router, then it can wait.

Hi John,

I'll have a look at this.

Tom
> 
> Cheers,
> 
> John
> 
> On Tue, Jun 12, 2018 at 1:56 PM, Wayne Stambaugh  > wrote:
> 
> I apologize for being absent the last few days but I had out of town
> guests visiting and I didn't want to be rude and spend a lot of time in
> front of my computer.
> 
> Things seem to be coming along nicely for the v5 stable release and it
> appears that all of the critical bugs have been fixed.  Hopefully no new
> critical bugs will surface between now and release time and we can get
> some good testing on the critical bugs that were recently fixed.  I
> would *really* like to get the stable release out before I go on
> vacation during the week of July 4th.  Are there any known issues that
> anyone can think of that would prevent this from happening?  If so,
> please speak up.  If not, let's try to shoot for a June 29th release
> date.
> 
> Thank you to everyone for your hard work.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


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

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[Wayne Stambaugh]

On 6/12/2018 9:47 AM, Nick Østergaard wrote:
> I am not sure if this will slightly derail this patch's topic. Sorry if
> that is the case and tell me to back off.
> 
> There have been multiple attempts on getting the python API in better
> shape. Originally it was Ajo and some others with
> https://github.com/kicad/kicad-python
> 
> But the most recent work is on
> https://github.com/pointhi/kicad-python
> 
> Which is different from the initial work. I don't really know the state
> of that work.
> 
> I would like to see a supported API, but I guess this could be blocked
> slightly because of the wxpython phoenix story.

I think this will have to happen first given the current situation with
gtk2/3 build issues.  It would also be rather nice to be able to use
python 3.

> 
> 
> 
> 2018-06-12 15:34 GMT+02:00 John Beard  >:
> 
> Hi Nick and Wayne,
> 
> The patches as they are don't hook into the existing Python API
> doxygen stuff as it's not exactly the same as the Python API, it's a
> helper layer on top of that, and I was't sure if that would be OK.
> 
> I will take a look at adding it to the existing Python doc
> generation if that's an acceptable way to present it.
> 
> Cheers,
> 
> John
> 
> On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard  > wrote:
> 
> We already have doxygen generation for the python API, although
> people say that it is easier to read the C++ one. It is
> generated with the doxygen-python make target.
> See http://docs.kicad-pcb.org/doxygen-python/
> 
> 
> Does the additions in 0002 add to the normal python docs?
> 
> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh  >:
> 
> Hey John,
> 
> I like the idea of using doxygen to document the python
> plugins.  The
> current Doxyfile does not include .py files so that would
> need to
> change.  Before we do that, I would like to see a new
> section (maybe
> "Python Plugins") added to the documentation to separate the
> python
> plugin code from the c++ source documentation.  I can commit
> your patch
> as is and you can make the doxygen changes in a later patch
> or I can
> wait for you to create a new patch with all of the changes. 
> I'm fine
> either way.
> 
> Cheers,
> 
> Wayne
> 
> On 6/4/2018 7:33 AM, John Beard wrote:
> > Hi,
> >
> > Here is a simple patch sequence for the Python Footprint
> Wizard helpers:
> >
> > 1) Minor spelling and formatting tidy-up
> > 2) Add docstrings for the wizard base. As this is intended
> to be used
> > by writers of new plugins, having the functions documented
> is probably
> > a Good Idea (TM)
> > 3) Add rounded rectangle and chamfered rectangle helpers.
> Useful for
> > some footprints or even board outlines.
> >
> > I used Doxygen-style docstrings, but I haven't actually
> done anything
> > about building actual output docs with it. Any thoughts of
> if that
> > should be done, and if so, where to put it?
> >
> > There shouldn't be anything here that will break existing
> plugins, the
> > only API changes are additions.
> >
> > Cheers,
> >
> > John
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> 
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> 
> > More help   : https://help.launchpad.net/ListHelp
> 
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
>  

[Kicad-developers] Jenkins build is back to normal : linux-kicad-full-gcc-head #3552

[Miguel Angel Ajo]

See 



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

Re: [Kicad-developers] kicad doc build process

[Simon Richter]

Hi,

On 12.06.2018 16:54, Marco Ciampa wrote:

>> I guess that there are some new dependencies that needs to be installed as
>> of https://github.com/KiCad/kicad-doc/issues/588

> Every day it does not work I miss revisions from users...

FWIW, I have a working setup at

http://darine.hogyros.de:8080/job/any-kicad-doc-head/

This one just installs texlive-full, which is probably overkill but
contains everything that is needed to build CJK documents.

Copying that config back to the official server should be doable,
although I use a chroot to build docs.

   Simon



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

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

[Miguel Angel Ajo]

See 


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

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #3551

[Miguel Angel Ajo]

See 


Changes:

[Wayne Stambaugh] Minor Python scripting documentation fixes.

--
[...truncated 151.80 KB...]
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_edit_frame.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_libraries_utils.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_viewer_frame.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_no_connect.cpp.o
Scanning dependencies of target test_polygon_triangulation
[ 91%] Building CXX object 
qa/polygon_triangulation/CMakeFiles/test_polygon_triangulation.dir/__/common/mocks.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_plugin.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/globaleditpad.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/highlight.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_screen.cpp.o
[ 91%] Building CXX object 
qa/polygon_triangulation/CMakeFiles/test_polygon_triangulation.dir/__/__/common/base_units.cpp.o
Scanning dependencies of target test_polygon_generator
[ 91%] Building CXX object 
qa/polygon_generator/CMakeFiles/test_polygon_generator.dir/__/common/mocks.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/hotkeys.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_sheet.cpp.o
[ 91%] Building CXX object 
qa/polygon_triangulation/CMakeFiles/test_polygon_triangulation.dir/test_polygon_triangulation.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/hotkeys_board_editor.cpp.o
[ 91%] Building CXX object 
qa/polygon_generator/CMakeFiles/test_polygon_generator.dir/__/__/common/base_units.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_sheet_path.cpp.o
[ 91%] Linking CXX executable test_polygon_triangulation
[ 91%] Building CXX object 
qa/polygon_generator/CMakeFiles/test_polygon_generator.dir/test_polygon_generator.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/hotkeys_footprint_editor.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_sheet_pin.cpp.o
[ 91%] Linking CXX executable test_polygon_generator
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.o
[ 91%] Built target test_polygon_triangulation
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_text.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_validators.cpp.o
[ 92%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/schedit.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/layer_widget.cpp.o
Scanning dependencies of target cvpcb_kiface
[ 92%] Building CXX object cvpcb/CMakeFiles/cvpcb_kiface.dir/cvpcb.cpp.o
[ 92%] Built target test_polygon_generator
Scanning dependencies of target gerbview
[ 92%] Building CXX object 
gerbview/CMakeFiles/gerbview.dir/__/common/single_top.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/load_select_footprint.cpp.o
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/schematic_undo_redo.cpp.o
[ 92%] Building CXX object 
gerbview/CMakeFiles/gerbview.dir/__/common/pgm_base.cpp.o
[ 92%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/common/base_units.cpp.o
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_edit_frame.cpp.o
[ 92%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/board_items_to_polygon_shape_transform.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/magnetic_tracks_functions.cpp.o
[ 92%] Linking CXX executable gerbview
[ 92%] Built target gerbview
Scanning dependencies of target pl_editor
[ 92%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor.dir/__/common/single_top.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/menubar_footprint_editor.cpp.o
[ 92%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/pcb_general_settings.cpp.o
[ 92%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/selpart.cpp.o
[ 92%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor.dir/__/common/pgm_base.cpp.o
[ 92%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/drc_item.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/menubar_pcb_editor.cpp.o
[ 92%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/sheet.cpp.o
[ 92%] Linking CXX executable pl_editor
[ 92%] Built target pl_editor
Scanning dependencies of target pcb_calculator
[ 92%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator.dir/__/common/single_top.cpp.o
[ 92%] Building 

Re: [Kicad-developers] kicad doc build process

[Marco Ciampa]

On Tue, Jun 12, 2018 at 10:31:55AM +0200, Nick Østergaard wrote:
> tir. 12. jun. 2018 09.28 skrev Marco Ciampa :
> 
> > Hi folks,
> > I would like to know better the organization of the build process
> > (Continuous Integration) for the doc files.
> >
> > What I would like to know precisely is:
> >
> > - who is in charge to run the machines that build the docs
> >
> 
> Ajo, but I primarely maintain it.
> 
> - what is the frequency of the build process
> 
> Every commit
> 
> - where I can find the links to these machines (in the site)
> 
> You browse Jenkins at ci.kicad-pcb.org
> 
> The specific job is at http://ci.kicad-pcb.org/job/any-kicad-doc-head/
> 
> It has been failing since
> https://github.com/KiCad/kicad-doc/commit/f7e9226902156d79459ad63b1a9a393a3b5da829
> 
> I guess that there are some new dependencies that needs to be installed as
> of https://github.com/KiCad/kicad-doc/issues/588

Ok will someone please make this working again?

Every day it does not work I miss revisions from users...

I can help if someone explains me how to or give me access to the system...

TIA

--


Marco Ciampa

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



 GNU/Linux User #78271
 FSFE fellow #364




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

Re: [Kicad-developers] Stable release update.

[Steven A. Falco]

@lkundrak, the Fedora KiCad package admin, should pick up my -rc2 changes very 
soon - they will go into Fedora Rawhide.

So we should be well positioned for a stable release to appear there soon after 
everything is tagged for the official 5.0.0 release.

Steve

On 06/12/2018 10:18 AM, John Beard wrote:
> Hi Wayne,
> 
> Great news!
> 
> I have one suggestion for a currently-un-milestoned bug that I'd (partly 
> selfishly) really like to see fixed for v5: 
> https://bugs.launchpad.net/kicad/+bug/1518694
> 
> This is the one where you can't shift posture when routing to a pad in the 
> PNS router. It's certainly not a critical bug, and can be worked around by 
> routing "backwards". However, if it's an easy fix (I'm trying to find it, but 
> I don't know anything about the router code, so I have so far only managed to 
> add a ton of trace and confuse myself), it would be shame IMO to leave it in 
> for release. It's something that pretty much all users of the PNS router 
> would run into almost as soon as they try to use it. If it's a harder fix or 
> introduces unacceptably risky changes to the router, then it can wait.
> 
> Cheers,
> 
> John
> 
> On Tue, Jun 12, 2018 at 1:56 PM, Wayne Stambaugh  > wrote:
> 
> I apologize for being absent the last few days but I had out of town
> guests visiting and I didn't want to be rude and spend a lot of time in
> front of my computer.
> 
> Things seem to be coming along nicely for the v5 stable release and it
> appears that all of the critical bugs have been fixed.  Hopefully no new
> critical bugs will surface between now and release time and we can get
> some good testing on the critical bugs that were recently fixed.  I
> would *really* like to get the stable release out before I go on
> vacation during the week of July 4th.  Are there any known issues that
> anyone can think of that would prevent this from happening?  If so,
> please speak up.  If not, let's try to shoot for a June 29th release date.
> 
> Thank you to everyone for your hard work.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to     : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


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

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[Wayne Stambaugh]

Hi Thomas,

I would like to see KiCad finally have a high level Python api as part
of v6.  It's something that has been long over due.  If anyone wants to
help Thomas out, the help would be appreciated.  I would prefer that the
development discussion for this stay on this mailing list for the sake
of convenience.  I would also like to avoid a long drawn out discussion
about this until after v5 is released.

Cheers,

Wayne

On 6/12/2018 10:18 AM, Thomas Pointhuber wrote:
> Hi
> 
> As Nick already mentioned, I did one of the last attempts of a
> high-level abstraction. The goal would be to have this as proposal for
> an official API in the KiCad 6 release (and I will likely carry on with
> the work on July).
> 
> My goal would be to have a "pythonic" and natural to use API, which
> means to not represent the internal data structures in a 1:1 fashion.
> This therefore requires me to combine/split kicad objects into python
> object of different structure, but I think I already did some good
> examples how that could work out.
> 
> I am happy to get any input for the current solution and ideas for
> further improvements.
> 
> Regards, Thomas
> 
> Am 2018-06-12 um 15:47 schrieb Nick Østergaard:
>> I am not sure if this will slightly derail this patch's topic. Sorry if
>> that is the case and tell me to back off.
>>
>> There have been multiple attempts on getting the python API in better
>> shape. Originally it was Ajo and some others with
>> https://github.com/kicad/kicad-python
>>
>> But the most recent work is on
>> https://github.com/pointhi/kicad-python
>>
>> Which is different from the initial work. I don't really know the state
>> of that work.
>>
>> I would like to see a supported API, but I guess this could be blocked
>> slightly because of the wxpython phoenix story.
>>
>>
>>
>> 2018-06-12 15:34 GMT+02:00 John Beard > >:
>>
>> Hi Nick and Wayne,
>>
>> The patches as they are don't hook into the existing Python API
>> doxygen stuff as it's not exactly the same as the Python API, it's a
>> helper layer on top of that, and I was't sure if that would be OK.
>>
>> I will take a look at adding it to the existing Python doc
>> generation if that's an acceptable way to present it.
>>
>> Cheers,
>>
>> John
>>
>> On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard > > wrote:
>>
>> We already have doxygen generation for the python API, although
>> people say that it is easier to read the C++ one. It is
>> generated with the doxygen-python make target.
>> See http://docs.kicad-pcb.org/doxygen-python/
>> 
>>
>> Does the additions in 0002 add to the normal python docs?
>>
>> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh > >:
>>
>> Hey John,
>>
>> I like the idea of using doxygen to document the python
>> plugins.  The
>> current Doxyfile does not include .py files so that would
>> need to
>> change.  Before we do that, I would like to see a new
>> section (maybe
>> "Python Plugins") added to the documentation to separate the
>> python
>> plugin code from the c++ source documentation.  I can commit
>> your patch
>> as is and you can make the doxygen changes in a later patch
>> or I can
>> wait for you to create a new patch with all of the changes. 
>> I'm fine
>> either way.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 6/4/2018 7:33 AM, John Beard wrote:
>> > Hi,
>> >
>> > Here is a simple patch sequence for the Python Footprint
>> Wizard helpers:
>> >
>> > 1) Minor spelling and formatting tidy-up
>> > 2) Add docstrings for the wizard base. As this is intended
>> to be used
>> > by writers of new plugins, having the functions documented
>> is probably
>> > a Good Idea (TM)
>> > 3) Add rounded rectangle and chamfered rectangle helpers.
>> Useful for
>> > some footprints or even board outlines.
>> >
>> > I used Doxygen-style docstrings, but I haven't actually
>> done anything
>> > about building actual output docs with it. Any thoughts of
>> if that
>> > should be done, and if so, where to put it?
>> >
>> > There shouldn't be anything here that will break existing
>> plugins, the
>> > only API changes are additions.
>> >
>> > Cheers,
>> >
>> > John
>> >
>> >
>> >
>> > 

Re: [Kicad-developers] Stable release update.

[Wayne Stambaugh]

On 6/12/2018 10:18 AM, John Beard wrote:
> Hi Wayne,
> 
> Great news!
> 
> I have one suggestion for a currently-un-milestoned bug that I'd (partly
> selfishly) really like to see fixed for v5:
> https://bugs.launchpad.net/kicad/+bug/1518694
> 
> This is the one where you can't shift posture when routing to a pad in
> the PNS router. It's certainly not a critical bug, and can be worked
> around by routing "backwards". However, if it's an easy fix (I'm trying
> to find it, but I don't know anything about the router code, so I have
> so far only managed to add a ton of trace and confuse myself), it would
> be shame IMO to leave it in for release. It's something that pretty much
> all users of the PNS router would run into almost as soon as they try to
> use it. If it's a harder fix or introduces unacceptably risky changes to
> the router, then it can wait.

I'm not opposed to this as long as the risk of adding new bugs to the
P router is low.  If not, I would rather wait until the first v5 point
release.  @Tom or @Orson, do you have any input on this?

> 
> Cheers,
> 
> John
> 
> On Tue, Jun 12, 2018 at 1:56 PM, Wayne Stambaugh  > wrote:
> 
> I apologize for being absent the last few days but I had out of town
> guests visiting and I didn't want to be rude and spend a lot of time in
> front of my computer.
> 
> Things seem to be coming along nicely for the v5 stable release and it
> appears that all of the critical bugs have been fixed.  Hopefully no new
> critical bugs will surface between now and release time and we can get
> some good testing on the critical bugs that were recently fixed.  I
> would *really* like to get the stable release out before I go on
> vacation during the week of July 4th.  Are there any known issues that
> anyone can think of that would prevent this from happening?  If so,
> please speak up.  If not, let's try to shoot for a June 29th release
> date.
> 
> Thank you to everyone for your hard work.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 

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

[Kicad-developers] Build failed in Jenkins: kicad-qa #4256

[Miguel Angel Ajo]

See 

Changes:

[Wayne Stambaugh] Minor Python scripting documentation fixes.

--
Started by an SCM change
Building remotely on debian8 (clang gcc linux) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://github.com/KiCad/kicad-source-mirror.git # timeout=10
Fetching upstream changes from https://github.com/KiCad/kicad-source-mirror.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/KiCad/kicad-source-mirror.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision ade3c2b12921a01360c75ad7e5a77371ae6d4f0e 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f ade3c2b12921a01360c75ad7e5a77371ae6d4f0e
Commit message: "Minor Python scripting documentation fixes."
 > git rev-list --no-walk 660aed71b4e21c7e3052c665accf1d36ad612a13 # timeout=10
[kicad-qa] $ /bin/sh -xe /tmp/jenkins1165005224288930315.sh
+ cmake --version
cmake version 3.0.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
+ gcc --version
gcc (Debian 4.9.2-10+deb8u1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ git --version
git version 2.1.4
+ OPTS= -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
+ [ -d passed-qa ]
+ [ -d build ]
+ cd build
+ /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
-- Kicad install dir: 
-- Check for installed GLEW -- found
-- Boost version: 1.55.0
-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/dist-packages
-- wxPython version 3.0 found.
-- S3DSG version: 2.0.0
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Configuring done
-- Generating done
-- Build files have been written to: 

+ echo CMAKE exit code is 0
CMAKE exit code is 0
+ rm -f pcbnew/pcbnewPYTHON_wrap.cxx
+ env
+ grep -q ^MAKEJOBS=
+ echo The MAKEJOBS variable is empty
The MAKEJOBS variable is empty
+ JOBS=4
+ make -j4 pcbnew_python_module
[  1%] Built target pcb_plot_lexer_source_files
[  1%] [  1%] Built target lib_table_lexer_source_files
Built target pcb_lexer_source_files
[  1%] Built target netlist_lexer_source_files
[  1%] Built target idf3
[  1%] [  1%] Built target page_layout_lexer_source_files
Generating version string header
-- Using Git to determine build version string.
-- Found Git: /usr/bin/git (found version "2.1.4") 
[  4%] Built target gal
[  7%] Built target kicad_3dsg
-- Writing 
 file with 
version: (5.0.0-rc2-127-gade3c2b)
[  7%] [  7%] Built target lib_dxf
Built target version_header
[  7%] Built target polygon
[ 49%] Built target bitmaps
[ 49%] Built target specctra_lexer_source_files
[ 53%] Built target pcbcommon
[ 54%] Built target pcad2kicadpcb
[ 60%] Built target 3d-viewer
Scanning dependencies of target common
[ 61%] Building CXX object common/CMakeFiles/common.dir/build_version.cpp.o
[ 83%] Built target pcbnew_kiface_objects
Linking CXX static library libcommon.a
[ 97%] Built target common
[ 97%] Built target github_plugin
[100%] Built target pnsrouter
Linking CXX shared module _pcbnew.kiface
[100%] Built target pcbnew_kiface
[100%] Creating python's pcbnew native module _pcbnew.so for command line use.
[100%] Built target pcbnew_python_module
+ pwd
+ export PYTHONPATH=
+ cd ../qa
+ /usr/bin/python2 test.py
test_pcb_bounding_box (test_002_board_class.TestBoardClass) ... FAIL
test_pcb_find_module (test_002_board_class.TestBoardClass) ... ok
test_pcb_get_pad (test_002_board_class.TestBoardClass) ... ok
test_pcb_get_track_count (test_002_board_class.TestBoardClass) ... ok
test_pcb_layer_id_get (test_002_board_class.TestBoardClass) ... ok
test_pcb_layer_name_set_get (test_002_board_class.TestBoardClass) ... ok
test_pcb_save_and_load (test_002_board_class.TestBoardClass) ... ok
test_pcb_load (test_001_pcb_load.TestPCBLoad) ... ok
test_pcb_module_references (test_001_pcb_load.TestPCBLoad) ... ok
test_pcb_modules (test_001_pcb_load.TestPCBLoad) ... ok

Re: [Kicad-developers] Stable release update.

[John Beard]

Hi Wayne,

Great news!

I have one suggestion for a currently-un-milestoned bug that I'd (partly
selfishly) really like to see fixed for v5:
https://bugs.launchpad.net/kicad/+bug/1518694

This is the one where you can't shift posture when routing to a pad in the
PNS router. It's certainly not a critical bug, and can be worked around by
routing "backwards". However, if it's an easy fix (I'm trying to find it,
but I don't know anything about the router code, so I have so far only
managed to add a ton of trace and confuse myself), it would be shame IMO to
leave it in for release. It's something that pretty much all users of the
PNS router would run into almost as soon as they try to use it. If it's a
harder fix or introduces unacceptably risky changes to the router, then it
can wait.

Cheers,

John

On Tue, Jun 12, 2018 at 1:56 PM, Wayne Stambaugh 
wrote:

> I apologize for being absent the last few days but I had out of town
> guests visiting and I didn't want to be rude and spend a lot of time in
> front of my computer.
>
> Things seem to be coming along nicely for the v5 stable release and it
> appears that all of the critical bugs have been fixed.  Hopefully no new
> critical bugs will surface between now and release time and we can get
> some good testing on the critical bugs that were recently fixed.  I
> would *really* like to get the stable release out before I go on
> vacation during the week of July 4th.  Are there any known issues that
> anyone can think of that would prevent this from happening?  If so,
> please speak up.  If not, let's try to shoot for a June 29th release date.
>
> Thank you to everyone for your hard work.
>
> Cheers,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[Thomas Pointhuber]

Hi

As Nick already mentioned, I did one of the last attempts of a
high-level abstraction. The goal would be to have this as proposal for
an official API in the KiCad 6 release (and I will likely carry on with
the work on July).

My goal would be to have a "pythonic" and natural to use API, which
means to not represent the internal data structures in a 1:1 fashion.
This therefore requires me to combine/split kicad objects into python
object of different structure, but I think I already did some good
examples how that could work out.

I am happy to get any input for the current solution and ideas for
further improvements.

Regards, Thomas

Am 2018-06-12 um 15:47 schrieb Nick Østergaard:
> I am not sure if this will slightly derail this patch's topic. Sorry if
> that is the case and tell me to back off.
> 
> There have been multiple attempts on getting the python API in better
> shape. Originally it was Ajo and some others with
> https://github.com/kicad/kicad-python
> 
> But the most recent work is on
> https://github.com/pointhi/kicad-python
> 
> Which is different from the initial work. I don't really know the state
> of that work.
> 
> I would like to see a supported API, but I guess this could be blocked
> slightly because of the wxpython phoenix story.
> 
> 
> 
> 2018-06-12 15:34 GMT+02:00 John Beard  >:
> 
> Hi Nick and Wayne,
> 
> The patches as they are don't hook into the existing Python API
> doxygen stuff as it's not exactly the same as the Python API, it's a
> helper layer on top of that, and I was't sure if that would be OK.
> 
> I will take a look at adding it to the existing Python doc
> generation if that's an acceptable way to present it.
> 
> Cheers,
> 
> John
> 
> On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard  > wrote:
> 
> We already have doxygen generation for the python API, although
> people say that it is easier to read the C++ one. It is
> generated with the doxygen-python make target.
> See http://docs.kicad-pcb.org/doxygen-python/
> 
> 
> Does the additions in 0002 add to the normal python docs?
> 
> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh  >:
> 
> Hey John,
> 
> I like the idea of using doxygen to document the python
> plugins.  The
> current Doxyfile does not include .py files so that would
> need to
> change.  Before we do that, I would like to see a new
> section (maybe
> "Python Plugins") added to the documentation to separate the
> python
> plugin code from the c++ source documentation.  I can commit
> your patch
> as is and you can make the doxygen changes in a later patch
> or I can
> wait for you to create a new patch with all of the changes. 
> I'm fine
> either way.
> 
> Cheers,
> 
> Wayne
> 
> On 6/4/2018 7:33 AM, John Beard wrote:
> > Hi,
> >
> > Here is a simple patch sequence for the Python Footprint
> Wizard helpers:
> >
> > 1) Minor spelling and formatting tidy-up
> > 2) Add docstrings for the wizard base. As this is intended
> to be used
> > by writers of new plugins, having the functions documented
> is probably
> > a Good Idea (TM)
> > 3) Add rounded rectangle and chamfered rectangle helpers.
> Useful for
> > some footprints or even board outlines.
> >
> > I used Doxygen-style docstrings, but I haven't actually
> done anything
> > about building actual output docs with it. Any thoughts of
> if that
> > should be done, and if so, where to put it?
> >
> > There shouldn't be anything here that will break existing
> plugins, the
> > only API changes are additions.
> >
> > Cheers,
> >
> > John
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> 
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> 
> > More help   : https://help.launchpad.net/ListHelp
> 
> >
> 
> ___
>   

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[Nick Østergaard]

Hi John,

Ok, thank your for your clarification. For the record, I am not opposing
the change, but would just mention it looks strange to add it to the
doxygen-docs target when we have the doxygen-python target.

Nick

2018-06-12 16:11 GMT+02:00 John Beard :

> Hi Nick,
>
> It's a related concept, certainly. The drawing helper stuff acts as a
> "buffer" between the Pcbnew API and the plugin writer, but this isn't
> really a design aim, it's just a side effect. It certainly does not totally
> insulate the writer from the Pcbnew API as it's a very limited subset of
> functionality. Thus the user is still vulnerable to Pcbnew internal API
> changes (and as Python is not a compiled language, they won't find out
> until it all explodes at runtime!). It's better than calling on the Pcbnew
> API directly (as there's only one place of breakage), but it's not a
> panacea, and was never really designed to be.
>
> However, these helpers also add some stuff that isn't just an API
> translation layer, it adds stuff like a transform stack and helpers for
> shapes like boxes and so on that would otherwise be repetitive in plugin
> code. All this can (and should) be transplanted onto a new "stable" Python
> interface in future.
>
> Cheers,
>
> John
>
> On Tue, Jun 12, 2018 at 2:47 PM, Nick Østergaard 
> wrote:
>
>> I am not sure if this will slightly derail this patch's topic. Sorry if
>> that is the case and tell me to back off.
>>
>> There have been multiple attempts on getting the python API in better
>> shape. Originally it was Ajo and some others with
>> https://github.com/kicad/kicad-python
>>
>> But the most recent work is on
>> https://github.com/pointhi/kicad-python
>>
>> Which is different from the initial work. I don't really know the state
>> of that work.
>>
>> I would like to see a supported API, but I guess this could be blocked
>> slightly because of the wxpython phoenix story.
>>
>>
>>
>> 2018-06-12 15:34 GMT+02:00 John Beard :
>>
>>> Hi Nick and Wayne,
>>>
>>> The patches as they are don't hook into the existing Python API doxygen
>>> stuff as it's not exactly the same as the Python API, it's a helper layer
>>> on top of that, and I was't sure if that would be OK.
>>>
>>> I will take a look at adding it to the existing Python doc generation if
>>> that's an acceptable way to present it.
>>>
>>> Cheers,
>>>
>>> John
>>>
>>> On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard 
>>> wrote:
>>>
 We already have doxygen generation for the python API, although people
 say that it is easier to read the C++ one. It is generated with
 the doxygen-python make target. See http://docs.kicad-pcb.org/
 doxygen-python/

 Does the additions in 0002 add to the normal python docs?

 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh :

> Hey John,
>
> I like the idea of using doxygen to document the python plugins.  The
> current Doxyfile does not include .py files so that would need to
> change.  Before we do that, I would like to see a new section (maybe
> "Python Plugins") added to the documentation to separate the python
> plugin code from the c++ source documentation.  I can commit your patch
> as is and you can make the doxygen changes in a later patch or I can
> wait for you to create a new patch with all of the changes.  I'm fine
> either way.
>
> Cheers,
>
> Wayne
>
> On 6/4/2018 7:33 AM, John Beard wrote:
> > Hi,
> >
> > Here is a simple patch sequence for the Python Footprint Wizard
> helpers:
> >
> > 1) Minor spelling and formatting tidy-up
> > 2) Add docstrings for the wizard base. As this is intended to be used
> > by writers of new plugins, having the functions documented is
> probably
> > a Good Idea (TM)
> > 3) Add rounded rectangle and chamfered rectangle helpers. Useful for
> > some footprints or even board outlines.
> >
> > I used Doxygen-style docstrings, but I haven't actually done anything
> > about building actual output docs with it. Any thoughts of if that
> > should be done, and if so, where to put it?
> >
> > There shouldn't be anything here that will break existing plugins,
> the
> > only API changes are additions.
> >
> > Cheers,
> >
> > John
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


 

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[John Beard]

Hi Nick,

It's a related concept, certainly. The drawing helper stuff acts as a
"buffer" between the Pcbnew API and the plugin writer, but this isn't
really a design aim, it's just a side effect. It certainly does not totally
insulate the writer from the Pcbnew API as it's a very limited subset of
functionality. Thus the user is still vulnerable to Pcbnew internal API
changes (and as Python is not a compiled language, they won't find out
until it all explodes at runtime!). It's better than calling on the Pcbnew
API directly (as there's only one place of breakage), but it's not a
panacea, and was never really designed to be.

However, these helpers also add some stuff that isn't just an API
translation layer, it adds stuff like a transform stack and helpers for
shapes like boxes and so on that would otherwise be repetitive in plugin
code. All this can (and should) be transplanted onto a new "stable" Python
interface in future.

Cheers,

John

On Tue, Jun 12, 2018 at 2:47 PM, Nick Østergaard  wrote:

> I am not sure if this will slightly derail this patch's topic. Sorry if
> that is the case and tell me to back off.
>
> There have been multiple attempts on getting the python API in better
> shape. Originally it was Ajo and some others with
> https://github.com/kicad/kicad-python
>
> But the most recent work is on
> https://github.com/pointhi/kicad-python
>
> Which is different from the initial work. I don't really know the state of
> that work.
>
> I would like to see a supported API, but I guess this could be blocked
> slightly because of the wxpython phoenix story.
>
>
>
> 2018-06-12 15:34 GMT+02:00 John Beard :
>
>> Hi Nick and Wayne,
>>
>> The patches as they are don't hook into the existing Python API doxygen
>> stuff as it's not exactly the same as the Python API, it's a helper layer
>> on top of that, and I was't sure if that would be OK.
>>
>> I will take a look at adding it to the existing Python doc generation if
>> that's an acceptable way to present it.
>>
>> Cheers,
>>
>> John
>>
>> On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard 
>> wrote:
>>
>>> We already have doxygen generation for the python API, although people
>>> say that it is easier to read the C++ one. It is generated with
>>> the doxygen-python make target. See http://docs.kicad-pcb.org/
>>> doxygen-python/
>>>
>>> Does the additions in 0002 add to the normal python docs?
>>>
>>> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh :
>>>
 Hey John,

 I like the idea of using doxygen to document the python plugins.  The
 current Doxyfile does not include .py files so that would need to
 change.  Before we do that, I would like to see a new section (maybe
 "Python Plugins") added to the documentation to separate the python
 plugin code from the c++ source documentation.  I can commit your patch
 as is and you can make the doxygen changes in a later patch or I can
 wait for you to create a new patch with all of the changes.  I'm fine
 either way.

 Cheers,

 Wayne

 On 6/4/2018 7:33 AM, John Beard wrote:
 > Hi,
 >
 > Here is a simple patch sequence for the Python Footprint Wizard
 helpers:
 >
 > 1) Minor spelling and formatting tidy-up
 > 2) Add docstrings for the wizard base. As this is intended to be used
 > by writers of new plugins, having the functions documented is probably
 > a Good Idea (TM)
 > 3) Add rounded rectangle and chamfered rectangle helpers. Useful for
 > some footprints or even board outlines.
 >
 > I used Doxygen-style docstrings, but I haven't actually done anything
 > about building actual output docs with it. Any thoughts of if that
 > should be done, and if so, where to put it?
 >
 > There shouldn't be anything here that will break existing plugins, the
 > only API changes are additions.
 >
 > Cheers,
 >
 > John
 >
 >
 >
 > ___
 > Mailing list: https://launchpad.net/~kicad-developers
 > Post to : kicad-developers@lists.launchpad.net
 > Unsubscribe : https://launchpad.net/~kicad-developers
 > More help   : https://help.launchpad.net/ListHelp
 >

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

>>>
>>>
>>> ___
>>> 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 : 

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[Wayne Stambaugh]

On 6/12/2018 9:34 AM, John Beard wrote:
> Hi Nick and Wayne,
> 
> The patches as they are don't hook into the existing Python API doxygen
> stuff as it's not exactly the same as the Python API, it's a helper
> layer on top of that, and I was't sure if that would be OK.
> 
> I will take a look at adding it to the existing Python doc generation if
> that's an acceptable way to present it.

This makes more sense to me than adding it to the c++ source documentation.

> 
> Cheers,
> 
> John
> 
> On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard  > wrote:
> 
> We already have doxygen generation for the python API, although
> people say that it is easier to read the C++ one. It is generated
> with the doxygen-python make target.
> See http://docs.kicad-pcb.org/doxygen-python/
> 
> 
> Does the additions in 0002 add to the normal python docs?
> 
> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh  >:
> 
> Hey John,
> 
> I like the idea of using doxygen to document the python
> plugins.  The
> current Doxyfile does not include .py files so that would need to
> change.  Before we do that, I would like to see a new section (maybe
> "Python Plugins") added to the documentation to separate the python
> plugin code from the c++ source documentation.  I can commit
> your patch
> as is and you can make the doxygen changes in a later patch or I can
> wait for you to create a new patch with all of the changes.  I'm
> fine
> either way.
> 
> Cheers,
> 
> Wayne
> 
> On 6/4/2018 7:33 AM, John Beard wrote:
> > Hi,
> >
> > Here is a simple patch sequence for the Python Footprint
> Wizard helpers:
> >
> > 1) Minor spelling and formatting tidy-up
> > 2) Add docstrings for the wizard base. As this is intended to
> be used
> > by writers of new plugins, having the functions documented is
> probably
> > a Good Idea (TM)
> > 3) Add rounded rectangle and chamfered rectangle helpers.
> Useful for
> > some footprints or even board outlines.
> >
> > I used Doxygen-style docstrings, but I haven't actually done
> anything
> > about building actual output docs with it. Any thoughts of if that
> > should be done, and if so, where to put it?
> >
> > There shouldn't be anything here that will break existing
> plugins, the
> > only API changes are additions.
> >
> > Cheers,
> >
> > John
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> 
> > Post to     : kicad-developers@lists.launchpad.net
> 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> 
> > More help   : https://help.launchpad.net/ListHelp
> 
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 

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

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #3550

[Miguel Angel Ajo]

See 


Changes:

[jeff] Make sure initially loaded footprint is rendered.

--
[...truncated 151.00 KB...]
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/exporters/export_idf.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/exporters/export_vrml.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_bitmap.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_bus_entry.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/exporters/gen_drill_report_files.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_collectors.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_component.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/exporters/gen_footprints_placefile.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/exporters/gendrill_Excellon_writer.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_eagle_plugin.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_field.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/exporters/gendrill_file_writer_base.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/exporters/gendrill_gerber_writer.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_io_mgr.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/exporters/gerber_jobfile_writer.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_item_struct.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_dxf/dialog_dxf_import.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_junction.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_legacy_plugin.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_dxf/dialog_dxf_import_base.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/import_dxf/dxf2brd_items.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_line.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/autorouter/rect_placement/rect_placement.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/autorouter/spread_footprints.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/action_plugin.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_marker.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_no_connect.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/append_board_to_current.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/array_creator.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_plugin.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_screen.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_sheet.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/attribut.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/block.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_sheet_path.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_sheet_pin.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/block_footprint_editor.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/board_netlist_updater.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_text.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_validators.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/build_BOM_from_board.cpp.o
[ 91%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/schedit.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/connect.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/schematic_undo_redo.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/controle.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_edit_frame.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/cross-probing.cpp.o
[ 91%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/selpart.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/deltrack.cpp.o
[ 91%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/sheet.cpp.o
[ 91%] Building CXX object 

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[Nick Østergaard]

I am not sure if this will slightly derail this patch's topic. Sorry if
that is the case and tell me to back off.

There have been multiple attempts on getting the python API in better
shape. Originally it was Ajo and some others with
https://github.com/kicad/kicad-python

But the most recent work is on
https://github.com/pointhi/kicad-python

Which is different from the initial work. I don't really know the state of
that work.

I would like to see a supported API, but I guess this could be blocked
slightly because of the wxpython phoenix story.



2018-06-12 15:34 GMT+02:00 John Beard :

> Hi Nick and Wayne,
>
> The patches as they are don't hook into the existing Python API doxygen
> stuff as it's not exactly the same as the Python API, it's a helper layer
> on top of that, and I was't sure if that would be OK.
>
> I will take a look at adding it to the existing Python doc generation if
> that's an acceptable way to present it.
>
> Cheers,
>
> John
>
> On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard 
> wrote:
>
>> We already have doxygen generation for the python API, although people
>> say that it is easier to read the C++ one. It is generated with
>> the doxygen-python make target. See http://docs.kicad-pcb.org/
>> doxygen-python/
>>
>> Does the additions in 0002 add to the normal python docs?
>>
>> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh :
>>
>>> Hey John,
>>>
>>> I like the idea of using doxygen to document the python plugins.  The
>>> current Doxyfile does not include .py files so that would need to
>>> change.  Before we do that, I would like to see a new section (maybe
>>> "Python Plugins") added to the documentation to separate the python
>>> plugin code from the c++ source documentation.  I can commit your patch
>>> as is and you can make the doxygen changes in a later patch or I can
>>> wait for you to create a new patch with all of the changes.  I'm fine
>>> either way.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> On 6/4/2018 7:33 AM, John Beard wrote:
>>> > Hi,
>>> >
>>> > Here is a simple patch sequence for the Python Footprint Wizard
>>> helpers:
>>> >
>>> > 1) Minor spelling and formatting tidy-up
>>> > 2) Add docstrings for the wizard base. As this is intended to be used
>>> > by writers of new plugins, having the functions documented is probably
>>> > a Good Idea (TM)
>>> > 3) Add rounded rectangle and chamfered rectangle helpers. Useful for
>>> > some footprints or even board outlines.
>>> >
>>> > I used Doxygen-style docstrings, but I haven't actually done anything
>>> > about building actual output docs with it. Any thoughts of if that
>>> > should be done, and if so, where to put it?
>>> >
>>> > There shouldn't be anything here that will break existing plugins, the
>>> > only API changes are additions.
>>> >
>>> > Cheers,
>>> >
>>> > John
>>> >
>>> >
>>> >
>>> > ___
>>> > Mailing list: https://launchpad.net/~kicad-developers
>>> > Post to : kicad-developers@lists.launchpad.net
>>> > Unsubscribe : https://launchpad.net/~kicad-developers
>>> > More help   : https://help.launchpad.net/ListHelp
>>> >
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Stable release update.

[Adam Wolf]

I should be able to get the Mac packaging release-candidate ready by
the middle of next week, which gives us more than a week of testing of
that version.  I already have folks testing on it now.

Adam
On Tue, Jun 12, 2018 at 7:57 AM Wayne Stambaugh  wrote:
>
> I apologize for being absent the last few days but I had out of town
> guests visiting and I didn't want to be rude and spend a lot of time in
> front of my computer.
>
> Things seem to be coming along nicely for the v5 stable release and it
> appears that all of the critical bugs have been fixed.  Hopefully no new
> critical bugs will surface between now and release time and we can get
> some good testing on the critical bugs that were recently fixed.  I
> would *really* like to get the stable release out before I go on
> vacation during the week of July 4th.  Are there any known issues that
> anyone can think of that would prevent this from happening?  If so,
> please speak up.  If not, let's try to shoot for a June 29th release date.
>
> Thank you to everyone for your hard work.
>
> Cheers,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[John Beard]

Hi Nick and Wayne,

The patches as they are don't hook into the existing Python API doxygen
stuff as it's not exactly the same as the Python API, it's a helper layer
on top of that, and I was't sure if that would be OK.

I will take a look at adding it to the existing Python doc generation if
that's an acceptable way to present it.

Cheers,

John

On Tue, Jun 12, 2018 at 2:11 PM, Nick Østergaard  wrote:

> We already have doxygen generation for the python API, although people say
> that it is easier to read the C++ one. It is generated with
> the doxygen-python make target. See http://docs.kicad-pcb.org/
> doxygen-python/
>
> Does the additions in 0002 add to the normal python docs?
>
> 2018-06-12 15:07 GMT+02:00 Wayne Stambaugh :
>
>> Hey John,
>>
>> I like the idea of using doxygen to document the python plugins.  The
>> current Doxyfile does not include .py files so that would need to
>> change.  Before we do that, I would like to see a new section (maybe
>> "Python Plugins") added to the documentation to separate the python
>> plugin code from the c++ source documentation.  I can commit your patch
>> as is and you can make the doxygen changes in a later patch or I can
>> wait for you to create a new patch with all of the changes.  I'm fine
>> either way.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 6/4/2018 7:33 AM, John Beard wrote:
>> > Hi,
>> >
>> > Here is a simple patch sequence for the Python Footprint Wizard helpers:
>> >
>> > 1) Minor spelling and formatting tidy-up
>> > 2) Add docstrings for the wizard base. As this is intended to be used
>> > by writers of new plugins, having the functions documented is probably
>> > a Good Idea (TM)
>> > 3) Add rounded rectangle and chamfered rectangle helpers. Useful for
>> > some footprints or even board outlines.
>> >
>> > I used Doxygen-style docstrings, but I haven't actually done anything
>> > about building actual output docs with it. Any thoughts of if that
>> > should be done, and if so, where to put it?
>> >
>> > There shouldn't be anything here that will break existing plugins, the
>> > only API changes are additions.
>> >
>> > Cheers,
>> >
>> > John
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> ___
> 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] Untranslated strings

[Marco Ciampa]

On Tue, Jun 12, 2018 at 08:43:53AM -0400, Wayne Stambaugh wrote:
> Hey Carsten,
> 
> On 6/12/2018 8:28 AM, Carsten Schoenert wrote:
> > Hello Wayne,
> > 
> > Am 12.06.2018 um 14:07 schrieb Wayne Stambaugh:
> >> I'm thinking we should probably wait until after v5 and back port the
> >> fix to the v5 branch but the string example you noted should definitely
> >> be translated.  I don't know how much grief this would cause our
> >> translators this late in the game.  Would any of our translators care to
> >> comment on this?
> > 
> > as Seth pointed out the impact for users is quite zero if the change
> > from 'wxT(foo)' to '_(foo)' is happen without further translating of the
> > strings.
> > I personally would like to see the changes right now instead in one of
> > the point releases after 5.0.0. So from my side a clear go, do it right now.
> > 
> 
> If there are no objections, I'm fine with changing them now even if the
> strings don't get translated for the v5 release.
> 

>From me, no objections at all.
Thanks!


-- 


Marco Ciampa

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



 GNU/Linux User #78271
 FSFE fellow #364




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

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #3549

[Miguel Angel Ajo]

See 


Changes:

[Maciej Suminski] Fix -Wparentheses in track_cleaner.cpp

--
[...truncated 153.44 KB...]
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/onleftclick.cpp.o
[ 92%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/__/common/eda_text.cpp.o
[ 92%] Linking CXX shared module _pcb_calculator.kiface
[ 92%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/__/common/dialogs/dialog_page_settings.cpp.o
[ 92%] Built target pcb_calculator_kiface
Scanning dependencies of target s3d_plugin_idf
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_preview_panel.cpp.o
[ 92%] Building CXX object 
plugins/3d/idf/CMakeFiles/s3d_plugin_idf.dir/s3d_plugin_idf.cpp.o
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/onrightclick.cpp.o
[ 92%] Building CXX object 
plugins/3d/idf/CMakeFiles/s3d_plugin_idf.dir/__/__/__/utils/idftools/vrml_layer.cpp.o
[ 92%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/__/common/page_info.cpp.o
[ 92%] Linking CXX shared module libs3d_plugin_idf.so
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/operations_on_items_lists.cpp.o
[ 92%] Built target s3d_plugin_idf
Scanning dependencies of target kicad
[ 92%] Building CXX object kicad/CMakeFiles/kicad.dir/commandframe.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/__/common/dialogs/dialog_page_settings.cpp.o
[ 92%] Linking CXX shared module _pl_editor.kiface
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/pin_number.cpp.o
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/pin_shape.cpp.o
[ 92%] Building CXX object 
kicad/CMakeFiles/kicad.dir/dialogs/dialog_template_selector_base.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/__/common/base_units.cpp.o
[ 92%] Built target pl_editor_kiface
Scanning dependencies of target io_benchmark
[ 92%] Building CXX object 
tools/io_benchmark/CMakeFiles/io_benchmark.dir/io_benchmark.cpp.o
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/pin_type.cpp.o
[ 92%] Building CXX object 
tools/io_benchmark/CMakeFiles/io_benchmark.dir/stdstream_line_reader.cpp.o
[ 92%] Building CXX object 
kicad/CMakeFiles/kicad.dir/dialogs/dialog_template_selector.cpp.o
[ 92%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/pinedit.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dialogs/dialog_scripting.cpp.o
[ 92%] Linking CXX executable io_benchmark
[ 92%] Built target io_benchmark
Scanning dependencies of target idf2vrml
[ 92%] Building CXX object utils/idftools/CMakeFiles/idf2vrml.dir/idf2vrml.cpp.o
[ 92%] Building CXX object kicad/CMakeFiles/kicad.dir/files-io.cpp.o
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_DXF.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dialogs/dialog_scripting_base.cpp.o
[ 92%] Linking CXX executable idf2vrml
[ 92%] Building CXX object kicad/CMakeFiles/kicad.dir/import_project.cpp.o
[ 92%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/pcbnew_wrap.cxx.o
[ 92%] Built target idf2vrml
[ 92%] Building CXX object kicad/CMakeFiles/kicad.dir/kicad.cpp.o
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_HPGL.cpp.o
[ 92%] Building CXX object kicad/CMakeFiles/kicad.dir/mainframe.cpp.o
[ 92%] Building CXX object kicad/CMakeFiles/kicad.dir/menubar.cpp.o
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_PDF.cpp.o
[ 92%] Building CXX object kicad/CMakeFiles/kicad.dir/preferences.cpp.o
[ 92%] Building CXX object kicad/CMakeFiles/kicad.dir/prjconfig.cpp.o
[ 92%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_PS.cpp.o
[ 93%] Building CXX object kicad/CMakeFiles/kicad.dir/project_template.cpp.o
[ 93%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_SVG.cpp.o
[ 93%] Building CXX object kicad/CMakeFiles/kicad.dir/tree_project_frame.cpp.o
[ 93%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/project_rescue.cpp.o
[ 93%] Building CXX object kicad/CMakeFiles/kicad.dir/treeprojectfiles.cpp.o
[ 93%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_base_frame.cpp.o
[ 93%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_bitmap.cpp.o
[ 93%] Building CXX object kicad/CMakeFiles/kicad.dir/treeproject_item.cpp.o
[ 93%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_bus_entry.cpp.o
[ 93%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_collectors.cpp.o
[ 93%] Linking CXX executable kicad
[ 93%] Built target kicad
[ 94%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_component.cpp.o
Scanning 

Re: [Kicad-developers] [PATCH] Python FP wizard helper: docstrings and rounded/chamfered rects

[Nick Østergaard]

We already have doxygen generation for the python API, although people say
that it is easier to read the C++ one. It is generated with
the doxygen-python make target. See
http://docs.kicad-pcb.org/doxygen-python/

Does the additions in 0002 add to the normal python docs?

2018-06-12 15:07 GMT+02:00 Wayne Stambaugh :

> Hey John,
>
> I like the idea of using doxygen to document the python plugins.  The
> current Doxyfile does not include .py files so that would need to
> change.  Before we do that, I would like to see a new section (maybe
> "Python Plugins") added to the documentation to separate the python
> plugin code from the c++ source documentation.  I can commit your patch
> as is and you can make the doxygen changes in a later patch or I can
> wait for you to create a new patch with all of the changes.  I'm fine
> either way.
>
> Cheers,
>
> Wayne
>
> On 6/4/2018 7:33 AM, John Beard wrote:
> > Hi,
> >
> > Here is a simple patch sequence for the Python Footprint Wizard helpers:
> >
> > 1) Minor spelling and formatting tidy-up
> > 2) Add docstrings for the wizard base. As this is intended to be used
> > by writers of new plugins, having the functions documented is probably
> > a Good Idea (TM)
> > 3) Add rounded rectangle and chamfered rectangle helpers. Useful for
> > some footprints or even board outlines.
> >
> > I used Doxygen-style docstrings, but I haven't actually done anything
> > about building actual output docs with it. Any thoughts of if that
> > should be done, and if so, where to put it?
> >
> > There shouldn't be anything here that will break existing plugins, the
> > only API changes are additions.
> >
> > Cheers,
> >
> > John
> >
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
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] Python FP wizard helper: docstrings and rounded/chamfered rects

[Wayne Stambaugh]

Hey John,

I like the idea of using doxygen to document the python plugins.  The
current Doxyfile does not include .py files so that would need to
change.  Before we do that, I would like to see a new section (maybe
"Python Plugins") added to the documentation to separate the python
plugin code from the c++ source documentation.  I can commit your patch
as is and you can make the doxygen changes in a later patch or I can
wait for you to create a new patch with all of the changes.  I'm fine
either way.

Cheers,

Wayne

On 6/4/2018 7:33 AM, John Beard wrote:
> Hi,
> 
> Here is a simple patch sequence for the Python Footprint Wizard helpers:
> 
> 1) Minor spelling and formatting tidy-up
> 2) Add docstrings for the wizard base. As this is intended to be used
> by writers of new plugins, having the functions documented is probably
> a Good Idea (TM)
> 3) Add rounded rectangle and chamfered rectangle helpers. Useful for
> some footprints or even board outlines.
> 
> I used Doxygen-style docstrings, but I haven't actually done anything
> about building actual output docs with it. Any thoughts of if that
> should be done, and if so, where to put it?
> 
> There shouldn't be anything here that will break existing plugins, the
> only API changes are additions.
> 
> Cheers,
> 
> John
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

[Kicad-developers] Stable release update.

[Wayne Stambaugh]

I apologize for being absent the last few days but I had out of town
guests visiting and I didn't want to be rude and spend a lot of time in
front of my computer.

Things seem to be coming along nicely for the v5 stable release and it
appears that all of the critical bugs have been fixed.  Hopefully no new
critical bugs will surface between now and release time and we can get
some good testing on the critical bugs that were recently fixed.  I
would *really* like to get the stable release out before I go on
vacation during the week of July 4th.  Are there any known issues that
anyone can think of that would prevent this from happening?  If so,
please speak up.  If not, let's try to shoot for a June 29th release date.

Thank you to everyone for your hard work.

Cheers,

Wayne

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

[Kicad-developers] Build failed in Jenkins: kicad-qa #4255

[Miguel Angel Ajo]

See 

Changes:

[jeff] Make sure initially loaded footprint is rendered.

--
Started by an SCM change
Building remotely on debian8 (clang gcc linux) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://github.com/KiCad/kicad-source-mirror.git # timeout=10
Fetching upstream changes from https://github.com/KiCad/kicad-source-mirror.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/KiCad/kicad-source-mirror.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 660aed71b4e21c7e3052c665accf1d36ad612a13 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 660aed71b4e21c7e3052c665accf1d36ad612a13
Commit message: "Make sure initially loaded footprint is rendered."
 > git rev-list --no-walk 16411c8c1ebabf934dccec8d9e8bffaef236a87d # timeout=10
[kicad-qa] $ /bin/sh -xe /tmp/jenkins2236287755164047077.sh
+ cmake --version
cmake version 3.0.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
+ gcc --version
gcc (Debian 4.9.2-10+deb8u1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ git --version
git version 2.1.4
+ OPTS= -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
+ [ -d passed-qa ]
+ [ -d build ]
+ cd build
+ /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
-- Kicad install dir: 
-- Check for installed GLEW -- found
-- Boost version: 1.55.0
-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/dist-packages
-- wxPython version 3.0 found.
-- S3DSG version: 2.0.0
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Configuring done
-- Generating done
-- Build files have been written to: 

+ echo CMAKE exit code is 0
CMAKE exit code is 0
+ rm -f pcbnew/pcbnewPYTHON_wrap.cxx
+ env
+ grep -q ^MAKEJOBS=
+ echo The MAKEJOBS variable is empty
The MAKEJOBS variable is empty
+ JOBS=4
+ make -j4 pcbnew_python_module
[  0%] [  0%] Built target pcb_lexer_source_files
Built target lib_table_lexer_source_files
[  1%] Built target pcb_plot_lexer_source_files
[  1%] Built target idf3
[  1%] [  1%] Built target page_layout_lexer_source_files
Built target netlist_lexer_source_files
[  1%] Generating version string header
-- Using Git to determine build version string.
-- Found Git: /usr/bin/git (found version "2.1.4") 
[  4%] Built target kicad_3dsg
-- Writing 
 file with 
version: (5.0.0-rc2-126-g660aed7)
[  4%] Built target version_header
[  7%] Built target gal
[  7%] Built target lib_dxf
[  7%] Built target specctra_lexer_source_files
[ 49%] Built target bitmaps
[ 49%] Built target polygon
[ 53%] Built target pcbcommon
[ 54%] Built target pcad2kicadpcb
[ 60%] Built target 3d-viewer
Scanning dependencies of target common
[ 61%] Building CXX object common/CMakeFiles/common.dir/build_version.cpp.o
Scanning dependencies of target pcbnew_kiface_objects
[ 61%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_viewer_frame.cpp.o
Linking CXX static library libcommon.a
[ 76%] Built target common
[ 76%] Built target github_plugin
[ 78%] Built target pnsrouter
[100%] Built target pcbnew_kiface_objects
Linking CXX shared module _pcbnew.kiface
[100%] Built target pcbnew_kiface
[100%] Creating python's pcbnew native module _pcbnew.so for command line use.
[100%] Built target pcbnew_python_module
+ pwd
+ export PYTHONPATH=
+ cd ../qa
+ /usr/bin/python2 test.py
test_pcb_bounding_box (test_002_board_class.TestBoardClass) ... FAIL
test_pcb_find_module (test_002_board_class.TestBoardClass) ... ok
test_pcb_get_pad (test_002_board_class.TestBoardClass) ... ok
test_pcb_get_track_count (test_002_board_class.TestBoardClass) ... ok
test_pcb_layer_id_get (test_002_board_class.TestBoardClass) ... ok
test_pcb_layer_name_set_get (test_002_board_class.TestBoardClass) ... ok
test_pcb_save_and_load (test_002_board_class.TestBoardClass) ... ok
test_pcb_load 

Re: [Kicad-developers] Untranslated strings

[Wayne Stambaugh]

Hey Carsten,

On 6/12/2018 8:28 AM, Carsten Schoenert wrote:
> Hello Wayne,
> 
> Am 12.06.2018 um 14:07 schrieb Wayne Stambaugh:
>> I'm thinking we should probably wait until after v5 and back port the
>> fix to the v5 branch but the string example you noted should definitely
>> be translated.  I don't know how much grief this would cause our
>> translators this late in the game.  Would any of our translators care to
>> comment on this?
> 
> as Seth pointed out the impact for users is quite zero if the change
> from 'wxT(foo)' to '_(foo)' is happen without further translating of the
> strings.
> I personally would like to see the changes right now instead in one of
> the point releases after 5.0.0. So from my side a clear go, do it right now.
> 

If there are no objections, I'm fine with changing them now even if the
strings don't get translated for the v5 release.

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

[Kicad-developers] Build failed in Jenkins: kicad-qa #4254

[Miguel Angel Ajo]

See 

Changes:

[Maciej Suminski] Fix -Wparentheses in track_cleaner.cpp

--
Started by an SCM change
Building remotely on debian8 (clang gcc linux) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://github.com/KiCad/kicad-source-mirror.git # timeout=10
Fetching upstream changes from https://github.com/KiCad/kicad-source-mirror.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/KiCad/kicad-source-mirror.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 16411c8c1ebabf934dccec8d9e8bffaef236a87d 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 16411c8c1ebabf934dccec8d9e8bffaef236a87d
Commit message: "Fix -Wparentheses in track_cleaner.cpp"
 > git rev-list --no-walk 9605dd8e1de3179643d075fa587efb26e31ca883 # timeout=10
[kicad-qa] $ /bin/sh -xe /tmp/jenkins7187636663585883735.sh
+ cmake --version
cmake version 3.0.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
+ gcc --version
gcc (Debian 4.9.2-10+deb8u1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ git --version
git version 2.1.4
+ OPTS= -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
+ [ -d passed-qa ]
+ [ -d build ]
+ cd build
+ /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
-- Kicad install dir: 
-- Check for installed GLEW -- found
-- Boost version: 1.55.0
-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/dist-packages
-- wxPython version 3.0 found.
-- S3DSG version: 2.0.0
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   unit_test_framework
-- Configuring done
-- Generating done
-- Build files have been written to: 

+ echo CMAKE exit code is 0
CMAKE exit code is 0
+ rm -f pcbnew/pcbnewPYTHON_wrap.cxx
+ env
+ grep -q ^MAKEJOBS=
+ echo The MAKEJOBS variable is empty
The MAKEJOBS variable is empty
+ JOBS=4
+ make -j4 pcbnew_python_module
[  0%] [  0%] [  1%] Built target pcb_lexer_source_files
Built target lib_table_lexer_source_files
Built target pcb_plot_lexer_source_files
[  1%] Built target idf3
[  1%] Built target page_layout_lexer_source_files
[  1%] Built target netlist_lexer_source_files
[  1%] [  4%] Generating version string header
Built target kicad_3dsg
-- Using Git to determine build version string.
[  7%] Built target gal
-- Found Git: /usr/bin/git (found version "2.1.4") 
[  7%] Built target lib_dxf
-- Writing 
 file with 
version: (5.0.0-rc2-125-g16411c8)
[  7%] [  7%] Built target polygon
Built target version_header
[  7%] Built target specctra_lexer_source_files
[ 49%] Built target bitmaps
[ 53%] Built target pcbcommon
[ 54%] Built target pcad2kicadpcb
[ 60%] Built target 3d-viewer
Scanning dependencies of target common
[ 61%] Building CXX object common/CMakeFiles/common.dir/build_version.cpp.o
Scanning dependencies of target pcbnew_kiface_objects
[ 61%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tracks_cleaner.cpp.o
Linking CXX static library libcommon.a
[ 83%] Built target pcbnew_kiface_objects
[ 97%] Built target common
[ 97%] Built target github_plugin
[100%] Built target pnsrouter
Linking CXX shared module _pcbnew.kiface
[100%] Built target pcbnew_kiface
[100%] Creating python's pcbnew native module _pcbnew.so for command line use.
[100%] Built target pcbnew_python_module
+ pwd
+ export PYTHONPATH=
+ cd ../qa
+ /usr/bin/python2 test.py
test_pcb_bounding_box (test_002_board_class.TestBoardClass) ... FAIL
test_pcb_find_module (test_002_board_class.TestBoardClass) ... ok
test_pcb_get_pad (test_002_board_class.TestBoardClass) ... ok
test_pcb_get_track_count (test_002_board_class.TestBoardClass) ... ok
test_pcb_layer_id_get (test_002_board_class.TestBoardClass) ... ok
test_pcb_layer_name_set_get (test_002_board_class.TestBoardClass) ... ok
test_pcb_save_and_load (test_002_board_class.TestBoardClass) ... ok
test_pcb_load (test_001_pcb_load.TestPCBLoad) 

Re: [Kicad-developers] Untranslated strings

[Carsten Schoenert]

Hello Wayne,

Am 12.06.2018 um 14:07 schrieb Wayne Stambaugh:
> I'm thinking we should probably wait until after v5 and back port the
> fix to the v5 branch but the string example you noted should definitely
> be translated.  I don't know how much grief this would cause our
> translators this late in the game.  Would any of our translators care to
> comment on this?

as Seth pointed out the impact for users is quite zero if the change
from 'wxT(foo)' to '_(foo)' is happen without further translating of the
strings.
I personally would like to see the changes right now instead in one of
the point releases after 5.0.0. So from my side a clear go, do it right now.

-- 
Regards
Carsten Schoenert

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

Re: [Kicad-developers] [PATCH] Fix -Wparentheses warning in track_cleaner.cpp

[Maciej Sumiński]

Hi John,

Thank you for the patch, I have just pushed it to the master branch.

Cheers,
Orson

On 06/12/2018 12:16 PM, John Beard wrote:
> Hi,
> 
> This is a very simple patch to address a -Wparentheses warning in
> pcbnew/track_cleaner.cpp.
> 
> It was "wxBusyCursor( dummy );", it is now "wxBusyCursor dummy;"
> 
> Cheers,
> 
> John
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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

Re: [Kicad-developers] Untranslated strings

[Wayne Stambaugh]

I'm thinking we should probably wait until after v5 and back port the
fix to the v5 branch but the string example you noted should definitely
be translated.  I don't know how much grief this would cause our
translators this late in the game.  Would any of our translators care to
comment on this?

Cheers,

Wayne

On 6/11/2018 11:28 PM, Seth Hillbrand wrote:
> ​Hi Devs-
> 
> We're in string freeze but I've run across a couple of strings that are
> wxT() instead of _()​.  Example: cvpcb/display_footprints_frame.cpp:435.
> 
> I have a preference for converting these to _(), even at this stage as
> worst-case is that they remain untranslated as they are now.  Does
> anyone object to this plan?  Is there a good reason to stay with wxT
> until after v5?
> 
> -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
> 

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

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #3548

[Miguel Angel Ajo]

See 


Changes:

[Maciej Suminski] Fix selection clearance for via and tracks

--
[...truncated 151.31 KB...]
[ 89%] Linking CXX executable pcb_calculator
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/pin_type.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/deltrack.cpp.o
[ 89%] Built target pcb_calculator
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dimension.cpp.o
[ 89%] Building CXX object cvpcb/CMakeFiles/cvpcb_kiface.dir/tool_cvpcb.cpp.o
[ 89%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/pinedit.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/fp_conflict_assignment_selector_base.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/dragsegm.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_DXF.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/fp_conflict_assignment_selector.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/dialog_display_options.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/dialog_display_options_base.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_HPGL.cpp.o
[ 89%] Building CXX object pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/drc.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/dialog_config_equfiles_base.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/dialog_config_equfiles.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_PDF.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/dialogs/dialog_fp_lib_table.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/drc_clearance_test_functions.cpp.o
[ 90%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/dialogs/dialog_fp_lib_table_base.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_PS.cpp.o
[ 90%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/dialogs/dialog_fp_plugin_options.cpp.o
[ 90%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/dialogs/dialog_fp_plugin_options_base.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/drc_marker_functions.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/plot_schematic_SVG.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/project_rescue.cpp.o
[ 90%] Linking CXX shared module _cvpcb.kiface
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/edgemod.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_base_frame.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_bitmap.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_bus_entry.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/edit.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_collectors.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/edit_pcb_text.cpp.o
[ 90%] Built target cvpcb_kiface
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/edit_track_width.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_component.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/editedge.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/editrack-part2.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/editrack.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/edtxtmod.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_eagle_plugin.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/event_handlers_tracks_vias_sizes.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/files.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_info_impl.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_editor_utils.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_field.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_editor_onclick.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_editor_options.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_edit_frame.cpp.o
[ 91%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sch_io_mgr.cpp.o
[ 92%] Building CXX object 

[Kicad-developers] [PATCH] Fix -Wparentheses warning in track_cleaner.cpp

[John Beard]

Hi,

This is a very simple patch to address a -Wparentheses warning in
pcbnew/track_cleaner.cpp.

It was "wxBusyCursor( dummy );", it is now "wxBusyCursor dummy;"

Cheers,

John
From 60b4e54c733934f42f1911c8c8a08d7c2ecf011a Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 12 Jun 2018 10:49:08 +0100
Subject: [PATCH] Fix -Wparentheses in track_cleaner.cpp
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Changes "wxBusyCursor( dummy );" to just "wxBusyCursor dummy;"

Fixes warning: ../pcbnew/tracks_cleaner.cpp:155:17:
warning: unnecessary parentheses in declaration of ‘dummy’ [-Wparentheses]
 wxBusyCursor( dummy )
---
 pcbnew/tracks_cleaner.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pcbnew/tracks_cleaner.cpp b/pcbnew/tracks_cleaner.cpp
index a291c1533..b853e02cc 100644
--- a/pcbnew/tracks_cleaner.cpp
+++ b/pcbnew/tracks_cleaner.cpp
@@ -152,7 +152,7 @@ void PCB_EDIT_FRAME::Clean_Pcb()
 // Old model has to be refreshed, GAL normally does not keep updating it
 Compile_Ratsnest( NULL, false );
 
-wxBusyCursor( dummy );
+wxBusyCursor dummy;
 BOARD_COMMIT commit( this );
 TRACKS_CLEANER cleaner( GetBoard(), commit );
 
-- 
2.17.0

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

[Kicad-developers] Build failed in Jenkins: kicad-qa #4253

[Miguel Angel Ajo]

See 

Changes:

[Maciej Suminski] Fix selection clearance for via and tracks

--
[...truncated 40.94 KB...]
:248:11: 
warning: declaration of ‘frame’ shadows a member of 'this' [-Wshadow]
 auto& frame = *getEditFrame();
   ^
: In member 
function ‘int PAD_TOOL::pushPadSettings(const TOOL_EVENT&)’:
:326:17: 
warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 const auto& selection = selTool.GetSelection();
 ^
:328:11: 
warning: declaration of ‘frame’ shadows a member of 'this' [-Wshadow]
 auto& frame = *getEditFrame();
   ^
:358:13: 
warning: declaration of ‘module’ shadows a member of 'this' [-Wshadow]
 MODULE* module = srcPad->GetParent();
 ^
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/pcb_selection_conditions.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/pcb_tool.cpp.o
[ 91%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/pcbnew_control.cpp.o
: 
In member function ‘int PCB_EDITOR_CONTROL::TrackWidthInc(const TOOL_EVENT&)’:
:350:12:
 warning: declaration of ‘board’ shadows a member of 'this' [-Wshadow]
 BOARD* board = getModel();
^
: 
In member function ‘int PCB_EDITOR_CONTROL::TrackWidthDec(const TOOL_EVENT&)’:
:367:12:
 warning: declaration of ‘board’ shadows a member of 'this' [-Wshadow]
 BOARD* board = getModel();
^
: 
In member function ‘int PCB_EDITOR_CONTROL::ViaSizeInc(const TOOL_EVENT&)’:
:384:12:
 warning: declaration of ‘board’ shadows a member of 'this' [-Wshadow]
 BOARD* board = getModel();
^
: 
In member function ‘int PCB_EDITOR_CONTROL::ViaSizeDec(const TOOL_EVENT&)’:
:401:12:
 warning: declaration of ‘board’ shadows a member of 'this' [-Wshadow]
 BOARD* board = getModel();
^
: 
In member function ‘int PCB_EDITOR_CONTROL::PlaceModule(const TOOL_EVENT&)’:
:418:13:
 warning: declaration of ‘module’ shadows a member of 'this' [-Wshadow]
 MODULE* module = aEvent.Parameter();
 ^
:419:27:
 warning: declaration of ‘controls’ shadows a member of 'this' [-Wshadow]
 KIGFX::VIEW_CONTROLS* controls = getViewControls();
   ^
:421:16:
 warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 SELECTION& selection = selTool->GetSelection();
^
: 
In member function ‘int 
PCB_EDITOR_CONTROL::modifyLockSelected(PCB_EDITOR_CONTROL::MODIFY_MODE)’:
:539:22:
 warning: declaration of ‘selection’ shadows a member of 'this' [-Wshadow]
 const SELECTION& selection = selTool->GetSelection();
  ^
: 
In member function ‘int PCB_EDITOR_CONTROL::PlaceTarget(const TOOL_EVENT&)’:
:581:18:
 warning: declaration of ‘view’ shadows a member of 'this' [-Wshadow]
 KIGFX::VIEW* view = getView();
  ^
:582:27:
 warning: declaration of ‘controls’ shadows a member of 'this' [-Wshadow]
 KIGFX::VIEW_CONTROLS* controls = getViewControls();
   ^
:583:12:
 warning: declaration of ‘board’ shadows a member of 'this' [-Wshadow]
 BOARD* board = 

Re: [Kicad-developers] Untranslated strings

[Nick Østergaard]

I think this would be ok as it does not change anything from the user even
if the translation is not updated. But I am not really a translator, so
there might be some subtle thing I have missed.

2018-06-12 5:28 GMT+02:00 Seth Hillbrand :

> ​Hi Devs-
>
> We're in string freeze but I've run across a couple of strings that are
> wxT() instead of _()​.  Example: cvpcb/display_footprints_frame.cpp:435.
>
> I have a preference for converting these to _(), even at this stage as
> worst-case is that they remain untranslated as they are now.  Does anyone
> object to this plan?  Is there a good reason to stay with wxT until after
> v5?
>
> -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
>
>
___
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 doc build process

[Nick Østergaard]

tir. 12. jun. 2018 09.28 skrev Marco Ciampa :

> Hi folks,
> I would like to know better the organization of the build process
> (Continuous Integration) for the doc files.
>
> What I would like to know precisely is:
>
> - who is in charge to run the machines that build the docs
>

Ajo, but I primarely maimtain it.

- what is the frequency of the build process
>

Every commit

- where I can find the links to these machines (in the site)
>

You browse Jenkins at ci.kicad-pcb.org

The specific job is at http://ci.kicad-pcb.org/job/any-kicad-doc-head/

It has been failing since
https://github.com/KiCad/kicad-doc/commit/f7e9226902156d79459ad63b1a9a39
3a3b5da829

I guess that there are some new dependencies that needs to be installed as
of https://github.com/KiCad/kicad-doc/issues/588

- how it works (for better undestanding of the whole process)
>   and how to check if, for instance, I did something wrong...
>

Check the build jon on Jenkins.

- where is (if there is) some docs for this whole process
>
>
It just does cmke amd make. no magic involved.

I think that if all this in not documented, why not document it?
>
>
There is no magic to document as such.

For my (very little) experience document processes is one of the best
> way to improve them...
>

I guess the best improvement we could wish for for the docs is faster build
times.  Historically we talked about comparing the build times and out with
asciidoctor vs asciidoc. I don't think we ever managed to get this done.


> TIA
>
> Best Regards,
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> 
>
>  GNU/Linux User #78271
>  FSFE fellow #364
>
> 
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
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] kicad doc build process

[Marco Ciampa]

Hi folks,
I would like to know better the organization of the build process
(Continuous Integration) for the doc files.

What I would like to know precisely is:

- who is in charge to run the machines that build the docs
- what is the frequency of the build process
- where I can find the links to these machines (in the site)
- how it works (for better undestanding of the whole process)
  and how to check if, for instance, I did something wrong...
- where is (if there is) some docs for this whole process


I think that if all this in not documented, why not document it? 

For my (very little) experience document processes is one of the best
way to improve them...

TIA

Best Regards,

--


Marco Ciampa

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



 GNU/Linux User #78271
 FSFE fellow #364




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