On 2019-08-13 10:50, Wayne Stambaugh wrote:
On 8/13/19 2:13 AM, jp charras wrote:
Le 12/08/2019 à 21:54, Wayne Stambaugh a écrit :
Sounds like a plan. If there are not bug reports against this over
the
next month, I'll will cherry-pick it into 5.1.
Wayne
I am not sure this issue exists in
Indeed,
there is actually a plan to improve this in the future. Personally, I
even wrote down a very rough idea myself:
https://github.com/pointhi/kicad-python/wiki/swig-interface-idea
I was able to compile eeschema with swig binding
(https://github.com/pointhi/kicad-source-mirror/commits/eesche
Hi,
On Tue, Aug 13, 2019 at 05:43:02PM +0200, Ian McInerney wrote:
> Smart pointers would definitely have been nicer to use, but the issue we
> have with the board objects is they are passed out through SWIG to Python
> currently, and SWIG doesn't seem to support unique_ptr, so I am not sure
> ho
Smart pointers would definitely have been nicer to use, but the issue we
have with the board objects is they are passed out through SWIG to Python
currently, and SWIG doesn't seem to support unique_ptr, so I am not sure
how it would react if we gave it a deque of unique_ptrs. Anyone know if
that wo
Hi,
On Tue, Aug 13, 2019 at 10:50:10AM -0400, Wayne Stambaugh wrote:
> Maybe we should have used boost::ptr_deque instead. You get heap
> allocation cleanup for free.
Or a deque of smart pointers. Without range-based for, that was annoying to
use because you needed the double dereference
f
On 8/13/19 2:13 AM, jp charras wrote:
> Le 12/08/2019 à 21:54, Wayne Stambaugh a écrit :
>> Sounds like a plan. If there are not bug reports against this over the
>> next month, I'll will cherry-pick it into 5.1.
>>
>> Wayne
>
> I am not sure this issue exists in 5.1.
>
> AFAIK it comes from mov
Le 12/08/2019 à 21:54, Wayne Stambaugh a écrit :
> Sounds like a plan. If there are not bug reports against this over the
> next month, I'll will cherry-pick it into 5.1.
>
> Wayne
I am not sure this issue exists in 5.1.
AFAIK it comes from moving code from our DLIST to std::deque, only in
mast
Sounds like a plan. If there are not bug reports against this over the
next month, I'll will cherry-pick it into 5.1.
Wayne
On 8/12/19 3:47 PM, Ian McInerney wrote:
> Wayne, lets let this settle in master for a while to make sure that no
> issues due to object lifetime surface.
>
> -Ian
>
> On
Wayne, lets let this settle in master for a while to make sure that no
issues due to object lifetime surface.
-Ian
On Mon, Aug 12, 2019 at 9:20 PM Wayne Stambaugh
wrote:
> Ian,
>
> I merged your patch. I'm guessing this should be cherry-picked into the
> 5.1 branch.
>
> Thanks,
>
> Wayne
>
> O
Ian,
I merged your patch. I'm guessing this should be cherry-picked into the
5.1 branch.
Thanks,
Wayne
On 8/11/19 4:42 PM, Ian McInerney wrote:
> I was noticing there were some memory leaks inside the board/module
> classes that got somewhat extreme in some cases (I saw ~300MB leaked
> from op
I was noticing there were some memory leaks inside the board/module classes
that got somewhat extreme in some cases (I saw ~300MB leaked from opening
and closing cvpcb in Eeschema when run without a project manager). This
patch adds some deletion to the destructors of the board/module classes, so
t
11 matches
Mail list logo
