Re: [Kicad-developers] Was the initial graphics mode screen removed?

[Tomasz Wlostowski]

On 12/01/2022 14:24, pmx wrote:


Le 12/01/2022 à 13:32, Franck Bourdonnec a écrit :


well, my second laptop is a an old e525 acer that is more than enough 
rapid to do 'internet/video/kicad/kicad debuging...' even with 2~3 
hours for a full build.

Having it unable to run KiCad , very disapointing ;)



Funny enough (so to speak...), my main laptop mainboard just crashed and 
I'm currently back to a 2007 Hewlett-Packard laptop (15 years old!) 
running Linux.
The Nvidia GPU driver is not supported anymore by the latest X11  
(AFAIK, they dropped the DirectX9 programming interface. Have to use 
Nouveau driver + DRI / OpenGL2.1).

.
Surprisingly, I can run Freecad almost flawlessly (on not too 
complicated designs), but Eeschema is stunningly slow (for example, 
serious lag when moving components onscreen).
A positive note : a slow machine help put some parts of the code 
efficiency under the magnifying glass  !!


Do you have antialiasing enabled?





Don't partitipate to "obsolescence programmée" ("programmed trashing 
?") ?


-> AFAIK, This is "Planned Obsolescence".


Well, if someone planned it, it's not us, but Apple and MS. Under Linux 
you can at least use any version of KiCad you please (or you're free to 
hack the newest master to your needs).


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] Was the initial graphics mode screen removed?

[Tomasz Wlostowski]

On 11/01/2022 22:45, pmx wrote:


 From my previous tests (Kicad 5.99), I can say that any speed 
bottleneck is likely NOT in the rendering engine, but in the rest of the 
code.
I can't count how many Boost:: containers are scanned, and even 
temporarily created and deleted, when you play with the graphics 
elements in the schematics !

(The 3D viewer is a different matter).


Dear pmx,

The biggest performance hog is zone fill rendering and triangulation 
which unfortunately has to be done on the CPU because (mostly for Linux 
and older Intel chipset users) we use a very old OpenGL 2.1 version.


Also lack of geometry shaders causes a huge PCI bandwidth overhead (each 
track segment is 2 triangles + attributes, sent from the CPU).


There's a LOT of room for improvement just by using more modern GPU 
features (and by modern I mean from 2012).


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] Tiling Algorithm Improvements

[Tomasz Wlostowski]

On 20/11/2020 10:02, Alex wrote:
> Hi everyone,
> 
> I started doing some C++11 modernization and Standard Library insertion
> in the rectangular placement segment of the PCBNew, and in the process I
> went down the rabbit hole of documentation for the algorithm. Out of
> curiosity I adjusted the Greater algorithm from only sorting on the
> longest side, to first sorting by longest side, and then sorting by
> shortest side.
> 
> I found that this small adjustment seemed to increase packing density
> enough that when presented with 500 rectangles of randomly generated
> size of (15x15) - (85x85) fit into surfaces of (255 x 255), the total
> number of required surfaces went from ~28 to ~26. The catch is that the
> initial sorting of the algorithm takes a little longer.
> 
> Always the skeptic, I would like to know if there is currently a
> methodology or recommendation for incorporating a benchmark test for
> both space and time performance. At minimum, I can use Google Benchmark,
> but I'd like to know if I should place the tests in the same folder, or
> if there is another place for this kind of stuff.
> 

Alex,

Do you mean the rect packing algorithm used by the autoplacer?

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] eeschema for IC design

[Tomasz Wlostowski]

On 14/10/2020 20:00, pepijn de vos wrote:
> Hey all,
> 
> I'm a sw dev and recent IC design graduate, who made it his mission to
> improve open source tools for IC designers.
> To this end I've been playing with the recently released Sky130 PDK,
> which is an open source PDK that does not require any annoying NDA's and
> will actually allow sharing IC designs.
> 
> I've been looking at eeschema a bit as one of the options to do
> schematic entry and simulation. However, I found that the integration
> with ngspice is very limited at the moment. So I'm interested in making
> this better!
> 
> The first problem I ran into is that it can't plot the currents of a
> transistor no matter what you add in terms of spice directives. More
> info:
> https://forum.kicad.info/t/how-can-i-plot-transistor-currents-after-a-simulation/25324/8
> So I have several questions.
> Would this be a good first issue to tackle?

Hi Pepijn,

Sure, go for it - and if you'll find it too hard as a starter, there's a
ton of other issues in the simulator/ngspice integration...

https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_name[]=ngspice

> I think there are a few ways to go about it, which don't exclude each
> other. One is to extend the logic that adds the currents for voltage
> sources and resistors to also add transistors. Another is to update the
> simulator UI to populate the signal list from the raw file, rather than
> its own idea of which signals were saved, so that you can add custom
> .save statements and plot them.

I would by default tell the simulator to log all node voltages/pin
currents (including transistor pins). Anything else (that is internal
currents, etc.) should be parsed from .save directive (so I'm more in
favor of option 2).

> For example, two other things that would be great to add is a way to
> plot algebraic expressions of different signals,

This looks like a nice feature in the longer term. If you're interested
in developing it, I could offer some (but not much) help due to my
current workload...

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] High speed tools

[Tomasz Wlostowski]

My 5 quick cents:

> 1) tool to visualize nets lengths (similar to
> https://github.com/MitjaNemec/Kicad_action_plugins#length-stats ). I
> want to make a gui where you can define what nets you want to see
> altogether. And it should show you length on each layer and summary.
> And vias as well.

  2) Same stuff for length between 2 objects (for example via and pad
> for T-topology) similar to
> https://github.com/MitjaNemec/Kicad_action_plugins#pad2pad-track-distance.
New DRC will take care of that (checking length between arbitrary
endpoints as well as reporting constrained length traces/diff pairs).


> 3) some tool to define and automatically change tracks length on
> different layers (to match target impedance)
Did you mean per-layer width/gap constraints? abs(Impedance) is not
related (at least not so simply) to trace lengths. We already have
length tuner tool, with the V6 design rule system it will be able to
pick length constraints from board design rules instead of hand-typed
values.

> 4) Tool to work with differential pairs. 
We didn't plan implementing such a tool. Beware that even if it happens,
applying more than cosmetic changes to the routing globally will likely
ruin your board so badly you'll spend rest of the day cleaning it up...

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] DRC - detecting acute angles

[Tomasz Wlostowski]

On 18/07/2020 23:47, Joshua Redstone wrote:
> Thanks, that link's a helpful starting point.
> Josh

Hi Joshua,

If you could figure out the algorithm for robust acute angle detection
(your input is a set of BOARD_ITEMs), I can integrate it with the new
KiCad DRC engine.

Tom


> 
> On Fri, Jul 17, 2020 at 7:40 PM Seth Hillbrand  > wrote:
> 
> Please have a look over the open issues on GitLab.  Until the new
> DRC code has been merged into master, it's not a good candidate for
> a new developer.
> 
> Here's a link with open issues for the feature-freeze that have not
> yet been assigned.  Please do note that any feature-development work
> should have a documented implementation plan that the lead
> developers sign off on before you begin coding.  This can help to
> avoid problems where you do a lot of work that doesn't get accepted
> because it doesn't fit in the larger plan.
> 
> 
> https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_title=6.0%20Feature%20Freeze_id=None
> 
> I would also strongly encourage you (as we do for all developers
> starting to work on KiCad) to look at fixing small issues first. 
> They are not nearly as appealing as a feature implementation but
> they are more manageable and will help you learn the general layout
> and workings of the system.
> 
> Best-
> Seth
> 
> KiCad Services Corporation KiCad Services Corporation Logo
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ 
> Davis, CA
> www.kipro-pcb.com     i...@kipro-pcb.com
> 
> https://twitter.com/KiProEDA 
> https://www.linkedin.com/company/kicad
> 
> 
> 
> On 2020-07-17 16:13, Joshua Redstone wrote:
> 
>> Hi all,
>> I was wondering what's the state of the pcbnew DRC work and what
>> are the todos left to be done?
>> I have a bit of time while waiting for a board to be assembled. I
>> was thinking of exploring DRC changes to either detect acute
>> angles in copper or detect silkscreen text that intersects vias /
>> pads, but I'm also curious to know what else needs doing.
>> Cheers,
>> Josh
>>  
>>
>> ___
>> 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] Display origin transforms for DRC reports?

[Tomasz Wlostowski]

On 10/07/2020 00:58, Reece R. Pollack wrote:
> I'm looking at display origin transformations for DRC reports.
> 
> With the 5.1.x branch Pcbnew, the DRC report dialog box message texts
> contained the Cartesian coordinates of each flagged item. It appears
> that the 5.99 branch no longer displays the coordinates of DRC items.
> However, the Cartesian coordinates are still listed in the report file.
> Unlike the display in a dialog box, this report is persistent and could
> be passed to someone using different display origin settings.
> 
>  1. Should these coordinates be reported relative to the page origin, or
> transformed per the user-selected origin and axis directions?
>  2. If the coordinates are transformed, should the report include the
> user settings?
> 
> -Reece
> 

Reece,

I wouldn't introduce any changes to the current DRC code, we're
designing a new DRC engine for KiCad V6 and many things in DRC interface
will likely change.

IMHO the DRC coordinate transform belongs to the UI, not the DRC itself:
- the DRC engine generates an internal report with coordinates in board
coordinate space
- whatever displays the report to the user (i.e. the DRC dialog)
converts the board coordinates to UI coordinates.

- my 5 cents
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] Granularity of DRC error code

[Tomasz Wlostowski]

On 11/06/2020 22:27, Jeff Young wrote:
> I had also originally planned on “compiling” the classic system into 
> behind-the-scenes rules, but I don’t think that’s going to work out.  It’s 
> pretty easy to agree on priority of all the edge case (pad override, 
> footprint overrides, netclasses vs. board settings, etc.), but there’s 
> nothing uniform about them.

Hi Jeff,

I'm actually coding it right now... Why do you think it will not work?

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] Altium board importer

[Tomasz Wlostowski]

On 04/04/2020 18:18, Wayne Stambaugh wrote:
> For those of you who haven't heard, the Altium board importer[1] was
> merged into the master branch.

Fantastic work Thomas, looking forward to import our Altium projects
using your plugin!

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] pcbnew extremly slow

[Tomasz Wlostowski]

On 28/02/2020 13:00, BERTRAND Joël wrote:
> jp charras a écrit :
>> Le 28/02/2020 à 12:46, BERTRAND Joël a écrit :
>>> BERTRAND Joël a écrit :
 Seth Hillbrand a écrit :

> Hi Joël-
>
> Please open an issue report at
> https://gitlab.com/kicad/code/kicad/issues and attach the project.
>

 Done.
 https://gitlab.com/kicad/code/kicad/issues/3955
>>>
>>> I have simplified my schematic (I have deleted bus labels and grouped
>>> some subcircuits to reduce sheets by 4), result is the same.
>>>
>>
>> Calculation time is closely related to pad count, not sheet count.
>>
>> Unfortunately, issue 3955 does not exist on Gitlab: latest is 3954.
> 
>   Issue 3955 exists but was created with confidential flag. But I can
> send to you my project. My design should contains 25344 pads for sensor
> itself and maybe 1000 pads more for driver.
> 
Hi Joel,

Can you share the design with me on gitlab?

Regards,
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] Status of improved drawing tools?

[Tomasz Wlostowski]

On 09/02/2020 11:39, Eeli Kaikkonen wrote:
> As early as in the fundraising video
> https://www.youtube.com/watch?v=uhcMGQ32Xw0 for v6 (before the plans for
> 5.1 existed) "improved drawing tools" were introduced and apparently
> some work was already done by then. I don't find this anywhere in the
> roadmaps. Has it been cancelled or just forgotten from the roadmap?
> 


Hi Eeli,

It's a work in progress, although my time to work on KiCad is quite
limited these days.

WIP version:
https://github.com/twlostow/kicad-dev/tree/tom-outline-edit-fosdem2020

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] Project leader announcement

[Tomasz Wlostowski]

On 03/12/2019 15:28, Wayne Stambaugh wrote:
> I am excited to announce that I have joined the
> KiCad Services Corporation[1]

Congratulations Wayne!

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] Altium 20 new interactive routing features

[Tomasz Wlostowski]

On 03/12/2019 02:43, Mark Roszko wrote:
> Just throw in a linear regression somewhere and we can say KiCad has
> AI based routing ;)
> 

Our GAL does a lot of matrix multiplications. We could perhaps advertise
KiCad as the first EDA tool with a Deep Learning Techniques-based
rendering engine ;-).

T.

___
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] Altium 20 new interactive routing features

[Tomasz Wlostowski]

On 02/12/2019 21:51, Kliment (Future Bits) wrote:
> The video looks very much like to me like the trace is following a
> voronoi cell boundary with cells coming out from each obstacle outline
> vertex. But what do I know? Maybe I'm just imagining things.

Maybe you're right ;-) I admire your ability to figure out the inner
workings of a complex algorithm just by looking at a video of it working...

In any case, such discussions are not very helpful nor encouraging for
the devs (I spent quite a lot of my time on KiCad router) and I'd rather
work on improving our own P instead of arguing what's topology ;-)

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] Altium 20 new interactive routing features

[Tomasz Wlostowski]

On 02/12/2019 19:15, Kliment (Future Bits) wrote:
> Ignoring the bovine references and attempting to answer the question:
> 
> Topological routing means using the connectivity graph of the system to
> generate geometrical constraints, and also to generate specific geometry
> for say traces or polygons. It's called that because it uses concepts
> from the discipline of topology such as Delauney triangulations,
> neighbourhood graphs, Voronoi diagrams, straight skeletons, etc. It
> means you can, for instance, make a set of traces that follow a path
> maximally distant from each obstacle, giving you maximum routing space
> around each trace. A number of autorouting algorithms are based on
> topological concepts, in this case however it specifically refers to
> generating trace shapes such that they have the maximum distance from
> each obstacle at each point along their path, as opposed to being
> constrained to straight line segments.

Kliment & Vesa,

All of this is true - for autorouters. This whole thread started with
Altium's videos about the improvements to their interactive
(semi-manual) router. P actually use very few strictly topological
concepts (in the case of Kicad P, mainly in the optimizer part of the
code)...

BTW, I'm surprised by the smoothness of the animation in A***m's
promotional videos. Did they use some editing/postprocessing to make
them look this way? :D

Tom


> 
> Hope this is helpful.
> 
> On 02.12.19 17:59, Tomasz Wlostowski wrote:
>> On 02/12/2019 17:40, Vesa Solonen wrote:
>>> topological routing will
>>
>> Could you please explain what 'topological routing' does mean (other
>> than being marketing buzzword used by some companies) and what exactly
>> it has to do with topology [1]?
>>
>> Tom
>>
>> [1] https://en.wikipedia.org/wiki/Topology
>>
>>
>>
>> ___
>> 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] Altium 20 new interactive routing features

[Tomasz Wlostowski]

On 02/12/2019 18:10, José Ignacio wrote:
> Cows (like most mammals) are toruses though...

Well, if you'd take circulatory and lymphatic systems into account, they
actually are higher order manifolds ;-)

T.

> 
> On Mon, Dec 2, 2019 at 11:06 AM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> 
>     On 12/2/19 11:59 AM, Tomasz Wlostowski wrote:
> > On 02/12/2019 17:40, Vesa Solonen wrote:
> >> topological routing will
> >
> > Could you please explain what 'topological routing' does mean (other
> > than being marketing buzzword used by some companies) and what exactly
> > it has to do with topology [1]?
> >
> > Tom
> >
> > [1] https://en.wikipedia.org/wiki/Topology
> 
> The cow morphing into a sphere made me smile :)
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net
> <mailto: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] Altium 20 new interactive routing features

[Tomasz Wlostowski]

On 02/12/2019 17:40, Vesa Solonen wrote:
> topological routing will

Could you please explain what 'topological routing' does mean (other
than being marketing buzzword used by some companies) and what exactly
it has to do with topology [1]?

Tom

[1] https://en.wikipedia.org/wiki/Topology



___
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] What does "when in doubt do it opposite than certain other pcb tool" stand for?

[Tomasz Wlostowski]

On 26/11/2019 20:46, Wayne Stambaugh wrote:
> 

>>
> 
> It was a joke in the same way that "Never trust the autorouter" is a
> joke.  And like most good jokes, there is an uncomfortable truth about
> it.

Indeed ;-) (says the author of the aforementioned joke...)

It's a pun on a quote on the design of Git attributed to Linus Torvalds,
something like "look at CVS/SVN and do exactly opposite".

He didn't mean CVS/SVN were bad - just wanted to go his own way, not
reusing solutions from these tools.

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] What does "when in doubt do it opposite than certain other pcb tool" stand for?

[Tomasz Wlostowski]

On 22/11/2019 17:42, Rene Pöschl wrote:
> 
> I would assume this is referencing version 6 of eagle. The current
> versions of eagle are actually something that can (in some aspects) be
> used as a good example. I would therefore assume that this sentence is
> simply out of date and could be removed or at least reworded.

I don't have access to that webpage, but whoever has, feel free to
remove it.

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] Using OPT types

[Tomasz Wlostowski]

On 24/11/2019 18:20, Seth Hillbrand wrote:
> 
> I generally like both of these.  But part of that is because my IDE (VS
> Code and sometimes Eclipse) shows me the underlying type(...)

I second Seth. Also use VScode, great editor ;-)

T.


___
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] New lead developer announcement

[Tomasz Wlostowski]

On 07/11/2019 21:14, Wayne Stambaugh wrote:
> I am happy to announce that the KiCad project now has a new member of
> the lead development team.  Ian McInerney has accepted an invitation to
> become a member of the lead development team.  Ian's contributions have
> earned him this privilege and we are grateful for his efforts.  Please
> join me in congratulating Ian and welcoming in his new role.


Congratulations Ian!

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] Benchmarking kicad compilation on CPUs released 6 years apart

[Tomasz Wlostowski]

On 30/10/2019 17:37, Seth Hillbrand wrote:
> 
> Two things can help there.  First, using the gold linker (if you are not
> already) and second, using Ninja.  The gold linker is substantially
> faster than the BFD linker. 

I can confirm the above, way faster!

> And Ninja is smarter than make about
> parallelizing actions.  Cmake will happily generate the Ninja files for
> you with -GNinja.

Didn't know about Ninja, thanks Seth!

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] Benchmarking kicad compilation on CPUs released 6 years apart

[Tomasz Wlostowski]

On 30/10/2019 16:20, Simon Richter wrote:
> Hi,
> 
> On Tue, Oct 29, 2019 at 07:00:48PM +0100, Tomasz Wlostowski wrote:
> 
>> $ make -j12
> 
>> real 7m59.758s
>> user 86m44.231s
>> sys  5m9.724s
> 
> That is more than 1100% CPU usage, with -j12, so very close to full usage.
> 
> How is that even possible, don't you have that two minute phase at the end
> of building pcbnew_kiface where it's just building pcbnew_wrap.cxx.o and
> everything else is done?
> 

IIRC pcbnew_wrap.cxx is only generated when Kicad is built with Python
support. I never build it with Python enabled ;-).

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] Benchmarking kicad compilation on CPUs released 6 years apart

[Tomasz Wlostowski]

On 29/10/2019 15:40, Simon Richter wrote:
> We could probably shave off another two or three minutes of build time if
> we could make sure that we always make progress on the critical path. The
> dependency generation as a side effect pulls all the sources and headers
> into cache, which reduces the effects of I/O latency a bit during
> compilation, so parallelizing with more than the number of threads you
> actually have is probably counterproductive.

Hi,

Another idea: use precompiled headers. I experimented some years ago
with cotire for CMake on KiCad sources and it gave quite promising
results. Since I didn't maintain this code it's probably useless by now
given how new stuff has been added to KiCad tree but the savings in
build time by header precompilation will be still IMHO quite significant.

As for MSYS's GCC speed - personally I use Visual Studio under Windows,
not only because of faster build time but also because of a debugger
that actually works...

As a side comment:

$ make -j12 (latest KiCad master, i7-9750H, 32 GB DDR4 @ 2666 MHz,
Ubuntu 19.04)

real7m59.758s
user86m44.231s
sys 5m9.724s

Citing the classic: "not great, not terrible" ;-)

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] Ctrl-click to highlight in pcbnew missing?

[Tomasz Wlostowski]

On 10/09/2019 20:55, Michael Kavanagh wrote:
> There is a subtle difference between Ctrl+Click and Shift+Click for
> adding items to a selection. E.g. in Windows Explorer/macOS Finder/MS
> Office:
>  - Ctrl + Click: Add only the clicked item to the selection
>  - Shift + Click: Add the clicked item and all the items in between
> the currently selected and clicked item.

We are not selecting from a list of items/icons/whatever, so there's no
notion of "items in between the currently selected and clicked item". No
graphical editor I know does that. Anyway, Seth's idea of modifier key
customization should fix this for good :)

T.

___
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] [OFFTOPIC] Ctrl-click to highlight in pcbnew missing?

[Tomasz Wlostowski]

On 10/09/2019 20:58, Andy Peters wrote:
> Oh, good god, don’t get me started on the shitty keyboard on the 2017 Touch 
> Bar MacBook Pro on which I type this! But the Mac trackpads are still head 
> and shoulders above every comer. 
> 
> (Truth be told, this MBP is a GREAT Kicad machine.)

I do have a 2017 (or 2018) MBP, I tried to develop KiCad on it but the
keyboard (esp. this OLED bar) makes it a no-go for anything that
requires typing more than a few words... I stick to my PC's
keyboard/mouse and use NoMachine for remote access while working on the
Mac version of KiCad.

Tom

BTW, is there any free (as in beer or as in freedom) RDP server for Macs?

___
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] Ctrl-click to highlight in pcbnew missing?

[Tomasz Wlostowski]

On 10/09/2019 20:45, Andy Peters wrote:
> 
> Ctrl-Click on macOS defaults to right-button click, harkening back to
> the days of the Mac’s one-button mouse (“one button oughta be enough for
> everyone!”).

Not much changed since then ("unusable keyboard oughta be enough for
everyone - all they need is to consume our content anyway" - Macbook
2018 sales pitch :-)
> 
> -a
> 
> ___
> 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] Ctrl-click to highlight in pcbnew missing?

[Tomasz Wlostowski]

On 10/09/2019 18:49, Seth Hillbrand wrote:
> One of our goals for v6 is to standardize the user interface to expected
> UX norms.  There will be a number of large changes to accomplish this
> and it will modify some workflows.  Moving the whole system to a
> selection-based interface (eeschema, pl editor as well as pcbnew) is
> good for long-term uptake of the system as well as making it easier to
> maintain.

Well, Ctrl-click to highlight was added by me during early development
of the GAL, because some other tools I'm quite used to have this
shortcut and the legacy highlight tool was a bit awkward for me.
Concerning the UX norms, it's not obvious that Ctrl is the standard way
of adding/removing items from the current selection. A quick test showed
that:
- MS office selection mode (sort of standard for Windows UX), Ctrl and
Shift have the same behaviour.
- LibreOffice ignores Ctrl modifier when selecting, only Shift works
- Same in case of Corel programs.
I know these keys have different function for selection lists (i.e. the
explorer window with folder/file icons), but this is not our case. IMHO
modifier keys (Shift, Alt, Ctrl) in a CAD tool should each have
different frequently used function.

If nobody opposes, I'll add an option in pcbnew preferences to select
between Ctrl-Click and a keyboard-only shortcut for net highlight.

Cheers,
Tom


> 
> -S
> 
> On 2019-09-10 12:29, José Ignacio wrote:
>> That's a big change. Are you sure it is a good idea to do without
>> asking users about it? (from my part it would annoy me quite a bit if
>> i was using master).
>>
>> On Tue, Sep 10, 2019 at 8:09 AM Jeff Young  wrote:
>>
>>> Ctrl-click was made consistent with Pcbnew (and platform standards)
>>> for toggle selection.
>>>
>>> ` is now hooked up to highlight net.
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>> On 10 Sep 2019, at 13:30, Tomasz Wlostowski
>>>  wrote:
>>>>
>>>> Hi,
>>>>
>>>> Am I missing something or did Ctrl-click to highlight a net
>>> suddenly
>>>> stopped working in pcbnew?
>>>>
>>>> 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
>>>
>>> ___
>>> 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

[Kicad-developers] Ctrl-click to highlight in pcbnew missing?

[Tomasz Wlostowski]

Hi,

Am I missing something or did Ctrl-click to highlight a net suddenly
stopped working in pcbnew?

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] CERN Open Days

[Tomasz Wlostowski]

On 10/09/2019 08:30, Diego Herranz wrote:
> Hi, all
> 
> The CERN Open Days (https://opendays.cern/) will be held this weekend.
> I'll be there on Sunday. Will any developer or librarian be there? Or
> any of the guys working at CERN?

Hi

I'll be there. Orson is away. Drop me an e-mail if you want to meet for
a beer/coffee/chat...

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: Fixing a compile error on Power PC

[Tomasz Wlostowski]

On 27/08/2019 16:18, Steven A. Falco wrote:
> On 8/26/19 4:16 PM, Seth Hillbrand wrote:
>> On 2019-08-26 16:05, Tomasz Wlostowski wrote:
>>> On 26/08/2019 17:24, Seth Hillbrand wrote:
>>>> Agreed.  That looks like it may be have been a rebase issue as the
>>>> commit was for MSVC and shouldn't affect PPC.
>>>>
>>>> @Tom, shout if you see an issue here.  I've pushed the patch to master
>>>> in the meantime.
>>>>
>>> I don't see a technical issue, but rather a practical one: why Linux
>>> distributions dictate us what architectures we should support?
>>>
>>> I've never seen a machine with a little-endian PPC.
>>>
>>> Tom
>>
>> The LE variant is the PPC future starting with POWER8[1][2].
>>
>> [1] 
>> https://www.phoronix.com/scan.php?page=news_item=POWER-PPC64-Discontinue-Fedora
>> [2] https://developer.ibm.com/articles/l-power-little-endian-faq-trs/
>>
> 
> I don't think it is a question of LE vs BE.  The issue is 32-bit vs 64-bit.
> 
> On a 64-bit PPC machine, gcc defines both _ARCH_PPC and _ARCH_PPC64, so the 
> test in libcontext.h was wrong, and resulted in both 32-bit and 64-bit code 
> trying to be compiled simultaneously.  My patch simply makes it "either 32bit 
> or 64-bit" rather than "both 32-bit and 64-bit at the same time".
> 

Does anybody here have a PPC machine to test this? Preferably one with
working OpenGL?

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: Fixing a compile error on Power PC

[Tomasz Wlostowski]

On 26/08/2019 17:24, Seth Hillbrand wrote:
> Agreed.  That looks like it may be have been a rebase issue as the
> commit was for MSVC and shouldn't affect PPC.
> 
> @Tom, shout if you see an issue here.  I've pushed the patch to master
> in the meantime.
> 
I don't see a technical issue, but rather a practical one: why Linux
distributions dictate us what architectures we should support?

I've never seen a machine with a little-endian PPC.

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

[Kicad-developers] Coding style question

[Tomasz Wlostowski]

Hi Fellow Devs,

I'm fixing some memory management issues in the P by introducing smart
pointers here and there. Do we have any coding policy on typedefing
shared_ptrs/unique_ptrs?

Should I:
- always use std::shared_ptr explicitly?
- or am I allowed to typedef std::shared_ptr TYPE_SP (or something
alike)?

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] GAL layer question

[Tomasz Wlostowski]

On 07/08/2019 19:45, Jeff Young wrote:
> Hi Orson,
> 
> I wanted to keep the selection highlight shadows uncached, but they need to 
> go above the device backgrounds and sheet backgrounds.
> 
> I can go ahead and put them in cached.  (I just need to add some code to 
> redraw them when the zoom level changes.)
>
Hi Jeff,

IIRC selected items are never cached in GAL, at least in pcbnew (select
moves them to m_selection which is a non-cached VIEW_GROUP).

Cheers,
Tom

> 
> Cheers,
> Jeff.
> 
>> On 7 Aug 2019, at 13:24, Maciej Suminski  wrote:
>>
>> Hi Jeff,
>>
>> I am afraid it is not possible. We use two framebuffers for rendering:
>> the cached one keeps in the video memory vertices that are not likely to
>> change in the near future, the non-cached is for vertices that are
>> modified (e.g. dragged tracks) and are send to the GPU every frame.
>>
>> To boost the performance even further, the framebuffers take advantage
>> of composition. The framebuffers are rendered to textures, then they are
>> blitted on the screen: first cached, then non-cached. Thanks to that,
>> the cached framebuffer might be reused for many frames when only
>> non-cached items are updated, but the drawback is that one cannot
>> interleave the rendering order.
>>
>> Is there a particular problem you are trying to solve? Perhaps it can be
>> implemented in another way.
>>
>> Cheers,
>> Orson
>>
>> On 8/3/19 11:09 PM, Jeff Young wrote:
>>> How do I interleave a GAL non-cached layer with cached layers?
>>>
>>> The selection shadow is currently non-cached, but because of that is always 
>>> drawn behind device fills.  Is there a way to put it between LAYER_DEVICE 
>>> and LAYER_DEVICE_BACKGROUND (both of which are cached in OpenGL)?
>>> ___
>>> 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] GAL layer question

[Tomasz Wlostowski]

On 07/08/2019 19:45, Jeff Young wrote:
> Hi Orson,
> 
> I wanted to keep the selection highlight shadows uncached, but they need to 
> go above the device backgrounds and sheet backgrounds.
> 
> I can go ahead and put them in cached.  (I just need to add some code to 
> redraw them when the zoom level changes.)

Hi Jeff,

How about using a shader for drawing selection highlights/overlays in
OpenGL (fallback has no distinction between cached/noncached anyway)?

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] Crash Reporter

[Tomasz Wlostowski]

On 30/07/2019 20:03, Nick Østergaard wrote:
> I get the same error. :(
> 

Hi Nick,

We had two problems:
- wrong check macro (I removed it in the last commit from my branch)
- wrong build of wx (must be configured with --enable-backtrace - fixed
PKGBUILD in the attachment).

Latest code here:
https://github.com/twlostow/kicad-dev/tree/tom-crash-reporter-aug01

Cheers,
Tom

#
# Based on packages found at these URLs
# https://www.archlinux.org/packages/extra/i686/wxgtk-common/
# https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-wxWidgets
#
# Maintainer: Tim S 
#


# Packages that are assumed to be installed when building this package.
#   pacman -S --needed mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain

_basename=wxWidgets
_realname=wxmsw
_wx_basever=3.1
# Example _wx_buildver value is "-rc"
_wx_buildver=

pkgbase=mingw-w64-${_basename}${_wx_basever}
pkgname="${MINGW_PACKAGE_PREFIX}-${_realname}${_wx_basever}"
pkgver=${_wx_basever}.2
pkgrel=1
pkgdesc="A C++ library that lets developers create applications for Windows, 
Linux and UNIX (mingw-w64)"
arch=('any')
url="http://wxwidgets.org;
license=('custom:wxWindows')
makedepends=(
  "make"
  "patch"
  "${MINGW_PACKAGE_PREFIX}-libpng"
  "${MINGW_PACKAGE_PREFIX}-libjpeg-turbo"
  "${MINGW_PACKAGE_PREFIX}-libtiff"
)
options=('strip' 'staticlibs' 'buildflags')
source=(
  
https://github.com/wxWidgets/wxWidgets/releases/download/v${pkgver}${_wx_buildver}/${_basename}-${pkgver}${_wx_buildver}.tar.bz2

  # This patch is a MSys2 run-time patch
  "001-wxWidgets-3.0.2-relocate-prefix-in-bin-wx-config.patch"

  "002-wxWidgets-3.0.3-make-abicheck-non-fatal.patch"

  # the wxTeam rejected this patch
  "005-wxWidgets-3.0.2-Remove-WX_LIBS_STATIC-from-m4.patch"

  011-wxWidgets-3.1.2-Enable-wxUSE_GRAPHICS_DIRECT2D.patch
)
sha256sums=('4cb8d23d70f9261debf7d6cfeca667fc0a7d2b6565adb8f1c484f9b674f1f27a'
'7c3b8f6ba275a448a5e82d64c4914acd5aefb8bbb952389688f3e7167a787c56'
'8e1eb9d6a13c7c52ffaec6093e40d1f3c397a220fd881274ce3ef54fc39525d9'
'6ae8ab869c091019f62a15de788a2b9c5d326bfac6be7f247e4c82426d41e4ef'
'a0079d43c0c0308060578318ee979af3ecc400cca537e9378dc9021fe4b5a371')
prepare() {
  cd "${srcdir}"/${_basename}-${pkgver}${_wx_buildver}

  # Fix MSys2 Run-Time wx-config bug.
  patch -p1 -i 
"${srcdir}"/001-wxWidgets-3.0.2-relocate-prefix-in-bin-wx-config.patch

  patch -p1 -i "${srcdir}"/002-wxWidgets-3.0.3-make-abicheck-non-fatal.patch

  # This patch is not really needed; but, WX_LIBS_STATIC does not work 
correctly under MSys2
  # Removed it to see if anything breaks or if anything is fixed.
  patch -p1 -i 
"${srcdir}"/005-wxWidgets-3.0.2-Remove-WX_LIBS_STATIC-from-m4.patch

  patch -p1 -i 
"${srcdir}"/011-wxWidgets-3.1.2-Enable-wxUSE_GRAPHICS_DIRECT2D.patch
}

build() {
  
  # Configure options added to support other software:
  #   --enable-graphics_ctx codelite
  #
  # Configure options added to check for build issues
  #   --disable-precomp-headers
  #
  # Configure options added to avoid possible future issues
  #   --with-cxx=14
  #   --enable-std_string
  #
  # Configure options added to avoid warnings:
  #   --with-regex=builtin
  #
  # Configure options known to cause build errors:
  #   --disable-regkeycompile error
  #
  # Configure options believed to reduce code size or build time:
  #   --without-opengl
  #   --without-subdirs
  #   --disable-webview
  #   --disable-mediactrl
  

  [[ -d "${srcdir}"/build-${CARCH}-shared ]] && rm -rf 
"${srcdir}"/build-${CARCH}-shared
  mkdir -p "${srcdir}"/build-${CARCH}-shared && cd 
"${srcdir}"/build-${CARCH}-shared

  ../${_basename}-${pkgver}${_wx_buildver}/configure \
--prefix=${MINGW_PREFIX} \
--host=${MINGW_CHOST} \
--target=${MINGW_CHOST} \
--build=${MINGW_CHOST} \
--enable-shared \
--enable-std_string \
--enable-iff \
--enable-permissive \
--enable-unicode \
--enable-graphics_ctx \
--enable-accessibility \
--enable-backtrace \
--disable-monolithic \
--disable-precomp-headers \
--with-msw \
--with-cxx=14 \
--with-opengl \
--with-libpng=sys \
--with-libjpeg=sys \
--with-libtiff=sys \
--with-regex=builtin

  make #VERBOSE=1


  [[ -d "${srcdir}"/build-${CARCH}-static ]] && rm -rf 
"${srcdir}"/build-${CARCH}-static
  mkdir -p "${srcdir}"/build-${CARCH}-static && cd 
"${srcdir}"/build-${CARCH}-static

  ../${_basename}-${pkgver}${_wx_buildver}/configure \
--prefix=${MINGW_PREFIX} \
--host=${MINGW_CHOST} \
--target=${MINGW_CHOST} \
--build=${MINGW_CHOST} \
--disable-shared \
--enable-std_string \
--enable-iff \
--enable-permissive \
--enable-backtrace \
--enable-unicode \
--enable-graphics_ctx \
--enable-accessibility \
--disable-monolithic \
--disable-precomp-headers \
--with-msw \
--with-cxx=14 \
--with-opengl \
--with-libpng=sys \

Re: [Kicad-developers] [PATCH] Crash Reporter

[Tomasz Wlostowski]

On 30/07/2019 15:33, Nick Østergaard wrote:
> It was built like this:
> https://github.com/msys2/MINGW-packages/blob/c6dfad711f4d956a02e93026a0eb9a74ad6bfd65/mingw-w64-wxWidgets3.1/PKGBUILD
> 

Try building wx with --enable-backtrace --enable-debugreport

T.

___
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] Crash Reporter

[Tomasz Wlostowski]

On 30/07/2019 14:54, Nick Østergaard wrote:
> Exacept when I try to build it against wx 3.1 I get errors like:
> 
> debug_report.cpp:515:5: error: 'YAML_STACK_WALKER' was not declared in
> this scope
> 
> Building against 3.0 is ok, but it crashes when it is trying to upload
> a bug report.
> 
> I used -DwxWidgets_CONFIG_EXECUTABLE=${MINGW_PREFIX}/bin/wx-config-3.1
> to select wx 3.1.


Did you build wx with stack walker support?

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] Crash Reporter

[Tomasz Wlostowski]

On 29/07/2019 18:47, Nick Østergaard wrote:
> I rebased this for todays master and pushed it to:
> https://github.com/nickoe/kicad-source-mirror/tree/tom-crash-reporter-may27_rebased20190729
> 
> Diff view of changes:
> https://github.com/nickoe/kicad-source-mirror/compare/7b5b807...nickoe:tom-crash-reporter-may27_rebased20190729?expand=1
> 
> I don't think I let it follow the recent style in mater about the menu:
> https://github.com/nickoe/kicad-source-mirror/compare/7b5b807...nickoe:tom-crash-reporter-may27_rebased20190729?expand=1#diff-512ddae11b132baba0403a7df0fc215bR376
> 
> I did see it build on archlinux and it did report to launchpad with
> the menu entry to test the crash reporter.
> 
> I still need to test it on windows.

Hi Nick,

Thanks for rebasing & testing.

I did a Windows7 x64 build (with wx 3.1.1), works fine (including full
stack traces).

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] hotkeys behaviour changed recently?

[Tomasz Wlostowski]

On 24/07/2019 19:28, Jeff Young wrote:
> Hi Tom,
> 
> I’ll implement the preference if you’ll review my latest via push-n-shove 
> stuff. ;)
> 
Hi Jeff,

Sure - do you mean the stitching via pushing patch? I can also help with
the hotkey action preference.

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

[Kicad-developers] hotkeys behaviour changed recently?

[Tomasz Wlostowski]

Hi Devs,

I built today's master and to my surprise, pressing 'X' in pcbnew starts
immediately drawing a trace under the cursor, something I don't like
very much. Was this change accompanied by the (promised) option to
select between immediate action/activate tool behaviour of hotkeys
somewhere in the Preferences?

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

[Kicad-developers] [silly question] Are pad/pin names case-sensitive (and should they be)?

[Tomasz Wlostowski]

Hi,

I have design with a multi-row connector with pins labeled BGA-style
(a1, a2, etc.). I noticed the footprint for the same symbol in my
library has the pad names in uppercase (A1, A2) and so the netlister
doesn't connect these pins.

Is this the expected behaviour or should we make the pin/pad names
case-insensitive?

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] Crash Reporter

[Tomasz Wlostowski]

On 15/07/2019 14:43, Nick Østergaard wrote:
> Remind me, is this feature still in a seperate branch to master, or
> how is it enabled?

IIRC it's still tom-crash-reporter on my github and it's enabled in
CMake config (KICAD_CRASH_REPORTER=yes).

T.

> 
> On Thu, 11 Jul 2019 at 21:08, Nick Østergaard  wrote:
>>
>> @Tomasz Wlostowski  I just found that it looks like someone has
>> uploaded a wxwidgets 3.1 pkgbuild for the mingw-packages for msys2, I
>> could try to build and and rebuild your branch for windows.
>>
>> https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-wxWidgets3.1/PKGBUILD
>>
>> On Tue, 9 Jul 2019 at 14:09, Wayne Stambaugh  wrote:
>>>
>>> Tom,
>>>
>>> On 7/9/19 2:41 AM, Tomasz Wlostowski wrote:
>>>> On 06/07/2019 21:10, Ian McInerney wrote:
>>>>> Tom,
>>>>>
>>>>> Not to pile on the questions, but does the linux stack trace support
>>>>> exist in the entire 3.0.x line, or how far back does it go? Currently,
>>>>> the minimum version searched by cmake is 3.0.0, and some major linux
>>>>> distros only have 3.0.2 (Debian Stable, EPEL6/7, and Ubuntu 16.04 to
>>>>> name a few).
>>>>
>>>> Hi,
>>>>
>>>> Under liunx stack trace works fine in 3.0.2. Under Windows it's not
>>>> implemented at all (unless using a crazy hack self-exception-raising
>>>> hack that works only under MSVC).
>>>>
>>>> I can work this around by having our own Windows stack walker - after
>>>> all the whole purpose  of the crash reporter was easy debug reports for
>>>> Windows users. Under Linux everyone knows how to use a debugger,
>>>> otherwise it's impossible to work ;-)
>>> I'm assuming that you mean that you are going to pull the
>>> wxDebugReporter code from the 3.1 branch of wxWidgets which can be
>>> removed once wxWidgets 3.2 becomes the default.  If it's any more than
>>> that, I would rather wait until 3.2 is available.
>>>
>>>>
>>>> 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


___
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] Arc Adjustment proposal

[Tomasz Wlostowski]

On 10/07/2019 19:25, Seth Hillbrand wrote:
> 
> Proposed solution: I would like to adjust the pcbnew file format and
> internal SHAPE_ARC, DRAWSEGMENT arc and EDGE_MODULE arc to use a single
> format consisting of start point, mid point and end point.  Mid point
> here is defined as the point along the arc that is at the half-angle of
> the full arc.
> 

Hi Seth,

As I've been working on the Constraint Solver for a while, I'd like to
add my 5 cents too. The solver allows to define arcs in different ways:
- center/angles/radius
- start/end point (tangential to adjacent lines/arcs)

The input parameters to the CS is some subset of the above. The outputs
are start/end/midpoint, which define the geometry of an arc for other
processes (plotting/drawing/etc.). In order to derive the arc from its
definition based radius/angles, I need that radius and angles to be
stored in the file too - for example calculating the radius back and
forth from endpoints/midpoint would accumulate rounding errors.

What would you say about storing the start/end/midpoint and the set of
CS arc input parameters which have been specified by the user?

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] Crash Reporter

[Tomasz Wlostowski]

On 06/07/2019 09:04, Carsten Schoenert wrote:
> Hi,
> 
> Am 05.07.19 um 23:28 schrieb Ian McInerney:
>> 3.1.x is essentially only available on the lesser-known distros and as
>> additional packages for OpenSUSE. Aside from that, most distros run
>> anything between 3.0.2 and 3.0.4. (see
>> here: https://repology.org/project/wxwidgets/versions).

Hi,

wx 3.0.4 under Linux has stack trace support, so we don't need 3.1 for
the crash reporter to work under Linux. wx 3.0.x under MSYS doesn't. I
have no idea if it's a matter of build settings or just unimplemented
feature, I'll have a look at this later in the eveing.

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 v2 0/8] MSVC Build

[Tomasz Wlostowski]

On 05/07/2019 18:21, Seth Hillbrand wrote:
> I can't test the Windows functionality but this doesn't appear to break
> anything on Linux.
> 

I'm ok with Simon's patches. Can give them a try on MSVC, but I'm pretty
confident they will work already.

@Simon: Now that we'll be supporting MSVC, should we put a 'MSVC
precompiled library kit' somewhere on Kicad webpage to spare people the
hassle of finding the right version on Jenkins?

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] Crash Reporter

[Tomasz Wlostowski]

On 01/07/2019 23:49, Nick Østergaard wrote:
> Hello Tomasz
> 
> Do you have any comments on the wxwidgets version?

Hi Nick,

I have 3.1.1 in my MSYS environment, probably manually built.

We have two options:
- ask MSYS folks to update wxWidgets in the package repository,
- factor out stack trace implementation from newer wx version and
maintain it within kicad tree...

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] MSVC?

[Tomasz Wlostowski]

On 27/06/2019 12:02, Simon Richter wrote:
> Hi,
> 
> I've rebased[1] Tom's adaptation of my MSVC branch on top of current
> master, seems to compile still[2], except for the usual dependency problems
> with the generated lexers[3].
> 
> In this branch, we have an assembler based libcontext (taken over from
> boost) that is in a later commit replaced by Windows Fibers.
> 
> Before I do any further work on this branch: which implementation should we
> go with, so I can squash the branch to that state?
> 

Hi Simon,

Thanks for your work.

I'd go for the WinFiber API, it's stable, it's been in WinNT systems for
ages... The libcontext backend for winfibers is somewhat ugly (it's just
a proof of concept), would you be able to clean it up a bit before merging?

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] VECTOR2I and VECTOR2D

[Tomasz Wlostowski]

On 25/06/2019 21:16, Simon Richter wrote:
> Hi Wayne,
> 
> On Tue, Jun 25, 2019 at 12:36:36PM -0400, Wayne Stambaugh wrote:
> 
>> I guess I should comment on this seeing that I am the project leader.  I
>> am fine with refactoring as long as it's an improvement over existing
>> code.
> 
> The main improvement is going to be that we can dump the preprocessor magic
> for the internal units, which then allows us to share binary code between
> different kifaces, so we can turn common into a shared library.
> 

Hi Simon,

I guess you're going to add custom vector/point/dimension types that
contain units information? I would like to leave basic data structures
(e.g. VECTOR2I) unit-less.

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] Zones 45 degree

[Tomasz Wlostowski]

On 24/06/2019 15:05, Wayne Stambaugh wrote:

> The geometric constraint solver will be the solution for v6 but this
> still leaves us with the issue of what to do for the 5.1 branch. 

Hi Wayne,

I didn't notice it's for v5.1.x branch. In this case, Seth solution is
perfectly OK.

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] Zones 45 degree

[Tomasz Wlostowski]

On 24/06/2019 11:50, Simon Richter wrote:
> Hi,
> 
> On Mon, Jun 24, 2019 at 12:43:47AM -0400, Seth Hillbrand wrote:
> 
>> 1) a double-joint in the final connection
> 
> Hm, that might be an interesting creation mode: draw the outline as if it
> were a trace.
> 
> I'm not entirely convinced that there are many use cases for that though.

Hi,

This is coming in the geometric constraint solver work package...

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

[Kicad-developers] [patch] [eeschema] restore junctions if optimized away

[Tomasz Wlostowski]

Hi all,

Here's a patch that restores missing junctions in schematic documents
that have been saved with missing libraries/cache (see [1] for an
example). In this case, some connection points on wires can be optimized
away, resulting in

a lot of ERC errors.

@JP/Wayne, is this OK for you or would you prefer to fix it in another
way (I'm asking because I'm not very proficient with eeschema internals).

Cheers,

Tom

[1] https://github.com/yetifrisstlama/Marble/tree/symbol_cleanup

>From b145efafc388ea39a66b668d53f2a792fcb68570 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= 
Date: Sun, 23 Jun 2019 17:12:25 +0200
Subject: [PATCH] eeschema: automatically insert junctions at pin connections
 if needed during file load

EEschema optimizes wires by merging colinear segments. If a schematic opened without a valid
cache library or missing installed libraries and later saved, this optimization can cause connectivity
errors. In order to fix that we check each pin-wire connection and junctions if necessary.
---
 eeschema/files-io.cpp   |  7 +++
 eeschema/sch_edit_frame.cpp | 35 +++
 eeschema/sch_edit_frame.h   |  2 ++
 3 files changed, 44 insertions(+)

diff --git a/eeschema/files-io.cpp b/eeschema/files-io.cpp
index 48d57eaf9..0889dfcc5 100644
--- a/eeschema/files-io.cpp
+++ b/eeschema/files-io.cpp
@@ -384,6 +384,13 @@ bool SCH_EDIT_FRAME::OpenProjectFiles( const std::vector& aFileSet, in
 GetScreen()->SetGrid( ID_POPUP_GRID_LEVEL_1000 + m_LastGridSizeId );
 m_toolManager->RunAction( ACTIONS::zoomFitScreen, true );
 SetSheetNumberAndCount();
+
+// re-create junctions if needed. EEschema optimizes wires by merging
+// colinear segments. If a schematic is saved without a valid
+// cache library or missing installed libraries, this can cause connectivity errors
+// unless junctions are added.
+FixupJunctions();
+
 SyncView();
 GetScreen()->ClearDrawingState();
 
diff --git a/eeschema/sch_edit_frame.cpp b/eeschema/sch_edit_frame.cpp
index e3010f36e..56f8b2d34 100644
--- a/eeschema/sch_edit_frame.cpp
+++ b/eeschema/sch_edit_frame.cpp
@@ -1139,3 +1139,38 @@ const BOX2I SCH_EDIT_FRAME::GetDocumentExtents() const
 
 return BOX2I( VECTOR2I(0, 0), VECTOR2I( sizeX, sizeY ) );
 }
+
+void SCH_EDIT_FRAME::FixupJunctions()
+{
+SCH_SHEET_LIST sheetList;
+
+sheetList.BuildSheetList( g_RootSheet );
+
+for( unsigned i = 0; i < sheetList.size();  i++ )
+{
+std::vector anchors;
+
+SetCurrentSheet( sheetList[i] );
+GetCurrentSheet().UpdateAllScreenReferences();
+
+auto screen = GetCurrentSheet().LastScreen();
+
+for( SCH_ITEM* item = screen->GetDrawItems(); item; item = item->Next() )
+{
+if( item->Type() == SCH_COMPONENT_T )
+{
+auto cmp = static_cast( item );
+auto xform = cmp->GetTransform();
+
+for( auto pin : cmp->GetPins() )
+{
+auto pos = cmp->GetPosition() + xform.TransformCoordinate( pin.GetPosition() );
+if ( screen->IsJunctionNeeded( pos ) )
+{
+AddJunction( pos );
+}
+}
+}
+}
+}
+}
\ No newline at end of file
diff --git a/eeschema/sch_edit_frame.h b/eeschema/sch_edit_frame.h
index 10f01c61b..126f3e1fe 100644
--- a/eeschema/sch_edit_frame.h
+++ b/eeschema/sch_edit_frame.h
@@ -1026,6 +1026,8 @@ public:
 
 const BOX2I GetDocumentExtents() const override;
 
+void FixupJunctions();
+
 DECLARE_EVENT_TABLE()
 };
 
-- 
2.17.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] VECTOR2I and VECTOR2D

[Tomasz Wlostowski]

On 22/06/2019 17:41, Reece R. Pollack wrote:
> 
> While it is true that you can add two point coordinates and multiply by
> scalar 0.5 to get the midpoint, this is not true in the general case for
> arbitrary scalar multipliers. However, calculating the vector distance
> between two points, multiplying the vector by a scalar, then adding the
> resulting vector distance to the first point /does/ work in the general
> case.
> 
> This is exactly the sort of bug that can be avoided by not allowing
> arbitrary operations on random vectors.

I've never experienced a bug caused by mixing points/vectors together,
at least in the math code. For passing coordinates/measurements from/to
the GUI it might make sense to create custom types. Moreover, most if
not all geometry libraries I've known used the same class for points and
vectors. Single class for both is IMHO Occam's razor approach. As Seth
already remarked, I would like to hear a solid argument for splitting
point/vector classes, otherwise it looks like bikeshedding to me.

Tom

PS1. I'm surprised no one yet noticed the VECTOR2<> class has public x/y
 members, which is an unforgivable violation of the tenets of classical
OO design :-)

PS2. There are some more serious OOD violations in KiCad codebase. Would
anybody here volunteer to refactor the diamond in EDA_TEXT derivatives,
DRAWSEGMENT/EDGE_MODULE classes or global variables in eeschema?

___
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] VECTOR2I and VECTOR2D

[Tomasz Wlostowski]

On 22/06/2019 16:32, hauptmech wrote:
> After reading through vector2d.h and matrix3x3.h, I agree with Reece
> more or less. There is ambiguity in the word vector, between math
> vectors, spatial vectors, and c++ vectors. Context implies that VECTOR2
> refers math vectors, but then MATRIX3x3 * VECTOR2 is allowed which
> violates expectations.  POINT2 and SE2 or HOMOGENEOUS2  would set
> expectations better.

Actually, the name MATRIX3x3 name is a bit misleading - it actually
represents a 2D affine transform. Anybody willing to send a patch
renaming it to XFORM2D or something more descriptive? :)

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] VECTOR2I and VECTOR2D

[Tomasz Wlostowski]

On 22/06/2019 09:09, Greg Smith wrote:

> 
> I think the biggest point I am making is that, mathematically, a point
> is identical to a vector from 0,0.
> 

Hi Greg & Reece,

This is precisely the reason why we don't have separate point and vector
classes.

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] Ratsnest options

[Tomasz Wlostowski]

On 13/06/2019 15:35, Seth Hillbrand wrote:
>> I like that set of options. It fits in to my plan of absorbing as much
>> as possible from the left toolbar into the layer widget as part of my
>> overhaul of that part of the UI.
>> I also think it would be totally fine to have it *only* in the layer
>> widget, because we don't duplicate the other object visibility
>> controls in Preferences.
> 
> I like this even better.  Single location, placed with all view options.
>  Anyone have objections to this idea?

No objections, only praise here :-)

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

[Kicad-developers] BOARD_ITEM::Print() - is it used?

[Tomasz Wlostowski]

Hi Jeff,

While rebasing my branches on the latest master, I noticed you've
refactored the legacy Draw() methods into Print() and moved some legacy
code to pcb_legacy_draw_utils.cpp. Is this code called anywhere within
pcbnew? (IIRC Orson finished Cairo/GAL printing support quite a while
ago...).

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] Crash Reporter

[Tomasz Wlostowski]

On 11/06/2019 22:29, Nick Østergaard wrote:
> Too bad the gcc windows
> build crash report doesn't have a stack trace.  Maybe MSVC builds would
> have more debug info.

Hi Nick,

My build (wx 3.1.1) under MSYS has stack traces. Which version of
wxWidgets did you use?

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] Latest info on copper zones using solid polygons without outline thickness.

[Tomasz Wlostowski]

On 09/06/2019 20:51, jp charras wrote:
> First, thanks Tom for your test.
> 
> But are the drawing issues (calculation time and memory overflow) fixed
> by this change?
> They were the main reason of this change.

Yes, the VBO out-of-memory issue is gone now. I haven't measured yet how
much memory we saved but it's ~50% at least (given 6 vertices per
outline segment). Also, the connectivity calculation time got ~30%
better (31 seconds for the old, 20 s for the new one). Great job JP!.

> * Unless bugs, plot functions are updated and are compatible with both
> zone filling algos.

OK, didn't check it.
> 
> * The file format keep trace of the zone filling algo that filled the
> zone (of course, because do not know how the zone was filled can create
> serious issues):
> the flag " (filled_areas_thickness no)" is added in the zone section
> when the fill algo is "do not use thick outline".
> It also ensure a "old" Pcbnew version cannot create broken Gerber files.

OK.
> 
> * The accessor to know the fill algo used to fill the zone is:
>  bool GetFilledPolysUseThickness() const
> that returns false for the new algo.

> 
> * I was not aware of the connectivity issue. Please, fix it.
> Thanks.
> 
Fixed, thanks for the hint. I'll push my changes later in the evening.

> * About the zone setup dialog:
> For me, the choice is temporary, until we are confident with the new algo.
> Usually, when a new option is added, the default choice is: keep the old
> behavior.
> It avoid many bug reports.
> However make the new algo the default could be the best way to test it...
> I am not thrilled by messages like "Use legacy ..." because only core
> developpers know the difference between "legacy" and "current" or "new"
> about algorithms.

OK, in this case I wouldn't use the term 'higher quality', it might be
misleading to many users and make them think the new algorithm is
somewhat inferior to the old one.

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] Latest info on copper zones using solid polygons without outline thickness.

[Tomasz Wlostowski]

On 05/06/2019 21:21, jp charras wrote:

> It is on the master branch (just committed).

Hi JP,

I gave it a try with a bunch of designs. Here are my observations:
- The filled zones look correct on the super-complex board and the
number of unconnected nets is identical to the old algorithm.
- There's a serios issue: connectivity algo can generate false positives
(thinking zones are connected to tracks or other zones) because is still
assumes all zones have thick outlines (see CN_ZONE::ContainsPoint). Did
you foresee any means of indicating this in the file format? Should
Gerber/other exporters be changed accordingly?
- I would rephrase the board setup zone filling option choice - it's the
max approximation error that defines the drawing quality, not the fact
that zones are outlined with rounded segments. My choice for the option
would be a single option "Use legacy zone filling outline method", off
by default.
- @Wayne/Seth I agree with JP that the change to the zone filling
algorithm is not very intrusive (and I also trust Clipper's
inflate/erode algorithms - they're used in the current zone filler and
never failed us so far).

I can fix the connectivity issue. Who's in for Gerber/other exporters
(if needed?)

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] Latest info on copper zones using solid polygons without outline thickness.

[Tomasz Wlostowski]

On 05/06/2019 20:33, jp charras wrote:
> Could you test this version on your very large board, and said me if it
> fixes the very long time calculation to redraw the board on OpenGL.
> Thanks.

Sure, will do. Sorry that I didn't follow the whole discussion, where
can I find the latest code?

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] Crash Reporter

[Tomasz Wlostowski]

On 04/06/2019 17:11, Tomasz Wlostowski wrote:

> Hi Wayne,
> 
> It looks like I screwed up the exception handler under KiCad windows
> shell. Will fix soon.

Fixed in my github branch.

T.

___
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] Crash Reporter

[Tomasz Wlostowski]

On 03/06/2019 14:42, Wayne Stambaugh wrote:
> On 5/31/19 4:23 PM, Tomasz Wlostowski wrote:
>> On 30/05/2019 21:12, Wayne Stambaugh wrote:
>>> Nothing was displayed.  I was running from the project manager.  I even
>>> crashed the project manager.  I'm using msys2 to create mingw32 and
>>> mingw64 debug builds of KiCad.  I'm using wxWidgets 3.0.4 (not a debug
>>> build).  I did not check to see if the msys2 wxWidgets package builds
>>> are configured with wxDebugReport enabled so maybe that was the issue.
>>> I'll check the next time I'm in windows.  However, your debug reporter
>>> branch built fine so I suspect this was not the issue.
>>
>> Hi Wayne,
>>
>> Ddoes any window pop up when you trigger the crash from pcbnew running
>> in standalone mode? The only other difference I see is my wxWidgets
>> version is 3.1.1.
>>
>> Tom
>>
> 
> Tom,
> 
> I didn't test in the stand alone mode.  I'm traveling this week so I
> wont be able to test with windows again until I get home next weekend.
> As soon as I test the stand alone mode, I will let you know if it worked
> any differently than running from KiCad.
> 
Hi Wayne,

It looks like I screwed up the exception handler under KiCad windows
shell. Will fix soon.

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] Crash Reporter

[Tomasz Wlostowski]

On 30/05/2019 21:12, Wayne Stambaugh wrote:
> Nothing was displayed.  I was running from the project manager.  I even
> crashed the project manager.  I'm using msys2 to create mingw32 and
> mingw64 debug builds of KiCad.  I'm using wxWidgets 3.0.4 (not a debug
> build).  I did not check to see if the msys2 wxWidgets package builds
> are configured with wxDebugReport enabled so maybe that was the issue.
> I'll check the next time I'm in windows.  However, your debug reporter
> branch built fine so I suspect this was not the issue.

Hi Wayne,

Ddoes any window pop up when you trigger the crash from pcbnew running
in standalone mode? The only other difference I see is my wxWidgets
version is 3.1.1.

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] Crash Reporter

[Tomasz Wlostowski]

On 30/05/2019 16:46, Wayne Stambaugh wrote:
> Hey Tom,
> 
> On 5/29/2019 7:59 PM, Tomasz Wlostowski wrote:
>> On 30/05/2019 00:35, Wayne Stambaugh wrote:
>>> A `git pull` from https://github.com/twlostow/kicad-dev.git says I'm up
>>> to date.
>>>
>>> A note to the lead dev team, please do not push your personal
>>> development branches to the main kicad repo.  Thanks.
>>>
>>
>> Hi Wayne,
>>
>> I hope I didn't push anything personal to the repo on Launchpad (if so,
>> it could have happened by accident).
> 
> No problem.  I see that your already removed it from the main repo.  Thanks.
> 
>>
>> Just in case, I attached the crash reporter as patches.
> 
> I finally got the crash reporter to build on windows.  Just out of
> curiosity, does the crash reporter not show anything to the user?  When
> I force a crash using the menu entry, I don't see anything indicating
> that a crash report was generated or where the crash information might
> be saved.  Are my expectations out of line here or is there something
> wrong with the crash reporter on windows builds.  I haven't tested this
> on linux yet.  I should get to that later today.
> 

Hi Wayne,

It should show a big 'We're sorry, Kicad just crashed' window. Do you
run KiCad standalone or from the project manager? What is your build
configuration under Windows?

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] Crash Reporter

[Tomasz Wlostowski]

On 30/05/2019 00:35, Wayne Stambaugh wrote:
> A `git pull` from https://github.com/twlostow/kicad-dev.git says I'm up
> to date.
> 
> A note to the lead dev team, please do not push your personal
> development branches to the main kicad repo.  Thanks.
> 
It looks I'm the bad boy ;-) Just removed the accidentally pushed
Launchpad crash-reporter branch. Sorry for the confusion.

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] [RFC] Test for Copper zones using solid polygons without outline thickness.

[Tomasz Wlostowski]

On 29/05/2019 16:33, jp charras wrote:
> Attached a patch that modify the way filled areas (solid polygons) are
> built in copper areas.
> 
> Currently, solid polygons are slightly smaller than the exact area, and
> the polygon outlines have a thickness to fill the exact area.
> With this patch, polygon outlines have no thickness and the polygons
> have the exact area.
> 
> To test it on a given zone, the zone setting must be edited with the
> "Fill polys without thick outline" checked.
> 
> (If checked, the file will be no longer readable by "old" pcbnew versions)
> 
> Tom,
> 
> Could you test it with the large 32 layers boards that create drawing
> time issue?
> (You will have to edit each large copper zone)

Hi JP,

Thanks for the patch, I'll give it a try in the evening.

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] Crash Reporter

[Tomasz Wlostowski]

On 29/05/2019 06:07, Seth Hillbrand wrote:
> On 2019-05-28 12:13, Tomasz Wlostowski wrote:
>>
>> Done (tom-crash-reporter-may27 on my Github)!
>>
>> Tom
> 
> Hi Tom-
> 
> This looks very nice.  I like the implementation a lot!
> 
> Here are a couple minor bits:
> 
> 1) The force crash dialog says "Clicking on OK will crash KiCad" but the
> buttons say "Yes/No"
> 2) The crash report doesn't seem to pick up my build version
> information.  It says:
> 
> KiCad crash report, version 1.0
> --
> 
> application: kicad
> version: , release build
> 
> 3) The tabbing changes in CMakeLists.txt are odd.  Intentional?
> 4) There's an untranslated string in OnSendReport ("Error sending cebug
> report.")[sic]
> 
Hi Seth,

Just pushed a fix for these. Thanks for testing!

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] Crash Reporter

[Tomasz Wlostowski]

On 27/05/2019 17:39, Seth Hillbrand wrote:
> On 2019-05-02 17:41, Tomasz Wlostowski wrote:
>> On 02/05/2019 07:06, Wayne Stambaugh wrote:
>>>
>>> By chance did you build with OCC instead of OCE which is what I am
>>> using?  Please fix this when you get a chance, I would like to get this
>>> merged but I need to be able to test.
>>>
>>> Why did your remove the GDK_* and GTK_* environment variables from
>>> APP_KICAD ctor?  Wont this break the compatibility support we currently
>>> have?
>>>
>>> I noticed quite a bit of trailing whitespace in patches 5 and 10 so that
>>> will need to be cleaned up.
>>>
>>> Please send me the link to your remote branch for this.  It's easier for
>>> me to just pull a branch into my repo than apply a large patch set using
>>> `git am`.
>>
>> Hi Wayne,
>>
>> Probably I screwed something up while rebasing the code on top of fresh
>> master. I'll check/fix the errors in the evening.
>>
>> Greetings from CO,
>> Tom
> 
> Ping!

Done (tom-crash-reporter-may27 on my Github)!

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] Crash Reporter

[Tomasz Wlostowski]

On 27/05/2019 17:39, Seth Hillbrand wrote:
> On 2019-05-02 17:41, Tomasz Wlostowski wrote:
>> On 02/05/2019 07:06, Wayne Stambaugh wrote:
>>>
>>> By chance did you build with OCC instead of OCE which is what I am
>>> using?  Please fix this when you get a chance, I would like to get this
>>> merged but I need to be able to test.
>>>
>>> Why did your remove the GDK_* and GTK_* environment variables from
>>> APP_KICAD ctor?  Wont this break the compatibility support we currently
>>> have?
>>>
>>> I noticed quite a bit of trailing whitespace in patches 5 and 10 so that
>>> will need to be cleaned up.
>>>
>>> Please send me the link to your remote branch for this.  It's easier for
>>> me to just pull a branch into my repo than apply a large patch set using
>>> `git am`.
>>
>> Hi Wayne,
>>
>> Probably I screwed something up while rebasing the code on top of fresh
>> master. I'll check/fix the errors in the evening.
>>
>> Greetings from CO,
>> Tom
> 
> Ping!

Hi Seth,

Rebasing it on the latest master right now. I'm still getting some
Windows build issues, hope to sort them out by tomorrow.

T.

___
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] Undo paradigms

[Tomasz Wlostowski]

On 27/05/2019 16:46, Jeff Young wrote:
> Hi Seth,
> 
> The Eeschema has one advantage that if you mess it up you get too many undo 
> steps rather than too few.  But it is somewhat crankier code to get right.
> 
> I agree that we should have only one scheme.  I don’t believe anyone’s 
> working on it — although it would probably be Tom if anyone was.

Hi,

Some time ago we introduced with Orson the COMMIT object, which manages
atomic updates to the PCB, lightweight notifications as well as creation
of undo entries. How about porting this to eeschema?

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] Kicad's way of drawing filled zones

[Tomasz Wlostowski]

On 13/05/2019 12:58, jp charras wrote:
> If we are talking about V6.0 version, we should add zone property field
> in the file format like (outline_thickness 0.0) to avoid serious issues
> (generating broken boards for fabrication).
> 

Hi JP,

Are you going to work on this (commit code)?

> Perhaps also adding a parameter like (circle_optimization [low, normal,
> high] to optimize shapes with arc/circle items (perhaps useful in
> microwave applications)

I'm OK with it. Seth?

> 
> I am not a specialist of Hyperlynx and other similar tools, but i am
> guessing it is not the only one tool that does not handle thick outlines
> in polygons.

IIRC Altium and Cadence store filled zones as borderless polygons.

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] Removing segment hard-coding

[Tomasz Wlostowski]

On 16/05/2019 20:44, Jon Evans wrote:
> I can think of at least two alternatives:
> 
> 1) automatic performance tuning based on self-benchmarking
> 
> 2) a "graphics performance" setting (high/medium/low) that changes
> multiple things under the hood.

Hi Jon,

I'm afraid this would be difficult to achieve without breaking the
WYSIWYG principle - board geometry should look exactly the same as in
the Gerber files (so IMHO we shouldn't allow for tweaking the number of
arc approx segments for display purposes only).

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] Kicad's way of drawing filled zones

[Tomasz Wlostowski]

On 13/05/2019 17:46, Wayne Stambaugh wrote:
> I guess I should weigh in on this issue.  I would prefer we exhaust all
> other options before bumping opengl to some later version.

Hi Wayne,

I think JP's solution is the way to go, it fixes the original issue
instead of working it around. What's your opinion?

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] Kicad's way of drawing filled zones

[Tomasz Wlostowski]

Hi,

I've been away for the weekend, here's the reply for all the
questions/comments:

> As far as I am aware, all commercial tools in the space have more
advanced / modern system requirements than KiCad
> The integrated Intel GPUs that are old enough to not have OpenGL 3.0
are no longer supported by Intel

Most (if not all) commercial EDA tools that use GPUs run under Windows
only, which - paradoxically - gives the authors more freedom while
choosing which GPU features to use. While OpenGL 2.1 (with only VS/PS
shaders) is more-or-less supported on all Linux distros, GL 3.0 (with
Geometry Shader support) is at least troublesome. I'm not sure if the
speed/memory improvements provided by using GS will be more beneficial
than additional support effort (fallback to 2.1 on unsupported systems?).

> I have a *strong preference* for the solution 3.

JP, You convinced me. This will solve the drawing issue without using
heavy weapons (like GL 3.0). The only thing I'm not sure about is how to
communicate the zone has a 0-width outline (still keeping the minimum
width parameter in the file). Should we add zone property field in the
file format?

Removing "thick" polygon outlines solves some other issues too - I
noticed Hyperlynx stores polygons with 0-width outlines, so the ones
exported currently from KiCad are thinner than they should be because
there's no inflation code in the exporter. Other EDA software exporters
might also be affected.

> I don't think any desktop computer released after 2010 would have
issues with GL3 unless the hardware/OS is defective in some way.

Hardware wouldn't, but drivers would. I still have issues running Half
Life 2 EP2 (a 9-year old game) on a 4-year old laptop with Intel
graphics under Linux...

> Is it possible to determine openGL hardware support at runtime and use
advanced API on newer machines while switching to fallback for older ones?

I'd rather go to JP's idea of not using thick outlines instead of
supporting rendering backends for two different OpenGL versions.

> I don't see the need to tie OS support to hardware support. It's
totally plausible to say, for example, "we'll support users on Debian 6
but onlyif they have a <10 year old graphics card"

Expect a lot of complaints on the bug tracker and the forums then :)

> What about moving the knock-out code to the relative-error calculation
first?  Vias probably don't need 32 segments around the edge.  Look at
buildZoneFeatureHoleList().  We currently use 32 as the minimum value
for segments per circle

Good idea, especially combined with JP's solution. Are you going to fix
this?

> For instance: trying to render just the visible part of the board (
culling ) or on the case on render the full board, implement some kind
of "level of detail" to render a less accurate version ? ( eg as you
pointed the vias could be a special case and simplified while on distance )

We only render the visible part of the board only (glDrawElements() with
indices generated from the currenlty visible item set obtained by
traversing the VIEW's rtree). I'm not sure if it the geometry LOD
wouldn't severely degrade the performance (the cost of generating and
uploading a 1 GB VBO on LOD change - most of board geometry is cached in
the GPU memory) or be just complex to implement (GAL has no LOD for
primitives cached in the GPU RAM).

> - render the via outline using a rectangular texture with transparent
corners
> - render the via hole in the zone as a simple square, side length =
via diameter, and underneath the texture, so the texture's curve fills
in the square's corners?

Vias are already rendered using 1 triangle (not even quad) per each,
except the 'texture' is generated by the pixel shader instead of being
static.

> Would be possible to share that Victor-s project or where we can get it?

I have been asked to not share the board. Please ask Victor if he'd want
to send you the design. Might be useful for optimizing 3D support.

Best,
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

[Kicad-developers] Kicad's way of drawing filled zones

[Tomasz Wlostowski]

Hi,

I've been recently playing with Victor's huge 32-layer PCB design and
trying to improve the performance of pcbnew for larger designs. This
board causes even pretty decent PCs to crash/render glitches due to
pcbnew's enormous VBO (Vertex Buffer) memory consumption.

It turns out it's caused by the way KiCad renders filled zones:
- the inside of a zone is drawn/plotted as a filled polygon with 0-width
boundary. This one not a problem - we already triangulate the polygons
and I recently developed a patch for the OpenGL GAL that allows reusing
vertices of triangulated polys in the VBO/Index buffer to further reduce
memory footprint.
- the thick outline is drawn with rounded segments with the width =
minimum width of the polygon. Since we don't have arcs in polygons, each
of round features (e.g. vias) surrounded by a zone gets a ton of tiny
segments in the polygon outline. Each rounded segment in OpenGL is
composed of 2 triangles, hence 6 vertices (that can't be reused...). For
Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
polygons alone. Disabling the outline drawing makes the renderer work
smooth again.

I've been experimenting with some ways to fix this:
- generating the thick outline strokes using a Geometry Shader (which
means bumping up GL 3.0+), which means farewell to many Linux/older
integrated Graphics users.
- caching a triangulated polygon which is a boolean sum of the filled
inside and the thick stroked outline. This takes a lot of time (~2
minutes for Victor's design) to load and still takes quite a bit of VBO
memory. Another downside is that the polygons are not fully WYSIWYG
(outline segments have true rounded corners, while the corners of the
displayed shape would be approximated with line segments).
- change the way KiCad handles filled zones to calculate the (stroke +
inside) boolean sum during zone filling process. It means changes to the
plotting/GAL/3D code, but no changes to the file format. We'll also be
forced to inform the users that they have to refill the zones if they
read a file generated by an older KiCad version.


Which solution would you prefer?
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] 6.0 task proposal

[Tomasz Wlostowski]

On 10/05/2019 11:46, John Beard wrote:
> Do the tool actions actually even need to know their hotkey? I think
> perhaps they shouldn't really care *what* the hotkey is or even if one
> is set, it's not their problem. It's the tool framework that should be
> maintaining this mapping.

Hi,

+1 here. The hotkeys (standard, sequential and
whatever-else-we-come-up-with) can be kept separate from the ACTION
objets in the code and stored in a configuration file. This would let
people coming from other EDA packages to have their own config files
with custom hotkey mappings.

IMO the same approach later can be used for toolbar/menu layouts.

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] Some first impressions on our tool framework

[Tomasz Wlostowski]

On 07/05/2019 07:47, Wayne Stambaugh wrote:
> 
> On 5/6/2019 9:02 PM, Tomasz Wlostowski wrote:
>> On 06/05/2019 09:48, Jeff Young wrote:
>>> 1) I hate the coroutines.  They truncate backtraces in the debugger.
>>
>> Hi,
>>
>> How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on
>> Windows? I have working implementation of the latter already in the MSVC
>> branch. Are there any reasons to not use ucontext under Linux/OSX?
>>
>> Tom
>>
> 
> I don't think we should be tackling this for v6.  Our v6 task list is
> plenty long already.  Let's shelve this discussion until v7 so we can
> take our time and come up with a plan that wont be too disruptive.

Hi Wayne,

I don't have any plans to rewrite the coroutine code during V6
development cycle or doing any other radical changes. The only stuff I
want to add is:
- winfiber backend (already done), which removes assembly code for
Win32/Win64 - the last obstacle for easy MSVC builds.
- proper caller address in the stack frame (so that Jeff will see full
stack traces)

Both of these changes are relatively minor.

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] Some first impressions on our tool framework

[Tomasz Wlostowski]

On 06/05/2019 09:48, Jeff Young wrote:
> 1) I hate the coroutines.  They truncate backtraces in the debugger.

Hi,

How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on
Windows? I have working implementation of the latter already in the MSVC
branch. Are there any reasons to not use ucontext under Linux/OSX?

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] Some first impressions on our tool framework

[Tomasz Wlostowski]

On 06/05/2019 09:48, Jeff Young wrote:
> 1) I hate the coroutines.  They truncate backtraces in the debugger.

Hi Jeff,

I'm thinking how to improve this. Perhaps we can 'fix' a fake stack
frame that will allow the debugger to unwind the stack past the
coroutine entry point...

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] eemodern branch

[Tomasz Wlostowski]

++

05.05.2019 11:40 Seth Hillbrand  napisał(a):
+1

Am 2019-05-05 13:33, schrieb Jon Evans:
> +1
> Merge it and get more testing.  It's already worlds better than the
> status quo.
>
> On Sun, May 5, 2019 at 12:12 PM Jeff Young  wrote:
>
>> I think this is ready to merge.  Any objections?
>>
>> ___
>> 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] eemodern merge request

[Tomasz Wlostowski]

On 02/05/2019 15:51, Jeff Young wrote:
> The eeschema modern toolset is “finished”.
> 
> It can be found at origin/eemodern.  A bit of testing before merging might be 
> in order….

Hi Jeff,

I noticed eemodern it's missing mouse drag action (i.e. dragging a
selected wire/component/etc. just starts drawing another selection
rectangle). Are you planning to add it (I can also contribute this
feature - long flight tomorrow should be enough to code it ;-)

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] Crash Reporter

[Tomasz Wlostowski]

On 02/05/2019 07:06, Wayne Stambaugh wrote:
> Hey Tom,
> 
> I finally got around to testing this.  I could not get it to build on
> windows or linux.  I'm getting the following compiler error on both 32
> and 64 bit windows and linux builds:
> 
> E:/msys64/home/Wayne/src/kicad-lp-clone/common/debug_report.cpp: In
> member function 'void DEBUG_REPORT::buildVersionInfo(wxString&)':
> E:/msys64/home/Wayne/src/kicad-lp-clone/common/debug_report.cpp:292:61:
> error: 'OCC_VERSION_COMPLETE' was not declared in this scope
>  aMsg << indent4 << "opencascade-community-edition: " <<
> OCC_VERSION_COMPLETE << eol;
> 
> ^~~~
> [ 43%] Building CXX object common/CMakeFiles/common.dir/eagle_parser.cpp.obj
> E:/msys64/home/Wayne/src/kicad-lp-clone/common/debug_report.cpp:292:61:
> note: suggested alternative: 'STG_E_INCOMPLETE'
>  aMsg << indent4 << "opencascade-community-edition: " <<
> OCC_VERSION_COMPLETE << eol;
> 
> ^~~~
> 
> STG_E_INCOMPLETE
> 
> By chance did you build with OCC instead of OCE which is what I am
> using?  Please fix this when you get a chance, I would like to get this
> merged but I need to be able to test.
> 
> Why did your remove the GDK_* and GTK_* environment variables from
> APP_KICAD ctor?  Wont this break the compatibility support we currently
> have?
> 
> I noticed quite a bit of trailing whitespace in patches 5 and 10 so that
> will need to be cleaned up.
> 
> Please send me the link to your remote branch for this.  It's easier for
> me to just pull a branch into my repo than apply a large patch set using
> `git am`.

Hi Wayne,

Probably I screwed something up while rebasing the code on top of fresh
master. I'll check/fix the errors in the evening.

Greetings from CO,
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] eemodern merge request

[Tomasz Wlostowski]

On 02/05/2019 15:51, Jeff Young wrote:
> The eeschema modern toolset is “finished”.
> 
> It can be found at origin/eemodern.  A bit of testing before merging might be 
> in order….
> 

Jeff,

Wow, I'm speechless. You did it lightning fast. I'll try to compile it
in the evening and give you some feedback!

Greetings from Colorado,
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] HotKey user model

[Tomasz Wlostowski]

On 26/04/2019 13:12, jp charras wrote:
> Le 26/04/2019 à 19:21, Jeff Young a écrit :
>> I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys.  It appears the 
>> design goal is to have these be immediate actions (that is, they start a 
>> wire or a track, rather than just selecting the wire or track tool).
>>
>> Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’, etc.  
>> (None of these perform an immediate action today, right?)
> 
> Why do you want to change the previous behavior? Is it not good?
> 

Hi JP,

I'm from the 'hotkey activates the tool camp' like Brian (for similar
reasons).

I realize hotkeys and accelerators working *simultaneously* would be
difficult to have, but what about an option to select the 'start tool
here'/'activate tool' hotkey behaviour globally?

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] A neat decision-making scheme

[Tomasz Wlostowski]

On 21/04/2019 18:08, Jeff Young wrote:
> In my last few years at Adobe I worked with Day Software in Switzerland which 
> we had just acquired.  They did a lot of open-source stuff with Apache and 
> had this neat decision-making scheme (which may have originated at Apache — 
> I’m unaware of its source):
> 
> If you need direction on something, you send an email to the list.  (This 
> part is no different than what we do today.)
> 
> If someone agrees, they reply with “+1”.
> 
> If someone wants to halt progress until either some discussion is had or 
> until another direction is chosen they veto with a “-1”.
> 
> When you accumulate three +1s and are clear of -1s you’re good to go.
> 
> If you do get one or more -1s you’re blocked until those folks change their 
> input to either a “+0” or a “+1”.
> 
> If you haven’t yet reached three +1s after a time-out period (I think we used 
> a week but it might have been two), but you are clear of -1s, you can send a 
> message to the list indicating a default-consensus and go ahead and implement 
> it.
> 
> Might this be useful for us?
+1.

T.

> ___
> 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] Zoom & Grid changes

[Tomasz Wlostowski]

On 18/04/2019 17:51, Jeff Young wrote:
> Nope.  For those that I’ve moved, the old ones are gone.
> 
> Note that I haven’t implemented a modern selection model yet, so the user 
> model is still “legacy”.  I’ve just replaced all the drawing code with new 
> code using INTERACTIVE_TOOLs and going through TOOL_DISPATCHER, etc.
> 
> The selection model is a big enough change that I’ll need to do that on a 
> branch.
> 

Hi Jeff,

That's what probably misled me into thinking I'm working with the old
toolset :-).

Looking forward to the selection model implementation, great job Jeff!

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] Zoom & Grid changes

[Tomasz Wlostowski]

On 18/04/2019 17:20, Jeff Young wrote:
> Hi Tom,
> 
> They’re in master.

OK, but do I need to activate the modern toolset somehow? It seems that
by default eeschema uses the old one?

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] Zoom & Grid changes

[Tomasz Wlostowski]

On 17/04/2019 22:51, Jeff Young wrote:
> Drawing tools (and zoom-to-selection) moved to modern toolset.
> 
Hi Jeff,

How can I try them out?

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] Crash Reporter

[Tomasz Wlostowski]

On 16/04/2019 23:25, Mark Roszko wrote:
> Just to throw it out there
> 
> Did you consider at all at using something off the shelf such as
> Breakpad which both Mozilla and Chrome use?
> https://wiki.mozilla.org/Breakpad 
> https://github.com/google/breakpad

Hi Mark,

I took some inspiration from Mozilla (mainly the 'apologies' text ;-),
but never had a serious look at Breakpad. I'm worried how many external
dependencies it would bring (both on the software packaging and server
side). Has anybody here used it?

> 
> There's then some off the shelf software potentially for processing
> Breakpad reports such as this service:
> https://help.backtrace.io/pricing-data-protection-privacy-and-terms/pricing-and-tiers/backtrace-for-open-source
>  
For the moment, the reporter uses a simple YAML-based format that is
both human- and machine-readable. As such it's IMHO already quite
useful, especially for tracking down Windows bugs (have you ever used
GDB under Windows? :D)

> 
> 
> Also do the data reports avoid identifying info such as usernames which
> might fall under GDPR? Not to mention we'll need a privacy notice added
> in somewhere anyway for collecting data.

The user can always review the report text and (s)he's informed about
this. No data is sent automatically. The report doesn't contain the
username unless there's some DLLs/executables linked to KiCad existing
in the home directory. No other personal data is collected (unless paths
to system libraries/CPU register values/stack trace are considered
personal data).

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] Crash Reporter

[Tomasz Wlostowski]

On 16/04/2019 22:52, Seth Hillbrand wrote:
> Am 2019-04-14 18:50, schrieb Tomasz Wlostowski:
>> Dear all,
>>
>> The attached patchset introduces a builtin crash reporter for Kicad -
>> that is a window that pops up in case of a segmentation fault/other
>> serious error, kindly apologizes to the user and lets him/her submit
>> (anonymously) a bug report to us. It's loosely based on wxDebugReport,
>> with a lot of new code (i.e. stack walker for windows or more meaningful
>> report format...).
>>
>> This is particularly targeted at Windows/OSX users, since getting a
>> useful stack trace on these systems is considerably more difficult (at
>> least for non-programmers) than on (L)Unixes.
>>
>> I invite you to test it, in case recent KiCad nightlies have become too
>> stable, you can always simulate a crash through 'Help->Simulate Kicad
>> Crash'.
>>
>> Cheers,
>> Tom
> 
> 
> Hi Tom-
> 
> I'm very happy to see these patches and am excited to try them out! 
> Unfortunately, like others, I won't have time to really poke at this
> until after KiCon.  But if others are comfortable with it, please don't
> wait for me.

Thanks Seth, no rush. See you in Chicago :)

> 
> One addition that would be nice is making the destination URL and
> enabling/disabling of the reporter advanced config settings instead of
> defines.

Good idea. I can add this.

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] new macos requirements, could use some help

[Tomasz Wlostowski]

On 13/04/2019 22:57, Adam Wolf wrote:
> Oh, that's what I get for trying to post from my phone...
> 
> I forgot the link, and without it, my post seems super ominous!  Sorry
> about that!
> 
> https://developer.apple.com/news/?id=04102019a

So does this mean we can't distribute our software anymore without
Apple's cryptographical blessing?

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] Eeschema modern toolset

[Tomasz Wlostowski]

On 12/04/2019 12:17, Jeff Young wrote:
> Hi Tom,
> 
> I was going to start laying some of the ground-work for Eeschema’s modern 
> toolset.  Do you already have some of this in a branch that you can share, or 
> should I go ahead and start with master?

Hi Jeff,

I've started working on something that might have impact for the modern
toolset for eeschema (and other KiCad tools), possibly making the
migration easier and allowing for more code reuse. It's removing the
dependencies of the tool classes from PCB_EDIT_FRAME and its ancestors.
The goals are:
- no direct dependencies on the toolkit in the tool/model classes -
opens the way to migration to any future toolkit of our choice
- have all interactive-related objects together in some sort of 'editor
context' class:

class EDITOR_CONTEXT_BASE
{
virtual KIGFX::VIEW* View() const = 0;
virtual KIGFX::VIEW_CONTROLS* ViewControls() const = 0;
virtual EDA_ITEM* Model() const;

// handles dialogs, prompts, updating the user interface
UI_MANAGER_BASE* UIManager() const;

// specialization of GRID_HELPER for particular appliaction
GRID_MANAGER_BASE* GridManager() const;

// Undo/redo list (factored out from EDA_BASE_FRAME)
UNDO_MANAGER *UndoManager() const;

// The tool manager (and all the tools)
TOOL_MANAGER *ToolManager() const;

// Creates an empty commit to board/sch/etc. Put other syntax sugar here...
virtual COMMIT* NewCommit();
};

I'll clean up the code I already have (empty classes for the moment) and
push it to a new branch. Will let you know as soon as it's done...

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] small typos (missing spaces)

[Tomasz Wlostowski]

On 09/04/2019 18:43, Kerusey Karyu wrote:
> Guys
> 
>> #: pcbnew/exporters/export_hyperlynx.cpp:190
>>
>> m_reporter->Report(
>>   _( "File contains pad shapes that are not supported by the"
>>  "Hyperlynx exporter (oval, rectangle, circle). They have been"
>>  "exported as oval pads." ),
>>  REPORTER::RPT_WARNING );
> 
> Is there no contradiction here or poor wording?
> 
> The first sentence says that oval, rectangular or circular are *not*
> supported - as I understand. But finally these are still exported as
> ovals, which are... after all, unsupported.
> 
> Maybe:
> 
> "File contains pad shapes that are not supported by the"
> "Hyperlynx exporter. Only oval, rectangle, circle are allowed."
> "During export, they will be changed to ovals."
> 

My bad, please send me the patch with the wording you prefer. But didn't
you notice this message is not (yet) printed anywhere as the m_reporter
is always null?

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] Merge schedule

[Tomasz Wlostowski]

On 08/04/2019 13:58, Nick Østergaard wrote:
> Hi Tomasz
> 
> I was wondering about this yesterday. Has it even been merged on master?
> 
> I think I would prefer not to merge it on stable

Hi Nick,

I don't plan to merge it to any stable release anytime soon. I meant the
nightlies...

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] Merge schedule

[Tomasz Wlostowski]

On 05/04/2019 12:09, Jeff Young wrote:
> I’ve got a changelist which cleans up the various SCH_ and LIB_ Draw() 
> routines to remove the interactivity features (since they’re now print-only).
> 

Hi all,

Since we're discussing merging again, may I push my Crash Reporter patch
(touches mostly kiface/single_top stuff, that I guess no one is working
at for the moment)?

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] [RFC] Exporter for Mentor Hyperlynx

[Tomasz Wlostowski]

On 05/04/2019 18:04, Wayne Stambaugh wrote:
> Tom,
> 
> On 4/4/19 8:16 PM, Tomasz Wlostowski wrote:
>> Hi,
>>
>> We needed to do some signal/power integrity simulations on one of our
>> Kicad designs and in order to do that, we needed to convert a Kicad PCB
>> to Hyperlynx format. Luckily, the format is simple, all text and well
>> documented in [1], so here comes a patch that adds a Hyperlynx exporter.
>>
>> Notes:
>> - since Kicad doesn't have a concept of board stackup (permittivities,
>> loss tangent, dielectric types, etc.), the exporter writes a dummy
>> stackup. Edit it to match the PCB spec in Hyperlynx.
>> - no support for offset pad holes, slotted pad holes,
>> trapezoid/polygonal pads (it seems HL format doesn't support such
>> features or I need to figure out how to emulate them).
>> - no support for thermal pads (yet)
>> - no error reporting.
>>
>> Looking forward to your feedback & wish you happy testing,
>> Tom
>>
>> [1] http://www.ibis.org/birds/bird33.txt
> 
> Your patch built and tested without issue.  I just have a few minor
> comments:
> 
> Please remove all commented out debugging output code and one instance
> of wxLogDebug unless you are planning to some additional debugging in
> the future.  In which case, use wxLogTrace.
> 
> Per section 4.2 in the coding policy[1], in source files there should be
> 2 blank lines between functions except when they are in the class
> definition in which case there should be 1 blank line.  I also saw a
> couple of if{} statements with missing blank lines above.
> 
> It is no longer necessary to wrap strings with the wxT() macro when
> using the wxString assignment operator.
> 
> The OUPUTFORMATTER::Print function can throw an IO_ERROR exception.  If
> you don't handle this, KiCad will most likely crash when it occurs.  It
> would be a good idea to add a try/catch block in
> HYPERLYNX_EXPORTER::Run() and return false when a exception is caught.
> 
> The copyright dates in the qa files are 2018.

Thanks Wayne,

It looks my settings for VSCode formatter don't catch all Kicad Coding
Style rules. Need to fix that ;-). I'll push a version with fixes
(including error handling via exceptions).

Tom

PS. We need to think about factoring out the exporters (including their
private settings dialogs) to some sort of plugins...




___
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] [RFC] Exporter for Mentor Hyperlynx

[Tomasz Wlostowski]

On 05/04/2019 16:48, John Beard wrote:
> Hi Tom,
> 
> Can the hyperlink export test not exist in the existing qa_pcbnew
> test? The code is all in pcbnew's library, so why not just mirror the
> source layout and put your test as
> "qa/pcbnew/exporters/test_export_hyperlynx.cpp"?
> 
> Otherwise we will eventually have dozens and dozens of tiny unit test
> executables all in need of CMake files and linking.
> 
> OTOH, if the hyperlynx stuff was a separate library, then it would
> make sense to have a separate test exec. At that point, we'd
> presumably have shared libs anyway.

Hi John,

It's just my internal test program that I accidentally put in the patch.
I don't like clicking through the pcbnew GUI just to test the exporter.
There's no formal unit tests for the exporter yet, I'll remove it from
the final commit.

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] [RFC] Exporter for Mentor Hyperlynx

[Tomasz Wlostowski]

On 05/04/2019 02:16, Tomasz Wlostowski wrote:
> Hi,
> 
> We needed to do some signal/power integrity simulations on one of our
> Kicad designs and in order to do that, we needed to convert a Kicad PCB
> to Hyperlynx format. Luckily, the format is simple, all text and well
> documented in [1], so here comes a patch that adds a Hyperlynx exporter.

Anybody opposed to merging this?

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

[Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

[Tomasz Wlostowski]

Hi,

We needed to do some signal/power integrity simulations on one of our
Kicad designs and in order to do that, we needed to convert a Kicad PCB
to Hyperlynx format. Luckily, the format is simple, all text and well
documented in [1], so here comes a patch that adds a Hyperlynx exporter.

Notes:
- since Kicad doesn't have a concept of board stackup (permittivities,
loss tangent, dielectric types, etc.), the exporter writes a dummy
stackup. Edit it to match the PCB spec in Hyperlynx.
- no support for offset pad holes, slotted pad holes,
trapezoid/polygonal pads (it seems HL format doesn't support such
features or I need to figure out how to emulate them).
- no support for thermal pads (yet)
- no error reporting.

Looking forward to your feedback & wish you happy testing,
Tom

[1] http://www.ibis.org/birds/bird33.txt
>From e966c63a6f00959e359be36bfc0b8206e01ed4bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20W=C5=82ostowski?= 
Date: Thu, 4 Apr 2019 18:07:12 +0200
Subject: [PATCH] pcbnew: Initial support for Mentor Hyperlynx export

---
 pcbnew/CMakeLists.txt |   1 +
 pcbnew/dialogs/dialog_export_idf.cpp  |   1 +
 pcbnew/exporters/export_hyperlynx.cpp | 547 ++
 pcbnew/menubar_pcb_editor.cpp |   5 +
 pcbnew/pcb_edit_frame.cpp |  29 +
 pcbnew/pcb_edit_frame.h   |   7 +
 pcbnew/pcbnew_id.h|   1 +
 qa/CMakeLists.txt |   1 +
 qa/hyperlynx_export/CMakeLists.txt|  64 ++
 qa/hyperlynx_export/test_hyperlynx_export.cpp |  61 ++
 10 files changed, 717 insertions(+)
 create mode 100644 pcbnew/exporters/export_hyperlynx.cpp
 create mode 100644 qa/hyperlynx_export/CMakeLists.txt
 create mode 100644 qa/hyperlynx_export/test_hyperlynx_export.cpp

diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 3bbdd8723..9f0f5eac1 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -193,6 +193,7 @@ set( PCBNEW_IMPORT_GFX
 )
 
 set( PCBNEW_EXPORTERS
+exporters/export_hyperlynx.cpp
 exporters/export_d356.cpp
 exporters/export_footprint_associations.cpp
 exporters/export_gencad.cpp
diff --git a/pcbnew/dialogs/dialog_export_idf.cpp b/pcbnew/dialogs/dialog_export_idf.cpp
index e9e16bfbc..882224b7c 100644
--- a/pcbnew/dialogs/dialog_export_idf.cpp
+++ b/pcbnew/dialogs/dialog_export_idf.cpp
@@ -229,3 +229,4 @@ void PCB_EDIT_FRAME::OnExportIDF3( wxCommandEvent& event )
 return;
 }
 }
+
diff --git a/pcbnew/exporters/export_hyperlynx.cpp b/pcbnew/exporters/export_hyperlynx.cpp
new file mode 100644
index 0..5f5c678dd
--- /dev/null
+++ b/pcbnew/exporters/export_hyperlynx.cpp
@@ -0,0 +1,547 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2019 CERN
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, you may find one here:
+ * http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ * or you may search the http://www.gnu.org website for the version 2 license,
+ * or you may write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static double iu2hyp( double iu )
+{
+return iu / 1e9 / 0.0254;
+}
+
+class PAD_STACK
+{
+public:
+PAD_STACK( BOARD* aBoard, const D_PAD* aPad );
+PAD_STACK( BOARD* aBoard, const VIA* aVia );
+~PAD_STACK(){};
+
+
+bool isThrough() const
+{
+return m_type == PAD_ATTRIB_HOLE_NOT_PLATED || m_type == PAD_ATTRIB_STANDARD;
+}
+
+bool operator==( const PAD_STACK& other ) const
+{
+if( m_shape != other.m_shape )
+return false;
+
+if( m_type != other.m_type )
+return false;
+
+if( isThrough() && other.isThrough() && m_drill != other.m_drill )
+return false;
+
+if( m_sx != other.m_sx )
+return false;
+
+if( m_sy != other.m_sy )
+return false;
+
+if( m_layers != other.m_layers )
+return false;
+
+if( m_angle != other.m_angle )
+return false;
+
+return true;
+}
+
+bool isSMD() const
+{
+return m_type == PAD_ATTRIB_SMD;
+}
+
+PCB_LAYER_ID getSMDLayer() const
+