from:"Michael Steinberg"


Hello all,

one question might have drowned a bit: is there any particular reason 
why kicad builds executables and libs into their own private directories 
in first place rather than into a "bin" directory that I should be aware 
off? It will help all considerations when I don't miss the important 
stuff :)


Michael

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

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests


Hello,

sorry for the noise, yes, the test cases can themselves be organized 
into suites inside the test-executable with Boost.Test (Test-trees so to 
say), so we're free to build a gazillion of executables per module or 
collect them inside one executable and add a CTest-test for each suite 
which is then run with the corresponding runtime arguments instead. We 
could use this functionality also for other things. Orson pointed out 
that having multiple executables will help speeding things up in case of 
distributed parallel builds.
In any case reorganizing stuff will be rather painless due to all the 
freedoms. Since I'm seeing it all only from the viewpoint of a developer 
people running build machines should have the last word to say, how to 
set it up so it blends in nicely.


Cheers!
Michael

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

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests


Hello Wayne, and others too of course!


I'm fine with copying the binaries to a single directory.  It's not very
elegant but it's probably the path of least resistance.  I'm surprised
cmake doesn't have a way to temporarily add build libs for testing
purposes.  Maybe they do and I'm just not aware of it.  Please make sure
you add any necessary hooks to clean up the shared test directory to the
cmake config so as not to leave a bunch of orphaned binaries laying around.


CMake makes it easy to customize the output build directory per target or 
shared. That was the most help I was expecting really. If we set a variable 
this way, we build to a shared directory, otherwise we don't. The build system 
will then figure out if that means to only copy the stuff from the intermediate 
build directories, or a full rebuild is necessary. Also see the last paragraph.


I would like finer test granularity as well.  It would also be nice if
tests could be grouped so that you could run say all of the tests on
libcommon as a group or each individual test within the libcommon group.
  I don't know if boost::unit_test supports this but if it does that
would be a good thing to implement.
I think we need to differ here on which level the granularity is 
intended to be. There's the CTest-level that works on "command" 
granularity. The executables themselves are linked to Boost.test, so you 
can specify which tests to run inside the executable as well.
CTest granularity could then be multiple executables: 
"libcommon.string", "libcommon.foo", "libcommon.bar". It could as well 
mean one executable but multiple runs of the same test-executable with 
different command line arguments.
I will investigate which if any possibilities there are to define suites 
per one executable in Boost.Test, or if test cases are the broadest 
thing there, just to get the picture complete. I only want to mention 
that CTest and Boost.Test are more or less complementing each other 
rather than doing the same thing and there's space to find the best 
combination for us.


I originally intended to actually build kicad into a shared directory on 
windows in development and test configurations (no need to run an extra 
install if they're directly built into a destination environment, so it 
helps the development cycle as well). So it would probably be a (c)make 
clean operation to purge the build in this case. What are the benefits 
of rather copying them around in a custom build step, since that seems 
so natural to you  that you take it as given?


Michael

PS: Sorry that the citing is not perfect, I copied from multiple sources.

___
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] [RFC] [PATCH] simple C++ tests


Hello Orson,


Am 07.12.2016 um 10:29 schrieb Maciej Sumiński:

I used to work with projects that had multiple small unit tests and it
was quite neat solution. Do you think it would be much harder to apply
the same rules here? If so, I would not mind having one-to-one relation
between targets and tests, especially that one can easily separate tests
using boost.test judging from the screenshot you posted.

Regards,
Orson
That would absolutely be possible, my intention avoiding that on the 
first shot was only that I feared having a full executable link process 
per test/test case might be a bit troublesome in the long run. Did you 
have no problems with that, how many tests were there, did it slow down 
the build process at all? No matter how many test targets we produce, 
CTest will only ever say "passed" or "not passed" for each without any 
further information of what is the cause, if I'm not completely mistaken.


Michael

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

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

2016-12-06 Thread Michael Steinberg


Hello,

I played around a bit and settled on a quick solution. For running 
the tests on windows binding to the shared libs is a problem with our 
default build, because we have separate output directories per target. 
Only after an install operation are they in one directory for proper 
library lookup. So I added an option to the kicad cmake script to output 
all targets to a single shared directory, this option is implicitly 
activated when unit tests are enabled on windows. It then also adds the 
boost.test dependency.
Everything else is just like I described in the last message: CTest can 
be used to run all the test executables, if you want boost.test 
verbosity, you can always run the tests from the command prompt.


Problem left would then be, how we set up the test targets. My initial 
thought would be to have one target per lib/executable. All tests 
related to the common library would then be combined to the 
"common-test" target for example.


Here's a screenshot for the targets, RUN_TESTS (CTest) output, 
boost.test output and the shared stage dir: 
https://s17.postimg.org/p5ktjhoe5/kicad_unit_tests.png


Am I making any sense? I might not be aware of all the things you expect 
from this.


Michael


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

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests

2016-12-05 Thread Michael Steinberg


Hey,

I have worked only on one CMake project that uses CTest and that worked 
like CTest calls the the executable for a test suite and checks the 
return error code. However if there are multiple tests in a executable 
it will just show that any of it failed, but not what exactly failed, so 
it is really not helpful for the developer. Linking an executable per 
test is imho prohibitive. So my workflow was coding the tests units with 
google test (or boost.test, whatever fits) and use CTest only as a 
validation if all tests-suites pass. If any fails I go ahead and run 
that test from the prompt to get the detailed unit-test-lib output.
Another option would be to use extended add_test to run the executables 
with arguments identifying the specific test to run, but that is not 
really developer friendly either, right?
Does anyone have experience with a nice CTest workflow or an example I 
could have a look at?


Michael


Am 05.12.2016 um 14:43 schrieb Wayne Stambaugh:

I would be more than happy if you wanted to take on the task of getting
the c++ unit testing framework set up.  Maybe once the infrastructure is
in place, developers would be more likely to write unit tests.  I would
also prefer if you used CTest for running the test suites rather than
using CMake custom targets.  This is what CTest was designed to handle.

On 12/5/2016 8:38 AM, Michael Steinberg wrote:

Thank you Wayne,

I'd be really highly interested in getting unit tests sorted out for the
C++ part. Each time I write something without a set of tests for a
project of this size I feel miserable :( Is there anything I can help
with, sort out, think about?

Michael


Am 05.12.2016 um 14:19 schrieb Wayne Stambaugh:

On 12/4/2016 8:53 AM, Michael Steinberg wrote:

Am 12.09.2016 um 17:14 schrieb Wayne Stambaugh:

On 9/12/2016 11:04 AM, Tomasz Wlostowski wrote:

On 08.09.2016 18:49, Wayne Stambaugh wrote:

Hey Tom,

Here is the patch that fixes the linking as well.  I linked
against the
static libraries.  That shouldn't be an issue.


Hi Wayne,

Thanks for the patch. It looks like the config.h file is generated in
the build directory, not the source one. I was building in-tree so I
didn't notice the problem.

Concerning static linking, I would like to have an option (say,
KICAD_TESTS_USE_KIFACE_DLLL) to avoid it and link directly to the
.kiface DLL. This results in way faster linking times and omits
dependency calculations, which I find very annoying (especially when I
know I didn't change anything that would result in an incompatible DLL
binary).

Linking to the dynamic library in the pcbnew/ build path is
problematic.
On linux, you would have to run ldconfig, on windows you would
have set
the $PATH environment variable, and I believe osx also has some type of
dynamic library loader that would require configuration otherwise the
tests would fail because the os wont be able to find the dynamic
library.  That's why I statically linked it.  I would think that would
be acceptable for unit testing purposes.

Hello all,

what's the status on this? If I'm rewriting lib stuff I could just as
well go ahead and add unit tests for it. I couldn't find the "tests"
folder that would be added by the patch.

Michael


Michael,

The unit tests are in the qa folder.  As of right now there are only
some python tests using the python unit test framework which means any
code you write would have to be built into the python scripting support
to test it.  We have discussed using the boost unit test framework for
testing c++ code directly so that is an option as well.

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



___
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] [RFC] [PATCH] simple C++ tests

2016-12-05 Thread Michael Steinberg


Thank you Wayne,

I'd be really highly interested in getting unit tests sorted out for the 
C++ part. Each time I write something without a set of tests for a 
project of this size I feel miserable :( Is there anything I can help 
with, sort out, think about?


Michael


Am 05.12.2016 um 14:19 schrieb Wayne Stambaugh:

On 12/4/2016 8:53 AM, Michael Steinberg wrote:

Am 12.09.2016 um 17:14 schrieb Wayne Stambaugh:

On 9/12/2016 11:04 AM, Tomasz Wlostowski wrote:

On 08.09.2016 18:49, Wayne Stambaugh wrote:

Hey Tom,

Here is the patch that fixes the linking as well.  I linked against the
static libraries.  That shouldn't be an issue.


Hi Wayne,

Thanks for the patch. It looks like the config.h file is generated in
the build directory, not the source one. I was building in-tree so I
didn't notice the problem.

Concerning static linking, I would like to have an option (say,
KICAD_TESTS_USE_KIFACE_DLLL) to avoid it and link directly to the
.kiface DLL. This results in way faster linking times and omits
dependency calculations, which I find very annoying (especially when I
know I didn't change anything that would result in an incompatible DLL
binary).

Linking to the dynamic library in the pcbnew/ build path is problematic.
   On linux, you would have to run ldconfig, on windows you would have set
the $PATH environment variable, and I believe osx also has some type of
dynamic library loader that would require configuration otherwise the
tests would fail because the os wont be able to find the dynamic
library.  That's why I statically linked it.  I would think that would
be acceptable for unit testing purposes.

Hello all,

what's the status on this? If I'm rewriting lib stuff I could just as
well go ahead and add unit tests for it. I couldn't find the "tests"
folder that would be added by the patch.

Michael


Michael,

The unit tests are in the qa folder.  As of right now there are only
some python tests using the python unit test framework which means any
code you write would have to be built into the python scripting support
to test it.  We have discussed using the boost unit test framework for
testing c++ code directly so that is an option as well.

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] SYMBOL_LIB_TABLE throw()

2016-12-05 Thread Michael Steinberg


Hello,

SYMBOL_LIB_TABLE::Parse is declared with "throw()", yet it explicitly 
throws an exception. What was the original intent?


Michael


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

Re: [Kicad-developers] StrNumCmp




Be careful with floating points: a separator can be a point or a comma, and you 
don't know what
separator was used when creating a string.
Never expect the separator is always a point or always a comma.
You can find a mix of these 2 notations.

And generally speaking, a point or a comma inside a string with digits is not 
necessary a fp separator.

As I said previously, StrNumCmp in mainly intended to sort references in list.
Most of time, for a component value, you cannot know the meaning of separator
You can have 4,7K or 4.7K or 4K7 but also 7400,DIP14

Hello!
When not specifying this Simon-Extended-Numbers-Mode, it should do what 
the original StrNumCmp function was intended to do. I only added that 
flag because Simon asked for generalization, it may well be that those 
two should better stay independent. That would of course simplify the 
parse_number function immensely ;)


Michael

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

Re: [Kicad-developers] StrNumCmp




It is similar to a string comparison (for string sorting) but unlike the usual 
strncmp() or
strncasecmp() functions, when digits are encountered in a string, they are 
converted to a number and
this is the number value which is taken in account for comparison.

I've written my own back then for the pin table, factored out into
eeschema/pin_number.cpp. This should be merged with the other
implementations then in the same process, and possibly generalized
(there is special treatment of "V" as a decimal point if it is placed
between numbers, for example, that may not always be appropriate).

Okay, I came up with a solution for which I'm not so sure if it would be 
generally accepted: http://pastebin.com/Y7rVzHV1

It should compile as is.
The big part of that code is made off the class CONST_WX_STRING_VIEW, 
which does nothing more than encapsulate a pair of wxString iterators, 
dereferencing yields the beginning character, incrementing increments 
the begin iterator etc. like in "ranges". I found such a range helper 
immensely helpful for parsing generally, but it might be a bit bulky to 
include only for StrNumCmp.
Simon, I tried to mimic the behaviour of your function, see the below 
the comment "Gyros-Mode", I doubt that the float-parsing is particularly 
clever however. Feel free to drop me compatible code that I could use 
instead.


Cheers!
Michael


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

Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests



Am 12.09.2016 um 17:14 schrieb Wayne Stambaugh:


On 9/12/2016 11:04 AM, Tomasz Wlostowski wrote:

On 08.09.2016 18:49, Wayne Stambaugh wrote:

Hey Tom,

Here is the patch that fixes the linking as well.  I linked against the
static libraries.  That shouldn't be an issue.


Hi Wayne,

Thanks for the patch. It looks like the config.h file is generated in
the build directory, not the source one. I was building in-tree so I
didn't notice the problem.

Concerning static linking, I would like to have an option (say,
KICAD_TESTS_USE_KIFACE_DLLL) to avoid it and link directly to the
.kiface DLL. This results in way faster linking times and omits
dependency calculations, which I find very annoying (especially when I
know I didn't change anything that would result in an incompatible DLL
binary).

Linking to the dynamic library in the pcbnew/ build path is problematic.
  On linux, you would have to run ldconfig, on windows you would have set
the $PATH environment variable, and I believe osx also has some type of
dynamic library loader that would require configuration otherwise the
tests would fail because the os wont be able to find the dynamic
library.  That's why I statically linked it.  I would think that would
be acceptable for unit testing purposes.

Hello all,

what's the status on this? If I'm rewriting lib stuff I could just as 
well go ahead and add unit tests for it. I couldn't find the "tests" 
folder that would be added by the patch.


Michael

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

Re: [Kicad-developers] StrNumCmp



Am 04.12.2016 um 13:33 schrieb jp charras:
It is similar to a string comparison (for string sorting) but unlike 
the usual strncmp() or

strncasecmp() functions, when digits are encountered in a string, they are 
converted to a number and
this is the number value which is taken in account for comparison.

This is especially useful to sort component references or value.
For instance:
when the 2 strings U12 and U2 are compared by ASCII value:
In usual comparison (from ASCII value), U120 is sorted before U20
In StrNumCmp:
120 is read as a integer value
20  is read as a integer value
and comparisons are between U<120> and U<20> where <120> and <20> are integers, 
not chars.

and U120 is sorted after U20


Hello Jean-Pierre,

thank you for the information.
So a numeric character range is to be treated as one character position 
whose value its the parsed number, right?
Is the aLength parameter designed to mean raw character counts, or 
character/number positions? Would "U12" compare smaller to "U2" at 
aLength == 2?
Cases like "U12A4A3" vs. "U12A4A4" are also specified where the latter 
would compare "greater", yes?


Michael


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

[Kicad-developers] StrNumCmp


Hello all,

when doing other stuff I ran into one of a gazillion cases that can make 
StrNumCmp starting in common/string.cpp:214 crash. There are quite a few 
unchecked iterator dereferences, the aLength parameter is not correctly 
taken into account, etc.. The comment on the function's declaration is 
not enough specification for me to rewrite it properly. If somebody 
would come up with a spec for me I would happily rewrite the function.


Cheers!
Michael


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

Re: [Kicad-developers] Stable version 4.0.5

2016-11-12 Thread Michael Steinberg

Hi all,

1. Boost 1.61 compatibility and bugfix?
2. Release version string.

Should the release should include the boost 1.61 fix. It was discussed in:
[Kicad-developers] About Bug 1604841: Pcbnew crash at moving via, and
boost::context fixes to make it compatible with boost 1.61

And there is a patch in [1], although it does not explicitly state
where it is from, but it looks similar to [2] and [3]. With out the
patch in [1] I can not build it against boost 1.62 on archlinux.
[...]
[1]https://git.archlinux.org/svntogit/community.git/tree/trunk/boost-1.61.patch?h=packages/kicad
[2]https://git.launchpad.net/kicad/commit/?id=06d4894fdbeb00727cdcc667b8899ad73d8eb1c2
[3]https://git.launchpad.net/kicad/commit/?id=78bc3c65de6c03d19be9902327d08cd4d87c229c

Regarding patches 1-3:

I'm still here reading mostly and supporting those patches, just that
I've been busy finding a job and a project is going on too. So in short,
these three patches, although commited individually actually belong
together in the retrospective. Nothing has changed with regard to the
fact that the public interface of boost::context requires c++11
compilation beginning with boost version 1.61, that's why it was decided
to not apply them to stable back then.

The now-encapsulated-and-moved-to-detail parts of boost::context that
Kicad uses for boost versions < 1.61 are actually still there, so it
might be possible to use those, but it might also be the case that it's
not possible to hide the c++11 header parts from the compiler when using
them. Not even considering I think it would *really* not be a wise
decision to rely on implementation details, especially looking into the
future.

I think it would be best to just tell people they need to use a recent
compiler (and the according standard switch) if they also want to use a
recent boost and apply these patches to stable, iff there is a growing
demand/complain-rate. But I will also try to help/assist/... finding a
different solution, if it is in demand.

Cheers!
Michael

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

Re: [Kicad-developers] Boost 1.62.

2016-10-12 Thread Michael Steinberg

That is simply because CMake 3.6 does not yet know boost 1.62, this is 
no problem because none of our boost dependencies introduce indirect 
dependencies.


Michael


Am 12.10.2016 um 15:51 schrieb Wayne Stambaugh:

It appears that you have to do a clean build.  However, I missed some
cmake warnings about missing dependencies:

CMake Warning at
C:/msys64/mingw32/share/cmake-3.6/Modules/FindBoost.cmake:743 (message):
   Imported targets not available for Boost version 106200
Call Stack (most recent call first):
   C:/msys64/mingw32/share/cmake-3.6/Modules/FindBoost.cmake:842
(_Boost_COMPONENT_DEPENDENCIES)
   C:/msys64/mingw32/share/cmake-3.6/Modules/FindBoost.cmake:1395
(_Boost_MISSING_DEPENDENCIES)
   CMakeLists.txt:544 (find_package)


CMake Warning at
C:/msys64/mingw32/share/cmake-3.6/Modules/FindBoost.cmake:743 (message):
   Imported targets not available for Boost version 106200
Call Stack (most recent call first):
   C:/msys64/mingw32/share/cmake-3.6/Modules/FindBoost.cmake:842
(_Boost_COMPONENT_DEPENDENCIES)
   C:/msys64/mingw32/share/cmake-3.6/Modules/FindBoost.cmake:1395
(_Boost_MISSING_DEPENDENCIES)
   CMakeLists.txt:544 (find_package)

CMake still creates the make files.  Everything compiles and links
properly and seems to work just fine so I'm not sure if the msys2 folks
changed something with the boost package or it's actually an issue with
boost that causing FindBoost.cmake to complain.  None the less, you can
use boost 1.62 on msys2 to build kicad.

Cheers,

Wayne

On 10/11/2016 8:58 PM, Michael Steinberg wrote:

Can't reproduce on windows with msvc + 1.62 (tried that weeks ago with
an rc already). Might be an msys, mingw or gcc thing. Any hints to what
causes this?

Michael


Am 12.10.2016 um 02:54 schrieb Chris Pavlina:

And people argue with me when I say Boost is a piece of crap.

On Tue, Oct 11, 2016 at 07:38:59PM -0400, Wayne Stambaugh wrote:

Another boost version, another broken context switching build.  Has
anyone successfully built kicad against boost 1.62?  The msys2 project
just packaged 1.62 and kicad fails to build on windows.  If you haven't
upgraded yet, don't.  Otherwise you will to downgrade.  Hopefully this
saves someone some grief.  This is getting old. :(

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

___
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] Boost 1.62.

2016-10-11 Thread Michael Steinberg

Can't reproduce on windows with msvc + 1.62 (tried that weeks ago with 
an rc already). Might be an msys, mingw or gcc thing. Any hints to what 
causes this?


Michael


Am 12.10.2016 um 02:54 schrieb Chris Pavlina:

And people argue with me when I say Boost is a piece of crap.

On Tue, Oct 11, 2016 at 07:38:59PM -0400, Wayne Stambaugh wrote:

Another boost version, another broken context switching build.  Has
anyone successfully built kicad against boost 1.62?  The msys2 project
just packaged 1.62 and kicad fails to build on windows.  If you haven't
upgraded yet, don't.  Otherwise you will to downgrade.  Hopefully this
saves someone some grief.  This is getting old. :(

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] SWIG binding

2016-09-19 Thread Michael Steinberg


Hello Wayne, Torsten & All,


Am 19.09.2016 um 15:17 schrieb Wayne Stambaugh:

I'm going to make an executive decision here so this doesn't drag on.
In short, swig stays.  Any other python bindings would either be on top
of or along side current swig bindings.  Swig is a valid tool for
generating scripting language bindings.  Lots of other projects use it
with great success so it can't be all bad.  We already have a large
investment of time in the current swig bindings along with lots of
project and user scripts that use them.  I do not want to discard that
investment of time and effort.  If anyone feels so inclined to write
some other python interface, there cannot be namespace clashes with the
current python bindings.

On 9/19/2016 5:49 AM, "Torsten Hüter" wrote:

Hi Tom & Michael,
  
I'm using the scripting interface quite often and had never that much

trouble with it.
The currently missing std::unique_ptr is not an argument, it is still
possible to use it, see
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
  
I'm quite sure that in the future almost any C++ 11 features will be

supported by swig.
Pybind is - as you have written - generatorless, in my opinion this is
exactly the downside.
You have to write wrappers yourself, while with swig you're simply
including headers in the *.i files.
  


I'm fine with staying with SWIG (See I also added it in the points of 
possible options twice). But still I'm left with contradicting 
statements about the stability of the blobs the current SWIG headers 
spit out. While Wayne's main point is that we cannot break existing 
scripts, Thorsten says that is no problem at all. If refactoring and 
exporting it like usual is no problem, then I have nothing left to 
argument about, because the initial problem I was addressing was 
non-existant to begin with (I'd like that, because it means no work!). 
If that is not the case, just saying SWIG stays is fixing the 
technicality, but not the specified API concerns imho.


Michael

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

Re: [Kicad-developers] SWIG binding

2016-09-18 Thread Michael Steinberg


Hello all!

Am 17.09.2016 um 23:39 schrieb Cirilo Bernardo:



On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski 
> wrote:


[...]


I agree with all that as well. I think the best thing to do is create 
a PCB API

which provides C bindings and people can make whatever scripting
language API on top of that; this way there will be a much more uniform
scheme for everyone. I was thinking about this while working on the STEP
exporter but the more I looked at things, the bigger the job became.
Eventually I thought it would take me a year or even more hacking at it
part-time so I put it on the deferred list of things to do. Until we 
have such

an API, I think things will be a bit of a mess. On the other hand some
people want a scripting API now and can't wait for some part-time coder
to come up with something in a year or two.



So I conclude that we pretty much all agree it's a bad idea to export a 
rather unconstrained set of internals to python or any scripting. I 
think we also agree that we can't just drop the current state 
immediately. Beside these points I see a set of diverging technical 
strategies to implement it the right way (tm):


1.) Keep SWIG, wrap the output on the python side to a specified API
2.) Drop SWIG and interface with python.h ourselves without convenience 
libraries

3.) Drop SWIG, implement a C-API, write bindings in any language vs. C-API
4.) Drop SWIG, use compiler-based c++ bindings adhering the specified 
API (pybind11-like), using wrappers where necessary


What has not been mentioned for completeness:
5.) Keep SWIG, use a constrained export set possibly using wrappers to 
adhere the specified API


Anything missing from the list?

Of course every alternative takes a specified API for granted, where we 
haven none, yet. I cannot compare the techniques at the current point of 
time, since I simply have no experience creating a C-API for C++ code. 
Where some stuff seems obvious as how to get right, I need to think 
about technicalities of how to implement move-semantics, smart-pointers, 
etc.. I have some experience using techniques like pybind11 or luabind, 
where one doesn't have these problems, because C++ is not stripped away 
at the binding level. So I'll have to delve into it and play around 
creating a super-limited sample binding in every alternative just to 
come to a personal conclusion.
While the C-API seems like being the best solution technically, we'd 
need to develop the C-part and also convenience wrappers on the Python 
side just to be on par with the current state, right? Will there be 
enough developers with enough time to pull that off, I fear I doubt 
that, but as I said, I'll need to play around with this. It is however 
possible to create a binding vs. "the specified API" without taking this 
route, and it is also possible to switch the implementation technique 
later without changing the experienced binding semantics.
Just how large of a deprecation-timespan would you think is necessary to 
make such changes? I think there are "some" devs who are eager to go in 
and refactor quite some parts, but we simply cannot do this right now 
due to this problem. So we're pretty much in a state where we can only 
add stuff on top, right, where adding already means fixing it for the 
future, too?


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

Re: [Kicad-developers] SWIG binding

2016-09-16 Thread Michael Steinberg


Hello Wayne,


Yet.  I'm sure they are going to have to implement it at some point.
You can always write your own swig wrapper something like this:
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig

They had 5+ years to add support, they didn't. So I wouldn't count on it.

As some of you may or may not know, the new wxpython project phoenix is
using sip instead of swig so that in and of itself may put us in a
position where we have to change to sip.  I would rather wait and see
what shakes out with the new wxpython implementation rather than head
down a path that only has to be changed yet again.

And another break, will we support SWIG, SIP and an interop layer?

With this message I want to ask what is the common view whether it is
okay to have SWIG thumbscrew the project's source code, considering
there are alternative generators, and generatorless libraries like
pybind11. Of those alternatives I would *personally* prefer the latter,
as it is no black box and the binding generation is part of the normal
c++ source code.

Honestly, changing scripting language generators does not thrill me at
this point in the project.  It would most likely break all of the python
scripting work done thus far which would create a lot backlash.
It will only get worse as time is passing by building upon the current 
state.


I think we need
1) a specified python API
2) adapters that match the specified API to the source code
3) Helpers to generate the necessary binding from the API adapters. This 
can be done with the aid of libraries or manually.


It seems none of that is currently available, the current unspecified 
API holds the source code tight, with a generator that hinders 
refactoring to modern c++ style. So we only lose on both sides.


Michael



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

[Kicad-developers] SWIG binding

2016-09-16 Thread Michael Steinberg


Hello all,

when activating python bindings on my msvc build with a few refactor 
commits applied, it came to my attention that SWIG simply does not 
support std::unique_ptr.


With this message I want to ask what is the common view whether it is 
okay to have SWIG thumbscrew the project's source code, considering 
there are alternative generators, and generatorless libraries like 
pybind11. Of those alternatives I would *personally* prefer the latter, 
as it is no black box and the binding generation is part of the normal 
c++ source code.
There's been a discussion on the irc channel regardings this and also 
the dependency on having wx exported as well. So I thought the logical 
consequence would be to broaden the audience and move the discussion here.


Cheers!
Michael


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

Re: [Kicad-developers] "Multichannel signed distance field" font rendering

2016-09-13 Thread Michael Steinberg


Hello all!

Thank you very much for the feedback. As I understand the technique 
works well enough on many different hardware levels (I'm using it myself 
in an i5 iGPU), so that's good to know. I tweaked the character 
placement to get in accordance with what the truetype font specifies. 
Beside other issues, this fixes the reported GND baseline problem, still 
their bounding boxes are not bottom-aligned, but their baselines are. 
These changes were pushed to the sdf branch.
There are some issues left that I would call minor (some special chars 
show slight glitches), but I would think that should not be a 
showstopper for now, I will still eventually try to address them. So 
unless there are important issues left I would polish the codestyle and 
get in touch with Orson for inclusion?


The atlas tool is now available on Github with CMake support (thank you 
very much José!), so there should be no "blackbox"-problem remaining.


Cheers!
Michael

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

Re: [Kicad-developers] "Multichannel signed distance field" font rendering

2016-09-12 Thread Michael Steinberg

Hey,

thanks for noticing. That and more off by one errors I'm working on to
fix currently. As I said, not polished, rather proof-of-concept.

Michael

Am 12.09.2016 um 17:18 schrieb Bernhard Stegmaier:

Hi,

looks great!

One nitpicking question about the comparison screenshots:
It looks like the baselines of the three letters are not the same… “N” is
higher than “D”, “D” is higher than “G”.
It doesn’t look like this in the blurry version…
Where does this come from?

Regards,
Bernhard

On 10 Sep 2016, at 17:05, Michael Steinberg <michste...@gmail.com> wrote:

Hello there,

I've been working on trying to solve the blurred font issue in the OpenGL canvas. The current state
of the work can be found in my branch "sdf" (
https://code.launchpad.net/~decimad/kicad/+git/kicad/+ref/sdf ). It uses a technique called
"multichannel signed distance field" to recreate clear edges and corners in high zoom
situations. The code is not polished for commiting yet! A motivational comparison screenshot
before/after: https://s10.postimg.io/k00tnaax5/comparison.png

It would be great if brave members could test the branch to see if it runs well
on different hardware levels and if you are happy with the visuals.

To create the font texture atlas I wrote a command-line tool that is only set
up to build on windows currently (nothing platform dependent included, but it's
currently a visual studio project). I don't know if there's a space to upload
helper tools and if platform dependency would be accepted there. I could
probably upload it to a github project though.

Cheers!
Michael

Re: [Kicad-developers] "Multichannel signed distance field" font rendering

2016-09-11 Thread Michael Steinberg


Hello Jean-Pierre,

Could you tell us more about this command-line tool?
the tool uses the MSDF-library by Viktor Chlumsky, adds a rectangle bin 
packing algorithm (max rectangles global) to pack the texture atlas and 
outputs in the format that is used by KiCad currently. Given that, for 
full support (Better character placement, maybe even kerning?) I would 
like to cooperate with Orson to make the necessary changes to the 
current OpenGL string code.
I uploaded the Visual Studio project for the tool under MIT-License (the 
library by Viktor Chlumsky uses that license) to 
https://github.com/decimad/msdf-atlasgen .


Cheers!
Michael

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

[Kicad-developers] "Multichannel signed distance field" font rendering

2016-09-10 Thread Michael Steinberg


Hello there,

I've been working on trying to solve the blurred font issue in the 
OpenGL canvas. The current state of the work can be found in my branch 
"sdf" ( https://code.launchpad.net/~decimad/kicad/+git/kicad/+ref/sdf ). 
It uses a technique called "multichannel signed distance field" to 
recreate clear edges and corners in high zoom situations. The code is 
not polished for commiting yet! A motivational comparison screenshot 
before/after: https://s10.postimg.io/k00tnaax5/comparison.png


It would be great if brave members could test the branch to see if it 
runs well on different hardware levels and if you are happy with the 
visuals.


To create the font texture atlas I wrote a command-line tool that is 
only set up to build on windows currently (nothing platform dependent 
included, but it's currently a visual studio project). I don't know if 
there's a space to upload helper tools and if platform dependency would 
be accepted there. I could probably upload it to a github project though.


Cheers!
Michael


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

Re: [Kicad-developers] PNS router patches batch #1

2016-09-01 Thread Michael Steinberg


Hello

Oh, thank you for noticing. No that was purely my stupidity. :(

I created a new branch "pnsbranch" rebased on master without this 
problem. ( git clone -b pnsbranch https://git.launchpad.net/~decimad/kicad )


@Tom:
Its commit hashes will obviously not match the patch hashes anymore. 
Should I create a new patch set?


Michael

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

[Kicad-developers] PNS router experimental patches

2016-09-01 Thread Michael Steinberg


Hi all,
attached are experimental patches for the pns router. The intent is 
refactoring how revisions are handled and thereby improving the peak 
memory footprint on deep springback stacks considerably. Other 
advantages would include a self-contained spatial state without 
complicating interrelations between a set of nodes.
I'd be really grateful for anybody testing this, Chris was already to so 
kind to give it a run during his last session.


Cheers!
Michael
>From 16f4a4cc0c59a244defa49719de4a64ef9bdd702 Mon Sep 17 00:00:00 2001
From: decimad 
Date: Wed, 31 Aug 2016 22:44:00 +0200
Subject: [PATCH] Reimplement PNS::NODE revisioning by means of the the class
 PNS::REVISION

Many changes, still largely untested, this is no patch to be applied without further testing and fixing
---
 pcbnew/router/CMakeLists.txt  |   1 +
 pcbnew/router/length_tuner_tool.cpp   |   4 +-
 pcbnew/router/pns_diff_pair_placer.cpp|  98 +++
 pcbnew/router/pns_diff_pair_placer.h  |  13 +-
 pcbnew/router/pns_dp_meander_placer.cpp   |  42 +--
 pcbnew/router/pns_dp_meander_placer.h |  14 +-
 pcbnew/router/pns_dragger.cpp |  57 ++--
 pcbnew/router/pns_dragger.h   |   9 +-
 pcbnew/router/pns_index.cpp   | 133 +
 pcbnew/router/pns_index.h | 117 +---
 pcbnew/router/pns_kicad_iface.cpp |  12 +-
 pcbnew/router/pns_kicad_iface.h   |   4 +-
 pcbnew/router/pns_line.cpp|   8 +-
 pcbnew/router/pns_line_placer.cpp | 109 
 pcbnew/router/pns_line_placer.h   |  17 +-
 pcbnew/router/pns_meander_placer.cpp  |  46 ++--
 pcbnew/router/pns_meander_placer.h|  12 +-
 pcbnew/router/pns_meander_skew_placer.cpp |  11 +-
 pcbnew/router/pns_node.cpp| 437 ++
 pcbnew/router/pns_node.h  | 203 +-
 pcbnew/router/pns_placement_algo.h|  11 +-
 pcbnew/router/pns_revision.cpp|  34 ++-
 pcbnew/router/pns_revision.h  |  19 +-
 pcbnew/router/pns_router.cpp  |  60 ++--
 pcbnew/router/pns_router.h|  22 +-
 pcbnew/router/pns_shove.cpp   | 161 ++-
 pcbnew/router/pns_shove.h |   7 +-
 pcbnew/router/pns_tool_base.cpp   |   6 +-
 pcbnew/router/pns_topology.cpp|   8 +-
 pcbnew/router/router_tool.cpp |   8 +-
 30 files changed, 883 insertions(+), 800 deletions(-)
 create mode 100644 pcbnew/router/pns_index.cpp

diff --git a/pcbnew/router/CMakeLists.txt b/pcbnew/router/CMakeLists.txt
index 12de287..776476e 100644
--- a/pcbnew/router/CMakeLists.txt
+++ b/pcbnew/router/CMakeLists.txt
@@ -28,6 +28,7 @@ set( PCBNEW_PNS_SRCS
 pns_meander_placer_base.cpp
 pns_meander_skew_placer.cpp
 pns_revision.cpp
+	pns_index.cpp
 pns_node.cpp
 pns_optimizer.cpp
 pns_router.cpp
diff --git a/pcbnew/router/length_tuner_tool.cpp b/pcbnew/router/length_tuner_tool.cpp
index e7cc806..b3ae89c 100644
--- a/pcbnew/router/length_tuner_tool.cpp
+++ b/pcbnew/router/length_tuner_tool.cpp
@@ -196,12 +196,12 @@ void LENGTH_TUNER_TOOL::performTuning()
 }
 else if( evt->IsClick( BUT_LEFT ) )
 {
-if( m_router->FixRoute( evt->Position(), NULL ) )
+if( m_router->CommitRoute( evt->Position(), NULL ) )
 break;
 }
 else if( evt->IsAction( _EndTuning ) )
 {
-if( m_router->FixRoute( end, NULL ) )
+if( m_router->CommitRoute( end, NULL ) )
 break;
 }
 else if( evt->IsAction( _AmplDecrease ) )
diff --git a/pcbnew/router/pns_diff_pair_placer.cpp b/pcbnew/router/pns_diff_pair_placer.cpp
index 7c05ddc..0adc06f 100644
--- a/pcbnew/router/pns_diff_pair_placer.cpp
+++ b/pcbnew/router/pns_diff_pair_placer.cpp
@@ -46,10 +46,8 @@ DIFF_PAIR_PLACER::DIFF_PAIR_PLACER( ROUTER* aRouter ) :
 m_netP = 0;
 m_netN = 0;
 m_iteration = 0;
-m_world = NULL;
-m_shove = NULL;
-m_currentNode = NULL;
-m_lastNode = NULL;
+m_shove = nullptr;
+m_node  = nullptr;
 m_placingVia = false;
 m_viaDiameter = 0;
 m_viaDrill = 0;
@@ -73,7 +71,7 @@ DIFF_PAIR_PLACER::~DIFF_PAIR_PLACER()
 
 void DIFF_PAIR_PLACER::setWorld( NODE* aWorld )
 {
-m_world = aWorld;
+m_node = aWorld;
 }
 
 const VIA DIFF_PAIR_PLACER::makeVia( const VECTOR2I& aP, int aNet )
@@ -112,8 +110,8 @@ bool DIFF_PAIR_PLACER::rhMarkObstacles( const VECTOR2I& aP )
 if( !routeHead( aP ) )
 return false;
 
-bool collP = static_cast( m_currentNode->CheckColliding( _currentTrace.PLine() ) );
-bool collN = static_cast( m_currentNode->CheckColliding( _currentTrace.NLine() ) );
+bool collP = static_cast( m_node->CheckColliding( _currentTrace.PLine() ) );
+bool collN = static_cast( m_node->CheckColliding( _currentTrace.NLine() ) );
 
 m_fitOk = !( collP || collN ) ;
 
@@ -148,7

Re: [Kicad-developers] Blured text on OpenGL

2016-08-30 Thread Michael Steinberg


Hey,

I think a signed distance field font rendering is a very good compromise 
between speed and quality. I had suggested that earlier, but it seemed 
others would not be as convinced...


Michael

Am 30.08.2016 um 20:41 schrieb Mário Luzeiro:

Hi Lorenzo,

I was aware of that change / improvement,
but for some reason (maybe because I changed for another laptop/screen) it was 
more noticeable for me theses days.

Sorry for the noise ;)

Mario

From: Kicad-developers 
[kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of 
Lorenzo Marcantonio [lomar...@tin.it]
Sent: 30 August 2016 19:13
To: Kicad Developers
Subject: Re: [Kicad-developers] Blured text on OpenGL

On Tue, Aug 30, 2016 at 04:11:57PM +, Mário Luzeiro wrote:

Hi all,

I had a feeling yesterday, on the openGL mode that looks different: low-res 
blurred interpolated font.
I may was a bit blurred myself, but I found other users complaining about the 
same:

https://forum.kicad.info/t/switch-of-blurring-of-pad-text-in-new-opengl-engine/3837

Any one noticed? Any changes that can causing this?

Probably it's the new bitmapped font... consumer GPUs are optimized for
munching textures, not vectors, so on very busy board the vectorial font
was too slow to handle. Now is done with quads (4 vertices) AFAIK, one
for each character. In comparison the vector text need to send to the
GPU something like 6 vertices for each line segment in the font, more or
less an order of magnitude of difference!

The cons is that now since the font is bitmapped the resolution is
finite and what you call blur is the bilinear filtering of the character
images...

This should explain the reason, for the details maybe the developers
that did it have more informations.

--
Lorenzo Marcantonio

___
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] RAII for the PNS_ROUTER

2016-08-04 Thread Michael Steinberg


Hello all,

up to the most current version of the router code I could get hold of, 
it is leaking much memory (eventually resulting in std::bad_alloc) on 
iterative stuff like dragging. I was also made aware of bugs like 
"https://bugs.launchpad.net/kicad/+bug/1553804;. Now this stuff is a 
complex beast, and I'm nowhere any near fluent with it. But it's also 
very interesting to me algorithm-wise. I believe that the original devs 
at this point are the only ones that could really spot leaks and 
segfaults in it with a reasonable time effort, might be wrong though.


It is my experience though, that such bugs usually surface while 
transforming source code to a more rigid RAII source-style with clear 
and enforced ownership. I would be totally willing to fight myself 
through the sources, trying to transform it without change in behaviour, 
but getting that right will probably reveal misconceptions on my side 
and it will also touch a huge amount of lines in the end and take quite 
a while. I might even feel forced to ask people for support.


So I don't want to rush ahead and get lost in details not being seen 
anymore, before I don't know if there's general interest walking such a 
route and nobody is actually addressing this currently (my time does 
have some tiny amount of rest-value to me ;)).


What are your thoughts?

Hope all goes well for a spedy 4.0.3! It's great to see how the wheels turn.

Michael


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

Re: [Kicad-developers] About Bug 1604841: Pcbnew crash at moving via, and boost::context fixes to make it compatible with boost 1.61

2016-08-01 Thread Michael Steinberg


Hi there!

Thank you for investigating the problem. After reading your explanation,
I am not completely sure the bug has existed before the boost-1.61
patch. In the mentioned patch, the order of transitions.clear() and
COROUTINE constructor has been reversed [1]. Do you think it could cause
the bug? If so, then the stable branch never had this bug and as such
should be safe.

I am still unable to recreate the problem, so could you simply try to
revert the order again to see if it solves the issue?

It's the "st->Push()" operation that eventually calls 
"st->transitions.clear()". When writing the 1.61 patch I must have run 
into 50% of the problem and changed the order of the *explicit* 
st->transistions.clear(), not realizing that Push does it as well. So 
before my patch it might have been cleared twice before dereferencing a 
referenced element. I don't suspect this to have caused any issues, 
since clear usually only calls the destructors and keeps the memory 
reserved, which then would silently work with the implementation of 
DELEGATE.


Michael

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

Re: [Kicad-developers] About Bug 1604841: Pcbnew crash at moving via, and boost::context fixes to make it compatible with boost 1.61

2016-07-31 Thread Michael Steinberg


Hey,

pinpointing the problem proved really difficult, I didn't expect it 
where it was...
This bug existed before my 1.61-patch and did not surface because 
DELEGATE would not clear its content on destruction. See the attached patch.


That being said, I'm not yet 100% sure the macro'ed code for old boost 
versions is 100% correct. During my bug search I refactored and checked 
that part for [1.54, 1.66) since I suspected my stuff being the cause. 
I'll check with 1.56 later, need to catch some sleep first...


Michael
>From 8d0b28ead9133c3e808f06d914463449fd6f08e0 Mon Sep 17 00:00:00 2001
From: decimad 
Date: Mon, 1 Aug 2016 05:11:29 +0200
Subject: [PATCH] Fix tool crash with "reentrant" states.

---
 common/tool/tool_manager.cpp | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/common/tool/tool_manager.cpp b/common/tool/tool_manager.cpp
index 0ec1882..46594da 100644
--- a/common/tool/tool_manager.cpp
+++ b/common/tool/tool_manager.cpp
@@ -532,11 +532,18 @@ void TOOL_MANAGER::dispatchInternal( const TOOL_EVENT& aEvent )
 {
 if( tr.first.Matches( aEvent ) )
 {
+// st->Push() might clear the transitions-list, copy the transition function
+// early. Can move the function since the transition list will be cleared.
+using coroutine_type = COROUTINE< int, const TOOL_EVENT& >;
+std::unique_ptr< coroutine_type > next_cofunc( 
+new coroutine_type( std::move( tr.second ) )
+);
+
 // if there is already a context, then store it
 if( st->cofunc )
 st->Push();
 
-st->cofunc = new COROUTINE( tr.second );
+st->cofunc = next_cofunc.release();
 
 // as the state changes, the transition table has to be set up again
 st->transitions.clear();
-- 
2.9.0.windows.1

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

Re: [Kicad-developers] About Bug 1604841: Pcbnew crash at moving via, and boost::context fixes to make it compatible with boost 1.61

2016-07-31 Thread Michael Steinberg


Hello,

of course! So I'm not to sure if 1.60 is supposed to work on windows, I 
think I read it might be bugged for that specific version and platform 
combination. I will investigate that. However the intent was to not 
change anything behaviorial for boost version < 1.61, so if a 
1.54-version build is not working after that patch, then the macro'ed 
code is wrong. I apologize sincerely and investigate subtleties tonight.


Michael


Am 31.07.2016 um 17:14 schrieb jp charras:

Orson, Michael:

May I ask you to have a look into this bug:
In gal mode, Pcbnew crashes when try to drag a via or a track.

To reproduce that, set the interactive Router Setting/ Mouse drag behavior to 
interactive drag.
(In move mode, no crash)

I am asking you to have a look into this issue because the version rev 6964 
does not crash.
The rev 6965 is the  boost::context fixes to make it compatible with boost 1.61.

I did not tested the rev 6965 but I am afraid this bug is related to this fix.

The crash occurs both on my Windows install (boost 1.60) and on my Linux 
install (boost 1.54)

Unfortunately the back trace is not useful, but it shows the crash is related 
to changes in rev 6965.

If it is really due to the rev 6965, this is a serious issue.

Thanks.




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

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


Hello Wayne,

Am 05.07.2016 um 17:14 schrieb Wayne Stambaugh:

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


Michael


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

[Kicad-developers] [PATCH proposal v2] Fix bitset access outside boundaries in LSET::FmtHex()

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

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

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

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

[Kicad-developers] [PATCH proposal] Fix bitset access outside boundaries in LSET::FmtHex()

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


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

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

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

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

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

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

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

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

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

[Kicad-developers] git stable mirror


Hey,

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


Michael


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

[Kicad-developers] LIB_PART weak_ptr-technique


Hello,

in anticipation of the eeschema rework I'm looking through the source 
base to get a feeling for the current data model. A year or two ago I 
filed a bug report regarding the "weak_ptr"-technique that LIB_PART is 
using.

The offending line reads:

PART_SPTR   m_me;   ///< 
http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/sp_techniques.html#weak_without_shared


where PART_SPTR is defined as "std::shared_ptr". The m_me is 
initialized with "this" and a null_deleter, which does nothing when 
m_me's lifetime ends, ie. it does not delete the pointee-object as 
opposed to default behaviour of shared_ptrs. The commented technique 
describes a usage pattern, where a !!!weak_ptr!!! to the object is 
handed out from a member function. That way, the handed out weak_ptrs 
get invalidated when the lifetime of m_me ends. However, a valid 
weak_ptr can always be promoted to a shared_ptr, which results in a 
shared_ptr to the object which does not keep the pointee-object alive 
(which actually breaks normal assumptions one has about holding a 
shared_ptr to an object)! So this described technique implicitly needs 
the user to _not_ store promoted shared_ptrs after temporary promotion 
from the weak_ptr, and even then this pattern totally falls apart once 
multithreading kicks in. On top of that, the implementation in LIB_PART 
does not return a weak_ptr, it returns the shared_ptr, rendering the 
technique completely void unless client code drops the shared_ptr in 
favor of a weak_ptr.


To make it a bit clearer, following is some source code...

== source snip ===
#include 
#include 

struct null_deleter {
template< typename T >
void operator()(T*) {}
};

struct weak_ptr_me {
weak_ptr_me()
: me_( this, null_deleter() ), pointer_(_member_)
{}

~weak_ptr_me() {
pointer_ = nullptr;
}

std::shared_ptr< weak_ptr_me > me_;

std::shared_ptr< weak_ptr_me > get_me() { return me_; }

void funky() {
// need pointer access to avoid not crashing by luck
*pointer_ = 4;
std::cout << this << ": funky me!" << std::endl;
}

int* pointer_;
int some_member_;
};


int main()
{
std::shared_ptr< weak_ptr_me > ptr;

{
weak_ptr_me* me = new weak_ptr_me();
me->funky();
ptr = me->get_me();
delete me;
}

if (ptr) {
// even though ptr thinks the object is alive, it is really not.
ptr->funky();
}

return 0;
}

=== source snip =

...which will certainly result in an access violation. I thought I might 
clarify this but it will hopefully be gone soon anyways.


Cheers!
Michael


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

[Kicad-developers] [PATCH]v3 Fix memory leaks with improper wxBaseConfig* usage (model ownership and ownership-transfer with std::unique_ptr)

Finally I catched up. Attached v3 of the patch, the auiManager part is 
removed. Sorry for misinterpreting the comments.


Michael
>From 46886bcccbbd4d99faaec9f374a1a5d1d5413c95 Mon Sep 17 00:00:00 2001
From: decimad 
Date: Tue, 5 Jul 2016 02:31:04 +0200
Subject: [PATCH] Fix memory leaks with improper wxBaseConfig* usage (model
 ownership and ownership-transfer with std::unique_ptr)

---
 bitmap2component/bitmap2cmp_gui.cpp |  9 ++---
 common/bin_mod.cpp  | 12 
 common/common.cpp   |  9 +
 common/hotkeys_basic.cpp|  6 ++
 common/pgm_base.cpp | 11 +++
 include/bin_mod.h   | 13 +++--
 include/common.h|  7 ---
 include/kiface_i.h  |  4 ++--
 include/pgm_base.h  | 11 +++
 include/wxstruct.h  |  4 ++--
 kicad/pgm_kicad.h   |  4 ++--
 pcb_calculator/pcb_calculator_frame.cpp |  8 
 12 files changed, 52 insertions(+), 46 deletions(-)

diff --git a/bitmap2component/bitmap2cmp_gui.cpp b/bitmap2component/bitmap2cmp_gui.cpp
index 99ad647..1eb3f53 100644
--- a/bitmap2component/bitmap2cmp_gui.cpp
+++ b/bitmap2component/bitmap2cmp_gui.cpp
@@ -2,7 +2,7 @@
  * This program source code file is part of KICAD, a free EDA CAD application.
  *
  * Copyright (C) 1992-2010 jean-pierre.charras
- * Copyright (C) 1992-2015 Kicad Developers, see change_log.txt for contributors.
+ * Copyright (C) 1992-2016 Kicad Developers, see authors.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -80,7 +80,8 @@ private:
 wxStringm_ConvertedFileName;
 wxSize  m_frameSize;
 wxPoint m_framePos;
-wxConfigBase*   m_config;
+
+std::unique_ptr< wxConfigBase > m_config;
 
 public:
 BM2CMP_FRAME( KIWAY* aKiway, wxWindow* aParent );
@@ -206,6 +207,7 @@ BM2CMP_FRAME::BM2CMP_FRAME( KIWAY* aKiway, wxWindow* aParent ) :
 
 BM2CMP_FRAME::~BM2CMP_FRAME()
 {
+/// @todo Should the config really not be written if BM2CMP is iconized?
 if( !m_config || IsIconized() )
 return;
 
@@ -223,7 +225,8 @@ BM2CMP_FRAME::~BM2CMP_FRAME()
 m_config->Write( KEYWORD_LAST_FORMAT,  m_radioBoxFormat->GetSelection() );
 m_config->Write( KEYWORD_LAST_MODLAYER,  m_radio_PCBLayer->GetSelection() );
 
-delete m_config;
+m_config->Flush();
+m_config.reset();
 
 /* This needed for OSX: avoids further OnDraw processing after this
  * destructor and before the native window is destroyed
diff --git a/common/bin_mod.cpp b/common/bin_mod.cpp
index 116bc20..55edb35 100644
--- a/common/bin_mod.cpp
+++ b/common/bin_mod.cpp
@@ -2,7 +2,7 @@
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
  * Copyright (C) 2014 CERN
- * Copyright (C) 2014 KiCad Developers, see CHANGELOG.TXT for contributors.
+ * Copyright (C) 2014-2016 KiCad Developers, see CHANGELOG.TXT for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -27,8 +27,7 @@
 
 
 BIN_MOD::BIN_MOD( const char* aName ) :
-m_name( aName ),
-m_config( 0 )
+m_name( aName )
 {
 }
 
@@ -55,11 +54,8 @@ void BIN_MOD::End()
 if( m_config )
 {
 m_history.Save( *m_config );
-
-// Deleting a wxConfigBase writes its contents to disk if changed.
-// Might be NULL if called twice, in which case nothing happens.
-delete m_config;
-m_config = 0;
+m_config->Flush();
+m_config.reset();
 }
 }
 
diff --git a/common/common.cpp b/common/common.cpp
index 976e419..5f6cac0 100644
--- a/common/common.cpp
+++ b/common/common.cpp
@@ -3,7 +3,7 @@
  *
  * Copyright (C) 2014-2015 Jean-Pierre Charras, jp.charras at wanadoo.fr
  * Copyright (C) 2008-2015 Wayne Stambaugh 
- * Copyright (C) 1992-2015 KiCad Developers, see AUTHORS.txt for contributors.
+ * Copyright (C) 1992-2016 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -300,15 +300,16 @@ double RoundTo0( double x, double precision )
 }
 
 
-wxConfigBase* GetNewConfig( const wxString& aProgName )
+std::unique_ptr< wxConfigBase > GetNewConfig( const wxString& aProgName )
 {
 wxConfigBase* cfg = 0;
 wxFileName configname;
 configname.AssignDir( GetKicadConfigPath() );
 configname.SetFullName( aProgName );
 
-cfg = new wxFileConfig( wxT( "" ), wxT( "" ), configname.GetFullPath() );
-return cfg;
+return std::unique_ptr< wxConfigBase >(
+new wxFileConfig( wxT(""), wxT(""), configname.GetFullPath() )
+);
 }
 
 wxString GetKicadLockFilePath()

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

I was made aware that MinGW's implementation of std::chrono might be 
lacking, but my testbed is not including that yet, so I cannot 
double-check the implementation. Please see this as a motivation to hold 
the patch back or check MinGW. I'm sorry for the noise.


Michael


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

[Kicad-developers] [PATCH] remove_boost_thread_dependency.patch


Please excuse my stupidity #2.

Remove dependency on boost::thread.

>From b7e21ab681ba1ba27fb14c615838e7368f8eb58e Mon Sep 17 00:00:00 2001
From: decimad 
Date: Sat, 2 Jul 2016 04:37:40 +0200
Subject: [PATCH] remove boost::thread dependency

---
 CMakeLists.txt| 2 +-
 common/footprint_info.cpp | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index d915d8b..15b8d4c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -482,7 +482,7 @@ find_package( Cairo 1.8.8 REQUIRED )
 #
 # Note: Prior to Boost 1.59, the Boost context library is not built when compiling on windows
 #   with GCC.  You must patch the Boost sources.
-find_package( Boost 1.54.0 REQUIRED COMPONENTS context system thread )
+find_package( Boost 1.54.0 REQUIRED COMPONENTS context system )
 
 # Include MinGW resource compiler.
 include( MinGWResourceCompiler )
diff --git a/common/footprint_info.cpp b/common/footprint_info.cpp
index dab09cf..690f0bf 100644
--- a/common/footprint_info.cpp
+++ b/common/footprint_info.cpp
@@ -50,7 +50,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 
@@ -213,7 +213,7 @@ bool FOOTPRINT_LIST::ReadFootprintFiles( FP_LIB_TABLE* aTable, const wxString* a
 LOCALE_IO   top_most_nesting;
 
 // Something which will not invoke a thread copy constructor, one of many ways obviously:
-typedef boost::ptr_vector< boost::thread >  MYTHREADS;
+typedef std::vector< std::thread >  MYTHREADS;
 
 MYTHREADS threads;
 
@@ -234,7 +234,7 @@ bool FOOTPRINT_LIST::ReadFootprintFiles( FP_LIB_TABLE* aTable, const wxString* a
 else
 {
 // Delegate the job to a temporary thread created here.
-threads.push_back( new boost::thread( _LIST::loader_job,
+threads.push_back( std::thread( _LIST::loader_job,
 this, [i], jobz ) );
 }
 
-- 
2.9.0.windows.1

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

[Kicad-developers] [PATCH] refactor_profile.patch


Please excuse my stupidity.

Refactor profile code to use std::chrono instead of posix extensions.
>From ddfcfece2ff1e8a7eb9d0f75806dce0da3196381 Mon Sep 17 00:00:00 2001
From: decimad 
Date: Sat, 2 Jul 2016 04:38:16 +0200
Subject: [PATCH] refactor profiling code to use std::chrono instead of posix
 functions

---
 include/profile.h | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/include/profile.h b/include/profile.h
index acf9166..926fa87 100644
--- a/include/profile.h
+++ b/include/profile.h
@@ -30,20 +30,18 @@
 #ifndef __TPROFILE_H
 #define __TPROFILE_H
 
-#include 
-#include 
+#include 
+
+using profile_clock = std::chrono::high_resolution_clock;
 
 /**
  * Function get_tics
  * Returns the number of microseconds that have elapsed since the system was started.
  * @return uint64_t Number of microseconds.
  */
-static inline uint64_t get_tics()
+static inline profile_clock::time_point get_tics()
 {
-struct timeval tv;
-gettimeofday( , NULL );
-
-return (uint64_t) tv.tv_sec * 100ULL + (uint64_t) tv.tv_usec;
+return profile_clock::now();
 }
 
 /**
@@ -51,16 +49,16 @@ static inline uint64_t get_tics()
  */
 struct prof_counter
 {
-uint64_t start, end; // Stored timer value
+profile_clock::time_point start, end; // Stored timer value
 
 uint64_t usecs() const
 {
-return end - start;
+return std::chrono::duration_cast( end - start ).count();
 }
 
 float msecs() const
 {
-return ( end - start ) / 1000.0;
+return std::chrono::duration_cast>( end - start ).count();
 }
 };
 
-- 
2.9.0.windows.1

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

[Kicad-developers] [patch] refactor_profile.patch

This patch reworks the profiling code in terms of std::chrono instead of 
relying on posix extensions.
0001-fix-overlength-string-literals.patch
0002-fix-for-msvc-only-supporting-OpenMP-v2.5.patch
0003-fix-object-slicing-bug-introduced-by-the-clone-seman.patch
0004-fix-include-directory-variable.patch
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] remove_boost_thread_dependency.patch


This patch removes the dependency on boost::thread.
0001-refactor-profiling-code-to-use-std-chrono-instead-of.patch
0002-fix-overlength-string-literals.patch
0003-fix-for-msvc-only-supporting-OpenMP-v2.5.patch
0004-fix-object-slicing-bug-introduced-by-the-clone-seman.patch
0005-fix-include-directory-variable.patch
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] fix object slicing bug introduced by the clone semantics of boost::ptr_vector (substitute by vector of unique_ptr)

2016-07-02 Thread Michael Steinberg


Hey,

attached a fix to remove object slicing issues.

I'm sorry that my other patch is delaying, I switched over to git and 
need to get going again (running into a few kicad crashes due to 
msvc-debug libraries being very thorough).


Michael

>From 326cf3de948b4def16542ffda3f930a0ee618088 Mon Sep 17 00:00:00 2001
From: decimad 
Date: Sat, 2 Jul 2016 15:56:56 +0200
Subject: [PATCH] fix object slicing bug introduced by the clone semantics of
 boost::ptr_vector (substitute by vector of unique_ptr)

---
 common/config_params.cpp   | 46 -
 cvpcb/cfg.cpp  |  6 ++--
 eeschema/class_library.cpp |  4 +--
 eeschema/eeschema.cpp  |  4 +--
 eeschema/eeschema_config.cpp   | 32 +-
 gerbview/gerbview_config.cpp   | 14 
 include/config_params.h|  9 ++---
 include/project.h  |  8 +++--
 pagelayout_editor/pl_editor_config.cpp |  3 +-
 pcbnew/class_board_design_settings.cpp | 24 ++---
 pcbnew/class_pad.cpp   |  8 ++---
 pcbnew/modeditoptions.cpp  | 36 ++--
 pcbnew/pcbnew_config.cpp   | 62 +-
 13 files changed, 129 insertions(+), 127 deletions(-)

diff --git a/common/config_params.cpp b/common/config_params.cpp
index 9737e8e..c1603d9 100644
--- a/common/config_params.cpp
+++ b/common/config_params.cpp
@@ -3,7 +3,7 @@
  *
  * Copyright (C) 2004 Jean-Pierre Charras, jaen-pierre.char...@gipsa-lab.inpg.com
  * Copyright (C) 2008-2011 Wayne Stambaugh 
- * Copyright (C) 1992-2011 KiCad Developers, see AUTHORS.txt for contributors.
+ * Copyright (C) 1992-2016 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -43,17 +43,17 @@ void wxConfigLoadParams( wxConfigBase* aCfg,
 {
 wxASSERT( aCfg );
 
-for( const PARAM_CFG_BASE& param : aList )
+for( const std::unique_ptr< PARAM_CFG_BASE >& param : aList )
 {
-if( !!param.m_Group )
-aCfg->SetPath( param.m_Group );
+if( !!param->m_Group )
+aCfg->SetPath( param->m_Group );
 else
 aCfg->SetPath( aGroup );
 
-if( param.m_Setup )
+if( param->m_Setup )
 continue;
 
-param.ReadParam( aCfg );
+param->ReadParam( aCfg );
 }
 }
 
@@ -62,12 +62,12 @@ void wxConfigLoadSetups( wxConfigBase* aCfg, const PARAM_CFG_ARRAY& aList )
 {
 wxASSERT( aCfg );
 
-for( const PARAM_CFG_BASE& param : aList )
+for( const std::unique_ptr< PARAM_CFG_BASE >& param : aList )
 {
-if( !param.m_Setup )
+if( !param->m_Setup )
 continue;
 
-param.ReadParam( aCfg );
+param->ReadParam( aCfg );
 }
 }
 
@@ -77,24 +77,24 @@ void wxConfigSaveParams( wxConfigBase* aCfg,
 {
 wxASSERT( aCfg );
 
-for( const PARAM_CFG_BASE& param : aList )
+for( const std::unique_ptr< PARAM_CFG_BASE >& param : aList )
 {
-if( !!param.m_Group )
-aCfg->SetPath( param.m_Group );
+if( !!param->m_Group )
+aCfg->SetPath( param->m_Group );
 else
 aCfg->SetPath( aGroup );
 
-if( param.m_Setup )
+if( param->m_Setup )
 continue;
 
-if( param.m_Type == PARAM_COMMAND_ERASE )   // Erase all data
+if( param->m_Type == PARAM_COMMAND_ERASE )   // Erase all data
 {
-if( !!param.m_Ident )
-aCfg->DeleteGroup( param.m_Ident );
+if( !!param->m_Ident )
+aCfg->DeleteGroup( param->m_Ident );
 }
 else
 {
-param.SaveParam( aCfg );
+param->SaveParam( aCfg );
 }
 }
 }
@@ -104,19 +104,19 @@ void wxConfigSaveSetups( wxConfigBase* aCfg, const PARAM_CFG_ARRAY& aList )
 {
 wxASSERT( aCfg );
 
-for( const PARAM_CFG_BASE& param : aList )
+for( const std::unique_ptr< PARAM_CFG_BASE >& param : aList )
 {
-if( !param.m_Setup )
+if( !param->m_Setup )
 continue;
 
-if( param.m_Type == PARAM_COMMAND_ERASE )   // Erase all data
+if( param->m_Type == PARAM_COMMAND_ERASE )   // Erase all data
 {
-if( !!param.m_Ident )
-aCfg->DeleteGroup( param.m_Ident );
+if( !!param->m_Ident )
+aCfg->DeleteGroup( param->m_Ident );
 }
 else
 {
-param.SaveParam( aCfg );
+param->SaveParam( aCfg );
 }
 }
 }
diff --git a/cvpcb/cfg.cpp b/cvpcb/cfg.cpp
index fe80064..e57a93a 100644
--- a/cvpcb/cfg.cpp
+++ b/cvpcb/cfg.cpp
@@ -2,7 +2,7 @@
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
  * Copyright (C) 2015 Jean-Pierre

[Kicad-developers] [PATCH]v2 Fix memory leaks with improper wxBaseConfig* usage (model ownership and ownership-transfer with std::unique_ptr)


Hello,
I removed the "auto" usage, added @todo's and tried to comply with the 
coding style. If there's anything noncompliant left I'd appreciate a 
pointer!


Michael
=== modified file 'bitmap2component/bitmap2cmp_gui.cpp'
--- bitmap2component/bitmap2cmp_gui.cpp	2016-06-08 06:32:01 +
+++ bitmap2component/bitmap2cmp_gui.cpp	2016-06-28 21:33:44 +
@@ -2,7 +2,7 @@
  * This program source code file is part of KICAD, a free EDA CAD application.
  *
  * Copyright (C) 1992-2010 jean-pierre.charras
- * Copyright (C) 1992-2015 Kicad Developers, see change_log.txt for contributors.
+ * Copyright (C) 1992-2016 Kicad Developers, see authors.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -80,7 +80,8 @@
 wxStringm_ConvertedFileName;
 wxSize  m_frameSize;
 wxPoint m_framePos;
-wxConfigBase*   m_config;
+
+std::unique_ptr< wxConfigBase > m_config;
 
 public:
 BM2CMP_FRAME( KIWAY* aKiway, wxWindow* aParent );
@@ -206,6 +207,7 @@
 
 BM2CMP_FRAME::~BM2CMP_FRAME()
 {
+/// @todo Should the config really not be written if BM2CMP is iconized?
 if( !m_config || IsIconized() )
 return;
 
@@ -223,7 +225,8 @@
 m_config->Write( KEYWORD_LAST_FORMAT,  m_radioBoxFormat->GetSelection() );
 m_config->Write( KEYWORD_LAST_MODLAYER,  m_radio_PCBLayer->GetSelection() );
 
-delete m_config;
+m_config->Flush();
+m_config.reset();
 
 /* This needed for OSX: avoids further OnDraw processing after this
  * destructor and before the native window is destroyed

=== modified file 'common/bin_mod.cpp'
--- common/bin_mod.cpp	2016-01-12 15:35:27 +
+++ common/bin_mod.cpp	2016-06-28 21:23:20 +
@@ -2,7 +2,7 @@
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
  * Copyright (C) 2014 CERN
- * Copyright (C) 2014 KiCad Developers, see CHANGELOG.TXT for contributors.
+ * Copyright (C) 2014-2016 KiCad Developers, see CHANGELOG.TXT for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -27,8 +27,7 @@
 
 
 BIN_MOD::BIN_MOD( const char* aName ) :
-m_name( aName ),
-m_config( 0 )
+m_name( aName )
 {
 }
 
@@ -55,11 +54,8 @@
 if( m_config )
 {
 m_history.Save( *m_config );
-
-// Deleting a wxConfigBase writes its contents to disk if changed.
-// Might be NULL if called twice, in which case nothing happens.
-delete m_config;
-m_config = 0;
+m_config->Flush();
+m_config.reset();
 }
 }
 

=== modified file 'common/common.cpp'
--- common/common.cpp	2016-05-28 16:46:22 +
+++ common/common.cpp	2016-06-28 21:35:29 +
@@ -3,7 +3,7 @@
  *
  * Copyright (C) 2014-2015 Jean-Pierre Charras, jp.charras at wanadoo.fr
  * Copyright (C) 2008-2015 Wayne Stambaugh 
- * Copyright (C) 1992-2015 KiCad Developers, see AUTHORS.txt for contributors.
+ * Copyright (C) 1992-2016 KiCad Developers, see AUTHORS.txt for contributors.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -300,15 +300,16 @@
 }
 
 
-wxConfigBase* GetNewConfig( const wxString& aProgName )
+std::unique_ptr< wxConfigBase > GetNewConfig( const wxString& aProgName )
 {
 wxConfigBase* cfg = 0;
 wxFileName configname;
 configname.AssignDir( GetKicadConfigPath() );
 configname.SetFullName( aProgName );
 
-cfg = new wxFileConfig( wxT( "" ), wxT( "" ), configname.GetFullPath() );
-return cfg;
+return std::unique_ptr< wxConfigBase >( 
+new wxFileConfig( wxT(""), wxT(""), configname.GetFullPath() )
+);
 }
 
 wxString GetKicadLockFilePath()

=== modified file 'common/hotkeys_basic.cpp'
--- common/hotkeys_basic.cpp	2016-06-12 01:22:13 +
+++ common/hotkeys_basic.cpp	2016-06-28 21:07:18 +
@@ -589,9 +589,8 @@
 {
 wxFileName fn( GetName() );
 fn.SetExt( DEFAULT_HOTKEY_FILENAME_EXT );
-wxConfigBase* config = GetNewConfig( fn.GetFullPath() );
+std::unique_ptr< wxConfigBase > config = GetNewConfig( fn.GetFullPath() );
 config->Write( HOTKEYS_CONFIG_KEY, msg );
-delete config;
 }
 
 return 1;
@@ -635,7 +634,7 @@
 wxFileName fn( Appname );
 fn.SetExt( DEFAULT_HOTKEY_FILENAME_EXT );
 
-wxConfigBase* config = GetNewConfig( fn.GetFullPath() );
+std::unique_ptr< wxConfigBase > config = GetNewConfig( fn.GetFullPath() );
 
 if( !config->HasEntry( HOTKEYS_CONFIG_KEY ) )
 {
@@ -645,7 +644,6 @@
 
 wxString data;
 config->Read( HOTKEYS_CONFIG_KEY,  );
-delete config;
 
 ParseHotkeyConfig( data, aDescList );
 }

=== modified file 'common/pgm_base.cpp'
--- common/pgm_base.cpp	2016-05-22 10:31:08 +
+++ common/pgm_base.cpp	2016-06-28 22:17:37 +
@@ -3,7 +3,7 @@

Re: [Kicad-developers] [PATCH] Fix memory leaks with improper wxBaseConfig* usage (model ownership and ownership-transfer with std::unique_ptr)


Potential for errors aside, I think auto makes the code less readable
and yes code readability matters.  In this case, I have to go look up
the return value of GetNewConfig() because I don't know what an auto
type is.  I do know what a wxConfigBase* type is.  I'll just warn
everyone now that I am not a big fan of using certain syntax just for
the sake of being "C++ correct".  If it makes the code less readable, I
will resist committing it.
I do hear all of you. Let's keep the intent of this patch and the 
implementation aside, I already learned in other side-talks, that having 
an IDE telling you the complete name and more is no default nor a 
desired situation for most developers.


The right thing to do is using a std::unique_ptr at that spot, that was 
the purpose of the patch and it solves for two leaks that are happening 
in the codebase currently.
Now I only need to know how I should go about your concerns. Maybe using 
something along the lines of


using WX_CONFIG_PTR = std::unique_ptr< wxConfigBase >;

?
I would like to avoid cluttering the source-code with the 
smart-pointer-templates, to avoid people saying "look how long that is, 
a good coder (tm) will just call delete correctly!".


A sidenote: if I find myself working on some parts of the code, are 
there objections if I silently add "override" specifiers in related 
code? I find these help a lot. Also there are many inline specifiers on 
in-class member-function definitions that could be removed.


Kind Regards
Michael


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

Re: [Kicad-developers] replace_boost_function_boost_bind.patch: Replace boost::function and boost::bind with their std:: counterparts



Am 28.06.2016 um 17:52 schrieb Wayne Stambaugh:

Orson,

Since this mostly effects the new tool framework, I'll defer to your
judgement as to whether or not to commit this patch.  I don't have a
strong opinion one way or the other since we will not be able to
completely eliminate boost until C++ supports context switching.


Hello Wayne,

also boost::optional will be left as well, since std::optional is only 
available in c++14.
That being said: the std implementations usually come dircetly from the 
compiler vendors and are supposedly lighter on the compiler, without all 
the necessary macro-indirection-stuff in boost trying to get it to 
compile on all platforms and all compilers and all versions with all bugs.


Michael


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

[Kicad-developers] replace_boost_function_boost_bind.patch: Replace boost::function and boost::bind with their std:: counterparts