Re: [Kicad-developers] Some first impressions on our tool framework

[Seth Hillbrand]

Am 2019-05-06 21:02, schrieb Tomasz Wlostowski:

On 06/05/2019 09:48, Jeff Young wrote:

1) I hate the coroutines.  They truncate backtraces in the debugger.


Hi,

How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on
Windows? I have working implementation of the latter already in the 
MSVC

branch. Are there any reasons to not use ucontext under Linux/OSX?


I'm sure you've seen this:
https://www.boost.org/doc/libs/1_70_0/libs/context/doc/html/context/performance.html

tldr; ucontext_t is really a bummer, performance-wise.

Maybe we look into Boost::Fiber?  It is stack-ful and as long as we 
stick to the the defined API, we should not hit the issues we had in the 
past with the low-level stuff.


-S

___
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 first impressions on our tool framework

[Simon Richter]

Hi,

On 07.05.19 03:02, Tomasz Wlostowski wrote:

> How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on
> Windows? I have working implementation of the latter already in the MSVC
> branch. Are there any reasons to not use ucontext under Linux/OSX?

Technically, these APIs are deprecated on OSX in favour of Grand Central
Dispatch, but I doubt they will be going anywhere.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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 first impressions on our tool framework

[Tomasz Wlostowski]

On 06/05/2019 09:48, Jeff Young wrote:
> 1) I hate the coroutines.  They truncate backtraces in the debugger.

Hi,

How about using ucontext.h on Unices (Linux/OSX) and WinFiber API on
Windows? I have working implementation of the latter already in the MSVC
branch. Are there any reasons to not use ucontext under Linux/OSX?

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] Bug #1773638: The origins of 6.0 (pun intended)

[Jon Evans]

Hi Reece,

I only have opinions on a few of your questions so far:

1. This seems logical to me
2. I agree this panel is getting full.  Maybe we should start a
"coordinates and grids" setting page, if we are eventually going to support
custom grids, move the current grid settings there, and add yours?  Anyone
else have ideas?
3. Use wxFormBuilder -- I recommend installing the latest version from
source.  You can browse through the existing preference dialog *.fbp
projects to get a feel for it.  I usually have that open on one monitor and
the wxWidgets documentation on the other :-)
6. This seems potentially quite handy for the footprint editor.  It's less
clear to me why this is needed for the schematic / symbol editors.

Best,
Jon

On Sat, May 4, 2019 at 8:58 PM Reece R. Pollack  wrote:

> Rene pointed out that my work on display origin transforms is really a fix
> for Bug #1773638, thus the retitling.
>
> I'm making good progress, but I need a bit of guidance before proceeding
> further.
>
> The code I've developed allows the user to select the origin for the
> display of X and Y coordinates, rather than the origin always being the
> upper left corner of the surrounding "page" frame. There is no change to
> the underlying board file or internal coordinate representation. This is
> purely a change the way coordinates are displayed to the user and entered
> by the user in dialog boxes.
>
> The user gets three configuration options:
>
>- The absolute display origin: Page (default), Aux, or Grid.
>- The direction of the positive Y-axis: Down (default) or Up.
>- The direction of the positive X-axis: Right (default) or Left.
>
> I've attached patch diffs for review and experimentation. The patches will
> apply cleanly to the current "eemodern" branch (commit 6137921), the 5.1.2
> tag with one trivial merge error, and probably the "master" branch. It's
> not ready for merging, though. It lacks a UI for configuration, and
> configuration isn't saved or loaded from the user preferences file. For
> testing the config defaults to Aux origin and Y-axis Up. Obviously these
> deficiencies will have to be addressed before a merge.
>
> Now for my request for guidance:
>
>1. The user configuration options are currently in the
>PCB_DISPLAY_OPTIONS class. I'd like some confirmation that this is the
>correct place before I code the preferences file save and restore.
>2. Where should the config UI go? I expect this will be a
>set-and-forget thing for most users. I'm thinking on the Pcbnew Preferences
>-> Preferences -> Pcbnew -> Display Options dialog, if there's room. But
>this panel seems to be half-shared with other apps and is getting kind of
>full. Perhaps another panel instead of Display Options?
>3. The last time I did UI work was when the TRS-80 was hot stuff (I'm
>a Linux kernel guy). Can someone recommend an approach for developing the
>UI changes, and perhaps a pointer to a relevant how-to?
>4. The dx/dy (relative coordinate) part of the status line isn't being
>transformed yet because of commit e6a200b. I posted a question regarding
>that earlier today but haven't received any replies yet.
>5. Have I missed any dialog boxes that present absolute coordinates to
>the user? There's a list in the commit log.
>6. Should this be extended to the footprint editor? Eeschema? Anywhere
>else?
>
> Thanks for the help, folks!
>
> -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] Pcbnew display origin transforms for v6

[John Beard]

On 06/05/2019 22:12, Wayne Stambaugh wrote:

On 5/6/2019 5:11 PM, John Beard wrote:

I still suggest to change it to false be default and allow developers to
manually align when they want (and then override the formatter). Then at
least the default behaviour is a valid formatting choice.


That works for me.


Here's a quick patch to make the _clang-format change and make it clear 
in the style guide that the column aligned method is still permitted 
when better for readability. The current switch formatting example is 
already formatted in multi-line style, so that's covered implicitly.


Cheers,

John
>From 7f2ae3c674030c1b22ecbadb9b70149d0e3e64ec Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Mon, 6 May 2019 22:23:51 +0100
Subject: [PATCH] Format: Default to switch cases on separate lines by default

Currently, the format enforces single lines when possible, but does
not enforce readable column-based alignment (and, moreover, *removes*
such manually added alignment:

switch( m_orientation )
{
case PIN_RIGHT: m_orientation = PIN_UP; break;
case PIN_UP: m_orientation = PIN_LEFT; break;
}

Change this to multi-line by default:

switch( m_orientation )
{
case PIN_RIGHT:
m_orientation = PIN_UP;
break;
case PIN_UP:
m_orientation = PIN_LEFT;
break;
}

If the developer wishes for column-aligned single-line cases, this
is permitted, but much be done manually:

switch( m_orientation )
{
case PIN_RIGHT: m_orientation = PIN_DOWN;  break;
case PIN_UP:m_orientation = PIN_RIGHT; break;
}

CHANGE: the _clang-format file to reflect this, and add note about
manual override in the dev docs.
---
 Documentation/development/coding-style-policy.md | 14 ++
 _clang-format|  2 +-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/Documentation/development/coding-style-policy.md b/Documentation/development/coding-style-policy.md
index 8836f6a27..1be6fd6f1 100644
--- a/Documentation/development/coding-style-policy.md
+++ b/Documentation/development/coding-style-policy.md
@@ -467,6 +467,20 @@ The case statement is to be indented to the same level as the switch.
 }
 ~
 
+It is permitted to place all cases on a single line each, if that makes the
+code more readable. This is often done for look-ups or translation functions. In
+this case, you will have to manually align for readability as appropriate and
+reject clang-format's suggested changes, if you use it:
+
+~{.cpp}
+switch( m_orientation )
+{
+case PIN_RIGHT: m_orientation = PIN_UP;break;
+case PIN_UP:m_orientation = PIN_LEFT;  break;
+case PIN_LEFT:  m_orientation = PIN_DOWN;  break;
+case PIN_DOWN:  m_orientation = PIN_RIGHT; break;
+}
+~
 
 # 5. License Statement # {#license_statement}
 There is a the file copyright.h which you can copy into the top of
diff --git a/_clang-format b/_clang-format
index 1a4179264..413c8b571 100644
--- a/_clang-format
+++ b/_clang-format
@@ -7,7 +7,7 @@ AlignOperands: true
 AlignTrailingComments: true
 AllowAllParametersOfDeclarationOnNextLine: true
 AllowShortBlocksOnASingleLine: false
-AllowShortCaseLabelsOnASingleLine: true
+AllowShortCaseLabelsOnASingleLine: false
 AllowShortFunctionsOnASingleLine: false
 AllowShortIfStatementsOnASingleLine: false
 AllowShortLoopsOnASingleLine: false
-- 
2.21.0

___
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 display origin transforms for v6

[Wayne Stambaugh]

Looks good John, feel free to push the change.

Thanks,

Wayne

On 5/6/2019 5:35 PM, John Beard wrote:
> On 06/05/2019 22:12, Wayne Stambaugh wrote:
>> On 5/6/2019 5:11 PM, John Beard wrote:
>>> I still suggest to change it to false be default and allow developers to
>>> manually align when they want (and then override the formatter). Then at
>>> least the default behaviour is a valid formatting choice.
>>
>> That works for me.
> 
> Here's a quick patch to make the _clang-format change and make it clear
> in the style guide that the column aligned method is still permitted
> when better for readability. The current switch formatting example is
> already formatted in multi-line style, so that's covered implicitly.
> 
> Cheers,
> 
> John

___
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 display origin transforms for v6

[Wayne Stambaugh]

John,

On 5/6/2019 5:11 PM, John Beard wrote:
> 
> 
> On 06/05/2019 21:46, Wayne Stambaugh wrote:
>> John,
>>
>> On 5/6/19 4:09 PM, John Beard wrote:
>>> On 06/05/2019 17:51, Reece R. Pollack wrote:
 John,

 I've already jumped to clang-format 6.0, which is one of the optional
 installs for Mint 18. That works, once you get all the symlinks fixed,
>>>
>>> Good to know, thanks for the update.
>>>
 except it keeps wanting to reformat my switch statements like this,
 which is contrary to the KiCad coding standards:

 @@ -148,15 +130,9 @@ int PCB_ORIGIN_TRANSFORM_Y_ABS::FromDisplay( int
 aValue ) const
    case ORIGIN_REFERENCE_PAGE:
    // No-op
    break;
 -    case ORIGIN_REFERENCE_AUX:
 -    origin = m_PcbBaseFrame->GetAuxOrigin().y;
 -    break;
 -    case ORIGIN_REFERENCE_GRID:
 -    origin = m_PcbBaseFrame->GetGridOrigin().y;
 -    break;
 -    default:
 -    wxASSERT(false);
 -    break;
 +    case ORIGIN_REFERENCE_AUX: origin =
 m_PcbBaseFrame->GetAuxOrigin().y; break;
 +    case ORIGIN_REFERENCE_GRID: origin =
 m_PcbBaseFrame->GetGridOrigin().y; break;
 +    default: wxASSERT( false ); break;
    }

    // Invert the direction if needed
>>>
>>> This is a weird style that I don't personally like, and IMO goes against
>>> the style implied by our "spacious" bracing and newline-before-if
>>> policies. But there are quite some uses of it. It's enforced by this
>>> line:
>>>
>>>  AllowShortCaseLabelsOnASingleLine: true
>>>
>>> It's the only line-condensing option we have set:
>>>
>>>  AllowShortBlocksOnASingleLine: false
>>>  AllowShortCaseLabelsOnASingleLine: true # the only true here
>>>  AllowShortFunctionsOnASingleLine: false
>>>  AllowShortIfStatementsOnASingleLine: false
>>>  AllowShortLoopsOnASingleLine: false
>>>
>>> If the formatter is proposing a change that goes against the existing
>>> style in the code area in question, I do not think it's controversial to
>>> ignore its suggestion.
>>>
>>> @Wayne, what do you think: is this enforcement representative of the
>>> right style? Should we change AllowShortCaseLabelsOnASingleLine to
>>> false? (+1 from me).
>>
>> I would rather not have clang-format force this change.  I am OK if the
>> developer prefers this for short case labels but if they prefer a
>> separate line that's fine.  I prefer everything on more than one line
>> but if I'm changing code that is already formatted on a single line, I
>> don't change it.  We didn't specify this in the coding policy so it's a
>> don't care but I would ask you to change it if you your case labels were
>> complex and you had them on a single line.
> 
> Fair enough - gratuitous formatting changes in the same commit as
> functional changes are a sin anyway!
> 
> Remember, (git-)clang-format will only change what you change, it
> shouldn't forcibly change formatting in general unless you tell it to.
> Users still need to ensure it looks sane and only accept good changes.
> 
> Having AllowShortCaseLabelsOnASingleLine = true means that clang-format
> will *enforce* the all-on-a-line policy when it can, but it will not
> enforce column alignment (and will actually collapse manual column
> alignment). So basically, the formatter is unlikely to ever give a good
> result for a short-case switch as it stands.
> 
> I still suggest to change it to false be default and allow developers to
> manually align when they want (and then override the formatter). Then at
> least the default behaviour is a valid formatting choice.
> 
> Cheers,
> 
> John

That works for me.

Thanks,

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

Re: [Kicad-developers] Pcbnew display origin transforms for v6

[John Beard]

On 06/05/2019 21:46, Wayne Stambaugh wrote:

John,

On 5/6/19 4:09 PM, John Beard wrote:

On 06/05/2019 17:51, Reece R. Pollack wrote:

John,

I've already jumped to clang-format 6.0, which is one of the optional
installs for Mint 18. That works, once you get all the symlinks fixed,


Good to know, thanks for the update.


except it keeps wanting to reformat my switch statements like this,
which is contrary to the KiCad coding standards:

@@ -148,15 +130,9 @@ int PCB_ORIGIN_TRANSFORM_Y_ABS::FromDisplay( int
aValue ) const
   case ORIGIN_REFERENCE_PAGE:
   // No-op
   break;
-    case ORIGIN_REFERENCE_AUX:
-    origin = m_PcbBaseFrame->GetAuxOrigin().y;
-    break;
-    case ORIGIN_REFERENCE_GRID:
-    origin = m_PcbBaseFrame->GetGridOrigin().y;
-    break;
-    default:
-    wxASSERT(false);
-    break;
+    case ORIGIN_REFERENCE_AUX: origin =
m_PcbBaseFrame->GetAuxOrigin().y; break;
+    case ORIGIN_REFERENCE_GRID: origin =
m_PcbBaseFrame->GetGridOrigin().y; break;
+    default: wxASSERT( false ); break;
   }

   // Invert the direction if needed


This is a weird style that I don't personally like, and IMO goes against
the style implied by our "spacious" bracing and newline-before-if
policies. But there are quite some uses of it. It's enforced by this line:

     AllowShortCaseLabelsOnASingleLine: true

It's the only line-condensing option we have set:

     AllowShortBlocksOnASingleLine: false
     AllowShortCaseLabelsOnASingleLine: true # the only true here
     AllowShortFunctionsOnASingleLine: false
     AllowShortIfStatementsOnASingleLine: false
     AllowShortLoopsOnASingleLine: false

If the formatter is proposing a change that goes against the existing
style in the code area in question, I do not think it's controversial to
ignore its suggestion.

@Wayne, what do you think: is this enforcement representative of the
right style? Should we change AllowShortCaseLabelsOnASingleLine to
false? (+1 from me).


I would rather not have clang-format force this change.  I am OK if the
developer prefers this for short case labels but if they prefer a
separate line that's fine.  I prefer everything on more than one line
but if I'm changing code that is already formatted on a single line, I
don't change it.  We didn't specify this in the coding policy so it's a
don't care but I would ask you to change it if you your case labels were
complex and you had them on a single line.


Fair enough - gratuitous formatting changes in the same commit as 
functional changes are a sin anyway!


Remember, (git-)clang-format will only change what you change, it 
shouldn't forcibly change formatting in general unless you tell it to. 
Users still need to ensure it looks sane and only accept good changes.


Having AllowShortCaseLabelsOnASingleLine = true means that clang-format 
will *enforce* the all-on-a-line policy when it can, but it will not 
enforce column alignment (and will actually collapse manual column 
alignment). So basically, the formatter is unlikely to ever give a good 
result for a short-case switch as it stands.


I still suggest to change it to false be default and allow developers to 
manually align when they want (and then override the formatter). Then at 
least the default behaviour is a valid formatting choice.


Cheers,

John

___
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 display origin transforms for v6

[Jeff Young]

We do use (and encourage) single-line cases when it’s more readable that way.  
This particularly comes up when mapping or converting something, such as:
switch( aFaceId )
{
case FACE_SCH:  name = KIFACE_PREFIX "eeschema";break;
case FACE_PCB:  name = KIFACE_PREFIX "pcbnew";  break;
case FACE_CVPCB:name = KIFACE_PREFIX "cvpcb";   break;
case FACE_GERBVIEW: name = KIFACE_PREFIX "gerbview";break;
case FACE_PL_EDITOR:name = KIFACE_PREFIX "pl_editor";   break;
case FACE_PCB_CALCULATOR:   name = KIFACE_PREFIX "pcb_calculator";  break;
case FACE_BMP2CMP:  name = KIFACE_PREFIX "bitmap2component";break;

default:
wxASSERT_MSG( 0, wxT( "caller has a bug, passed a bad aFaceId" ) );
return wxEmptyString;
}

or:

switch( aType )
{
case SCH_LABEL_T:newtext = new SCH_LABEL( position, txt );break;
case SCH_GLOBAL_LABEL_T: newtext = new SCH_GLOBALLABEL( position, txt );  break;
case SCH_HIER_LABEL_T:   newtext = new SCH_HIERLABEL( position, txt );break;
case SCH_TEXT_T: newtext = new SCH_TEXT( position, txt ); break;

default:
wxASSERT_MSG( false, wxString::Format( "Invalid text type: %d.", aType ) );
return;
}

or:

if( aRotateCCW )
{
switch( m_orientation )
{
case PIN_RIGHT: m_orientation = PIN_UP;break;
case PIN_UP:m_orientation = PIN_LEFT;  break;
case PIN_LEFT:  m_orientation = PIN_DOWN;  break;
case PIN_DOWN:  m_orientation = PIN_RIGHT; break;
}
}
else
{
switch( m_orientation )
{
case PIN_RIGHT: m_orientation = PIN_DOWN;  break;
case PIN_UP:m_orientation = PIN_RIGHT; break;
case PIN_LEFT:  m_orientation = PIN_UP;break;
case PIN_DOWN:  m_orientation = PIN_LEFT;  break;
}
}

Cheers,
Jeff.


> On 6 May 2019, at 21:09, John Beard  wrote:
> 
> On 06/05/2019 17:51, Reece R. Pollack wrote:
>> John,
>> I've already jumped to clang-format 6.0, which is one of the optional 
>> installs for Mint 18. That works, once you get all the symlinks fixed, 
> 
> Good to know, thanks for the update.
> 
>> except it keeps wanting to reformat my switch statements like this, which is 
>> contrary to the KiCad coding standards:
>> @@ -148,15 +130,9 @@ int PCB_ORIGIN_TRANSFORM_Y_ABS::FromDisplay( int aValue 
>> ) const
>>  case ORIGIN_REFERENCE_PAGE:
>>  // No-op
>>  break;
>> -case ORIGIN_REFERENCE_AUX:
>> -origin = m_PcbBaseFrame->GetAuxOrigin().y;
>> -break;
>> -case ORIGIN_REFERENCE_GRID:
>> -origin = m_PcbBaseFrame->GetGridOrigin().y;
>> -break;
>> -default:
>> -wxASSERT(false);
>> -break;
>> +case ORIGIN_REFERENCE_AUX: origin = m_PcbBaseFrame->GetAuxOrigin().y; 
>> break;
>> +case ORIGIN_REFERENCE_GRID: origin = m_PcbBaseFrame->GetGridOrigin().y; 
>> break;
>> +default: wxASSERT( false ); break;
>>  }
>>  // Invert the direction if needed
> 
> This is a weird style that I don't personally like, and IMO goes against the 
> style implied by our "spacious" bracing and newline-before-if policies. But 
> there are quite some uses of it. It's enforced by this line:
> 
>AllowShortCaseLabelsOnASingleLine: true
> 
> It's the only line-condensing option we have set:
> 
>AllowShortBlocksOnASingleLine: false
>AllowShortCaseLabelsOnASingleLine: true # the only true here
>AllowShortFunctionsOnASingleLine: false
>AllowShortIfStatementsOnASingleLine: false
>AllowShortLoopsOnASingleLine: false
> 
> If the formatter is proposing a change that goes against the existing style 
> in the code area in question, I do not think it's controversial to ignore its 
> suggestion.
> 
> @Wayne, what do you think: is this enforcement representative of the right 
> style? Should we change AllowShortCaseLabelsOnASingleLine to false? (+1 from 
> me).
> 
> Cheers,
> 
> John
> 
> ___
> 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] Pcbnew display origin transforms for v6

[Wayne Stambaugh]

John,

On 5/6/19 4:09 PM, John Beard wrote:
> On 06/05/2019 17:51, Reece R. Pollack wrote:
>> John,
>>
>> I've already jumped to clang-format 6.0, which is one of the optional
>> installs for Mint 18. That works, once you get all the symlinks fixed, 
> 
> Good to know, thanks for the update.
> 
>> except it keeps wanting to reformat my switch statements like this,
>> which is contrary to the KiCad coding standards:
>>
>> @@ -148,15 +130,9 @@ int PCB_ORIGIN_TRANSFORM_Y_ABS::FromDisplay( int
>> aValue ) const
>>   case ORIGIN_REFERENCE_PAGE:
>>   // No-op
>>   break;
>> -    case ORIGIN_REFERENCE_AUX:
>> -    origin = m_PcbBaseFrame->GetAuxOrigin().y;
>> -    break;
>> -    case ORIGIN_REFERENCE_GRID:
>> -    origin = m_PcbBaseFrame->GetGridOrigin().y;
>> -    break;
>> -    default:
>> -    wxASSERT(false);
>> -    break;
>> +    case ORIGIN_REFERENCE_AUX: origin =
>> m_PcbBaseFrame->GetAuxOrigin().y; break;
>> +    case ORIGIN_REFERENCE_GRID: origin =
>> m_PcbBaseFrame->GetGridOrigin().y; break;
>> +    default: wxASSERT( false ); break;
>>   }
>>
>>   // Invert the direction if needed
> 
> This is a weird style that I don't personally like, and IMO goes against
> the style implied by our "spacious" bracing and newline-before-if
> policies. But there are quite some uses of it. It's enforced by this line:
> 
>     AllowShortCaseLabelsOnASingleLine: true
> 
> It's the only line-condensing option we have set:
> 
>     AllowShortBlocksOnASingleLine: false
>     AllowShortCaseLabelsOnASingleLine: true # the only true here
>     AllowShortFunctionsOnASingleLine: false
>     AllowShortIfStatementsOnASingleLine: false
>     AllowShortLoopsOnASingleLine: false
> 
> If the formatter is proposing a change that goes against the existing
> style in the code area in question, I do not think it's controversial to
> ignore its suggestion.
> 
> @Wayne, what do you think: is this enforcement representative of the
> right style? Should we change AllowShortCaseLabelsOnASingleLine to
> false? (+1 from me).

I would rather not have clang-format force this change.  I am OK if the
developer prefers this for short case labels but if they prefer a
separate line that's fine.  I prefer everything on more than one line
but if I'm changing code that is already formatted on a single line, I
don't change it.  We didn't specify this in the coding policy so it's a
don't care but I would ask you to change it if you your case labels were
complex and you had them on a single line.

Wayne

> 
> Cheers,
> 
> John
> 
> ___
> 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] Pcbnew display origin transforms for v6

[John Beard]

On 06/05/2019 17:51, Reece R. Pollack wrote:

John,

I've already jumped to clang-format 6.0, which is one of the optional 
installs for Mint 18. That works, once you get all the symlinks fixed, 


Good to know, thanks for the update.

except it keeps wanting to reformat my switch statements like this, 
which is contrary to the KiCad coding standards:


@@ -148,15 +130,9 @@ int PCB_ORIGIN_TRANSFORM_Y_ABS::FromDisplay( int 
aValue ) const

  case ORIGIN_REFERENCE_PAGE:
  // No-op
  break;
-case ORIGIN_REFERENCE_AUX:
-origin = m_PcbBaseFrame->GetAuxOrigin().y;
-break;
-case ORIGIN_REFERENCE_GRID:
-origin = m_PcbBaseFrame->GetGridOrigin().y;
-break;
-default:
-wxASSERT(false);
-break;
+case ORIGIN_REFERENCE_AUX: origin = 
m_PcbBaseFrame->GetAuxOrigin().y; break;
+case ORIGIN_REFERENCE_GRID: origin = 
m_PcbBaseFrame->GetGridOrigin().y; break;

+default: wxASSERT( false ); break;
  }

  // Invert the direction if needed


This is a weird style that I don't personally like, and IMO goes against 
the style implied by our "spacious" bracing and newline-before-if 
policies. But there are quite some uses of it. It's enforced by this line:


AllowShortCaseLabelsOnASingleLine: true

It's the only line-condensing option we have set:

AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: true # the only true here
AllowShortFunctionsOnASingleLine: false
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false

If the formatter is proposing a change that goes against the existing 
style in the code area in question, I do not think it's controversial to 
ignore its suggestion.


@Wayne, what do you think: is this enforcement representative of the 
right style? Should we change AllowShortCaseLabelsOnASingleLine to 
false? (+1 from me).


Cheers,

John

___
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 first impressions on our tool framework

[Jeff Young]

That would be very cool, because a lot of the rest of the framework is really 
nice.

> On 6 May 2019, at 18:22, Tomasz Wlostowski  wrote:
> 
> On 06/05/2019 09:48, Jeff Young wrote:
>> 1) I hate the coroutines.  They truncate backtraces in the debugger.
> 
> Hi Jeff,
> 
> I'm thinking how to improve this. Perhaps we can 'fix' a fake stack
> frame that will allow the debugger to unwind the stack past the
> coroutine entry point...
> 
> 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] macOS build errors, swig?

[Adam Wolf]

Sorry for the noise.

It appears that we need to adjust that script for when new versions of
swig come out.  Homebrew recently updated to swig 4.0.0.  I will see
if I can version pin swig for the moment and come up with the patch to
get swig 4.0.0 working.

Adam

On Mon, May 6, 2019 at 12:25 PM Adam Wolf  wrote:
>
> Hi folks!
>
> I'm still not able to get anything to build on macOS, either 10.14 or
> 10.11.  I keep getting:
>
> Error: the swig import helper was not fixed, check
> /vagrant/build/kicad/src/kicad-build/pcbnew/pcbnew.py
> and fix this script: fix_swig_imports.py
>
> Does anyone know anything more about this?  Is anyone else able to
> make a Mac build?
>
> Adam
>
> On Wed, May 1, 2019 at 9:36 AM Adam Wolf  
> wrote:
> >
> > Hi folks!
> >
> > I'm seeing broken builds, reporting
> >
> > 06:14:03 default: Error: the swig import helper was not fixed, check
> > /vagrant/build/kicad/src/kicad-build/pcbnew/pcbnew.py
> >
> > 06:14:03 default:and fix this script: fix_swig_imports.py
> > 06:14:03 default: make[6]: *** [pcbnew/pcbnew_wrap.cxx] Error 2
> >
> > across the board on my macOS builds, both 10.11 and 10.14.
> >
> > This appears to be new since 9741b43da.
> >
> > Adam

___
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] Improving library editor checks

[Wayne Stambaugh]

If you are just doing the footprint checks then using the pcbnew python
support should be fine.  Whether or not it gets accepted into kicad
depends on you commitment to maintaining it but you can always load and
run it as a third party script.  You will have to live with some api
breakage from time to time until the stable python api wrapper is
complete.  Typically there isn't too much breakage with the swigged
python api.

Wayne

On 4/30/19 9:03 AM, Antonio Vázquez Blanco wrote:
> Maybe starting with footprint checking improvements is easier as python
> scripting support seems more advanced and that would allow me to start
> working on something. AFAIK there is SWIG for that part (I do not know
> how stable it is but I am willing to cope with that). ¿What do you think
> about that?
> 
> As pointed by users in the forum it would be interesting to be able to
> run the check scripts from command line in order to integrate the checks
> into Travis/Gitlab or whatever CI environment is going to be used. Also,
> current check scripts implement their own parsing which I would like to
> avoid by using KiCad implementation.
> 
> Thank you!
> 
> El jue., 25 abr. 2019 a las 16:15, Wayne Stambaugh
> (mailto:stambau...@gmail.com>>) escribió:
> 
> Python scripting support is hopefully going to be implemented at some
> point during V6 development.  This should allow you to integrate the KLC
> scripts directly into the symbol library editor.  This will most likely
> happen late in V6 development because there are some major functional
> changes to the low level schematic and library objects.  It doesn't make
> sense to swig this until the low level object APIs stabilize.
> 
> On 4/25/19 9:39 AM, Antonio Vázquez Blanco wrote:
> > From the feedback given I am thinking about changing the proposal.
> >
> > Given that my ultimate goal was to integrate KLC check into KiCad to
> > improve the quality of contributions and reduce librarian work,
> and that
> > seems conflicting we may need to re-think my approach to the problem.
> >
> > I don't want to enforce KLC on every user. Furthermore, from your
> > comments I thought that maybe I am interested in even writing some
> tests
> > that would conform with a set of rules that only my organization would
> > care about. That being said, I came to the conclusion that maybe we
> > could define groups of tests that could be enabled or disabled
> depending
> > on user preferences. For example, KLC could be one of those groups
> of rules.
> >
> > John suggested the usage of external scripts. That could be the
> solution
> > to various problems. Scripts could be externally updated if needed and
> > they would also allow to users to write their own checks without
> having
> > to recompille the full source code. It would also allow the
> distribution
> > of those "groups" of rules suggested above.
> >
> > Maybe we sould think of a interface that would allow KiCad to look
> for a
> > set of Python scripts inside a particular folder to allow us to
> perform
> > a certain set of checks that would return result objects that KiCad
> > could later show.
> >
> > Is this approach better? If so, given my lack of knowledge about KiCad
> > codebase, I would need some help designing that interface.
> >
> > Thank you for your feedback!
> >
> >
> >
> >
> >
> >
> > El jue., 25 abr. 2019 a las 13:46, Wayne Stambaugh
> > (mailto:stambau...@gmail.com>
> >>) escribió:
> >
> >     Antonio,
> >
> >     Exactly what checks are you planning on implementing?  As long
> as they
> >     are generic in nature like off grid pin checking, then I'm
> fine with
> >     that.  If they are specific KLC checks like spacing, line
> width, etc,
> >     that is a different issue.  We should not be forcing KLC rules
> on all
> >     users.  If you wanted to make KLC style checks that can be
> customized
> >     and disabled to meet each users specific needs, I would be
> open to that.
> >
> >     This code is not in the ERC code.  Symbol library tests are
> separate
> >     from the ERC and live in the symbol editor code.  You can find the
> >     symbol library editor code in the ./eeschema/libedit folder in the
> >     source tree.
> >
> >     Thank you in your interest in contributing to KiCad.
> >
> >     Cheers,
> >
> >     Wayne
> >
> >     On 4/25/19 5:39 AM, Antonio Vázquez Blanco wrote:
> >     > I've been playing around a little bit with KiCad source code
> >     lately and
> >     > in the forums [1] I was encouraged to write to the dev
> mailing list in
> >     > order to get feedback on how to improve the current 

Re: [Kicad-developers] Some first impressions on our tool framework

[Tomasz Wlostowski]

On 06/05/2019 09:48, Jeff Young wrote:
> 1) I hate the coroutines.  They truncate backtraces in the debugger.

Hi Jeff,

I'm thinking how to improve this. Perhaps we can 'fix' a fake stack
frame that will allow the debugger to unwind the stack past the
coroutine entry point...

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] macOS build errors, swig?

[Adam Wolf]

Hi folks!

I'm still not able to get anything to build on macOS, either 10.14 or
10.11.  I keep getting:

Error: the swig import helper was not fixed, check
/vagrant/build/kicad/src/kicad-build/pcbnew/pcbnew.py
and fix this script: fix_swig_imports.py

Does anyone know anything more about this?  Is anyone else able to
make a Mac build?

Adam

On Wed, May 1, 2019 at 9:36 AM Adam Wolf  wrote:
>
> Hi folks!
>
> I'm seeing broken builds, reporting
>
> 06:14:03 default: Error: the swig import helper was not fixed, check
> /vagrant/build/kicad/src/kicad-build/pcbnew/pcbnew.py
>
> 06:14:03 default:and fix this script: fix_swig_imports.py
> 06:14:03 default: make[6]: *** [pcbnew/pcbnew_wrap.cxx] Error 2
>
> across the board on my macOS builds, both 10.11 and 10.14.
>
> This appears to be new since 9741b43da.
>
> Adam

___
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 first impressions on our tool framework

[Wayne Stambaugh]

Jeff,

On 5/6/19 10:48 AM, Jeff Young wrote:
> 1) I hate the coroutines.  They truncate backtraces in the debugger.

I'm not a big fan either but apparently they were the best solution for
the P router design.  I don't know if that is still the case or if we
even tried a different solution at the time.   Given the maintenance
issues over the years with the coroutines context switching code, I
would be willing to bet that an equally robust solution that didn't
involve coroutines would not be frowned upon.  I'm sure Tom is getting
tired of fixing the context switching code.  Wait until someone files a
bug report that the RiscV chip context switching code has to be added to
support that platform across multiple compilers. ;)

> 
> 2) Having individual event loops for drawing, moving, etc. hugely improves 
> encapsulation.

This has always been my preferred solution assuming we can pull it off
with out any degradation of the P router performance.  It always
seemed to me that dovetailing event handlers in the event handler stack
would be a simple way to provide tool specific behavior without having
to fall back to coroutines or threads but I never tried it so I cannot
say for sure if this is possible or not.

> 
> 3) The improved encapsulation does make debugging easier overall.  It’s still 
> a pity about (1) though.>
> 4) It can be a bit hard to remember all the moving pieces required.  (Hotkey 
> translation, action definition, transistion, etc.)

I think this is true with event driven designs in general.  Although
coroutines add another layer of complexity on top of that.  You can just
as easily create the same issue by yielding in the middle of an event
handler.  I don't claim to be an authority on all of this but I know the
issues that we have had to deal with.  I don't want to spend time on
this during v6 development but it's something we could take a look at
during v7.

Wayne

> 
> 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] Pcbnew display origin transforms for v6

[Reece R. Pollack]

John,

I've already jumped to clang-format 6.0, which is one of the optional installs 
for Mint 18. That works, once you get all the symlinks fixed, except it keeps 
wanting to reformat my switch statements like this, which is contrary to the 
KiCad coding standards:

@@ -148,15 +130,9 @@ int PCB_ORIGIN_TRANSFORM_Y_ABS::FromDisplay( int aValue ) 
const
 case ORIGIN_REFERENCE_PAGE:
 // No-op
 break;
-    case ORIGIN_REFERENCE_AUX:
-    origin = m_PcbBaseFrame->GetAuxOrigin().y;
-    break;
-    case ORIGIN_REFERENCE_GRID:
-    origin = m_PcbBaseFrame->GetGridOrigin().y;
-    break;
-    default:
-    wxASSERT(false);
-    break;
+    case ORIGIN_REFERENCE_AUX: origin = m_PcbBaseFrame->GetAuxOrigin().y; 
break;
+    case ORIGIN_REFERENCE_GRID: origin = m_PcbBaseFrame->GetGridOrigin().y; 
break;
+    default: wxASSERT( false ); break;
 }

 // Invert the direction if needed



On 5/6/19 8:11 AM, John Beard wrote:

On 03/05/2019 19:28, Wayne Stambaugh wrote:


I'm guessing John used a later version of clang-format when he wrote the
commit hooks.  John, any ideas how to fix this or do we force devs to
use clang-format > 3.8?


I'm on Arch, so I have quite recent clang-format (8.0.0). This particular 
option has always been in the _clang-format, and seems the config was 
introduced in clang-format 3.9.

I don't really have any great idea to fix this in general. I think the options 
are:

* Tell people to use 3.9 or later (actually I don't know what options we have 
need what versions). Most distros will allow people to install newer toolchains 
(sometimes need to enable the updates/backports repos). I think clang 4 is 
available in Mint 18/Xenial, and 5 and 6 are in Xenial-updates.

* Provide multiple style files, suitable for older clangs. Then the git hook 
can feed the right one to clang-format. In this case, you might find formatting 
differences if people use older clangs.

* Remove any options that don't suit clang 3.8 (our de facto minimum version) 
and deal with the misformattings:

In this case: formatting clang-format <= 3.8 (BreakStringLiteral not available, so 
"default", which is "true"):

    std::string var =
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit, "
    "sed do eiusmod tempor incididunt ut labore et dolore magna "
    "aliqua";

Current _clang-format (BreakStringLiteral=false) with clang-format >= 3.9:

    std::string var =
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod 
tempor incididunt ut labore et dolore magna aliqua";

I suspect this happens little enough that we can deal with it in any case. 
People always need to be aware that you cannot blindly apply the formatter 
anyway. `git add -p` is the way to selectively apply formatting changes.

@Reese, could you give it a go with clang-4 and see if there are any more 
broken options?

@Wayne, any preference for how we deal with it?

Cheers,

John

___
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] eemodern branch, "return" hotkey

[Jeff Young]

Hi Dino,

No need for a bug report for this one.

Interestingly it was never implemented in the modern toolset for PCBNew either. 
 I’m going to enable it for both and we’ll see what falls out. ;)

Cheers,
Jeff.


> On 6 May 2019, at 16:10, Dino Ghilardi  wrote:
> 
> Hello everybody, I've seen a "fast fix" an eemodern, so...
> 
>   The "return" hotkey for "left-click" is not working for me on 
> 2d2b5f3e1915a270f2a51eb342f761df8b8a0122 doing a "paste" function.
> 
> Reproducing it:
>   -Select a block
>   -ctrl-c for copy
>   -ctrl-v for paste
>   
>   -enter trying to confirm after moving with cursor keys.
> 
> The enter key seems not to work.
> 
> Tried also doing a clean rebuild and nothing changed.
> 
> 
> 
> P.S.:  as Waine said not so long ago ago... "I can file a bug report if you 
> prefer".
> 
> Cheers,
>   Dino.
> ---
> Version information follows.
> ---
> 
> Application: kicad
> Version: (5.1.0-478-gd12eee9c9), debug build
> Libraries:
>wxWidgets 3.0.2
>libcurl/7.52.1 OpenSSL/1.0.2r zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 
> (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
> Platform: Linux 4.9.0-8-amd64 x86_64, 64 bit, Little endian, wxGTK
> Build Info:
>wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
>Boost: 1.69.0
>OpenCASCADE Community Edition: 6.8.0
>Curl: 7.52.1
>Compiler: GCC 6.3.0 with C++ ABI 1010
> 
> Build settings:
>USE_WX_GRAPHICS_CONTEXT=OFF
>USE_WX_OVERLAY=OFF
>KICAD_SCRIPTING=ON
>KICAD_SCRIPTING_MODULES=ON
>KICAD_SCRIPTING_PYTHON3=OFF
>KICAD_SCRIPTING_WXPYTHON=ON
>KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
>KICAD_SCRIPTING_ACTION_MENU=ON
>BUILD_GITHUB_PLUGIN=ON
>KICAD_USE_OCE=ON
>KICAD_USE_OCC=OFF
>KICAD_SPICE=ON
> 
> 
> ___
> 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] eemodern branch, "return" hotkey

[Dino Ghilardi]

Hello everybody, I've seen a "fast fix" an eemodern, so...

	The "return" hotkey for "left-click" is not working for me on 
2d2b5f3e1915a270f2a51eb342f761df8b8a0122 doing a "paste" function.


Reproducing it:
-Select a block
-ctrl-c for copy
-ctrl-v for paste

-enter trying to confirm after moving with cursor keys.

The enter key seems not to work.

Tried also doing a clean rebuild and nothing changed.



P.S.:  as Waine said not so long ago ago... "I can file a bug report if 
you prefer".


Cheers,
Dino.
---
Version information follows.
---

Application: kicad
Version: (5.1.0-478-gd12eee9c9), debug build
Libraries:
wxWidgets 3.0.2
libcurl/7.52.1 OpenSSL/1.0.2r zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 
(+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3

Platform: Linux 4.9.0-8-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
Boost: 1.69.0
OpenCASCADE Community Edition: 6.8.0
Curl: 7.52.1
Compiler: GCC 6.3.0 with C++ ABI 1010

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON


___
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] Some first impressions on our tool framework

[Jeff Young]

1) I hate the coroutines.  They truncate backtraces in the debugger.

2) Having individual event loops for drawing, moving, etc. hugely improves 
encapsulation.

3) The improved encapsulation does make debugging easier overall.  It’s still a 
pity about (1) though.

4) It can be a bit hard to remember all the moving pieces required.  (Hotkey 
translation, action definition, transistion, etc.)

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] Pcbnew display origin transforms for v6

[Kevin Cozens]

On 2019-05-06 8:11 a.m., John Beard wrote:
* Tell people to use 3.9 or later (actually I don't know what options we 
have need what versions).
I recently found an online clang configuration tool as I'm thinking of 
adding in git hooks to force a developer to follow a coding style we've 
talked about.


The configuation tool I found lets you select which version of clang you 
want to use and then only shows you the valid options for that version.


Have a look at https://zed0.co.uk/clang-format-configurator/

--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

___
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] eemodern branch

[Wayne Stambaugh]

That was quick!  Thanks Jeff.

On 5/6/19 10:32 AM, Jeff Young wrote:
> Fixed. (d12eee9c9876062e0463148a57f3b33ab016205f)
> 
>> On 6 May 2019, at 13:48, Jeff Young  wrote:
>>
>> No need.  Reproduces for me.  I’m on it.
>>
>>> On 6 May 2019, at 13:47, Wayne Stambaugh  wrote:
>>>
>>> The sheet tool is broken.  The first click starts drawing the sheet as
>>> expected.  The second click does not complete the sheet and show the
>>> sheet properties dialog and the sheet being drawn disappears.  I can
>>> file a bug report if your prefer.
>>>
>>> Wayne
>>>
>>> On 5/5/19 4:32 PM, Michael Kavanagh wrote:
 Sounds good.

 Another minor heads up, the leave hierarchical sheet menu/toolbar icon
 seems to not be hooked up.

 Cheers,
 Michael

 On Sun, 5 May 2019 at 21:22, Jeff Young >>> > wrote:

   Yeah, I had to move around a couple of the hotkeys for consistency
   with PCBNew.  Note that these debug warnings are just so we don’t
   ship a default set that already has collisions; we gracefully handle
   them if users create them.

   Cheers,
   Jeff.

>   On 5 May 2019, at 20:59, Michael Kavanagh
>   mailto:mich...@michaelkavanagh.me>>
>   wrote:
>
>   Ah, they're duplicated, both Cmd+D (I should have read the
>   message, duh!). A "Set to Defaults" fixed it.
>
>   Cheers,
>   Michael
>
>   On Sun, 5 May 2019 at 20:50, Jeff Young    > wrote:
>
>   HI Michael,
>
>   Can you go into List Hotkeys and tell me what your assignments
>   are for those two commands?
>
>   Thanks,
>   Jeff.
>
>
>>   On 5 May 2019, at 20:44, Michael Kavanagh
>>   >   > wrote:
>>
>>   Great work Jeff!
>>
>>   Minor issue, I'm getting an assert when trying to open an
>>   example project. See attached screenshot. If I "Cancel to
>>   suppress further warnings" everything seems to work fine in
>>   my limited testing.
>>
>>   Cheers,
>>   Michael
>>
>>   On Sun, 5 May 2019 at 19:57, Jeff Young >   > wrote:
>>
>>   Branch is in.  Please let me know if you see anything funny….
>>
>>   Cheers,
>>   Jeff.
>>
>>   PS: most of the ordering in the tool context menus is
>>   just a first guess.  If you see something that should
>>   move, holler.
>>
>>
>>>   On 5 May 2019, at 18:46, Tomasz Wlostowski
>>>   >>   > wrote:
>>>
>>>   ++
>>>
>>>   05.05.2019 11:40 Seth Hillbrand >>   > napisał(a):
>>>   +1
>>>
>>>   Am 2019-05-05 13:33, schrieb Jon Evans:
 +1
 Merge it and get more testing.  It's already worlds better than the
 status quo.

 On Sun, May 5, 2019 at 12:12 PM Jeff Young >>> > wrote:

> I think this is ready to merge.  Any objections?
>
> ___
> 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
>>
>>   ___
>>   Mailing list: https://launchpad.net/~kicad-developers

Re: [Kicad-developers] eemodern branch

[Jeff Young]

Fixed. (d12eee9c9876062e0463148a57f3b33ab016205f)

> On 6 May 2019, at 13:48, Jeff Young  wrote:
> 
> No need.  Reproduces for me.  I’m on it.
> 
>> On 6 May 2019, at 13:47, Wayne Stambaugh  wrote:
>> 
>> The sheet tool is broken.  The first click starts drawing the sheet as
>> expected.  The second click does not complete the sheet and show the
>> sheet properties dialog and the sheet being drawn disappears.  I can
>> file a bug report if your prefer.
>> 
>> Wayne
>> 
>> On 5/5/19 4:32 PM, Michael Kavanagh wrote:
>>> Sounds good.
>>> 
>>> Another minor heads up, the leave hierarchical sheet menu/toolbar icon
>>> seems to not be hooked up.
>>> 
>>> Cheers,
>>> Michael
>>> 
>>> On Sun, 5 May 2019 at 21:22, Jeff Young >> > wrote:
>>> 
>>>   Yeah, I had to move around a couple of the hotkeys for consistency
>>>   with PCBNew.  Note that these debug warnings are just so we don’t
>>>   ship a default set that already has collisions; we gracefully handle
>>>   them if users create them.
>>> 
>>>   Cheers,
>>>   Jeff.
>>> 
   On 5 May 2019, at 20:59, Michael Kavanagh
   mailto:mich...@michaelkavanagh.me>>
   wrote:
 
   Ah, they're duplicated, both Cmd+D (I should have read the
   message, duh!). A "Set to Defaults" fixed it.
 
   Cheers,
   Michael
 
   On Sun, 5 May 2019 at 20:50, Jeff Young >>>   > wrote:
 
   HI Michael,
 
   Can you go into List Hotkeys and tell me what your assignments
   are for those two commands?
 
   Thanks,
   Jeff.
 
 
>   On 5 May 2019, at 20:44, Michael Kavanagh
>      > wrote:
> 
>   Great work Jeff!
> 
>   Minor issue, I'm getting an assert when trying to open an
>   example project. See attached screenshot. If I "Cancel to
>   suppress further warnings" everything seems to work fine in
>   my limited testing.
> 
>   Cheers,
>   Michael
> 
>   On Sun, 5 May 2019 at 19:57, Jeff Young    > wrote:
> 
>   Branch is in.  Please let me know if you see anything funny….
> 
>   Cheers,
>   Jeff.
> 
>   PS: most of the ordering in the tool context menus is
>   just a first guess.  If you see something that should
>   move, holler.
> 
> 
>>   On 5 May 2019, at 18:46, Tomasz Wlostowski
>>   >   > wrote:
>> 
>>   ++
>> 
>>   05.05.2019 11:40 Seth Hillbrand >   > napisał(a):
>>   +1
>> 
>>   Am 2019-05-05 13:33, schrieb Jon Evans:
>>> +1
>>> Merge it and get more testing.  It's already worlds better than the
>>> status quo.
>>> 
>>> On Sun, May 5, 2019 at 12:12 PM Jeff Young >> > wrote:
>>> 
 I think this is ready to merge.  Any objections?
 
 ___
 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
> 
>   ___
>   Mailing list: https://launchpad.net/~kicad-developers
>   Post to : kicad-developers@lists.launchpad.net
>   
>   Unsubscribe : 

Re: [Kicad-developers] eemodern branch

[Jeff Young]

No need.  Reproduces for me.  I’m on it.

> On 6 May 2019, at 13:47, Wayne Stambaugh  wrote:
> 
> The sheet tool is broken.  The first click starts drawing the sheet as
> expected.  The second click does not complete the sheet and show the
> sheet properties dialog and the sheet being drawn disappears.  I can
> file a bug report if your prefer.
> 
> Wayne
> 
> On 5/5/19 4:32 PM, Michael Kavanagh wrote:
>> Sounds good.
>> 
>> Another minor heads up, the leave hierarchical sheet menu/toolbar icon
>> seems to not be hooked up.
>> 
>> Cheers,
>> Michael
>> 
>> On Sun, 5 May 2019 at 21:22, Jeff Young > > wrote:
>> 
>>Yeah, I had to move around a couple of the hotkeys for consistency
>>with PCBNew.  Note that these debug warnings are just so we don’t
>>ship a default set that already has collisions; we gracefully handle
>>them if users create them.
>> 
>>Cheers,
>>Jeff.
>> 
>>>On 5 May 2019, at 20:59, Michael Kavanagh
>>>mailto:mich...@michaelkavanagh.me>>
>>>wrote:
>>> 
>>>Ah, they're duplicated, both Cmd+D (I should have read the
>>>message, duh!). A "Set to Defaults" fixed it.
>>> 
>>>Cheers,
>>>Michael
>>> 
>>>On Sun, 5 May 2019 at 20:50, Jeff Young >>> wrote:
>>> 
>>>HI Michael,
>>> 
>>>Can you go into List Hotkeys and tell me what your assignments
>>>are for those two commands?
>>> 
>>>Thanks,
>>>Jeff.
>>> 
>>> 
On 5 May 2019, at 20:44, Michael Kavanagh
>>>> wrote:
 
Great work Jeff!
 
Minor issue, I'm getting an assert when trying to open an
example project. See attached screenshot. If I "Cancel to
suppress further warnings" everything seems to work fine in
my limited testing.
 
Cheers,
Michael
 
On Sun, 5 May 2019 at 19:57, Jeff Young >>>> wrote:
 
Branch is in.  Please let me know if you see anything funny….
 
Cheers,
Jeff.
 
PS: most of the ordering in the tool context menus is
just a first guess.  If you see something that should
move, holler.
 
 
>On 5 May 2019, at 18:46, Tomasz Wlostowski
>> wrote:
> 
>++
> 
>05.05.2019 11:40 Seth Hillbrand > napisał(a):
>+1
> 
>Am 2019-05-05 13:33, schrieb Jon Evans:
>> +1
>> Merge it and get more testing.  It's already worlds better than the
>> status quo.
>>  
>> On Sun, May 5, 2019 at 12:12 PM Jeff Young > > wrote:
>>  
>>> I think this is ready to merge.  Any objections?
>>>  
>>> ___
>>> 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
 
___
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] eemodern branch

[Wayne Stambaugh]

The sheet tool is broken.  The first click starts drawing the sheet as
expected.  The second click does not complete the sheet and show the
sheet properties dialog and the sheet being drawn disappears.  I can
file a bug report if your prefer.

Wayne

On 5/5/19 4:32 PM, Michael Kavanagh wrote:
> Sounds good.
> 
> Another minor heads up, the leave hierarchical sheet menu/toolbar icon
> seems to not be hooked up.
> 
> Cheers,
> Michael
> 
> On Sun, 5 May 2019 at 21:22, Jeff Young  > wrote:
> 
> Yeah, I had to move around a couple of the hotkeys for consistency
> with PCBNew.  Note that these debug warnings are just so we don’t
> ship a default set that already has collisions; we gracefully handle
> them if users create them.
> 
> Cheers,
> Jeff.
> 
>> On 5 May 2019, at 20:59, Michael Kavanagh
>> mailto:mich...@michaelkavanagh.me>>
>> wrote:
>>
>> Ah, they're duplicated, both Cmd+D (I should have read the
>> message, duh!). A "Set to Defaults" fixed it.
>>
>> Cheers,
>> Michael
>>
>> On Sun, 5 May 2019 at 20:50, Jeff Young > > wrote:
>>
>> HI Michael,
>>
>> Can you go into List Hotkeys and tell me what your assignments
>> are for those two commands?
>>
>> Thanks,
>> Jeff.
>>
>>
>>> On 5 May 2019, at 20:44, Michael Kavanagh
>>> >> > wrote:
>>>
>>> Great work Jeff!
>>>
>>> Minor issue, I'm getting an assert when trying to open an
>>> example project. See attached screenshot. If I "Cancel to
>>> suppress further warnings" everything seems to work fine in
>>> my limited testing.
>>>
>>> Cheers,
>>> Michael
>>>
>>> On Sun, 5 May 2019 at 19:57, Jeff Young >> > wrote:
>>>
>>> Branch is in.  Please let me know if you see anything funny….
>>>
>>> Cheers,
>>> Jeff.
>>>
>>> PS: most of the ordering in the tool context menus is
>>> just a first guess.  If you see something that should
>>> move, holler.
>>>
>>>
 On 5 May 2019, at 18:46, Tomasz Wlostowski
 >>> > wrote:

 ++

 05.05.2019 11:40 Seth Hillbrand >>> > napisał(a):
 +1

 Am 2019-05-05 13:33, schrieb Jon Evans:
 > +1
 > Merge it and get more testing.  It's already worlds better 
 than the
 > status quo.
 > 
 > On Sun, May 5, 2019 at 12:12 PM Jeff Young >>> > wrote:
 > 
 >> I think this is ready to merge.  Any objections?
 >> 
 >> ___
 >> 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
>>>
>>> ___
>>> 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] Cross-probe: select or highlight?

[Nick Østergaard]

I guess this is sort of related to the observation and response I got here:

https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg27587.html

Or maybe I misunderstand what exactly you mean.

On Mon, 6 May 2019 at 12:38, Jeff Young  wrote:
>
> Eelik reported that our cross-probing is inconsistent.  Symbols are 
> highlighted while footprints are selected.
>
> Is there a reason for them being different?
>
> If not, I presume uniformly highlighting would be better than uniformly 
> selecting?
> ___
> 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] Pcbnew display origin transforms for v6

[John Beard]

On 03/05/2019 19:28, Wayne Stambaugh wrote:


I'm guessing John used a later version of clang-format when he wrote the
commit hooks.  John, any ideas how to fix this or do we force devs to
use clang-format > 3.8?


I'm on Arch, so I have quite recent clang-format (8.0.0). This 
particular option has always been in the _clang-format, and seems the 
config was introduced in clang-format 3.9.


I don't really have any great idea to fix this in general. I think the 
options are:


* Tell people to use 3.9 or later (actually I don't know what options we 
have need what versions). Most distros will allow people to install 
newer toolchains (sometimes need to enable the updates/backports repos). 
I think clang 4 is available in Mint 18/Xenial, and 5 and 6 are in 
Xenial-updates.


* Provide multiple style files, suitable for older clangs. Then the git 
hook can feed the right one to clang-format. In this case, you might 
find formatting differences if people use older clangs.


* Remove any options that don't suit clang 3.8 (our de facto minimum 
version) and deal with the misformattings:


In this case: formatting clang-format <= 3.8 (BreakStringLiteral not 
available, so "default", which is "true"):


std::string var =
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, "
"sed do eiusmod tempor incididunt ut labore et dolore magna "
"aliqua";

Current _clang-format (BreakStringLiteral=false) with clang-format >= 3.9:

std::string var =
"Lorem ipsum dolor sit amet, consectetur adipiscing elit, 
sed do eiusmod tempor incididunt ut labore et dolore magna aliqua";


I suspect this happens little enough that we can deal with it in any 
case. People always need to be aware that you cannot blindly apply the 
formatter anyway. `git add -p` is the way to selectively apply 
formatting changes.


@Reese, could you give it a go with clang-4 and see if there are any 
more broken options?


@Wayne, any preference for how we deal with it?

Cheers,

John

___
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] Symbol editing with the latest nightly build, new eeschema toolset - does it work?

[Jeff Young]

It doesn’t work for anyone in last night’s build.  The mouse handling got lost 
in a recent merge.  (It’s now fixed if you do your own build, or you can wait 
for tonight’s nightly.)

Cheers,
Jeff.


> On 6 May 2019, at 12:06, Eeli Kaikkonen  wrote:
> 
> A quick question. I can't edit symbols (the editor's tools don't work at all, 
> at least graphic lines and pins) with the latest nightly build on Windows. 
> Going back to 5.1.2 helps. Has anyone tried symbol editing with a version 
> with modern toolset in eeschema? Or maybe it's not related to the modern 
> toolset. But does it work for others?
> 
> 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

Re: [Kicad-developers] [PATCH] Replace remaining Boost Mutexes with std::mutex

[John Beard]

Hi Ian,

On 05/05/2019 15:58, Ian McInerney wrote:
I saw that on the todo list along with the 
auto_ptr replacement and decided to take a stab at it.


Thank you for taking the initiative here, and thanks also for updating 
the TODO list!


doing the auto_ptr replacement part since when I looked through the code 
it seems they are only used in the sch_lib_table files, which I believe 
would be part of the overhaul for v6 with the new file formats. Whoever 
ends up working with those parts can do the replacements then


Yep, it's likely to be an area of heavy development. C++17 is (sadly) 
not likely to be in KiCad any time soon, as the older supported 
platforms don't have compiler support by default.



that will take care of all the parts in the C++11 technical todo list.


There's probably more, if you see anything deserving of a place, let me 
know, and I'll add it to the list.


Thanks again,

John

___
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] Symbol editing with the latest nightly build, new eeschema toolset - does it work?

[Eeli Kaikkonen]

A quick question. I can't edit symbols (the editor's tools don't work at
all, at least graphic lines and pins) with the latest nightly build on
Windows. Going back to 5.1.2 helps. Has anyone tried symbol editing with a
version with modern toolset in eeschema? Or maybe it's not related to the
modern toolset. But does it work for others?

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

[Kicad-developers] Cross-probe: select or highlight?

[Jeff Young]

Eelik reported that our cross-probing is inconsistent.  Symbols are highlighted 
while footprints are selected.

Is there a reason for them being different?

If not, I presume uniformly highlighting would be better than uniformly 
selecting?
___
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