Re: [Kicad-developers] New lead developers

[Maciej Sumiński]

Congratulations fellow developers! You have received well deserved
promotions, and I am glad to see your names in the
kicad-product-committers group. Keep on rocking!

Cheers,
Orson

On 03/01/2018 08:15 PM, Wayne Stambaugh wrote:
> I am pleased to announce the promotion of three developers to the KiCad
> lead development team.  Their efforts since joining the project have
> really helped move KiCad forward.  They have shown excellent technical
> skills and a willingness to cooperate with the development team.  Please
> congratulate Jon Evans, Seth Hillbrand, and Jeff Young for their
> promotion to the lead developers team.  Thank you gentlemen for all of
> you hard work.
> 
> Cheers,
> 
> Wayne
> 
> ___
> 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
> 




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

Re: [Kicad-developers] Mac HighDPI performance

[Andrey Kuznetsov]

Thanks, I didn't know that, Open in Low Resolution definitely speeds up
eeschema, I know kicad has this info on the website, however that fact that
you have to go inside the package and set that to low res mode as far as I
remember was not stated!

The docs should be updated to properly show how to enable low res mode,
step by step! Setting the main kicad.app to low res mode is not enough,
eeschema.app inside kicad.app package needs to be set.

It didn't feel like pcbnew got faster, I'll have to try on 5K monitor and I
found some supersampling and anti-aliasing modes that I want to turn on to
check.

Thank you to someone on the dev team I guess for getting rid of the mouse
warp events from right click, however the zoom mouse warp to the center of
the screen is still a major WTF.

Question: Is there something different in the way pcbnew does the zooming
compared to eeschema? My mouse zooming feels weird in escheema, but not in
pcbnew.
I think pcbnew has a linear incremental step and the zooming is crisp,
display changes per mouse wheel click, while eeschema what feels like
rubber banding between wheel clicks, step sizes are not linear thus causing
zooming ooogles. My mouse is a logitech mx master 2s using the ratchet
mode. In pcbnew, the zoom happens every ratchet, while in eeschema the zoom
can happen inbetween ratchets, like I just tilt the wheel and bring it back
but the zoom changed in one direction only, ie I can zoom all the way in
without ratcheting. In pcbnew you cannot do that, and it feels natural.


Bug or not? When I open eeschema and pcbnew from KiCad app, eeschema opens
as a standalone app and shows up in the dock on macOS while pcbnew opens as
another window that's part of kicad app. This caused issues with my logitec
options software for custom mouse button settings because I only programmed
kicad, but not eeschema.

On Thu, Mar 1, 2018 at 8:37 PM, Seth Hillbrand 
wrote:

> Usually, Eeschema, Pcbnew, etc are links into the KiCad package.  If you
> right-click and go to "Show Original", you will get the actual
> application.  Get Info there will allow you to select "Open in Low
> Resolution" for that application.
>
> -S
>
> 2018-03-02 4:00 GMT+00:00 Andrey Kuznetsov :
>
>> Only KiCad app has Open in Low Resolution Mode, and I already had it
>> enabled!
>>
>> On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand 
>> wrote:
>>
>>> Andrey-
>>>
>>> I'm moving this to a new thread so that we don't conflate the OpenMP
>>> discussion with this.
>>>
>>> Can you test running Kicad with the "Open in Low Resolution" mode
>>> enabled?  You can activate this by choosing "Get Info" on the main KiCad
>>> application and checking the option that says "Open in Low Resolution".
>>> You may need to do the same for the other applications (Eeschema, pcbnew,
>>> etc) as well.
>>>
>>> -Seth
>>>
>>> ​
>>> ​
>>> 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
>>>
 Hi,

 So for now I've had a chance to test the motherboard project on my
 Retina macbook display.
 eeschema: horrible zoom, feels like elastic band zoom and I have all
 scroll wheel accelerations and similar disabled, zoom response is super
 laggy, cannot work like this, will need to make schematics on windows.
 pcbnew by order of slowness:
 legacy - pretty slow, zoom lag is major, boo boo
 modern (fallback) - decent, but the lag can be felt, zoom lag is minor
 modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
 responsiveness

 I'll report tomorrow on 5K LG display.

>>> ​
>>>
>>>
>>> ___
>>> 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
>>>
>>>
>>
>>
>> --
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the
>> future [JFK]
>>
>> kandre...@gmail.com
>> Live Long and Prosper,
>> Andrey
>>
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Mac HighDPI performance

[Seth Hillbrand]

Usually, Eeschema, Pcbnew, etc are links into the KiCad package.  If you
right-click and go to "Show Original", you will get the actual
application.  Get Info there will allow you to select "Open in Low
Resolution" for that application.

-S

2018-03-02 4:00 GMT+00:00 Andrey Kuznetsov :

> Only KiCad app has Open in Low Resolution Mode, and I already had it
> enabled!
>
> On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand 
> wrote:
>
>> Andrey-
>>
>> I'm moving this to a new thread so that we don't conflate the OpenMP
>> discussion with this.
>>
>> Can you test running Kicad with the "Open in Low Resolution" mode
>> enabled?  You can activate this by choosing "Get Info" on the main KiCad
>> application and checking the option that says "Open in Low Resolution".
>> You may need to do the same for the other applications (Eeschema, pcbnew,
>> etc) as well.
>>
>> -Seth
>>
>> ​
>> ​
>> 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
>>
>>> Hi,
>>>
>>> So for now I've had a chance to test the motherboard project on my
>>> Retina macbook display.
>>> eeschema: horrible zoom, feels like elastic band zoom and I have all
>>> scroll wheel accelerations and similar disabled, zoom response is super
>>> laggy, cannot work like this, will need to make schematics on windows.
>>> pcbnew by order of slowness:
>>> legacy - pretty slow, zoom lag is major, boo boo
>>> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
>>> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
>>> responsiveness
>>>
>>> I'll report tomorrow on 5K LG display.
>>>
>> ​
>>
>>
>> ___
>> 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
>>
>>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
___
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] Mac HighDPI performance

[Andrey Kuznetsov]

Only KiCad app has Open in Low Resolution Mode, and I already had it
enabled!

On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand 
wrote:

> Andrey-
>
> I'm moving this to a new thread so that we don't conflate the OpenMP
> discussion with this.
>
> Can you test running Kicad with the "Open in Low Resolution" mode
> enabled?  You can activate this by choosing "Get Info" on the main KiCad
> application and checking the option that says "Open in Low Resolution".
> You may need to do the same for the other applications (Eeschema, pcbnew,
> etc) as well.
>
> -Seth
>
> ​
> ​
> 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
>
>> Hi,
>>
>> So for now I've had a chance to test the motherboard project on my Retina
>> macbook display.
>> eeschema: horrible zoom, feels like elastic band zoom and I have all
>> scroll wheel accelerations and similar disabled, zoom response is super
>> laggy, cannot work like this, will need to make schematics on windows.
>> pcbnew by order of slowness:
>> legacy - pretty slow, zoom lag is major, boo boo
>> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
>> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
>> responsiveness
>>
>> I'll report tomorrow on 5K LG display.
>>
> ​
>
>
> ___
> 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
>
>


-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] MacOS + OpenMP

[Andrey Kuznetsov]

Hi,

So for now I've had a chance to test the motherboard project on my Retina
macbook display.
eeschema: horrible zoom, feels like elastic band zoom and I have all scroll
wheel accelerations and similar disabled, zoom response is super laggy,
cannot work like this, will need to make schematics on windows.
pcbnew by order of slowness:
legacy - pretty slow, zoom lag is major, boo boo
modern (fallback) - decent, but the lag can be felt, zoom lag is minor
modern (accelerated) - almost cannot feel the lag, very nice, nice zoom
responsiveness

I'll report tomorrow on 5K LG display.

On Thu, Mar 1, 2018 at 9:06 AM, Bernhard Stegmaier 
wrote:

> When I started with KiCad I had massive problems mixing gcc and clang
> depending on what dependency was built with which compiler (different
> libstdc, ABI, etc.) - even if everything should have been compatible in
> theory.
> So, even if we decide to switch to our own toolchain and OpenMP I wouldn’t
> target that for v5.
>
> For my taste, I would rather stick to a toolchain being as stock as
> possible.
>
> > On 1. Mar 2018, at 18:00, Adam Wolf 
> wrote:
> >
> > I do not think it is feasible to distribute a different libstdc++ with
> > V5 stable for macOS unless there's someone who wants to take that on.
> >
> > Adam
> >
> > On Thu, Mar 1, 2018 at 10:50 AM, Wayne Stambaugh 
> wrote:
> >> Just for clarification I think Tom was commenting that the changes hurt
> >> the zone filling speed.  @Tom, is that what your were commenting on
> earlier?
> >>
> >> On 3/1/2018 10:11 AM, Jeff Young wrote:
> >>> But then the progress reporter won’t work (and you’ve got no way to
> cancel).
> >>>
> >>> Non-pooling parallel threads are sufficient for zone filling, aren’t
> they?
> >>>
> >>>
>  On 1 Mar 2018, at 15:00, Bernhard Stegmaier 
> wrote:
> 
>  For now it would probably be fine to just restore the pragma for the
> for loop optimisation.
>  Mac users are used to work single-threaded, all others would get back
> multithreading here.
> 
> > On 1. Mar 2018, at 15:58, Tomasz Wlostowski <
> tomasz.wlostow...@cern.ch> wrote:
> >
> > On 01/03/18 15:43, Jeff Young wrote:
> >> The purpose is it works on Mac.
> >>
> >> But it does appear I misread the std::max( omp_get_num_procs(), 2 )
> part.
> >>
> >
> > Thanks Jeff!
> >
> > Be aware that neither std::thread nor std::async have any concept of
> > thread pooling - we need to look for a suitable library or write or
> own.
> >
> > 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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] Fabrication Outputs and Plot

[Diego Herranz]

Gentle reminder.

Thanks,
Diego

On Tue, Feb 27, 2018 at 12:16 AM, Wayne Stambaugh 
wrote:

> This looks fine to me.  Does anyone else have any objections to this
> change?
>
> On 02/25/2018 03:17 PM, Diego Herranz wrote:
>
>> Thanks for your replies. I think there's a consensus that this needs
>> improving and restructuring, but given your emails, it sounds like a big
>> task :)
>>
>> In the meantime, would you accept the attached patch to change the order
>> in which "Fabrication Outputs" is listed in the menu?
>>
>> Before:
>> Fabrication Outputs
>> Import
>> Export
>>
>> After:
>> Import
>> Export
>> Fabrication Outputs
>>
>>
>> I think that "Fabrication Outputs" is conceptually very similar to
>> "Export" and it belongs next to it better than having "Import" in between
>> them.
>>
>> Thanks,
>> Diego
>>
>>
>>
>> On Sat, Feb 24, 2018 at 9:01 PM, Wayne Stambaugh > > wrote:
>>
>> I'm open to any solution that improves the current situation.  This
>> solution seems reasonable as well.  I also just noticed that wx
>> 3.1.1 was just released and it looks like there have been a lot of
>> fixes the various device contexts so some of the work may have
>> already been done for us.
>>
>> On 02/24/2018 03:31 PM, Jon Evans wrote:
>>
>> I thought the idea was to write a backend for GAL that could
>> render onto a wxDC for printing?  It seems wise to use the
>> wxWidgets printing API rather than bypassing it; so we just need
>> to be able to render onto a DC (without using the old XOR tricks
>> from the legacy drawing code)
>>
>> On Sat, Feb 24, 2018 at 3:26 PM, Jeff Young >  > >> wrote:
>>
>>  On the other hand, if we don’t then we have to keep
>> carrying around
>>  a boat-load of Legacy rendering code (because we use that
>> for printing).
>>
>>   > On 24 Feb 2018, at 20:16, Wayne Stambaugh
>> 
>>  >
>> >> wrote:
>>   >
>>   > There is no plan yet but it has been discussed.  The only
>>  downside is that we will have to write our own print
>> handling on
>>  windows and I'm guessing macos.  That's one of the reasons
>> no one
>>  has signed up yet because it will be a large undertaking.
>>   >
>>   > On 02/24/2018 02:02 PM, Jon Evans wrote:
>>   >> Yes I think that's the plan, just needs someone to sign
>> up to
>>  write it :)
>>   >> On Sat, Feb 24, 2018, 14:00 Andrzej Wolski
>>  
>> >
>>  >  > >  wrote:
>>   >>Cairo have PDF, SVG and Postscript support. I was once
>>  wondering if
>>   >>GAL/Cairo could be used for printing.
>>   >>Andrzej
>>   >>W dniu 2018-02-24 o 19:24, Jon Evans pisze:
>>   >>>Yeah, there (at least) three different dialogs that
>> all present
>>   >>>similar things (i.e. a list of layers to include,
>> settings,
>>  etc):
>>   >>>
>>   >>>Export->SVG
>>   >>>Print
>>   >>>Plot
>>   >>>
>>   >>>The Print code for Export->SVG seems to just use
>> the same SVG
>>   >>>plotter, so maybe it's just mostly GUI cleanup that
>> is needed.
>>   >>>
>>   >>>The main Print code does need an overhaul to use
>> something other
>>   >>>than wxDC for graphics generation (and perhaps
>> adding some more
>>   >>>features to PDF export)
>>   >>>
>>   >>>-Jon
>>   >>>
>>   >>>On Sat, Feb 24, 2018 at 1:16 PM, Jeff Young
>> 
>>  >
>>   >>>
>> >   >>>
>>   >>>Plot SVG and Export SVG are different.  The
>> former goes
>>   >>>through the Plot code while the later goes
>> through the Print
>>   >>>code.
>>   >>>
>>   

[Kicad-developers] [PATCH] Restore some missing visibility items from board file

[Andrzej Wolski]

I'm resending a patch from this thread:
https://lists.launchpad.net/kicad-developers/msg34285.html

I believe it should go into rc2?

State of some recently added checkboxes to Render panel was not restored 
on file open. This patch fixes that.


Andrzej

>From 9ccc36e2d0de45175e928bb70f14340392bd35be Mon Sep 17 00:00:00 2001
From: Andrzej Wolski 
Date: Sat, 24 Feb 2018 21:51:33 +0100
Subject: [PATCH] Restore some missing visibility items from board file
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.7.4"

This is a multi-part message in MIME format.
--2.7.4
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


LAYER_TRACKS, LAYER_PADS_TH and LAYER_NON_PLATEDHOLES
now have their own visibility control, so do not force them on.
---
 include/layers_id_colors_and_visibility.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)


--2.7.4
Content-Type: text/x-patch; name="0001-Restore-some-missing-visibility-items-from-board-fil.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Restore-some-missing-visibility-items-from-board-fil.patch"

diff --git a/include/layers_id_colors_and_visibility.h b/include/layers_id_colors_and_visibility.h
index 01b5df9..2cd5d31 100644
--- a/include/layers_id_colors_and_visibility.h
+++ b/include/layers_id_colors_and_visibility.h
@@ -302,10 +302,7 @@ enum GERBVIEW_LAYER_ID: int
 // from a dialog, but have a visibility control flag.
 // Here is a mask to set them visible, to be sure they are displayed
 // after loading a board for instance
-#define MIN_VISIBILITY_MASK int( (1 << GAL_LAYER_INDEX( LAYER_TRACKS ) ) +\
- ( 1 << GAL_LAYER_INDEX( LAYER_PADS_TH ) ) +\
- ( 1 << GAL_LAYER_INDEX( LAYER_PADS_PLATEDHOLES ) ) +\
- ( 1 << GAL_LAYER_INDEX( LAYER_NON_PLATEDHOLES ) ) +\
+#define MIN_VISIBILITY_MASK int( ( 1 << GAL_LAYER_INDEX( LAYER_PADS_PLATEDHOLES ) ) +\
  ( 1 << GAL_LAYER_INDEX( LAYER_VIAS_HOLES ) ) +\
  ( 1 << GAL_LAYER_INDEX( LAYER_DRC ) ) +\
  ( 1 << GAL_LAYER_INDEX( LAYER_GP_OVERLAY ) ) )

--2.7.4--


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

[Wayne Stambaugh]

I am pleased to announce the promotion of three developers to the KiCad
lead development team.  Their efforts since joining the project have
really helped move KiCad forward.  They have shown excellent technical
skills and a willingness to cooperate with the development team.  Please
congratulate Jon Evans, Seth Hillbrand, and Jeff Young for their
promotion to the lead developers team.  Thank you gentlemen for all of
you hard work.

Cheers,

Wayne

___
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

[Wayne Stambaugh]

On 3/1/2018 10:56 AM, jp charras wrote:
> Le 01/03/2018 à 15:47, Wayne Stambaugh a écrit :
>> On 3/1/2018 9:28 AM, Jon Evans wrote:
>>> Here's a blog post from the developers of Atom editor talking about
>>> solving this problem:
>>> https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html
>>
>> I always new keyboard issues were bad but I didn't think they were this
>> bad.  Someone needs to sit down with keyboard and/or os manufactures and
>> start beating them about the head and shoulders with a clue bat until
>> they fix this mess.  So basically we have to create key mappers to
>> handle both os and keyboard layout differences to have any hope of
>> providing sane hotkey behavior.
>>
> 
> On Windows (only) there is a much more annoying issue:
> if a key is used as accelerator key in menu, the key is captured and key 
> events do not propagate.

I don't think this is big problem.  Generally, menu accelerators are
translated into a command events.  Propagating the character event could
lead to unexpected behavior where one or more command events could be
triggered.  I suppose there could be cases where you would want multiple
commands generated for a single key press but it seems unlikely.

> 
> When a key is typed, first a EVT_CHAR_HOOK is sent to other windows,
> and if not captured a second key event: a EVT_CHAR is sent.
> 
> But in a EVT_CHAR_HOOK the key code is the base key code, not the actual key 
> code.
> if the key is the ? / key (? is  shift+/) the key code is /
> and ? only in EVT_CHAR (assuming you have used shift+/)
> 
> Here is a trace (on a French keyboard equivalent to the "? /" key is "? ," ) 
> of "shift+,"
> The  "shift+," (therefore the ? letter) was typed:
> 16:37:38: EDA_DRAW_PANEL::OnCharHook key 2C (,)
> 16:37:38: EDA_DRAW_FRAME::OnCharHook key 2C (,)
> 16:37:38: EDA_DRAW_PANEL::OnKeyEvent key 3F (?)
> and the Hotkey list is show (as expected).
> not also the '?' is not captured perhaps it is not the base letter of the key 
> or because the actual
> code is shift + someting
> 
> Now the trace of the same key not shifted ("," letter typed)
> 16:42:59: EDA_DRAW_PANEL::OnCharHook key 2C (,)
> 16:42:59: EDA_DRAW_FRAME::OnCharHook key 2C (,)

The key modifier state is required as well.  The translated key code is
not enough information to make a useful decision for fixing the issue.
I'm going to commit the wxKeyEvent trace code that I've written so I can
we can gather up all of the relevant wxKeyEvent information and come up
with a reasonable solution.

> 
> The trace shows the key "? ," was captured (the Hotkey list is show)
> and not EVT_CHAR was fired (perhaps because the ',' is the base key).
> 
> Therefore for EVT_CHAR_HOOK events only the key (not the letter) has meaning.
> This is only inside a EVT_CHAR the letter is identified.
> And it looks like the accelerator key is a key, not a letter.

Irregardless of how the key events are received, they need to be mapped
correctly to a common key to have any chance of making non-alphabetic
keys usable as hot keys in KiCad.

> 
> I spent a lot of time to try to fix it, but never succeed.
> (I have only a workaround specific to Windows)
> 
> I am not sure this is specific to wxWidgets.
> I have seen some other applications having this strange behavior.
> 

___
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] MacOS + OpenMP

[Bernhard Stegmaier]

When I started with KiCad I had massive problems mixing gcc and clang depending 
on what dependency was built with which compiler (different libstdc, ABI, etc.) 
- even if everything should have been compatible in theory.
So, even if we decide to switch to our own toolchain and OpenMP I wouldn’t 
target that for v5.

For my taste, I would rather stick to a toolchain being as stock as possible.

> On 1. Mar 2018, at 18:00, Adam Wolf  wrote:
> 
> I do not think it is feasible to distribute a different libstdc++ with
> V5 stable for macOS unless there's someone who wants to take that on.
> 
> Adam
> 
> On Thu, Mar 1, 2018 at 10:50 AM, Wayne Stambaugh  wrote:
>> Just for clarification I think Tom was commenting that the changes hurt
>> the zone filling speed.  @Tom, is that what your were commenting on earlier?
>> 
>> On 3/1/2018 10:11 AM, Jeff Young wrote:
>>> But then the progress reporter won’t work (and you’ve got no way to cancel).
>>> 
>>> Non-pooling parallel threads are sufficient for zone filling, aren’t they?
>>> 
>>> 
 On 1 Mar 2018, at 15:00, Bernhard Stegmaier  
 wrote:
 
 For now it would probably be fine to just restore the pragma for the for 
 loop optimisation.
 Mac users are used to work single-threaded, all others would get back 
 multithreading here.
 
> On 1. Mar 2018, at 15:58, Tomasz Wlostowski  
> wrote:
> 
> On 01/03/18 15:43, Jeff Young wrote:
>> The purpose is it works on Mac.
>> 
>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
>> 
> 
> Thanks Jeff!
> 
> Be aware that neither std::thread nor std::async have any concept of
> thread pooling - we need to look for a suitable library or write or own.
> 
> 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

Re: [Kicad-developers] MacOS + OpenMP

[Seth Hillbrand]

Hi All-

I was playing with this last night (don't normally compile on the mac) and
found that using homebrew's llvm 3.8.1 seems to compile fine with
-fopenmp.  Running some OMP test code from
https://gist.github.com/sethhillbrand/45dfb50e5a1865ad65bda1d6522778c5
shows expected result of 4 threads.  I didn't get OpenMP errors when
compiling KiCad although I didn't really notice a substantial difference in
speed for the quick tests I was running.  Maybe with more involved
operations.

I'm not sure if this will require us to distribute a different libstdc++
with KiCad.  Probably.  Does that seem feasible to the packing team?

-S

2018-03-01 7:23 GMT-08:00 Bernhard Stegmaier :

> Hmm?
> You keep everything as is (especially creating threads), but just put the
> “#pragma …” before the for-loop.
> So, there is one thread for the progress and one for the workers.
> In the workers thread OpenMP (if there) takes care of adding additional
> threads for parallelising the loop?
>
> Or, am I wrong with that?
>
> > On 1. Mar 2018, at 16:11, Jeff Young  wrote:
> >
> > But then the progress reporter won’t work (and you’ve got no way to
> cancel).
> >
> > Non-pooling parallel threads are sufficient for zone filling, aren’t
> they?
> >
> >
> >> On 1 Mar 2018, at 15:00, Bernhard Stegmaier 
> wrote:
> >>
> >> For now it would probably be fine to just restore the pragma for the
> for loop optimisation.
> >> Mac users are used to work single-threaded, all others would get back
> multithreading here.
> >>
> >>> On 1. Mar 2018, at 15:58, Tomasz Wlostowski 
> wrote:
> >>>
> >>> On 01/03/18 15:43, Jeff Young wrote:
>  The purpose is it works on Mac.
> 
>  But it does appear I misread the std::max( omp_get_num_procs(), 2 )
> part.
> 
> >>>
> >>> Thanks Jeff!
> >>>
> >>> Be aware that neither std::thread nor std::async have any concept of
> >>> thread pooling - we need to look for a suitable library or write or
> own.
> >>>
> >>> 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

Re: [Kicad-developers] Alternative presentation of Symbol properties

[Jeff Young]

Technically yes, but even the existing dialog only lets you edit both.

> On 1 Mar 2018, at 16:23, Andy Peters  wrote:
> 
> 
> 
>> On Mar 1, 2018, at 5:29 AM, Jeff Young  wrote:
>> 
>> What do you guys think of this for displaying / editing symbol fields:
>> 
>> 
> 
> Don’t the text items have thickness and width attributes, not just one “size?”
> 
> -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] Alternative presentation of Symbol properties

[Andy Peters]

> On Mar 1, 2018, at 5:29 AM, Jeff Young  wrote:
> 
> What do you guys think of this for displaying / editing symbol fields:
> 
> 

Don’t the text items have thickness and width attributes, not just one “size?”

-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

Re: [Kicad-developers] '/' hotkey

[jp charras]

Le 01/03/2018 à 15:47, Wayne Stambaugh a écrit :
> On 3/1/2018 9:28 AM, Jon Evans wrote:
>> Here's a blog post from the developers of Atom editor talking about
>> solving this problem:
>> https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html
> 
> I always new keyboard issues were bad but I didn't think they were this
> bad.  Someone needs to sit down with keyboard and/or os manufactures and
> start beating them about the head and shoulders with a clue bat until
> they fix this mess.  So basically we have to create key mappers to
> handle both os and keyboard layout differences to have any hope of
> providing sane hotkey behavior.
> 

On Windows (only) there is a much more annoying issue:
if a key is used as accelerator key in menu, the key is captured and key events 
do not propagate.

When a key is typed, first a EVT_CHAR_HOOK is sent to other windows,
and if not captured a second key event: a EVT_CHAR is sent.

But in a EVT_CHAR_HOOK the key code is the base key code, not the actual key 
code.
if the key is the ? / key (? is  shift+/) the key code is /
and ? only in EVT_CHAR (assuming you have used shift+/)

Here is a trace (on a French keyboard equivalent to the "? /" key is "? ," ) of 
"shift+,"
The  "shift+," (therefore the ? letter) was typed:
16:37:38: EDA_DRAW_PANEL::OnCharHook key 2C (,)
16:37:38: EDA_DRAW_FRAME::OnCharHook key 2C (,)
16:37:38: EDA_DRAW_PANEL::OnKeyEvent key 3F (?)
and the Hotkey list is show (as expected).
not also the '?' is not captured perhaps it is not the base letter of the key 
or because the actual
code is shift + someting

Now the trace of the same key not shifted ("," letter typed)
16:42:59: EDA_DRAW_PANEL::OnCharHook key 2C (,)
16:42:59: EDA_DRAW_FRAME::OnCharHook key 2C (,)

The trace shows the key "? ," was captured (the Hotkey list is show)
and not EVT_CHAR was fired (perhaps because the ',' is the base key).

Therefore for EVT_CHAR_HOOK events only the key (not the letter) has meaning.
This is only inside a EVT_CHAR the letter is identified.
And it looks like the accelerator key is a key, not a letter.

I spent a lot of time to try to fix it, but never succeed.
(I have only a workaround specific to Windows)

I am not sure this is specific to wxWidgets.
I have seen some other applications having this strange behavior.

-- 
Jean-Pierre CHARRAS

___
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] Alternative presentation of Symbol properties

[Wayne Stambaugh]

Hey Jeff,

I'll try to check it out this weekend if I can find the time.

Cheers,

Wayne

On 3/1/2018 8:44 AM, Jeff Young wrote:
> Hi Wayne,
> 
> The table editor is already done.  That wasn’t controversial (since it was 
> already a table-style presentation).  You can play with that on my branch: 
> https://git.launchpad.net/~jeyjey/kicad/.  (If you do, have a look at the 
> whizzy new DRC highlighting too: generate some errors, right click over a 
> marker in the DRC window, and hover back and forth between the items in the 
> popup.)
> 
> The screen-shotted in the previous post is from the Edit Symbol dialog, but I 
> haven’t removed the old stuff yet so I didn’t screen-shot the whole dialog.  
> Sounds like it’s worth at least a few more hours to clean out the old stuff 
> and see what it’s like?
> 
> Cheers,
> Jeff.
> 
> 
>> On 1 Mar 2018, at 13:08, Wayne Stambaugh  wrote:
>>
>> Maybe I'm not seeing this correctly but your editor is only showing the
>> fields for a single symbol.  I thought you were replacing the current
>> table editor where you could group symbols and edit field values for
>> group of symbols rather than each symbol individually.  I would like to
>> see what you have currently done embedded in the symbol properties
>> editor to replace the one at a time field editing that we currently have.
>>
>> On 3/1/2018 7:29 AM, Jeff Young wrote:
>>> What do you guys think of this for displaying / editing symbol fields:
>>>
>>>
>>> On the plus side it’s much more direct to edit stuff (without having to
>>> select the field first to get its properties set in the controls).
>>>
>>> On the minus side it is perhaps a bit more industrial looking.
>>>
>>>
>>> ___
>>> 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] MacOS + OpenMP

[Bernhard Stegmaier]

Hmm?
You keep everything as is (especially creating threads), but just put the 
“#pragma …” before the for-loop.
So, there is one thread for the progress and one for the workers.
In the workers thread OpenMP (if there) takes care of adding additional threads 
for parallelising the loop?

Or, am I wrong with that?

> On 1. Mar 2018, at 16:11, Jeff Young  wrote:
> 
> But then the progress reporter won’t work (and you’ve got no way to cancel).
> 
> Non-pooling parallel threads are sufficient for zone filling, aren’t they?
> 
> 
>> On 1 Mar 2018, at 15:00, Bernhard Stegmaier  wrote:
>> 
>> For now it would probably be fine to just restore the pragma for the for 
>> loop optimisation.
>> Mac users are used to work single-threaded, all others would get back 
>> multithreading here.
>> 
>>> On 1. Mar 2018, at 15:58, Tomasz Wlostowski  
>>> wrote:
>>> 
>>> On 01/03/18 15:43, Jeff Young wrote:
 The purpose is it works on Mac.
 
 But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
 
>>> 
>>> Thanks Jeff!
>>> 
>>> Be aware that neither std::thread nor std::async have any concept of
>>> thread pooling - we need to look for a suitable library or write or own.
>>> 
>>> 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

Re: [Kicad-developers] MacOS + OpenMP

[Jeff Young]

But then the progress reporter won’t work (and you’ve got no way to cancel).

Non-pooling parallel threads are sufficient for zone filling, aren’t they?


> On 1 Mar 2018, at 15:00, Bernhard Stegmaier  wrote:
> 
> For now it would probably be fine to just restore the pragma for the for loop 
> optimisation.
> Mac users are used to work single-threaded, all others would get back 
> multithreading here.
> 
>> On 1. Mar 2018, at 15:58, Tomasz Wlostowski  
>> wrote:
>> 
>> On 01/03/18 15:43, Jeff Young wrote:
>>> The purpose is it works on Mac.
>>> 
>>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
>>> 
>> 
>> Thanks Jeff!
>> 
>> Be aware that neither std::thread nor std::async have any concept of
>> thread pooling - we need to look for a suitable library or write or own.
>> 
>> 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

Re: [Kicad-developers] '/' hotkey

[Wayne Stambaugh]

You can get the untranslated key code using EVT_CHAR by calling
GetRawKeyCode() and GetRawKeyFlags().

On 3/1/2018 9:52 AM, Jon Evans wrote:
> sorry, meant KEY_DOWN / KEY_UP, got them mixed up.  Translated vs.
> untranslated.
> 
> On Thu, Mar 1, 2018 at 9:47 AM, Wayne Stambaugh  > wrote:
> 
> On 3/1/2018 9:28 AM, Jon Evans wrote:
> > Here's a blog post from the developers of Atom editor talking about
> > solving this problem:
> > https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html 
> 
> 
> I always new keyboard issues were bad but I didn't think they were this
> bad.  Someone needs to sit down with keyboard and/or os manufactures and
> start beating them about the head and shoulders with a clue bat until
> they fix this mess.  So basically we have to create key mappers to
> handle both os and keyboard layout differences to have any hope of
> providing sane hotkey behavior.
> 
> >
> > I have not studied this at all yet but perhaps it is relevant (i.e.
> > maybe we should be looking at EVT_CHAR too?)
> 
> These are the events from EVT_CHAR.
> 
> >
> > On Thu, Mar 1, 2018 at 9:19 AM, Wayne Stambaugh  
> > >> wrote:
> >
> >     On 2/28/2018 3:46 PM, Wayne Stambaugh wrote:
> >     > On 2/28/2018 2:31 PM, jp charras wrote:
> >     >> Le 28/02/2018 à 17:45, Wayne Stambaugh a écrit :
> >     >>> In the process of attempting to fix this bug[1], I ran
> into an issue
> >     >>> with the '/' hotkey for all main frames.  For some reason, the
> >     hotkey
> >     >>> help dialog is being displayed for both '/' and '?' keys which
> >     broke the
> >     >>> track posture switching in pcbnew.  This bug only seems to
> affect
> >     >>> windows.  The attached patch fixes the issue but changes the
> >     menu entry
> >     >>> shortcut text from '?' to 'shift+?' which would make pcbnew
> >     different
> >     >>> from all of the other mainframe windows which is ugly but it's
> >     better
> >     >>> than a broken hotkey.
> >     >>>
> >     >>> While I was at it, I took a look at the schematic editor and
> >     sure enough
> >     >>> the same behavior exists except that the same change as
> the attached
> >     >>> patch does not fix the issue so the bus wire entry hotkey
> is broken.
> >     >>> When I set a debugger breakpoint in the
> EDA_DRAW_PANEL::OnKeyEvent()
> >     >>> function, it is not triggered for either a '/' key.  The
> '?' key
> >     does
> >     >>> trigger the breakpoint.  Did someone create a character hook
> >     somewhere
> >     >>> that could be preventing EDA_DRAW_PANEL from ever
> receiving the
> >     '/' key
> >     >>> presses and passing them directly to the SCH_EDIT_FRAME?  I
> >     cannot find
> >     >>> any reason why the EDA_DRAW_PANEL::OnKeyEvent() event
> handler is not
> >     >>> being called for this key on windows.
> >     >>>
> >     >>> Cheers,
> >     >>>
> >     >>> Wayne
> >     >>>
> >     >>> [1]: https://bugs.launchpad.net/kicad/+bug/1751812
> 
> >      >
> >     >>
> >     >> Wayne,
> >     >> Because the hotkeys can be redefined by user, I don't think
> your
> >     fix is working.
> >     >
> >     > '/' is the default hotkey for change track posture in pcbnew
> and place
> >     > bus wire entry in eeschema.  So user hotkey definitions are not
> >     relevant
> >     > since I have not changed any of my hotkey defaults.  What is odd
> >     is that
> >     > this fix works for pcbnew but not eeschema.
> >     >
> >     >>
> >     >> Moreover it happen mainly in US keyboards
> >     >> (I am guessing the chars '?' and '/' are the same keyboard key)
> >     >
> >     > They are on the same key on US keyboard.  That being said '/' is
> >     not the
> >     > same as key code as 'shift+/' or at least they shouldn't be
> the same.
> >     >
> >     >>
> >     >> On Windows, the key events are really tricky, and I never
> be able
> >     to fix the accelerators versus
> >     >> hotkeys issues.
> >     >>
> >     >> In this case the issue is due to the complexity of keys events:
> >     >> The simplified event list is:
> >     >>
> >     >> - first the EVT_CHAR_HOOK_EVENT is send with key code = '/'
> >     >> if not captured:
> >     >> - send EVT_CHAR_EVENT is send with 

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

For now it would probably be fine to just restore the pragma for the for loop 
optimisation.
Mac users are used to work single-threaded, all others would get back 
multithreading here.

> On 1. Mar 2018, at 15:58, Tomasz Wlostowski  wrote:
> 
> On 01/03/18 15:43, Jeff Young wrote:
>> The purpose is it works on Mac.
>> 
>> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
>> 
> 
> Thanks Jeff!
> 
> Be aware that neither std::thread nor std::async have any concept of
> thread pooling - we need to look for a suitable library or write or own.
> 
> 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

Re: [Kicad-developers] MacOS + OpenMP

[Tomasz Wlostowski]

On 01/03/18 15:43, Jeff Young wrote:
> The purpose is it works on Mac.
> 
> But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.
> 

Thanks Jeff!

Be aware that neither std::thread nor std::async have any concept of
thread pooling - we need to look for a suitable library or write or own.

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] '/' hotkey

[Jon Evans]

sorry, meant KEY_DOWN / KEY_UP, got them mixed up.  Translated vs.
untranslated.

On Thu, Mar 1, 2018 at 9:47 AM, Wayne Stambaugh 
wrote:

> On 3/1/2018 9:28 AM, Jon Evans wrote:
> > Here's a blog post from the developers of Atom editor talking about
> > solving this problem:
> > https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html
>
> I always new keyboard issues were bad but I didn't think they were this
> bad.  Someone needs to sit down with keyboard and/or os manufactures and
> start beating them about the head and shoulders with a clue bat until
> they fix this mess.  So basically we have to create key mappers to
> handle both os and keyboard layout differences to have any hope of
> providing sane hotkey behavior.
>
> >
> > I have not studied this at all yet but perhaps it is relevant (i.e.
> > maybe we should be looking at EVT_CHAR too?)
>
> These are the events from EVT_CHAR.
>
> >
> > On Thu, Mar 1, 2018 at 9:19 AM, Wayne Stambaugh  > > wrote:
> >
> > On 2/28/2018 3:46 PM, Wayne Stambaugh wrote:
> > > On 2/28/2018 2:31 PM, jp charras wrote:
> > >> Le 28/02/2018 à 17:45, Wayne Stambaugh a écrit :
> > >>> In the process of attempting to fix this bug[1], I ran into an
> issue
> > >>> with the '/' hotkey for all main frames.  For some reason, the
> > hotkey
> > >>> help dialog is being displayed for both '/' and '?' keys which
> > broke the
> > >>> track posture switching in pcbnew.  This bug only seems to affect
> > >>> windows.  The attached patch fixes the issue but changes the
> > menu entry
> > >>> shortcut text from '?' to 'shift+?' which would make pcbnew
> > different
> > >>> from all of the other mainframe windows which is ugly but it's
> > better
> > >>> than a broken hotkey.
> > >>>
> > >>> While I was at it, I took a look at the schematic editor and
> > sure enough
> > >>> the same behavior exists except that the same change as the
> attached
> > >>> patch does not fix the issue so the bus wire entry hotkey is
> broken.
> > >>> When I set a debugger breakpoint in the
> EDA_DRAW_PANEL::OnKeyEvent()
> > >>> function, it is not triggered for either a '/' key.  The '?' key
> > does
> > >>> trigger the breakpoint.  Did someone create a character hook
> > somewhere
> > >>> that could be preventing EDA_DRAW_PANEL from ever receiving the
> > '/' key
> > >>> presses and passing them directly to the SCH_EDIT_FRAME?  I
> > cannot find
> > >>> any reason why the EDA_DRAW_PANEL::OnKeyEvent() event handler is
> not
> > >>> being called for this key on windows.
> > >>>
> > >>> Cheers,
> > >>>
> > >>> Wayne
> > >>>
> > >>> [1]: https://bugs.launchpad.net/kicad/+bug/1751812
> > 
> > >>
> > >> Wayne,
> > >> Because the hotkeys can be redefined by user, I don't think your
> > fix is working.
> > >
> > > '/' is the default hotkey for change track posture in pcbnew and
> place
> > > bus wire entry in eeschema.  So user hotkey definitions are not
> > relevant
> > > since I have not changed any of my hotkey defaults.  What is odd
> > is that
> > > this fix works for pcbnew but not eeschema.
> > >
> > >>
> > >> Moreover it happen mainly in US keyboards
> > >> (I am guessing the chars '?' and '/' are the same keyboard key)
> > >
> > > They are on the same key on US keyboard.  That being said '/' is
> > not the
> > > same as key code as 'shift+/' or at least they shouldn't be the
> same.
> > >
> > >>
> > >> On Windows, the key events are really tricky, and I never be able
> > to fix the accelerators versus
> > >> hotkeys issues.
> > >>
> > >> In this case the issue is due to the complexity of keys events:
> > >> The simplified event list is:
> > >>
> > >> - first the EVT_CHAR_HOOK_EVENT is send with key code = '/'
> > >> if not captured:
> > >> - send EVT_CHAR_EVENT is send with key code = '?'
> > >>
> > >> and in fact there are more events sent, both using
> > EVT_CHAR_HOOK_EVENT and EVT_CHAR_EVENT.
> > >>
> > >> This is true for each key: a event is send with code
> > corresponding to the non shifted code, and then
> > >> to the shifted code (if the envent is not captured)
> > >>
> > >
> > > While all of this is informative it still does not answer the
> question
> > > as to why the '/' character is never getting handled in
> > > EDA_DRAW_PANEL::OnKeyEvent() while the '?' character is being
> handled.
> > > I'll keep digging around because something is different between the
> > > schematic and board editors.
> > >
> >
> > JP,
> >
> > I figured out what is going on with some simple tracing.  On windows
> > with US keyboard layouts, 

Re: [Kicad-developers] '/' hotkey

[Wayne Stambaugh]

On 3/1/2018 9:28 AM, Jon Evans wrote:
> Here's a blog post from the developers of Atom editor talking about
> solving this problem:
> https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html

I always new keyboard issues were bad but I didn't think they were this
bad.  Someone needs to sit down with keyboard and/or os manufactures and
start beating them about the head and shoulders with a clue bat until
they fix this mess.  So basically we have to create key mappers to
handle both os and keyboard layout differences to have any hope of
providing sane hotkey behavior.

> 
> I have not studied this at all yet but perhaps it is relevant (i.e.
> maybe we should be looking at EVT_CHAR too?)

These are the events from EVT_CHAR.

> 
> On Thu, Mar 1, 2018 at 9:19 AM, Wayne Stambaugh  > wrote:
> 
> On 2/28/2018 3:46 PM, Wayne Stambaugh wrote:
> > On 2/28/2018 2:31 PM, jp charras wrote:
> >> Le 28/02/2018 à 17:45, Wayne Stambaugh a écrit :
> >>> In the process of attempting to fix this bug[1], I ran into an issue
> >>> with the '/' hotkey for all main frames.  For some reason, the
> hotkey
> >>> help dialog is being displayed for both '/' and '?' keys which
> broke the
> >>> track posture switching in pcbnew.  This bug only seems to affect
> >>> windows.  The attached patch fixes the issue but changes the
> menu entry
> >>> shortcut text from '?' to 'shift+?' which would make pcbnew
> different
> >>> from all of the other mainframe windows which is ugly but it's
> better
> >>> than a broken hotkey.
> >>>
> >>> While I was at it, I took a look at the schematic editor and
> sure enough
> >>> the same behavior exists except that the same change as the attached
> >>> patch does not fix the issue so the bus wire entry hotkey is broken.
> >>> When I set a debugger breakpoint in the EDA_DRAW_PANEL::OnKeyEvent()
> >>> function, it is not triggered for either a '/' key.  The '?' key
> does
> >>> trigger the breakpoint.  Did someone create a character hook
> somewhere
> >>> that could be preventing EDA_DRAW_PANEL from ever receiving the
> '/' key
> >>> presses and passing them directly to the SCH_EDIT_FRAME?  I
> cannot find
> >>> any reason why the EDA_DRAW_PANEL::OnKeyEvent() event handler is not
> >>> being called for this key on windows.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> [1]: https://bugs.launchpad.net/kicad/+bug/1751812
> 
> >>
> >> Wayne,
> >> Because the hotkeys can be redefined by user, I don't think your
> fix is working.
> >
> > '/' is the default hotkey for change track posture in pcbnew and place
> > bus wire entry in eeschema.  So user hotkey definitions are not
> relevant
> > since I have not changed any of my hotkey defaults.  What is odd
> is that
> > this fix works for pcbnew but not eeschema.
> >
> >>
> >> Moreover it happen mainly in US keyboards
> >> (I am guessing the chars '?' and '/' are the same keyboard key)
> >
> > They are on the same key on US keyboard.  That being said '/' is
> not the
> > same as key code as 'shift+/' or at least they shouldn't be the same.
> >
> >>
> >> On Windows, the key events are really tricky, and I never be able
> to fix the accelerators versus
> >> hotkeys issues.
> >>
> >> In this case the issue is due to the complexity of keys events:
> >> The simplified event list is:
> >>
> >> - first the EVT_CHAR_HOOK_EVENT is send with key code = '/'
> >> if not captured:
> >> - send EVT_CHAR_EVENT is send with key code = '?'
> >>
> >> and in fact there are more events sent, both using
> EVT_CHAR_HOOK_EVENT and EVT_CHAR_EVENT.
> >>
> >> This is true for each key: a event is send with code
> corresponding to the non shifted code, and then
> >> to the shifted code (if the envent is not captured)
> >>
> >
> > While all of this is informative it still does not answer the question
> > as to why the '/' character is never getting handled in
> > EDA_DRAW_PANEL::OnKeyEvent() while the '?' character is being handled.
> > I'll keep digging around because something is different between the
> > schematic and board editors.
> >
> 
> JP,
> 
> I figured out what is going on with some simple tracing.  On windows
> with US keyboard layouts, the '?' key is sent as a 'shift+/' which isn't
> unexpected.  What is unexpected is that we are only allowing the shift
> key to be passed when keys 'a' - 'z' and 'A' - 'Z' are pressed by this
> code and associated comment:
> 
>     /* Disallow shift for keys that have two keycodes on them (e.g.
> number and
>      * punctuation keys) leaving only the "letter keys" of 

Re: [Kicad-developers] MacOS + OpenMP

[Jeff Young]

The purpose is it works on Mac.

But it does appear I misread the std::max( omp_get_num_procs(), 2 ) part.

Patch coming.

Cheers,
Jeff.


> On 1 Mar 2018, at 14:09, Tomasz Wlostowski  wrote:
> 
> On 01/03/18 15:01, Jon Evans wrote:
>> I missed that change to STL, oops!
>> In that case we should standardize on STL for all new code in the future
>> so that it will work on Mac.
> 
> Me too.
> 
> I don't understand the purpose of it - now all zone calculation (except
> for insulated copper island removal) works in a *single* worker thread
> (the main thread is just refreshing the progress dialog).
> 
> It means ~3.5x slower zone refilling on a 4-core CPU.
> 
> Can anybody comment on that?
> 
> Tom
> 
> 
>> There are already many edge cases I have found (or users have reported)
>> where KiCad is extremely slow, and we need to have a good story for
>> multiprocessing so that we can take advantage of it where it makes sense
>> to increase performance and/or responsiveness.
>> 
>> -Jon
>> 
>> On Thu, Mar 1, 2018 at 8:48 AM, Jeff Young > > wrote:
>> 
>>There’s performance and there’s responsiveness.
>> 
>>The footprint loading and zone filling were moved to STL so that
>>progress reporting would work on Mac.
>> 
>>As long as we don’t introduce more OpenMP into core stuff, I’m not
>>that fixated on what we use for raytracing.
>> 
>>Cheers,
>>Jeff.
>> 
>> 
>>>On 1 Mar 2018, at 13:34, Tomasz Wlostowski
>>>> wrote:
>>> 
>>>On 01/03/18 14:29, Jon Evans wrote:
It is also used for zone filling and in my new eeschema connectivity
code that I'm hoping to get merged soon after V5 release.
 
I'm happy to help with research / testing of alternatives if we can't
use OpenMP on Mac. 
 
>>>I'd like to hear from a *single* Apple user who designs boards of
>>>sufficient complexity for the multithreading to really have an
>>>impact on
>>>performance. What's next, rewriting Kicad in Objective-C?
>>> 
>>>- my 5 cents
>>> 
>>>Tom
>>> 
>>> 
Jon
 
On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh 
> wrote:
 
   Ughh!  Thank you Apple.  I'm not opposed to this idea if
OpenMP isn't a
   viable option on macos.  I would like to see our macos port be
on par
   with linux and windows ports.
 
   Wayne
 
   On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
>I did look around a bit.
>Looks like OpenMP isn’t a friend of Xcode clang, because Apple
>has its
>own Grand Central Dispatch (libdispatch) implementation/library
>doing
>similar things (at first glance, didn’t look into details).
>So, I guess OpenMP maybe won’t happen soon with stock toolchain
>or we
>would have to use non-stock toolchain (probably with all
>problems that
>come with that - I have seen bad things mixing compilers, etc.).
> 
>Seems to be quite easy to convert OpenMP for loop parallelisation
   to GCD:
><<<
>//#pragma omp parallel for
>//for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
>dispatch_queue_t queue =
>dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
>dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
>{
>...
>}
>);
 
> 
>I just naively replaced all of the OpenMP for loops like above
>and now
>3d-Viewer uses all cores.
>On my i7-3770T rendering time decreased from about 100s to 30s.
> 
>I also did it for the ratsnest loop but didn’t notice any difference
>(maybe my test PCB was just to small).
> 
>I could play around a bit to put that stuff into some nice syntax
   maybe
>similar to what Microsoft has with concurrency::parallel_for_each
>  https://msdn.microsoft.com/en-us/library/dd492857.aspx
>
>So, at least ugly #ifdef around each parallel for loop could be
   hidden.
> 
>Don’t get me wrong, I don’t want to add just another parallelisation
>library/mechanism.
>And… I guess it won’t be possible to transparently cover all the
   OpenMP
>pragma stuff maybe needed inside for loop body or maybe other stuff
>needed for GCD (e.g. when writing to variables outside for body).
> 
>Thoughts? Would this be an option?
> 
>Oh, yes:
>I did look into using STL std::async.
>Doesn’t seem to be a good idea, because it usually doesn’t seem
>to use
>anything like thread pools, etc. on 

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

I didn’t follow in detail, but from what I saw I guess the bad thing about it 
was to use OpenMP for
(1) parallelising for loop
  and
(2) creating individual threads for progress reporter and workers.

As soon as you don’t have OpenMP it didn’t work anymore… so maybe using OpenMP 
for (1) and usual STL threading stuff for (2) would be a compromise (even) if 
maybe clumsy.
At least, it would work also with non-OpenMP systems.


Regards,
Bernhard

> On 1. Mar 2018, at 15:09, Tomasz Wlostowski  wrote:
> 
> On 01/03/18 15:01, Jon Evans wrote:
>> I missed that change to STL, oops!
>> In that case we should standardize on STL for all new code in the future
>> so that it will work on Mac.
> 
> Me too.
> 
> I don't understand the purpose of it - now all zone calculation (except
> for insulated copper island removal) works in a *single* worker thread
> (the main thread is just refreshing the progress dialog).
> 
> It means ~3.5x slower zone refilling on a 4-core CPU.
> 
> Can anybody comment on that?
> 
> Tom
> 
> 
>> There are already many edge cases I have found (or users have reported)
>> where KiCad is extremely slow, and we need to have a good story for
>> multiprocessing so that we can take advantage of it where it makes sense
>> to increase performance and/or responsiveness.
>> 
>> -Jon
>> 
>> On Thu, Mar 1, 2018 at 8:48 AM, Jeff Young > > wrote:
>> 
>>There’s performance and there’s responsiveness.
>> 
>>The footprint loading and zone filling were moved to STL so that
>>progress reporting would work on Mac.
>> 
>>As long as we don’t introduce more OpenMP into core stuff, I’m not
>>that fixated on what we use for raytracing.
>> 
>>Cheers,
>>Jeff.
>> 
>> 
>>>On 1 Mar 2018, at 13:34, Tomasz Wlostowski
>>>> wrote:
>>> 
>>>On 01/03/18 14:29, Jon Evans wrote:
It is also used for zone filling and in my new eeschema connectivity
code that I'm hoping to get merged soon after V5 release.
 
I'm happy to help with research / testing of alternatives if we can't
use OpenMP on Mac. 
 
>>>I'd like to hear from a *single* Apple user who designs boards of
>>>sufficient complexity for the multithreading to really have an
>>>impact on
>>>performance. What's next, rewriting Kicad in Objective-C?
>>> 
>>>- my 5 cents
>>> 
>>>Tom
>>> 
>>> 
Jon
 
On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh 
> wrote:
 
   Ughh!  Thank you Apple.  I'm not opposed to this idea if
OpenMP isn't a
   viable option on macos.  I would like to see our macos port be
on par
   with linux and windows ports.
 
   Wayne
 
   On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
>I did look around a bit.
>Looks like OpenMP isn’t a friend of Xcode clang, because Apple
>has its
>own Grand Central Dispatch (libdispatch) implementation/library
>doing
>similar things (at first glance, didn’t look into details).
>So, I guess OpenMP maybe won’t happen soon with stock toolchain
>or we
>would have to use non-stock toolchain (probably with all
>problems that
>come with that - I have seen bad things mixing compilers, etc.).
> 
>Seems to be quite easy to convert OpenMP for loop parallelisation
   to GCD:
><<<
>//#pragma omp parallel for
>//for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
>dispatch_queue_t queue =
>dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
>dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
>{
>...
>}
>);
 
> 
>I just naively replaced all of the OpenMP for loops like above
>and now
>3d-Viewer uses all cores.
>On my i7-3770T rendering time decreased from about 100s to 30s.
> 
>I also did it for the ratsnest loop but didn’t notice any difference
>(maybe my test PCB was just to small).
> 
>I could play around a bit to put that stuff into some nice syntax
   maybe
>similar to what Microsoft has with concurrency::parallel_for_each
>  https://msdn.microsoft.com/en-us/library/dd492857.aspx
>
>So, at least ugly #ifdef around each parallel for loop could be
   hidden.
> 
>Don’t get me wrong, I don’t want to add just another parallelisation
>library/mechanism.
>And… I guess it won’t be possible to transparently cover all the
   OpenMP
>pragma stuff maybe needed inside for loop body or maybe other stuff
>needed for GCD 

Re: [Kicad-developers] MacOS + OpenMP

[Tomasz Wlostowski]

On 01/03/18 15:26, Bernhard Stegmaier wrote:
> I didn’t follow in detail, but from what I saw I guess the bad thing about it 
> was to use OpenMP for
> (1) parallelising for loop
>   and
> (2) creating individual threads for progress reporter and workers.
> 
> As soon as you don’t have OpenMP it didn’t work anymore… so maybe using 
> OpenMP for (1) and usual STL threading stuff for (2) would be a compromise 
> (even) if maybe clumsy.
> At least, it would work also with non-OpenMP systems.
> 
Sure, I'm all in for STL - my only concern is that zone filling, as it
is done now, does not benefit at all from multiple CPU cores. We need a
proper STL-based worker dispatcher for that to 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] '/' hotkey

[Jon Evans]

Here's a blog post from the developers of Atom editor talking about solving
this problem:
https://blog.atom.io/2016/10/17/the-wonderful-world-of-keyboards.html

I have not studied this at all yet but perhaps it is relevant (i.e. maybe
we should be looking at EVT_CHAR too?)

On Thu, Mar 1, 2018 at 9:19 AM, Wayne Stambaugh 
wrote:

> On 2/28/2018 3:46 PM, Wayne Stambaugh wrote:
> > On 2/28/2018 2:31 PM, jp charras wrote:
> >> Le 28/02/2018 à 17:45, Wayne Stambaugh a écrit :
> >>> In the process of attempting to fix this bug[1], I ran into an issue
> >>> with the '/' hotkey for all main frames.  For some reason, the hotkey
> >>> help dialog is being displayed for both '/' and '?' keys which broke
> the
> >>> track posture switching in pcbnew.  This bug only seems to affect
> >>> windows.  The attached patch fixes the issue but changes the menu entry
> >>> shortcut text from '?' to 'shift+?' which would make pcbnew different
> >>> from all of the other mainframe windows which is ugly but it's better
> >>> than a broken hotkey.
> >>>
> >>> While I was at it, I took a look at the schematic editor and sure
> enough
> >>> the same behavior exists except that the same change as the attached
> >>> patch does not fix the issue so the bus wire entry hotkey is broken.
> >>> When I set a debugger breakpoint in the EDA_DRAW_PANEL::OnKeyEvent()
> >>> function, it is not triggered for either a '/' key.  The '?' key does
> >>> trigger the breakpoint.  Did someone create a character hook somewhere
> >>> that could be preventing EDA_DRAW_PANEL from ever receiving the '/' key
> >>> presses and passing them directly to the SCH_EDIT_FRAME?  I cannot find
> >>> any reason why the EDA_DRAW_PANEL::OnKeyEvent() event handler is not
> >>> being called for this key on windows.
> >>>
> >>> Cheers,
> >>>
> >>> Wayne
> >>>
> >>> [1]: https://bugs.launchpad.net/kicad/+bug/1751812
> >>
> >> Wayne,
> >> Because the hotkeys can be redefined by user, I don't think your fix is
> working.
> >
> > '/' is the default hotkey for change track posture in pcbnew and place
> > bus wire entry in eeschema.  So user hotkey definitions are not relevant
> > since I have not changed any of my hotkey defaults.  What is odd is that
> > this fix works for pcbnew but not eeschema.
> >
> >>
> >> Moreover it happen mainly in US keyboards
> >> (I am guessing the chars '?' and '/' are the same keyboard key)
> >
> > They are on the same key on US keyboard.  That being said '/' is not the
> > same as key code as 'shift+/' or at least they shouldn't be the same.
> >
> >>
> >> On Windows, the key events are really tricky, and I never be able to
> fix the accelerators versus
> >> hotkeys issues.
> >>
> >> In this case the issue is due to the complexity of keys events:
> >> The simplified event list is:
> >>
> >> - first the EVT_CHAR_HOOK_EVENT is send with key code = '/'
> >> if not captured:
> >> - send EVT_CHAR_EVENT is send with key code = '?'
> >>
> >> and in fact there are more events sent, both using EVT_CHAR_HOOK_EVENT
> and EVT_CHAR_EVENT.
> >>
> >> This is true for each key: a event is send with code corresponding to
> the non shifted code, and then
> >> to the shifted code (if the envent is not captured)
> >>
> >
> > While all of this is informative it still does not answer the question
> > as to why the '/' character is never getting handled in
> > EDA_DRAW_PANEL::OnKeyEvent() while the '?' character is being handled.
> > I'll keep digging around because something is different between the
> > schematic and board editors.
> >
>
> JP,
>
> I figured out what is going on with some simple tracing.  On windows
> with US keyboard layouts, the '?' key is sent as a 'shift+/' which isn't
> unexpected.  What is unexpected is that we are only allowing the shift
> key to be passed when keys 'a' - 'z' and 'A' - 'Z' are pressed by this
> code and associated comment:
>
> /* Disallow shift for keys that have two keycodes on them (e.g.
> number and
>  * punctuation keys) leaving only the "letter keys" of A-Z.
>  * Then, you can have, e.g. Ctrl-5 and Ctrl-% (GB layout)
>  * and Ctrl-( and Ctrl-5 (FR layout).
>  * Otherwise, you'd have to have to say Ctrl-Shift-5 on a FR layout
>  */
> bool keyIsLetter = ( localkey >= 'A' && localkey <= 'Z' ) ||
>( localkey >= 'a' && localkey <= 'z' );
>
> if( event.ShiftDown() && ( keyIsLetter || localkey > 256 ) )
> localkey |= GR_KB_SHIFT;
>
> This means any keys such as ';:', ''"', ',<', '>.', '/?', etc. will most
> likely be broken when used as hotkeys.  I could easily add the '/' to
> the keyIsLetter text code but that is an ugly hack which will most
> likely break for non-us keyboard layouts.  Any ideas how to implement
> this cleanly or is this just an ugliness we have to live with due to
> keyboard layout issues?
>
> Cheers,
>
> Wayne
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to  

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

> On 1. Mar 2018, at 15:28, Tomasz Wlostowski  wrote:
>> 
> Sure, I'm all in for STL - my only concern is that zone filling, as it
> is done now, does not benefit at all from multiple CPU cores. We need a

Welcome to the KiCad Mac world, citing you some mails ago:
<<<
I'd like to hear from a *single* Apple user who designs boards of
sufficient complexity for the multithreading to really have an impact on
performance.
>>>

Sorry, couldn’t resist… :)

> proper STL-based worker dispatcher for that to work.

Yes, that’s the problem.
std::async goes into that direction, but seems to pretty unusable in practice 
since it doesn’t impose any pooling, etc.


Regards,
Bernhard
___
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

[Wayne Stambaugh]

On 2/28/2018 3:46 PM, Wayne Stambaugh wrote:
> On 2/28/2018 2:31 PM, jp charras wrote:
>> Le 28/02/2018 à 17:45, Wayne Stambaugh a écrit :
>>> In the process of attempting to fix this bug[1], I ran into an issue
>>> with the '/' hotkey for all main frames.  For some reason, the hotkey
>>> help dialog is being displayed for both '/' and '?' keys which broke the
>>> track posture switching in pcbnew.  This bug only seems to affect
>>> windows.  The attached patch fixes the issue but changes the menu entry
>>> shortcut text from '?' to 'shift+?' which would make pcbnew different
>>> from all of the other mainframe windows which is ugly but it's better
>>> than a broken hotkey.
>>>
>>> While I was at it, I took a look at the schematic editor and sure enough
>>> the same behavior exists except that the same change as the attached
>>> patch does not fix the issue so the bus wire entry hotkey is broken.
>>> When I set a debugger breakpoint in the EDA_DRAW_PANEL::OnKeyEvent()
>>> function, it is not triggered for either a '/' key.  The '?' key does
>>> trigger the breakpoint.  Did someone create a character hook somewhere
>>> that could be preventing EDA_DRAW_PANEL from ever receiving the '/' key
>>> presses and passing them directly to the SCH_EDIT_FRAME?  I cannot find
>>> any reason why the EDA_DRAW_PANEL::OnKeyEvent() event handler is not
>>> being called for this key on windows.
>>>
>>> Cheers,
>>>
>>> Wayne
>>>
>>> [1]: https://bugs.launchpad.net/kicad/+bug/1751812
>>
>> Wayne,
>> Because the hotkeys can be redefined by user, I don't think your fix is 
>> working.
> 
> '/' is the default hotkey for change track posture in pcbnew and place
> bus wire entry in eeschema.  So user hotkey definitions are not relevant
> since I have not changed any of my hotkey defaults.  What is odd is that
> this fix works for pcbnew but not eeschema.
> 
>>
>> Moreover it happen mainly in US keyboards
>> (I am guessing the chars '?' and '/' are the same keyboard key)
> 
> They are on the same key on US keyboard.  That being said '/' is not the
> same as key code as 'shift+/' or at least they shouldn't be the same.
> 
>>
>> On Windows, the key events are really tricky, and I never be able to fix the 
>> accelerators versus
>> hotkeys issues.
>>
>> In this case the issue is due to the complexity of keys events:
>> The simplified event list is:
>>
>> - first the EVT_CHAR_HOOK_EVENT is send with key code = '/'
>> if not captured:
>> - send EVT_CHAR_EVENT is send with key code = '?'
>>
>> and in fact there are more events sent, both using EVT_CHAR_HOOK_EVENT and 
>> EVT_CHAR_EVENT.
>>
>> This is true for each key: a event is send with code corresponding to the 
>> non shifted code, and then
>> to the shifted code (if the envent is not captured)
>>
> 
> While all of this is informative it still does not answer the question
> as to why the '/' character is never getting handled in
> EDA_DRAW_PANEL::OnKeyEvent() while the '?' character is being handled.
> I'll keep digging around because something is different between the
> schematic and board editors.
> 

JP,

I figured out what is going on with some simple tracing.  On windows
with US keyboard layouts, the '?' key is sent as a 'shift+/' which isn't
unexpected.  What is unexpected is that we are only allowing the shift
key to be passed when keys 'a' - 'z' and 'A' - 'Z' are pressed by this
code and associated comment:

/* Disallow shift for keys that have two keycodes on them (e.g.
number and
 * punctuation keys) leaving only the "letter keys" of A-Z.
 * Then, you can have, e.g. Ctrl-5 and Ctrl-% (GB layout)
 * and Ctrl-( and Ctrl-5 (FR layout).
 * Otherwise, you'd have to have to say Ctrl-Shift-5 on a FR layout
 */
bool keyIsLetter = ( localkey >= 'A' && localkey <= 'Z' ) ||
   ( localkey >= 'a' && localkey <= 'z' );

if( event.ShiftDown() && ( keyIsLetter || localkey > 256 ) )
localkey |= GR_KB_SHIFT;

This means any keys such as ';:', ''"', ',<', '>.', '/?', etc. will most
likely be broken when used as hotkeys.  I could easily add the '/' to
the keyIsLetter text code but that is an ugly hack which will most
likely break for non-us keyboard layouts.  Any ideas how to implement
this cleanly or is this just an ugliness we have to live with due to
keyboard layout issues?

Cheers,

Wayne

___
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] MacOS + OpenMP

[Tomasz Wlostowski]

On 01/03/18 15:01, Jon Evans wrote:
> I missed that change to STL, oops!
> In that case we should standardize on STL for all new code in the future
> so that it will work on Mac.

Me too.

I don't understand the purpose of it - now all zone calculation (except
for insulated copper island removal) works in a *single* worker thread
(the main thread is just refreshing the progress dialog).

It means ~3.5x slower zone refilling on a 4-core CPU.

Can anybody comment on that?

Tom


> There are already many edge cases I have found (or users have reported)
> where KiCad is extremely slow, and we need to have a good story for
> multiprocessing so that we can take advantage of it where it makes sense
> to increase performance and/or responsiveness.
> 
> -Jon
> 
> On Thu, Mar 1, 2018 at 8:48 AM, Jeff Young  > wrote:
> 
> There’s performance and there’s responsiveness.
> 
> The footprint loading and zone filling were moved to STL so that
> progress reporting would work on Mac.
> 
> As long as we don’t introduce more OpenMP into core stuff, I’m not
> that fixated on what we use for raytracing.
> 
> Cheers,
> Jeff.
> 
> 
>> On 1 Mar 2018, at 13:34, Tomasz Wlostowski
>> > wrote:
>>
>> On 01/03/18 14:29, Jon Evans wrote:
>>> It is also used for zone filling and in my new eeschema connectivity
>>> code that I'm hoping to get merged soon after V5 release.
>>>
>>> I'm happy to help with research / testing of alternatives if we can't
>>> use OpenMP on Mac. 
>>>
>> I'd like to hear from a *single* Apple user who designs boards of
>> sufficient complexity for the multithreading to really have an
>> impact on
>> performance. What's next, rewriting Kicad in Objective-C?
>>
>> - my 5 cents
>>
>> Tom
>>
>>
>>> Jon
>>>
>>> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh >> 
>>> > wrote:
>>>
>>>    Ughh!  Thank you Apple.  I'm not opposed to this idea if
>>> OpenMP isn't a
>>>    viable option on macos.  I would like to see our macos port be
>>> on par
>>>    with linux and windows ports.
>>>
>>>    Wayne
>>>
>>>    On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
 I did look around a bit.
 Looks like OpenMP isn’t a friend of Xcode clang, because Apple
 has its
 own Grand Central Dispatch (libdispatch) implementation/library
 doing
 similar things (at first glance, didn’t look into details).
 So, I guess OpenMP maybe won’t happen soon with stock toolchain
 or we
 would have to use non-stock toolchain (probably with all
 problems that
 come with that - I have seen bad things mixing compilers, etc.).

 Seems to be quite easy to convert OpenMP for loop parallelisation
>>>    to GCD:
 <<<
 //#pragma omp parallel for
 //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
 dispatch_queue_t queue =
 dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
 dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
 {
 ...
 }
 );
>>>

 I just naively replaced all of the OpenMP for loops like above
 and now
 3d-Viewer uses all cores.
 On my i7-3770T rendering time decreased from about 100s to 30s.

 I also did it for the ratsnest loop but didn’t notice any difference
 (maybe my test PCB was just to small).

 I could play around a bit to put that stuff into some nice syntax
>>>    maybe
 similar to what Microsoft has with concurrency::parallel_for_each
   https://msdn.microsoft.com/en-us/library/dd492857.aspx
 
 So, at least ugly #ifdef around each parallel for loop could be
>>>    hidden.

 Don’t get me wrong, I don’t want to add just another parallelisation
 library/mechanism.
 And… I guess it won’t be possible to transparently cover all the
>>>    OpenMP
 pragma stuff maybe needed inside for loop body or maybe other stuff
 needed for GCD (e.g. when writing to variables outside for body).

 Thoughts? Would this be an option?

 Oh, yes:
 I did look into using STL std::async.
 Doesn’t seem to be a good idea, because it usually doesn’t seem
 to use
 anything like thread pools, etc. on various platforms.
 You probably don’t want to create that much threads… :) 


 Regards,
 Bernhard

> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>>>    >>  >> 

Re: [Kicad-developers] MacOS + OpenMP

[Jon Evans]

I missed that change to STL, oops!
In that case we should standardize on STL for all new code in the future so
that it will work on Mac.
There are already many edge cases I have found (or users have reported)
where KiCad is extremely slow, and we need to have a good story for
multiprocessing so that we can take advantage of it where it makes sense to
increase performance and/or responsiveness.

-Jon

On Thu, Mar 1, 2018 at 8:48 AM, Jeff Young  wrote:

> There’s performance and there’s responsiveness.
>
> The footprint loading and zone filling were moved to STL so that progress
> reporting would work on Mac.
>
> As long as we don’t introduce more OpenMP into core stuff, I’m not that
> fixated on what we use for raytracing.
>
> Cheers,
> Jeff.
>
>
> On 1 Mar 2018, at 13:34, Tomasz Wlostowski 
> wrote:
>
> On 01/03/18 14:29, Jon Evans wrote:
>
> It is also used for zone filling and in my new eeschema connectivity
> code that I'm hoping to get merged soon after V5 release.
>
> I'm happy to help with research / testing of alternatives if we can't
> use OpenMP on Mac.
>
> I'd like to hear from a *single* Apple user who designs boards of
> sufficient complexity for the multithreading to really have an impact on
> performance. What's next, rewriting Kicad in Objective-C?
>
> - my 5 cents
>
> Tom
>
>
> Jon
>
> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  >> wrote:
>
>Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
>viable option on macos.  I would like to see our macos port be on par
>with linux and windows ports.
>
>Wayne
>
>On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
>
> I did look around a bit.
> Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> own Grand Central Dispatch (libdispatch) implementation/library doing
> similar things (at first glance, didn’t look into details).
> So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> would have to use non-stock toolchain (probably with all problems that
> come with that - I have seen bad things mixing compilers, etc.).
>
> Seems to be quite easy to convert OpenMP for loop parallelisation
>
>to GCD:
>
> <<<
> //#pragma omp parallel for
> //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> dispatch_queue_t queue =
> dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> {
> ...
> }
> );
>
>
>
> I just naively replaced all of the OpenMP for loops like above and now
> 3d-Viewer uses all cores.
> On my i7-3770T rendering time decreased from about 100s to 30s.
>
> I also did it for the ratsnest loop but didn’t notice any difference
> (maybe my test PCB was just to small).
>
> I could play around a bit to put that stuff into some nice syntax
>
>maybe
>
> similar to what Microsoft has with concurrency::parallel_for_each
>   https://msdn.microsoft.com/en-us/library/dd492857.aspx
> So, at least ugly #ifdef around each parallel for loop could be
>
>hidden.
>
>
> Don’t get me wrong, I don’t want to add just another parallelisation
> library/mechanism.
> And… I guess it won’t be possible to transparently cover all the
>
>OpenMP
>
> pragma stuff maybe needed inside for loop body or maybe other stuff
> needed for GCD (e.g. when writing to variables outside for body).
>
> Thoughts? Would this be an option?
>
> Oh, yes:
> I did look into using STL std::async.
> Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> anything like thread pools, etc. on various platforms.
> You probably don’t want to create that much threads… :)
>
>
> Regards,
> Bernhard
>
> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>
> >
>
> 
>
>
>
> I had a quick look where OpenMP is used.
>
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I
> had never a bad experience.
>
> And then, 3D-Viewer.
>
> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> if user experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used
> for normal viewing stuff anyway.
>
> If I find some time over the weekend I will also try… but I don’t
> think it will be worth it.
>
>
> Regards,
> Bernhard
>
> On 1. Mar 2018, at 00:50, Jeff Young 
>>
>
>   
> Or rip it out and use STL?
>
> On 28 Feb 2018, at 23:38, Jon Evans 
>>
>
> 

Re: [Kicad-developers] MacOS + OpenMP

[Wayne Stambaugh]

Once we figure out what is involved and any risks, we can make a
decision at that point.  I'm working under the assumption that this only
applies to the raytracing.

Wayne

On 3/1/2018 8:41 AM, Bernhard Stegmaier wrote:
> Currently, I fully agree with you.
> 
> The only spot right now where it has real impact is the raytracing 3d viewer.
> And for me it is also only 3x faster with threading, so not that critical for 
> some “offline” functionality.
> 
> But more and more OpenMP stuff might get added which maybe will make an 
> impact in future.
> This has caused much problems with the zone filling already…
> 
> So, from my point of view at least a clear strategy should be defined.
> 
> 
> Bernhard
> 
>> On 1. Mar 2018, at 14:34, Tomasz Wlostowski  
>> wrote:
>>
>> On 01/03/18 14:29, Jon Evans wrote:
>>> It is also used for zone filling and in my new eeschema connectivity
>>> code that I'm hoping to get merged soon after V5 release.
>>>
>>> I'm happy to help with research / testing of alternatives if we can't
>>> use OpenMP on Mac. 
>>>
>> I'd like to hear from a *single* Apple user who designs boards of
>> sufficient complexity for the multithreading to really have an impact on
>> performance. What's next, rewriting Kicad in Objective-C?
>>
>> - my 5 cents
>>
>> Tom
>>
>>
>>> Jon
>>>
>>> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh >> > wrote:
>>>
>>>Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
>>>viable option on macos.  I would like to see our macos port be on par
>>>with linux and windows ports.
>>>
>>>Wayne
>>>
>>>On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
 I did look around a bit.
 Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
 own Grand Central Dispatch (libdispatch) implementation/library doing
 similar things (at first glance, didn’t look into details).
 So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
 would have to use non-stock toolchain (probably with all problems that
 come with that - I have seen bad things mixing compilers, etc.).

 Seems to be quite easy to convert OpenMP for loop parallelisation
>>>to GCD:
 <<<
 //#pragma omp parallel for
 //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
 dispatch_queue_t queue =
 dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
 dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
 {
 ...
 }
 );
>>>

 I just naively replaced all of the OpenMP for loops like above and now
 3d-Viewer uses all cores.
 On my i7-3770T rendering time decreased from about 100s to 30s.

 I also did it for the ratsnest loop but didn’t notice any difference
 (maybe my test PCB was just to small).

 I could play around a bit to put that stuff into some nice syntax
>>>maybe
 similar to what Microsoft has with concurrency::parallel_for_each
   https://msdn.microsoft.com/en-us/library/dd492857.aspx
 So, at least ugly #ifdef around each parallel for loop could be
>>>hidden.

 Don’t get me wrong, I don’t want to add just another parallelisation
 library/mechanism.
 And… I guess it won’t be possible to transparently cover all the
>>>OpenMP
 pragma stuff maybe needed inside for loop body or maybe other stuff
 needed for GCD (e.g. when writing to variables outside for body).

 Thoughts? Would this be an option?

 Oh, yes:
 I did look into using STL std::async.
 Doesn’t seem to be a good idea, because it usually doesn’t seem to use
 anything like thread pools, etc. on various platforms.
 You probably don’t want to create that much threads… :) 


 Regards,
 Bernhard

> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>>>
> >>>> wrote:
>
> I had a quick look where OpenMP is used.
>
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I
> had never a bad experience.
>
> And then, 3D-Viewer.
>
> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> if user experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used
> for normal viewing stuff anyway.
>
> If I find some time over the weekend I will also try… but I don’t
> think it will be worth it.
>
>
> Regards,
> Bernhard
>
>> On 1. Mar 2018, at 00:50, Jeff Young >>
>> >> wrote:
>>
>> Or rip it out and use STL?
>>
>>> On 28 Feb 2018, at 23:38, Jon Evans 

Re: [Kicad-developers] MacOS + OpenMP

[Jeff Young]

There’s performance and there’s responsiveness.

The footprint loading and zone filling were moved to STL so that progress 
reporting would work on Mac.

As long as we don’t introduce more OpenMP into core stuff, I’m not that fixated 
on what we use for raytracing.

Cheers,
Jeff.


> On 1 Mar 2018, at 13:34, Tomasz Wlostowski  wrote:
> 
> On 01/03/18 14:29, Jon Evans wrote:
>> It is also used for zone filling and in my new eeschema connectivity
>> code that I'm hoping to get merged soon after V5 release.
>> 
>> I'm happy to help with research / testing of alternatives if we can't
>> use OpenMP on Mac. 
>> 
> I'd like to hear from a *single* Apple user who designs boards of
> sufficient complexity for the multithreading to really have an impact on
> performance. What's next, rewriting Kicad in Objective-C?
> 
> - my 5 cents
> 
> Tom
> 
> 
>> Jon
>> 
>> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh > 
>> >> wrote:
>> 
>>Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
>>viable option on macos.  I would like to see our macos port be on par
>>with linux and windows ports.
>> 
>>Wayne
>> 
>>On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
>>> I did look around a bit.
>>> Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
>>> own Grand Central Dispatch (libdispatch) implementation/library doing
>>> similar things (at first glance, didn’t look into details).
>>> So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
>>> would have to use non-stock toolchain (probably with all problems that
>>> come with that - I have seen bad things mixing compilers, etc.).
>>> 
>>> Seems to be quite easy to convert OpenMP for loop parallelisation
>>to GCD:
>>> <<<
>>> //#pragma omp parallel for
>>> //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
>>> dispatch_queue_t queue =
>>> dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
>>> dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
>>> {
>>> ...
>>> }
>>> );
>> 
>>> 
>>> I just naively replaced all of the OpenMP for loops like above and now
>>> 3d-Viewer uses all cores.
>>> On my i7-3770T rendering time decreased from about 100s to 30s.
>>> 
>>> I also did it for the ratsnest loop but didn’t notice any difference
>>> (maybe my test PCB was just to small).
>>> 
>>> I could play around a bit to put that stuff into some nice syntax
>>maybe
>>> similar to what Microsoft has with concurrency::parallel_for_each
>>>   https://msdn.microsoft.com/en-us/library/dd492857.aspx 
>>> 
>>> So, at least ugly #ifdef around each parallel for loop could be
>>hidden.
>>> 
>>> Don’t get me wrong, I don’t want to add just another parallelisation
>>> library/mechanism.
>>> And… I guess it won’t be possible to transparently cover all the
>>OpenMP
>>> pragma stuff maybe needed inside for loop body or maybe other stuff
>>> needed for GCD (e.g. when writing to variables outside for body).
>>> 
>>> Thoughts? Would this be an option?
>>> 
>>> Oh, yes:
>>> I did look into using STL std::async.
>>> Doesn’t seem to be a good idea, because it usually doesn’t seem to use
>>> anything like thread pools, etc. on various platforms.
>>> You probably don’t want to create that much threads… :) 
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>> 
>> >
 
>> On 1. Mar 2018, at 00:50, Jeff Young  
>>>
>    
> Or rip it out and use STL?
> 
>> On 28 Feb 2018, at 23:38, Jon Evans > 
>>>
>> 

Re: [Kicad-developers] MacOS + OpenMP

[Adam Wolf]

This seems like it is not critical for the upcoming V5 release, but
that a strategy should be determined before we get too far into V6,
right?

Adam

On Thu, Mar 1, 2018 at 7:41 AM, Bernhard Stegmaier
 wrote:
> Currently, I fully agree with you.
>
> The only spot right now where it has real impact is the raytracing 3d viewer.
> And for me it is also only 3x faster with threading, so not that critical for 
> some “offline” functionality.
>
> But more and more OpenMP stuff might get added which maybe will make an 
> impact in future.
> This has caused much problems with the zone filling already…
>
> So, from my point of view at least a clear strategy should be defined.
>
>
> Bernhard
>
>> On 1. Mar 2018, at 14:34, Tomasz Wlostowski  
>> wrote:
>>
>> On 01/03/18 14:29, Jon Evans wrote:
>>> It is also used for zone filling and in my new eeschema connectivity
>>> code that I'm hoping to get merged soon after V5 release.
>>>
>>> I'm happy to help with research / testing of alternatives if we can't
>>> use OpenMP on Mac.
>>>
>> I'd like to hear from a *single* Apple user who designs boards of
>> sufficient complexity for the multithreading to really have an impact on
>> performance. What's next, rewriting Kicad in Objective-C?
>>
>> - my 5 cents
>>
>> Tom
>>
>>
>>> Jon
>>>
>>> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh >> > wrote:
>>>
>>>Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
>>>viable option on macos.  I would like to see our macos port be on par
>>>with linux and windows ports.
>>>
>>>Wayne
>>>
>>>On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
 I did look around a bit.
 Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
 own Grand Central Dispatch (libdispatch) implementation/library doing
 similar things (at first glance, didn’t look into details).
 So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
 would have to use non-stock toolchain (probably with all problems that
 come with that - I have seen bad things mixing compilers, etc.).

 Seems to be quite easy to convert OpenMP for loop parallelisation
>>>to GCD:
 <<<
 //#pragma omp parallel for
 //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
 dispatch_queue_t queue =
 dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
 dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
 {
 ...
 }
 );
>>>

 I just naively replaced all of the OpenMP for loops like above and now
 3d-Viewer uses all cores.
 On my i7-3770T rendering time decreased from about 100s to 30s.

 I also did it for the ratsnest loop but didn’t notice any difference
 (maybe my test PCB was just to small).

 I could play around a bit to put that stuff into some nice syntax
>>>maybe
 similar to what Microsoft has with concurrency::parallel_for_each
   https://msdn.microsoft.com/en-us/library/dd492857.aspx
 So, at least ugly #ifdef around each parallel for loop could be
>>>hidden.

 Don’t get me wrong, I don’t want to add just another parallelisation
 library/mechanism.
 And… I guess it won’t be possible to transparently cover all the
>>>OpenMP
 pragma stuff maybe needed inside for loop body or maybe other stuff
 needed for GCD (e.g. when writing to variables outside for body).

 Thoughts? Would this be an option?

 Oh, yes:
 I did look into using STL std::async.
 Doesn’t seem to be a good idea, because it usually doesn’t seem to use
 anything like thread pools, etc. on various platforms.
 You probably don’t want to create that much threads… :)


 Regards,
 Bernhard

> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
>>>
> >>>> wrote:
>
> I had a quick look where OpenMP is used.
>
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I
> had never a bad experience.
>
> And then, 3D-Viewer.
>
> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> if user experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used
> for normal viewing stuff anyway.
>
> If I find some time over the weekend I will also try… but I don’t
> think it will be worth it.
>
>
> Regards,
> Bernhard
>
>> On 1. Mar 2018, at 00:50, Jeff Young >>
>> >> wrote:
>>
>> Or rip it out and use STL?
>>
>>> On 28 Feb 2018, at 23:38, Jon Evans 

Re: [Kicad-developers] MacOS + OpenMP

[Jeff Young]

The zone filler was moved to STL.

> On 1 Mar 2018, at 13:29, Jon Evans  wrote:
> 
> It is also used for zone filling and in my new eeschema connectivity code 
> that I'm hoping to get merged soon after V5 release.
> 
> I'm happy to help with research / testing of alternatives if we can't use 
> OpenMP on Mac. 
> 
> Jon
> 
> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  > wrote:
> Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
> viable option on macos.  I would like to see our macos port be on par
> with linux and windows ports.
> 
> Wayne
> 
> On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> > I did look around a bit.
> > Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> > own Grand Central Dispatch (libdispatch) implementation/library doing
> > similar things (at first glance, didn’t look into details).
> > So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> > would have to use non-stock toolchain (probably with all problems that
> > come with that - I have seen bad things mixing compilers, etc.).
> >
> > Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
> > <<<
> > //#pragma omp parallel for
> > //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> > dispatch_queue_t queue =
> > dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> > dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> > {
> > ...
> > }
> > );
> 
> >
> > I just naively replaced all of the OpenMP for loops like above and now
> > 3d-Viewer uses all cores.
> > On my i7-3770T rendering time decreased from about 100s to 30s.
> >
> > I also did it for the ratsnest loop but didn’t notice any difference
> > (maybe my test PCB was just to small).
> >
> > I could play around a bit to put that stuff into some nice syntax maybe
> > similar to what Microsoft has with concurrency::parallel_for_each
> >   https://msdn.microsoft.com/en-us/library/dd492857.aspx 
> > 
> > So, at least ugly #ifdef around each parallel for loop could be hidden.
> >
> > Don’t get me wrong, I don’t want to add just another parallelisation
> > library/mechanism.
> > And… I guess it won’t be possible to transparently cover all the OpenMP
> > pragma stuff maybe needed inside for loop body or maybe other stuff
> > needed for GCD (e.g. when writing to variables outside for body).
> >
> > Thoughts? Would this be an option?
> >
> > Oh, yes:
> > I did look into using STL std::async.
> > Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> > anything like thread pools, etc. on various platforms.
> > You probably don’t want to create that much threads… :) 
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 1. Mar 2018, at 08:40, Bernhard Stegmaier  >> 
> >> >> wrote:
> >>
> >> I had a quick look where OpenMP is used.
> >>
> >> I found it somewhere in the connectivity/ratsnest code.
> >> I don’t know of any complaints in that area and even on my old HW I
> >> had never a bad experience.
> >>
> >> And then, 3D-Viewer.
> >>
> >> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> >> if user experience will be that bad without OpenMP.
> >> IMHO it’s only the Raytracing view, which isn’t intended to be used
> >> for normal viewing stuff anyway.
> >>
> >> If I find some time over the weekend I will also try… but I don’t
> >> think it will be worth it.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 1. Mar 2018, at 00:50, Jeff Young  >>> 
> >>> >> wrote:
> >>>
> >>> Or rip it out and use STL?
> >>>
>  On 28 Feb 2018, at 23:38, Jon Evans   
>  >> wrote:
> 
>  Hi all,
> 
>  Does anyone have a working build setup for getting OpenMP-enabled
>  KiCad out of MacOS?
>  If so, please share how -- I tried for a bit but couldn't get it
>  going (I'm not super familiar with the MacOS toolchain yet).
> 
>  We should make sure that the 5.0 release is built with OpenMP,
>  otherwise our Mac users are going to have a slower user experience.
> 
>  -Jon
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers 
>  
>  Post to : kicad-developers@lists.launchpad.net 
>  
>    >
>  Unsubscribe : https://launchpad.net/~kicad-developers 
>  
>  More help   

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

The zone filling code was the only spot which didn’t work by just simply 
replacing the for loop with dispatch_apply.
I’ll have to dig a little deeper on what has to be done there… I guess it is 
something about using variables outside the loop body in the clang block given 
to dispatch_apply.


Bernhard

> On 1. Mar 2018, at 14:29, Jon Evans  wrote:
> 
> It is also used for zone filling and in my new eeschema connectivity code 
> that I'm hoping to get merged soon after V5 release.
> 
> I'm happy to help with research / testing of alternatives if we can't use 
> OpenMP on Mac. 
> 
> Jon
> 
> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  > wrote:
> Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
> viable option on macos.  I would like to see our macos port be on par
> with linux and windows ports.
> 
> Wayne
> 
> On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> > I did look around a bit.
> > Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> > own Grand Central Dispatch (libdispatch) implementation/library doing
> > similar things (at first glance, didn’t look into details).
> > So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> > would have to use non-stock toolchain (probably with all problems that
> > come with that - I have seen bad things mixing compilers, etc.).
> >
> > Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
> > <<<
> > //#pragma omp parallel for
> > //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> > dispatch_queue_t queue =
> > dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> > dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> > {
> > ...
> > }
> > );
> 
> >
> > I just naively replaced all of the OpenMP for loops like above and now
> > 3d-Viewer uses all cores.
> > On my i7-3770T rendering time decreased from about 100s to 30s.
> >
> > I also did it for the ratsnest loop but didn’t notice any difference
> > (maybe my test PCB was just to small).
> >
> > I could play around a bit to put that stuff into some nice syntax maybe
> > similar to what Microsoft has with concurrency::parallel_for_each
> >   https://msdn.microsoft.com/en-us/library/dd492857.aspx 
> > 
> > So, at least ugly #ifdef around each parallel for loop could be hidden.
> >
> > Don’t get me wrong, I don’t want to add just another parallelisation
> > library/mechanism.
> > And… I guess it won’t be possible to transparently cover all the OpenMP
> > pragma stuff maybe needed inside for loop body or maybe other stuff
> > needed for GCD (e.g. when writing to variables outside for body).
> >
> > Thoughts? Would this be an option?
> >
> > Oh, yes:
> > I did look into using STL std::async.
> > Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> > anything like thread pools, etc. on various platforms.
> > You probably don’t want to create that much threads… :) 
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 1. Mar 2018, at 08:40, Bernhard Stegmaier  >> 
> >> >> wrote:
> >>
> >> I had a quick look where OpenMP is used.
> >>
> >> I found it somewhere in the connectivity/ratsnest code.
> >> I don’t know of any complaints in that area and even on my old HW I
> >> had never a bad experience.
> >>
> >> And then, 3D-Viewer.
> >>
> >> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> >> if user experience will be that bad without OpenMP.
> >> IMHO it’s only the Raytracing view, which isn’t intended to be used
> >> for normal viewing stuff anyway.
> >>
> >> If I find some time over the weekend I will also try… but I don’t
> >> think it will be worth it.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 1. Mar 2018, at 00:50, Jeff Young  >>> 
> >>> >> wrote:
> >>>
> >>> Or rip it out and use STL?
> >>>
>  On 28 Feb 2018, at 23:38, Jon Evans   
>  >> wrote:
> 
>  Hi all,
> 
>  Does anyone have a working build setup for getting OpenMP-enabled
>  KiCad out of MacOS?
>  If so, please share how -- I tried for a bit but couldn't get it
>  going (I'm not super familiar with the MacOS toolchain yet).
> 
>  We should make sure that the 5.0 release is built with OpenMP,
>  otherwise our Mac users are going to have a slower user experience.
> 
>  -Jon
>  ___
>  Mailing list: https://launchpad.net/~kicad-developers 
>  
>  Post to : kicad-developers@lists.launchpad.net 
>  

Re: [Kicad-developers] MacOS + OpenMP

[Tomasz Wlostowski]

On 01/03/18 14:29, Jon Evans wrote:
> It is also used for zone filling and in my new eeschema connectivity
> code that I'm hoping to get merged soon after V5 release.
> 
> I'm happy to help with research / testing of alternatives if we can't
> use OpenMP on Mac. 
> 
I'd like to hear from a *single* Apple user who designs boards of
sufficient complexity for the multithreading to really have an impact on
performance. What's next, rewriting Kicad in Objective-C?

- my 5 cents

Tom


> Jon
> 
> On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  > wrote:
> 
> Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
> viable option on macos.  I would like to see our macos port be on par
> with linux and windows ports.
> 
> Wayne
> 
> On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> > I did look around a bit.
> > Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> > own Grand Central Dispatch (libdispatch) implementation/library doing
> > similar things (at first glance, didn’t look into details).
> > So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> > would have to use non-stock toolchain (probably with all problems that
> > come with that - I have seen bad things mixing compilers, etc.).
> >
> > Seems to be quite easy to convert OpenMP for loop parallelisation
> to GCD:
> > <<<
> > //#pragma omp parallel for
> > //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> > dispatch_queue_t queue =
> > dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> > dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> > {
> > ...
> > }
> > );
> 
> >
> > I just naively replaced all of the OpenMP for loops like above and now
> > 3d-Viewer uses all cores.
> > On my i7-3770T rendering time decreased from about 100s to 30s.
> >
> > I also did it for the ratsnest loop but didn’t notice any difference
> > (maybe my test PCB was just to small).
> >
> > I could play around a bit to put that stuff into some nice syntax
> maybe
> > similar to what Microsoft has with concurrency::parallel_for_each
> >   https://msdn.microsoft.com/en-us/library/dd492857.aspx
> > So, at least ugly #ifdef around each parallel for loop could be
> hidden.
> >
> > Don’t get me wrong, I don’t want to add just another parallelisation
> > library/mechanism.
> > And… I guess it won’t be possible to transparently cover all the
> OpenMP
> > pragma stuff maybe needed inside for loop body or maybe other stuff
> > needed for GCD (e.g. when writing to variables outside for body).
> >
> > Thoughts? Would this be an option?
> >
> > Oh, yes:
> > I did look into using STL std::async.
> > Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> > anything like thread pools, etc. on various platforms.
> > You probably don’t want to create that much threads… :) 
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 1. Mar 2018, at 08:40, Bernhard Stegmaier
> 
> >>  >> wrote:
> >>
> >> I had a quick look where OpenMP is used.
> >>
> >> I found it somewhere in the connectivity/ratsnest code.
> >> I don’t know of any complaints in that area and even on my old HW I
> >> had never a bad experience.
> >>
> >> And then, 3D-Viewer.
> >>
> >> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> >> if user experience will be that bad without OpenMP.
> >> IMHO it’s only the Raytracing view, which isn’t intended to be used
> >> for normal viewing stuff anyway.
> >>
> >> If I find some time over the weekend I will also try… but I don’t
> >> think it will be worth it.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 1. Mar 2018, at 00:50, Jeff Young  
> >>> >> wrote:
> >>>
> >>> Or rip it out and use STL?
> >>>
>  On 28 Feb 2018, at 23:38, Jon Evans  
>  >> wrote:
> 
>  Hi all,
> 
>  Does anyone have a working build setup for getting OpenMP-enabled
>  KiCad out of MacOS?
>  If so, please share how -- I tried for a bit but couldn't get it
>  going (I'm not super familiar with the MacOS toolchain yet).
> 
>  We should make sure that the 5.0 release is built with OpenMP,
>  otherwise our Mac users are going to have a slower user experience.
> 
>  -Jon
> 

Re: [Kicad-developers] MacOS + OpenMP

[Jon Evans]

It is also used for zone filling and in my new eeschema connectivity code
that I'm hoping to get merged soon after V5 release.

I'm happy to help with research / testing of alternatives if we can't use
OpenMP on Mac.

Jon

On Thu, Mar 1, 2018, 08:26 Wayne Stambaugh  wrote:

> Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
> viable option on macos.  I would like to see our macos port be on par
> with linux and windows ports.
>
> Wayne
>
> On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> > I did look around a bit.
> > Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> > own Grand Central Dispatch (libdispatch) implementation/library doing
> > similar things (at first glance, didn’t look into details).
> > So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> > would have to use non-stock toolchain (probably with all problems that
> > come with that - I have seen bad things mixing compilers, etc.).
> >
> > Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
> > <<<
> > //#pragma omp parallel for
> > //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> > dispatch_queue_t queue =
> > dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> > dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> > {
> > ...
> > }
> > );
> 
> >
> > I just naively replaced all of the OpenMP for loops like above and now
> > 3d-Viewer uses all cores.
> > On my i7-3770T rendering time decreased from about 100s to 30s.
> >
> > I also did it for the ratsnest loop but didn’t notice any difference
> > (maybe my test PCB was just to small).
> >
> > I could play around a bit to put that stuff into some nice syntax maybe
> > similar to what Microsoft has with concurrency::parallel_for_each
> >   https://msdn.microsoft.com/en-us/library/dd492857.aspx
> > So, at least ugly #ifdef around each parallel for loop could be hidden.
> >
> > Don’t get me wrong, I don’t want to add just another parallelisation
> > library/mechanism.
> > And… I guess it won’t be possible to transparently cover all the OpenMP
> > pragma stuff maybe needed inside for loop body or maybe other stuff
> > needed for GCD (e.g. when writing to variables outside for body).
> >
> > Thoughts? Would this be an option?
> >
> > Oh, yes:
> > I did look into using STL std::async.
> > Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> > anything like thread pools, etc. on various platforms.
> > You probably don’t want to create that much threads… :)
> >
> >
> > Regards,
> > Bernhard
> >
> >> On 1. Mar 2018, at 08:40, Bernhard Stegmaier  >> > wrote:
> >>
> >> I had a quick look where OpenMP is used.
> >>
> >> I found it somewhere in the connectivity/ratsnest code.
> >> I don’t know of any complaints in that area and even on my old HW I
> >> had never a bad experience.
> >>
> >> And then, 3D-Viewer.
> >>
> >> So, in my opinion it is basically only about 3D-Viewer… I don’t know
> >> if user experience will be that bad without OpenMP.
> >> IMHO it’s only the Raytracing view, which isn’t intended to be used
> >> for normal viewing stuff anyway.
> >>
> >> If I find some time over the weekend I will also try… but I don’t
> >> think it will be worth it.
> >>
> >>
> >> Regards,
> >> Bernhard
> >>
> >>> On 1. Mar 2018, at 00:50, Jeff Young  >>> > wrote:
> >>>
> >>> Or rip it out and use STL?
> >>>
>  On 28 Feb 2018, at 23:38, Jon Evans   > wrote:
> 
>  Hi all,
> 
>  Does anyone have a working build setup for getting OpenMP-enabled
>  KiCad out of MacOS?
>  If so, please share how -- I tried for a bit but couldn't get it
>  going (I'm not super familiar with the MacOS toolchain yet).
> 
>  We should make sure that the 5.0 release is built with OpenMP,
>  otherwise our Mac users are going to have a slower user experience.
> 
>  -Jon
>  ___
>  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
> >> 
> 

Re: [Kicad-developers] MacOS + OpenMP

[Wayne Stambaugh]

Ughh!  Thank you Apple.  I'm not opposed to this idea if OpenMP isn't a
viable option on macos.  I would like to see our macos port be on par
with linux and windows ports.

Wayne

On 3/1/2018 8:20 AM, Bernhard Stegmaier wrote:
> I did look around a bit.
> Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its
> own Grand Central Dispatch (libdispatch) implementation/library doing
> similar things (at first glance, didn’t look into details).
> So, I guess OpenMP maybe won’t happen soon with stock toolchain or we
> would have to use non-stock toolchain (probably with all problems that
> come with that - I have seen bad things mixing compilers, etc.).
> 
> Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
> <<<
> //#pragma omp parallel for
> //for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
> dispatch_queue_t queue =
> dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
> dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
> {
> ...
> }
> );

> 
> I just naively replaced all of the OpenMP for loops like above and now
> 3d-Viewer uses all cores.
> On my i7-3770T rendering time decreased from about 100s to 30s.
> 
> I also did it for the ratsnest loop but didn’t notice any difference
> (maybe my test PCB was just to small).
> 
> I could play around a bit to put that stuff into some nice syntax maybe
> similar to what Microsoft has with concurrency::parallel_for_each
>   https://msdn.microsoft.com/en-us/library/dd492857.aspx
> So, at least ugly #ifdef around each parallel for loop could be hidden.
> 
> Don’t get me wrong, I don’t want to add just another parallelisation
> library/mechanism.
> And… I guess it won’t be possible to transparently cover all the OpenMP
> pragma stuff maybe needed inside for loop body or maybe other stuff
> needed for GCD (e.g. when writing to variables outside for body).
> 
> Thoughts? Would this be an option?
> 
> Oh, yes:
> I did look into using STL std::async.
> Doesn’t seem to be a good idea, because it usually doesn’t seem to use
> anything like thread pools, etc. on various platforms.
> You probably don’t want to create that much threads… :) 
> 
> 
> Regards,
> Bernhard
> 
>> On 1. Mar 2018, at 08:40, Bernhard Stegmaier > > wrote:
>>
>> I had a quick look where OpenMP is used.
>>
>> I found it somewhere in the connectivity/ratsnest code.
>> I don’t know of any complaints in that area and even on my old HW I
>> had never a bad experience.
>>
>> And then, 3D-Viewer.
>>
>> So, in my opinion it is basically only about 3D-Viewer… I don’t know
>> if user experience will be that bad without OpenMP.
>> IMHO it’s only the Raytracing view, which isn’t intended to be used
>> for normal viewing stuff anyway.
>>
>> If I find some time over the weekend I will also try… but I don’t
>> think it will be worth it.
>>
>>
>> Regards,
>> Bernhard
>>
>>> On 1. Mar 2018, at 00:50, Jeff Young >> > wrote:
>>>
>>> Or rip it out and use STL?
>>>
 On 28 Feb 2018, at 23:38, Jon Evans > wrote:

 Hi all,

 Does anyone have a working build setup for getting OpenMP-enabled
 KiCad out of MacOS?
 If so, please share how -- I tried for a bit but couldn't get it
 going (I'm not super familiar with the MacOS toolchain yet).

 We should make sure that the 5.0 release is built with OpenMP,
 otherwise our Mac users are going to have a slower user experience.

 -Jon
 ___
 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 : 

Re: [Kicad-developers] MacOS + OpenMP

[Bernhard Stegmaier]

I did look around a bit.
Looks like OpenMP isn’t a friend of Xcode clang, because Apple has its own 
Grand Central Dispatch (libdispatch) implementation/library doing similar 
things (at first glance, didn’t look into details).
So, I guess OpenMP maybe won’t happen soon with stock toolchain or we would 
have to use non-stock toolchain (probably with all problems that come with that 
- I have seen bad things mixing compilers, etc.).

Seems to be quite easy to convert OpenMP for loop parallelisation to GCD:
<<<
//#pragma omp parallel for
//for( signed int i = 0; i < aPolySet.OutlineCount(); ++i )
dispatch_queue_t queue = 
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_apply(aPolySet.OutlineCount(), queue, ^(size_t i)
{
...
}
);
>>>

I just naively replaced all of the OpenMP for loops like above and now 
3d-Viewer uses all cores.
On my i7-3770T rendering time decreased from about 100s to 30s.

I also did it for the ratsnest loop but didn’t notice any difference (maybe my 
test PCB was just to small).

I could play around a bit to put that stuff into some nice syntax maybe similar 
to what Microsoft has with concurrency::parallel_for_each
  https://msdn.microsoft.com/en-us/library/dd492857.aspx 

So, at least ugly #ifdef around each parallel for loop could be hidden.

Don’t get me wrong, I don’t want to add just another parallelisation 
library/mechanism.
And… I guess it won’t be possible to transparently cover all the OpenMP pragma 
stuff maybe needed inside for loop body or maybe other stuff needed for GCD 
(e.g. when writing to variables outside for body).

Thoughts? Would this be an option?

Oh, yes:
I did look into using STL std::async.
Doesn’t seem to be a good idea, because it usually doesn’t seem to use anything 
like thread pools, etc. on various platforms.
You probably don’t want to create that much threads… :) 


Regards,
Bernhard

> On 1. Mar 2018, at 08:40, Bernhard Stegmaier  wrote:
> 
> I had a quick look where OpenMP is used.
> 
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I had never 
> a bad experience.
> 
> And then, 3D-Viewer.
> 
> So, in my opinion it is basically only about 3D-Viewer… I don’t know if user 
> experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used for 
> normal viewing stuff anyway.
> 
> If I find some time over the weekend I will also try… but I don’t think it 
> will be worth it.
> 
> 
> Regards,
> Bernhard
> 
>> On 1. Mar 2018, at 00:50, Jeff Young  wrote:
>> 
>> Or rip it out and use STL?
>> 
>>> On 28 Feb 2018, at 23:38, Jon Evans  wrote:
>>> 
>>> Hi all,
>>> 
>>> Does anyone have a working build setup for getting OpenMP-enabled KiCad out 
>>> of MacOS?
>>> If so, please share how -- I tried for a bit but couldn't get it going (I'm 
>>> not super familiar with the MacOS toolchain yet).
>>> 
>>> We should make sure that the 5.0 release is built with OpenMP, otherwise 
>>> our Mac users are going to have a slower user experience.
>>> 
>>> -Jon
>>> ___
>>> 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] Alternative presentation of Symbol properties

[Wayne Stambaugh]

Maybe I'm not seeing this correctly but your editor is only showing the
fields for a single symbol.  I thought you were replacing the current
table editor where you could group symbols and edit field values for
group of symbols rather than each symbol individually.  I would like to
see what you have currently done embedded in the symbol properties
editor to replace the one at a time field editing that we currently have.

On 3/1/2018 7:29 AM, Jeff Young wrote:
> What do you guys think of this for displaying / editing symbol fields:
> 
> 
> On the plus side it’s much more direct to edit stuff (without having to
> select the field first to get its properties set in the controls).
> 
> On the minus side it is perhaps a bit more industrial looking.
> 
> 
> ___
> 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] Alternative presentation of Symbol properties

[Jeff Young]

Hi Simon,

I do.  (Pin Table and Fields Editor too.)

My guess is you tried to use a wxDataViewCtrl, which is a mess.

These are based on the wxGrid.

You can try out the pin table and fields editor (the spreadsheet icon at the 
top of a schematic window) at: https://git.launchpad.net/~jeyjey/kicad/

Cheers,
Jeff.


> On 1 Mar 2018, at 12:40, Simon Richter  wrote:
> 
> Hi,
> 
> On 01.03.2018 13:29, Jeff Young wrote:
> 
>> What do you guys think of this for displaying / editing symbol fields:
> 
> Do you have actual working code for that? I've tried getting this to
> work for editing pin type in the pin table, but got nowhere as widgets
> wouldn't be rendered and focus was all over the place.
> 
>   Simon
> 
> ___
> 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] Alternative presentation of Symbol properties

[Simon Richter]

Hi,

On 01.03.2018 13:29, Jeff Young wrote:

> What do you guys think of this for displaying / editing symbol fields:

Do you have actual working code for that? I've tried getting this to
work for editing pin type in the pin table, but got nowhere as widgets
wouldn't be rendered and focus was all over the place.

   Simon



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

[Kicad-developers] Alternative presentation of Symbol properties

[Jeff Young]

What do you guys think of this for displaying / editing symbol fields:



On the plus side it’s much more direct to edit stuff (without having to select 
the field first to get its properties set in the controls).

On the minus side it is perhaps a bit more industrial looking.___
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] MacOS + OpenMP

[Andrey Kuznetsov]

Is there a complicated board design online I could download and test for
comparison between macOS and windows?
Someone people have used before for kicad verification for example.

On Wed, Feb 28, 2018 at 11:40 PM, Bernhard Stegmaier <
stegma...@sw-systems.de> wrote:

> I had a quick look where OpenMP is used.
>
> I found it somewhere in the connectivity/ratsnest code.
> I don’t know of any complaints in that area and even on my old HW I had
> never a bad experience.
>
> And then, 3D-Viewer.
>
> So, in my opinion it is basically only about 3D-Viewer… I don’t know if
> user experience will be that bad without OpenMP.
> IMHO it’s only the Raytracing view, which isn’t intended to be used for
> normal viewing stuff anyway.
>
> If I find some time over the weekend I will also try… but I don’t think it
> will be worth it.
>
>
> Regards,
> Bernhard
>
> > On 1. Mar 2018, at 00:50, Jeff Young  wrote:
> >
> > Or rip it out and use STL?
> >
> >> On 28 Feb 2018, at 23:38, Jon Evans  wrote:
> >>
> >> Hi all,
> >>
> >> Does anyone have a working build setup for getting OpenMP-enabled KiCad
> out of MacOS?
> >> If so, please share how -- I tried for a bit but couldn't get it going
> (I'm not super familiar with the MacOS toolchain yet).
> >>
> >> We should make sure that the 5.0 release is built with OpenMP,
> otherwise our Mac users are going to have a slower user experience.
> >>
> >> -Jon
> >> ___
> >> 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
>



-- 
Remember The Past, Live The Present, Change The Future
Those who look only to the past or the present are certain to miss the
future [JFK]

kandre...@gmail.com
Live Long and Prosper,
Andrey
___
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