Re: [Kicad-developers] [PATCH] Fix crash on footprint filter tab

[Jeff Young]

Thanks for your contribution to Kicad, Damien!

(It actually counted double.  I at first misunderstood your report and found 
another bug deleting something else with nothing selected.)

I’ll merge your patch momentarily….

Cheers,
Jeff.

> On 5 Jun 2018, at 22:40, Damien Espitallier  
> wrote:
> 
> Hi,
> 
> This very small patch checks that a footprint is selected before running the 
> action when clicking on the delete button of the footprint filter window 
> (symbol editing). The check is already done on every other actions of the 
> window.
> 
> Damien
> <0001-Fix-crash-when-delete-button-of-footprint-filter-is-.patch>___
> 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] [PATCH] Fix crash on footprint filter tab

[Damien Espitallier]

Hi,

This very small patch checks that a footprint is selected before running
the action when clicking on the delete button of the footprint filter
window (symbol editing). The check is already done on every other actions
of the window.

Damien
From 46bf6df7f7ae81c58a78afa2f879d515bb14371a Mon Sep 17 00:00:00 2001
From: Damien Espitallier 
Date: Tue, 5 Jun 2018 23:33:49 +0200
Subject: [PATCH] Fix crash when delete button of footprint filter is clicked
 and no footprint is selected
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.17.1"

This is a multi-part message in MIME format.
--2.17.1
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
 eeschema/dialogs/dialog_edit_component_in_lib.cpp | 5 +
 1 file changed, 5 insertions(+)


--2.17.1
Content-Type: text/x-patch; name="0001-Fix-crash-when-delete-button-of-footprint-filter-is-.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-crash-when-delete-button-of-footprint-filter-is-.patch"

diff --git a/eeschema/dialogs/dialog_edit_component_in_lib.cpp b/eeschema/dialogs/dialog_edit_component_in_lib.cpp
index 7392da993..bc154d099 100644
--- a/eeschema/dialogs/dialog_edit_component_in_lib.cpp
+++ b/eeschema/dialogs/dialog_edit_component_in_lib.cpp
@@ -555,6 +555,11 @@ void DIALOG_EDIT_COMPONENT_IN_LIBRARY::DeleteOneFootprintFilter( wxCommandEvent&
 LIB_PART*  component = m_Parent->GetCurPart();
 int ii = m_FootprintFilterListBox->GetSelection();
 
+if( ii == wxNOT_FOUND )
+{
+return;
+}
+
 m_FootprintFilterListBox->Delete( ii );
 
 if( !component || ( m_FootprintFilterListBox->GetCount() == 0 ) )

--2.17.1--


___
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] Another problem with the generic (XML) netlist exporter

[Jeff Young]

Well, the BOM generators we ship with the product output the (other) 
description field as well.

I’ll go with the less-invasive approach of adding an attribute to the 
 element.

Cheers,
Jeff.

> On 4 Jun 2018, at 11:56, jp charras  wrote:
> 
> Le 03/06/2018 à 22:52, Jeff Young a écrit :
>> Hi JP,
>> 
>> What are you considering the “description” in that?
>> 
>> Here’s what I’m seeing (interesting bits highlighted in red):
>> 
>>   
>> ECC83
>> Valves:VALVE-NOVAL_
>> http://www.r-type.org/pdfs/ecc83.pdf
>> 
>> 
>> 5B141B34
>>   
> 
> From the point of view of a BOM, 
> "http://www.r-type.org/pdfs/ecc83.pdf 
> " is
> the only one description info.
> 
> The string fields stored in libpart section are the default values, not the 
> actual values (that can
> be edited by the designer inside the schematic).
> 
>> 
>>   ...
>>   
>>   
>> 
>>   ECC83
>> 
>> double triode ECC81 (root part)
>> http://www.r-type.org/pdfs/ecc81.pdf
>> 
>>   VALVE*NOVAL*P*
>> 
>> 
>>   U
>>   ECC81
>>   Valves:VALVE-NOVAL_
>> 
>> 
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>> 
>>   
>> 
>> The Python code does a lookup of libparts & aliases to make a connection and 
>> then reads the (single)
>> description.
>> 
>> 
> 
> 
> 
> -- 
> 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] Netlist generation for pins with no-connects

[Sergey A. Borshch]

On 05.06.2018 16:54, Jon Evans wrote:
it seems a bit like there ought to be a better way to 
support those needs

Indeed.


but I understand and will maintain that behavior.
Can you also try to fix bug 1704083 caused by assigning different net names to 
unconnected instances of shared pins in every gate (unit).


On Tue, Jun 5, 2018 at 2:50 AM, jp charras > wrote:


Le 05/06/2018 à 04:38, Jon Evans a écrit :
 > Hi all,
 >
 > In the current netlisting algorithm, pins with no-connects sometimes
appear in the netlist, with
 > auto-generated names like Net-(U1-Pad1).
 >
 > This seems to not always happen, but I haven't investigated why yet,
since I'm approaching
 > netlisting from a different direction with my new connectivity
algorithm.  In my algorithm, a pin
 > with a no-connect attached will never generate an entry in the netlist.
 >
 > Is there some reason we should be including these pins on the netlist? 
It seems like if they are

 > marked as no-connects and don't actually connect to anything, we
shouldn't be forwarding them to the
 > layout.
 >
 > -Jon
 >

We *should* forward them to the layout.
This is the best way to detect if the footprint has missing pads (incorrect
footprint choice)

-- 
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




--
Regards,
  Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia


___
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] Netlist generation for pins with no-connects

[Jon Evans]

OK, these are good points, it seems a bit like there ought to be a better
way to support those needs but I understand and will maintain that behavior.

On Tue, Jun 5, 2018 at 2:50 AM, jp charras  wrote:

> Le 05/06/2018 à 04:38, Jon Evans a écrit :
> > Hi all,
> >
> > In the current netlisting algorithm, pins with no-connects sometimes
> appear in the netlist, with
> > auto-generated names like Net-(U1-Pad1).
> >
> > This seems to not always happen, but I haven't investigated why yet,
> since I'm approaching
> > netlisting from a different direction with my new connectivity
> algorithm.  In my algorithm, a pin
> > with a no-connect attached will never generate an entry in the netlist.
> >
> > Is there some reason we should be including these pins on the netlist?
> It seems like if they are
> > marked as no-connects and don't actually connect to anything, we
> shouldn't be forwarding them to the
> > layout.
> >
> > -Jon
> >
>
> We *should* forward them to the layout.
> This is the best way to detect if the footprint has missing pads
> (incorrect footprint choice)
>
> --
> 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] [PATCH] Fix 'catching polymorphic type by value' warnings

[Maciej Sumiński]

Thank you John, I have just pushed your patch.

Cheers,
Orson

On 06/05/2018 10:02 AM, John Beard wrote:
> Hi,
> 
> Sorry, I missed one out in kicad/import_project.cpp
> 
> Cheers,
> 
> John
> 
> On Tue, Jun 5, 2018 at 8:43 AM, John Beard  wrote:
> 
>> Hi,
>>
>> Small patch to fix some warnings (GCC 8.1.0) like this:
>>
>> warning: catching polymorphic type ‘class std::out_of_range’ by value
>> [-Wcatch-value=]
>>  catch( std::out_of_range )
>>  ^~~~
>>
>> Fixed by changing to catch-by-reference: "catch( const std:::out_of_range&
>> )"
>>
>> C.f. recent commit ff1802d7a "Fix Coverity "Big parameter passed by value"
>> warnings".
>>
>> As one of these fixes is in view.h, the warning came up a fair bit.
>>
>> 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
> 




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] [PATCH] Fix 'catching polymorphic type by value' warnings

[John Beard]

Hi,

Sorry, I missed one out in kicad/import_project.cpp

Cheers,

John

On Tue, Jun 5, 2018 at 8:43 AM, John Beard  wrote:

> Hi,
>
> Small patch to fix some warnings (GCC 8.1.0) like this:
>
> warning: catching polymorphic type ‘class std::out_of_range’ by value
> [-Wcatch-value=]
>  catch( std::out_of_range )
>  ^~~~
>
> Fixed by changing to catch-by-reference: "catch( const std:::out_of_range&
> )"
>
> C.f. recent commit ff1802d7a "Fix Coverity "Big parameter passed by value"
> warnings".
>
> As one of these fixes is in view.h, the warning came up a fair bit.
>
> Cheers,
>
> John
>
From dfe24f872bcc9665efbddd949e19a538258b5e12 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 5 Jun 2018 08:38:49 +0100
Subject: [PATCH] Common: Fix -Wcatch-value warnings (catching exceptions by
 value)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This fixes some warnings on GCC 8.1:

warning: catching polymorphic type ‘class std::out_of_range’ by value [-Wcatch-value=]
 catch( std::out_of_range )
 ^~~~

This fix is along the same lines as:

* ff1802d7a "Fix Coverity "Big parameter passed by value" warnings"
---
 common/view/view.cpp | 4 ++--
 include/view/view.h  | 2 +-
 kicad/import_project.cpp | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/common/view/view.cpp b/common/view/view.cpp
index d4e22ff6b..84f848cd4 100644
--- a/common/view/view.cpp
+++ b/common/view/view.cpp
@@ -207,7 +207,7 @@ private:
 {
 new_layer = aReorderMap.at( orig_layer );
 }
-catch( std::out_of_range ) {}
+catch( const std::out_of_range& ) {}
 
 m_groups[i].first = new_layer;
 }
@@ -665,7 +665,7 @@ void VIEW::ReorderLayerData( std::unordered_map aReorderMap )
 {
 new_idx = aReorderMap.at( orig_idx );
 }
-catch( std::out_of_range )
+catch( const std::out_of_range& )
 {
 new_idx = orig_idx;
 }
diff --git a/include/view/view.h b/include/view/view.h
index 1397b4d54..3938bfdf8 100644
--- a/include/view/view.h
+++ b/include/view/view.h
@@ -590,7 +590,7 @@ public:
 {
 return m_layers.at( aLayer ).target == TARGET_CACHED;
 }
-catch( std::out_of_range )
+catch( const std::out_of_range& )
 {
 return false;
 }
diff --git a/kicad/import_project.cpp b/kicad/import_project.cpp
index 4f9d04360..3bcc7bb9f 100644
--- a/kicad/import_project.cpp
+++ b/kicad/import_project.cpp
@@ -165,7 +165,7 @@ void KICAD_MANAGER_FRAME::OnImportEagleFiles( wxCommandEvent& event )
 {
 pcbframe = Kiway.Player( FRAME_PCB, true );
 }
-catch( IO_ERROR err )
+catch( const IO_ERROR& err )
 {
 wxMessageBox( _( "Pcbnew failed to load:\n" ) + err.What(), _( "KiCad Error" ),
 wxOK | wxICON_ERROR, this );
-- 
2.17.1

___
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] [PATCH] Fix 'catching polymorphic type by value' warnings

[John Beard]

Hi,

Small patch to fix some warnings (GCC 8.1.0) like this:

warning: catching polymorphic type ‘class std::out_of_range’ by value
[-Wcatch-value=]
 catch( std::out_of_range )
 ^~~~

Fixed by changing to catch-by-reference: "catch( const std:::out_of_range&
)"

C.f. recent commit ff1802d7a "Fix Coverity "Big parameter passed by value"
warnings".

As one of these fixes is in view.h, the warning came up a fair bit.

Cheers,

John
From 24c862577174450ba2a591797e2f6dd6b188e87c Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Tue, 5 Jun 2018 08:38:49 +0100
Subject: [PATCH] Common: Fix -Wcatch-value warnings (catching exceptions by
 value)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This fixes some warnings on GCC 8.1:

warning: catching polymorphic type ‘class std::out_of_range’ by value [-Wcatch-value=]
 catch( std::out_of_range )
 ^~~~

This fix is along the same lines as:

* ff1802d7a "Fix Coverity "Big parameter passed by value" warnings"
---
 common/view/view.cpp | 4 ++--
 include/view/view.h  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/view/view.cpp b/common/view/view.cpp
index d4e22ff6b..84f848cd4 100644
--- a/common/view/view.cpp
+++ b/common/view/view.cpp
@@ -207,7 +207,7 @@ private:
 {
 new_layer = aReorderMap.at( orig_layer );
 }
-catch( std::out_of_range ) {}
+catch( const std::out_of_range& ) {}
 
 m_groups[i].first = new_layer;
 }
@@ -665,7 +665,7 @@ void VIEW::ReorderLayerData( std::unordered_map aReorderMap )
 {
 new_idx = aReorderMap.at( orig_idx );
 }
-catch( std::out_of_range )
+catch( const std::out_of_range& )
 {
 new_idx = orig_idx;
 }
diff --git a/include/view/view.h b/include/view/view.h
index 1397b4d54..3938bfdf8 100644
--- a/include/view/view.h
+++ b/include/view/view.h
@@ -590,7 +590,7 @@ public:
 {
 return m_layers.at( aLayer ).target == TARGET_CACHED;
 }
-catch( std::out_of_range )
+catch( const std::out_of_range& )
 {
 return false;
 }
-- 
2.17.1

___
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] Netlist generation for pins with no-connects

[jp charras]

Le 05/06/2018 à 04:38, Jon Evans a écrit :
> Hi all,
> 
> In the current netlisting algorithm, pins with no-connects sometimes appear 
> in the netlist, with
> auto-generated names like Net-(U1-Pad1).
> 
> This seems to not always happen, but I haven't investigated why yet, since 
> I'm approaching
> netlisting from a different direction with my new connectivity algorithm.  In 
> my algorithm, a pin
> with a no-connect attached will never generate an entry in the netlist.
> 
> Is there some reason we should be including these pins on the netlist?  It 
> seems like if they are
> marked as no-connects and don't actually connect to anything, we shouldn't be 
> forwarding them to the
> layout.
> 
> -Jon
> 

We *should* forward them to the layout.
This is the best way to detect if the footprint has missing pads (incorrect 
footprint choice)

-- 
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