[Kicad-developers] Plugin Startup Phase (KIFACE)

Hello, so I'm newly digging my way through the Kicad startup phase, which gets my head melting... I can follow the way from getting the KIFACE_1 of the dll all the way to a CreateWindow-Call which for example creates a SCH_EDIT_FRAME. Now what I could not find out yet is, how is the

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

-wxConfigBase* config = GetNewConfig( fn.GetFullPath() ); +auto config = GetNewConfig( fn.GetFullPath() ); config->Write( HOTKEYS_CONFIG_KEY, msg ); -delete config; This has subtle potential for errors -- while I'm normally in favour of using "auto", spelling it

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

=== modified file 'bitmap2component/bitmap2cmp_gui.cpp' --- bitmap2component/bitmap2cmp_gui.cpp 2016-06-08 06:32:01 + +++ bitmap2component/bitmap2cmp_gui.cpp 2016-06-27 19:02:56 + @@ -80,7 +80,7 @@ wxStringm_ConvertedFileName; wxSize m_frameSize; wxPoint

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

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

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

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

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

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

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++

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

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

=== modified file 'common/gal/opengl/opengl_gal.cpp' --- common/gal/opengl/opengl_gal.cpp 2016-06-13 14:43:33 + +++ common/gal/opengl/opengl_gal.cpp 2016-06-28 13:23:01 + @@ -39,7 +39,8 @@ #endif /* __WXDEBUG__ */ #include -#include +#include +using namespace std::placeholders;

[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 + +++

[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

[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

[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

[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

[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;

[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|

[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

[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

[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

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

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

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

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

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

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

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

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.

[Kicad-developers] PNS router experimental patches

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

Re: [Kicad-developers] Blured text on OpenGL

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 /

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

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

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

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

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

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

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

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'v

Re: [Kicad-developers] SWIG binding

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

Re: [Kicad-developers] SWIG binding

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

[Kicad-developers] SWIG binding

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

Re: [Kicad-developers] SWIG binding

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

Re: [Kicad-developers] Stable version 4.0.5

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

Re: [Kicad-developers] Boost 1.62.

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,

Re: [Kicad-developers] Boost 1.62.

, 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

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

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

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

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

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

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

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

Re: [Kicad-developers] Footprint properties: Normal, Normal+Insert

Am 14.12.2016 um 21:21 schrieb jp charras: Le 14/12/2016 à 20:51, Chris Pavlina a écrit : Can we rename "Normal" and "Normal+Insert" to "THT" and "SMT", or "Through hole" and "Surface mount", or something similarly descriptive? I *still* have to mouse over for the tooltip to remember which is

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

[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

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

[Kicad-developers] SYMBOL_LIB_TABLE throw()

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

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

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

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

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

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

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

[Kicad-developers] Anti-Aliasing in GAL OpenGL Canvas

Hello all, I've been working on adding Anti-Aliasing to the OpenGL canvas. Supported modes are: - Smaa: Relatively fast post process edge smoothing (High/Ultra qualities). Can result in visual glitches when zoomed far out. - Supersampling: 2x and 4x, high quality but slow, only use on potent

Re: [Kicad-developers] Anti-Aliasing in GAL OpenGL Canvas

Oh, the AA mode can be chosen in the "Display Options" Dialog! Am 23.12.2016 um 17:48 schrieb Michael Steinberg: Hello all, I've been working on adding Anti-Aliasing to the OpenGL canvas. Supported modes are: - Smaa: Relatively fast post process edge smoothing (High/Ultra quali

Re: [Kicad-developers] OpenGL rendering, etc

Hello, it might perhaps be worthwile to add Pixel-Snapping to the vertex/geometry shader, depending on the introduced relative error. Of course pixel snapping geometry is always altering reality in favor of "clean" graphics, but if the error is reasonably small, it's mostly the ERC that