Le 05/03/2016 19:48, Simon Wells a écrit :
> thanks jp
>
> damn, i meant to do that as i saw the warning fire on simons build
> bot, tbh i thought it was just a compile-time warning rather than a
> run-time crash so thanks and i will have an updated v5 patch soon
This is a compile-time warning
thanks jp
damn, i meant to do that as i saw the warning fire on simons build
bot, tbh i thought it was just a compile-time warning rather than a
run-time crash so thanks and i will have an updated v5 patch soon
On Sun, Mar 6, 2016 at 7:44 AM, jp charras wrote:
> Le
Le 05/03/2016 18:48, jp charras a écrit :
> Le 05/03/2016 17:57, Nick Østergaard a écrit :
>> I tested the patch on windows x86_64 the other day and did not see any
>> issue. But I am not sure that was the latest version of the patch.
>> Den 05/03/2016 17.41 skrev "jp charras"
Le 05/03/2016 17:27, Simon Wells a écrit :
> Hey jp
>
> Have you tested it on any other platforms and thats the only one its
> crashed on or is that your only test? I will check to see why the
> patch didn't apply as thats rather odd as it was bzr diff'd off 6606.
>
> I wonder if it is an issue
Hey jp
Have you tested it on any other platforms and thats the only one its
crashed on or is that your only test? I will check to see why the
patch didn't apply as thats rather odd as it was bzr diff'd off 6606.
I wonder if it is an issue with wx3.1 as i am still deving on 3.0.2
but thanks for
Le 03/03/2016 17:56, Simon Wells a écrit :
> Attached is an updated patch changing KiCAD to KiCad and also removing
> the debug flag from build-time info of wx as its no longer valid
>
Simon,
I have some trouble with your patch (kicad_about-v4).
It does not apply correctly. (Fortunately, issues
I missed that. The about dialog copyright date string is the one exception.
On 3/5/2016 9:27 AM, Simon Wells wrote:
> Hey Wayne,
>
> FYI I believe this file should normally be an exception to the rule as
> it wasn't only the comment at the head of the file being updated but the
> copyright
Hey Wayne,
FYI I believe this file should normally be an exception to the rule as it
wasn't only the comment at the head of the file being updated but the
copyright information that shows up in the about dialog
Simon
On Sun, Mar 6, 2016 at 2:31 AM, Eldar Khayrullin
I was already reply that this is my mistake. Sorry again
![](https://link.nylas.com/open/ac7n0u7eu8cj6vjow9ajimqdr/b663a194d96f4ff89b48
cecf3a0416d6)
> On Mar 5 2016, at 4:27 pm, Wayne Stambaugh stambau...@gmail.com
wrote:
>
> Eldar,
>
> It's only necessary to update the copyright date
Eldar,
It's only necessary to update the copyright date when we actually modify
the source file. Hopefully devs are doing that but occasionally it
doesn't get updated. I don't think that's important enough to create a
patch just to update the copyright date.
Wayne
On 3/5/2016 12:37 AM, Eldar
2016-03-05 11:21 GMT+01:00 Mário Luzeiro :
> Hi Nick,
>
> Would it be possible to share your project with me?
Yes, I will send that directly to you in a moment.
> The loading times you refer does not make sense to me :/ So I have to test
> the project and see if I can find
Le 05/03/2016 11:36, Mário Luzeiro a écrit :
> Thanks!
>
> T15: 16214,593 ms
>
> This is when it is simplifying the copper layers polygon tessellation (with
> Clipper)
> // This will make a union of all added contourns
> layerPoly->Simplify( SHAPE_POLY_SET::PM_FAST );
>
> I
2016-03-05 11:24 GMT+01:00 Mário Luzeiro :
> Do you have only that long timing issue in that specific board?
>
> It is not expect that the different render modes render the board same way..
> they are different renders implementation.
>
> Why do you like to remove /have holes in
Thanks!
T15: 16214,593 ms
This is when it is simplifying the copper layers polygon tessellation (with
Clipper)
// This will make a union of all added contourns
layerPoly->Simplify( SHAPE_POLY_SET::PM_FAST );
I believe there are big layers on that project?
I will investigate
Do you have only that long timing issue in that specific board?
It is not expect that the different render modes render the board same way..
they are different renders implementation.
Why do you like to remove /have holes in the paste?
Mario Luzeiro
Hi Nick,
Would it be possible to share your project with me?
The loading times you refer does not make sense to me :/ So I have to test the
project and see if I can find something wrong..
If any issues do share, you can "scramble" the board and send to me in a way
that you still experience the
Ohh, and maybe these numbers are of use for comparison:
InitSettings...
T01: 0,269 ms
T02: 0,022 ms
T03: 0,767 ms
T04: 0,099 ms
T05: 1,085 ms
T06: 11,195 ms
T07: 0,103 ms
T08: 2,142 ms
T09: 53,627 ms
T10: 950,696 ms
T11: 17,716 ms
T12: 31,455 ms
T13: 0,843 ms
T14: 7,214 ms
T15: 16214,593 ms
T16:
The stuff I was describing below was only with the opengl renderer. If
I get the raytracer to render and I sort of try to rotate the board,
it takes about 16 seconds to rerender, but still with the crappy
resolution image.
But here I notice that the holes in the solder paste is rendered :),
which
.2016-03-05 0:22 GMT+01:00 Mário Luzeiro :
> Hi NickOe,
>
> tanks for testing it!
>
> The issues you describe I didn't experienced it yet, would you like to try a
> latest version?
> I am testing on a linux machine and on a windows machine.
I was testing 5909 Fix an issue on
19 matches
Mail list logo