kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #32057
Re: Some tests.
On 11/29/2017 8:08 AM, Heikki Pulkkinen wrote:
>
> Hi
>
>
> On Wed, Nov 29, 2017 at 1:32 AM, Tomasz Wlostowski
> <tomasz.wlostowski@xxxxxxx <mailto:tomasz.wlostowski@xxxxxxx>> wrote:
>
> On 28/11/17 18:25, Heikki Pulkkinen wrote:
> >
> > Zones filling new record with new connectivity algo with A64-Olinuxino
> > board. 13s.
>
> Heikki,
>
> I would be very glad to include your improvements in the zone filling,
> but the code you've sent to me (your Github) does not meet the quality
> standard we expect:
> - It's a mix of object and non-object oriented code which is diffucult
> to understand.
>
>
> Can you specify what part is object and what are not?
>
> - It doesn't follow Kicad coding style rules.
>
>
> Maybe, but can you specify that too? I can not see.
>
> - It contains much more than faster zone filling, everything is mixed
> with your via stitching/thermal code that we did not accept for the
> reasons we had already explained to you.
>
>
> Yes of course, it is my developed and going to use it in that way.
>
>
> I also investigated why the zones are filled slowly - the major reason
> was a bug in the GAL zone filling algorithm, which was filling all zones
> by performing N independent fills of every zone causing the isolated
> copper islands to be checked N times (where N=number of zones in the
> design) instead of just once. The branch [1] contains this bug fixed. It
> also introduces quite a speedup in zone loading/rendering and
> parallelizes all zone filling operations using OpenMP. It refills all
> zones on the "A64-Olinuxino
> board" in less than 3 seconds and something around 10s for the "wrs"
> board on a Core i7-4700MQ, 16GB RAM machine.
>
>
>
>
> Please, if you want to be a member of Kicad developers, follow some
> rules:
>
>
> Of course you want that!
> Wayne, do you accept this kind of blackmailing and all these rules?
I see no blackmailing here. Tomasz is just pointing out the rules that
all KiCad developers are expected to follow when making contributions to
the project. These rules apply to everyone including the project leader
so you are not being singled out. You are being asked to help make life
easier for the lead developers so that they can possibly merge your code
into KiCad. If your code does not conform to the coding policy[1], your
repo cannot be easily merged into the main kicad repo, or your code is
difficult to follow then you cannot expect someone else to fix this for
you. The lead kicad developers are busy and do not have the time to do
this.
Cheers,
Wayne
[1]:
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html
>
> - Ask before making heavy changes. Connectivity algorithm is an example
> of a heavy change.
>
>
> - Don't introduce large or risky changes in your first patches. Changing
> the file format is an example of a potentially risky change that should
> be consulted with other developers.
>
>
> - Announce you're working on something before you start writing the
> code. Someone else may be already working on this part - which is what
> exactly happened with the connectivity algorithm
>
>
> I'll be very happy to have a look at your teardrops and automatic zone
> stitching code - which IMHO is an very valuable addition to Kicad -
> after the V5 stable release is out.
>
>
> Cheers,
> Tom
>
> [1] https://github.com/twlostow/kicad-dev/tree/tom-faster-zones
> <https://github.com/twlostow/kicad-dev/tree/tom-faster-zones>
>
>
> Why are you yelling all the time that connectivity algo for me?
> Why do you think that other people do not have rights to do experiments?
> I am going to do my experiments and tests anyway. And I do not want to
> use my time for this.
>
> I thought this is open source, and all kind of ideas should be accepted
> as an idea. Even if they make any "sense".
>
>
> Regards
>
> Heikki
>
Follow ups
References