Hi,
nearly the same.
I added the #elif __amd64__ section for completeness.
Greetings
---
Mike
Am 13. März 2017 23:03:33 MEZ schrieb Chris Pavlina :
>Isn't this the same as what I linked to?
>
>On Mon, Mar 13, 2017 at 10:11:54PM +0100, Michael wrote:
>> Hi,
>> currently I'm using the following pat
On 13.03.2017 22:11, Michael wrote:
> Hi,
> currently I'm using the following patch for the FreeBSD Port.
> (I'm not entirely shure if clang sets __x86_64__ too or only __amd64__)
>
Hi Michael,
I've pushed your patch. Thank for your contribution to Kicad!
Cheers,
Tom
___
On 03/11/2017 12:58 PM, Tomasz Wlostowski wrote:
On 13.02.2017 01:59, Andy Peters wrote:
I route the signals and run the DRC, and for every corner in the trace
pairs, I get an ErrType(x): “Two Track Ends Too Close” complaint.
Sometimes it’s ErrType(16), sometimes it’s ErrType(17), the rest
ErrTy
This pretty much is my take on it. GPL2+ implies all later versions of
the GPL so I think we are covered.
On 3/14/2017 12:55 AM, José Ignacio wrote:
> GPL2+ Already includes GPL3+, i see no reason to change it up aside from
> preventing code reuse by other projects. The whole of KiCad as it is
>
Hi Orson, Wayne,
I looked at the "enum inheritance" thing some more and I don't think it
would be a good solution for our case.
This technique lets you extend enum A with enum B, and have functions f(A)
and f(A or B), and you could continue making larger enums that contained
smaller ones.
But, if
On 3/14/2017 10:08 AM, Jon Evans wrote:
> Hi Orson, Wayne,
>
> I looked at the "enum inheritance" thing some more and I don't think it
> would be a good solution for our case.
>
> This technique lets you extend enum A with enum B, and have functions
> f(A) and f(A or B), and you could continue ma
Hi Jon,
Protocol Buffers has the same problem. Messages have a unique number
for each field, but extensions to messages don't know about
"siblings". A common thing [1] to so is reserve IDs up to 1000 for the
base message, and then messages start at offsets 1000, 2000, etc,
based on some in-house s
Hi John, that's basically what my first patch did, but inside one enum.
Hi Wayne, thanks for elaborating more, I see your point.
I am still not sure there is benefit to adding some class to handle enum
inheritance.
I think it would work fine to just chain multiple enums together, as was
done befo
Hi folks!
Just a minor docs tweak to compiling.md. I updated OSX to macOS, in
most places, and I changed the wording around "supported versions 10.7
to 10.10" to "10.9 to 10.12".
Let me know if there are any issues.
Adam Wolf
0001-Update-macOS-portion-of-compiling.md.patch
Description: Binary
Hi,
Currently, the footprint filter strings in a component match a footprint
if they occur *anywhere* in the footprint's name. This leads to some
possibly unintentional matches - for example, "R" has a filter "R_*",
which matches literally every footprint with R_ somewhere in its name.
This is qui
HI Chris,
That sounds reasonable. A match pattern like "R_*" looks like a
globbing pattern, and I'd expect globbing patterns to act like that in
general. It's how most bash works, for a start, as well as things like
find(1).
I imagine that most footprints with a pattern like "R_*" intended it
to
Hi,
On 14.03.2017 16:57, Chris Pavlina wrote:
> What if I changed this to require matching at the beginning of the
> string? A filter meant to match anywhere in the string could be written
> "*R_*" instead. This should significantly reduce the number of false
> positive matches.
The regex matche
On Tue, Mar 14, 2017 at 05:24:07PM +0100, Simon Richter wrote:
> Hi,
>
> On 14.03.2017 16:57, Chris Pavlina wrote:
>
> > What if I changed this to require matching at the beginning of the
> > string? A filter meant to match anywhere in the string could be written
> > "*R_*" instead. This should s
Agreed, they do look like standard globbing patterns and should probably
behave that way. In fact globs have to line up at _both_ ends... but I
think a lot of people set the filters assuming left-aligned matching, so
I don't think I want to go that far.
On Wed, Mar 15, 2017 at 12:16:20AM +0800, Jo
Yes, please!
*R* -> R somewhere in the name.
R* -> R in the beginning of the name.
*R -> R at the end of the name.
R*1005M*1* are 1005M (0402) sized resistors with different values starting with
1
1, 10, 100, 1.2, 12, 120, 15. ... [k|M]Ohms as i.e.:
R-1005M-1R0 (1Ohm)
R-1005M-103 (10kOhm)
R-
Hi,
On 14.03.2017 17:30, Chris Pavlina wrote:
>> The regex matcher should give you good results for "^R".
> I think people would be opposed to using regexes in the footprint
> filters. I like having them in some places as an option, but they're
> complicated for people who aren't programmers, an
> On Mar 11, 2017, at 12:58 PM, Tomasz Wlostowski
> wrote:
>
> On 13.02.2017 01:59, Andy Peters wrote:
>> I route the signals and run the DRC, and for every corner in the trace
>> pairs, I get an ErrType(x): “Two Track Ends Too Close” complaint.
>> Sometimes it’s ErrType(16), sometimes it’s Err
On Tue, Mar 14, 2017 at 05:49:28PM +0100, Simon Richter wrote:
> Hi,
>
> On 14.03.2017 17:30, Chris Pavlina wrote:
>
> >> The regex matcher should give you good results for "^R".
>
> > I think people would be opposed to using regexes in the footprint
> > filters. I like having them in some place
This one is probably for Orson or Tom...
Tested with latest code from git (on Debian Jessie), but I also had the
issue with my old version (a few weeks old, forgot to write down the
exact hash).
Steps to reproduce:
* Create schematic that has a differential pair in it
* Set differential pair des
I can repro this as well. Latest master, also Linux.
On Tue, Mar 14, 2017 at 11:20:52AM -0700, Andrew Zonenberg wrote:
> This one is probably for Orson or Tom...
>
>
> Tested with latest code from git (on Debian Jessie), but I also had the
> issue with my old version (a few weeks old, forgot to
Your patch has been committed to the master branch. Thank you for your
contribution to KiCad.
On 3/7/2017 5:14 PM, Oliver Walters wrote:
> Attached is a small patch that addresses two usability issues in the
> label editor in eeschema:
>
> 1. Set wxTextCtrl flag wxTE_RICH so that pressing Ctrl+B
Cirilo,
I finally got around to pushing all of your patches. Thank you for
fixing this.
Cheers,
Wayne
On 3/8/2017 9:56 PM, Cirilo Bernardo wrote:
> I think I've got something that works now. The _D patch attached fixes
> the UTF8 issues in kicad2step provided the patch to the wxWidgets
> head
Hey Jon,
This is better than the giant enum concept and I'm willing to accept
this. It still lacks the type safety of the enum inheritance solution.
I still see ints being cast to enums and enum bounds checking so this is
less than ideal. I would prefer to see some additional testing so if
any o
On 14.03.2017 19:20, Andrew Zonenberg wrote:
> This one is probably for Orson or Tom...
>
>
> Tested with latest code from git (on Debian Jessie), but I also had the
> issue with my old version (a few weeks old, forgot to write down the
> exact hash).
>
> Steps to reproduce:
> * Create schematic
Hi Wayne,
Please keep in mind that anywhere there is currently int casting and bounds
checking that deals with colors, will be replaced with type-safe methods in
an upcoming patch from me. For those places not dealing with colors, I
will see if it can be improved in a future patch.
Thanks,
Jon
Hi,
Here's a micro-patch to close out a little UI wrinkle - the Design
Rules Pcbnew dialog used ", not in, for the imperial unit labels.
Closes: https://bugs.launchpad.net/kicad/+bug/1667644
Cheers,
John
From 8c3de299c27062b6b2020843f6791e5d14d6c3cb Mon Sep 17 00:00:00 2001
From: John Beard
Da
I committed your patch. Thanks Adam.
On 3/14/2017 10:59 AM, Adam Wolf wrote:
> Hi folks!
>
> Just a minor docs tweak to compiling.md. I updated OSX to macOS, in
> most places, and I changed the wording around "supported versions 10.7
> to 10.10" to "10.9 to 10.12".
>
> Let me know if there are
Hi,
Try to skew-match the pair in the attached file.
On 14/03/17 16:06, Tomasz Wlostowski wrote:
> On 14.03.2017 19:20, Andrew Zonenberg wrote:
>> This one is probably for Orson or Tom...
>>
>>
>> Tested with latest code from git (on Debian Jessie), but I also had the
>> issue with my old version
28 matches
Mail list logo
