Re: [Kicad-developers] Warning regarding global wxStrings and thread-safety

[Tomasz Wlostowski]

On 02/08/18 19:01, Jeff Young wrote:
> I finally caught a long-standing but very infrequent crash in the
> debugger.  It’s somewhat harrowing.
> 
> wxString keeps multiple iterators on a string up-to-date with regard to
> editing.  It keeps them in a linked list.  If you reference a global
> string in a thread (/*even*/ in a const manner, such as taking its
> length), wxString will create an interator in your thread, link it into
> the list, and then unlink it when done (with no thread safety).  Sooner
> or later, this */will/* crash.

Hi Jeff,

I've been aware of this bug for quite a while (it manifested itself
during the development of multithreaded zone filler). I should have sent
a warning to the dev list, sorry for not doing that.

Cheers,
Tom

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

Re: [Kicad-developers] [PATCH] Re: SHAPE_LINE_CHAIN in swig?

[Wayne Stambaugh]

Andrew,

I merged your patch into the development branch of KiCad.  Thank you for
your contribution to KiCad.

Cheers,

Wayne

On 7/31/2018 5:34 PM, Andrew Lutsenko wrote:
> Removing or renaming operator<< does not work because it is used by
> boost test suite in qa/geometry/test_fillet.cpp
> 
> But I found an easier solution. There is no need to have friend
> declaration in VECTOR2 class at all because it's fields are public anyway.
> I removed that declaration but kept operator<< implementation and that
> compiles just fine. Tested on debian8 and msys2.
> 
> If this solution is acceptable to you, see my amended patch attached.
> 
> Andrew
> 
> 
> On Tue, Jul 31, 2018 at 1:01 PM Wayne Stambaugh  > wrote:
> 
> If option 2 is the only option that works, please make sure to set the
> minimum swig version in the cmake file that finds swig.  I would rather
> the config fail then the build fail because an unusable version of swig
> is found.
> 
> On 7/31/2018 2:57 PM, Andrew Lutsenko wrote:
> > I will test later today both options
> > 1. Removing VECTOR2::operator<< or renaming it to str() if it's used.
> > 2. Upgrading to swig 3.0.10 from backports.
> >
> > Hopefully first is doable and would be transparent for users.
> > Second one should definitely solve the issue and I feel like
> compared to
> > other hoops a user has to jump through to make KiCad compile on
> debian8
> > this would not be the worst.
> >
> > Regards,
> > Andrew
> >
> > On Tue, Jul 31, 2018 at 11:32 AM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > >> wrote:
> >
> >     On 7/31/2018 1:13 PM, Seth Hillbrand wrote:
> >     >
> >     >
> >     > Am Di., 31. Juli 2018 um 07:31 Uhr schrieb Wayne Stambaugh
> >     > mailto:stambau...@gmail.com>
> >
> >     
>  >     >
> >     >     On 7/31/2018 8:33 AM, Carsten Schoenert wrote:
> >     >     > Am 31.07.18 um 17:50 schrieb Andrew Lutsenko:
> >     >     > ...
> >     >     >> Can swig on the qa machine be updated? Or better yet
> can you
> >     >     upgrade to
> >     >     >> debian 9? Debian 9 has swig 3.0.10 and compiles this
> just fine.
> >     >     >> Aside from this debian 8 is very old and should be done
> >     away with
> >     >     anyway
> >     >     >> because of security, old compilers, etc.
> >     >     >
> >     >     > Argumentation by missing security isn't a valid
> choice, even
> >     now the
> >     >     > ELTS team is taking care of security updates, old versions
> >     can be
> >     >     solved
> >     >     > by using backports, even swig has 3.0.10 in
> >     jessie-backports. I agree
> >     >     > that GCC wont become any version updates for Jessie.
> >     >     >
> >     >     > But there are still users out there which use Jessie based
> >     desktops.
> >     >     >
> >     >
> >     >     I'm siding with Carsten on this.  There are people who
> prefer
> >     stable
> >     >     computing platforms and I want to avoid making kicad only
> >     build on the
> >     >     latest distros.  I prefer that we keep as large of a target
> >     audience as
> >     >     possible.  How difficult would it be to change the
> >     SHAPE_LINE_CHAIN
> >     >     object (actually its the VECTOR2 object that causes the swig
> >     issue) so
> >     >     that older versions of swig don't choke on it?  I would be
> >     open to that
> >     >     solution.
> >     >
> >     >     Cheers,
> >     >
> >     >     Wayne
> >     >
> >     >
> >     > ​I'm not sure I follow the discussion.  I thought Carsten
> was saying
> >     > that jessie-backports does have SWIG 3.0.10 and so we can
> upgrade swig
> >     > on the kicad-qa​ without changing to a newer debian.
> >
> >     I was operating under the assumption that not every user will
> track or
> >     want to track Debian backports so in this case the user would
> still only
> >     have the older version of swig.  The line of code that is
> causing swig
> >     to choke is the VECTOR2 << operator which I'm almost sure is
> being used
> >     for debugging output and therefore could easily be removed without
> >     issue.  I'm not sure that there are not other swig related
> issues in the
> >     SHAPE_LINE_CHAIN implementation this change may not be
> enough.  If we
> >     are going to use a version of swig that works with the current
> code, we
> > 

Re: [Kicad-developers] [PATCH] Re: SHAPE_LINE_CHAIN in swig?

[Andrew Lutsenko]

Awesome, thanks!
Qa machine seems happy too.

So is there any chance of this getting into 5.0 branch?

I published my plugin earlier here
https://github.com/openscopeproject/InteractiveHtmlBom

And it generated a fair amount of interest on kicad.info
https://forum.kicad.info/t/interactive-html-bom-plugin-for-kicad-5-0/11713

Plugin doesn't require this patch but without it it can't render custom
shape pads and any graphics on copper/silkscreen.
Would be great to see this in 5.0.1 but I understand if you only want to
put critical fixes in that release.

Regards,
Andrew

On Fri, Aug 3, 2018 at 5:35 AM Wayne Stambaugh  wrote:

> Andrew,
>
> I merged your patch into the development branch of KiCad.  Thank you for
> your contribution to KiCad.
>
> Cheers,
>
> Wayne
>
> On 7/31/2018 5:34 PM, Andrew Lutsenko wrote:
> > Removing or renaming operator<< does not work because it is used by
> > boost test suite in qa/geometry/test_fillet.cpp
> >
> > But I found an easier solution. There is no need to have friend
> > declaration in VECTOR2 class at all because it's fields are public
> anyway.
> > I removed that declaration but kept operator<< implementation and that
> > compiles just fine. Tested on debian8 and msys2.
> >
> > If this solution is acceptable to you, see my amended patch attached.
> >
> > Andrew
> >
> >
> > On Tue, Jul 31, 2018 at 1:01 PM Wayne Stambaugh  > > wrote:
> >
> > If option 2 is the only option that works, please make sure to set
> the
> > minimum swig version in the cmake file that finds swig.  I would
> rather
> > the config fail then the build fail because an unusable version of
> swig
> > is found.
> >
> > On 7/31/2018 2:57 PM, Andrew Lutsenko wrote:
> > > I will test later today both options
> > > 1. Removing VECTOR2::operator<< or renaming it to str() if it's
> used.
> > > 2. Upgrading to swig 3.0.10 from backports.
> > >
> > > Hopefully first is doable and would be transparent for users.
> > > Second one should definitely solve the issue and I feel like
> > compared to
> > > other hoops a user has to jump through to make KiCad compile on
> > debian8
> > > this would not be the worst.
> > >
> > > Regards,
> > > Andrew
> > >
> > > On Tue, Jul 31, 2018 at 11:32 AM Wayne Stambaugh
> > mailto:stambau...@gmail.com>
> > > >>
> wrote:
> > >
> > > On 7/31/2018 1:13 PM, Seth Hillbrand wrote:
> > > >
> > > >
> > > > Am Di., 31. Juli 2018 um 07:31 Uhr schrieb Wayne Stambaugh
> > > > mailto:stambau...@gmail.com>
> > >
> > > 
> >  > > >
> > > > On 7/31/2018 8:33 AM, Carsten Schoenert wrote:
> > > > > Am 31.07.18 um 17:50 schrieb Andrew Lutsenko:
> > > > > ...
> > > > >> Can swig on the qa machine be updated? Or better yet
> > can you
> > > > upgrade to
> > > > >> debian 9? Debian 9 has swig 3.0.10 and compiles this
> > just fine.
> > > > >> Aside from this debian 8 is very old and should be
> done
> > > away with
> > > > anyway
> > > > >> because of security, old compilers, etc.
> > > > >
> > > > > Argumentation by missing security isn't a valid
> > choice, even
> > > now the
> > > > > ELTS team is taking care of security updates, old
> versions
> > > can be
> > > > solved
> > > > > by using backports, even swig has 3.0.10 in
> > > jessie-backports. I agree
> > > > > that GCC wont become any version updates for Jessie.
> > > > >
> > > > > But there are still users out there which use Jessie
> based
> > > desktops.
> > > > >
> > > >
> > > > I'm siding with Carsten on this.  There are people who
> > prefer
> > > stable
> > > > computing platforms and I want to avoid making kicad only
> > > build on the
> > > > latest distros.  I prefer that we keep as large of a
> target
> > > audience as
> > > > possible.  How difficult would it be to change the
> > > SHAPE_LINE_CHAIN
> > > > object (actually its the VECTOR2 object that causes the
> swig
> > > issue) so
> > > > that older versions of swig don't choke on it?  I would
> be
> > > open to that
> > > > solution.
> > > >
> > > > Cheers,
> > > >
> > > > Wayne
> > > >
> > > >
> > > > ​I'm not sure I follow the discussion.  I thought Carsten
> > was saying
> > > > 

[Kicad-developers] Performance enhancements

[Jeff Young]

I’ve got some performance enhancements that I’ll probably merge tomorrow, but I 
just wanted to give everyone a head’s up.

1) Cache footprint info on disk in the project.  The footprint info is 
time-stamp-hashed and compared to the library file hashes before each use.  The 
second part of that required (2) and (3).

2) POSIX-only improvements to wxDir to stop calling stat() at the drop of a 
hat, and to stop calling wxFileName::wxFileName to limit traversal to files or 
directories (our *.kicad_mod pattern should be sufficient to select only 
footprint files).

3) Performance improvements to wxFileName and its usage to stop calling 
SplitPath() at the drop of a hat.  (When scanning a directory it was calling it 
over and over again on the same path.)

4) Change in the initialization of Footprint Editor and Footprint Viewer to not 
spool up a full PcbNew Frame to fetch the canvas setting.  This is only an 
improvement when PcbNew isn’t already running, but it’s significant then.

5) Changes to layer widget to not do a layout after each row addition.

6) Replace linear searching of the Footprint Info List with binary searches.

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

Re: [Kicad-developers] KiCad v5 build warning

[Simon Richter]

Hi,

On 03.08.2018 06:06, Adam Wolf wrote:

> It works fine with macOS, and I've already enabled it for nightlies.

It has also been active for Windows nightlies for quite some time, so
people were confused when it was suddenly off in the release version.

So in addition to a decision on the action menu, we need a general
strategy for experimental features around release time.

Should we:

 - always build nightlies with default settings (experimental features
get less testing)
 - always build nightlies with all features (people will miss features
from the release)
 - switch over from "all features" to "defaults" with the first release
candidate
 - build nightlies with all features, but release candidates with default
 - ???

   Simon



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

[Kicad-developers] wxConfigBase string values

[Jeff Young]

I noticed that we spend a lot of time processing EnvVars in wxConfigBases when 
starting apps (to the tune of 10%, believe it or not).

Do we even have any EnvVars in config settings?  (Ones that we want expanded on 
the way in, rather than ones that are just stored as text?)
___
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] PCB West Attendees?

[Seth Hillbrand]

Hi All-

If anyone is planning on heading to PCB West this year and would like to
meet up and talk KiCad, let me know.  I'll be there for the weekend prior
through Tuesday 9/11.

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