Hello *,
Am 02.02.2018 um 08:06 schrieb Wayne Stambaugh:
> You can use git. There are some good tips for using git on launchpad
> here https://help.launchpad.net/Code/Git.
in my eyes git has won the race. It's the most popular vcs in recent
times. Some side notes to Launchpad, GitHub, Bibuckt,
You can use git. There are some good tips for using git on launchpad
here https://help.launchpad.net/Code/Git.
Yep! Git is the 800lb gorilla of vcs but it is powerful. Once you wrap
your head around it, you will find that it is a great vcs. It just has
a steep learning curve.
On 02/01/20
The only option I can find is to upload one with “bzr” (whatever that is). Is
that the only way to do it?
Thanks,
Jeff.
PS: I was a ClearCase and SVN guy. Don’t get too git-complicated with me….
___
Mailing list: https://launchpad.net/~kicad-develope
Hi Seth
The second patch seems more broken.
I get something like this when configuring:
...
-- Found OCC: /opt/oce/lib/oce-0.18/../../include/oce (found version
"6.9.1")
-- Found OpenCASCADE Community Edition version: 6.9.1
-- ++ OpenCASCADE Community Edition include directory: /opt/oce/include/
It looks like the "sort layers" feature is causing removal and re-adding of
all items on the canvas, which is extremely slow.
I'm going to see if that is actually necessary, since my initial thought is
that it should be possible to avoid that work.
Unfortunately RTREE::Remove is super slow if there
Le 01/02/2018 à 18:16, Jon Evans a écrit :
> Thanks for the data, Seth.
>
> I'm curious, has anyone tried my other patch (changing from bitset to vector)
> to see if it has any
> performance impact on your machines?
I just tested it in Gerbview, and I do not really seen any performance change.
I’m using OCCT 7.2.0. I’ve also tried from the master branch. Both built with
MSVC.
I’m able to export using OCE just fine. With OCE, I do get missing model
messages when using
kicad2step from command line. I hadn’t tried it from the command line before
with OCE, so the
output from the prior
Hi Thomas-
Thanks for testing! Couple questions:
- Which version of OCCT are you testing?
- Are you able to correctly export the board when using OCE?
- Do you not see the missing model messages when using OCE?
-Seth
2018-01-31 19:04 GMT-08:00 Thomas Figueroa :
> Hello Seth,
>
>
>
> I’ve had t
Thanks for the data, Seth.
I'm curious, has anyone tried my other patch (changing from bitset to
vector) to see if it has any performance impact on your machines?
-Jon
On Thu, Feb 1, 2018 at 11:58 AM, Seth Hillbrand
wrote:
> Hi Jon-
>
> I see a similar situation to JP (although my machine is n
Hi Jon-
I see a similar situation to JP (although my machine is not so fast).
Loading all layers is fast. Changing the dcode display takes about 40s on
my machine and no difference in the patch. Interestingly, it is faster for
me to close all layers, change the dcode display and re-open the file
I will look into the layer sorting, I haven't profiled that extensively
yet. I do see improvement in showing DCodes with this patch on my machine
at least, it takes about 40% less time (it's still too long for good user
experience though)
On Feb 1, 2018 10:48, "jp charras" wrote:
Le 01/02/2018 à
Le 01/02/2018 à 15:34, Jon Evans a écrit :
> Thanks for feedback Orson and JP, I will definitely keep investigating.
> FYI I only see a big speed change in GerbView when loading all of the test
> files (not just a single
> layer) from the bug report.
> I also see no difference in pcbnew (which ten
On 2/1/2018 9:03 AM, Jeff Young wrote:
>> If a pad is on front and back layers, currently it is on all copper
>> layers,
>> so "all copper layers" is better for me.
>> (Otherwise it is on one copper layer.)
>
> Ahhh… I didn’t realise the choices were that restricted. That certainly
> simplifies t
Thanks for feedback Orson and JP, I will definitely keep investigating.
FYI I only see a big speed change in GerbView when loading all of the test
files (not just a single layer) from the bug report.
I also see no difference in pcbnew (which tends to have much fewer vertices)
-Jon
On Thu, Feb 1,
Oh, that particular one is definitely for 6.0. (I had submitted a small hack
patch for 5.0, but JP and I concluded it was better to hold off till I could do
it right.)
Cheers,
Jeff.
> On 1 Feb 2018, at 13:10, Wayne Stambaugh wrote:
>
>> This one already has a bug report, so that’s not an iss
2018-02-01 14:10 GMT+01:00 Wayne Stambaugh :
> On 2/1/2018 7:48 AM, Jeff Young wrote:
> > One other question: what about large but simple changes?
> >
> > For instance, I’m currently working on getting rid of the g_UserUnits
> global. It’s going to be several thousand lines of changes, but each o
On 2/1/2018 7:48 AM, Jeff Young wrote:
> One other question: what about large but simple changes?
>
> For instance, I’m currently working on getting rid of the g_UserUnits global.
> It’s going to be several thousand lines of changes, but each one is pretty
> brain-dead.
In this case, a patch w
Le 01/02/2018 à 13:47, Wayne Stambaugh a écrit :
> On 2/1/2018 4:31 AM, jp charras wrote:
>> Le 31/01/2018 à 16:47, Jeff Young a écrit :
>>> When we display the layers of a pad, we display the top-most and
>>> bottom-most layers, and then
>>> include “Internal” if there are also any internal layer
On 2/1/2018 4:31 AM, jp charras wrote:
> Le 31/01/2018 à 16:47, Jeff Young a écrit :
>> When we display the layers of a pad, we display the top-most and bottom-most
>> layers, and then
>> include “Internal” if there are also any internal layers, and “Non-copper”
>> if there are also any
>> non-co
One other question: what about large but simple changes?
For instance, I’m currently working on getting rid of the g_UserUnits global.
It’s going to be several thousand lines of changes, but each one is pretty
brain-dead.
This one already has a bug report, so that’s not an issue. But would yo
Sounds good.
> On 1 Feb 2018, at 09:31, jp charras wrote:
>
> Le 31/01/2018 à 16:47, Jeff Young a écrit :
>> When we display the layers of a pad, we display the top-most and bottom-most
>> layers, and then
>> include “Internal” if there are also any internal layers, and “Non-copper”
>> if ther
Le 01/02/2018 à 10:43, Maciej Sumiński a écrit :
> Hi Jon,
>
> TL;DR: I have no idea why it boosts the performance. I would love to see
> some extra input from others, to see if patch helps on other systems or
> at least does not decrease performance on low-spec cards.
>
>
> It is hard to explai
Hi Jon,
TL;DR: I have no idea why it boosts the performance. I would love to see
some extra input from others, to see if patch helps on other systems or
at least does not decrease performance on low-spec cards.
It is hard to explain why do you see a performance boost. I tried it on
my machine (i
Le 31/01/2018 à 16:47, Jeff Young a écrit :
> When we display the layers of a pad, we display the top-most and bottom-most
> layers, and then
> include “Internal” if there are also any internal layers, and “Non-copper” if
> there are also any
> non-copper layers.
>
> Sounds good so far. Unfortu
24 matches
Mail list logo