Re: [Kicad-developers] MacOS Packaging Question

[Nick Østergaard]

This is the current scripts used for the current nightlies for macos
https://github.com/wayneandlayne/KiCadMacOSPackaging.git

2018-03-04 0:37 GMT+01:00 Rene Pöschl :

> On 03/03/18 23:32, Seth Hillbrand wrote:
>
>> ​In the current nightly MacOS builds, we package the applications,
>> symbols and 3d models but no footprints.
>>
>> Is this an oversight?
>>
>> -S​
>>
>>
>>
> This might be because in kicad 4 the footprints where downloaded on demand
> via the github plugin.
> With the new library setup (single repository for all footprints) this is
> no longer possible.
>
> I assume some packages for other operating systems might have a similar
> problem
>
> ___
> 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] Mac HighDPI performance

[Bernhard Stegmaier]

No.

> On 4. Mar 2018, at 01:51, Andrey Kuznetsov  wrote:
> 
> Would it be an easy fix to change the text/font such that it does not affect 
> performance so significantly on MacOS?
> 
> On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh  > wrote:
> On 03/03/2018 07:33 AM, Jeff Young wrote:
> Hi Andrey,
> 
> I did some profiling and I’d guess that the difference in eeschema and 
> pcbnew-legacy performance is down to there being more text in the schema.  
> Since we use a stroke font, there’s a lot of stroke segments in each letter.
> 
> @Devs,
> 
> I understand why we use a stroke font on the PCB, but there’s not much reason 
> in eeschema, is there?
> 
> This is possibly one of the things that I plan on changing after the new 
> schematic file format is written.  The new file format will support font 
> definitions so replacing the stroke font in Eeschema should be doable. 
> Whether or not I have time to make this change remains to be seen.
> 
> Wayne
> 
> 
> Cheers,
> Jeff.
> 
> 
> On 3 Mar 2018, at 08:18, Andrey Kuznetsov    >> wrote:
> 
> The motherboard project is not very complex, I would say that performance 
> should be tolerable UP to that size complexity, if we set the bar any lower, 
> usability will suffer and people won't like KiCad because it's sluggish and 
> interface lag is the worst kind of lag.
> My project isn't finished and Chris' project is available now, is just the 
> right complexity and has layout that can be used for testing as well as a 
> schematic.
> 
> *LG 5K 27" display running 3200x1800 (the highest resolution without making 
> text blurry, using this for work every day, so it's extravagant, it's 
> practical)*
> 
> *Actions:* pan with middle mouse, zoom back and forth.
> 
> *eeschema:*
> Low Res - at least 2 times slower than would be considered normal, I would 
> have to guess ~400ms lag
> Normal - 4-5x slower compared to low res mode ~1700ms lag
> Even in low res mode, and removing 75% of the items from Chris' schematic, 
> the lag is still ~200-300ms, that's just not right. Additionally, I filed 
> https://bugs.launchpad.net/kicad/+bug/1753054 
>  because the mouse zoom is 
> screwed up in eeschema, coupled with the lag, it's unusable. Maybe the pan 
> lag is related to the zoom, maybe there are multiple steps being rendered 
> when it should just jump to where the mouse ended up at, I don't know.
> 
> *pcbnew - **Normal Resolution:*
> Accelerated: No-AA, <50ms
> Fallback: 500-1000ms for panning, 300-600ms for zoom
> Legacy: 1300-1700ms for panning, 600ms for zoom
> Low Res mode: did not notice speed increase, except maybe Fallback was ~400ms 
> faster.
> 
> I'm not saying halt the horses, certain modes are obviously limited, ie 
> Legacy and Fallback by the nature of the task presented, but eeschema is 
> barely displaying 10% of the content pcbnew is but lagging so much worse!
> 
> Just thought I'd include rendering of the Accelerated Graphics (top to 
> bottom: Supersampling 4x, Subpixel AA (Ultra Quality), No AA)
> All 3 modes are responsive, probably <50-100ms lag, I'd consider this 
> performance great, considering the amount of elements on screen.
> 
> 
> How long should it take to delete this many selected elements in pcbnew?
> Answer: about 50x too long! I think it was like 3mins, perhaps ESC key should 
> be available to press anytime to undo the delete action and restore to 
> pre-delete screen when accidental actions are triggered that take forever to 
> complete?
> 
> 
> On Fri, Mar 2, 2018 at 9:53 AM, Bernhard Stegmaier    >> wrote:
> 
> Hi,
> 
> to be honest, I don’t really know what this is about.
> 
> @Andrey:
> You looked for a very complex (foreign) project (Chris mainboard?)
> to prove that eeschema is slow on Mac?
> Well, we know that and we told you already some weeks/months ago
> why it is like it is (if memory serves me right).
> 
> Or, do you have an own project that is so ridiculously slow, that
> you can’t work with it?
> If so, please provide it so that we can analyse why this specific
> project behaves like that.
> If you can’t or don’t want to provide it we could tell you how to
> do some performance measurements so that we might see something.
> 
> Obviously, there are a number of Mac users here and also over at
> the KiCad forum who might also be happy to get some more
> performance here and there, but who are in general reasonably able
> to work on their projects (including myself, on a 2012 Retina
> MacBook with only an i5).
> 
> 
> Regards,
> Bernhard
> 
> > On 2. Mar 2018, at 17:59, Andy Peters  
> >> wrote:
> >
> >

Re: [Kicad-developers] Mac HighDPI performance

[Andrey Kuznetsov]

Would it be an easy fix to change the text/font such that it does not
affect performance so significantly on MacOS?

On Sat, Mar 3, 2018 at 5:20 AM, Wayne Stambaugh 
wrote:

> On 03/03/2018 07:33 AM, Jeff Young wrote:
>
>> Hi Andrey,
>>
>> I did some profiling and I’d guess that the difference in eeschema and
>> pcbnew-legacy performance is down to there being more text in the schema.
>> Since we use a stroke font, there’s a lot of stroke segments in each letter.
>>
>> @Devs,
>>
>> I understand why we use a stroke font on the PCB, but there’s not much
>> reason in eeschema, is there?
>>
>
> This is possibly one of the things that I plan on changing after the new
> schematic file format is written.  The new file format will support font
> definitions so replacing the stroke font in Eeschema should be doable.
> Whether or not I have time to make this change remains to be seen.
>
> Wayne
>
>
>> Cheers,
>> Jeff.
>>
>>
>> On 3 Mar 2018, at 08:18, Andrey Kuznetsov >> kandre...@gmail.com>> wrote:
>>>
>>> The motherboard project is not very complex, I would say that
>>> performance should be tolerable UP to that size complexity, if we set the
>>> bar any lower, usability will suffer and people won't like KiCad because
>>> it's sluggish and interface lag is the worst kind of lag.
>>> My project isn't finished and Chris' project is available now, is just
>>> the right complexity and has layout that can be used for testing as well as
>>> a schematic.
>>>
>>> *LG 5K 27" display running 3200x1800 (the highest resolution without
>>> making text blurry, using this for work every day, so it's extravagant,
>>> it's practical)*
>>>
>>> *Actions:* pan with middle mouse, zoom back and forth.
>>>
>>> *eeschema:*
>>> Low Res - at least 2 times slower than would be considered normal, I
>>> would have to guess ~400ms lag
>>> Normal - 4-5x slower compared to low res mode ~1700ms lag
>>> Even in low res mode, and removing 75% of the items from Chris'
>>> schematic, the lag is still ~200-300ms, that's just not right.
>>> Additionally, I filed https://bugs.launchpad.net/kicad/+bug/1753054
>>> because the mouse zoom is screwed up in eeschema, coupled with the lag,
>>> it's unusable. Maybe the pan lag is related to the zoom, maybe there are
>>> multiple steps being rendered when it should just jump to where the mouse
>>> ended up at, I don't know.
>>>
>>> *pcbnew - **Normal Resolution:*
>>> Accelerated: No-AA, <50ms
>>> Fallback: 500-1000ms for panning, 300-600ms for zoom
>>> Legacy: 1300-1700ms for panning, 600ms for zoom
>>> Low Res mode: did not notice speed increase, except maybe Fallback was
>>> ~400ms faster.
>>>
>>> I'm not saying halt the horses, certain modes are obviously limited, ie
>>> Legacy and Fallback by the nature of the task presented, but eeschema is
>>> barely displaying 10% of the content pcbnew is but lagging so much worse!
>>>
>>> Just thought I'd include rendering of the Accelerated Graphics (top to
>>> bottom: Supersampling 4x, Subpixel AA (Ultra Quality), No AA)
>>> All 3 modes are responsive, probably <50-100ms lag, I'd consider this
>>> performance great, considering the amount of elements on screen.
>>> 
>>>
>>> How long should it take to delete this many selected elements in pcbnew?
>>> Answer: about 50x too long! I think it was like 3mins, perhaps ESC key
>>> should be available to press anytime to undo the delete action and restore
>>> to pre-delete screen when accidental actions are triggered that take
>>> forever to complete?
>>> 
>>>
>>> On Fri, Mar 2, 2018 at 9:53 AM, Bernhard Stegmaier <
>>> stegma...@sw-systems.de > wrote:
>>>
>>> Hi,
>>>
>>> to be honest, I don’t really know what this is about.
>>>
>>> @Andrey:
>>> You looked for a very complex (foreign) project (Chris mainboard?)
>>> to prove that eeschema is slow on Mac?
>>> Well, we know that and we told you already some weeks/months ago
>>> why it is like it is (if memory serves me right).
>>>
>>> Or, do you have an own project that is so ridiculously slow, that
>>> you can’t work with it?
>>> If so, please provide it so that we can analyse why this specific
>>> project behaves like that.
>>> If you can’t or don’t want to provide it we could tell you how to
>>> do some performance measurements so that we might see something.
>>>
>>> Obviously, there are a number of Mac users here and also over at
>>> the KiCad forum who might also be happy to get some more
>>> performance here and there, but who are in general reasonably able
>>> to work on their projects (including myself, on a 2012 Retina
>>> MacBook with only an i5).
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> > On 2. Mar 2018, at 17:59, Andy Peters >> > wrote:
>>> >
>>> >
>>> >
>>> >> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand
>>> mailto:seth.hillbr...@gmail.com>> wrote:
>>> >>
>>> >> Andrey-
>>> >>
>>> >> I'm movi

Re: [Kicad-developers] MacOS Packaging Question

[Rene Pöschl]

On 03/03/18 23:32, Seth Hillbrand wrote:
​In the current nightly MacOS builds, we package the applications, 
symbols and 3d models but no footprints.


Is this an oversight?

-S​




This might be because in kicad 4 the footprints where downloaded on 
demand via the github plugin.
With the new library setup (single repository for all footprints) this 
is no longer possible.


I assume some packages for other operating systems might have a similar 
problem


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

Re: [Kicad-developers] [PATCH] Rework footprint selection filtering to improve behavior

[Jon Evans]

Hey Andy, Andrzej,

Updated patch attached, let me know if this behavior makes more sense

Best,
Jon

On Fri, Mar 2, 2018 at 3:29 PM, Andy Peters  wrote:

>
>
> On Mar 2, 2018, at 10:28 AM, Andrzej Wolski 
> wrote:
>
> Jon,
>
> I probably didn't express myself clearly. What I mean is a situation when
> *only* enabled layer if F.Paste and then you disable "Pads Front". Now
> nothing is visible on the board, but footprints are still selectable.
>
> In other words, when no single item belonging to footprint is visible,
> footprints should not be selectable.
>
> Do you still disagree with me?
>
>
> I agree with Andrzej. This is the crux of my bug report.
>
> But I understand what Jon is saying, and it doesn’t contradict. If the
> _pads_ (for example) are invisible, but say the silkscreen is visible, then
> the footprint _should_ be selectable.
>
> That, I think, is the difference between layer visibility and item
> visibility. All of the layers could be visible, but if I disable Footprints
> Front, then everything associated with all top-layer footprints vanishes
> and none of the footprints can be selected. That’s the proper operation.
>
> The converse of that is if I leave Footprints Front visibility enabled,
> and then I go and disable all of the layers associated with front
> footprints, like I did in my bug report case (disable all layers except
> Cmts.User), I am still able to select all of the invisible footprints.
> That’s not correct (IMHO).
>
> -a
>
>
>
> Andrzej
>
> W dniu 2018-03-02 o 15:42, Jon Evans pisze:
>
> Hi Andrzej,
>
> This was my intention, which is why I said I was prepared for other people
> to have other opinions :-)
>
> I think that you should still be able to select footprints even if the
> "front pads" is hidden from layers like the paste layer, *unless* you are
> in high contrast mode.
>
> -Jon
>
> On Fri, Mar 2, 2018 at 3:53 AM, Andrzej Wolski 
> wrote:
>
>> I've tried this patch, and there is a small issue: if you have only eg
>> front paste layer enabled and front pads are hidden, footprint is still
>> selectable.
>>
>> Andrzej
>>
>>
>> W dniu 2018-02-27 o 04:11, Jon Evans pisze:
>>
>> This patch changes the selection logic for footprints to fix a reported
>> issue[1] and to make the behavior more logical to me.
>>
>> I know that correct selection behavior is something of a personal
>> preference, so I'm ready to be flamed :-)
>>
>> The new behavior:
>>
>> A footprint may be selected if:
>> 1) The corresponding "Footprints" switch is on in the Items tab, AND
>> 2) One or more of the layers that the footprint draws on is visible
>>
>> This means that if all of the layers are turned off, footprints are not
>> selectable (fixes the bug), but it also means that now footprints can be
>> selected if any draw layers are visible (for example, if you have only
>> F.Mask enabled, you can select a footprint that has solder mask and is on
>> the front layer).
>>
>> Before anyone complains, this is only if high-contrast mode is turned
>> OFF.  When it is on, you can still only select items that *only* exist on
>> that layer (to make moving silkscreen around easier, for example)
>>
>> Even though this adds some more for-loops to selection filtering, I have
>> not noticed any performance hits on some selection of large boards that I
>> tested.  More testing is welcome.
>>
>> [1] https://bugs.launchpad.net/kicad/+bug/1751960
>>
>> -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
>
>


0001-Rework-footprint-selection-filtering-to-improve-beha.patch
Description: Binary data
___
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] MacOS Packaging Question

[Seth Hillbrand]

​In the current nightly MacOS builds, we package the applications, symbols
and 3d models but no footprints.

Is this an oversight?

-S​
___
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] Git noob question

[Maciej Suminski]

[...] git pull would do a fetch and merge together, 
but you want to fetch and rebase -- you can set your .gitconfig to do 
the fetch and rebase, but I think it's easier to follow along with 
what's going on if you do the fetch separately and check the tree each 
time with git hist.


If we are speaking about git tips - I think 'git pull --rebase' is even 
simpler in this case.


Cheers,
Orson

___
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] Should footprint library wizard recognise gEDA files?

[Jeff Young]

Unfortunately we have to go with GEDA/Pcb (as it’s stored in the fp-lib-table 
files).

I did change it so that it uses a lookup rather than hard-coding the strings in 
different places.  (There’s still the separate name the plugin reports, but 
that’s only used to populate an exception with some error info.)

Cheers,
Jeff.


> On 3 Mar 2018, at 20:31, Wayne Stambaugh  wrote:
> 
> FYI, the plugin (Geda PCB) is correct.  If you fix this, fix it
> everywhere else it is broken not the plugin name.
> 
> Wayne
> 
> On 03/03/2018 02:31 PM, Jeff Young wrote:
>> This looks to have been broken for some time.
>> 
>> (Wizard thinks the plugin name is Geda-PCB; plugin /says/ its name is
>> Geda PCB, and then goes and registers itself under GEDA/Pcb.)
>> 
>> 
>>> On 3 Mar 2018, at 11:20, Jeff Young >> > wrote:
>>> 
>>> It recognises them as footprint files, just not as gEDA footprint files.
>>> 
>>> In other words, it lets me add a directory full of them to the
>>> footprint lib table, but the lib table entry gets the Kicad plugin.
>>> 
>>> If I add an Eagle file, the lib table entry gets the Eagle plugin.
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> 
>> ___
>> 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] V5 Version Info?

[Bernhard Stegmaier]

Yes, -dirty is clear.
I guess I didn’t explicitly pull tags since I first cloned the repo… didn’t 
know that they are not pulled per default.
Again learned something, thanks!

> On 3. Mar 2018, at 21:30, Wayne Stambaugh  wrote:
> 
> -dirty means you have code that is not in master.  You are either
> working in a different branch or you have made modifications to master.
> Given that your version string says 4.0.0-rc2, it also looks like you
> need to do a `git pull --tags` to fetch the latest tags.
> 
> Wayne
> 
> 
> On 03/03/2018 02:39 PM, Bernhard Stegmaier wrote:
>> Hi all,
>> 
>> just out of curiosity… all my builds from master claim to be a v4:
>> <<<
>> Application: kicad
>> Version: (4.0.0-rc2-4230-gaeae32b1a-dirty), release build
> 
>> 
>> According to git I have a clean source tree… I yesterday made a build on a 
>> Linux box with a completely fresh tree and it showed v5.
>> What’s wrong with my repo/branch?
>> 
>> 
>> 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
>> 
> 
> ___
> 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] Should footprint library wizard recognise gEDA files?

[Wayne Stambaugh]

FYI, the plugin (Geda PCB) is correct.  If you fix this, fix it
everywhere else it is broken not the plugin name.

Wayne

On 03/03/2018 02:31 PM, Jeff Young wrote:
> This looks to have been broken for some time.
> 
> (Wizard thinks the plugin name is Geda-PCB; plugin /says/ its name is
> Geda PCB, and then goes and registers itself under GEDA/Pcb.)
> 
> 
>> On 3 Mar 2018, at 11:20, Jeff Young > > wrote:
>>
>> It recognises them as footprint files, just not as gEDA footprint files.
>>
>> In other words, it lets me add a directory full of them to the
>> footprint lib table, but the lib table entry gets the Kicad plugin.
>>
>> If I add an Eagle file, the lib table entry gets the Eagle plugin.
>>
>> Cheers,
>> Jeff.
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> ___
> 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] V5 Version Info?

[Wayne Stambaugh]

-dirty means you have code that is not in master.  You are either
working in a different branch or you have made modifications to master.
Given that your version string says 4.0.0-rc2, it also looks like you
need to do a `git pull --tags` to fetch the latest tags.

Wayne


On 03/03/2018 02:39 PM, Bernhard Stegmaier wrote:
> Hi all,
> 
> just out of curiosity… all my builds from master claim to be a v4:
> <<<
> Application: kicad
> Version: (4.0.0-rc2-4230-gaeae32b1a-dirty), release build

> 
> According to git I have a clean source tree… I yesterday made a build on a 
> Linux box with a completely fresh tree and it showed v5.
> What’s wrong with my repo/branch?
> 
> 
> 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
> 

___
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] Zone filling (was: MacOS + OpenMP)

[Jeff Young]

> you implemented multiple workers yourself now?

Yes.  We’re pulling zones from a list anyway, so it was easy enough to use the 
list as a work queue.  I just added a std::atomic index into the list; each 
worker grabs the next index when it’s looking for more to do.

Cheers,
Jeff.


> On 3 Mar 2018, at 18:34, Bernhard Stegmaier  wrote:
> 
> Hi,
> 
> you implemented multiple workers yourself now?
> I’ll have to check in detail.
> 
> I thought of just using OpenMP for the for loop again like this.
> <<<
> diff --git a/pcbnew/zone_filler.cpp b/pcbnew/zone_filler.cpp
> index 6fe40555a..408c5e7aa 100644
> --- a/pcbnew/zone_filler.cpp
> +++ b/pcbnew/zone_filler.cpp
> @@ -118,6 +118,9 @@ void ZONE_FILLER::Fill( std::vector 
> aZones )
>  m_count_done = 0;
>  std::thread fillWorker( [ this, toFill ]()
>  {
> +#ifdef USE_OPENMP
> +#pragma omp for schedule(dynamic)
> +#endif
>  for( unsigned i = 0; i < toFill.size(); i++ )
>  {
>  SHAPE_POLY_SET rawPolys, finalPolys;
> >>>
> 
> Currently compiling, but my (test) clang with OpenMP is pretty picky about 
> other OpenMP stuff… :(
> 
> 
> Regards,
> Bernhard
> 
>> On 3. Mar 2018, at 18:50, Jeff Young > > wrote:
>> 
>> Hi Tomasz & Bernhard,
>> 
>> If you have a chance could you guys please take a look at 
>> https://git.launchpad.net/kicad/commit/?id=c77d13292b63a3ef7c28f004ee93f3ed93cca9f3
>>  
>> 
>>  ?
>> 
>> It reinstates multi-threading (with thread pooling) to the zone filler.
>> 
>> Bernard is still looking for ways to make this a bit more elegant; this 
>> version just uses brute force for now.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 1 Mar 2018, at 14: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

[Kicad-developers] V5 Version Info?

[Bernhard Stegmaier]

Hi all,

just out of curiosity… all my builds from master claim to be a v4:
<<<
Application: kicad
Version: (4.0.0-rc2-4230-gaeae32b1a-dirty), release build
>>>

According to git I have a clean source tree… I yesterday made a build on a 
Linux box with a completely fresh tree and it showed v5.
What’s wrong with my repo/branch?


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

[Bernhard Stegmaier]

Hi all,

So, I played around a bit to get OpenMP and GCD into something like a 
“parallel_for” wrapper which either uses OpenMP or GCD.
Unfortunately, OpenMP seems to require that the “for” statement directly 
follows the “#pragma omg for …”.
That currently killed all my attempts to define such a “parallel_for” (as 
function, #define, ?) so that the code will stay the same for both.
One option would be to pull the “#pragma omp for …” into the wrapper, but I 
guess this is not really acceptable (since you can’t specify any specific 
schedule parameters any longer).

I will think about it some more just because of the challenge… but I am not 
very optimistic at the moment to get something nice.
If anyone else has a nice idea, I’d be very interested to learn freaky new 
stuff… :)

On the other side, I looked at using a non-Xcode OpenMP capable clang.
The only caveat seems to be not to mix standard C++ libraries (in the past 
libc++/libstdc++ haven’t been compatible in some aspects - didn’t try to find 
out if that is resolved).
Default on macOS now is libc++, but it seems that at least MacPorts builds 
clang with libstdc++ per default (no idea why).
The MacPorts build can easily be switched to libc++.
That clang-mp builds KiCad without problems even if dependencies have been 
built with Xcode clang.
Everything seems to work as expected, multithreading is there where it should 
be.

So, for now it seems to be the most easy solution to switch to a suitable 
non-Xcode clang for building packages - if we want to have OpenMP for macOS.

AFAIK our build machines use Homebrew.
Seems as if Homebrew decides which standard library to use depending on macOS 
version (https://docs.brew.sh/C++-Standard-Libraries 
).
So, if everything is recent enough it might not be a problem at all… like it 
obviously also has been for Seth below.


Regards,
Bernhard

> On 1. Mar 2018, at 17:47, Seth Hillbrand  wrote:
> 
> 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-develo

Re: [Kicad-developers] Should footprint library wizard recognise gEDA files?

[Jeff Young]

This looks to have been broken for some time.

(Wizard thinks the plugin name is Geda-PCB; plugin says its name is Geda PCB, 
and then goes and registers itself under GEDA/Pcb.)


> On 3 Mar 2018, at 11:20, Jeff Young  wrote:
> 
> It recognises them as footprint files, just not as gEDA footprint files.
> 
> In other words, it lets me add a directory full of them to the footprint lib 
> table, but the lib table entry gets the Kicad plugin.
> 
> If I add an Eagle file, the lib table entry gets the Eagle plugin.
> 
> Cheers,
> Jeff.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] [PATCH] Fix clang-mp-6.0 compile error

[Bernhard Stegmaier]

Hi,Small patch to fix a compile error with (MacPorts) clang-6.0-mp.See  https://www.mail-archive.com/llvm-bugs@lists.llvm.org/msg20164.htmlRegards,Bernhard

0001-Fix-clang-mp-build-error-don-t-declare-const-variabl.patch
Description: Binary data
___
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] Zone filling (was: MacOS + OpenMP)

[Bernhard Stegmaier]

Hi,

you implemented multiple workers yourself now?
I’ll have to check in detail.

I thought of just using OpenMP for the for loop again like this.
<<<
diff --git a/pcbnew/zone_filler.cpp b/pcbnew/zone_filler.cpp
index 6fe40555a..408c5e7aa 100644
--- a/pcbnew/zone_filler.cpp
+++ b/pcbnew/zone_filler.cpp
@@ -118,6 +118,9 @@ void ZONE_FILLER::Fill( std::vector aZones 
)
 m_count_done = 0;
 std::thread fillWorker( [ this, toFill ]()
 {
+#ifdef USE_OPENMP
+#pragma omp for schedule(dynamic)
+#endif
 for( unsigned i = 0; i < toFill.size(); i++ )
 {
 SHAPE_POLY_SET rawPolys, finalPolys;
>>>

Currently compiling, but my (test) clang with OpenMP is pretty picky about 
other OpenMP stuff… :(


Regards,
Bernhard

> On 3. Mar 2018, at 18:50, Jeff Young  wrote:
> 
> Hi Tomasz & Bernhard,
> 
> If you have a chance could you guys please take a look at 
> https://git.launchpad.net/kicad/commit/?id=c77d13292b63a3ef7c28f004ee93f3ed93cca9f3
>  
> 
>  ?
> 
> It reinstates multi-threading (with thread pooling) to the zone filler.
> 
> Bernard is still looking for ways to make this a bit more elegant; this 
> version just uses brute force for now.
> 
> Cheers,
> Jeff.
> 
> 
>> On 1 Mar 2018, at 14: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

[Kicad-developers] Zone filling (was: MacOS + OpenMP)

[Jeff Young]

Hi Tomasz & Bernhard,

If you have a chance could you guys please take a look at 
https://git.launchpad.net/kicad/commit/?id=c77d13292b63a3ef7c28f004ee93f3ed93cca9f3
 

 ?

It reinstates multi-threading (with thread pooling) to the zone filler.

Bernard is still looking for ways to make this a bit more elegant; this version 
just uses brute force for now.

Cheers,
Jeff.


> On 1 Mar 2018, at 14: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

Re: [Kicad-developers] Git noob question

[Kevin Cozens]

On 2018-03-02 03:28 PM, Jeff Young wrote:
Before I go and make a hash of everything, can someone please validate the 
following.


I have a bunch of 6.0 work on my master.

I have a 5.0stable branch that I use for 5.0.

If I want to push changes for RC2, I’d do:

git push origin 5.0stable:master


I don't like git. I only use it because I have no choice when working with 
some Open Source projects. I try to keep my use of git simple. In the case 
you describe I would have multiple copies of Kicad in different directories.


For example, kicad-master, kicad-5.0, and kicad-6 (or named based on which 
version you are working on). In those directories I use git gui to create a 
branch that tracks an upstream branch. By doing that I only need to use the 
standard "git push" command to push changes and the changes go to the proper 
branch. I don't need to specify things like "origin" or a branch name.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#include  | --Chris Hardwick

___
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 build missing frameworks

[Bernhard Stegmaier]

Yes… I have configured QTCreator to build debug/release into separate folders 
and I do my “production” builds via console.
QTCreator seems to have its own ideas how default folder structure should look 
like and I didn’t yet figure out in detail on how to configure it so that it 
doesn’t clash.


Bernhard


> On 3. Mar 2018, at 14:48, Jeff Young  wrote:
> 
> Thanks, Bernhard.  I re-did mine to that scheme, but it didn’t help.  I think 
> it’s just QTCreator not quite following what’s going on.
> 
> 
> 
>> On 3 Mar 2018, at 12:45, Bernhard Stegmaier > > wrote:
>> 
>> Sure.
>> 
>> My work folder looks like that:
>>   kicad => git repo
>>   build => build folder
>>   wx-3.0 => wx binaries
>> 
>> In build folder, I use that cmake
>> <<<
>> cmake ../kicad -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ 
>> -DwxWidgets_CONFIG_EXECUTABLE=../wx-3.0/bin/wx-config -DKICAD_SCRIPTING=OFF 
>> -DKICAD_SCRIPTING_MODULES=OFF -DKICAD_SCRIPTING_WXPYTHON=OFF 
>> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_USE_OCE=ON 
>> -DOCE_DIR=/opt/local/Library/Frameworks/OCE.framework/Versions/0.17/Resources
>>  -DKICAD_SPICE=OFF -DCMAKE_INSTALL_PREFIX=../bin -DCMAKE_BUILD_TYPE=Release 
>> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.12
>> >>>
>> 
>> 
>> Bernhard
>> 
>>> On 3. Mar 2018, at 13:41, Jeff Young >> > wrote:
>>> 
>>> Interesting.  Could you share your cmake command?
>>> 
 On 3 Mar 2018, at 12:19, Bernhard Stegmaier >>> > wrote:
 
 You are sure that you have a clean build folder and don’t mix things from 
 console builds, QTCreator, etc.?
 In my build folder (built yesterday) I don’t have a “bin” or “debug” 
 folder…
 
 HackMini:build bstegmaier$ ls -l
 total 200
 drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:43 3d-viewer
 -rw-r--r--   1 bstegmaier  staff  41439 Mar  2 13:06 CMakeCache.txt
 drwxr-xr-x  18 bstegmaier  staff612 Mar  2 13:43 CMakeFiles
 -rw-r--r--   1 bstegmaier  staff  35407 Mar  2 13:06 Makefile
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmap2component
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmaps_png
 -rw-r--r--   1 bstegmaier  staff   4235 Mar  2 13:06 cmake_install.cmake
 -rw-r--r--   1 bstegmaier  staff907 Mar  2 13:06 cmake_uninstall.cmake
 drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:42 common
 -rw-r--r--   1 bstegmaier  staff   1834 Mar  2 13:06 config.h
 drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 cvpcb
 drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 demos
 drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 eeschema
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 gerbview
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 kicad
 -rw-r--r--   1 bstegmaier  staff277 Mar  2 13:06 kicad_build_version.h
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 lib_dxf
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pagelayout_editor
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pcb_calculator
 drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 pcbnew
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 plugins
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 polygon
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 potrace
 drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 qa
 drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 template
 drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 tools
 drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 utils
 
 
 
 Bernhard
 
> On 3. Mar 2018, at 12:38, Jeff Young  > wrote:
> 
> When I do a build I get 3 copies of all the stand-alone apps:
> 
> build/
>bin/
>   eeschema.app
>debug/
>   eeschema/
>  eeschema.app
>   kicad/
>  kicad.app/
> Contents/
>eeschema.app
> 
> The build/bin/ version is a link to the 
> build/debug/kicad/kicad.app/Contents/ version.  This one has a 
> Contents/Frameworks/ inside it (with all the dylibs in it).  So far so 
> good.
> 
> However, the debug/eeschema/eeschema.app is not a link, and does not have 
> a Contents/Frameworks/ directory inside, and so generates a bunch of 
> errors.
> 
> Ring any bells?
> ___
> 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 build missing frameworks

[Jeff Young]

Thanks, Bernhard.  I re-did mine to that scheme, but it didn’t help.  I think 
it’s just QTCreator not quite following what’s going on.



> On 3 Mar 2018, at 12:45, Bernhard Stegmaier  wrote:
> 
> Sure.
> 
> My work folder looks like that:
>   kicad => git repo
>   build => build folder
>   wx-3.0 => wx binaries
> 
> In build folder, I use that cmake
> <<<
> cmake ../kicad -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ 
> -DwxWidgets_CONFIG_EXECUTABLE=../wx-3.0/bin/wx-config -DKICAD_SCRIPTING=OFF 
> -DKICAD_SCRIPTING_MODULES=OFF -DKICAD_SCRIPTING_WXPYTHON=OFF 
> -DBUILD_GITHUB_PLUGIN=ON -DKICAD_USE_OCE=ON 
> -DOCE_DIR=/opt/local/Library/Frameworks/OCE.framework/Versions/0.17/Resources 
> -DKICAD_SPICE=OFF -DCMAKE_INSTALL_PREFIX=../bin -DCMAKE_BUILD_TYPE=Release 
> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.12
> >>>
> 
> 
> Bernhard
> 
>> On 3. Mar 2018, at 13:41, Jeff Young > > wrote:
>> 
>> Interesting.  Could you share your cmake command?
>> 
>>> On 3 Mar 2018, at 12:19, Bernhard Stegmaier >> > wrote:
>>> 
>>> You are sure that you have a clean build folder and don’t mix things from 
>>> console builds, QTCreator, etc.?
>>> In my build folder (built yesterday) I don’t have a “bin” or “debug” folder…
>>> 
>>> HackMini:build bstegmaier$ ls -l
>>> total 200
>>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:43 3d-viewer
>>> -rw-r--r--   1 bstegmaier  staff  41439 Mar  2 13:06 CMakeCache.txt
>>> drwxr-xr-x  18 bstegmaier  staff612 Mar  2 13:43 CMakeFiles
>>> -rw-r--r--   1 bstegmaier  staff  35407 Mar  2 13:06 Makefile
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmap2component
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmaps_png
>>> -rw-r--r--   1 bstegmaier  staff   4235 Mar  2 13:06 cmake_install.cmake
>>> -rw-r--r--   1 bstegmaier  staff907 Mar  2 13:06 cmake_uninstall.cmake
>>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:42 common
>>> -rw-r--r--   1 bstegmaier  staff   1834 Mar  2 13:06 config.h
>>> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 cvpcb
>>> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 demos
>>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 eeschema
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 gerbview
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 kicad
>>> -rw-r--r--   1 bstegmaier  staff277 Mar  2 13:06 kicad_build_version.h
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 lib_dxf
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pagelayout_editor
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pcb_calculator
>>> drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 pcbnew
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 plugins
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 polygon
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 potrace
>>> drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 qa
>>> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 template
>>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 tools
>>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 utils
>>> 
>>> 
>>> 
>>> Bernhard
>>> 
 On 3. Mar 2018, at 12:38, Jeff Young >>> > wrote:
 
 When I do a build I get 3 copies of all the stand-alone apps:
 
 build/
bin/
   eeschema.app
debug/
   eeschema/
  eeschema.app
   kicad/
  kicad.app/
 Contents/
eeschema.app
 
 The build/bin/ version is a link to the 
 build/debug/kicad/kicad.app/Contents/ version.  This one has a 
 Contents/Frameworks/ inside it (with all the dylibs in it).  So far so 
 good.
 
 However, the debug/eeschema/eeschema.app is not a link, and does not have 
 a Contents/Frameworks/ directory inside, and so generates a bunch of 
 errors.
 
 Ring any bells?
 ___
 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] Mac HighDPI performance

[Wayne Stambaugh]

On 03/03/2018 07:33 AM, Jeff Young wrote:

Hi Andrey,

I did some profiling and I’d guess that the difference in eeschema and 
pcbnew-legacy performance is down to there being more text in the 
schema.  Since we use a stroke font, there’s a lot of stroke segments in 
each letter.


@Devs,

I understand why we use a stroke font on the PCB, but there’s not much 
reason in eeschema, is there?


This is possibly one of the things that I plan on changing after the new 
schematic file format is written.  The new file format will support font 
definitions so replacing the stroke font in Eeschema should be doable. 
Whether or not I have time to make this change remains to be seen.


Wayne



Cheers,
Jeff.


On 3 Mar 2018, at 08:18, Andrey Kuznetsov > wrote:


The motherboard project is not very complex, I would say that 
performance should be tolerable UP to that size complexity, if we set 
the bar any lower, usability will suffer and people won't like KiCad 
because it's sluggish and interface lag is the worst kind of lag.
My project isn't finished and Chris' project is available now, is just 
the right complexity and has layout that can be used for testing as 
well as a schematic.


*LG 5K 27" display running 3200x1800 (the highest resolution without 
making text blurry, using this for work every day, so it's 
extravagant, it's practical)*


*Actions:* pan with middle mouse, zoom back and forth.

*eeschema:*
Low Res - at least 2 times slower than would be considered normal, I 
would have to guess ~400ms lag

Normal - 4-5x slower compared to low res mode ~1700ms lag
Even in low res mode, and removing 75% of the items from Chris' 
schematic, the lag is still ~200-300ms, that's just not right. 
Additionally, I filed https://bugs.launchpad.net/kicad/+bug/1753054 
because the mouse zoom is screwed up in eeschema, coupled with the 
lag, it's unusable. Maybe the pan lag is related to the zoom, maybe 
there are multiple steps being rendered when it should just jump to 
where the mouse ended up at, I don't know.


*pcbnew - **Normal Resolution:*
Accelerated: No-AA, <50ms
Fallback: 500-1000ms for panning, 300-600ms for zoom
Legacy: 1300-1700ms for panning, 600ms for zoom
Low Res mode: did not notice speed increase, except maybe Fallback was 
~400ms faster.


I'm not saying halt the horses, certain modes are obviously limited, 
ie Legacy and Fallback by the nature of the task presented, but 
eeschema is barely displaying 10% of the content pcbnew is but lagging 
so much worse!


Just thought I'd include rendering of the Accelerated Graphics (top to 
bottom: Supersampling 4x, Subpixel AA (Ultra Quality), No AA)
All 3 modes are responsive, probably <50-100ms lag, I'd consider this 
performance great, considering the amount of elements on screen.



How long should it take to delete this many selected elements in pcbnew?
Answer: about 50x too long! I think it was like 3mins, perhaps ESC key 
should be available to press anytime to undo the delete action and 
restore to pre-delete screen when accidental actions are triggered 
that take forever to complete?



On Fri, Mar 2, 2018 at 9:53 AM, Bernhard Stegmaier 
mailto:stegma...@sw-systems.de>> wrote:


Hi,

to be honest, I don’t really know what this is about.

@Andrey:
You looked for a very complex (foreign) project (Chris mainboard?)
to prove that eeschema is slow on Mac?
Well, we know that and we told you already some weeks/months ago
why it is like it is (if memory serves me right).

Or, do you have an own project that is so ridiculously slow, that
you can’t work with it?
If so, please provide it so that we can analyse why this specific
project behaves like that.
If you can’t or don’t want to provide it we could tell you how to
do some performance measurements so that we might see something.

Obviously, there are a number of Mac users here and also over at
the KiCad forum who might also be happy to get some more
performance here and there, but who are in general reasonably able
to work on their projects (including myself, on a 2012 Retina
MacBook with only an i5).


Regards,
Bernhard

> On 2. Mar 2018, at 17:59, Andy Peters mailto:de...@latke.net>> wrote:
>
>
>
>> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand
mailto:seth.hillbr...@gmail.com>> 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.
>
> testing on my 2017” touch-bar MBP …
>
> Good g-d, low-res mode looks fuzzy and weird!
>
> I don’t notice any specific d

Re: [Kicad-developers] MacOS build missing frameworks

[Bernhard Stegmaier]

Sure.

My work folder looks like that:
  kicad => git repo
  build => build folder
  wx-3.0 => wx binaries

In build folder, I use that cmake
<<<
cmake ../kicad -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ 
-DwxWidgets_CONFIG_EXECUTABLE=../wx-3.0/bin/wx-config -DKICAD_SCRIPTING=OFF 
-DKICAD_SCRIPTING_MODULES=OFF -DKICAD_SCRIPTING_WXPYTHON=OFF 
-DBUILD_GITHUB_PLUGIN=ON -DKICAD_USE_OCE=ON 
-DOCE_DIR=/opt/local/Library/Frameworks/OCE.framework/Versions/0.17/Resources 
-DKICAD_SPICE=OFF -DCMAKE_INSTALL_PREFIX=../bin -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.12
>>>


Bernhard

> On 3. Mar 2018, at 13:41, Jeff Young  wrote:
> 
> Interesting.  Could you share your cmake command?
> 
>> On 3 Mar 2018, at 12:19, Bernhard Stegmaier > > wrote:
>> 
>> You are sure that you have a clean build folder and don’t mix things from 
>> console builds, QTCreator, etc.?
>> In my build folder (built yesterday) I don’t have a “bin” or “debug” folder…
>> 
>> HackMini:build bstegmaier$ ls -l
>> total 200
>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:43 3d-viewer
>> -rw-r--r--   1 bstegmaier  staff  41439 Mar  2 13:06 CMakeCache.txt
>> drwxr-xr-x  18 bstegmaier  staff612 Mar  2 13:43 CMakeFiles
>> -rw-r--r--   1 bstegmaier  staff  35407 Mar  2 13:06 Makefile
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmap2component
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmaps_png
>> -rw-r--r--   1 bstegmaier  staff   4235 Mar  2 13:06 cmake_install.cmake
>> -rw-r--r--   1 bstegmaier  staff907 Mar  2 13:06 cmake_uninstall.cmake
>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:42 common
>> -rw-r--r--   1 bstegmaier  staff   1834 Mar  2 13:06 config.h
>> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 cvpcb
>> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 demos
>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 eeschema
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 gerbview
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 kicad
>> -rw-r--r--   1 bstegmaier  staff277 Mar  2 13:06 kicad_build_version.h
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 lib_dxf
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pagelayout_editor
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pcb_calculator
>> drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 pcbnew
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 plugins
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 polygon
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 potrace
>> drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 qa
>> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 template
>> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 tools
>> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 utils
>> 
>> 
>> 
>> Bernhard
>> 
>>> On 3. Mar 2018, at 12:38, Jeff Young >> > wrote:
>>> 
>>> When I do a build I get 3 copies of all the stand-alone apps:
>>> 
>>> build/
>>>bin/
>>>   eeschema.app
>>>debug/
>>>   eeschema/
>>>  eeschema.app
>>>   kicad/
>>>  kicad.app/
>>> Contents/
>>>eeschema.app
>>> 
>>> The build/bin/ version is a link to the 
>>> build/debug/kicad/kicad.app/Contents/ version.  This one has a 
>>> Contents/Frameworks/ inside it (with all the dylibs in it).  So far so good.
>>> 
>>> However, the debug/eeschema/eeschema.app is not a link, and does not have a 
>>> Contents/Frameworks/ directory inside, and so generates a bunch of errors.
>>> 
>>> Ring any bells?
>>> ___
>>> 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 build missing frameworks

[Jeff Young]

Interesting.  Could you share your cmake command?

> On 3 Mar 2018, at 12:19, Bernhard Stegmaier  wrote:
> 
> You are sure that you have a clean build folder and don’t mix things from 
> console builds, QTCreator, etc.?
> In my build folder (built yesterday) I don’t have a “bin” or “debug” folder…
> 
> HackMini:build bstegmaier$ ls -l
> total 200
> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:43 3d-viewer
> -rw-r--r--   1 bstegmaier  staff  41439 Mar  2 13:06 CMakeCache.txt
> drwxr-xr-x  18 bstegmaier  staff612 Mar  2 13:43 CMakeFiles
> -rw-r--r--   1 bstegmaier  staff  35407 Mar  2 13:06 Makefile
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmap2component
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmaps_png
> -rw-r--r--   1 bstegmaier  staff   4235 Mar  2 13:06 cmake_install.cmake
> -rw-r--r--   1 bstegmaier  staff907 Mar  2 13:06 cmake_uninstall.cmake
> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:42 common
> -rw-r--r--   1 bstegmaier  staff   1834 Mar  2 13:06 config.h
> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 cvpcb
> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 demos
> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 eeschema
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 gerbview
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 kicad
> -rw-r--r--   1 bstegmaier  staff277 Mar  2 13:06 kicad_build_version.h
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 lib_dxf
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pagelayout_editor
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pcb_calculator
> drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 pcbnew
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 plugins
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 polygon
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 potrace
> drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 qa
> drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 template
> drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 tools
> drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 utils
> 
> 
> 
> Bernhard
> 
>> On 3. Mar 2018, at 12:38, Jeff Young > > wrote:
>> 
>> When I do a build I get 3 copies of all the stand-alone apps:
>> 
>> build/
>>bin/
>>   eeschema.app
>>debug/
>>   eeschema/
>>  eeschema.app
>>   kicad/
>>  kicad.app/
>> Contents/
>>eeschema.app
>> 
>> The build/bin/ version is a link to the 
>> build/debug/kicad/kicad.app/Contents/ version.  This one has a 
>> Contents/Frameworks/ inside it (with all the dylibs in it).  So far so good.
>> 
>> However, the debug/eeschema/eeschema.app is not a link, and does not have a 
>> Contents/Frameworks/ directory inside, and so generates a bunch of errors.
>> 
>> Ring any bells?
>> ___
>> 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] Mac HighDPI performance

[Jeff Young]

Hi Andrey,

I did some profiling and I’d guess that the difference in eeschema and 
pcbnew-legacy performance is down to there being more text in the schema.  
Since we use a stroke font, there’s a lot of stroke segments in each letter.

@Devs,

I understand why we use a stroke font on the PCB, but there’s not much reason 
in eeschema, is there?

Cheers,
Jeff.


> On 3 Mar 2018, at 08:18, Andrey Kuznetsov  wrote:
> 
> The motherboard project is not very complex, I would say that performance 
> should be tolerable UP to that size complexity, if we set the bar any lower, 
> usability will suffer and people won't like KiCad because it's sluggish and 
> interface lag is the worst kind of lag.
> My project isn't finished and Chris' project is available now, is just the 
> right complexity and has layout that can be used for testing as well as a 
> schematic.
> 
> LG 5K 27" display running 3200x1800 (the highest resolution without making 
> text blurry, using this for work every day, so it's extravagant, it's 
> practical)
> 
> Actions: pan with middle mouse, zoom back and forth.
> 
> eeschema:
> Low Res - at least 2 times slower than would be considered normal, I would 
> have to guess ~400ms lag
> Normal - 4-5x slower compared to low res mode ~1700ms lag
> Even in low res mode, and removing 75% of the items from Chris' schematic, 
> the lag is still ~200-300ms, that's just not right. Additionally, I filed 
> https://bugs.launchpad.net/kicad/+bug/1753054 
>  because the mouse zoom is 
> screwed up in eeschema, coupled with the lag, it's unusable. Maybe the pan 
> lag is related to the zoom, maybe there are multiple steps being rendered 
> when it should just jump to where the mouse ended up at, I don't know.
> 
> pcbnew - Normal Resolution:
> Accelerated: No-AA, <50ms
> Fallback: 500-1000ms for panning, 300-600ms for zoom
> Legacy: 1300-1700ms for panning, 600ms for zoom
> Low Res mode: did not notice speed increase, except maybe Fallback was ~400ms 
> faster.
> 
> I'm not saying halt the horses, certain modes are obviously limited, ie 
> Legacy and Fallback by the nature of the task presented, but eeschema is 
> barely displaying 10% of the content pcbnew is but lagging so much worse!
> 
> Just thought I'd include rendering of the Accelerated Graphics (top to 
> bottom: Supersampling 4x, Subpixel AA (Ultra Quality), No AA)
> All 3 modes are responsive, probably <50-100ms lag, I'd consider this 
> performance great, considering the amount of elements on screen. 
> 
> 
> How long should it take to delete this many selected elements in pcbnew?
> Answer: about 50x too long! I think it was like 3mins, perhaps ESC key should 
> be available to press anytime to undo the delete action and restore to 
> pre-delete screen when accidental actions are triggered that take forever to 
> complete?
> 
> 
> On Fri, Mar 2, 2018 at 9:53 AM, Bernhard Stegmaier  > wrote:
> Hi,
> 
> to be honest, I don’t really know what this is about.
> 
> @Andrey:
> You looked for a very complex (foreign) project (Chris mainboard?) to prove 
> that eeschema is slow on Mac?
> Well, we know that and we told you already some weeks/months ago why it is 
> like it is (if memory serves me right).
> 
> Or, do you have an own project that is so ridiculously slow, that you can’t 
> work with it?
> If so, please provide it so that we can analyse why this specific project 
> behaves like that.
> If you can’t or don’t want to provide it we could tell you how to do some 
> performance measurements so that we might see something.
> 
> Obviously, there are a number of Mac users here and also over at the KiCad 
> forum who might also be happy to get some more performance here and there, 
> but who are in general reasonably able to work on their projects (including 
> myself, on a 2012 Retina MacBook with only an i5).
> 
> 
> Regards,
> Bernhard
> 
> > On 2. Mar 2018, at 17:59, Andy Peters  > > wrote:
> >
> >
> >
> >> On Mar 1, 2018, at 8: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.
> >
> > testing on my 2017” touch-bar MBP …
> >
> > Good g-d, low-res mode looks fuzzy and weird!
> >
> > I don’t notice any specific differences in EESchema performance. Maybe my 
> > schematic isn’t busy enough? I’m a fan of using more smaller sheets with 
> > less info on each than one big sheet with everything.
> >
> > I know, anecdote is not evidence.
> >
> > -a
> >
> >
> >>
> >> -Seth
> >>
> >> ​​2018-03-

Re: [Kicad-developers] MacOS build missing frameworks

[Bernhard Stegmaier]

You are sure that you have a clean build folder and don’t mix things from 
console builds, QTCreator, etc.?
In my build folder (built yesterday) I don’t have a “bin” or “debug” folder…

HackMini:build bstegmaier$ ls -l
total 200
drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:43 3d-viewer
-rw-r--r--   1 bstegmaier  staff  41439 Mar  2 13:06 CMakeCache.txt
drwxr-xr-x  18 bstegmaier  staff612 Mar  2 13:43 CMakeFiles
-rw-r--r--   1 bstegmaier  staff  35407 Mar  2 13:06 Makefile
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmap2component
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 bitmaps_png
-rw-r--r--   1 bstegmaier  staff   4235 Mar  2 13:06 cmake_install.cmake
-rw-r--r--   1 bstegmaier  staff907 Mar  2 13:06 cmake_uninstall.cmake
drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:42 common
-rw-r--r--   1 bstegmaier  staff   1834 Mar  2 13:06 config.h
drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 cvpcb
drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 demos
drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 eeschema
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 gerbview
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 kicad
-rw-r--r--   1 bstegmaier  staff277 Mar  2 13:06 kicad_build_version.h
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 lib_dxf
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pagelayout_editor
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 pcb_calculator
drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 pcbnew
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 plugins
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 polygon
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 potrace
drwxr-xr-x   9 bstegmaier  staff306 Mar  2 13:06 qa
drwxr-xr-x   5 bstegmaier  staff170 Mar  2 13:06 template
drwxr-xr-x   6 bstegmaier  staff204 Mar  2 13:06 tools
drwxr-xr-x   8 bstegmaier  staff272 Mar  2 13:06 utils



Bernhard

> On 3. Mar 2018, at 12:38, Jeff Young  wrote:
> 
> When I do a build I get 3 copies of all the stand-alone apps:
> 
> build/
>bin/
>   eeschema.app
>debug/
>   eeschema/
>  eeschema.app
>   kicad/
>  kicad.app/
> Contents/
>eeschema.app
> 
> The build/bin/ version is a link to the build/debug/kicad/kicad.app/Contents/ 
> version.  This one has a Contents/Frameworks/ inside it (with all the dylibs 
> in it).  So far so good.
> 
> However, the debug/eeschema/eeschema.app is not a link, and does not have a 
> Contents/Frameworks/ directory inside, and so generates a bunch of errors.
> 
> Ring any bells?
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] MacOS build missing frameworks

[Jeff Young]

When I do a build I get 3 copies of all the stand-alone apps:

build/
   bin/
  eeschema.app
   debug/
  eeschema/
 eeschema.app
  kicad/
 kicad.app/
Contents/
   eeschema.app

The build/bin/ version is a link to the build/debug/kicad/kicad.app/Contents/ 
version.  This one has a Contents/Frameworks/ inside it (with all the dylibs in 
it).  So far so good.

However, the debug/eeschema/eeschema.app is not a link, and does not have a 
Contents/Frameworks/ directory inside, and so generates a bunch of errors.

Ring any bells?___
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] Git noob question

[Jeff Young]

Cool stuff; thanks for those.  I’m finding the —graph option particularly 
useful.

Cheers,
Jeff.



> On 3 Mar 2018, at 01:40, Tiger12506  wrote:
> 
> I'm not a kicad dev, just an avid reader of the list, but I am pretty fluent 
> in git.
> Here are some aliases that you might find useful (that go in your 
> ~/.gitconfig)
> 
> [alias]
> co = checkout
> ci = commit
> st = status
> br = branch
> hist = log --all --abbrev-commit --graph --date=short 
> --pretty=format:\"%h %C(yellow)%aN %C(green)| %C(cyan)%d%Creset%s\"
> histd = log --all --abbrev-commit --graph --date=short 
> --pretty=format:\"%h %C(green)%ad %C(yellow)%aN%Creset | %C(cyan)%d%Creset%s\"
> ll = log --all --stat --abbrev-commit --graph 
> --pretty=format:\"%C(green)%h %aN | %C(yellow)%d%C(green)%s\"
> type = cat-file -t
> dump = cat-file -p
> d = whatchanged -1 -p
> del = !git rm $(git ls-files --deleted)
> dc = diff --cached
> wd = diff --word-diff
> cw = diff --color-words
> b = blame -w
> 
> 
> I tend to use `git hist` and `git st` all the time. So that I can always see 
> what's going on, I never use git pull, I always use git fetch instead. That 
> seems to be in-line with what Wayne expects, since he says to rebase your 
> changes. git pull would do a fetch and merge together, but you want to fetch 
> and rebase -- you can set your .gitconfig to do the fetch and rebase, but I 
> think it's easier to follow along with what's going on if you do the fetch 
> separately and check the tree each time with git hist.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

[Kicad-developers] Should footprint library wizard recognise gEDA files?

[Jeff Young]

It recognises them as footprint files, just not as gEDA footprint files.

In other words, it lets me add a directory full of them to the footprint lib 
table, but the lib table entry gets the Kicad plugin.

If I add an Eagle file, the lib table entry gets the Eagle plugin.

Cheers,
Jeff.


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