On Sun, Jun 01, 2014 at 10:42:33PM +0100, John Beard wrote:
I have never registered erasure of silk over pads as a problem, no
fabricator has ever complained or delivered over-printed pads. Has
anyone seen this happen?
Neither have I. Simply because our fabricator erase everything in 0.2mm
of
On 29/05/14 16:15, Nick Østergaard wrote:
Hello
I am not sure who maintains the Jenkins build bot at
http://ci.kicad-pcb.org/, but I have noticed that is has stopped. I am
not sure who runs that, so I write to the list.
Also the kicad-source-mirror on github has stopped updating. Is it the
On 02/06/14 12:36, Povilas Kanapickas wrote:
On 29/05/14 16:15, Nick Østergaard wrote:
Hello
I am not sure who maintains the Jenkins build bot at
http://ci.kicad-pcb.org/, but I have noticed that is has stopped. I am
not sure who runs that, so I write to the list.
Also the kicad-source-mirror
Le 02/06/2014 12:15, Povilas Kanapickas a écrit :
On 02/06/14 12:36, Povilas Kanapickas wrote:
On 29/05/14 16:15, Nick Østergaard wrote:
Hello
I am not sure who maintains the Jenkins build bot at
http://ci.kicad-pcb.org/, but I have noticed that is has stopped. I am
not sure who runs that,
On 2 June 2014 22:35, jp charras jp.char...@wanadoo.fr wrote:
Le 02/06/2014 12:15, Povilas Kanapickas a écrit :
On 02/06/14 12:36, Povilas Kanapickas wrote:
On 29/05/14 16:15, Nick Østergaard wrote:
Hello
I am not sure who maintains the Jenkins build bot at
http://ci.kicad-pcb.org/,
On Mon, Jun 02, 2014 at 10:32:18AM -0400, Jean-Paul Louis wrote:
Guys,
I am reading all this thread, and I am amazed that people suggest a silk
shape that will HAVE TO BE REMOVED by the PCB fabricator.
The industry took a long time to discover this, too :D
And it isn't a full standard yet,
On Mon, Jun 02, 2014 at 11:04:21PM +1200, Blair Bonnett wrote:
For anybody wanting to use GitHub, I also have a mirror at
https://github.com/blairbonnett-mirrors/kicad which is updated every 10
minutes. Henner Zeller used it to fork from for his contributions a couple
of months back so I
Hi,
building with clang (at least on OSX) and -Wall is really noisy so that you can
hardly see what’s going wrong.
So, I decided to fix the warnings… attached are 3 patches I prepared (against
rev. 4911):
*** clang-warnings-1.diff:
Everything that probably should be fixed:
* Disable
On Mon, Jun 02, 2014 at 07:52:52PM +0200, Bernhard Stegmaier wrote:
Removes unneeded checks (e.g., a check “x 0” for an unsigned x” is pretty
obsolete).
x = 0, I hope :D
As for unused variable probably it's only a Mac thing (or clang has
a better flow analyzer than g++), I don't see any with
On 02.06.2014 19:52, Bernhard Stegmaier wrote:
Hi,
building with clang (at least on OSX) and -Wall is really noisy so that
you can hardly see what’s going wrong.
So, I decided to fix the warnings… attached are 3 patches I prepared
(against rev. 4911):
*** clang-warnings-1.diff:
Everything that
This is a guess (i'm not OP), but it's pretty common to shun assignment
within an if condition.
The second line probably just masks the warning from the compiler -- the
check that triggers the warning probably isn't exhaustive enough to
check within the parentheses for assignment.
On
Hi,
it warns because it is not clear whether (a) you really mean the assignment
(and want to check if the result is zero) or (b) you just forgot one “=“ and
you meant “ip == s1…”. The additional brackets are proposed in the compiler
warning to silence the warning in case of (a).
Beside a lot
12 matches
Mail list logo
