Re: [Kicad-developers] Differential pair skew matching fails with certain dimensions

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

Re: [Kicad-developers] [PATCH] Update macOS portion of compiling.md

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

[Kicad-developers] [PATCH] Tiny UI patch - " to in

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

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

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

Re: [Kicad-developers] Differential pair skew matching fails with certain dimensions

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

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

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

Re: [Kicad-developers] [PATCH] eeschema - label editor

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

[Kicad-developers] Differential pair skew matching fails with certain dimensions

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

Re: [Kicad-developers] Footprint filter match behavior

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

Re: [Kicad-developers] Differential pair DRC Errors

> 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

Re: [Kicad-developers] Footprint filter match behavior

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,

Re: [Kicad-developers] Footprint filter match behavior

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)

Re: [Kicad-developers] Footprint filter match behavior

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,

Re: [Kicad-developers] Footprint filter match behavior

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

Re: [Kicad-developers] Footprint filter match behavior

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

Re: [Kicad-developers] Footprint filter match behavior

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

[Kicad-developers] Footprint filter match behavior

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

[Kicad-developers] [PATCH] Update macOS portion of compiling.md

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:

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

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

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

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

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

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

Re: [Kicad-developers] [PATCH] Refactor LAYER_ID to be the one and only layer definition

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,

Re: [Kicad-developers] file licenses

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 >

Re: [Kicad-developers] Differential pair DRC Errors

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

Re: [Kicad-developers] FreeBSD

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

Re: [Kicad-developers] FreeBSD

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