Re: [Kicad-developers] New lead developer announcement

[Jeff Young]

Awesome!  Welcome aboard Mikolaj.

> On 19 Nov 2021, at 14:28, Jon Evans  wrote:
> 
> Welcome Mikolaj!  Happy to have you in this role :)
> 
> -Jon
> 
> On Fri, Nov 19, 2021 at 9:15 AM Wayne Stambaugh  > wrote:
> I am happy to announce that Mikolaj Wielgus has accepted an invitation 
> to become a member of the KiCad lead development team.  Mikolaj has made 
> some significant contributions to the KiCad project and I look forward 
> to his contributions as lead developer.  Please join me in 
> congratulating Mikolaj in his new role.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [OT-ish] Rotate while moving?

[Jeff Young]

It works on my build (5.99).  What version are you running?

> On 15 Nov 2021, at 16:58, Brian  wrote:
> 
> Hi,
> 
> I would swear that at one time in the past, while moving / grabbing a symbol 
> or footprint (M or G), I could rotate it in the midst of the move/grab 
> operation by pressing R.  Somewhere along the way, that stopped working; now 
> I can only move, grab, OR rotate.
> 
> Is there some option that controls this?  Being able to rotate while moving 
> saves a lot of clicks when I'm trying to determine the best fit, turning a 
> part this way and that while moving it around...
> 
> I know this is more of a usage question than a development question, so 
> please excuse the noise if this is the complete wrong place to ask.
> 
> Thanks,
> -Brian
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Fwd: Crash invoking pcbnew Board settings

[Jeff Young]

I presume that’s supposed to look like:

-DKICAD_SANITIZE_ADDRESS=ON

It didn’t produce any output.


> On 6 Nov 2021, at 18:06, Ian McInerney  wrote:
> 
> So, for some reason GMail thinks this email is empty when I open it but shows 
> text in the inbox view, so I am going off of what I can see in the "show 
> original message" option.
> 
> For running with ASAN, you simply need to pass the CMake flag 
> KICAD_SANITIZE_ADDRESS and then I would suggest setting the environment 
> variable 
> "ASAN_OPTIONS=detect_leaks=0:halt_on_error=0:check_initialization_order=1:detect_stack_use_after_return=1:detect_invalid_pointer_pairs=2"
>  in whatever you run the KiCad process in (that helps configure ASAN).
> 
> -Ian
> 
> FYI, the content I can see:
> Devs,
> 
> Can someone run this on the flatpak and see if it reproduces for them?  (It=
>  does not for me on OSX.  Speaking of which, can someone refresh my memory =
> on the cmake instruction to turn on something like ASAN on OSX?)
> 
> Cheers,
> Jeff.
> 
> On Sat, Nov 6, 2021 at 5:56 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Fwd: Crash invoking pcbnew Board settings

[Jeff Young]

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Crash invoking pcbnew Board settings

[Jeff Young]

He he… yeah, this is one of the reasons our coding style discourages the use of 
“auto” — it tends to obfuscate the code.  However, a lot of C++ programmers are 
used to using it, so it tends to creep in from time to time.

The case given should read:

for( const std::pair>& netclass : 
netclasses )
{
m_netclassGrid->SetCellValue( row, GRID_NAME, netclass.first );

so netclass.first is the key to the netclass in the netclasses map (ie: the 
netclass name).

However, if you’re seeing the crash when opening the Board Settings dialog, 
then I don’t think this is the issue (that’s a completely separate dialog).  
Sadly the flatpak doesn’t contain symbols so it’s a little hard to match the 
backtrace up with the code.

Can you send us a copy of the project (with the -1 re-instated so that it 
crashes) so we can see if we can reproduce it?  (Even if it’s from a bad file, 
it’d still be nice to not crash on it.)

Cheers,
Jeff.


> On 6 Nov 2021, at 01:59, Ruth Ivimey-Cook  wrote:
> 
> Hi
> 
> I've been using the nightly build of kicad via flatpak (because of the 
> WxWidgets issues on Linux) for a while, and have encountered a fairly 
> consistent crash when invoking board settings from the File menu of pcbnew.
> 
> The build is from this evening, using up to date flatpak and libs, was done 
> on ubuntu 21.04. However I have also experienced a very similar crash with 
> the same project using a recent (~week old) MacOS build.
> 
> The crash results in this appearing in the terminal window:
> 
>> terminate called after throwing an instance of 'std::bad_alloc'
>>   what():  std::bad_alloc
> [aside: could Kicad catch such exceptions rather than having the window just 
> disappear?]
> 
> Invoking gdb produces a backtrace of 54 frames of which the top 27 are 
> somewhat interesting:
> 
>> (gdb) bt
>> #0  0x75a6d4bb in raise () at /usr/lib/x86_64-linux-gnu/libc.so.6
>> #1  0x75a56867 in abort () at /usr/lib/x86_64-linux-gnu/libc.so.6
>> #2  0x75e308f9 in __gnu_cxx::__verbose_terminate_handler() [clone 
>> .cold] () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> #3  0x75e3c62a in __cxxabiv1::__terminate(void (*)()) () at 
>> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> #4  0x75e3c695 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> #5  0x75e3c971 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> #6  0x75e3050e in operator new(unsigned long, std::nothrow_t const&) 
>> [clone .cold] () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>> #7  0x55858695 in std::__cxx11::basic_string> std::char_traits, std::allocator 
>> >::_M_assign(std::__cxx11::basic_string, 
>> std::allocator > const&) ()
>> #8  0x77be21e2 in wxGrid::SetCellValue(int, int, wxString const&) () 
>> at /app/lib/libwx_gtk3u_core-3.1.so.5
>> #9  0x7fffcaefe280 in  () at /app/bin/_pcbnew.kiface
>> #10 0x7fffcaf034f3 in  () at /app/bin/_pcbnew.kiface
>> #11 0x77b21728 in wxWindowBase::TransferDataToWindow() () at 
>> /app/lib/libwx_gtk3u_core-3.1.so.5
>> #12 0x77b21728 in wxWindowBase::TransferDataToWindow() () at 
>> /app/lib/libwx_gtk3u_core-3.1.so.5
>> #13 0x7fffcaf40227 in  () at /app/bin/_pcbnew.kiface
>> #14 0x77b21b32 in wxWindowBase::OnInitDialog(wxInitDialogEvent&) () 
>> at /app/lib/libwx_gtk3u_core-3.1.so.5
>> #15 0x7746229e in 
>> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
>> wxEvtHandler*, wxEvent&) ()
>> at /app/lib/libwx_baseu-3.1.so.5
>> #16 0x77462443 in wxEventHashTable::HandleEvent(wxEvent&, 
>> wxEvtHandler*) () at /app/lib/libwx_baseu-3.1.so.5
>> #17 0x77462b56 in wxEvtHandler::TryHereOnly(wxEvent&) () at 
>> /app/lib/libwx_baseu-3.1.so.5
>> #18 0x77462be0 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at 
>> /app/lib/libwx_baseu-3.1.so.5
>> #19 0x77462cf2 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
>> /app/lib/libwx_baseu-3.1.so.5
>> #20 0x77b1a2ce in wxWindowBase::InitDialog() () at 
>> /app/lib/libwx_gtk3u_core-3.1.so.5
>> #21 0x77972114 in wxDialog::Show(bool) () at 
>> /app/lib/libwx_gtk3u_core-3.1.so.5
>> #22 0x7fffcafc7e7a in  () at /app/bin/_pcbnew.kiface
>> #23 0x7fffcafc68a6 in  () at /app/bin/_pcbnew.kiface
>> #24 0x7fffca7a74ad in  () at /app/bin/_pcbnew.kiface
>> #25 0x7fffca823117 in  () at /app/bin/_pcbnew.kiface
>> #26 0x7fffcb0fd3a0 in  () at /app/bin/_pcbnew.kiface
>> #27 0x7fffcb19e211 in make_fcontext () at /app/bin/_pcbnew.kiface
>> #28 0x00780031 in  ()
> 
> Suggestions online are that the crash is to do with using a the address of a 
> local variable out of scope. Having looked at the code, and using 
> SetCellValue as the anchor point, I believe the problem lies in the code in:
> 
>> dialog_global_edit_tracks_and_vias.cpp: void 
>> DIALOG_GLOBAL_EDIT_TRACKS_AND_VIAS::buildNetclassesGrid()
> 
> and specifically in the netclass loop:
> 
>> for( const auto& netclass : 

Re: [Kicad-developers] Problem compiling 5.1, maybe from commit 2975e859500

[Jeff Young]

This normally happens when you’re building both 5.1 and 5.99 in a single tree.  
I have to delete them a lot as I do that.

But I haven’t a clue how it’s supposed to be.  When I have a working build 
(even if it’s clunky), I tend to be very hesitant to change anything. ;)

> On 14 Sep 2021, at 14:27, Steven A. Falco  wrote:
> 
> It looks like the problem is that the definition of T_kicad_wks appears in a 
> generated file: include/page_layout_reader_lexer.h
> 
> However, while I do "out of tree" builds, page_layout_reader_lexer.h is not 
> created in the build directory, but rather it is created in the source 
> directory.
> 
> So when I deleted my build directory to force a clean build, 
> page_layout_reader_lexer.h was not deleted / re-created, hence the new 
> definition was not found.
> 
> Is the intention to have page_layout_reader_lexer.h be created in the source 
> directory or in the build directory?
> 
>   Steve
> 
> On 9/13/21 17:17, Steven A. Falco wrote:
>> I'm getting the following error compiling the 5.1 branch:
>> /home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:
>>  In member function ‘void 
>> PAGE_LAYOUT_READER_PARSER::Parse(WORKSHEET_LAYOUT*)’:
>> /home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:22:
>>  error: ‘T_kicad_wks’ was not declared in this scope
>>   131 | if( token == T_kicad_wks || token == T_drawing_sheet )
>>   |  ^~~
>> /home/sfalco/src/kicad/kicad5/gitlab/code/kicad-5.1/common/page_layout/page_layout_reader.cpp:131:46:
>>  error: ‘T_drawing_sheet’ was not declared in this scope
>>   131 | if( token == T_kicad_wks || token == T_drawing_sheet )
>>   |  ^~~
>> This appears to be due to commit 2975e859500, which added this code:
>> +if( token == T_kicad_wks || token == T_drawing_sheet )
>> +{
>> +THROW_PARSE_ERROR( _( "KiCad was unable to open this file 
>> because it was created with "
>> +  "a more recent version than the one you 
>> are running.\n\n"
>> +  "To open it you will need to upgrade 
>> KiCad to 5.99 or later." ),
>> +   CurSource(), CurLine(), CurLineNumber(), 
>> CurOffset() );
>> +}
>> +
>> Steve
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Modifier Key Modification

[Jeff Young]

Umm… how do you do a long-click on a track-pad set up for tapping?

> On 5 Sep 2021, at 21:53, Seth Hillbrand  wrote:
> 
> Hi Folks-
> 
> A final update to the 5.99 modifier key situation has been pushed.  This 
> resolves a number of conflicting modifier keys for different actions.
> 
> Part of this changes how you work with the 45° limitation and part of this 
> changes how you get the disambiguation menu.
> 
> Previously 45° was a hotkey (Shift or in v5 Ctrl/Cmd).  This is now set as a 
> state.  By default, the TAB key switches between states but you can customize 
> this action hotkey to your liking.  
> 
> Previously, Ctrl (and earlier Alt in v5) allowed you to show the full 
> disambiguation menu (which item should I choose) without KiCad applying 
> heuristics to the items under the cursor.  Now, you access this option by 
> clicking and holding the left mouse button down.
> 
> Moving these actions allows us to standardize the modifier key mapping 
> (Ctrl/Alt/Shift) for selections without the use of the Alt key, which was 
> problematic for Windows users.
> 
> Currently:
> 
> Shift + Click = Add to selection
> Shift + Ctrl + Click = Remove from selection
> Ctrl + Click = Highlight net
> 
> When not using the selection tool, the Ctrl modifier key still allows you to 
> ignore grid snaps when drawing and the Shift modifier still allows you to 
> ignore item snaps.
> 
> Seth
> 
> -- 
> 
> Seth Hillbrand
> Lead Developer
> +1-530-302-5483‬
> Long Beach, CA
> www.kipro-pcb.com i...@kipro-pcb.com 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Experience compiling latest HEAD

[Jeff Young]

> I presume KiCad 6 will be released after wx 3.2 is released (stated by their 
> releases page as 'hopefully in September 2021’).

No, we won’t be waiting on wxWidgets to release.  (I suspect their date is 
optimistic.)

Cheers,
Jeff.


> On 29 Jun 2021, at 14:14, Ruth Ivimey-Cook  wrote:
> 
> 
> On 29/06/2021 12:39, Jeff Young wrote:
>> Windows and Mac are single platforms, so the KiCad team builds those.  We 
>> also build the Linux flatpak, which is statically linked (to 3.1).
> 
> Except that the flatpak I installed yesterday is of version 5.1.10 and that 
> one at least is linked to wx 3.0. If there is another version of kicad 
> available as a flatpak I am unaware of it.
> 
> I need (because of the new lib formats) a 5.99 linked to wx 3.1.
> 
> I did try to self-compile, but the DRI linkage stuff broke. I still don't 
> know why.
> 
> Could the team consider making a flatpak of kicad-nightly available, linked 
> to wx 3.1.x (not necessarily latest), and document on the relevant page how 
> to install and use it for those like me who are unused to the flatpak?
> 
> 
>> It’s all the Linux distros that we can’t do much about.
>> 
>>> I'm not saying it's ideal to use the possibly broken -dev version of wx, 
>>> but IMO it is worse to use the actually broken "stable" version of it
>> He he… yeah, that about sums up the state of wxWidgets. ;)
> 
> I presume KiCad 6 will be released after wx 3.2 is released (stated by their 
> releases page as 'hopefully in September 2021').
> 
> I personally feel the project would be much better off using Qt because it's 
> a far better supported and designed framework, but I guess that's a question 
> for another era!
> 
> Ruth
> 
> 
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 29 Jun 2021, at 11:44, Ruth Ivimey-Cook  wrote:
>>> 
>>> 
>>>> wxwidget 3.1 is the development version for the upcoming stable version
>>>> 3.2 which possible breaks the API/ABI with every new version that is
>>>> getting released. That makes this software breaking other software too
>>>> often and by this unfit to get introduced into Debian unstable, it
>>>> simply make to less sense.
>>> Despite this, both the Windows and MacOS builds are using wx 3.1, somehow 
>>> or other
>>> 
>>> I'm not saying it's ideal to use the possibly broken -dev version of wx, 
>>> but IMO it is worse to use the actually broken "stable" version of it.
>>> 
>>> If needed, select a good-enough build of wx3.1 from the repo I referenced 
>>> and link kicad statically to it, so there can be no pollution of other apps.
>>> 
>>> Ruth
>>> 
>>> -- 
>>> 
>>> Tel: 01223 414180
>>> Blog: http://www.ivimey.org/blog
>>> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
> 
> -- 
> Software Manager & Engineer
> Tel: 01223 414180
> Blog: http://www.ivimey.org/blog <http://www.ivimey.org/blog>
> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/ 
> <http://uk.linkedin.com/in/ruthivimeycook/>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Experience compiling latest HEAD

[Jeff Young]

Windows and Mac are single platforms, so the KiCad team builds those.  We also 
build the Linux flatpak, which is statically linked (to 3.1).

It’s all the Linux distros that we can’t do much about.

> I'm not saying it's ideal to use the possibly broken -dev version of wx, but 
> IMO it is worse to use the actually broken "stable" version of it

He he… yeah, that about sums up the state of wxWidgets. ;)

Cheers,
Jeff.


> On 29 Jun 2021, at 11:44, Ruth Ivimey-Cook  wrote:
> 
> 
>> wxwidget 3.1 is the development version for the upcoming stable version
>> 3.2 which possible breaks the API/ABI with every new version that is
>> getting released. That makes this software breaking other software too
>> often and by this unfit to get introduced into Debian unstable, it
>> simply make to less sense.
> 
> Despite this, both the Windows and MacOS builds are using wx 3.1, somehow or 
> other
> 
> I'm not saying it's ideal to use the possibly broken -dev version of wx, but 
> IMO it is worse to use the actually broken "stable" version of it.
> 
> If needed, select a good-enough build of wx3.1 from the repo I referenced and 
> link kicad statically to it, so there can be no pollution of other apps.
> 
> Ruth
> 
> -- 
> 
> Tel: 01223 414180
> Blog: http://www.ivimey.org/blog
> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Experiences/feedback with 'nightly'

[Jeff Young]

Hi Ruth,

Are your 3D issues in raytracing or normal (OpenGL) rendering?  Could you 
screenshot your Preferences > 3D Viewer > Display Options panel?  (I’m unable 
to reproduce any of the issues you’re mentioning.)

For unlock all you can do a Select All and then a right-mouse-button Unlock.

You can convert old-format symbols to new format in the Manage Symbol Libraries 
dialog (the Migrate Libraries button).

The project viewer stuff is controversial. ;)  (See: 
https://gitlab.com/kicad/code/kicad/-/issues/7946 
.)

Single sided board (well, odd layer boards actually) is tracked in 
https://gitlab.com/kicad/code/kicad/-/issues/2425 
.

Cheers,
Jeff.


> On 28 Jun 2021, at 17:28, Ruth Ivimey-Cook  wrote:
> 
> I've been using the nightly build for the last couple of weeks on a hobby 
> project, with generally good results. I thought it might be helpful for you 
> some feedback on it. My comparisons are against 5.1.14:
> 
> I love the new cut/paste, click to move etc. Very much easier. I love too the 
> Schematic's 'edit endpoint' on a wire to extend it, but couldn't it support 
> general movement too, as is true for 'd' on the PCB?
> 
> I like the new part Group and part Lock options, and the dialog for lock 
> override. Have I missed finding a general Unlock All, though?
> 
> The router tool to drag whole parts with their tracks (opt 'd') gets very 
> easily confused with conflicts on tracks that shouldn't be there and for any 
> many-pin part it's almost unusable. I didn't notice the same problems in 
> v5.1. By 'shouldn't be there' I think there is a conflict is with THT pads 
> where the hole itself becomes something to avoid. You can also conflict with 
> existing track segments which should and can move and are at least 1 segment 
> distant from the part being moved (e.g. part has pad A, which has a track 
> segment on it B, which then bends at 45deg to a segment C. Moving the part 
> moves A and B, but not C, which could move but is instead counted as a 
> conflict. Where the part movement is in line with tracks, things are 
> generally ok; problems arise when part movement is at an angle to track 
> connections.
> 
> A nice enhancement would be for PCB drag to support dragging of contiguous 
> groups of parts (e.g. when you use an area selection).
> 
> The 3D viewer is great as always. I'm not sure if this is a regression, but 
> when the solder resist layer (green etc) is not clipped at pcb holes, e.g. 
> mounting holes, and should be, so currently you can't see all the way through 
> holes. Switch off display of solder resist and you can. You also can't see 
> through THT part holes when components are not shown.
> 
> The new library format was obviously needed and makes more sense 
> (internals-wise). However, integration with older libraries needs 
> improvement, specifically there needs to be a way to auto import specific 
> symbols to an existing new-format library (e.g. project-specific) from an 
> old-format library (or if present this option is not obvious), and ideally a 
> way to export an new format symbol to an old format (even if that is then 
> marked as potentially broken and needs checking). At present it is not 
> practical for everyone to be on the new format all the time. Migration 
> old->new was good when that was appropriate.
> 
> The new project viewer tool layout is improved, but could the clickable area 
> for each tool encompass the text as well as the image? Perhaps also the icons 
> could be somewhat larger.
> 
> I was slightly confused, when setting up my board, that I wasn't allowed to 
> specify a single sided board... there is no option for just one layer of 
> copper. It so happens that my project grew and I do need 2 layers, but still.
> 
> My project has so far had a major revision, as I reimplemented the core of 
> the circuit, and in the process reset the part numbering. Of course there was 
> a fair bit of movement and redoing of pcb placement but some non-core parts 
> stayed put. I was hoping/expecting the areas that hadn't been changed would 
> either show up with lots of broken connections or be retained as-is, but no. 
> For parts that were renumbered  but not moved on the pcb, the track was left 
> with its original net, while the part's connections were those of the new 
> one. (e.g. old part R1 pad1 = 3V3 and has track 3V3, following change now R1 
> pad1 is GND. After change, R1 still refers to the same footprint so pad1 is 
> now GND but track is still 3V3, and yet the ratsnest showed nothing wrong). 
> NB Rule checker dialog not invoked, just the ratsnest.
> 
> Hope this helps,
> 
> Ruth
> 
> 
> -- 
> Tel: 01223 414180
> Blog: http://www.ivimey.org/blog
> LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : 

Re: [Kicad-developers] Default netlist

[Jeff Young]

Can you look in your project file and see if it’s getting set?

> On 11 May 2021, at 11:09, BERTRAND Joël  wrote:
> 
> Holger Vogt a écrit :
>> In 5.99: Eeschema ->  File -> Export -> Netlist
> 
>   Yes, I know. But dialog is always opened on default KiCAD netlist.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Default netlist

[Jeff Young]

Hi Joël,

Does it not remember the last setting?  (It’s supposed to.)

Cheers,
Jeff.

> On 11 May 2021, at 09:32, BERTRAND Joël  wrote:
> 
>   Hello,
> 
>   In KiCAD 5.x, if I remember, there was a button to select default
> netlist (and of course a button in main menu to generate netlist).
> 
>   Now, both buttons have been removed.
> 
>   But when you use external ngspice, you have to generate netlist by
> hands and you have to select each time you generate a netlist ngspice
> format. Is it possible to re-add a button to select a default netlist
> format ?
> 
>   Best regards,
> 
>   JB
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Updating Paths

[Jeff Young]

Woot!

> On 21 Mar 2021, at 14:41, Seth Hillbrand  wrote:
> 
> Hi All-
> 
> I've submitted a series of merge requests to coordinate renaming the default 
> paths from "library" to  "symbols" and from "modules" to "footprints"
> 
> https://gitlab.com/kicad/code/kicad/-/merge_requests/741 
> 
> https://gitlab.com/kicad/libraries/kicad-footprints/-/merge_requests/2618 
> 
> https://gitlab.com/kicad/libraries/kicad-symbols/-/merge_requests/3229 
> 
> https://gitlab.com/kicad/packaging/kicad-win-builder/-/merge_requests/116 
> 
> https://gitlab.com/kicad/packaging/kicad-ubuntu-builder/kicad-daily-package/-/merge_requests/3
>  
> 
> https://gitlab.com/kicad/packaging/kicad-fedora-builder/-/merge_requests/55 
> 
> 
> These should be merged at the same time to minimize disruption to our daily 
> packages.  Please look over any areas that affect you and let me know if 
> anything looks amiss.
> 
> Also, packagers not in our GitLab repository, please note that this is 
> changing (hopefully today).
> 
> -Seth
> 
> -- 
> 
> Seth Hillbrand
> Lead Developer
> +1-530-302-5483‬
> Long Beach, CA
> www.kipro-pcb.com i...@kipro-pcb.com 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Build error.

[Jeff Young]

Ditto!

> On 27 Feb 2021, at 13:55, Wayne Stambaugh  wrote:
> 
> Thanks!
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PCB Calculator text problem

[Jeff Young]

Huh.  I thought wxWidgets auto-column-widths were only broken on GTK?

> On 19 Feb 2021, at 18:04, David  wrote:
> 
> Done. Thanks.
> 
> On 19/02/2021 17:52, Seth Hillbrand wrote:
>> You can click Help->Report Bug
>> 
>> Thanks-
>> Seth
>> 
>> On Fri, Feb 19, 2021 at 9:43 AM David > > wrote:
>> Hi,
>> 
>> Just to let you know that there is a problem with the text on the first 
>> column fourth row of the board classes tab of the PCB Calculator (Please 
>> see attached screenshot). The text overflows the box.
>> 
>> I don't know how to report bugs so thought I'd mention it here. Thanks.
>> 
>> Thanks.
>> 
>> David.
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
>> 
>> 
>> -- 
>> 
>> Seth Hillbrand
>> Lead Developer
>> +1-530-302-5483‬
>> Long Beach, CA
>> www.kipro-pcb.com i...@kipro-pcb.com 
>> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] question about XML BOM output

[Jeff Young]

The  elements are used by Pcbnew.  We should probably suppress 
writing them in “BOM mode”.

> On 19 Feb 2021, at 14:50, Jonatan Liljedahl  wrote:
> 
> Hi,
> 
> When using jlcpcb-kicad-tools, it's tedious and error prone to fill in
> the LCSC_Part for all components, so I'm thinking how to automate this
> from a database/CSV file of preferred parts.
> 
> I'm thinking one could make a BOM plugin that processes the XML and
> matches value and footprint (package) to insert the correct LCSC_Part.
> 
> Looking at the XML, it looks for example like this:
> 
>
>  5819
>  kymatica:D_SOD-123
>  ~
>  
>C8598
> name="Spice_Lib_File">/Users/lijon/Dropbox/Electronics/Spice-Models/easyeda.lib
>0
>N
>2 1
>R
>  
>   description="Schottky diode, small symbol, filled shape"/>
>  
>  
>  
>   value="/Users/lijon/Dropbox/Electronics/Spice-Models/easyeda.lib"/>
>  
>  
>  
>  
>  
>  ----5d77ea7f
>
> 
> How come each custom field is repeated both in  as well as
> having a ? Which one is used?
> 
> Is there any way to read such an XML file back after processing it? Or
> is there a plugin API to process the schematic in place to fill in
> those LCSC_Part fields?
> 
> -- 
> /Jonatan
> http://kymatica.com
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] some property field names are translated in kicad_pcb file

[Jeff Young]

Hi Johann,

That looks like a bug.  Can you log it in GitLab?  (Mostly so you can test it 
after I attempt to fix it.)

Cheers,
Jeff.


> On 27 Jan 2021, at 10:45, Johann Wilhelm  
> wrote:
> 
> Hi!
> 
> I'm currently doing some parsing of PCB files and stumbled over this:
> 
> (footprint "Resistor_SMD:R_0805_2012Metric" (layer "B.Cu")
> ...
> (property "Dateiname Blatt" "some path to some schematic file")
> (property "Schaltplanname" "")
> ...
>   )
> 
> I'm not sure if this is on purpose, but I guess it is not too good of an idea 
> to translate the names of property fields in the kicad_pcb files.
> At least, it makes the format less portable since it relies on some 
> translations.
> 
> Any thoughts on this?
> 
> Regards,
> Johann
> 
> Dipl.-Ing. 
> Johann Maximilian Wilhelm
> Bahnhofstraße 16/1
> 4600 Wels / AUSTRIA
> Tel: +43 664 55 269 77
> VAT Number: ATU74582123
> EORI-Number: ATEOS1000106258
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Odp: Re: Questions to the QA code

[Jeff Young]

Good point.  I have only used the Java one (which I guess is the original?).

Cheers,
Jeff.


> On 20 Jan 2021, at 21:18, Sylwester Kocjan  wrote:
> 
> Hi Jeff,
> 
> Did you use https://github.com/tpounds/mockitopp 
> <https://github.com/tpounds/mockitopp> or that one for Java 
> https://github.com/mockito/mockito <https://github.com/mockito/mockito> ?
> Mockitopp has it's last code update about ~1,5 year ago, so it looks it has 
> the same downside as HippoMocks.
> There is also Mockpp, also not actively developed: 
> https://sourceforge.net/projects/mockpp/ 
> <https://sourceforge.net/projects/mockpp/>
> 
> BR,
> SK
> Dnia 17 stycznia 2021 16:45 Jeff Young  napisał(a):
> 
> I’ve used Mockito.  Can’t say I remember a thing about it, though (which 
> could be good?).
> 
> Cheers,
> Jeff.
> 
>> On 17 Jan 2021, at 14:49, Sylwester Kocjan < 
>> <mailto:s.koc...@o2.pl>s.koc...@o2.pl <mailto:s.koc...@o2.pl>> wrote:
>> 
>> Hello,
>> 
>> On 17/01/2021 09:47, Alex wrote:
>> > ...GTest, Doctest and Catch2, (...) they'll all get the job done
>> 
>> They are all testing frameworks without mocking capability. We have already 
>> Boost.Test based tests and I find it unnecessary effort to migrate them, and 
>> alone
>> they don't solve the problem. 
>> 
>> 
>> On 17/01/2021 09:47, Alex wrote:
>> > I wasn't aware that GMock could operate separately from GTest, but if it 
>> > can, that's pretty neat.
>> 
>> On Sun, Jan 17, 2021, 12:15 AM Andrew Lutsenko  
>> <mailto:anlutse...@gmail.com> wrote:
>> > You can also use gmock separately from gtest.
>> 
>> Since some time gmock is a part of gtest. Any search results in the topic of 
>> gmock with another testing frameworks are quite old. I think there is a risk 
>> that it will not work. 
>> 
>> 
>> On 17/01/2021 09:47, Alex wrote:
>> > Catch is a single header
>> 
>> I was instructed to avoid introducing new dependencies, hence my initial 
>> choice of single-header HippoMocks:
>> 
>> https://gitlab.com/kicad/code/kicad/-/issues/4446#note_445185505 
>> <https://gitlab.com/kicad/code/kicad/-/issues/4446#note_445185505>
>> 
>> On Sat, Jan 16, 2021 at 6:47 AM Seth Hillbrand  
>> <mailto:s...@kipro-pcb.com> wrote:
>> > The downside of HippoMocks from what I can gather is that the project 
>> > appears abandoned. 
>> 
>> Sadly, this is true. There are also other choices, but I don't have any 
>> hands-on experience with them and I don't know which one to choose:
>> - http://turtle.sourceforge.net/ <http://turtle.sourceforge.net/>
>> - https://github.com/tpounds/mockitopp <https://github.com/tpounds/mockitopp>
>> - https://github.com/rollbear/trompeloeil 
>> <https://github.com/rollbear/trompeloeil>
>> 
>> Best regards,
>> Sylwester
>> 
>> 
>> On 17/01/2021 09:47, Alex wrote:
>>> I've used GTest, Doctest and Catch2, and they'll all get the job done; 
>>> Doctest is definitely the fastest to compile, but also has the least of 
>>> features; Catch and GTest have the most features.
>>> 
>>> I wasn't aware that GMock could operate separately from GTest, but if it 
>>> can, that's pretty neat.
>>> 
>>> I believe Doctest and Catch both are single header - I know at least Catch 
>>> is a single header; but I think it makes sense to use a git submodule in 
>>> this case.
>>> 
>>> 
>>> On Sun, Jan 17, 2021, 12:15 AM Andrew Lutsenko < 
>>> <mailto:anlutse...@gmail.com>anlutse...@gmail.com 
>>> <mailto:anlutse...@gmail.com>> wrote:
>>> I would also suggest to look towards gtest/gmock. 
>>> It's widely adopted, works with cmake out of the box, has integrations with 
>>> popular IDEs and a good choice of supporting tools like parallelized 
>>> runners, GUI inspectors etc.
>>> You can also use gmock separately from gtest.
>>> 
>>> Andrew
>>> 
>>> On Sat, Jan 16, 2021 at 6:47 AM Seth Hillbrand < 
>>> <mailto:s...@kipro-pcb.com>s...@kipro-pcb.com <mailto:s...@kipro-pcb.com>> 
>>> wrote:
>>> Hi Sylwester-
>>> 
>>> I haven't used HippoMocks but in general, adding QA tests is always welcome 
>>> as long as they run as expected under the Fedora docker we use for online 
>>> QA with GitLab.
>>> 
>>> The downside of HippoMocks from what I can gather is that the project 
>>> appears abandoned.  

Re: [Kicad-developers] Questions to the QA code

[Jeff Young]

I’ve used Mockito.  Can’t say I remember a thing about it, though (which could 
be good?).

Cheers,
Jeff.

> On 17 Jan 2021, at 14:49, Sylwester Kocjan  wrote:
> 
> Hello,
> 
> On 17/01/2021 09:47, Alex wrote:
> > ...GTest, Doctest and Catch2, (...) they'll all get the job done
> 
> They are all testing frameworks without mocking capability. We have already 
> Boost.Test based tests and I find it unnecessary effort to migrate them, and 
> alone
> they don't solve the problem. 
> 
> 
> On 17/01/2021 09:47, Alex wrote:
> > I wasn't aware that GMock could operate separately from GTest, but if it 
> > can, that's pretty neat.
> 
> On Sun, Jan 17, 2021, 12:15 AM Andrew Lutsenko  
>  wrote:
> > You can also use gmock separately from gtest.
> 
> Since some time gmock is a part of gtest. Any search results in the topic of 
> gmock with another testing frameworks are quite old. I think there is a risk 
> that it will not work. 
> 
> 
> On 17/01/2021 09:47, Alex wrote:
> > Catch is a single header
> 
> I was instructed to avoid introducing new dependencies, hence my initial 
> choice of single-header HippoMocks:
> 
> https://gitlab.com/kicad/code/kicad/-/issues/4446#note_445185505 
> 
> 
> On Sat, Jan 16, 2021 at 6:47 AM Seth Hillbrand  
>  wrote:
> > The downside of HippoMocks from what I can gather is that the project 
> > appears abandoned. 
> 
> Sadly, this is true. There are also other choices, but I don't have any 
> hands-on experience with them and I don't know which one to choose:
> - http://turtle.sourceforge.net/ 
> - https://github.com/tpounds/mockitopp 
> - https://github.com/rollbear/trompeloeil 
> 
> 
> Best regards,
> Sylwester
> 
> 
> On 17/01/2021 09:47, Alex wrote:
>> I've used GTest, Doctest and Catch2, and they'll all get the job done; 
>> Doctest is definitely the fastest to compile, but also has the least of 
>> features; Catch and GTest have the most features.
>> 
>> I wasn't aware that GMock could operate separately from GTest, but if it 
>> can, that's pretty neat.
>> 
>> I believe Doctest and Catch both are single header - I know at least Catch 
>> is a single header; but I think it makes sense to use a git submodule in 
>> this case.
>> 
>> On Sun, Jan 17, 2021, 12:15 AM Andrew Lutsenko > > wrote:
>> I would also suggest to look towards gtest/gmock.
>> It's widely adopted, works with cmake out of the box, has integrations with 
>> popular IDEs and a good choice of supporting tools like parallelized 
>> runners, GUI inspectors etc.
>> You can also use gmock separately from gtest.
>> 
>> Andrew
>> 
>> On Sat, Jan 16, 2021 at 6:47 AM Seth Hillbrand > > wrote:
>> Hi Sylwester-
>> 
>> I haven't used HippoMocks but in general, adding QA tests is always welcome 
>> as long as they run as expected under the Fedora docker we use for online QA 
>> with GitLab.
>> 
>> The downside of HippoMocks from what I can gather is that the project 
>> appears abandoned.  If I'm incorrect here, can you link to the current 
>> repository/documentation?
>> 
>> Thanks-
>> Seth
>> 
>> On Fri, Jan 15, 2021 at 2:49 PM Sylwester Kocjan > > wrote:
>> Hello,
>> 
>> I have two questions regarding QA code for KiCad and I'd like to ask for 
>> your comments about them:
>> 
>> 1. I reviewed contents of qa directory in KiCad repo and I saw some issues 
>> that can be fixed.
>>Could you please take a look at the summary and let me know if they are 
>> valid:
>> 
>> https://docs.google.com/spreadsheets/d/14QAy9rRIHqRr4YuXfQO2GicURAG1BgJmwKe7B1H6xXI/edit#gid=326687467
>>  
>> 
>> 
>> 2. What do you think about adding mocking library to the KiCad code? I found 
>> that PGM object is mocked few times
>> 
>>https://gitlab.com/kicad/code/kicad/-/issues/4446#note_342766728 
>> 
>>   
>>A libary for creating mocks would simplify creting the tests. In this MR 
>> and commit:
>>   
>>https://gitlab.com/kicad/code/kicad/-/merge_requests/542 
>> 
>>
>> https://gitlab.com/kicad/code/kicad/-/merge_requests/542/diffs?commit_id=b7b401d7128057831c049a723ffc895453d65a0e
>>  
>> 
>>   
>>there is added HippoMocks, a single-header mocking tool and it does it's 
>> job.
>>If that's ok, it could help to get rid of these duplicated mocks (maybe 
>> even hand-written mocks at all).
>> 
>> Best regards,
>> Sylwester
>> ___
>> Mailing 

Re: [Kicad-developers] Build problem of current master tree

[Jeff Young]

I’m a 3rd-grader (at best) when it comes to cmake/build systems, so I’ll leave 
that one for others….

> On 2 Jan 2021, at 15:06, Carsten Schoenert  wrote:
> 
> Hello Jeff,
> 
> Am 02.01.21 um 15:45 schrieb Jeff Young:
>> Hi Carsten,
>> 
>> Known problem when building 5.99 in a tree that used to hold 5.1.
>> 
>> Try:
>> 
>> cd include
>> rm *_lexer.h
> ahh, yes that fixed the build.
> 
> But I see the build of additional required files within the source tree
> rather as issue if I build out of tree. Is this behavior a problem of
> cmake or more a miss configuration of the build controlling?
> 
> -- 
> Mit freundlichen Grüßen
> Carsten Schönert
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Build problem of current master tree

[Jeff Young]

Hi Carsten,

Known problem when building 5.99 in a tree that used to hold 5.1.

Try:

cd include
rm *_lexer.h

Cheers,
Jeff.


> On 2 Jan 2021, at 14:00, Carsten Schoenert  wrote:
> 
> Hi,
> 
> since a long time I'm trying to build a current version of 5.99 again.
> But my attempt is failing with this error.
> 
>> [ 70%] Built target eeschema_kiface_objects
>> Scanning dependencies of target eeschema_kiface
>> [ 70%] Building CXX object 
>> eeschema/CMakeFiles/eeschema_kiface.dir/eeschema.cpp.o
>> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:239:22:
>>  error: use of undeclared identifier 'T_pinfunction'
>>case T_pinfunction:
>> ^
>> /home/carsten/gitprojects/kicad-upstream/kicad/pcbnew/netlist_reader/kicad_netlist_reader.cpp:362:14:
>>  error: use of undeclared identifier 'T_property'
>>case T_property:
>> ^
>> 2 errors generated.
>> make[2]: *** [common/CMakeFiles/pcbcommon.dir/build.make:689: 
>> common/CMakeFiles/pcbcommon.dir/__/pcbnew/netlist_reader/kicad_netlist_reader.cpp.o]
>>  Error 1
>> make[2]: *** Waiting for unfinished jobs
>> [ 70%] Linking CXX shared module _eeschema.kiface
>> make[1]: *** [CMakeFiles/Makefile2:2859: 
>> common/CMakeFiles/pcbcommon.dir/all] Error 2
>> make[1]: *** Waiting for unfinished jobs
>> [ 70%] Built target eeschema_kiface
>> make: *** [Makefile:182: all] Error 2
> 
> I'm running the required configuration within the classical subfolder
> build/ which is empty before starting the cmake call.
> 
> Known problem or do I miss some thing on my site?
> 
> -- 
> Regrads
> Carsten
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Odp: broken pipe and a simple commit

[Jeff Young]

No worries.  Everyone runs into it.

> On 22 Oct 2020, at 12:22, Marco Ciampa  wrote:
> 
> On Thu, Oct 22, 2020 at 11:01:48AM +0100, Jeff Young wrote:
>> I can’t see the pipeline reports (they’re all 404),
>> but did you increase the CI timeout for your repo to 4 hours?  
> 
> I am really sorry, I didn't know that I should do it ... let's try again
> ... if it do not finish I just can't ask a pull request...
> 
>> (Our CI system is really slow.)
> 
> Yes I saw...
> 
> --
> 
> Saluton,
> Marco Ciampa


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Odp: broken pipe and a simple commit

[Jeff Young]

I can’t see the pipeline reports (they’re all 404), but did you increase the CI 
timeout for your repo to 4 hours?  (Our CI system is really slow.)

> On 22 Oct 2020, at 10:42, Marco Ciampa  wrote:
> 
> On Thu, Oct 22, 2020 at 10:52:08AM +0200, Sylwester Kocjan wrote:
>> Hi Marco,   Did you try to push your commit directly on master branch?
> 
> No, I did this (as I am used to in github...):
> 
>> General Guidelines:
>> 
>>   1)Always create a new branch for merge requests instead of using your 
>> fork's master branch.
> 
> I created a personal fork. First commit (super small change that does not
> affect compilation at all) error message:
> 
> Your pipeline has failed.
> 
> Project: kicad ( https://gitlab.com/ciampix/kicad )
> Branch: master ( https://gitlab.com/ciampix/kicad/-/commits/master )
> 
> Commit: d8da1615 ( 
> https://gitlab.com/ciampix/kicad/-/commit/d8da161599065e519cc1a33b8bef01d3be3f8204
>  )
> Commit Message: Fixed single language translation update that w...
> Commit Author: Marco Ciampa ( https://gitlab.com/ciampix )
> 
> Pipeline #206121055 ( https://gitlab.com/ciampix/kicad/-/pipelines/206121055 
> ) triggered by Marco Ciampa ( https://gitlab.com/ciampix )
> had 3 failed builds.
> 
> Job #805521551 ( https://gitlab.com/ciampix/kicad/-/jobs/805521551/raw )
> 
> Stage: report
> Name: report_build_warn
> Job #805521552 ( https://gitlab.com/ciampix/kicad/-/jobs/805521552/raw )
> 
> Stage: report
> Name: report_metrics
> Job #805521539 ( https://gitlab.com/ciampix/kicad/-/jobs/805521539/raw )
> 
> Stage: build
> Name: build_linux
> 
> TIA
> 
> -- 
> 
> Saluton,
> Marco Ciampa
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] V6 Usability suggestion

[Jeff Young]

Hi Brian,

While it doesn’t directly address your suggestion, did you discover that you 
can also edit the severities by right-clicking on an actual DRC error (in the 
DRC dialog)?

Cheers,
Jeff.

> On 21 Oct 2020, at 17:44, Brian Piccioni  wrote:
> 
> Hello
> 
> The power new DRC is great. I believe it would be more usable if the
> 
> Board Setup -> Design Rules -> Violation Severity table
> 
> would be in alphabetical order.
> 
> Until the table has been configured there are a profligacy of DRC errors, 
> many of which are novel. The errors have names but since the table is not in 
> alphabetical order, finding them in the table to adjust (i.e. error to 
> warning) is unnecessarily complicated.
> 
> A minor thing, obviously.
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] New lead developer announcement.

[Jeff Young]

Welcome Mark & Thomas!

> On 7 Oct 2020, at 14:28, Chris Gammell  wrote:
> 
> Congrats, that's awesome! Wayne, can you post on the main site (blog) or the 
> forum as well so we can spread the word?
> 
> On Wed, Oct 7, 2020 at 8:23 AM Wayne Stambaugh  > wrote:
> I am happy to announce that Mark Roszko and Thomas Pointhuber have
> accepted invitations to the KiCad lead development team.  Mark and
> Thomas have be long time contributors to the KiCad project and I look
> forward to their contributions as lead developers.  Please join me in
> congratulating them in their new roles.
> 
> Cheers,
> 
> Wayne
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Back Annotate - Ignore Other Projects

[Jeff Young]

I think this is no longer used.  If memory serves, it was used in multi-part 
warnings.  (Now that we can independently back-annotate parts it no longer 
applies.)

But someone should probably do a cursory poke around to see if that memory 
matches reality….

> On 28 Sep 2020, at 19:58, jasura...@gmail.com wrote:
> 
> Hi Ian,
> Sorry I write from phone. I can tell you what logic was from very beginning. 
> In old schematic version it was possible to re-use schematic from the other 
> projects(for example you have 2 projects in one folder and each of them use 
> same schematic sheet).
> I'm not sure what happens next, I haven't look into the code after my old 
> commits. May be something changed with new schematic format and now it really 
> does nothing. I'm away from pc and cannot check it now.
> I hope it helps.
> 
> 28 сентября 2020 г. 20:04:27 GMT+03:00, Ian McInerney 
> mailto:ian.s.mciner...@ieee.org>> пишет:
> What is the option to "Ignore other projects" supposed to be used for in the 
> back annotation system? Right now it appears that it isn't connected to 
> anything outside the UI because I am getting an unused variable warning on it:
> 
> [1257/1983] Building CXX object 
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/tools/backannotate.cpp.o
> In file included from ../../eeschema/tools/backannotate.cpp:26:
> ../../eeschema/./tools/backannotate.h:112:34: warning: private field 
> 'm_ignoreOtherProjects' is not used [-Wunused-private-field]
> bool m_ignoreOtherProjects;
>  ^
> 1 warning generated.
> 
> -Ian
> 
> -- 
> Простите за краткость, создано в K-9 
> Mail.___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pad SHAPE, SH_RECT vs SH_SIMPLE

[Jeff Young]

Check the value of m_orient.  It sounds like it’s not exactly 0.  (Or 900, 1800 
or 2700.)

> On 7 Sep 2020, at 08:41, Mário Luzeiro  wrote:
> 
> Here are the debug of some cases that has 4 points SH_SIMPLE
> (51849001, 1150) (51849000, 1239) (52798999, 1240) (52799000, 
> 1151)
> It looks the points are differ 1 unit
> 
> These looks to be some strange 1 unit pad:
> (51849001, 1300) (51849000, 1389) (52798999, 1390) (52799000, 
> 1301)
> (54364001, 11247000) (54364000, 12096999) (55363999, 12097000) (55364000, 
> 11247001)
> 
> Format is (X1, Y1) (X2, Y2) ...
> 
> not sure if its related but this was an old project that was 
> converted/updated to the new format.
> 
> Mario
> 
> 
> From: Seth Hillbrand 
> Sent: 07 September 2020 00:33
> To: Mário Luzeiro
> Cc: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] Pad SHAPE, SH_RECT vs SH_SIMPLE
> 
> That might happen if the shape cache is dirty.  You can call 'pad->IsDirty()' 
> to check.
> 
> One related question: if you get the SH_SIMPLE and check the coordinates, do 
> they form a rectangle with angle 0?
> 
> -Seth
> 
> On Sun, Sep 6, 2020 at 3:52 PM Mário Luzeiro 
> mailto:mrluze...@ua.pt>> wrote:
> Hi all,
> 
> I noticed that (if I looked correctly) that there are some Pads, that are 
> marked as Rectangles but its shape Type is set to be SH_SIMPLE (both angles 
> are 0)
> So I got some rectangles that are SH_RECT and other rectangles are SH_SIMPLE
> 
> Could some one clarify this differences and what originate it?
> 
> Mario
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : 
> kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> --
> [KiCad Services Corporation Logo]
> Seth Hillbrand
> Lead Developer
> +1-530-302-5483‬
> Davis, CA
> www.kipro-pcb.com
> i...@kipro-pcb.com
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] D_PAD contributing to solder mask

[Jeff Young]

IsOnLayer( F_Mask ) || IsOnLayer( B_Mask )



> On 6 Sep 2020, at 18:43, Mário Luzeiro  wrote:
> 
> Hi all,
> what is the correct way to check that a D_PAD is contributing to solder mask?
> eg: on the Pad Properties editor, the F.Mask or B.Mask is ticked..
> 
> Mario
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] request for comment about perhaps clearer strings

[Jeff Young]

I was thinking that but decided I must just be too much of a MOSFET-head.  
(Well, at least when I can’t find a suitable JFET.)

> On 31 Aug 2020, at 17:37, Seth Hillbrand  wrote:
> 
> 
> 
> On Mon, Aug 31, 2020 at 9:30 AM Marco Ciampa  > wrote:
> On Mon, Aug 31, 2020 at 07:08:51AM -0700, Seth Hillbrand wrote:
> > There are a couple reasons not to change the term from "Power" to "Supply".
> > First,  we have symbol libraries with the "Power" term.  Changing the
> > software to "Supply" would need to include changing the library.  Second,
> > the term "Supply" in electrical engineering is reserved.  It refers to a
> > direction of current.  It is the pair of "Drain".
> 
> clear & right
> 
> My apologies.  I wrote this before finishing my coffee.  The pairs (in 
> english) are "Source" and "Drain" not "Supply" and "Drain".  But the first 
> reason is valid.
> 
> -- 
> 
> Seth Hillbrand
> Lead Developer
> +1-530-302-5483‬ 
> Davis, CA
> www.kipro-pcb.com i...@kipro-pcb.com 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Placing real components out of a database instead of: "Automatic assignment of footprint with a database"

[Jeff Young]

Awesome.  You guys might lose me so I can go work on that….

> On 29 Aug 2020, at 16:07, Seth Hillbrand  wrote:
> 
> Calcite is a classic open source application.  No ODBC driver but they 
> support queries in pig latin.
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Placing real components out of a database instead of: "Automatic assignment of footprint with a database"

[Jeff Young]

My point about MySQL wasn’t that *we* should bundle it, but rather why some of 
the contributors to this thread wanted to avoid it (or other things that 
support ODBC) and instead use CSV.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Placing real components out of a database instead of: "Automatic assignment of footprint with a database"

[Jeff Young]

Surely there must be an open source impl of an ODBC interface on a CSV file?

Although I’m not sure of the desire to avoid MySQL.  It’s remarkably easy to 
set up an instance (or auto-deploy one with an app).  

Apologies if we’ve already talked about that; I’ll confess to not having 
followed this thread 100%….

> On 29 Aug 2020, at 14:11, Wayne Stambaugh  wrote:
> 
> I would most likely reject any solution that was tied to a particular
> database.  All this would do is open up a Pandora's box of complaints as
> to why we didn't use database A over database B.  ODBC is the most
> flexible solution that I am aware of and allows users to choose their
> preferred database.
> 
> Cheers,
> 
> Wayne
> 
> On 8/29/20 8:29 AM, Jon Evans wrote:
>> Putting aside the fact that I think this feature isn't really aimed at
>> hobbyists, I would not be opposed to people wanting to extend it beyond
>> ODBC but that comes with extra complexity that must be handled.
>> 
>> With ODBC, KiCad just needs to know about the interface to retrieve the
>> data.
>> 
>> With a CSV file, KiCad actually needs to read that file in and keep it
>> in memory.  Watch for modifications on disk, or else lock it
>> exclusively.  Things like that.
>> 
>> I'm not sure I really see the advantage of a CSV-backed "database" over
>> the existing KiCad library system, if we're talking about a single user.
>> 
>> -Jon
>> 
>> On Sat, Aug 29, 2020 at 8:19 AM Mark Roszko > >> wrote:
>> 
>>> Sqlite was a quick way to test if my ideas would work. 
>>There are ODBC wrappers for SQLite
>> 
>>> I mean libreoffice would do for the management.
>>Yes, and you know what you would use? Not CSV files.
>>LibreOffice Base / Microsoft Access.
>>This is the office suite database that's basically SQLite and there
>>are ODBC wrappers as well :D
>> 
>>> Also, why would a hobbyist fire up a sql database when a CSV file
>>would be sufficient? I mean libreoffice would do for the management.
>> 
>>KiCad's uses aren't limited to hobbyists...
>>And, you assume there aren't hobbyists like me who will gladly take
>>that ODBC link and spin up an frontend in a few hours to the whole
>>system :D
>> 
>> 
>>On Sat, Aug 29, 2020 at 4:22 AM Johann Wilhelm
>>> > wrote:
>> 
>>Hi there!
>> 
>>Well, then my comment was not completely wrong.
>> 
>>Sqlite was a quick way to test if my ideas would work. For
>>my future productive system I really want to use a mix of
>>couchdb and maybe postgres. i.e. a JSON document storage for the
>>component information and sql for inventory management.
>> 
>>So ODBC would not work well for me.
>> 
>>Also, why would a hobbyist fire up a sql database when a CSV
>>file would be sufficient? I mean libreoffice would do for the
>>management.
>> 
>>Additionally, I'd suggest looking at the BOM creation. There,
>>external programs are called.
>> 
>>So why not define a dataformat (xml, json, csv,...) and just
>>call an external app or read from a file/uri?
>> 
>>Anyways, I would volunteer for implementing some alternatives
>>(read from file/uri and output of executable) to the ODBC
>>interface if someone guides me through the KiCad procedures.
>> 
>>Regards,
>>Johann
>> 
>> 
>>Jon Evans mailto:j...@craftyjon.com> 
>> >> schrieb
>>am Fr., 28. Aug. 2020, 19:54:
>> 
>>My idea is to make it possible for KiCad to talk to an
>>external database.
>>The database itself (and its schema) will not be defined as
>>part of this spec, and will not be part of KiCad.
>> 
>>The only requirement is that you have some columns in your
>>schema that KiCad understands (for example, to point to the
>>right symbols and footprints in the KiCad libraries).
>>The planned interface to connect to the database is ODBC. 
>>This would in theory allow using sqlite to create a database
>>as a file on disk, although I anticipate that most users
>>will be using something like MariaDB or Postgres.
>> 
>>There has been some discussion of supporting talking to web
>>interfaces via some REST API, or even talking to arbitrary
>>interfaces via Python scripting, but that discussion should
>>stay separate.
>>The original thread was about getting component information
>>out of a database and I just wanted to let people know that
>>I am working on this.
>> 
>>People are welcome to also discuss the ideas of getting
>>component information from a web API or from some Python script.
>>But, I 

Re: [Kicad-developers] running gerbview from local build on macOS

[Jeff Young]

It’s a “thing” on OSX.  I run the attached script which fixes things up.  Sadly it has to be run after each build.I know Jon has the same issue, but I haven’t heard about it from Ian.  Perhaps he has a better solution….Cheers,Jeff.

link_apps.sh
Description: Binary data
On 19 Aug 2020, at 10:32, Jonatan Liljedahl  wrote:I now tried deleting the old system-wide /Applications/KiCad, and nowwhen clicking the gerbview button in project manager it gives the sameerror about not finding _gerbview.kifaceOn Wed, Aug 19, 2020 at 11:25 AM Jonatan Liljedahl  wrote:Hi! I'm having difficulties launching gerbview from my local build.I'm opening kicad.app like this, while standing in the build directory(/Users/lijon/Coding/kicad/build/master)   open kicad/kicad.app...which works fine. However, clicking the gerbview button in theproject manager launches an old gerbview installed in systemwide/Applications/KiCad/Trying to open it manually by   open gerbview/gerbview.appfails with "Failed to load kiface library“/Users/lijon/Coding/kicad/build/Contents/PlugIns/_gerbview.kiface”and then crashes.Same with:   ./gerbview/gerbview.app/Contents/MacOS/gerbviewexcept now it tries to look in/Users/lijon/Coding/kicad/build/master/Contents/PlugIns/I've also tried to stand in the kicad.app directory and open it fromthere, but with similar results.Any ideas how to run a locally built gerbview on macOS?Cheers--/Jonatanhttp://kymatica.com-- /Jonatanhttp://kymatica.com___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pcbnew - wxWidgets Debug Alerts on startup

[Jeff Young]

I don’t see them.

Can you drop into a debugger and give us the stack trace for each one of them?

Thanks,
Jeff.

> On 18 Aug 2020, at 19:56, pjmo...@csi.com wrote:
> 
> Is it just me or does anyone else get these "wxWidgets Debug Alert" 
> messages when starting up Pcbnew:
> 
> -
> C:/msys64/home/kicad-master/kicad/include/property.h(418): assert 
> "m_choices.GetCount() > 0" failed in PROPERTY_ENUM(): No enum choices 
> defined
> Do you want to stop the program?
> You can also choose [Cancel] to suppress further warnings.
> -
> 
> If you click "No" to continue, you get two more of them before Pcbnew 
> finally starts.  Clicking cancel on the first skips the other two.
> 
> I've been seeing these for probably 3-4 weeks and assumed it would be 
> found and fixed long ago.  However, since the glitch still shows up even 
> in the 96f4e8f6f877a4a13ac7 commit from 8/17/2020, I'd like to know if 
> anyone else is seeing this?
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] ERC Rules Options missing?

[Jeff Young]

Schematic Setup.

It got much bigger because you can now set the severities of all the errors.

Cheers,
Jeff.


> On 8 Aug 2020, at 17:47, Brian Piccioni  wrote:
> 
> Hello
> 
> I'm running my built Version: (5.99.0-2620-g2af4bd02a), release build.
> 
> ERC Rules options seems to have disappeared. It is no longer part of the ERC 
> dialog (where I think it should be) and I can't find it in preferences.
> 
> Any suggestions?
> 
> Brian
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] kicad | pcbnew: dragging leaves behind the courtyard (#5037)

[Jeff Young]

My numeric dyslexia hath produced another great bug.  Check out this video. ;)

> On 2 Aug 2020, at 03:43, evils  wrote:
> 
> evils  commented:
> 
> @jeffyoung  is this related?
> 
> 
> 2020-08-02T04_41_10+02_00 
> 
> kicad version
> — 
> Reply to this email directly or view it on GitLab 
> . 
> You're receiving this email because you have been mentioned on gitlab.com 
> . If you'd like to receive fewer emails, you can 
> unsubscribe 
> 
>  from this thread or adjust your notification settings.
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules panel

[Jeff Young]

To do syntax highlighting and code completion.

> On 20 Jul 2020, at 14:41, Ben Ellis  wrote:
> 
> Why are the DRC rules parsed w/ s-exprs as they're being typed instead of 
> after? I just fixed a bug where typing ) without ( crashed the entire program
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Display origin transforms for DRC reports?

[Jeff Young]

Callers of the form:

GetSelectMenuText( EDA_UNITS::MILLIMETRES );

are most likely test cases.

Dialogs also know what the user units are, so you can get it from there too if 
you don’t have a frame.

But yes, I spent a lot of time divorcing GetSelectMenuText() from global 
variables and the frame; I’d hate to see it lost.

On the topic Jon and Ian were discussing (one parameter or two) I don’t have 
strong feelings.

Cheers,
Jeff.


> On 10 Jul 2020, at 21:30, Jon Evans  wrote:
> 
> The way I see it, there is one package of information that we should
> be delivering: how to turn internal units into real text for display.
> That information includes both a units selection and whatever
> transform to apply in case there are coordinates involved.
> 
> I see no benefit into splitting that into two arguments.
> 
> On Fri, Jul 10, 2020 at 4:27 PM Ian McInerney  
> wrote:
>> 
>> Doesn't the origin transform operate on the IU and not use the units 
>> directly (so the units are only needed by the actual menu text generation 
>> function)? If they are separate, then we should pass them as two individual 
>> arguments to the GetSelectMenuText function.
>> 
>> -Ian
>> 
>> On Fri, Jul 10, 2020 at 8:40 PM Jon Evans  wrote:
>>> 
>>> It would be preferable to make it possible to call GetSelectMenuText
>>> (or really, any facility that needs access to the current units and
>>> coordinate transform) without a frame.
>>> 
>>> We have recently been putting a lot of effort into separating the
>>> logic code from the UI / frame code in KiCad, and it would be a shame
>>> to introduce something that ties them together.
>>> 
>>> What about bundling together the units selection and the origin
>>> transforms into a single object that can be passed into
>>> GetSelectMenuText instead of the EDA_DRAW_FRAME?
>>> 
>>> That would make it easier to write testcases and other standalone
>>> chunks of code that can pass in arbitrary units and transforms without
>>> having to construct a frame.
>>> 
>>> -Jon
>>> 
>>> On Fri, Jul 10, 2020 at 3:33 PM Reece R. Pollack  wrote:
>>>> 
>>>> The units selection and the origin transforms are both available through
>>>> the EDA_DRAW_FRAME. I haven't looked at every call in detail (there are
>>>> a combined 118 calls and function declarations), but it appears that
>>>> when the caller has access to an EDA_DRAW_FRAME then the call is some
>>>> variant of:
>>>> 
>>>>  GetSelectMenuText( m_editFrame->GetUserUnits() );
>>>> 
>>>> Where there isn't access to an EDA_DRAW_FRAME, it's coded as:
>>>> 
>>>>  GetSelectMenuText( EDA_UNITS::MILLIMETRES );
>>>> 
>>>> It seems to me that if we're going to change the parameters to this
>>>> function, we should pass a pointer to an EDA_DRAW_FRAME as a single
>>>> parameter. If this parameter is nullptr, then we assume
>>>> EDA_UNITS::MILLIMETRES and null transforms, otherwise we use the getter
>>>> functions in EDA_DRAW_FRAME to get the correct object or data.
>>>> 
>>>> I'd need to see more than a few nodding heads before I made either of
>>>> these changes.
>>>> 
>>>> -Reece
>>>> 
>>>> On 7/10/20 3:00 PM, Jeff Young wrote:
>>>>> I agree on both points: units and transform should be saved in the 
>>>>> project file, and they should be passed to GetSelectMenuText as 
>>>>> parameters.
>>>>> 
>>>>> Cheers,
>>>>> Jeff.
>>>>> 
>>>>> 
>>>>>> On 10 Jul 2020, at 19:35, Jon Evans  wrote:
>>>>>> 
>>>>>> OK, I see.
>>>>>> 
>>>>>> I have mostly stayed out of this conversation before so I will
>>>>>> probably step back, but I would suggest that I think that display
>>>>>> units and origin choice should be a project-level setting, not
>>>>>> system-level.
>>>>>> 
>>>>>> Probably it makes sense to change GetSelectMenuText so that it has
>>>>>> this context available somehow (whether by passing in an
>>>>>> EDA_DRAW_FRAME or by just passing in the ORIGIN_TRANSFORMS or
>>>>>> whatever)
>>>>>> 
>>>>>> -Jon
>>>>>> 
>>>>>> On Fri, Jul 10, 2020 at 2:29 PM Reece R. Pollack  wrote:
>>&

Re: [Kicad-developers] Display origin transforms for DRC reports?

[Jeff Young]

I agree on both points: units and transform should be saved in the project 
file, and they should be passed to GetSelectMenuText as parameters.

Cheers,
Jeff.


> On 10 Jul 2020, at 19:35, Jon Evans  wrote:
> 
> OK, I see.
> 
> I have mostly stayed out of this conversation before so I will
> probably step back, but I would suggest that I think that display
> units and origin choice should be a project-level setting, not
> system-level.
> 
> Probably it makes sense to change GetSelectMenuText so that it has
> this context available somehow (whether by passing in an
> EDA_DRAW_FRAME or by just passing in the ORIGIN_TRANSFORMS or
> whatever)
> 
> -Jon
> 
> On Fri, Jul 10, 2020 at 2:29 PM Reece R. Pollack  wrote:
>> 
>> Jon,
>> 
>> The alternate origins themselves (Place & Drill / Aux origin, and Grid
>> origin) in Pcbnew are stored in the BOARD_DESIGN_SETTINGS class and
>> saved in the board file. Of course, the Page origin location doesn't
>> need to be stored; it's always (0,0).
>> 
>> My initial thought last year was to store the user's choice of display
>> origin in the board file, but after some discussion we reached consensus
>> that the choice of display origin was more like millimeters/inches and
>> thus should be a user option rather than a board property. In the
>> proposed implementation, the user's preference for which origin is used
>> for display is stored in the PCB_DISPLAY_OPTIONS class and saved in the
>> pcbnew.json file. I think a case could be made that this should be saved
>> per-project, but no one has made a good argument for that.
>> 
>> 
>> The primary user of the display origin transforms is the UNIT_BINDER
>> class. This class has a pointer to the EDA_DRAW_FRAME object.  Since
>> UNIT_BINDER is common, I added a virtual function
>> "GetOriginTransforms()" to the EDA_DRAW_FRAME class. This function
>> returns a reference to an ORIGIN_TRANSFORMS class. The base
>> implementation of the ORIGIN_TRANSFORMS class contains functions that
>> return their coordinate arguments unchanged. This way none of the KiCad
>> applications see a change in behavior unless they override the
>> GetOriginTransforms() function.
>> 
>> In the case of Pcbnew, the EDA_DRAW_FRAME parameter is actually a
>> pointer to a PCB_BASE_FRAME object. In this class, the
>> GetOriginTransforms() function is overridden and returns a reference to
>> a PCB_ORIGIN_TRANSFORMS object. This object's functions know how to
>> access the BOARD_DESIGN_SETTINGS and PCB_DISPLAY_OPTIONS objects through
>> the PCB_BASE_FRAME object and perform the needed transformations.
>> 
>> This works for everything that can find the EDA_DRAW_FRAME object, like
>> UNIT_BINDER. The GetMsgPanelInfo functions take an EDA_DRAW_FRAME
>> pointer as a parameter, so this isn't a problem. However, the
>> GetSelectMenuText() functions take only an EDA_UNITS parameter. Thus my
>> problem.
>> 
>> -Reece
>> 
>> On 7/10/20 1:25 PM, Jon Evans wrote:
>>> Shouldn't the origin be stored in the design data (BOARD / SCHEMATIC)
>>> rather than the base frame?
>>> 
>>> It seems like all data about objects, including their coordinates in
>>> the coordinate space defined by the user, should be available just by
>>> parsing a board or schematic file (which should be independent of the
>>> EDA_BASE_FRAME)
>>> 
>>> -Jon
>>> 
>>> On Fri, Jul 10, 2020 at 1:18 PM Reece R. Pollack  wrote:
>>>> Jeff,
>>>> 
>>>> Thanks for the follow-up.
>>>> 
>>>> I'm finding some of the GetSelectMenuText() implementations format
>>>> coordinate addresses for display. That means they need to use display
>>>> origin transforms so the displayed coordinate matches what the user sees
>>>> on the status line and elsewhere. However, there does not appear to be a
>>>> path from these functions to the EDA_BASE_FRAME class where these
>>>> transforms are currently available.
>>>> 
>>>> Might someone more familiar with the data structures and calling
>>>> sequences could suggest how this can best be accomplished?
>>>> 
>>>> Seth, I'd appreciate it if you could bring your knowledge and expertise
>>>> to bear.
>>>> 
>>>> -Reece
>>>> 
>>>> On 7/10/20 6:35 AM, Jeff Young wrote:
>>>>> No, the DRC re-write won’t affect GetSelectMenuText().  It originated for 
>>>>> describing items in the Clarify Selection menu, but it’s 

Re: [Kicad-developers] Display origin transforms for DRC reports?

[Jeff Young]

I think that depends on whether the data is stored independently or not.  For 
instance, our internal values are independent of units, and the display units 
are only shown in the EDA_BASE_FRAME.

If the origin is similar (ie: it’s a view transform), then it should be passed 
as a parameter to GetSelectMenuText().

However, if the origin affects how to interpret the data in the file, then it 
should be in the BOARD/SCHEMATIC like Jon said (which is easy to access from 
the BOARD_ITEM or SCH_ITEM).

Cheers,
Jeff.


> On 10 Jul 2020, at 18:25, Jon Evans  wrote:
> 
> Shouldn't the origin be stored in the design data (BOARD / SCHEMATIC)
> rather than the base frame?
> 
> It seems like all data about objects, including their coordinates in
> the coordinate space defined by the user, should be available just by
> parsing a board or schematic file (which should be independent of the
> EDA_BASE_FRAME)
> 
> -Jon
> 
> On Fri, Jul 10, 2020 at 1:18 PM Reece R. Pollack  wrote:
>> 
>> Jeff,
>> 
>> Thanks for the follow-up.
>> 
>> I'm finding some of the GetSelectMenuText() implementations format
>> coordinate addresses for display. That means they need to use display
>> origin transforms so the displayed coordinate matches what the user sees
>> on the status line and elsewhere. However, there does not appear to be a
>> path from these functions to the EDA_BASE_FRAME class where these
>> transforms are currently available.
>> 
>> Might someone more familiar with the data structures and calling
>> sequences could suggest how this can best be accomplished?
>> 
>> Seth, I'd appreciate it if you could bring your knowledge and expertise
>> to bear.
>> 
>> -Reece
>> 
>> On 7/10/20 6:35 AM, Jeff Young wrote:
>>> No, the DRC re-write won’t affect GetSelectMenuText().  It originated for 
>>> describing items in the Clarify Selection menu, but it’s now used whenever 
>>> we want to describe an item to the user.
>>> 
>>>> On 10 Jul 2020, at 00:51, Reece R. Pollack  wrote:
>>>> 
>>>> On 7/9/20 7:09 PM, Tomasz Wlostowski wrote:
>>>>> On 10/07/2020 00:58, Reece R. Pollack wrote:
>>>>>> I'm looking at display origin transformations for DRC reports.
>>>>>> 
>>>>>> With the 5.1.x branch Pcbnew, the DRC report dialog box message texts
>>>>>> contained the Cartesian coordinates of each flagged item. It appears
>>>>>> that the 5.99 branch no longer displays the coordinates of DRC items.
>>>>>> However, the Cartesian coordinates are still listed in the report file.
>>>>>> Unlike the display in a dialog box, this report is persistent and could
>>>>>> be passed to someone using different display origin settings.
>>>>>> 
>>>>>>  1. Should these coordinates be reported relative to the page origin, or
>>>>>> transformed per the user-selected origin and axis directions?
>>>>>>  2. If the coordinates are transformed, should the report include the
>>>>>> user settings?
>>>>>> 
>>>>>> -Reece
>>>>>> 
>>>>> Reece,
>>>>> 
>>>>> I wouldn't introduce any changes to the current DRC code, we're
>>>>> designing a new DRC engine for KiCad V6 and many things in DRC interface
>>>>> will likely change.
>>>>> 
>>>>> IMHO the DRC coordinate transform belongs to the UI, not the DRC itself:
>>>>> - the DRC engine generates an internal report with coordinates in board
>>>>> coordinate space
>>>>> - whatever displays the report to the user (i.e. the DRC dialog)
>>>>> converts the board coordinates to UI coordinates.
>>>>> 
>>>>> - my 5 cents
>>>>> Tom
>>>>> 
>>>>> 
>>>> Tom,
>>>> 
>>>> I'm not hard to convince, especially when it means doing less work.
>>>> 
>>>> This sounds like the RC_ITEM::ShowCoord function will be removed or 
>>>> replaced. It's one of the two troublesome function groups.
>>>> 
>>>> The other troublesome function group is the GetSelectMenuText function. 
>>>> Last year I knew what they did but I've forgotten in the interim. Will 
>>>> this DRC rewrite replace these?
>>>> 
>>>> -Reece
>>>> 
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Display origin transforms for DRC reports?

[Jeff Young]

No, the DRC re-write won’t affect GetSelectMenuText().  It originated for 
describing items in the Clarify Selection menu, but it’s now used whenever we 
want to describe an item to the user.

> On 10 Jul 2020, at 00:51, Reece R. Pollack  wrote:
> 
> On 7/9/20 7:09 PM, Tomasz Wlostowski wrote:
>> On 10/07/2020 00:58, Reece R. Pollack wrote:
>>> I'm looking at display origin transformations for DRC reports.
>>> 
>>> With the 5.1.x branch Pcbnew, the DRC report dialog box message texts
>>> contained the Cartesian coordinates of each flagged item. It appears
>>> that the 5.99 branch no longer displays the coordinates of DRC items.
>>> However, the Cartesian coordinates are still listed in the report file.
>>> Unlike the display in a dialog box, this report is persistent and could
>>> be passed to someone using different display origin settings.
>>> 
>>>  1. Should these coordinates be reported relative to the page origin, or
>>> transformed per the user-selected origin and axis directions?
>>>  2. If the coordinates are transformed, should the report include the
>>> user settings?
>>> 
>>> -Reece
>>> 
>> Reece,
>> 
>> I wouldn't introduce any changes to the current DRC code, we're
>> designing a new DRC engine for KiCad V6 and many things in DRC interface
>> will likely change.
>> 
>> IMHO the DRC coordinate transform belongs to the UI, not the DRC itself:
>> - the DRC engine generates an internal report with coordinates in board
>> coordinate space
>> - whatever displays the report to the user (i.e. the DRC dialog)
>> converts the board coordinates to UI coordinates.
>> 
>> - my 5 cents
>> Tom
>> 
>> 
> Tom,
> 
> I'm not hard to convince, especially when it means doing less work.
> 
> This sounds like the RC_ITEM::ShowCoord function will be removed or replaced. 
> It's one of the two troublesome function groups.
> 
> The other troublesome function group is the GetSelectMenuText function. Last 
> year I knew what they did but I've forgotten in the interim. Will this DRC 
> rewrite replace these?
> 
> -Reece
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 3d-viewer: via diameter calculation off?

[Jeff Young]

Our usage of “drill” in the terminology is pretty misleading.  As far as I’m 
aware the vast majority of board houses treat it as “finish hole” diameter.

Cheers,
Jeff.


> On 8 Jul 2020, at 23:00, Seth Hillbrand  wrote:
> 
> That really depends on the manufacturer.  Many manufacturers will overdrill 
> and expand the size of their bits to account for the plating.  If you are 
> thinking of making a change like this, it would need to be an optional 
> preference.
> 
> Best-
> Seth
> 
>  
> Seth Hillbrand
> Lead Developer
> +1-530-302-5483‬ 
> Davis, CA
> www.kipro-pcb.com i...@kipro-pcb.com 
> 
>
> 
> 
> On 2020-07-08 14:47, Joshua Redstone wrote:
> 
>> Hi,
>> I'm a bit new to pcbs and Kicad, but I thought that the effective diameter 
>> of a through-hole is the drill diameter minus copper plating thickness 
>> (since plating is done after drilling).
>> In the 3d-viewer code, it looks like it's increasing the drill diameter to 
>> account for the plating so the plated hole is the drill diameter rather than 
>> the unplated hole, which seems odd.
>>  
>> I was thinking of doing a diff to fix that, but wanted to check if I'm 
>> reading the code correctly.
>> Specifically, in 3d-viewer/3d_canvas/create_layer_items.cpp
>> the calculation of a hole's inner diameter is (hole_inner_radius) rather 
>> than (hole_inner_radius - [plating_]thickness).  And there's a corresponding 
>> offset in the calc of the outer diameter.
>>  
>> An example: 
>> https://gitlab.com/kicad/code/kicad/-/blob/master/3d-viewer/3d_canvas/create_layer_items.cpp#L306
>>  
>> 
>>  
>> I played around with rendering some test circuits and confirmed that the 
>> rendering seems to be producing holes that are too big.
>>  
>> Am I reading this right?
>>  
>> Thanks,
>> Josh
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Critical path item / request for help

[Jeff Young]

I love this part:

> wxPython4.0 (needed for Python3)

And I thought our versioning was challenged. ;)___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

[Jeff Young]

> On 4 Jul 2020, at 00:31, Reece R. Pollack  wrote:
> 
> On 7/3/20 5:42 PM, Jeff Young wrote:
>> Hi Reece,
>> 
>>> On 3 Jul 2020, at 21:32, Reece R. Pollack >> <mailto:re...@his.com>> wrote:
>>> 
>>> Noting that the PCB_BASE_FRAME class is derived from the EDA_DRAW_FRAME 
>>> class, is it acceptable to assume that the EDA_DRAW_FRAME pointer 
>>> parameters passed to functions in Pcbnew classes are actually pointers to a 
>>> PCB_BASE_FRAME?
>> 
>> Yes, but it would be considered bad practice.
> 
> I would argue that it could easily be defined that code in the pcbnew 
> directory is dealing with a PCB_BASE_FRAME rather than an EDA_DRAW_FRAME. 
> Common code should not make that assumption, of course, and would not use 
> anything beyond the base class.

The problem is not when the code is written, but rather years later when 
someone changes one of the assumptions you were depending on and doesn’t even 
remember that your code exists.  dynamic_cast will then protect you, while a 
C-style or static_cast is likely going to do something ugly.

> 
>>> 
>>> Specifically:
>>> The UNIT_BINDER class constructor
>>> The classes implementing the GetMsgPanelInfo function
>>> The classes implementing the GetSelectMenuText function
>>> The reason I'm asking is that to implement origin transforms these 
>>> functions need access to the user's display option that chooses the display 
>>> origin. This needs access to a function defined in the PCB_BASE_FRAME 
>>> class. I can make that a common function defined in EDU_DRAW_FRAME and 
>>> overridden in PCB_BASE_FRAME, or the code needs to know that parameter is 
>>> really a pointer to a PCB_BASE_FRAME object.
>>> 
>> Ask yourself this: is there anything PCB-specific about a settable origin?  
>> Is there any reason a settable origin wouldn’t also be useful, say, a 
>> schematic?  If the answer is “no”, then you should push the origin (along 
>> with its getters and setters) down in to EDA_DRAW_FRAME.
> 
> My submission last year was intended to allow any or all of the KiCad 
> subsystems (eeschema, pcbnew, gerbview, etc.) make use of origin transforms. 
> Gerbview could benefit, because if you set the place and drill origin to the 
> lower left of you design when you generate Gerbers, Gerbview displays the 
> page border below the displayed board. I'd thought about how to do this in 
> eeschema, considering an origin at any of the four corners or at the aux 
> origin (which is defined in eeschema but is not settable). But I did a full 
> implementation on pcbnew because that was what I felt really needed it.That  
> implementation added a parameter to the functions I mentioned above, which 
> resulted in the eeschema functions also having that parameter even though 
> they didn't use it. 
> 
> When Wayne sent out his last call for comments before he merged the changes, 
> Seth complained that since I didn't implement support in eeschema then these 
> changes should not affect any code in the eeschema directory. His suggestion 
> was to use function overloading, but that would result in having two 
> interfaces visible in the both eeschema and pcbnew, one that worked in that 
> context and one that didn't. You wouldn't know that the code called the wrong 
> function until you noticed broken behavior. I don't consider that an 
> acceptable situation just to avoid a trivial parameter list change.
> 
> My approach this year is that code in the pcbnew directory knows it's dealing 
> with a PCB_BASE_FRAME because it's PCB-specific code in the first place. Then 
> it's easy to access the PCB-specific interfaces and data. Rather than 
> changing the UNIT_BINDER class I've implemented a PCB_UNIT_BINDER class 
> derived from UNIT_BINDER. It knows that it's getting a PCB_BASE_FRAME rather 
> than an EDA_DRAW_FRAME, and passes that to the base class constructor. It's 
> more tricky with the functions that are called indirectly through the 
> EDA_DRAW_FRAME, such as GetMsgPanelInfo and GetSelectMenuText. The 
> implementations are specific to pcbnew and live in the pcbnew directory.
> 
> I can do it with dynamic casts, but I'm an embedded systems guy and I hate to 
> waste CPU cycles checking things that are defined to be true. And 
> dynamic_cast is slow: my tests of the Icarus Verilog simulator appear to show 
> VVP spends about 20% of its CPU cycles just resolving dynamic casts. 
> 
>> If this really is PCB-specific, then you can either push just the origin 
>> getters/setters down into EDA_DRAW_FRAME and override them in 
>> PCB_BASE_FRAME, or do a dynamic_cast to PCB_BASE_FRAME and if non-null call 
>&

Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

[Jeff Young]

Hi Reece,

> On 3 Jul 2020, at 21:32, Reece R. Pollack  wrote:
> 
> Noting that the PCB_BASE_FRAME class is derived from the EDA_DRAW_FRAME 
> class, is it acceptable to assume that the EDA_DRAW_FRAME pointer parameters 
> passed to functions in Pcbnew classes are actually pointers to a 
> PCB_BASE_FRAME?

Yes, but it would be considered bad practice.

> 
> Specifically:
> The UNIT_BINDER class constructor
> The classes implementing the GetMsgPanelInfo function
> The classes implementing the GetSelectMenuText function
> The reason I'm asking is that to implement origin transforms these functions 
> need access to the user's display option that chooses the display origin. 
> This needs access to a function defined in the PCB_BASE_FRAME class. I can 
> make that a common function defined in EDU_DRAW_FRAME and overridden in 
> PCB_BASE_FRAME, or the code needs to know that parameter is really a pointer 
> to a PCB_BASE_FRAME object.
> 
Ask yourself this: is there anything PCB-specific about a settable origin?  Is 
there any reason a settable origin wouldn’t also be useful, say, a schematic?  
If the answer is “no”, then you should push the origin (along with its getters 
and setters) down in to EDA_DRAW_FRAME.

If this really is PCB-specific, then you can either push just the origin 
getters/setters down into EDA_DRAW_FRAME and override them in PCB_BASE_FRAME, 
or do a dynamic_cast to PCB_BASE_FRAME and if non-null call the getters/setters.

Cheers,
Jeff.

> If the functions defined in PCB-specific classes are defined to be getting 
> pointers to PCB_BASE_FRAME classes, I can just change the parameter type and 
> avoid the need to play games with dynamic casts.
> 
> Thanks!
> 
> -Reece
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Derived class naming questions

[Jeff Young]

PCB_UNIT_BINDER.

No rule, so go with the prevailing practice.

Cheers,
Jeff.


> On 3 Jul 2020, at 21:49, Reece R. Pollack  wrote:
> 
> Here's a coding standards question:
> 
> Let's say I create a PCB-specific class derived from UNIT_BINDER. Should it 
> be called PCB_UNIT_BINDER or UNIT_BINDER_PCB?
> 
> -Reece
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Auto-generated backup files: are they useful?

[Jeff Young]

I find the backup files in the directory pretty annoying.

While it’s not ideal I’m willing to completely lose the backup functionality to 
fix that.

I’m also fine with building a more sophisticated system to folder them (ie: one 
that can handle the external files), but only if it’s going to actually get 
done for 6.0.  If it’s going to result in the can getting kicked further down 
the road, them I’d rather remove the feature.

Cheers,
Jeff.

> On 30 Jun 2020, at 12:57, Nick Østergaard  wrote:
> 
> Last time I looked, there was rescue feature in the file menu of pcbnew, I 
> think. I never used it, I don't really know what it does, but I guess it just 
> reads the bak file.
> 
> tir. 30. jun. 2020 09.32 skrev jp charras  >:
> Le 30/06/2020 à 00:13, hauptmech a écrit :
> > 
> > While I agree that it is not KiCad's job to do archival backups or version 
> > control, I do think that KiCad should preserve the integrity of users data 
> > through a crash. Even better if the work between the last save and the 
> > crash is also preserved and recovered on restart.
> > 
> > I have had to use the backup files to recover data in the past. I have no 
> > idea if that recovery was related to something that is now no longer a 
> > possible issue.
> > 
> > 
> > -Hauptmech
> > 
> > 
> 
> I am also thinking a backup can be useful when something unexpected happens.
> 
> Backups, like any security system, bothers you as long as you do not need to 
> use them.
> But you are happy to find them in case of trouble.
> 
> I like the way some CAD tools manage backup:
> only one zip archive is created (for instance projectname_backup.zip) and 
> contains all saved files
> (in our case: *.kicad_sch (and sub paths) and .kicad_pcb)
> This is not a full project backup, just main files are saved.
> 
> This is not invasive (only one file, or a few .zip if one want to keep last n 
> saved versions)
> and is a security against  unexpected cases.
> 
> For me, backups are like a accident insurance: you need them and you hope 
> never use them.
> 
> And about VCS use:
> 
> Many good electronics guys do not even know what is it, and have never 
> compiled any source code.
> Electronics world and Software world are not exactly the same world.
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Auto-generated backup files: are they useful?

[Jeff Young]

How does the current backup file strategy interact with the autosave feature?  
If autosave works without it, that might address a lot of these concerns.



> On 29 Jun 2020, at 23:13, hauptmech  wrote:
> 
> 
> While I agree that it is not KiCad's job to do archival backups or version 
> control, I do think that KiCad should preserve the integrity of users data 
> through a crash. Even better if the work between the last save and the crash 
> is also preserved and recovered on restart.
> 
> I have had to use the backup files to recover data in the past. I have no 
> idea if that recovery was related to something that is now no longer a 
> possible issue.
> 
> 
> -Hauptmech
> 
> 
> On 6/30/2020 7:23 AM, Jon Evans wrote:
>> Currently, KiCad automatically creates backups of schematic and PCB
>> files when you save a file.
>> 
>> The logic for these backups is basically: if a file already exists
>> with the same name as what we are saving, copy that file to a new file
>> and give it the "-bak" suffix on the file extension.
>> 
>> These backups are stored next to the original file in the current
>> KiCad codebase.  This understandably creates clutter that some people
>> don't like (myself included) so in the project-settings branch that is
>> about ready to be merged, I changed this behavior to place all these
>> backups in a special backups folder for the project.
>> 
>> This proved to have some complications around the handling of files
>> outside the project path (which it's possible to have with
>> hierarchical schematic sheets) so I need to do something else.
>> 
>> After some thought, I am pretty convinced that the right thing to do
>> is just *remove this backup feature entirely*.  Here's why:
>> 
>> 1) It's not a very good backup:  It just stores the state from the
>> last time you hit "save".  If you hit save again, your backup is blown
>> up.  So, it's really like a "undo" function, but on disk, and with
>> only one level of undo.
>> 
>> 2) Recently I changed how we save schematic and board files to fix
>> some unrelated issues people were seeing with cloud backup services.
>> Before this change, if KiCad crashed or had some other serious error
>> while saving a file, the file would be lost (because we used to delete
>> the old file and then write a new one in its place).  After this
>> change, we write the new file to a temporary location, and only if
>> that write succeeds do we copy it on top of the old file.  I think
>> this vulnerability to generating corrupt files if we crash was one of
>> the reasons for this backup file system, and that reason is now gone.
>> 
>> 3) Because it's not a very good backup, I worry that the fact that
>> "bak" files exist might cause some users to have a false sense of
>> security and not use a true backup system (like a version control
>> system, or some other mechanism that actually backs up files
>> periodically).  I want to remove this false sense of security so that
>> it is more clear that users should back up their files in some way if
>> they care about the work.
>> 
>> In other words, I don't think this feature actually gives enough value
>> to make it worth the clutter in the project folder and/or the
>> development effort to make it work well with less clutter.
>> 
>> So, I'd like to hear from others on this: anyone disagree?
>> 
>> Thanks,
>> Jon
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] WYSISYG pad editor

[Jeff Young]

Hi Roberto,

I confess I haven’t looked at the padstack document yet.

The prototype WYSIWYG shape editor is currently only in the Footprint Editor, 
although I’ve made most of the code agnostic between that and the board editor. 
 

I did look at doing it in the Pad Properties dialog, but that got nixed on 
account of many custom-shaped pads being related to each other (and therefore 
easier to edit en masse), and on that being the hardest place to integrate our 
tool framework (although I got far enough down that path that it’s now somewhat 
easier).

The trouble with the single-pad mode is that there’s a *lot* of editing code 
you do want to make available (copy/paste, duplicate, flip, rotate, move 
exactly, creating new shapes, deleting some existing shapes, etc.), and a *lot* 
that you want to exclude (pasting other shapes, pasting into other layers, 
switching layers, etc.).  That’s going to equate to a lot of code that has to 
be maintained.

Doing all pads at once gets around this, but it does indeed have the “might 
connect two pads” issue.  (Then again, it will only do that if their 
copper/mask/whatever is touching, so is that really an issue in practice?  Hmm… 
if someone is using a polygon to do a neck-down to a pad, and we allow 
recombine to run in Pcbnew, then we’re going to suck that polygon into the pad 
definition.  Maybe we do need to keep it Footprint Editor only.)

Cheers,
Jeff.

> On 26 Jun 2020, at 17:05, Roberto Fernández Bautista 
>  wrote:
> 
> Hi Jeff,
> 
> Did you have a chance to look at the draft document I sent on padstacks a few 
> days ago? I briefly explain how Altium and Cadstar handle pads and vias in 
> that document - hopefully it is helpful?
> 
> I'd like to point out that custom pad shapes are not actually well supported 
> in most other commercial EDAs, so what you are doing at KiCad is definitely 
> above and beyond! Great stuff!
> 
> The prototype shape editor that you are talking about: is this in pcbnew or 
> in the footprint editor? I suppose it would be valid to use this both for 
> editing vias in the PCB as well as pads in a footprint, in the library.  
> Maybe this could be done in the properties window of the pad/via where you 
> could have a basic drawing canvas to draw the shape of the pad/via (maybe in 
> the future you could even import a DXF or other similar format to define the 
> pad shape). Each shape could maybe be saved into a library that can be 
> re-used/selected.
> 
> I'd suggest that regardless of it being a "high contrast mode" or a 
> "properties" window: if you are creating custom shapes for a pad, you should 
> only be doing that: i.e. you are entering "pad editing mode" - you don't want 
> to be accidentally moving other things around while you are doing that and 
> certain certain things should be restricted while in this "mode" - e.g. 
> if you "paste other stuff", you should look at what is being pasted and if it 
> is a valid shape object, you could accept it, otherwise just don't do 
> anything; 
> you should not allow to "delete the pad anchor" - only to move it
> new objects on different layers - isn't the idea of this to be a padstack 
> editor? If so, then assign those shapes to the specific layer.
> I'm not sure I understand your second approach of exploding pads into shapes? 
> Seems to me like you might end up with a lot of random shapes that don't get 
> recombined if you forget to run the "recombine" command? Also I can see that 
> you'd end up joining up several pads together accidentally... I'd suggest the 
> "editing" mode should restrict editing to a single pad
> 
> Roberto (Qbort)
> 
> On Thu, 25 Jun 2020 at 21:53, Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> I implemented a prototype of a WYSIWYG custom-pad shape editor.
> 
> You can ctrl-E on a pad and it explodes it and puts you into high-contrast 
> mode with the shapes.  After editing the shapes a second ctrl-E re-combines 
> everything and exits high-contrast mode.
> 
> While it’s pretty neat if you do exactly that, it turns out to have a 
> bazillion corner cases.  (What happens if you paste other stuff in; what 
> happens if you delete the pad anchor; what happens if you create new objects 
> on different layers; etc.)
> 
> So I was considering a different idea which would be more “regular” (from an 
> implementation perspective).
> 
> Basically it would be a command to explode *all* pads in the current 
> footprint, and a command to recombine everything.  The recombine would expand 
> outwards from each pad to consume touching copper shapes.  (It might still 
> need a few edge cases for net-ties.)
> 
> Thoughts?
> ___
> Mailing 

Re: [Kicad-developers] GitLab milestone cleanup

[Jeff Young]

Hi Jon, et al,

So I’m still playing with WYSIWYG pad editing, but there’s no requirement for 
it in 6.0.  If I find something that works well then I’ll merge it, but 
otherwise it will probably get pushed to the back-burner (ie: 7.0 & padstacks).

So should it be in the milestone or not?

Cheers,
Jeff.

> On 26 Jun 2020, at 11:11, Ian McInerney  wrote:
> 
> In general, wishlist items should only be given a milestone if they are 
> either:
> 1) Actively being worked on by a developer
> 2) Currently on the plan for the release they are milestoned against (this 
> one doesn't need a developer assigned/working on them yet)
> 
> Other wishlist items don't get a milestone attached to them. I don't think 
> there is a need to have a "future" milestone though, since the GitLab 
> interface makes it easy to look through issues with no milestone and the 
> wishlist label (it is far easier than Launchpad was).
> 
> -Ian
> 
> On Fri, Jun 26, 2020 at 10:09 AM Eeli Kaikkonen  > wrote:
> 
> 
> On Fri, Jun 26, 2020 at 8:46 AM Nick Østergaard  > wrote:
> What about feature requests / wishes from users that are very unlikely to 
> realise quickly? Should they still be assigned the new milestone?
> 
> I just worry they may clutter the overview too much, but I guess when we will 
> see how it goes. :) My concern may not be a real problem afterall.
> 
> Nick
> 
> 
> Could there be a milestone "Future" for features which are wanted but not 
> planned for the next release? For example, some things were in the v6 roadmap 
> but were moved to the future roadmap, and even more can(?) be moved later. It 
> would be better to have them in Future milestone than keep them in v6 
> milestone or remove the milestone completely.
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] WYSISYG pad editor

[Jeff Young]

I implemented a prototype of a WYSIWYG custom-pad shape editor.

You can ctrl-E on a pad and it explodes it and puts you into high-contrast mode 
with the shapes.  After editing the shapes a second ctrl-E re-combines 
everything and exits high-contrast mode.

While it’s pretty neat if you do exactly that, it turns out to have a bazillion 
corner cases.  (What happens if you paste other stuff in; what happens if you 
delete the pad anchor; what happens if you create new objects on different 
layers; etc.)

So I was considering a different idea which would be more “regular” (from an 
implementation perspective).

Basically it would be a command to explode *all* pads in the current footprint, 
and a command to recombine everything.  The recombine would expand outwards 
from each pad to consume touching copper shapes.  (It might still need a few 
edge cases for net-ties.)

Thoughts?
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Compile issue

[Jeff Young]

A clean build sorted it….


> On 23 Jun 2020, at 15:33, Ian McInerney  wrote:
> 
> The pcb calculator is a kiface (the bitmap 2 component is not though). The 
> Kiface() symbol is defined in `pcb_calculator.cpp`, and that hasn't changed.
> 
> -Ian
> 
> On Tue, Jun 23, 2020 at 3:19 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Did something change regarding how much of common is getting pulled into 
> pcb_calculator?
> 
> I’m getting the following link errors:
> 
> Undefined symbols for architecture x86_64:
>   "Kiface()", referenced from:
>   EDA_BASE_FRAME::config() const in libcommon.a(eda_base_frame.cpp.o)
>   EDA_BASE_FRAME::sys_search() in libcommon.a(eda_base_frame.cpp.o)
>   EDA_BASE_FRAME::help_name() in libcommon.a(eda_base_frame.cpp.o)
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> gmake[2]: *** [pcb_calculator/CMakeFiles/pcb_calculator.dir/build.make:113: 
> pcb_calculator/pcb_calculator.app/Contents/MacOS/pcb_calculator] Error 1
> gmake[1]: *** [CMakeFiles/Makefile2:2954: 
> pcb_calculator/CMakeFiles/pcb_calculator.dir/all] Error 2
> 
> I don’t think pcb_calculator is supposed to have a Kiface()?
> 
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Compile issue

[Jeff Young]

Did something change regarding how much of common is getting pulled into 
pcb_calculator?

I’m getting the following link errors:

Undefined symbols for architecture x86_64:
  "Kiface()", referenced from:
  EDA_BASE_FRAME::config() const in libcommon.a(eda_base_frame.cpp.o)
  EDA_BASE_FRAME::sys_search() in libcommon.a(eda_base_frame.cpp.o)
  EDA_BASE_FRAME::help_name() in libcommon.a(eda_base_frame.cpp.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [pcb_calculator/CMakeFiles/pcb_calculator.dir/build.make:113: 
pcb_calculator/pcb_calculator.app/Contents/MacOS/pcb_calculator] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2954: 
pcb_calculator/CMakeFiles/pcb_calculator.dir/all] Error 2

I don’t think pcb_calculator is supposed to have a Kiface()?

Thanks,
Jeff.___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [Proposed Feature] GerbView - Mapping Gerbers w Altium extensions to KiCad PCB layers

[Jeff Young]

Some answers below:

> On 20 Jun 2020, at 06:39,   wrote:
> 
> I wanted to add a feature to GerbView that relates to exporting a KiCad PCB 
> file from loaded Gerbers.  I often use "Export to PCBNew..." to recreate 
> boards from Gerbers, and many of them involve Gerbers generated by Protel, 
> the progenitor to Altium.  Since Altium (and Protel) use specific file 
> extensions for specfic layers, it's tedious to manually have to set each 
> Gerber layer to the equivalent KiCad PCB layer.  Every time I use "Export to 
> PCBNew..." I keep thinking how handy it would be if GerbView could recognize 
> the file extensions and offer to map them to the appropriate KiCad PCB 
> layers.  
> 
> So, I've created a proof of concept that compiles into my local copy of 
> GerbView, and I have a couple of questions:
> 
> 1 - I made my changes directly in the file select_layers_to_pcb.cpp by adding 
> a new member function to it.  The new function is called from and used within 
> "initDialog()". Is it preferable to create a whole new source file/object for 
> containing the new function (or functions if more are needed), or is it okay 
> to add it directly into this existing file?  Or is this the sort of question 
> best answered when someone is reviewing a submission?

Add it directly.

> 
> 2 - In the KiCad source code, I see a lot of text using the macro "_" to 
> provide string translations, but there are also cases where the "wxT" macro 
> (which I don't believe handles translations) is used instead.  Is there a 
> rule of thumb for when to use "_", or is best to just always use it?

The translation framework can only handle 7-bit ASCII.  So any characters above 
that must be broken out and used with the “wxT” macro (as well as anything you 
don’t want translated, such as file tokens or the like).

> 
> 3 - The source files I've looked at seem to use "ii" as the default integer 
> index in loops, versus the more traditional "i".  Is this a KiCad thing, or 
> something specific to whatever developer(s) worked in the code I've looked at?

It’s pretty random over a larger sample of code.  Use either.

> 
> 4 - The source files I've looked at only use the generic "int" as opposed to 
> using more specific types such as "int32_t" or "int8_t".  Is the use of 
> "stdint.h" not allowed/not encouraged?

I’ll let someone else field this.

Cheers,
Jeff.

> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

It’ll work; there are just more special cases than there are non-special cases. 
 I felt it reduced the SNR, but I’m not against someone else giving it a go.

Are you doing it with the priority system we worked out?

> On 11 Jun 2020, at 21:43, Tomasz Wlostowski  wrote:
> 
> On 11/06/2020 22:27, Jeff Young wrote:
>> I had also originally planned on “compiling” the classic system into 
>> behind-the-scenes rules, but I don’t think that’s going to work out.  It’s 
>> pretty easy to agree on priority of all the edge case (pad override, 
>> footprint overrides, netclasses vs. board settings, etc.), but there’s 
>> nothing uniform about them.
> 
> Hi Jeff,
> 
> I'm actually coding it right now... Why do you think it will not work?
> 
> Tom


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

I had also originally planned on “compiling” the classic system into 
behind-the-scenes rules, but I don’t think that’s going to work out.  It’s 
pretty easy to agree on priority of all the edge case (pad override, footprint 
overrides, netclasses vs. board settings, etc.), but there’s nothing uniform 
about them.

> On 11 Jun 2020, at 19:35, Jon Evans  wrote:
> 
> That has yet to be determined, IIRC.  Jeff expressed a preference for
> keeping around the current "basic rules" GUI we have, but that doesn't
> answer whether those rules are internally represented in the new rules
> engine or via a different path.
> 
> I think it makes sense to express them as part of the new rules engine
> internally so that we don't have two parallel paths of tests.  I don't
> think it's a good idea to express them that way externally (i.e. put
> them in a rules file as a template).
> 
> For one, putting them in the file would break the proposed priority
> system Jeff and I were talking about earlier, where netclass rules
> beat/combine with basic rules and file rules beat netclass rules.
> This would open back up that whole can of worms which I'd rather not
> at this point :)
> 
> So, I think what I'm suggesting is:
> 
> - A way to assign a severity to each of the basic and netclass rules
> (and also adding severity to the custom rules syntax)
> - Decoupling severity from DRC error code
> - Simplifying and consolidating DRC error codes as much as possible,
> since now they will mostly just be categories for grouping things in
> reports.
> 
> I can handle these three things as part of the project settings branch
> I'm working on now.  I do not want to try to tackle moving the basic
> rules over to a new engine as part of that, but it could happen
> afterwards.
> 
> -Jon
> 
> 
> On Thu, Jun 11, 2020 at 2:25 PM Ian McInerney  
> wrote:
>> 
>> I might have missed something, but how are the basic rules being specified? 
>> Are we going to ship them as pre-built selectors that run through the same 
>> DRC engine as the custom rules (so we only have one engine to worry about), 
>> or are they being done differently? It would seem better to ship them as 
>> pre-built selectors and use the same mechanisms for specifying the severity 
>> of them as custom rules would. I think that is also nicer, because it 
>> essentially provides an example rules file.
>> 
>> -Ian
>> 
>> On Thu, Jun 11, 2020 at 6:40 PM Jon Evans  wrote:
>>> 
>>> Yeah I like this.
>>> 
>>> For the basic rules, we could still make it so that each basic rule had 
>>> independent severity while generating common error codes, although that 
>>> increases complexity. It might be better to keep one error code per "basic" 
>>> rule, except for the ones we are already in agreement can be consolidated.
>>> 
>>> Then for net class and custom rules, we can just have the severity be a 
>>> rule property, not an error code property.
>>> 
>>> -Jon
>>> 
>>> On Thu, Jun 11, 2020, 13:36 Ian McInerney  wrote:
>>>> 
>>>> Another example I just thought of (not involving costs): differential pair 
>>>> rules. We could have a category "Trace length mismatch" (or some other 
>>>> name...), and then someone could define rules such that:
>>>> Rule 1) If mismatch > x, flag the "Trace length mismatch" as an error
>>>> Rule 2) If mismatch > y, flag the "Trace length mismatch" as a warning
>>>> 
>>>> When x > y and rule 1 is a higher priority, this can then basically allow 
>>>> for a zone for the DRC to flag the length mismatch where the design will 
>>>> still work, but is not ideal as a warning, and any larger values where the 
>>>> design would fail as an error.
>>>> 
>>>> -Ian
>>>> 
>>>> On Thu, Jun 11, 2020 at 6:25 PM Ian McInerney  
>>>> wrote:
>>>>>> 
>>>>>> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
>>>>>>> 
>>>>>>> Imagine that violating the micro-via min bumps me up a classification 
>>>>>>> but violating the through-via min drops me out of pooling.  There’s a 
>>>>>>> big cost difference between those two.
>>>>>>> 
>>>>> 
>>>>> 
>>>>> This is why I think switching to the severities coming from the rules 
>>>>> would be a better way than defining them by the category of the 
>>>>> violation. By doing that we can limit the need for a lot of categories of 
>>>>> violations. We can for instance have a single code for "Minimum drill 
>>>>> violated", and then have two different rules for the minimum u-via drill 
>>>>> and the minimum through-via drill. Then those rules can treat the code 
>>>>> "Minimum drill violated" as either a warning or an error as they see fit.
>>>>> 
>>>>> -Ian
>>>>> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

Yeah, I want to know if the cost is going to increase (so it’s a warning), but 
I only want an error if it’s going to drop me out of pooling.

> On 11 Jun 2020, at 18:18, Jon Evans  wrote:
> 
> I guess we just think about this differently.  I would not use
> "errors" for anything that is a cost difference.  I would only use
> errors to mean "this can't be built at any cost from my preferred
> manufacturer" or "this design won't work if I try to build it"
> 
> On Thu, Jun 11, 2020 at 1:13 PM Jeff Young  wrote:
>> 
>> Imagine that violating the micro-via min bumps me up a classification but 
>> violating the through-via min drops me out of pooling.  There’s a big cost 
>> difference between those two.
>> 
>> 
>>> On 11 Jun 2020, at 16:47, Jon Evans  wrote:
>>> 
>>> Unconnected copper can also have electrical impacts.  I agree it makes
>>> sense to have some separation between copper and non-copper (not
>>> connected vs. non-connected).
>>> 
>>> I'm okay in general with the idea of trying to have different
>>> severities for production vs. design performance constraints and so
>>> on.  Keeping annulus separate from via diameter is fine.
>>> 
>>> Can you explain a situation where it makes sense to have e.g.
>>> through-via drill be a warning but uVia drill be an error or
>>> vice-versa?  This is what I don't understand.
>>> 
>>> On Thu, Jun 11, 2020 at 11:24 AM Jeff Young  wrote:
>>>> 
>>>> I’d definitely want to set edge clearance apart from other clearance.
>>>> 
>>>> And I’d definitely want to set connected-item clearance (an electrical 
>>>> constraint) apart from non-connected-copper-item clearance (a production 
>>>> constraint).
>>>> 
>>>> And I’d definitely want different violations for via annulus (a production 
>>>> constraint) and via size (possibly just a current/heat constraint).
>>>> 
>>>> I’m still on the fence with throughVia drill vs. uVia drill.  The rest I 
>>>> can agree with.
>>>> 
>>>> Cheers,
>>>> Jeff.
>>>> 
>>>> 
>>>>> On 11 Jun 2020, at 15:56, Jon Evans  wrote:
>>>>> 
>>>>> I think having fewer codes is something to strive for, especially
>>>>> since we are auto-generating severity options from the list of codes.
>>>>> 
>>>>> Having a bunch of severity settings where people wouldn't reasonably
>>>>> need to change them clutters the UI.
>>>>> 
>>>>> Having excessive categorization in the DRC window makes it harder to
>>>>> sort through that information (for me at least).
>>>>> 
>>>>> I don't think we need to be able to set severities independently for
>>>>> each rule in the "classic" system, we just need enough different
>>>>> severity settings to make sense.
>>>>> 
>>>>> For example, going down the classic DRC rules dialog:
>>>>> 
>>>>> Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES
>>>>> Arc/circle and zone fill: these aren't actually DRC checks
>>>>> Copper min clearance: generates DRCE_CLEARANCE
>>>>> Min track width: generates DRCE_WIDTH
>>>>> Min via annulus: generates DRCE_VIA_SIZE
>>>>> Min via diameter: generates DRCE_VIA_SIZE
>>>>> Copper edge clearance: generates DRCE_CLEARANCE
>>>>> Min through hole: generates DRCE_HOLE_SIZE
>>>>> Hole to hole: generates DRCE_HOLE_CLEARANCE
>>>>> uVia diameter: generates DRCE_VIA_SIZE
>>>>> uVia drill: generates DRCE_HOLE_SIZE
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Jun 11, 2020 at 10:42 AM Jeff Young  wrote:
>>>>>> 
>>>>>> What does that buy us?  The only things the error code gives us is a 
>>>>>> string and a severity.   The data storage (items, locations, etc.) is 
>>>>>> already completely orthogonal.
>>>>>> 
>>>>>>> On 11 Jun 2020, at 15:36, Jon Evans  wrote:
>>>>>>> 
>>>>>>> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
>>>>>>> code) taxonomy?
>>>>>>> 
>>>>>>> For example you could have a "classic minimum clearance" severity 
>>>>>>> setting.
>>&

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

Imagine that violating the micro-via min bumps me up a classification but 
violating the through-via min drops me out of pooling.  There’s a big cost 
difference between those two.


> On 11 Jun 2020, at 16:47, Jon Evans  wrote:
> 
> Unconnected copper can also have electrical impacts.  I agree it makes
> sense to have some separation between copper and non-copper (not
> connected vs. non-connected).
> 
> I'm okay in general with the idea of trying to have different
> severities for production vs. design performance constraints and so
> on.  Keeping annulus separate from via diameter is fine.
> 
> Can you explain a situation where it makes sense to have e.g.
> through-via drill be a warning but uVia drill be an error or
> vice-versa?  This is what I don't understand.
> 
> On Thu, Jun 11, 2020 at 11:24 AM Jeff Young  wrote:
>> 
>> I’d definitely want to set edge clearance apart from other clearance.
>> 
>> And I’d definitely want to set connected-item clearance (an electrical 
>> constraint) apart from non-connected-copper-item clearance (a production 
>> constraint).
>> 
>> And I’d definitely want different violations for via annulus (a production 
>> constraint) and via size (possibly just a current/heat constraint).
>> 
>> I’m still on the fence with throughVia drill vs. uVia drill.  The rest I can 
>> agree with.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 11 Jun 2020, at 15:56, Jon Evans  wrote:
>>> 
>>> I think having fewer codes is something to strive for, especially
>>> since we are auto-generating severity options from the list of codes.
>>> 
>>> Having a bunch of severity settings where people wouldn't reasonably
>>> need to change them clutters the UI.
>>> 
>>> Having excessive categorization in the DRC window makes it harder to
>>> sort through that information (for me at least).
>>> 
>>> I don't think we need to be able to set severities independently for
>>> each rule in the "classic" system, we just need enough different
>>> severity settings to make sense.
>>> 
>>> For example, going down the classic DRC rules dialog:
>>> 
>>> Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES
>>> Arc/circle and zone fill: these aren't actually DRC checks
>>> Copper min clearance: generates DRCE_CLEARANCE
>>> Min track width: generates DRCE_WIDTH
>>> Min via annulus: generates DRCE_VIA_SIZE
>>> Min via diameter: generates DRCE_VIA_SIZE
>>> Copper edge clearance: generates DRCE_CLEARANCE
>>> Min through hole: generates DRCE_HOLE_SIZE
>>> Hole to hole: generates DRCE_HOLE_CLEARANCE
>>> uVia diameter: generates DRCE_VIA_SIZE
>>> uVia drill: generates DRCE_HOLE_SIZE
>>> 
>>> 
>>> 
>>> On Thu, Jun 11, 2020 at 10:42 AM Jeff Young  wrote:
>>>> 
>>>> What does that buy us?  The only things the error code gives us is a 
>>>> string and a severity.   The data storage (items, locations, etc.) is 
>>>> already completely orthogonal.
>>>> 
>>>>> On 11 Jun 2020, at 15:36, Jon Evans  wrote:
>>>>> 
>>>>> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
>>>>> code) taxonomy?
>>>>> 
>>>>> For example you could have a "classic minimum clearance" severity setting.
>>>>> This would set the severity of any DRCE_CLEARANCE items generated
>>>>> where the rule source is the classic system.
>>>>> This would replace all of the "X too close to Y" error codes
>>>>> 
>>>>> I think if we did this, the minimum set of error codes would look
>>>>> something like one error code per setting in the Constraints setup
>>>>> dialog.
>>>>> Maybe even smaller than that number of settings, because you can set
>>>>> separate numbers for vias and microvias and I still don't think you
>>>>> need separate severities for those.
>>>>> 
>>>>> On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
>>>>>> 
>>>>>> (But I do like being able to assign a severity to a rule.)
>>>>>> 
>>>>>> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
>>>>>> 
>>>>>> I think we’d still need some sort of taxonomy to put the severities on 
>>>>>> for the “classic” system.
>>>>>> 
>>>>>> On 11 Jun 2020, at 15:01,

Re: [Kicad-developers] How do we envision Pad Stacks?

[Jeff Young]

> On 11 Jun 2020, at 16:16, Wayne Stambaugh  wrote:
> 
> If not, we
> need to create one to make sure we have it well defined before any
> implementation can be done.

Just to be clear: I’m not looking at implementing it.  But I’d need to know 
what direction we were moving in *if* I were to implement a WYSIWYG custom pad 
editor.

If we’re going to allow a shape per layer, then it pretty much needs to be a 
repurposed PCB_BASE_FRAME.  If we’re going to do something like Altium then we 
probably just want a canvas with shape tools and the point editor.___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

I’d definitely want to set edge clearance apart from other clearance.

And I’d definitely want to set connected-item clearance (an electrical 
constraint) apart from non-connected-copper-item clearance (a production 
constraint).

And I’d definitely want different violations for via annulus (a production 
constraint) and via size (possibly just a current/heat constraint).

I’m still on the fence with throughVia drill vs. uVia drill.  The rest I can 
agree with.

Cheers,
Jeff.


> On 11 Jun 2020, at 15:56, Jon Evans  wrote:
> 
> I think having fewer codes is something to strive for, especially
> since we are auto-generating severity options from the list of codes.
> 
> Having a bunch of severity settings where people wouldn't reasonably
> need to change them clutters the UI.
> 
> Having excessive categorization in the DRC window makes it harder to
> sort through that information (for me at least).
> 
> I don't think we need to be able to set severities independently for
> each rule in the "classic" system, we just need enough different
> severity settings to make sense.
> 
> For example, going down the classic DRC rules dialog:
> 
> Allowed features: both checkboxes generate DRCE_ALLOWED_FEATURES
> Arc/circle and zone fill: these aren't actually DRC checks
> Copper min clearance: generates DRCE_CLEARANCE
> Min track width: generates DRCE_WIDTH
> Min via annulus: generates DRCE_VIA_SIZE
> Min via diameter: generates DRCE_VIA_SIZE
> Copper edge clearance: generates DRCE_CLEARANCE
> Min through hole: generates DRCE_HOLE_SIZE
> Hole to hole: generates DRCE_HOLE_CLEARANCE
> uVia diameter: generates DRCE_VIA_SIZE
> uVia drill: generates DRCE_HOLE_SIZE
> 
> 
> 
> On Thu, Jun 11, 2020 at 10:42 AM Jeff Young  wrote:
>> 
>> What does that buy us?  The only things the error code gives us is a string 
>> and a severity.   The data storage (items, locations, etc.) is already 
>> completely orthogonal.
>> 
>>> On 11 Jun 2020, at 15:36, Jon Evans  wrote:
>>> 
>>> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
>>> code) taxonomy?
>>> 
>>> For example you could have a "classic minimum clearance" severity setting.
>>> This would set the severity of any DRCE_CLEARANCE items generated
>>> where the rule source is the classic system.
>>> This would replace all of the "X too close to Y" error codes
>>> 
>>> I think if we did this, the minimum set of error codes would look
>>> something like one error code per setting in the Constraints setup
>>> dialog.
>>> Maybe even smaller than that number of settings, because you can set
>>> separate numbers for vias and microvias and I still don't think you
>>> need separate severities for those.
>>> 
>>> On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
>>>> 
>>>> (But I do like being able to assign a severity to a rule.)
>>>> 
>>>> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
>>>> 
>>>> I think we’d still need some sort of taxonomy to put the severities on for 
>>>> the “classic” system.
>>>> 
>>>> On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
>>>> 
>>>> Why not make the severity attached to the rule being used instead of the 
>>>> error code type. I think being able to say "this rule is very important 
>>>> and should be treated as an error" and "this rule is just a guideline and 
>>>> can be treated as a warning" while they are both the same error code would 
>>>> make more sense.
>>>> 
>>>> -Ian
>>>> 
>>>> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:
>>>>> 
>>>>> The only reasons to have multiple violation error codes is to be able
>>>>> to set a different severity for them, or to be able to filter/sort
>>>>> them.
>>>>> 
>>>>> I can't think of a situation in which I would want to do either of
>>>>> those things for different via types.
>>>>> 
>>>>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  
>>>>> wrote:
>>>>>> 
>>>>>> I was thinking along the same lines.  Wouldn't it make more sense to
>>>>>> define the objects that violate a DRC rule and generate the error
>>>>>> message on the fly rather than adding violation error codes for every
>>>>>> possible error?
>>>>>> 
>>>>>> On 6/11/20 9:26 AM, Jon Evans wrote:
>>

[Kicad-developers] How do we envision Pad Stacks?

[Jeff Young]

I had been assuming that you could define a separate shape for each layer.  
Full flexibility, but time-consuming to edit (even with commands such as “push 
current layer to other layers”).

Most users are looking to route traces on inner layers between tight pads.  
This is commonly done with the definition of a “capture pad”.  The constraint 
on inner layers that have connecting tracks is simply not to have a butt joint 
between the track and the plated hole.  A capture pad is therefore a circular 
pad with an annulus width of the drill wander plus 1 or 2 mils; other capture 
pad shapes get you nothing more.

There were also a few requests for SMD pads on a single inner layer (or perhaps 
multiple) — but importantly not for different shapes on different layers.

So one could imagine allowing the pad shape to be placed on any number of 
layers, and a capture annulus width for any other connected layers.  While it 
doesn’t have same flexibility, it would be a lot easier to edit.

Another possible complication is wanting a different shape for mask (or paste) 
layers.  Is this ever required?

Thoughts?___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

What does that buy us?  The only things the error code gives us is a string and 
a severity.   The data storage (items, locations, etc.) is already completely 
orthogonal.

> On 11 Jun 2020, at 15:36, Jon Evans  wrote:
> 
> But couldn't this taxonomy be separate from the DRC_ITEM (i.e. error
> code) taxonomy?
> 
> For example you could have a "classic minimum clearance" severity setting.
> This would set the severity of any DRCE_CLEARANCE items generated
> where the rule source is the classic system.
> This would replace all of the "X too close to Y" error codes
> 
> I think if we did this, the minimum set of error codes would look
> something like one error code per setting in the Constraints setup
> dialog.
> Maybe even smaller than that number of settings, because you can set
> separate numbers for vias and microvias and I still don't think you
> need separate severities for those.
> 
> On Thu, Jun 11, 2020 at 10:24 AM Jeff Young  wrote:
>> 
>> (But I do like being able to assign a severity to a rule.)
>> 
>> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
>> 
>> I think we’d still need some sort of taxonomy to put the severities on for 
>> the “classic” system.
>> 
>> On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
>> 
>> Why not make the severity attached to the rule being used instead of the 
>> error code type. I think being able to say "this rule is very important and 
>> should be treated as an error" and "this rule is just a guideline and can be 
>> treated as a warning" while they are both the same error code would make 
>> more sense.
>> 
>> -Ian
>> 
>> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  wrote:
>>> 
>>> The only reasons to have multiple violation error codes is to be able
>>> to set a different severity for them, or to be able to filter/sort
>>> them.
>>> 
>>> I can't think of a situation in which I would want to do either of
>>> those things for different via types.
>>> 
>>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  
>>> wrote:
>>>> 
>>>> I was thinking along the same lines.  Wouldn't it make more sense to
>>>> define the objects that violate a DRC rule and generate the error
>>>> message on the fly rather than adding violation error codes for every
>>>> possible error?
>>>> 
>>>> On 6/11/20 9:26 AM, Jon Evans wrote:
>>>>> I think microvias and vias using different technologies means they
>>>>> need different *rules*, not different error codes.
>>>>> 
>>>>> Whether a hole is laser or mechanically drilled, it will have some
>>>>> rules, and those rules could generate an error "hole size is outside
>>>>> allowed range".
>>>>> 
>>>>> You can tell from the affected items whether the hole in question is a
>>>>> via, microvia, blind via, buried via.
>>>>> You can tell from the rule source whether this came from a microvia
>>>>> rule, normal via rule, custom rule, etc.
>>>>> 
>>>>> Why should we have separate violations per via type?  (not separate
>>>>> *rules* but separate violations)  I still don't get the use case.
>>>>> 
>>>>> As mentioned in the last taxonomy discussion, I still think we could
>>>>> get rid of the tons of different "X close to Y" errors and just call
>>>>> it a "clearance error", but I understand that might be more
>>>>> contentious so I'd like to focus for now on just the keepouts and
>>>>> vias.
>>>>> 
>>>>> -Jon
>>>>> 
>>>>> On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  wrote:
>>>>>> 
>>>>>> The “Inside Keepout” issue might be a bad example.  I’d definitely be in 
>>>>>> favour of folding all of those into a single violation because a keepout 
>>>>>> already specifies which types of things are excluded.
>>>>>> 
>>>>>> But other things I’d be less in favour of.  I want a warning about NPTHs 
>>>>>> in courtyards; I don’t want one for PTHs (the former likely has a 
>>>>>> mechanical fixing, the later likely doesn't).
>>>>>> 
>>>>>> While I don’t personally use uVias, I’d certainly think we’d want 
>>>>>> separate violations for their holes (as they’re made with different 
>>>>>> technologies). 

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

(But I do like being able to assign a severity to a rule.)

> On 11 Jun 2020, at 15:22, Jeff Young  wrote:
> 
> I think we’d still need some sort of taxonomy to put the severities on for 
> the “classic” system.
> 
>> On 11 Jun 2020, at 15:01, Ian McInerney > <mailto:ian.s.mciner...@ieee.org>> wrote:
>> 
>> Why not make the severity attached to the rule being used instead of the 
>> error code type. I think being able to say "this rule is very important and 
>> should be treated as an error" and "this rule is just a guideline and can be 
>> treated as a warning" while they are both the same error code would make 
>> more sense.
>> 
>> -Ian
>> 
>> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans > <mailto:j...@craftyjon.com>> wrote:
>> The only reasons to have multiple violation error codes is to be able
>> to set a different severity for them, or to be able to filter/sort
>> them.
>> 
>> I can't think of a situation in which I would want to do either of
>> those things for different via types.
>> 
>> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh > <mailto:stambau...@gmail.com>> wrote:
>> >
>> > I was thinking along the same lines.  Wouldn't it make more sense to
>> > define the objects that violate a DRC rule and generate the error
>> > message on the fly rather than adding violation error codes for every
>> > possible error?
>> >
>> > On 6/11/20 9:26 AM, Jon Evans wrote:
>> > > I think microvias and vias using different technologies means they
>> > > need different *rules*, not different error codes.
>> > >
>> > > Whether a hole is laser or mechanically drilled, it will have some
>> > > rules, and those rules could generate an error "hole size is outside
>> > > allowed range".
>> > >
>> > > You can tell from the affected items whether the hole in question is a
>> > > via, microvia, blind via, buried via.
>> > > You can tell from the rule source whether this came from a microvia
>> > > rule, normal via rule, custom rule, etc.
>> > >
>> > > Why should we have separate violations per via type?  (not separate
>> > > *rules* but separate violations)  I still don't get the use case.
>> > >
>> > > As mentioned in the last taxonomy discussion, I still think we could
>> > > get rid of the tons of different "X close to Y" errors and just call
>> > > it a "clearance error", but I understand that might be more
>> > > contentious so I'd like to focus for now on just the keepouts and
>> > > vias.
>> > >
>> > > -Jon
>> > >
>> > > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young > > > <mailto:j...@rokeby.ie>> wrote:
>> > >>
>> > >> The “Inside Keepout” issue might be a bad example.  I’d definitely be 
>> > >> in favour of folding all of those into a single violation because a 
>> > >> keepout already specifies which types of things are excluded.
>> > >>
>> > >> But other things I’d be less in favour of.  I want a warning about 
>> > >> NPTHs in courtyards; I don’t want one for PTHs (the former likely has a 
>> > >> mechanical fixing, the later likely doesn't).
>> > >>
>> > >> While I don’t personally use uVias, I’d certainly think we’d want 
>> > >> separate violations for their holes (as they’re made with different 
>> > >> technologies).  On the flip side, I’m not sure there’s any value in 
>> > >> distinguishing between throughVia holes and pad holes.
>> > >>
>> > >> But that gives us a different taxonomy for size vs. hole, as the 
>> > >> difference between uVia and throughVia size may not be important.  (We 
>> > >> already have this to some extent as I didn’t bother with separate 
>> > >> annulus violations for via types, although there’s a TODO in the code).
>> > >>
>> > >> This all begs the question “how bad is an uneven taxonomy”?  Is it just 
>> > >> an ivory-tower kind of thing, or will it actually cause confusion?
>> > >>
>> > >> Back to specific instances, I like being able to treat 
>> > >> track-too-close-to-connected-item separately from 
>> > >> track-to-close-to-unconnected-item, but I’m less fussed about the 
>> > >> differences between the type of c

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

I think we’d still need some sort of taxonomy to put the severities on for the 
“classic” system.

> On 11 Jun 2020, at 15:01, Ian McInerney  wrote:
> 
> Why not make the severity attached to the rule being used instead of the 
> error code type. I think being able to say "this rule is very important and 
> should be treated as an error" and "this rule is just a guideline and can be 
> treated as a warning" while they are both the same error code would make more 
> sense.
> 
> -Ian
> 
> On Thu, Jun 11, 2020 at 2:53 PM Jon Evans  <mailto:j...@craftyjon.com>> wrote:
> The only reasons to have multiple violation error codes is to be able
> to set a different severity for them, or to be able to filter/sort
> them.
> 
> I can't think of a situation in which I would want to do either of
> those things for different via types.
> 
> On Thu, Jun 11, 2020 at 9:48 AM Wayne Stambaugh  <mailto:stambau...@gmail.com>> wrote:
> >
> > I was thinking along the same lines.  Wouldn't it make more sense to
> > define the objects that violate a DRC rule and generate the error
> > message on the fly rather than adding violation error codes for every
> > possible error?
> >
> > On 6/11/20 9:26 AM, Jon Evans wrote:
> > > I think microvias and vias using different technologies means they
> > > need different *rules*, not different error codes.
> > >
> > > Whether a hole is laser or mechanically drilled, it will have some
> > > rules, and those rules could generate an error "hole size is outside
> > > allowed range".
> > >
> > > You can tell from the affected items whether the hole in question is a
> > > via, microvia, blind via, buried via.
> > > You can tell from the rule source whether this came from a microvia
> > > rule, normal via rule, custom rule, etc.
> > >
> > > Why should we have separate violations per via type?  (not separate
> > > *rules* but separate violations)  I still don't get the use case.
> > >
> > > As mentioned in the last taxonomy discussion, I still think we could
> > > get rid of the tons of different "X close to Y" errors and just call
> > > it a "clearance error", but I understand that might be more
> > > contentious so I'd like to focus for now on just the keepouts and
> > > vias.
> > >
> > > -Jon
> > >
> > > On Thu, Jun 11, 2020 at 6:51 AM Jeff Young  > > <mailto:j...@rokeby.ie>> wrote:
> > >>
> > >> The “Inside Keepout” issue might be a bad example.  I’d definitely be in 
> > >> favour of folding all of those into a single violation because a keepout 
> > >> already specifies which types of things are excluded.
> > >>
> > >> But other things I’d be less in favour of.  I want a warning about NPTHs 
> > >> in courtyards; I don’t want one for PTHs (the former likely has a 
> > >> mechanical fixing, the later likely doesn't).
> > >>
> > >> While I don’t personally use uVias, I’d certainly think we’d want 
> > >> separate violations for their holes (as they’re made with different 
> > >> technologies).  On the flip side, I’m not sure there’s any value in 
> > >> distinguishing between throughVia holes and pad holes.
> > >>
> > >> But that gives us a different taxonomy for size vs. hole, as the 
> > >> difference between uVia and throughVia size may not be important.  (We 
> > >> already have this to some extent as I didn’t bother with separate 
> > >> annulus violations for via types, although there’s a TODO in the code).
> > >>
> > >> This all begs the question “how bad is an uneven taxonomy”?  Is it just 
> > >> an ivory-tower kind of thing, or will it actually cause confusion?
> > >>
> > >> Back to specific instances, I like being able to treat 
> > >> track-too-close-to-connected-item separately from 
> > >> track-to-close-to-unconnected-item, but I’m less fussed about the 
> > >> differences between the type of connected item (track-to-close-to-via vs 
> > >> track-to-close-to-track).  (For what it’s worth, unconnected items are 
> > >> already grouped as we don’t have separate errors for 
> > >> track-to-close-to-graphics vs track-to-close-to-text.  Yet another bit 
> > >> of unevenness in the existing taxonomy.)
> > >>
> > >> Oddly I find the parallel-tracks vs crossing-tracks useful, but I have 
> > >> no idea w

Re: [Kicad-developers] Granularity of DRC error code

[Jeff Young]

The “Inside Keepout” issue might be a bad example.  I’d definitely be in favour 
of folding all of those into a single violation because a keepout already 
specifies which types of things are excluded.

But other things I’d be less in favour of.  I want a warning about NPTHs in 
courtyards; I don’t want one for PTHs (the former likely has a mechanical 
fixing, the later likely doesn't).

While I don’t personally use uVias, I’d certainly think we’d want separate 
violations for their holes (as they’re made with different technologies).  On 
the flip side, I’m not sure there’s any value in distinguishing between 
throughVia holes and pad holes.

But that gives us a different taxonomy for size vs. hole, as the difference 
between uVia and throughVia size may not be important.  (We already have this 
to some extent as I didn’t bother with separate annulus violations for via 
types, although there’s a TODO in the code).

This all begs the question “how bad is an uneven taxonomy”?  Is it just an 
ivory-tower kind of thing, or will it actually cause confusion?

Back to specific instances, I like being able to treat 
track-too-close-to-connected-item separately from 
track-to-close-to-unconnected-item, but I’m less fussed about the differences 
between the type of connected item (track-to-close-to-via vs 
track-to-close-to-track).  (For what it’s worth, unconnected items are already 
grouped as we don’t have separate errors for track-to-close-to-graphics vs 
track-to-close-to-text.  Yet another bit of unevenness in the existing 
taxonomy.)

Oddly I find the parallel-tracks vs crossing-tracks useful, but I have no idea 
why.  I guess it just gives me a better idea of what I’m looking for on the 
board?

One last note: Greg’s request for specific exclusions is already in the 
nightlies.

Cheers,
Jeff



> On 11 Jun 2020, at 06:19, Greg Smith  wrote:
> 
> I think more grouping in general categories is good. I also think that it 
> would be nice to exclude *specific* DRCs that once a designer checks the 
> error, they can flag it to ignore in the future. The specific check could be 
> identified by a unique id: a hash of specific information, like unique error 
> and objects involved (identified by geometries and properties involved). If 
> anything changes, then the rule violation reappears under a different unique 
> id. I think this would help greatly on near-tapeout activities where sifting 
> over the same DRC errors becomes tedious and prone to missing valid DRC 
> violations in the midst of “designer checked and allowed” ones.
> 
> Greg S.
> 
>> On Jun 10, 2020, at 7:59 PM, Jon Evans  wrote:
>> 
>> Hi all,
>> 
>> A DRC error code is something like "Via inside keepout area", or in
>> the code, DRCE_VIA_INSIDE_KEEPOUT.  It describes a "type" of DRC
>> error.  This type is used for organizing the errors in the DRC report,
>> and more recently, for letting you set a severity
>> (error/warning/ignore) for each code.
>> 
>> Currently we have a lot of DRC violation types, probably because the
>> violation types match up to the underlying code that is doing the
>> checking.  So, we also have a DRCE_MICROVIA_INSIDE_KEEPOUT and
>> DRCE_BBVIA_INSIDE_KEEPOUT, because a lot of KiCad code has separate
>> paths for those three types of vias.
>> 
>> Do people find this useful?  I think it is too specific: I would
>> rather see a single code DRCE_VIA_INSIDE_KEEPOUT to include all types
>> of vias.  I could even see having a single code for any object inside
>> a keepout that isn't supposed to be there.  I can't imagine a
>> situation where I would want to have a via inside a keepout be an
>> error, but a microvia inside a keepout be a warning or an ignore
>> (having the separate error codes means you can have seperate severity
>> settings).  If I wanted to know if a particular DRC error referred to
>> a via or a microvia, I can do that from the linked item information --
>> I don't need a category to tell me that.
>> 
>> What do you think?  Does having a lot of very specific error codes
>> help your workflow?  Would you miss these categories if some of them
>> got consolidated like the example I gave?  If so, are there other
>> changes we could make (or features we could add) that would make it
>> easier to deal with having less specific error codes?
>> 
>> Thanks,
>> Jon
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : 

Re: [Kicad-developers] Build error: Now compiles for me.

[Jeff Young]

Thanks, Dino!

> On 10 Jun 2020, at 14:18, Dino Ghilardi  wrote:
> 
> No more build error on my machine (gcc 6.3.0)
> 
> 
> Cheers,
> Dino.
> 
> On 10/06/20 14:52, Jeff Young wrote:
>> I’ve merged an attempted fix.  (Of course the previous one compiled fine on 
>> CLang too, so I’m not 100% confident in it -- but it seem to fit the error 
>> GCC was generating.)
>>> On 10 Jun 2020, at 12:59, Wayne Stambaugh  wrote:
>>> 
>>> I forgot to mention, lead devs please do not commit any new code until
>>> this gets fixed.
>>> 
>>> On 6/10/20 7:14 AM, Wayne Stambaugh wrote:
>>>> As of commit 4138c8554 I'm getting the following build error on linux.
>>>> 
>>>> /home/wayne/src/kicad-trunk/pcbnew/drc/drc_rule_parser.cpp: In
>>>> constructor ‘DRC_RULES_PARSER::DRC_RULES_PARSER(BOARD*, const wxString&,
>>>> const wxString&)’:
>>>> /home/wayne/src/kicad-trunk/pcbnew/drc/drc_rule_parser.cpp:36:26: error:
>>>> invalid user-defined conversion from ‘const wxString’ to ‘FILE*’ {aka
>>>> ‘_IO_FILE*’} [-fpermissive]
>>>>   36 | DRC_RULES_LEXER( aSource, aSourceDescr ),
>>>>  |  ^~~
>>>> In file included from /usr/include/wx-3.0/wx/memory.h:15,
>>>> from /usr/include/wx-3.0/wx/object.h:19,
>>>> from /usr/include/wx-3.0/wx/wx.h:15,
>>>> from /home/wayne/src/kicad-trunk/include/fctsys.h:28,
>>>> from
>>>> /home/wayne/src/kicad-trunk/pcbnew/drc/drc_rule_parser.cpp:25:
>>>> /usr/include/wx-3.0/wx/string.h:1629:5: note: candidate is:
>>>> ‘wxString::operator const void*() const’ 
>>>> 1629 | operator const void*() const { return c_str(); }
>>>>  | ^~~~
>>>> /usr/include/wx-3.0/wx/string.h:1629:5: note:   no known conversion from
>>>> ‘const void*’ to ‘FILE*’ {aka ‘_IO_FILE*’}
>>>> In file included from
>>>> /home/wayne/src/kicad-trunk/pcbnew/./drc/drc_rule_parser.h:31,
>>>> from
>>>> /home/wayne/src/kicad-trunk/pcbnew/drc/drc_rule_parser.cpp:26:
>>>> /home/wayne/build/kicad/trunk-debug-gtk3-python/common/drc_rules_lexer.h:108:28:
>>>> note:   initializing argument 1 of
>>>> ‘DRC_RULES_LEXER::DRC_RULES_LEXER(FILE*, const wxString&)’
>>>>  108 | DRC_RULES_LEXER( FILE* aFile, const wxString& aFilename ) :
>>>>  |  ~~^
>>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Build error

[Jeff Young]

I’ve merged an attempted fix.  (Of course the previous one compiled fine on 
CLang too, so I’m not 100% confident in it -- but it seem to fit the error GCC 
was generating.)

> On 10 Jun 2020, at 12:59, Wayne Stambaugh  wrote:
> 
> I forgot to mention, lead devs please do not commit any new code until
> this gets fixed.
> 
> On 6/10/20 7:14 AM, Wayne Stambaugh wrote:
>> As of commit 4138c8554 I'm getting the following build error on linux.
>> 
>> /home/wayne/src/kicad-trunk/pcbnew/drc/drc_rule_parser.cpp: In
>> constructor ‘DRC_RULES_PARSER::DRC_RULES_PARSER(BOARD*, const wxString&,
>> const wxString&)’:
>> /home/wayne/src/kicad-trunk/pcbnew/drc/drc_rule_parser.cpp:36:26: error:
>> invalid user-defined conversion from ‘const wxString’ to ‘FILE*’ {aka
>> ‘_IO_FILE*’} [-fpermissive]
>>   36 | DRC_RULES_LEXER( aSource, aSourceDescr ),
>>  |  ^~~
>> In file included from /usr/include/wx-3.0/wx/memory.h:15,
>> from /usr/include/wx-3.0/wx/object.h:19,
>> from /usr/include/wx-3.0/wx/wx.h:15,
>> from /home/wayne/src/kicad-trunk/include/fctsys.h:28,
>> from
>> /home/wayne/src/kicad-trunk/pcbnew/drc/drc_rule_parser.cpp:25:
>> /usr/include/wx-3.0/wx/string.h:1629:5: note: candidate is:
>> ‘wxString::operator const void*() const’ 
>> 1629 | operator const void*() const { return c_str(); }
>>  | ^~~~
>> /usr/include/wx-3.0/wx/string.h:1629:5: note:   no known conversion from
>> ‘const void*’ to ‘FILE*’ {aka ‘_IO_FILE*’}
>> In file included from
>> /home/wayne/src/kicad-trunk/pcbnew/./drc/drc_rule_parser.h:31,
>> from
>> /home/wayne/src/kicad-trunk/pcbnew/drc/drc_rule_parser.cpp:26:
>> /home/wayne/build/kicad/trunk-debug-gtk3-python/common/drc_rules_lexer.h:108:28:
>> note:   initializing argument 1 of
>> ‘DRC_RULES_LEXER::DRC_RULES_LEXER(FILE*, const wxString&)’
>>  108 | DRC_RULES_LEXER( FILE* aFile, const wxString& aFilename ) :
>>  |  ~~^
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

We’ve seen something like that DRC error before.  I think it was because the 
two items (the reported item and the correct item) had the same UUID.  Can you 
check to see if that’s the case here?

Thanks,
Jeff.

> On 4 Jun 2020, at 13:59, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I was using github instead of gitlab, this lags gitlab by a day it seems.
> The problem fixed with ae852e17f987b77e2acf141285edbbbdaf27548f.
> 
> I am not able to reproduce the overflow, but it seems it might be
> something else. The attached project does contain a DRC error, but the
> wrong pads are identified. The actual error is in the middle of the board,
> where Net-(R4-Pad2) and Net-(R1-Pad2) are too close. The reported error
> is between Net-(C2-Pad1) and Net-(C1-Pad2), the location of the error
> arrows are correct however. The violated constraint is also correct.
> 
> regards,
> 
> Mark
> 
> Jeff Young  wrote:
> 
>   Hi Mark,
>   
>   That???s 6 change-lists too early for the fix.  You need at least 
> d2cd4de280353b02ab66dab8e22e8da88415dc13.
>   
>   Cheers,
>   Jeff.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

That’s 6 change-lists too early for the fix.  You need at least 
d2cd4de280353b02ab66dab8e22e8da88415dc13.

Cheers,
Jeff.

> On 4 Jun 2020, at 10:13, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I just tried version 9ff09aa784551264e89350368f61ed6b35266f7a, but
> it still fails. I tells me that it requires 1.3mm clearance, but both
> the hole and the track are in the "Net-(C1-Pad1)" netclass, which should
> only require 0.25mm. The plane clearances are as expected.
> 
> With this version I can fix the problem by changing the drc file to
> remove the default clearance of the netclass. So what I have now is:
> 
> 
> (selector (match_netclass "Net-(C1-Pad1)") (rule "1.3mm")) #  the "default" 
> rule
> (selector (match_netclass "Net-(C1-Pad1)") (match_netclass "Net-(C1-Pad1)") 
> (rule "Default"))
> 
> 
> If the "default" rule is removed everything is OK. Now obviously I can
> do this, but it has consequences for the number of drc-rules I need. For
> the big design I can constrain with 451 lines when I can use a default,
> if that's not possible I need 7437 lines.
> 
> There is also an overflow at some point. Two pads, one at (364, 218.5)
> and the other at (124.45, 50.4) are only 4.351mm apart according to the
> DRC check.  I'll create a testcase if you want me to.
> 
> regards,
> 
> Mark.
> 
> Jeff Young  wrote:
> 
>   Hi Mark,
>   
>   The hole clearance logic never got updated to pass both items (the 
> track and the hole).  It should work now.
>   
>   Cheers,
>   Jeff.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

The hole clearance logic never got updated to pass both items (the track and 
the hole).  It should work now.

Cheers,
Jeff.


> On 2 Jun 2020, at 22:27, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I've tried my big board and the clearances seem to work OK for planes.
> I still have to compare the gerbers and check if they are exactly as
> expected.
> 
> However I get a lot of clearance error on holes in the board, and am
> unable to solve this. I've attached an example project. There is a
> plane which has the correct clearance, there is a track in this plane
> as well. I don't expect this track to give a DRC error, but it does.
> 
> I've tried (match_type pth) and also hole but I cannot make the error
> disappear. Any help would be welcome.
> 
> regards,
> 
> Mark.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Mark,

Yes, last selector.  Order of rules (at present) doesn’t matter.

No, we were not planning on keeping the separation, although we did discuss 
supporting named conditions.

Cheers,
Jeff.

> On 2 Jun 2020, at 13:00, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I assume in that case the last selector is applied and not the last
> rule, correct?
> 
> To be honest I prefer the selector/rule seperation, is that going to stay?
> 
> regards,
> 
> Mark.
> 
> Jeff Young  wrote:
> 
>   Hi Mark,
>   
>   The condition syntax was just a preview.  It???s not implemented yet.
>   
>   You???ll need to use the selector syntax for now.
>   
>   So, for instance:
>   
>   (selector (match_netclass "Net-(C1-Pad1)") (match_netclass 
> "Net-(C1-Pad1)???) (rule ???Min_Net-(C1-Pad1)")
>   
>   Cheers,
>   Jeff.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

The condition syntax was just a preview.  It’s not implemented yet.

You’ll need to use the selector syntax for now.

So, for instance:

(selector (match_netclass "Net-(C1-Pad1)") (match_netclass "Net-(C1-Pad1)”) 
(rule “Min_Net-(C1-Pad1)")

Cheers,
Jeff.

> On 2 Jun 2020, at 11:05, mdoes...@xs4all.nl wrote:
> 
> I just tested the old simple testcase, the new rule file is:
> 
> 
> (rule "Max_Net-(C1-Pad1)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(C1-Pad1)"))
> (rule "Min_Net-(C1-Pad1)"
>(constraint clearance (min 0.25mm))
>(condition "A.netclass == Net-(C1-Pad1) && B.netclass == 
> Net-(C1-Pad1)"))
> (rule "Max_Net-(R1-Pad2)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(R1-Pad2)"))
> (rule "Min_Net-(R1-Pad2)"
>(constraint clearance (min 0.25mm))
>(condition "A.netclass == Net-(R1-Pad2) && B.netclass == 
> Net-(R1-Pad2)"))
> (rule "Max_Net-(R4-Pad2)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(R4-Pad2)"))
> (rule "Min_Net-(R4-Pad2)"
>(constraint clearance (min 0.25mm))
>(condition "A.netclass == Net-(R4-Pad2) && B.netclass == 
> Net-(R4-Pad2)"))
> (rule "Specific_Net-(C1-Pad1)__Net-(R1-Pad2)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(C1-Pad1) && B.netclass == 
> Net-(R1-Pad2)"))
> (rule "Specific_Net-(C1-Pad1)__Net-(R4-Pad2)"
>(constraint clearance (min 1.3mm))
>(condition "A.netclass == Net-(C1-Pad1) && B.netclass == 
> Net-(R4-Pad2)"))
> 
> 
> I'm probably completely missing the point, but everything seems to be
> constrained at 0.25mm clearance.
> 
> 
> regards,
> 
> Mark.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

Rules are now evaluated in order: last one which matches wins.

Most of the time you won’t need priority, but if you do have two rules that 
match the same things, put the higher priority one later in the rules file.

Cheers,
Jeff.


> On 2 Jun 2020, at 09:41, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I tried to give the big board a new attempt, previously a lot of strange
> things happened which I quite couldn't figure out. I noticed the priority
> was no longer accepted. Can you give a quick update on the intended way
> the rules are supposed to be used?
> 
> regards,
> 
> Mark.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Poll: how does autocomplete filter?

[Jeff Young]

Huh, appears things are pretty uniform.  I wonder where the Scintilla folks 
came up with their model?

Anyway, thanks.  I’ll bend the Scintilla engine to our wishes. ;)

Cheers,
Jeff.

> On 30 May 2020, at 17:11, Ian McInerney  wrote:
> 
> I am used to autocomplete tools only showing those that match the current 
> search query. That would also be consistent with the way our hotkey search 
> control matches when typed as well.
> 
> -Ian
> 
> On Sat, May 30, 2020 at 4:04 PM Eeli Kaikkonen  <mailto:eeli.kaikko...@gmail.com>> wrote:
> Definitely leaving only matching items and removing others.
> 
> Eeli Kaikkonen
> 
> 
> On Sat, May 30, 2020 at 5:50 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> One strategy is to highlight the first match as you type, but leave the menu 
> entries unchanged.
> 
> Another strategy is to remove the un-matched entries (so the selected on is 
> always at the top).
> 
> I’m used to CLion, which removes, but the Scintilla Editor’s default is to 
> just highlight.
> 
> Which is more common?  Which are you used to?  Which do you like better?
> 
> Cheers,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Poll: how does autocomplete filter?

[Jeff Young]

One strategy is to highlight the first match as you type, but leave the menu 
entries unchanged.

Another strategy is to remove the un-matched entries (so the selected on is 
always at the top).

I’m used to CLion, which removes, but the Scintilla Editor’s default is to just 
highlight.

Which is more common?  Which are you used to?  Which do you like better?

Cheers,
Jeff.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Configure dialog shim in eeschema to be modeless instead of modal.

[Jeff Young]

No.  The dialogs would all have to be beefed up to listen to changes in the 
document and update their values, pointers, etc.

We do have some work in progress for an Inspector, which would be modeless and 
show the selected items’ properties.

Cheers,
Jeff.


> On 29 May 2020, at 19:31, Andrea Martí  wrote:
> 
> Hi,
> Is there any way to configure the file “dialogshim” in eeschema to be 
> modeless instead of modal? 
> Cheers, 
> Andrea
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

There are 4 or 5 bug fixes after the hash you’re using.  The one I just pushed 
is most likely to address your pad-to-pad DRC issue.

Cheers,
Jeff.


> On 21 May 2020, at 20:53, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> That works fine on the plane, but when I do a DRC check if fails on the
> pads of C1 and C2. I'm using cec857c0f49d4fd984a4095896306ff5d3a5930e,
> not sure if you changed anything after that.
> 
> To me the syntax is just fine, as long as these things can be specified
> correcly.
> 
> regards,
> 
> Mark.
> 
> 
> 
> Jeff Young  wrote:
> 
>   Hi Mark,
>   
>   That???s expected.  The effective clearance is the largest specified in 
> all rules that match.  Since both selectors match in the same-net case, the 
> effective clearance is 1.3mm.
>   
>   There is a ???relaxed??? token to address this, which allows a 
> higher-priority rule to relax a constraint.
>   
>   So try:
>   
>   (version 1)
>   (selector (priority 150) (match_netclass "Net-(C1-Pad1)") 
> (match_netclass "Net-(C1-Pad1)") (rule "0.2mm"))
>   (selector (priority 100) (match_netclass "Net-(C1-Pad1)") (rule 
> "1.3mm"))
>   (rule "1.3mm" (clearance 1.3))
>   (rule "0.2mm" (clearance relaxed 0.2))
>   
>   It???s worth noting that we???re not very happy with this syntax and 
> are working on some other ways to address it.
>   
>   Cheers,
>   Jeff.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

That’s expected.  The effective clearance is the largest specified in all rules 
that match.  Since both selectors match in the same-net case, the effective 
clearance is 1.3mm.

There is a “relaxed” token to address this, which allows a higher-priority rule 
to relax a constraint.

So try:

(version 1)
(selector (priority 150) (match_netclass "Net-(C1-Pad1)") (match_netclass 
"Net-(C1-Pad1)") (rule "0.2mm"))
(selector (priority 100) (match_netclass "Net-(C1-Pad1)") (rule "1.3mm"))
(rule "1.3mm" (clearance 1.3))
(rule "0.2mm" (clearance relaxed 0.2))

It’s worth noting that we’re not very happy with this syntax and are working on 
some other ways to address it.

Cheers,
Jeff.


> On 21 May 2020, at 19:55, mdoes...@xs4all.nl wrote:
> 
> Hello Jeff,
> 
> I've tried to get the big board working, but I'm unable to set a default
> clearance on a netclass. What I want to achieve is that a certain netclass
> has a small clearance (0.2mm) with itself, but a large clearance to
> other netclasses, for example 5.5mm. For some netclasses I would like
> to set a smaller clearance. I've tried the following approach (with and 
> without
> priority, and in reverse priority). But in this case it always uses the 1.3mm,
> also within the netclass itself. I've attached the test project.
> 
> 
> (version 1)
> (selector (priority 100) (match_netclass "Net-(C1-Pad1)") (match_netclass 
> "Net-(C1-Pad1)") (rule "0.2mm"))
> (selector (priority 150) (match_netclass "Net-(C1-Pad1)") (rule "1.3mm"))
> (rule "1.3mm" (clearance 1.3))
> (rule "0.2mm" (clearance 0.2))
> 
> 
> regards,
> 
> Mark.
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

While the prototype is selector-based the “real” implementation is likely to be 
expression-based, so you’ll be able to say something like:

(rule “my special rule” … (condition “A.net <http://a.net/> == B.net 
<http://b.net/>”))

Cheers,
Jeff.


> On 21 May 2020, at 12:19, James Jackson  wrote:
> 
> Hi Jeff,
> 
> The background is that I'm looking at a ruleset which has different rules 
> depending on whether two neighbouring vias are in the same, or different, 
> nets. Running the risk of 'feature creep', of course, I think the constraints 
> can indeed be met by what is there, but I suppose my question (and apologies 
> for think out loud - the nature of the beast!) can be considered as 'Can a 
> rule be matched based on whether the two objects are in the same, or 
> different, nets?' Of course, this could be done by matching all permutations 
> and combinations of nets, but that would become a combinatorial nightmare!
> 
> Yours,
> James.
> 
> 
> On Thu, May 21, 2020 at 11:29 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Hi James,
> 
> It sounds like you’re looking for hole-to-hole min.  That’s in the existing 
> constraints system in 5.99; you don’t need rules for that.
> 
> Or does your hole-to-hole min depend on the specific via, specific netclass, 
> or something else?  (The current hole-to-hole min is board-wide.)
> 
> Cheers,
> Jeff
> 
> 
>> On 21 May 2020, at 10:54, James Jackson > <mailto:james.a.f.jackso...@gmail.com>> wrote:
>> 
>> Hi Jeff,
>> 
>> Many thanks for this - looks very powerful, and when it gets hooked in to 
>> the PNS router will be killer. An issue I'm currently grappling with a 
>> variety of rules considering placements around vias. Some rules require a 
>> distance measured from the outside of the annular ring to a track (or 
>> another annular ring outer edge), and some from the outside of a hole (i.e. 
>> the inside of the annular ring) to the nearest other outside edge of a hole. 
>> I suspect the former is achieved with what is currently there, but is the 
>> latter possible? It's essentially a question of where via-to-via 
>> measurements are made.
>> 
>> Thanks,
>> James.
>> 
>> 
>> 
>> On Sat, May 16, 2020 at 4:44 PM Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> I’ve just merged a possible implementation of the DRC rules.  I’d like to 
>> get some feedback on it, and also some testing.  (Because the rules support 
>> such a wide range of possibilities it’s going to need a good deal of 
>> testing.)
>> 
>> For now, it picks up DRC rules from a file named “drc-rules” in the project 
>> directory.
>> 
>> There’s no GUI editor at present: use a text editor.
>> 
>> Grammar is s-expr.  It generally follows the ideas set down here:
>> 
>> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>>  
>> <https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU>
>> 
>> with one major exception: I found the select-a-single-rule didn’t pan out.  
>> You have to duplicate too much stuff in each rule for that.
>> 
>> Also, because the DRC engine (and zone filler) don’t currently support 
>> min/opt/max the prototype implements min with Seth’s “relaxed” option.
>> 
>> Top level is a list; first expression must be (version x) followed by any 
>> number of (selector…) and (rule…) expressions.
>> /*
>>  * Match tokens:
>>  * match_netclass
>>  * match_type
>>  * match_layer
>>  * match_all
>>  * match_area  (not yet implemented with the exception of “$board”, 
>> which matches everything)
>>  *
>>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>>  *
>>  * (selector (match_netclass "HV") (rule "HV_internal"))
>>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
>> "HV_external"))
>>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
>> "HV_external"))
>>  *
>>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "F_Cu") (rule "HV2HV_external"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "B_Cu") (rule "HV2HV_external"))
>>  *
>>  *   TODO: pads for 

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi James,

It sounds like you’re looking for hole-to-hole min.  That’s in the existing 
constraints system in 5.99; you don’t need rules for that.

Or does your hole-to-hole min depend on the specific via, specific netclass, or 
something else?  (The current hole-to-hole min is board-wide.)

Cheers,
Jeff


> On 21 May 2020, at 10:54, James Jackson  wrote:
> 
> Hi Jeff,
> 
> Many thanks for this - looks very powerful, and when it gets hooked in to the 
> PNS router will be killer. An issue I'm currently grappling with a variety of 
> rules considering placements around vias. Some rules require a distance 
> measured from the outside of the annular ring to a track (or another annular 
> ring outer edge), and some from the outside of a hole (i.e. the inside of the 
> annular ring) to the nearest other outside edge of a hole. I suspect the 
> former is achieved with what is currently there, but is the latter possible? 
> It's essentially a question of where via-to-via measurements are made.
> 
> Thanks,
> James.
> 
> 
> 
> On Sat, May 16, 2020 at 4:44 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> I’ve just merged a possible implementation of the DRC rules.  I’d like to get 
> some feedback on it, and also some testing.  (Because the rules support such 
> a wide range of possibilities it’s going to need a good deal of testing.)
> 
> For now, it picks up DRC rules from a file named “drc-rules” in the project 
> directory.
> 
> There’s no GUI editor at present: use a text editor.
> 
> Grammar is s-expr.  It generally follows the ideas set down here:
> 
> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>  
> <https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU>
> 
> with one major exception: I found the select-a-single-rule didn’t pan out.  
> You have to duplicate too much stuff in each rule for that.
> 
> Also, because the DRC engine (and zone filler) don’t currently support 
> min/opt/max the prototype implements min with Seth’s “relaxed” option.
> 
> Top level is a list; first expression must be (version x) followed by any 
> number of (selector…) and (rule…) expressions.
> /*
>  * Match tokens:
>  * match_netclass
>  * match_type
>  * match_layer
>  * match_all
>  * match_area  (not yet implemented with the exception of “$board”, which 
> matches everything)
>  *
>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>  *
>  * (selector (match_netclass "HV") (rule "HV_internal"))
>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
> "HV_external"))
>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
> "HV_external"))
>  *
>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "F_Cu") (rule "HV2HV_external"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "B_Cu") (rule "HV2HV_external"))
>  *
>  *   TODO: pads for connector pins or wire pads have even larger required 
> creepage clearances.  How to encode?
>  *   User attributes on parent footprint?
>  *
>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
> "HV") (match_type "pad") (rule "pad2PadHV"))
>  *
>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
> "neckdown"))
>  *
>  * Type tokens:
>  * track
>  * via
>  * micro_via
>  * blind_via
>  * pad
>  * zone
>  * text
>  * graphic
>  * board_edge
>  * hole
>  * npth
>  * pth
>  *
>  * Rule tokens:
>  * allow  (not yet implemented)
>  * clearance
>  * annulus_width
>  * track_width
>  * hole
>  *
>  * Rule modifiers:
>  * relaxed
>  *
>  * (rule "HV" (clearance 200) (priority 200))
>  * (rule "HV_external" (clearance 400) (priority 200))
>  * (rule "HV2HV" (clearance 200) (priority 200))
>  * (rule "HV2HV_external" (clearance 500) (priority 200))
>  * (rule "pad2padHV" (clearance 500) (priority 200))
>  *
>  * (rule "signal" (clearance 20))   // implied 
> priority of 1
>  * (rule "neckdown" (clearance relaxed 15) (priority 2))
>  *
>  * (rule "allowMicro

Re: [Kicad-developers] Requesting maintainership for KiCad manifest on flathub.org

[Jeff Young]

Awesome!  Welcome on board, Johannes.

> On 18 May 2020, at 21:42, Jon Evans  wrote:
> 
> Hi Johannes,
> 
> Thank you for offering to take on maintenance of the flathub package.
> We are happy to have your help with this, and as far as I know none of
> the other lead developers was planning on taking it on.
> 
> Please feel free to reach out here if you run into any challenges with
> fixing the packaging issues.  I'm not sure how much experience any
> of us have with flatpak, but we can do our best to help figure them out.
> 
> Best,
> Jon
> 
> On Mon, May 18, 2020 at 4:33 PM Johannes Maibaum  > wrote:
> Wow, that was quick. I got added as a collaborator.
> 
> And I have just merged the update to v5.1.6 on flathub. This should hit
> flatpak users as soon as some build machine does the job. It will still
> lack all of the open issues, like no Python scripting support, no docs,
> among a few other things), but I will start tackling them during the
> next few days.
> 
> Let me just repeat in case I wasn't getting through my point before: If
> anyone from the core team wants to maintain 
> https://github.com/flathub/org.kicad_pcb.KiCad 
>  please let me know.
> 
> Apart from that I will try doing my best as flatpak packager from now
> on.
> 
> Johannes
> 
> Am Montag, den 18.05.2020, 22:16 +0200 schrieb Johannes Maibaum:
> > Am Montag, den 18.05.2020, 19:35 +0200 schrieb Nick Østergaard:
> > > Yeah, hence there are probably no one here that can give you
> > > maintainer ship, unfortunately. :/
> > 
> > My original intent for asking here was not asking someone on this list
> > to give me maintainer rights, but rather if somebody from the core
> > packagers/devs would be wanting to take over the flathub
> > maintainership
> > themselves.
> > 
> > Anyhow, I have just asked over on flathub [1] if they would be giving
> > me
> > maintainership rights. Let's see what comes out of this.
> > 
> > Johannes
> > 
> > [1]: https://github.com/flathub/flathub/issues/1527 
> > 
> > 
> > > On Sat, 16 May 2020 at 16:10, Johannes Maibaum  > > >
> > > wrote:
> > > > Hi Nick,
> > > > 
> > > > Am Samstag, den 16.05.2020, 15:50 +0200 schrieb Nick Østergaard:
> > > > 
> > > > I am not aware of who the maintainer of the flatpak is, nor do I
> > > > think he may follow this list closely.
> > > > 
> > > > 
> > > > From what I can say, so far the flatpak has been maintained by
> > > > whoever sent in a PR, and it was updated whenever one of the main
> > > > flathub maintainers found time to review the PR.
> > > > 
> > > > Johannes
> > > > 
> > > > 
> > > > But it would certanly be good to get the package updated to be on
> > > > part with other packages.
> > > > 
> > > > Nick
> > > > 
> > > > lør. 16. maj 2020 12.27 skrev Johannes Maibaum  > > > 
> > > > >:
> > > > 
> > > > Hello KiCad team,
> > > > 
> > > > during the past months, I have been updating the KiCad flatpak on
> > > > flathub.org  from time to time, via PRs to
> > > > https://github.com/flathub/org.kicad_pcb.KiCad 
> > > >  (I am preparing the
> > > > update to KiCad 5.1.6 right now as well).
> > > > 
> > > > There are a few pending issues with the current flatpak build
> > > > manifest
> > > > for KiCad which I'd like to address: Activating Python scripting
> > > > support, adding the docs, and generally updating various
> > > > dependencies
> > > > would be my next steps.
> > > > 
> > > > I was recently being asked by another user if I would like to
> > > > request
> > > > the maintainership of the KiCad manifest on flathub, and I am now
> > > > contemplating to do so. But, since I did only contribute a few
> > > > tiny-
> > > > tiny
> > > > things to KiCad in the past, I wanted to ask the core
> > > > packagers/developers first, if anyone else would take over the
> > > > maintainership instead?
> > > > 
> > > > 
> > > > Cheers,
> > > > Johannes
> > > > ___
> > > > Mailing list: https://launchpad.net/~kicad-developers 
> > > > 
> > > > Post to : kicad-developers@lists.launchpad.net 
> > > > 
> > > > Unsubscribe : https://launchpad.net/~kicad-developers 
> > > > 
> > > > More help   : https://help.launchpad.net/ListHelp 
> > > > 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : 

Re: [Kicad-developers] DRC rules

[Jeff Young]

Congrats on the first bug!

Actually 4 separate ones: the caching mechanism was causing the rules to not be 
loaded when the board was read, the zone cutout stuff wasn’t fully hooked up to 
the new rules engine, there’s no "Net-(C1-Pad2)" netclass in the document (only 
"Net-(C1-Pad1)”), and the code responded poorly to failing to find a net 
(putting subsequent nets off-by-one).

The third one is yours. ;)

Fixes for the other three are now in master (if you build your own); otherwise 
you can get them from tonight’s nightly.

Cheers,
Jeff.

> On 18 May 2020, at 12:01, mdoes...@xs4all.nl wrote:
> 
> Sorry, forgot to attach the project.
> 
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

Hi Mark,

Clearances are in mm, so your clearances are *really* big.  At a guess I’d say 
all the clearances are overflow when we multiply them by mm-to-nm, but I’d 
think that would give random results not no results.

You shouldn’t need to set a priority unless you’re authoring a “relaxed” 
constraint (for instance, spacing can be decreased near a BGA).  But in any 
case (priority x) goes in the selector, not the rule.

I see some lines of the form: (match_netclass "Net-(R79-Pad2)”).  Did you 
create netclass to match the net names, or are you trying to match against a 
specific net?  (The later isn’t implemented, although maybe it needs to be.)

Let me know how it goes with smaller clearances.  If it still doesn’t work I 
may need a copy of your project to debug.

Cheers,
Jeff.


> On 18 May 2020, at 10:18, mdoes...@xs4all.nl wrote:
> 
> I've just tested this on a design and the drc-rules is read, which I
> know because if I don't add "(version 1)" at the first line I get an
> error message. Other than that I doesn't seem to do anything.
> 
> I tried to add "(priority 100)" to the rules, but that is refused when
> reading the drc file. It's also not clear to me what the clearance
> dimension is, so I assumed nanometers.
> 
> I've been using a hack to get clearance rules working for some time, so
> the design is already pretty large and uses 209 different netclasses. I
> did a clean built of 0658d297e528616e233b4074c27f1bdcb870dede,created
> drc-rules and edited the pcb file to create all the netclasses. I then
> loaded the board and rebuilt the planes, but all the rules seem to
> be ignored. I've attached the drc-rules file for reference.
> 
> regards,
> 
> Mark
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC rules

[Jeff Young]

I got tired of my text editor not highlighting matching parens so there’s now a 
basic rule editor in Board Setup > Design Rules > Rules.

> On 16 May 2020, at 17:02, Jon Evans  wrote:
> 
> Thanks Jeff, this is awesome.  I look forward to trying it out.
> 
> On Sat, May 16, 2020 at 12:00 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Here’s a really dumb test file just so you can get an idea of what it looks 
> like:
> 
> (version 1)
> (selector (match_netclass "Default") (rule "Big Gap"))
> (selector (match_type track) (rule "Big Gap"))
> (rule "Big Gap" (clearance 1.5))
> (selector (match_type blind_via) (rule "Big Hole"))
> (rule "Big Hole" (hole 2))
> (rule "Small Edge" (clearance 2))
> (rule "Big Edge" (clearance 3))
> (selector (match_type board_edge) (rule "Small Edge"))
> (selector (match_layer "In1.Cu") (match_type board_edge) (rule "Big Edge") 
> (priority 2))
> 
> 
>> On 16 May 2020, at 16:43, Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> 
>> I’ve just merged a possible implementation of the DRC rules.  I’d like to 
>> get some feedback on it, and also some testing.  (Because the rules support 
>> such a wide range of possibilities it’s going to need a good deal of 
>> testing.)
>> 
>> For now, it picks up DRC rules from a file named “drc-rules” in the project 
>> directory.
>> 
>> There’s no GUI editor at present: use a text editor.
>> 
>> Grammar is s-expr.  It generally follows the ideas set down here:
>> 
>> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>>  
>> <https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU>
>> 
>> with one major exception: I found the select-a-single-rule didn’t pan out.  
>> You have to duplicate too much stuff in each rule for that.
>> 
>> Also, because the DRC engine (and zone filler) don’t currently support 
>> min/opt/max the prototype implements min with Seth’s “relaxed” option.
>> 
>> Top level is a list; first expression must be (version x) followed by any 
>> number of (selector…) and (rule…) expressions.
>> /*
>>  * Match tokens:
>>  * match_netclass
>>  * match_type
>>  * match_layer
>>  * match_all
>>  * match_area  (not yet implemented with the exception of “$board”, 
>> which matches everything)
>>  *
>>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>>  *
>>  * (selector (match_netclass "HV") (rule "HV_internal"))
>>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
>> "HV_external"))
>>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
>> "HV_external"))
>>  *
>>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "F_Cu") (rule "HV2HV_external"))
>>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
>> "B_Cu") (rule "HV2HV_external"))
>>  *
>>  *   TODO: pads for connector pins or wire pads have even larger required 
>> creepage clearances.  How to encode?
>>  *   User attributes on parent footprint?
>>  *
>>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
>> "HV") (match_type "pad") (rule "pad2PadHV"))
>>  *
>>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
>> "neckdown"))
>>  *
>>  * Type tokens:
>>  * track
>>  * via
>>  * micro_via
>>  * blind_via
>>  * pad
>>  * zone
>>  * text
>>  * graphic
>>  * board_edge
>>  * hole
>>  * npth
>>  * pth
>>  *
>>  * Rule tokens:
>>  * allow  (not yet implemented)
>>  * clearance
>>  * annulus_width
>>  * track_width
>>  * hole
>>  *
>>  * Rule modifiers:
>>  * relaxed
>>  *
>>  * (rule "HV" (clearance 200) (priority 200))
>>  * (rule "HV_external" (clearance 400) (priority 200))
>>  * (rule "HV2HV" (clearance 200) (priority 200))
>>  * (rule "HV2HV_external" (

Re: [Kicad-developers] DRC rules

[Jeff Young]

Here’s a really dumb test file just so you can get an idea of what it looks 
like:

(version 1)
(selector (match_netclass "Default") (rule "Big Gap"))
(selector (match_type track) (rule "Big Gap"))
(rule "Big Gap" (clearance 1.5))
(selector (match_type blind_via) (rule "Big Hole"))
(rule "Big Hole" (hole 2))
(rule "Small Edge" (clearance 2))
(rule "Big Edge" (clearance 3))
(selector (match_type board_edge) (rule "Small Edge"))
(selector (match_layer "In1.Cu") (match_type board_edge) (rule "Big Edge") 
(priority 2))


> On 16 May 2020, at 16:43, Jeff Young  wrote:
> 
> I’ve just merged a possible implementation of the DRC rules.  I’d like to get 
> some feedback on it, and also some testing.  (Because the rules support such 
> a wide range of possibilities it’s going to need a good deal of testing.)
> 
> For now, it picks up DRC rules from a file named “drc-rules” in the project 
> directory.
> 
> There’s no GUI editor at present: use a text editor.
> 
> Grammar is s-expr.  It generally follows the ideas set down here:
> 
> https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU
>  
> <https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU>
> 
> with one major exception: I found the select-a-single-rule didn’t pan out.  
> You have to duplicate too much stuff in each rule for that.
> 
> Also, because the DRC engine (and zone filler) don’t currently support 
> min/opt/max the prototype implements min with Seth’s “relaxed” option.
> 
> Top level is a list; first expression must be (version x) followed by any 
> number of (selector…) and (rule…) expressions.
> /*
>  * Match tokens:
>  * match_netclass
>  * match_type
>  * match_layer
>  * match_all
>  * match_area  (not yet implemented with the exception of “$board”, which 
> matches everything)
>  *
>  * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
>  *
>  * (selector (match_netclass "HV") (rule "HV_internal"))
>  * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
> "HV_external"))
>  * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
> "HV_external"))
>  *
>  * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "F_Cu") (rule "HV2HV_external"))
>  * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
> "B_Cu") (rule "HV2HV_external"))
>  *
>  *   TODO: pads for connector pins or wire pads have even larger required 
> creepage clearances.  How to encode?
>  *   User attributes on parent footprint?
>  *
>  * (selector (match_netclass "HV") (match_type "pad") (match_netclass 
> "HV") (match_type "pad") (rule "pad2PadHV"))
>  *
>  * (selector (match_netclass "signal") (match_area "BGA") (rule 
> "neckdown"))
>  *
>  * Type tokens:
>  * track
>  * via
>  * micro_via
>  * blind_via
>  * pad
>  * zone
>  * text
>  * graphic
>  * board_edge
>  * hole
>  * npth
>  * pth
>  *
>  * Rule tokens:
>  * allow  (not yet implemented)
>  * clearance
>  * annulus_width
>  * track_width
>  * hole
>  *
>  * Rule modifiers:
>  * relaxed
>  *
>  * (rule "HV" (clearance 200) (priority 200))
>  * (rule "HV_external" (clearance 400) (priority 200))
>  * (rule "HV2HV" (clearance 200) (priority 200))
>  * (rule "HV2HV_external" (clearance 500) (priority 200))
>  * (rule "pad2padHV" (clearance 500) (priority 200))
>  *
>  * (rule "signal" (clearance 20))   // implied 
> priority of 1
>  * (rule "neckdown" (clearance relaxed 15) (priority 2))
>  *
>  * (rule "allowMicrovias" (allow microvia))
>  */
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] DRC rules

[Jeff Young]

I’ve just merged a possible implementation of the DRC rules.  I’d like to get 
some feedback on it, and also some testing.  (Because the rules support such a 
wide range of possibilities it’s going to need a good deal of testing.)

For now, it picks up DRC rules from a file named “drc-rules” in the project 
directory.

There’s no GUI editor at present: use a text editor.

Grammar is s-expr.  It generally follows the ideas set down here:

https://docs.google.com/document/d/1qvCH9aHwCzp5qtKTna4jJXuloNU0b96gAxAHSKPuXpU 


with one major exception: I found the select-a-single-rule didn’t pan out.  You 
have to duplicate too much stuff in each rule for that.

Also, because the DRC engine (and zone filler) don’t currently support 
min/opt/max the prototype implements min with Seth’s “relaxed” option.

Top level is a list; first expression must be (version x) followed by any 
number of (selector…) and (rule…) expressions.
/*
 * Match tokens:
 * match_netclass
 * match_type
 * match_layer
 * match_all
 * match_area  (not yet implemented with the exception of “$board”, which 
matches everything)
 *
 * (selector (match_area "$board") (rule "OSHParkClass3") (priority 100))
 *
 * (selector (match_netclass "HV") (rule "HV_internal"))
 * (selector (match_netclass "HV") (match_layer "F_Cu") (rule 
"HV_external"))
 * (selector (match_netclass "HV") (match_layer "B_Cu") (rule 
"HV_external"))
 *
 * (selector (match_netclass "HV") (match_netclass "HV") (rule "HV2HV"))
 * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
"F_Cu") (rule "HV2HV_external"))
 * (selector (match_netclass "HV") (match_netclass "HV") (match_layer 
"B_Cu") (rule "HV2HV_external"))
 *
 *   TODO: pads for connector pins or wire pads have even larger required 
creepage clearances.  How to encode?
 *   User attributes on parent footprint?
 *
 * (selector (match_netclass "HV") (match_type "pad") (match_netclass "HV") 
(match_type "pad") (rule "pad2PadHV"))
 *
 * (selector (match_netclass "signal") (match_area "BGA") (rule "neckdown"))
 *
 * Type tokens:
 * track
 * via
 * micro_via
 * blind_via
 * pad
 * zone
 * text
 * graphic
 * board_edge
 * hole
 * npth
 * pth
 *
 * Rule tokens:
 * allow  (not yet implemented)
 * clearance
 * annulus_width
 * track_width
 * hole
 *
 * Rule modifiers:
 * relaxed
 *
 * (rule "HV" (clearance 200) (priority 200))
 * (rule "HV_external" (clearance 400) (priority 200))
 * (rule "HV2HV" (clearance 200) (priority 200))
 * (rule "HV2HV_external" (clearance 500) (priority 200))
 * (rule "pad2padHV" (clearance 500) (priority 200))
 *
 * (rule "signal" (clearance 20))   // implied priority 
of 1
 * (rule "neckdown" (clearance relaxed 15) (priority 2))
 *
 * (rule "allowMicrovias" (allow microvia))
 */


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[Jeff Young]

Hi James,

You might first want to download one of the nightlies (5.99) and play with it.  
Block selections are gone: eeschema now has a “normal” selection model where 
you click on things and/or drag-select and they get highlighted.

So from the GUI perspective you’d just need to add the options to the Scope 
section of the Annotate dialog.

I believe there’s already a Wishlist item for this in the issue database.

I suck at git, so you don’t want to know what I do for branching, etc. ;)

Cheers,
Jeff.

> On 7 May 2020, at 14:19, James Jackson  wrote:
> 
> Hi all,
> 
> Firstly thanks Wayne for adding me to the list - long time KiCad user for 
> hobby stuff, but I've got a background (partially) in fast real-time 
> mixed-signal electronics.
> 
> Working on a fairly large personal project recently, with many nested and 
> shared schematics, I would really have liked the ability to only 
> automatically annotate either a selected block of components, and/or only a 
> subset of the component types. I haven't done an KiCad UI-facing dev work 
> (or, frankly, much at all bar poking around in the code a little bit) but I'd 
> be happy to have a bash at implementing it - but would welcome others' 
> thoughts. I can't find any mention of it in roadmaps etc.
> 
> Proposal: Add the ability to annotate only a selected block and / or only 
> specific component types
> UI Flow: Two changes required, as detailed below. As described, they do not 
> change the current default UI flow, but offer up more options for users 
> should they wish to use them:
> 
>1. Add a new menu item to the block selection context menu, with text 
> 'Annotate block...'. On clicking, takes the user to the current 'Annotate 
> Schematic' dialog.
>2. Modify the 'Annotate Schematic' dialog to include:
>a. Within the 'Scope' radio button selection list, add 'Use the 
> current selected block' (not enabled if the dialog is entered the existing 
> way through the Tools menu) - autoselected if dialog entered through the 
> block context menu
>b. Add a checklist containing the prefixes of component types 
> available for annotation (i.e. 'R', 'C', 'U', whatever...). Default to all 
> being selected.
> 
> I'd welcome thoughts on this proposal, and also, if people think it's worth 
> looking at, any pointers to a quick guide to KiCad dev wrt branch handling. 
> I.e., do developers work to the head of the repository or the last stable 
> release, etc etc? I couldn't find anything on this hiding in the dev docs. I 
> can figure the rest out (internationalisation, code structures, etc etc).
> 
> Yours,
> James.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC changes

[Jeff Young]

In my simple test, the round-off errors are no longer an issue.

But I don’t have that exact footprint.  Could someone make the testcase (which 
fails on master) and send me the project + board?

Thanks,
Jeff.


> On 26 Apr 2020, at 16:58, Ian McInerney  wrote:
> 
> Is it still subject to the round-off errors 
> (https://gitlab.com/kicad/code/kicad/-/issues/4139 
> <https://gitlab.com/kicad/code/kicad/-/issues/4139>)?
> 
> -Ian
> 
> On Sun, Apr 26, 2020 at 4:30 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> New bits up here: https://gitlab.com/kicad/code/kicad/-/merge_requests/193 
> <https://gitlab.com/kicad/code/kicad/-/merge_requests/193>
> 
> I claim this fixes the rotation problems and should markedly improve 
> performance.
> 
> Cheers,
> Jeff.
> 
> 
>> On 26 Apr 2020, at 15:48, Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> 
>> Yeah, rotated rectangles report negative clearances too….
>> 
>>> On 26 Apr 2020, at 15:40, Jeff Young >> <mailto:j...@rokeby.ie>> wrote:
>>> 
>>> Cool, I’ll look into that.
>>> 
>>> I’ve also got some performance improvements to upload.
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>>> On 26 Apr 2020, at 15:35, jp charras >>> <mailto:jp.char...@wanadoo.fr>> wrote:
>>>> 
>>>> Le 26/04/2020 à 16:15, Jeff Young a écrit :
>>>>> Hi JP,
>>>>> 
>>>>> Did they report the same number of errors?
>>>>> 
>>>>> Thanks,
>>>>> Jeff.
>>>>> 
>>>> 
>>>> No:
>>>> The old algo reports 0 error.
>>>> The new reports a lot.
>>>> I am thinking there is an issue with rectangular or round/rect pads 
>>>> rotated by +- 90 deg.
>>>> 
>>>> 
>>>> -- 
>>>> Jean-Pierre CHARRAS
>>>> 
>>>> ___
>>>> Mailing list: https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers>
>>>> Post to : kicad-developers@lists.launchpad.net 
>>>> <mailto:kicad-developers@lists.launchpad.net>
>>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>>> <https://launchpad.net/~kicad-developers>
>>>> More help   : https://help.launchpad.net/ListHelp 
>>>> <https://help.launchpad.net/ListHelp>
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to : kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC changes

[Jeff Young]

New bits up here: https://gitlab.com/kicad/code/kicad/-/merge_requests/193 
<https://gitlab.com/kicad/code/kicad/-/merge_requests/193>

I claim this fixes the rotation problems and should markedly improve 
performance.

Cheers,
Jeff.


> On 26 Apr 2020, at 15:48, Jeff Young  wrote:
> 
> Yeah, rotated rectangles report negative clearances too….
> 
>> On 26 Apr 2020, at 15:40, Jeff Young  wrote:
>> 
>> Cool, I’ll look into that.
>> 
>> I’ve also got some performance improvements to upload.
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 26 Apr 2020, at 15:35, jp charras  wrote:
>>> 
>>> Le 26/04/2020 à 16:15, Jeff Young a écrit :
>>>> Hi JP,
>>>> 
>>>> Did they report the same number of errors?
>>>> 
>>>> Thanks,
>>>> Jeff.
>>>> 
>>> 
>>> No:
>>> The old algo reports 0 error.
>>> The new reports a lot.
>>> I am thinking there is an issue with rectangular or round/rect pads rotated 
>>> by +- 90 deg.
>>> 
>>> 
>>> -- 
>>> Jean-Pierre CHARRAS
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC changes

[Jeff Young]

Yeah, rotated rectangles report negative clearances too….

> On 26 Apr 2020, at 15:40, Jeff Young  wrote:
> 
> Cool, I’ll look into that.
> 
> I’ve also got some performance improvements to upload.
> 
> Cheers,
> Jeff.
> 
>> On 26 Apr 2020, at 15:35, jp charras  wrote:
>> 
>> Le 26/04/2020 à 16:15, Jeff Young a écrit :
>>> Hi JP,
>>> 
>>> Did they report the same number of errors?
>>> 
>>> Thanks,
>>> Jeff.
>>> 
>> 
>> No:
>> The old algo reports 0 error.
>> The new reports a lot.
>> I am thinking there is an issue with rectangular or round/rect pads rotated 
>> by +- 90 deg.
>> 
>> 
>> -- 
>> Jean-Pierre CHARRAS
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC changes

[Jeff Young]

—force does the trick.

> On 26 Apr 2020, at 15:43, Jeff Young  wrote:
> 
> OK, I’ve turned mirroring off.  Anyone know how to delete all the other 
> branches?  (I tried through git, but of course run into the same “protected” 
> issue.)
> 
>> On 26 Apr 2020, at 15:35, Seth Hillbrand > <mailto:s...@kipro-pcb.com>> wrote:
>> 
>> Hi Jeff-
>> 
>> You do not want your fork to mirror KiCad.  You don't need the KiCad code 
>> mirrored in your fork.  You just keep branches there to do personal work.  
>> The mirror is prevented you from pushing.
>> 
>> -Seth
>> 
>>  
>> Seth Hillbrand
>> Lead Developer
>> +1-530-302-5483‬ 
>> Davis, CA
>> www.kipro-pcb.com <http://www.kipro-pcb.com/>i...@kipro-pcb.com 
>> <mailto:i...@kipro-pcb.com>
>>  <https://twitter.com/KiProEDA>   <https://twitter.com/KiProEDA>  
>> <https://www.linkedin.com/company/kicad>   
>> <https://www.linkedin.com/company/kicad>
>> 
>> On 2020-04-26 07:14, Jeff Young wrote:
>> 
>>> So I set jeffyoung/kicad as a remote named "public" and set as a mirror.  
>>> But when I push to it I get a bunch of errors:
>>>  
>>> Jeffs-MBP:kicad jeff$ git push public
>>> Enter passphrase for key '/Users/jeff/.ssh/id_rsa': 
>>> Enumerating objects: 3601, done.
>>> Counting objects: 100% (2535/2535), done.
>>> Delta compression using up to 8 threads
>>> Compressing objects: 100% (471/471), done.
>>> Writing objects: 100% (937/937), 529.58 KiB | 8.83 MiB/s, done.
>>> Total 937 (delta 797), reused 533 (delta 458)
>>> remote: Resolving deltas: 100% (797/797), completed with 378 local objects.
>>> remote: GitLab: You are not allowed to force push code to a protected 
>>> branch on this project.
>>> To gitlab.com <http://gitlab.com/>:jeffyoung/kicad.git
>>>  ! [remote rejected] 4.0 (pre-receive hook declined)
>>>  ! [remote rejected] 5.0 -> 5.0 (pre-receive hook declined)
>>>  ! [remote rejected]     5.1 -> 5.1 (pre-receive hook declined)
>>>  ! [remote rejected] drc (pre-receive hook declined)
>>>  
>>> This is all greek to me.  Any ideas?
>>>  
>>> Thanks,
>>> Jeff.
>>>  
>>> 
>>>> On 26 Apr 2020, at 14:58, Jeff Young >>> <mailto:j...@rokeby.ie>> wrote:
>>>> 
>>>> Never mind.  That page explains how to do the later.
>>>>  
>>>> 
>>>>> On 26 Apr 2020, at 14:56, Jeff Young >>>> <mailto:j...@rokeby.ie>> wrote:
>>>>> 
>>>>> And then the merge request, is that from jeff/kicad:jeffDRC to 
>>>>> jeff/kicad:master, or is there some way to do a merge request from 
>>>>> jeff/kicad:jeffDRC to kicad/code/kicad:master?
>>>>> 
>>>>>> On 26 Apr 2020, at 14:50, Ian McInerney >>>>> <mailto:ian.s.mciner...@ieee.org>> wrote:
>>>>>> 
>>>>>> Jeff,
>>>>>>  
>>>>>> From the main repository page, simply click on "Fork" at the top of the 
>>>>>> page. Then you create it inside your Personal namespace. Once you do 
>>>>>> that, the fork can just become a new remote in your git repository.
>>>>>>  
>>>>>> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>>>>>>  
>>>>>> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
>>>>>>  
>>>>>> -Ian
>>>>>> 
>>>>>> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young >>>>> <mailto:j...@rokeby.ie>> wrote:
>>>>>> I don't have a personal repo.  Is it (reasonably) obvious how to create 
>>>>>> one?
>>>>>> 
>>>>>> > On 26 Apr 2020, at 14:32, Wayne Stambaugh >>>>> > <mailto:stambau...@gmail.com>> wrote:
>>>>>> > 
>>>>>> > Hi Jeff,
>>>>>> > 
>>>>>> > Would you please move your working branch from the main repo to your
>>>>>> > personal repo and create a merge request?  This will make it much 
>>>>>> > easier
>>>>>> > to test and avoid poluting the main repo with developers personal
>>>>>> > working branches.
>>>>>> > 
>&g

Re: [Kicad-developers] DRC changes

[Jeff Young]

OK, I’ve turned mirroring off.  Anyone know how to delete all the other 
branches?  (I tried through git, but of course run into the same “protected” 
issue.)

> On 26 Apr 2020, at 15:35, Seth Hillbrand  wrote:
> 
> Hi Jeff-
> 
> You do not want your fork to mirror KiCad.  You don't need the KiCad code 
> mirrored in your fork.  You just keep branches there to do personal work.  
> The mirror is prevented you from pushing.
> 
> -Seth
> 
>  
> Seth Hillbrand
> Lead Developer
> +1-530-302-5483‬ 
> Davis, CA
> www.kipro-pcb.com <http://www.kipro-pcb.com/>i...@kipro-pcb.com 
> <mailto:i...@kipro-pcb.com>
><https://twitter.com/KiProEDA>    
> <https://www.linkedin.com/company/kicad>
> 
> On 2020-04-26 07:14, Jeff Young wrote:
> 
>> So I set jeffyoung/kicad as a remote named "public" and set as a mirror.  
>> But when I push to it I get a bunch of errors:
>>  
>> Jeffs-MBP:kicad jeff$ git push public
>> Enter passphrase for key '/Users/jeff/.ssh/id_rsa': 
>> Enumerating objects: 3601, done.
>> Counting objects: 100% (2535/2535), done.
>> Delta compression using up to 8 threads
>> Compressing objects: 100% (471/471), done.
>> Writing objects: 100% (937/937), 529.58 KiB | 8.83 MiB/s, done.
>> Total 937 (delta 797), reused 533 (delta 458)
>> remote: Resolving deltas: 100% (797/797), completed with 378 local objects.
>> remote: GitLab: You are not allowed to force push code to a protected branch 
>> on this project.
>> To gitlab.com <http://gitlab.com/>:jeffyoung/kicad.git
>>  ! [remote rejected] 4.0 (pre-receive hook declined)
>>  ! [remote rejected] 5.0 -> 5.0 (pre-receive hook declined)
>>  ! [remote rejected] 5.1 -> 5.1 (pre-receive hook declined)
>>  ! [remote rejected] drc (pre-receive hook declined)
>>  
>> This is all greek to me.  Any ideas?
>>  
>> Thanks,
>> Jeff.
>>  
>> 
>>> On 26 Apr 2020, at 14:58, Jeff Young >> <mailto:j...@rokeby.ie>> wrote:
>>> 
>>> Never mind.  That page explains how to do the later.
>>>  
>>> 
>>>> On 26 Apr 2020, at 14:56, Jeff Young >>> <mailto:j...@rokeby.ie>> wrote:
>>>> 
>>>> And then the merge request, is that from jeff/kicad:jeffDRC to 
>>>> jeff/kicad:master, or is there some way to do a merge request from 
>>>> jeff/kicad:jeffDRC to kicad/code/kicad:master?
>>>> 
>>>>> On 26 Apr 2020, at 14:50, Ian McInerney >>>> <mailto:ian.s.mciner...@ieee.org>> wrote:
>>>>> 
>>>>> Jeff,
>>>>>  
>>>>> From the main repository page, simply click on "Fork" at the top of the 
>>>>> page. Then you create it inside your Personal namespace. Once you do 
>>>>> that, the fork can just become a new remote in your git repository.
>>>>>  
>>>>> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>>>>>  
>>>>> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
>>>>>  
>>>>> -Ian
>>>>> 
>>>>> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young >>>> <mailto:j...@rokeby.ie>> wrote:
>>>>> I don't have a personal repo.  Is it (reasonably) obvious how to create 
>>>>> one?
>>>>> 
>>>>> > On 26 Apr 2020, at 14:32, Wayne Stambaugh >>>> > <mailto:stambau...@gmail.com>> wrote:
>>>>> > 
>>>>> > Hi Jeff,
>>>>> > 
>>>>> > Would you please move your working branch from the main repo to your
>>>>> > personal repo and create a merge request?  This will make it much easier
>>>>> > to test and avoid poluting the main repo with developers personal
>>>>> > working branches.
>>>>> > 
>>>>> > Thanks,
>>>>> > 
>>>>> > Wayne
>>>>> > 
>>>>> > On 4/26/20 8:27 AM, Jeff Young wrote:
>>>>> >> I have added code to many DRC errors which shows the minimum clearance,
>>>>> >> its source, and the actual clearance.
>>>>> >> 
>>>>> >> The old DRC code was pretty heavily optimised around the idea of only
>>>>> >> needing to know if the clearance was violated (and not by how much), so
>>>>> >> a lot of 

Re: [Kicad-developers] DRC changes

[Jeff Young]

Cool, I’ll look into that.

I’ve also got some performance improvements to upload.

Cheers,
Jeff.

> On 26 Apr 2020, at 15:35, jp charras  wrote:
> 
> Le 26/04/2020 à 16:15, Jeff Young a écrit :
>> Hi JP,
>> 
>> Did they report the same number of errors?
>> 
>> Thanks,
>> Jeff.
>> 
> 
> No:
> The old algo reports 0 error.
> The new reports a lot.
> I am thinking there is an issue with rectangular or round/rect pads rotated 
> by +- 90 deg.
> 
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC changes

[Jeff Young]

Hi Ian,

Yeah, I tried just pushing the branch first, but it does the same thing.  I 
think I need to either delete all the other branches by hand, or turn off the 
“mirror” property (as that might force pushing of all branches).

Cheers,
Jeff.


> On 26 Apr 2020, at 15:21, Ian McInerney  wrote:
> 
> Try pushing only the branch you are actively working on to your personal repo.
> 
> In my setup, I have 2 remotes:
> 1) product - this is the main KiCad repo
> 2) personal - this is my personal fork
> 
> When I am working on a feature branch (called im/featurebranch) I push it to 
> my personal repo like this:
> `git push personal im/featurebranch`
> 
> Every other time I am working directly on master (such as for bug fixes or 
> smaller changes), I just push like this:
> `git push product master`
> 
> What is probably happening is that your fork has the main branches marked as 
> protected still - since they are marked as protected in the main repo the 
> fork copies that setting over.
> 
> -Ian
> 
> On Sun, Apr 26, 2020 at 3:14 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> So I set jeffyoung/kicad as a remote named “public” and set as a mirror.  But 
> when I push to it I get a bunch of errors:
> 
> Jeffs-MBP:kicad jeff$ git push public
> Enter passphrase for key '/Users/jeff/.ssh/id_rsa': 
> Enumerating objects: 3601, done.
> Counting objects: 100% (2535/2535), done.
> Delta compression using up to 8 threads
> Compressing objects: 100% (471/471), done.
> Writing objects: 100% (937/937), 529.58 KiB | 8.83 MiB/s, done.
> Total 937 (delta 797), reused 533 (delta 458)
> remote: Resolving deltas: 100% (797/797), completed with 378 local objects.
> remote: GitLab: You are not allowed to force push code to a protected branch 
> on this project.
> To gitlab.com <http://gitlab.com/>:jeffyoung/kicad.git
>  ! [remote rejected] 4.0 (pre-receive hook declined)
>  ! [remote rejected] 5.0 -> 5.0 (pre-receive hook declined)
>  ! [remote rejected] 5.1 -> 5.1 (pre-receive hook declined)
>  ! [remote rejected] drc (pre-receive hook declined)
> 
> This is all greek to me.  Any ideas?
> 
> Thanks,
> Jeff.
> 
> 
>> On 26 Apr 2020, at 14:58, Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> 
>> Never mind.  That page explains how to do the later.
>> 
>> 
>>> On 26 Apr 2020, at 14:56, Jeff Young >> <mailto:j...@rokeby.ie>> wrote:
>>> 
>>> And then the merge request, is that from jeff/kicad:jeffDRC to 
>>> jeff/kicad:master, or is there some way to do a merge request from 
>>> jeff/kicad:jeffDRC to kicad/code/kicad:master?
>>> 
>>>> On 26 Apr 2020, at 14:50, Ian McInerney >>> <mailto:ian.s.mciner...@ieee.org>> wrote:
>>>> 
>>>> Jeff,
>>>> 
>>>> From the main repository page, simply click on "Fork" at the top of the 
>>>> page. Then you create it inside your Personal namespace. Once you do that, 
>>>> the fork can just become a new remote in your git repository.
>>>> 
>>>> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>>>>  
>>>> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
>>>> 
>>>> -Ian
>>>> 
>>>> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young >>> <mailto:j...@rokeby.ie>> wrote:
>>>> I don’t have a personal repo.  Is it (reasonably) obvious how to create 
>>>> one?
>>>> 
>>>> > On 26 Apr 2020, at 14:32, Wayne Stambaugh >>> > <mailto:stambau...@gmail.com>> wrote:
>>>> > 
>>>> > Hi Jeff,
>>>> > 
>>>> > Would you please move your working branch from the main repo to your
>>>> > personal repo and create a merge request?  This will make it much easier
>>>> > to test and avoid poluting the main repo with developers personal
>>>> > working branches.
>>>> > 
>>>> > Thanks,
>>>> > 
>>>> > Wayne
>>>> > 
>>>> > On 4/26/20 8:27 AM, Jeff Young wrote:
>>>> >> I have added code to many DRC errors which shows the minimum clearance,
>>>> >> its source, and the actual clearance.
>>>> >> 
>>>> >> The old DRC code was pretty heavily optimised around the idea of only
>>>> >> needing to know if the clearance was violated (and not by how much), so
>>>> >> a lot of it has been re-wr

Re: [Kicad-developers] DRC changes

[Jeff Young]

Hi JP,

Did they report the same number of errors?

Thanks,
Jeff.


> On 26 Apr 2020, at 15:03, jp charras  wrote:
> 
> Le 26/04/2020 à 14:27, Jeff Young a écrit :
>> I have added code to many DRC errors which shows the minimum clearance, its 
>> source, and the actual clearance.
>> 
>> The old DRC code was pretty heavily optimised around the idea of only 
>> needing to know if the clearance was violated (and not by how much), so a 
>> lot of it has been re-written.  For this reason the new code is currently in 
>> a branch (jeffDRC).
>> 
>> I’d appreciate some testing on it if anyone gets a chance.  (More on the DRC 
>> errors themselves than the new reporting.)
>> 
>> Cheers,
>> Jeff.
>> 
>> PS: feel free to report issues here in email, or in 
>> https://gitlab.com/kicad/code/kicad/-/issues/2313.
>> 
> 
> Hi Jeff,
> I just tested it.
> 
> The old DRC code was pretty heavily optimized around the idea of only needing 
> to know if the clearance was violated because the calculation time
> is *much* faster than calculating actual distances.
> I tested the calculation time on the same (a 16 layers large board) with both 
> DRC versions:
> To test tracks clearance:
> Current algo: 14 s.
> Your new algo: 4 m
> 
> This is really a blocking problem.
> 
> -- 
> Jean-Pierre CHARRAS
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC changes

[Jeff Young]

So I set jeffyoung/kicad as a remote named “public” and set as a mirror.  But 
when I push to it I get a bunch of errors:

Jeffs-MBP:kicad jeff$ git push public
Enter passphrase for key '/Users/jeff/.ssh/id_rsa': 
Enumerating objects: 3601, done.
Counting objects: 100% (2535/2535), done.
Delta compression using up to 8 threads
Compressing objects: 100% (471/471), done.
Writing objects: 100% (937/937), 529.58 KiB | 8.83 MiB/s, done.
Total 937 (delta 797), reused 533 (delta 458)
remote: Resolving deltas: 100% (797/797), completed with 378 local objects.
remote: GitLab: You are not allowed to force push code to a protected branch on 
this project.
To gitlab.com:jeffyoung/kicad.git
 ! [remote rejected] 4.0 (pre-receive hook declined)
 ! [remote rejected] 5.0 -> 5.0 (pre-receive hook declined)
 ! [remote rejected] 5.1 -> 5.1 (pre-receive hook declined)
 ! [remote rejected] drc (pre-receive hook declined)

This is all greek to me.  Any ideas?

Thanks,
Jeff.


> On 26 Apr 2020, at 14:58, Jeff Young  wrote:
> 
> Never mind.  That page explains how to do the later.
> 
> 
>> On 26 Apr 2020, at 14:56, Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> 
>> And then the merge request, is that from jeff/kicad:jeffDRC to 
>> jeff/kicad:master, or is there some way to do a merge request from 
>> jeff/kicad:jeffDRC to kicad/code/kicad:master?
>> 
>>> On 26 Apr 2020, at 14:50, Ian McInerney >> <mailto:ian.s.mciner...@ieee.org>> wrote:
>>> 
>>> Jeff,
>>> 
>>> From the main repository page, simply click on "Fork" at the top of the 
>>> page. Then you create it inside your Personal namespace. Once you do that, 
>>> the fork can just become a new remote in your git repository.
>>> 
>>> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>>>  
>>> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
>>> 
>>> -Ian
>>> 
>>> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young >> <mailto:j...@rokeby.ie>> wrote:
>>> I don’t have a personal repo.  Is it (reasonably) obvious how to create one?
>>> 
>>> > On 26 Apr 2020, at 14:32, Wayne Stambaugh >> > <mailto:stambau...@gmail.com>> wrote:
>>> > 
>>> > Hi Jeff,
>>> > 
>>> > Would you please move your working branch from the main repo to your
>>> > personal repo and create a merge request?  This will make it much easier
>>> > to test and avoid poluting the main repo with developers personal
>>> > working branches.
>>> > 
>>> > Thanks,
>>> > 
>>> > Wayne
>>> > 
>>> > On 4/26/20 8:27 AM, Jeff Young wrote:
>>> >> I have added code to many DRC errors which shows the minimum clearance,
>>> >> its source, and the actual clearance.
>>> >> 
>>> >> The old DRC code was pretty heavily optimised around the idea of only
>>> >> needing to know if the clearance was violated (and not by how much), so
>>> >> a lot of it has been re-written.  For this reason the new code is
>>> >> currently in a branch (jeffDRC).
>>> >> 
>>> >> I’d appreciate some testing on it if anyone gets a chance.  (More on the
>>> >> DRC errors themselves than the new reporting.)
>>> >> 
>>> >> Cheers,
>>> >> Jeff.
>>> >> 
>>> >> PS: feel free to report issues here in email, or
>>> >> in https://gitlab.com/kicad/code/kicad/-/issues/2313 
>>> >> <https://gitlab.com/kicad/code/kicad/-/issues/2313>.
>>> >> 
>>> >> ___
>>> >> Mailing list: https://launchpad.net/~kicad-developers 
>>> >> <https://launchpad.net/~kicad-developers>
>>> >> Post to : kicad-developers@lists.launchpad.net 
>>> >> <mailto:kicad-developers@lists.launchpad.net>
>>> >> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> >> <https://launchpad.net/~kicad-developers>
>>> >> More help   : https://help.launchpad.net/ListHelp 
>>> >> <https://help.launchpad.net/ListHelp>
>>> >> 
>>> > 
>>> > ___
>>> > Mailing list: https://launchpad.net/~kicad-developers 
>>> > <https://launchpad.net/~kicad-developers>
>>> > Post to : kicad-developers

Re: [Kicad-developers] DRC changes

[Jeff Young]

Never mind.  That page explains how to do the later.


> On 26 Apr 2020, at 14:56, Jeff Young  wrote:
> 
> And then the merge request, is that from jeff/kicad:jeffDRC to 
> jeff/kicad:master, or is there some way to do a merge request from 
> jeff/kicad:jeffDRC to kicad/code/kicad:master?
> 
>> On 26 Apr 2020, at 14:50, Ian McInerney > <mailto:ian.s.mciner...@ieee.org>> wrote:
>> 
>> Jeff,
>> 
>> From the main repository page, simply click on "Fork" at the top of the 
>> page. Then you create it inside your Personal namespace. Once you do that, 
>> the fork can just become a new remote in your git repository.
>> 
>> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>>  
>> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
>> 
>> -Ian
>> 
>> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> I don’t have a personal repo.  Is it (reasonably) obvious how to create one?
>> 
>> > On 26 Apr 2020, at 14:32, Wayne Stambaugh > > <mailto:stambau...@gmail.com>> wrote:
>> > 
>> > Hi Jeff,
>> > 
>> > Would you please move your working branch from the main repo to your
>> > personal repo and create a merge request?  This will make it much easier
>> > to test and avoid poluting the main repo with developers personal
>> > working branches.
>> > 
>> > Thanks,
>> > 
>> > Wayne
>> > 
>> > On 4/26/20 8:27 AM, Jeff Young wrote:
>> >> I have added code to many DRC errors which shows the minimum clearance,
>> >> its source, and the actual clearance.
>> >> 
>> >> The old DRC code was pretty heavily optimised around the idea of only
>> >> needing to know if the clearance was violated (and not by how much), so
>> >> a lot of it has been re-written.  For this reason the new code is
>> >> currently in a branch (jeffDRC).
>> >> 
>> >> I’d appreciate some testing on it if anyone gets a chance.  (More on the
>> >> DRC errors themselves than the new reporting.)
>> >> 
>> >> Cheers,
>> >> Jeff.
>> >> 
>> >> PS: feel free to report issues here in email, or
>> >> in https://gitlab.com/kicad/code/kicad/-/issues/2313 
>> >> <https://gitlab.com/kicad/code/kicad/-/issues/2313>.
>> >> 
>> >> ___
>> >> Mailing list: https://launchpad.net/~kicad-developers 
>> >> <https://launchpad.net/~kicad-developers>
>> >> Post to : kicad-developers@lists.launchpad.net 
>> >> <mailto:kicad-developers@lists.launchpad.net>
>> >> Unsubscribe : https://launchpad.net/~kicad-developers 
>> >> <https://launchpad.net/~kicad-developers>
>> >> More help   : https://help.launchpad.net/ListHelp 
>> >> <https://help.launchpad.net/ListHelp>
>> >> 
>> > 
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers 
>> > <https://launchpad.net/~kicad-developers>
>> > Post to : kicad-developers@lists.launchpad.net 
>> > <mailto:kicad-developers@lists.launchpad.net>
>> > Unsubscribe : https://launchpad.net/~kicad-developers 
>> > <https://launchpad.net/~kicad-developers>
>> > More help   : https://help.launchpad.net/ListHelp 
>> > <https://help.launchpad.net/ListHelp>
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC changes

[Jeff Young]

And then the merge request, is that from jeff/kicad:jeffDRC to 
jeff/kicad:master, or is there some way to do a merge request from 
jeff/kicad:jeffDRC to kicad/code/kicad:master?

> On 26 Apr 2020, at 14:50, Ian McInerney  wrote:
> 
> Jeff,
> 
> From the main repository page, simply click on "Fork" at the top of the page. 
> Then you create it inside your Personal namespace. Once you do that, the fork 
> can just become a new remote in your git repository.
> 
> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>  
> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
> 
> -Ian
> 
> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> I don’t have a personal repo.  Is it (reasonably) obvious how to create one?
> 
> > On 26 Apr 2020, at 14:32, Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> > 
> > Hi Jeff,
> > 
> > Would you please move your working branch from the main repo to your
> > personal repo and create a merge request?  This will make it much easier
> > to test and avoid poluting the main repo with developers personal
> > working branches.
> > 
> > Thanks,
> > 
> > Wayne
> > 
> > On 4/26/20 8:27 AM, Jeff Young wrote:
> >> I have added code to many DRC errors which shows the minimum clearance,
> >> its source, and the actual clearance.
> >> 
> >> The old DRC code was pretty heavily optimised around the idea of only
> >> needing to know if the clearance was violated (and not by how much), so
> >> a lot of it has been re-written.  For this reason the new code is
> >> currently in a branch (jeffDRC).
> >> 
> >> I’d appreciate some testing on it if anyone gets a chance.  (More on the
> >> DRC errors themselves than the new reporting.)
> >> 
> >> Cheers,
> >> Jeff.
> >> 
> >> PS: feel free to report issues here in email, or
> >> in https://gitlab.com/kicad/code/kicad/-/issues/2313 
> >> <https://gitlab.com/kicad/code/kicad/-/issues/2313>.
> >> 
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> Post to : kicad-developers@lists.launchpad.net 
> >> <mailto:kicad-developers@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> More help   : https://help.launchpad.net/ListHelp 
> >> <https://help.launchpad.net/ListHelp>
> >> 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net 
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp 
> > <https://help.launchpad.net/ListHelp>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC changes

[Jeff Young]

Do I fork the project and put it in my “namespace”?

> On 26 Apr 2020, at 14:47, Jeff Young  wrote:
> 
> I don’t have a personal repo.  Is it (reasonably) obvious how to create one?
> 
>> On 26 Apr 2020, at 14:32, Wayne Stambaugh  wrote:
>> 
>> Hi Jeff,
>> 
>> Would you please move your working branch from the main repo to your
>> personal repo and create a merge request?  This will make it much easier
>> to test and avoid poluting the main repo with developers personal
>> working branches.
>> 
>> Thanks,
>> 
>> Wayne
>> 
>> On 4/26/20 8:27 AM, Jeff Young wrote:
>>> I have added code to many DRC errors which shows the minimum clearance,
>>> its source, and the actual clearance.
>>> 
>>> The old DRC code was pretty heavily optimised around the idea of only
>>> needing to know if the clearance was violated (and not by how much), so
>>> a lot of it has been re-written.  For this reason the new code is
>>> currently in a branch (jeffDRC).
>>> 
>>> I’d appreciate some testing on it if anyone gets a chance.  (More on the
>>> DRC errors themselves than the new reporting.)
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> PS: feel free to report issues here in email, or
>>> in https://gitlab.com/kicad/code/kicad/-/issues/2313.
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] DRC changes

[Jeff Young]

I don’t have a personal repo.  Is it (reasonably) obvious how to create one?

> On 26 Apr 2020, at 14:32, Wayne Stambaugh  wrote:
> 
> Hi Jeff,
> 
> Would you please move your working branch from the main repo to your
> personal repo and create a merge request?  This will make it much easier
> to test and avoid poluting the main repo with developers personal
> working branches.
> 
> Thanks,
> 
> Wayne
> 
> On 4/26/20 8:27 AM, Jeff Young wrote:
>> I have added code to many DRC errors which shows the minimum clearance,
>> its source, and the actual clearance.
>> 
>> The old DRC code was pretty heavily optimised around the idea of only
>> needing to know if the clearance was violated (and not by how much), so
>> a lot of it has been re-written.  For this reason the new code is
>> currently in a branch (jeffDRC).
>> 
>> I’d appreciate some testing on it if anyone gets a chance.  (More on the
>> DRC errors themselves than the new reporting.)
>> 
>> Cheers,
>> Jeff.
>> 
>> PS: feel free to report issues here in email, or
>> in https://gitlab.com/kicad/code/kicad/-/issues/2313.
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp