Re: [Kicad-developers] Rev 6350, abs vs std::abs

JP, Please add to math_for_graphic.cpp to see if it resolves the issue? It does look a bit odd using both abs() and std::abs() in the same source file. Thanks, Wayne On 12/7/2015 8:28 AM, Chris Pavlina wrote: > It is indeed difficult to test an issue that doesn't appear on your computer, >

Re: [Kicad-developers] Rev 6350, abs vs std::abs

Le 07/12/2015 14:28, Chris Pavlina a écrit : > It is indeed difficult to test an issue that doesn't appear on your > computer, but from a quick look around, it looks like the correct way > is to leave std::abs, but add #include . Unlike stdlib.h, > cstdlib defines overloads for all the integer

Re: [Kicad-developers] [patch] default kicad_common to environment variables

The test build is going now, will be done within 30 minutes. Adam Wolf On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh wrote: > Adam, > > I forgot to ask, do you want me to go ahead with this patch? > > Thanks, > > Wayne > > On 12/6/2015 7:13 PM, Adam Wolf wrote: > > When

Re: [Kicad-developers] Full integration to Github

So I did just a import of "open" issues from launchpad. https://github.com/marekr/kicad-issue-test/issues?page=7=is%3Aissue+is%3Aopen 1. Github's API rate limiting is extreme, they trip on "abuse detection" really really often so it took ~24 hours just to get 700 issues and only partial comments

Re: [Kicad-developers] FindGLM script

Orson, I think the patch has been tested on all platforms so go ahead and commit it if you comfortable with the changes. Thanks, Wayne On 12/7/2015 7:38 AM, Maciej Sumiński wrote: > Hi Cirilo, > > Thank you for the FindGLM script. I had to modify it slightly, as it did > not work with CMake

Re: [Kicad-developers] [patch] default kicad_common to environment variables

Adam, I forgot to ask, do you want me to go ahead with this patch? Thanks, Wayne On 12/6/2015 7:13 PM, Adam Wolf wrote: > When are you planning on doing the 4.0.1 release? Todayish or in about 7 > days? > > Adam Wolf > > > On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh

Re: [Kicad-developers] Rev 6350, abs vs std::abs

It is indeed difficult to test an issue that doesn't appear on your computer, but from a quick look around, it looks like the correct way is to leave std::abs, but add #include . Unlike stdlib.h, cstdlib defines overloads for all the integer widths, reducing the possibility of a bad mistake

Re: [Kicad-developers] [patch] default kicad_common to environment variables

I just noticed that on linux at least, that when I set KISYSMOD=/tmp (nothing else) I do get KISYSMOD=/tmp in the configure paths dialog, good, but I have a KISYS3DMOD=/packages3d/tmp That would be totally wrong. I did definitely not expect the tmp to be appended after packages3d. 2015-12-07

Re: [Kicad-developers] Full integration to Github

Hi. Maybe one need to run script that add message to all open bugs in launchpad. Message like that: If we want to add new message click to this link ... Message consists link to another script that (or instruction how) check and if need open new bug on Github with name copied from Launchpad and

Re: [Kicad-developers] [patch] default kicad_common to environment variables

To clarify, by "results", I mean "shows up in the path manager as". I wonder if we're doing something later, hmm. Adam Wolf On Mon, Dec 7, 2015 at 11:09 AM, Adam Wolf wrote: > It works fine on OS X. > > I found a weirdess with AppendDir, however, that I don't

Re: [Kicad-developers] [patch] default kicad_common to environment variables

It works fine on OS X. I found a weirdess with AppendDir, however, that I don't think should hold this patch up, but I want to mention on the list. If tmpfilename is set to something like "helloworld", tmpFileName.AppendDir( wxT( "packages3d" ) ); results in

Re: [Kicad-developers] [patch] default kicad_common to environment variables

Yes, I noticed that too. :) 2015-12-07 18:14 GMT+01:00 Adam Wolf : > To clarify, by "results", I mean "shows up in the path manager as". I > wonder if we're doing something later, hmm. > > Adam Wolf > > On Mon, Dec 7, 2015 at 11:09 AM, Adam Wolf

[Kicad-developers] PATCH: bugfix for IDF export

The attached patch fixes the following bugs in the IDF export: 1. incorrect orientation of components on the bottom side of the board when the #D model rotation is non-zero 2. failure to export when some components have no model set - Cirilo === modified file 'pcbnew/exporters/export_idf.cpp'

Re: [Kicad-developers] ancient autorouter code

Le 07/12/2015 06:13, Henner Zeller a écrit : > On 6 December 2015 at 20:58, Adam Wolf wrote: >> I believe that there was integration done so that if you click the >> autorouter button, it tells you in the status bar to put the jar in a >> certain path, at which

Re: [Kicad-developers] PATCH: bugfix for IDF export

Le 07/12/2015 09:07, Cirilo Bernardo a écrit : > The attached patch fixes the following bugs in the IDF export: > > 1. incorrect orientation of components on the bottom side of the board > when the #D model rotation is non-zero > > 2. failure to export when some components have no model set > >

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

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

Re: [Kicad-developers] [patch] default kicad_common to environment variables

2015-12-06 23:01 GMT+01:00 Wayne Stambaugh : > On 12/6/2015 3:48 PM, Nick Østergaard wrote: >> I am very tempted to just apply this to the 4.0.0 windows installer, >> just such that the libs will actually work when people install them. >> >> Should I refrain from this? > >

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

See Changes: [jean-pierre charras] Kicad manager: fix a potential bug which could crash Kicad manager. math_for_graphics.cpp: remove useless includes. -- Started by an SCM change Building on master in

Re: [Kicad-developers] FindGLM script

Hi Cirilo, Thank you for the FindGLM script. I had to modify it slightly, as it did not work with CMake 3.4.0 (problem with STREQUAL). Here is complete patch [1], that I applied to KiCad in order to use the system glm library (0.9.7 in my case). If there are no problems with other

Re: [Kicad-developers] [patch] default kicad_common to environment variables

Was this the case before the patch? I don't remember seeing this when I was debugging the original code. On 12/7/2015 12:15 PM, Nick Østergaard wrote: > Yes, I noticed that too. :) > > 2015-12-07 18:14 GMT+01:00 Adam Wolf : >> To clarify, by "results", I mean

Re: [Kicad-developers] [patch] default kicad_common to environment variables

That it did not work at all. 2015-12-07 18:55 GMT+01:00 Wayne Stambaugh : > Was this the case before the patch? I don't remember seeing this when I > was debugging the original code. > > On 12/7/2015 12:15 PM, Nick Østergaard wrote: >> Yes, I noticed that too. :) >> >>

Re: [Kicad-developers] [patch] default kicad_common to environment variables

wxFileName makes some "choices". i.e. its constructor/assignment takes the string and tries to separate file from path. in the case of wxFileName = "helloworld"; it assumes its a filename in the case of wxFileName = "/helloworld", it assumes its a file name in the case of wxFilename =

Re: [Kicad-developers] [patch] default kicad_common to environment variables

2015-12-07 19:45 GMT+01:00 Wayne Stambaugh : > I'm not sure what you mean by it did not work at all. It does exactly > what I designed to do. It gives the user the ability to override the > env variables by doing this: > > export KISYSMOD=/some/path/to/footprint/libraries >

[Kicad-developers] Rev 6350, abs vs std::abs

Mostly directed at JP: Back in June, I went through and changed a few 'weird' things we were doing, including using C abs instead of C++ std::abs: http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5831 You just changed it back:

Re: [Kicad-developers] Rev 6350, abs vs std::abs

Le 07/12/2015 13:51, Chris Pavlina a écrit : > Mostly directed at JP: > > Back in June, I went through and changed a few 'weird' things we were doing, > including using C abs instead of C++ std::abs: > > http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5831 > > You

Re: [Kicad-developers] [patch] default kicad_common to environment variables

On 12/7/2015 5:07 AM, Nick Østergaard wrote: > 2015-12-06 23:01 GMT+01:00 Wayne Stambaugh : >> On 12/6/2015 3:48 PM, Nick Østergaard wrote: >>> I am very tempted to just apply this to the 4.0.0 windows installer, >>> just such that the libs will actually work when people

Re: [Kicad-developers] CMake version.

Adam, I updated my Port today, Jean-Pauls-MacBook-Pro:~ jean-paullouis$ sudo port selfupdate followed by Jean-Pauls-MacBook-Pro:~ jean-paullouis$ sudo port upgrade outdated and the update moved cmake to 3.4.1. Jean-Pauls-MacBook-Pro:~ jean-paullouis$ cmake --version cmake version 3.4.1 CMake

Re: [Kicad-developers] CMake version.

I do not use MacPorts. I was talking about the machine that does the Mac releases/nightly builds. Thanks! OS X folks are definitely able to get up to 3.0.2 or newer. Adam Wolf On Mon, Dec 7, 2015 at 8:26 PM, Jean-Paul Louis wrote: > Adam, > I updated my Port today, > >

[Kicad-developers] Updated kicad-install.sh build script

Just updated the kicad-install.sh bash install script for linux-debian, Added disable parts libs build/install option with option "-L" This should make thing's a little faster. Also fix some file permissions, problems when building under sub directors not owned by the user. It's hosted at:

Re: [Kicad-developers] [PATCH v2] Use CMake high-level facility for visibility

I lost the thread, but someone was asking if this works on OS X. It appears to work fine. Adam Wolf On Sun, Sep 6, 2015 at 10:48 AM, Simon Richter wrote: > Hi, > > this is an improved version of the earlier patch, using the visibility > handling in CMake 3.3, and

Re: [Kicad-developers] [PATCH v2] Use CMake high-level facility for visibility

Thanks Adam! I'll commit the patch. On 12/7/2015 2:26 PM, Adam Wolf wrote: > I lost the thread, but someone was asking if this works on OS X. It > appears to work fine. > > Adam Wolf > > On Sun, Sep 6, 2015 at 10:48 AM, Simon Richter

Re: [Kicad-developers] [patch] default kicad_common to environment variables

On Tue, Dec 8, 2015 at 4:09 AM, Adam Wolf wrote: > It works fine on OS X. > > I found a weirdess with AppendDir, however, that I don't think should hold > this patch up, but I want to mention on the list. > > If tmpfilename is set to something like "helloworld", >

Re: [Kicad-developers] [patch] default kicad_common to environment variables

Updated patch to use AssignDir instead of me stupidly assigning to wxFilename. I added an empty var check(so it uses default instead) but it's pointless. Windows disallows empty env vars. On other systems if its empty you have configuration issues and you should be fixing them, not kicad.

Re: [Kicad-developers] [PATCH] Copper layers selected by default in plot dialog

Updated patch. The stupid thing I missed shouldn't happen any more. When you plot it will only plot the layers you have selected rather than all of the copper layers. Jon On Fri, Dec 4, 2015 at 4:06 PM, Jon Neal wrote: > I think I understand the issue. I will provide

Re: [Kicad-developers] [patch] default kicad_common to environment variables

This patch seem to work more sanely. 2015-12-07 21:48 GMT+01:00 Mark Roszko : > Updated patch to use AssignDir instead of me stupidly assigning to wxFilename. > > I added an empty var check(so it uses default instead) but it's > pointless. Windows disallows > empty env

Re: [Kicad-developers] [patch] default kicad_common to environment variables

On 12/7/2015 3:48 PM, Mark Roszko wrote: > Updated patch to use AssignDir instead of me stupidly assigning to wxFilename. > > I added an empty var check(so it uses default instead) but it's > pointless. Windows disallows > empty env vars. On other systems if its empty you have configuration >

Re: [Kicad-developers] [PATCH 1/4] Use CMake high-level facility for visibility

Patch committed in product branch r6352. Thanks. On 12/1/2015 2:14 AM, Simon Richter wrote: > > CMake 3.0 defines two new variables, > > * CMAKE_CXX_VISIBILITY_PRESET and > * CMAKE_VISIBILITY_INLINES_HIDDEN > > to control whether symbols not explicitly tagged for export are implicitly >

[Kicad-developers] CMake version.

We currently have the minimum CMake version set to 2.8.4 which was release in February of 2011. Debian stable which is usually one of the last distros to get updated is currently at 3.0.2. Is anyone using a version older than 3.0.2 to build KiCad? If not, I'm going to bump the minumum CMake

Re: [Kicad-developers] [patch] default kicad_common to environment variables

That's what the patch does now.. Someone using msys2 for anything other than compiling is a bit strange though. On Dec 7, 2015 4:59 PM, "Wayne Stambaugh" wrote: > On 12/7/2015 3:48 PM, Mark Roszko wrote: > > Updated patch to use AssignDir instead of me stupidly assigning

[Kicad-developers] [PATCH] Fix broken language in duplicate zone error message

The following error messages in pcbnew are poorly written: - The duplicated zone is on the same layer as the initial zone, which has no sense. Please, choose another layer for the new zone. + for obvious reasons, broken English - The outline of the duplicated zone fails DRC check! +

Re: [Kicad-developers] CMake version.

On Mon, Dec 07, 2015 at 04:54:06PM -0500, Wayne Stambaugh wrote: > We currently have the minimum CMake version set to 2.8.4 which was > release in February of 2011. Debian stable which is usually one of the > last distros to get updated is currently at 3.0.2. Is anyone using a > version older

Re: [Kicad-developers] [patch] default kicad_common to environment variables

Actually turns out theres a AssignDir function. So tmpFileName = blah just needs to be converted to tmpFileName.AssignDir( env_var ) assuming they didn't make assigndir barf on no trailing slash ___ Mailing list:

Re: [Kicad-developers] [patch] default kicad_common to environment variables

I'm working through it--if anyone can dig deeper sooner, please do so. (I need to refactor my build system so I can do non-fresh builds, this is taking forever :) ) Adam Wolf On Mon, Dec 7, 2015 at 11:55 AM, Wayne Stambaugh wrote: > Was this the case before the patch? I

Re: [Kicad-developers] [patch] default kicad_common to environment variables

I think that would be a good idea. This is the way it seems to always go for me too--have a patch to add something to KiCad, and expose an issue we didn't realize we had :) Adam Wolf On Mon, Dec 7, 2015 at 12:10 PM, Mark Roszko wrote: > wxFileName makes some "choices".

Re: [Kicad-developers] [patch] default kicad_common to environment variables

I'm not sure what you mean by it did not work at all. It does exactly what I designed to do. It gives the user the ability to override the env variables by doing this: export KISYSMOD=/some/path/to/footprint/libraries kicad and to gives package devs a way to define where the library and

Re: [Kicad-developers] Full integration to Github

>I am not sure that closed issues have no value. In the last few months, >probably 10% of the bugs I've closed were old bugs that resurfaced in a new >way. I don't think we want to lose that. But they can sit in cold storage on launchpad. People don't reopen the old bug reports do they? They

Re: [Kicad-developers] CMake version.

https://launchpad.net/ubuntu/+source/cmake Wow, a distro that's slower than Debian, I don't know what to say. Sadly I don't think we should necessarily wait for the 14.04 LTS to expire 4 years from now. On Mon, Dec 7, 2015 at 6:27 PM, Marco Ciampa wrote: > On Mon, Dec 07,

Re: [Kicad-developers] CMake version.

(We're at 3.1.2 for OS X builds, btw.) On Mon, Dec 7, 2015 at 7:20 PM, Mark Roszko wrote: > https://launchpad.net/ubuntu/+source/cmake > > Wow, a distro that's slower than Debian, I don't know what to say. > Sadly I don't think we should necessarily wait for the 14.04 LTS

Re: [Kicad-developers] CMake version.

Presumably anyone building on an old Ubuntu-LTS must know what they're doing and CMake is the least of their worries, so I wouldn't count this as a problem. If the LTS people want to support a newer kicad version on that system I'm sure they can backport all the other libraries and frameworks