[Kicad-developers] Board Edge clearance problem

[Strontium]

My second "show stopper" bug for me, using V5 RC2

I also reported this in the bug tracker, again sorry for the double up.

I was trying to layout a board, but Kicad is refusing to let me lay 
tracks or vias in close proximity to the board edge.  Its highlighting 
the edge, and ignoring any command to drop the via or track segment.


The problem is, this proximity seems to be uncontrollable, I can't find 
any option which sets it, or even references it.


Further, the proximity is a really long way from the board edge, which 
makes routing a tight board tedious because you need this excessive and 
unnecessary border.


For example, this is fine: http://i.imgur.com/5hAzrhL.png

But this is not: http://i.imgur.com/2wBHePK.png

You can also see the "halo" is well over the via, and would cover it in 
both positions.


So, it just looks and feels wrong, and seems totally uncontrollable.  I 
should be able to place the annular ring of the via right up against the 
edge of the fill of the zone.  Now it may be this isn't a bug and i have 
my setup wrong, and i would be pleased if it were the case, but if it is 
so, then the option controlling this isn't obvious at all, and the halo 
being shown still looks wildly off.


Steven


___
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] Zone filling problems

[Strontium]

Sorry for posting this, AND also posting a bug report, but i know you 
guys are close to releasing a V5 and i have been testing RC2 from 
nightly PPA and have hit two bugs which would be show stoppers for me, 
and make me want to go back to V4.


First one is a problem with Zone refills using DRC.

If I have a zone, and place a via or track over it from another net.  
And then do a DRC, but select "Refill all zones..." then the DRC 
proceeds without error, and says it refilled the Zone.


However, a visual inspection of the board shows, no the zone did not 
refill and the via and zone now clash because they are not the same net, 
but there is no DRC violation.


Thats what it looks like. But what is really happening is the zone is 
being recalculated, and the DRC is passing because the Zone does now 
actually flow properly around the net overlapping it. BUT what happens 
is the board is not redrawn to show the new zone outline.  Zooming 
around the board, etc, does not cause it to redraw either.  The only 
ways i have found to make it redraw is to manually select the zone for 
editing, or to press "B"


Its a highly disconcerting problem, because the board that kicad 
"understands" and the one it "displays" are out of sync.


The effect is obvious when one does a 3d render of the board, because 
that shows the board that kicad understands, even though in the pcb 
editor its shown as not that.  as shown here: 
http://i.imgur.com/hKfPJ22.png


the other problem i will post separately.

Steven


___
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] Embrace TransferDataTo/FromWindow

[Jeff Young]

> ...most of our dialogs do not use this.  It will be a non-trivial task to get 
> them all updated.

We could start by getting rid of the Swap Layers… dialog. ;)

https://bugs.launchpad.net/kicad/+bug/1670422 





> On 6 Mar 2018, at 21:18, Wayne Stambaugh  wrote:
> 
> This is already in the UI policy
> 
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_ui-policy.html#dialogs-xfer
> 
> The problem is a lot of developers relied on the old pattern when
> creating dialogs so most of our dialogs do not use this.  It will be a
> non-trivial task to get them all updated.
> 
> On 3/6/2018 4:08 PM, Jeff Young wrote:
>> We’ve got a lot of dialogs that don’t make use of these.  Not only does it 
>> make the code longer and more complex, it also results in bugs (the most 
>> recent being that hitting  in the Create Array… dialog does a Cancel, 
>> not an OK).
>> 
>> I’ve got to go through most all of the dialogs for the eradication of 
>> g_UserUnit in 6.0, so don’t bother to change any existing ones (we’ll just 
>> have merge conflicts).
>> 
>> But for new dialogs, please use them.
>> 
>> 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

___
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] [fun feature request] Create PCB from schematic with one click :)

[Wayne Stambaugh]

On 3/6/2018 4:18 PM, Robbert Lagerweij wrote:
> Op 5-3-2018 om 18:49 schreef Wayne Stambaugh:
>> All kidding aside, I was told by a very highly skilled board designer
>> not to waste our time with auto-routers because no one actually uses
>> them except for the simplest designs with lots of free board space and
>> few or no routing restrictions.  This is someone who uses Altium in his
>> day job and has laid out far more boards than I have.  I'm guessing
>> auto-routers appeal to hobbyists rather than professionals.
> I guess this begs the question, who is kicad targeting? Are we trying to 
> serve the professionals or also be a tool for the less skilled 
> (comparative) masses.

For those of you who are new here, the answer is professionals.  If we
can accommodate hobbyists without alienating professional designers all
the better but I will not throw professional developers under the bus to
appease the hobbyists.

> 
>> There are far more useful features to add to KiCad
>> than auto-routing.  If we ever get to the point we are sitting around
>> twiddling our thumbs, then we should work on an auto-router.
> I absolutely agree, but after reading this article 
> https://wp.josh.com/2017/10/23/adventures-in-autorouting/, I did find 
> myself wondering what a Google Summer of Code Student (with some 
> opencl/machine learning/other buzzword skills) might be able to do with 
> the auto-router.

I'm not going to hold my breath on that one.  How many students do you
know that are expert board designers?  I'll lean on my developers who
understand how to layout a board for this one.  I'm not a buzz word kind
of developer. ;)

> 
> Robbert
> ___
> 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] Embrace TransferDataTo/FromWindow

[Wayne Stambaugh]

This is already in the UI policy

http://docs.kicad-pcb.org/doxygen/md_Documentation_development_ui-policy.html#dialogs-xfer

The problem is a lot of developers relied on the old pattern when
creating dialogs so most of our dialogs do not use this.  It will be a
non-trivial task to get them all updated.

On 3/6/2018 4:08 PM, Jeff Young wrote:
> We’ve got a lot of dialogs that don’t make use of these.  Not only does it 
> make the code longer and more complex, it also results in bugs (the most 
> recent being that hitting  in the Create Array… dialog does a Cancel, 
> not an OK).
> 
> I’ve got to go through most all of the dialogs for the eradication of 
> g_UserUnit in 6.0, so don’t bother to change any existing ones (we’ll just 
> have merge conflicts).
> 
> But for new dialogs, please use them.
> 
> 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] [fun feature request] Create PCB from schematic with one click :)

[Robbert Lagerweij]

Op 5-3-2018 om 18:49 schreef Wayne Stambaugh:
> All kidding aside, I was told by a very highly skilled board designer
> not to waste our time with auto-routers because no one actually uses
> them except for the simplest designs with lots of free board space and
> few or no routing restrictions.  This is someone who uses Altium in his
> day job and has laid out far more boards than I have.  I'm guessing
> auto-routers appeal to hobbyists rather than professionals.
I guess this begs the question, who is kicad targeting? Are we trying to 
serve the professionals or also be a tool for the less skilled 
(comparative) masses.

> There are far more useful features to add to KiCad
> than auto-routing.  If we ever get to the point we are sitting around
> twiddling our thumbs, then we should work on an auto-router.
I absolutely agree, but after reading this article 
https://wp.josh.com/2017/10/23/adventures-in-autorouting/, I did find 
myself wondering what a Google Summer of Code Student (with some 
opencl/machine learning/other buzzword skills) might be able to do with 
the auto-router.

Robbert
___
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] Potential issue with 49486b83

[Jeff Young]

It’s up, Kevin.  Thanks for offering to test.

Cheers,
Jeff.


> On 6 Mar 2018, at 20:33, Kevin Cozens  wrote:
> 
> On 2018-03-06 02:19 PM, Jeff Young wrote:
>> I’m going to merge a conditional compilation fix for this (I agree that we 
>> don’t want to chase anyone away from the debug versions).
> 
> I'll test the patch on my machine when you have it ready. Thanks, Jeff.
> 
> -- 
> Cheers!
> 
> Kevin.
> 
> http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
> Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
>| powerful!"
> #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


___
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] Embrace TransferDataTo/FromWindow

[Jeff Young]

We’ve got a lot of dialogs that don’t make use of these.  Not only does it make 
the code longer and more complex, it also results in bugs (the most recent 
being that hitting  in the Create Array… dialog does a Cancel, not an 
OK).

I’ve got to go through most all of the dialogs for the eradication of 
g_UserUnit in 6.0, so don’t bother to change any existing ones (we’ll just have 
merge conflicts).

But for new dialogs, please use them.

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] Potential issue with 49486b83

[Kevin Cozens]

On 2018-03-06 02:19 PM, Jeff Young wrote:
I’m going to merge a conditional compilation fix for this (I agree that we 
don’t want to chase anyone away from the debug versions).


I'll test the patch on my machine when you have it ready. Thanks, Jeff.

--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#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] Proposed roadmap changes

[Jon Evans]

I will be sure to send a proposed update to the official doc after there is
no more churn on my scratch pad doc.
I am not allowing anyone to edit, only I can edit (anyone can comment, and
I have been incorporating changes based on people's comments)

I think the next pass (now that it has been a day with no one making any
more comments on my doc) is to think about who is going to do what to make
sure the manpower thing makes sense.

-Jon

On Tue, Mar 6, 2018 at 2:33 PM, Wayne Stambaugh 
wrote:

> I'm fine with using this for bike shedding as long as the results get
> updated in the actual road map and this is not the official road map.
> One caveat, by allowing anyone to edit this file, you may loose control
> of it's content.  That's one of the things I don't like about launchpads
> blueprints.  I also don't want this to turn into a popularity contest.
> We have to make sensible decisions based upon project requirements and
> manpower limitations so all final decisions are made by the lead
> development team.
>
> On 3/5/2018 12:57 PM, Jon Evans wrote:
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc,
> > I've had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play
> > with; I'm happy to send patches against the official roadmaps if get
> > some buy-in for this.
> >
> > Feel free to comment (either directly on the doc or by email) with
> > thoughts on this.
> >
> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF
> 7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into Eeschema
> > for 6.0, with changes to other parts of the software basically being
> > "whatever people have time left over for".  Everything else has been
> > bumped to 7.0
> >
> > -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] Proposed roadmap changes

[José Ignacio]

Only jon can edit, our "edits" are just suggestions, which can be accepted
or rejected.

On Tue, Mar 6, 2018 at 1:33 PM, Wayne Stambaugh 
wrote:

> I'm fine with using this for bike shedding as long as the results get
> updated in the actual road map and this is not the official road map.
> One caveat, by allowing anyone to edit this file, you may loose control
> of it's content.  That's one of the things I don't like about launchpads
> blueprints.  I also don't want this to turn into a popularity contest.
> We have to make sensible decisions based upon project requirements and
> manpower limitations so all final decisions are made by the lead
> development team.
>
> On 3/5/2018 12:57 PM, Jon Evans wrote:
> > Hi all,
> >
> > Since my day job involves a lot of engineering planning/timelines/etc,
> > I've had this rolling around in my head...
> > I started brainstorming some proposed changes to the roadmaps.
> >
> > I am using Google drive because that's what is easiest for me to play
> > with; I'm happy to send patches against the official roadmaps if get
> > some buy-in for this.
> >
> > Feel free to comment (either directly on the doc or by email) with
> > thoughts on this.
> >
> > https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF
> 7ooTtcT_HU86kw/edit#
> >
> > Basically what I am proposing is to put most of the energy into Eeschema
> > for 6.0, with changes to other parts of the software basically being
> > "whatever people have time left over for".  Everything else has been
> > bumped to 7.0
> >
> > -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] Proposed roadmap changes

[Wayne Stambaugh]

I'm fine with using this for bike shedding as long as the results get
updated in the actual road map and this is not the official road map.
One caveat, by allowing anyone to edit this file, you may loose control
of it's content.  That's one of the things I don't like about launchpads
blueprints.  I also don't want this to turn into a popularity contest.
We have to make sensible decisions based upon project requirements and
manpower limitations so all final decisions are made by the lead
development team.

On 3/5/2018 12:57 PM, Jon Evans wrote:
> Hi all,
> 
> Since my day job involves a lot of engineering planning/timelines/etc,
> I've had this rolling around in my head...
> I started brainstorming some proposed changes to the roadmaps.
> 
> I am using Google drive because that's what is easiest for me to play
> with; I'm happy to send patches against the official roadmaps if get
> some buy-in for this.
> 
> Feel free to comment (either directly on the doc or by email) with
> thoughts on this.
> 
> https://docs.google.com/document/d/1mpxqvxLv497cyfk8KTQijhySSpFxF7ooTtcT_HU86kw/edit#
> 
> Basically what I am proposing is to put most of the energy into Eeschema
> for 6.0, with changes to other parts of the software basically being
> "whatever people have time left over for".  Everything else has been
> bumped to 7.0
> 
> -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

Re: [Kicad-developers] Potential issue with 49486b83

[Maciej Suminski]

Jean-Pierre,

Is the jumpy canvas [1] on first panning fixed with newer wxWidgets
version on Linux? If so, what version do you use?

I see it occurring on 3.0.3 and I also get the assert. Wayne said the
recent patch did not help on Windows, so we can either make the change
specific to macOS or to wxWidgets version.

I agree it is a wxWidgets bug, as we use a legit flag in
wxScrolledWindow constructor, so there is no reason to complain. The
only problem here it is a bit annoying to click 'Ok' every time KiCad
starts.

Regards,
Orson

1. https://lists.launchpad.net/kicad-developers/msg34692.html

On 03/06/2018 08:09 PM, jp charras wrote:
> Le 06/03/2018 à 19:57, Steven A. Falco a écrit :
>> On 03/06/2018 01:51 PM, Kevin Cozens wrote:
>>> On 2018-03-06 01:40 PM, Steven A. Falco wrote:
 I just finished building 49486b83 for Linux (Fedora 27) and immediately 
 upon starting eechema from the main kicad window, I get an assert in 
 src/gtk/scrolwin.cpp at line 213.
>>>
>>> I ran across the same problem yesterday and filed a bug report.
>>>
>>> https://bugs.launchpad.net/kicad/+bug/1753592
>>>
>>
>> Ok, thanks.  I made a note in the bug and attached a screenshot of the 
>> assert.  I'll try a bisection, but it seems like the recent scrollbar 
>> changes may need to be reverted or modified.
>>
>>  Steve
>>
> 
> This is an assert only in debug mode with wxWidgets 3.0.2 and only on Linux.
> It is perhaps a bug in wxWidgets.
> I rebuilt Kicad against latest wxWidgets (current git version) and I do not 
> have this assert.
> 
> So i am not sure this is a critical issue (and perhaps not an issue).
> 
> 

___
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] Potential issue with 49486b83

[Jeff Young]

Hi Steve,

I’m going to merge a conditional compilation fix for this (I agree that we 
don’t want to chase anyone away from the debug versions).

But I was working on another branch so I have to do a full build to test it.  
It’ll be a few hours….

Cheers,
Jeff.


> On 6 Mar 2018, at 19:12, Steven A. Falco  wrote:
> 
> On 03/06/2018 02:09 PM, jp charras wrote:
>> Le 06/03/2018 à 19:57, Steven A. Falco a écrit :
>>> On 03/06/2018 01:51 PM, Kevin Cozens wrote:
 On 2018-03-06 01:40 PM, Steven A. Falco wrote:
> I just finished building 49486b83 for Linux (Fedora 27) and immediately 
> upon starting eechema from the main kicad window, I get an assert in 
> src/gtk/scrolwin.cpp at line 213.
 
 I ran across the same problem yesterday and filed a bug report.
 
 https://bugs.launchpad.net/kicad/+bug/1753592
 
>>> 
>>> Ok, thanks.  I made a note in the bug and attached a screenshot of the 
>>> assert.  I'll try a bisection, but it seems like the recent scrollbar 
>>> changes may need to be reverted or modified.
>>> 
>>> Steve
>>> 
>> 
>> This is an assert only in debug mode with wxWidgets 3.0.2 and only on Linux.
>> It is perhaps a bug in wxWidgets.
>> I rebuilt Kicad against latest wxWidgets (current git version) and I do not 
>> have this assert.
>> 
>> So i am not sure this is a critical issue (and perhaps not an issue).
> 
> That may be true, but it may also discourage people who are trying out the 
> nightly builds from Fedora copr.  And it wasn't happening until recently, so 
> it seems like a regression.
> 
>   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] Potential issue with 49486b83

[jp charras]

Le 06/03/2018 à 19:57, Steven A. Falco a écrit :
> On 03/06/2018 01:51 PM, Kevin Cozens wrote:
>> On 2018-03-06 01:40 PM, Steven A. Falco wrote:
>>> I just finished building 49486b83 for Linux (Fedora 27) and immediately 
>>> upon starting eechema from the main kicad window, I get an assert in 
>>> src/gtk/scrolwin.cpp at line 213.
>>
>> I ran across the same problem yesterday and filed a bug report.
>>
>> https://bugs.launchpad.net/kicad/+bug/1753592
>>
> 
> Ok, thanks.  I made a note in the bug and attached a screenshot of the 
> assert.  I'll try a bisection, but it seems like the recent scrollbar changes 
> may need to be reverted or modified.
> 
>   Steve
> 

This is an assert only in debug mode with wxWidgets 3.0.2 and only on Linux.
It is perhaps a bug in wxWidgets.
I rebuilt Kicad against latest wxWidgets (current git version) and I do not 
have this assert.

So i am not sure this is a critical issue (and perhaps not an issue).


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

Re: [Kicad-developers] Potential issue with 49486b83

[Steven A. Falco]

On 03/06/2018 01:51 PM, Kevin Cozens wrote:
> On 2018-03-06 01:40 PM, Steven A. Falco wrote:
>> I just finished building 49486b83 for Linux (Fedora 27) and immediately upon 
>> starting eechema from the main kicad window, I get an assert in 
>> src/gtk/scrolwin.cpp at line 213.
> 
> I ran across the same problem yesterday and filed a bug report.
> 
> https://bugs.launchpad.net/kicad/+bug/1753592
> 

Ok, thanks.  I made a note in the bug and attached a screenshot of the assert.  
I'll try a bisection, but it seems like the recent scrollbar changes may need 
to be reverted or modified.

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

Re: [Kicad-developers] critical bug in Spice simulator - feedback from OSX devs needed

[Seth Hillbrand]

Hi Tom-

Relevant discussion here:
https://lists.launchpad.net/kicad-developers/msg25762.html

FWIW, I don't think there's a technical reason why.

-S

2018-03-06 9:44 GMT-08:00 Tomasz Wlostowski :

> Hi,
>
> I've been trying to fix [1] without success: ngspice will not load
> another circuit if the current one contains fatal errors. Under some
> circumstances, this segfaults KiCad.
>
> The only solution I see is to bring back dynamic
> (dlopen()/wxDynamicLibrary) loading of ngspice DLL every time the
> simulator is launched, since unloading and reloading again resets
> ngspice's internal state and releases all allocated resources. The early
> versions of the simulator had worked like this but later it was changed
> to traditional linking reportedly due to some issues on OSX with dynamic
> library loading. I can't find any trace of information about these
> DLL-related issues - so I'm calling our Mac devs here to reply if
> anybody remembers why this change was done.
>
> If no one gives a solid reason to stay with a hard-linked ngspice DLL,
> I'll revert the ngspice plugin to use wxDynamicLibrary.
>
> Tom
>
> [1] https://bugs.launchpad.net/kicad/+bug/1753092
>
> ___
> 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] Potential issue with 49486b83

[Kevin Cozens]

On 2018-03-06 01:40 PM, Steven A. Falco wrote:

I just finished building 49486b83 for Linux (Fedora 27) and immediately upon 
starting eechema from the main kicad window, I get an assert in 
src/gtk/scrolwin.cpp at line 213.


I ran across the same problem yesterday and filed a bug report.

https://bugs.launchpad.net/kicad/+bug/1753592

--
Cheers!

Kevin.

http://www.ve3syb.ca/   |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!"
#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] Handling invalid characters in symbol/component LIB_IDs

[Wayne Stambaugh]

Orson,

On 3/6/2018 8:55 AM, Maciej Sumiński wrote:
> I am trying to find a reasonable way to handle symbol and components
> with invalid characters in their LIB_IDs (see bug report #1752419 [1]).
> While now it is impossible to create such LIB_IDs, we need to handle
> documents that had been created before the restriction was introduced.
> 
> LIB_IDs in SCH_COMPONENTS will have illegal characters replaced on load,
> but it is not the case for LIB_{PART,ALIAS} classes. Due to that:
> 
> - Symbol-component links are broken (e.g. component with LIB_ID
> 'Test/Name' will change to 'Test_Name', but the corresponding LIB_PART
> will remain 'Test/Name'.
> 
> - It is impossible to place/edit such symbols.
> 
> The simplest solution is to process LIB_{PART,ALIAS} LIB_IDs in the same
> way as id done for SCH_COMPONENTs, so they become valid names that match
> SCH_COMPONENTs using them (see the attached patches). There are two
> drawbacks:

I would prefer to keep the behavior consistent with what is done with
the SCH_COMPONENT LIB_ID renaming.  I know it's less than elegant but we
are going to just have to take our medicine until we transition over to
the new file format.

> 
> - Changing names that user had previously assigned, which might be
> annoying if LIB_IDs are used e.g. to create BOMs. Personally I would use
> the value field that accepts all characters for this purpose.

Can LIB_IDs be used in BOMs?  That would be an odd way to do it but I
suppose you could.  Typically the contents of the value field is used
for BOM output not the symbol name.

> 
> - Naming conflicts may occur (e.g. both 'Test/Name' and 'Test:Name' will
> be changed to 'Test_Name', but I believe it is a rare case.

I just used a simple counter to append digits to the end of the name in
the case of name conflicts in the remapping code so a similar approach
here would not be out of line.

> 
> Any thoughts? I believe a more elegant solution will be implemented once
> the new schematic file format is ready.

The current behavior is just going to last during v5.  Once the new
schematic file format is done and the LIB_ID parser and formatter
support escaping the / and : characters, we should be able to use any
character (except for control characters) in LIB_IDs.

> 
> Cheers,
> Orson
> 
> 1. https://bugs.launchpad.net/kicad/+bug/1752419
> 
> 
> 
> ___
> 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] critical bug in Spice simulator - feedback from OSX devs needed

[Tomasz Wlostowski]

Hi,

I've been trying to fix [1] without success: ngspice will not load
another circuit if the current one contains fatal errors. Under some
circumstances, this segfaults KiCad.

The only solution I see is to bring back dynamic
(dlopen()/wxDynamicLibrary) loading of ngspice DLL every time the
simulator is launched, since unloading and reloading again resets
ngspice's internal state and releases all allocated resources. The early
versions of the simulator had worked like this but later it was changed
to traditional linking reportedly due to some issues on OSX with dynamic
library loading. I can't find any trace of information about these
DLL-related issues - so I'm calling our Mac devs here to reply if
anybody remembers why this change was done.

If no one gives a solid reason to stay with a hard-linked ngspice DLL,
I'll revert the ngspice plugin to use wxDynamicLibrary.

Tom

[1] https://bugs.launchpad.net/kicad/+bug/1753092

___
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] Deletion in plugins causing trouble

[dick]

  
  
Over many years I have adopted the habit of using an extended brainstorming 
phase at the front end of any problem solving exercise.But for this to 
succeed in a team environment it requires that everyone knows about the 
brainstorming process, how it works and its various phases.It also requires 
patience to follow the dicipline of that process.And as you may know, often 
the biggest problem is passing judgement or offering opinion on one of the 
options too early.If the phases have agreed upon names and everyone knows 
what phase the team is in, then the process can often find superior solutions.  
  In fact it always does.
  

  
Even when the team is only me, I almost never settle on a solution until I have 
more than one on the table for consideration.This often entails patient 
research into what other people are doing in a similar situation.
  

  
Other projects that blend python scripting with C++ are out there and some are 
larger than kicad.XBMC now called something else, and Blender are 2 off the 
top of my head.
  

  
I dont have a lot of experience with shared pointers in C++, because I have 
always tended to believe that object ownerships should be more managed by the 
coder.However, without evaluation of the idea, and merely listing it during 
the storm phase, I throw out the idea that all python objects could use shared 
pointers to point to their objects.And this seems to require that all C++ 
parents would do the same.   This punts the object management to the shared 
pointer. 
  

  
This could be an expensive idea to implement.That assesment comes later in 
the brainstorming process however.Before getting to that I suggest that 
some of the other projects get looked at, and the list of things on the table 
get expanded even more.I can not over state the value in studying previous 
solutions to a similar problem.Smart people do that.
  

  
Dick
  

  

  
  
  

  
  
  
  
  
>   
> On Mar 6, 2018 at 4:01 AM,wrote:
>   
>   Hi Miles,  
>
>   
> I wasn’t around for the first discussion on the topic, but one of the reasons 
> (1) doesn’t work terribly well is that it’s not enough to know what changed; 
> one also has to know how to group the changes into individual undo/redo 
> steps.It sounds like the plugin infrastructure accomplishes this by the 
> over-simplification that a plugin does discrete operations (ie: one plugin 
> call == one undo step).
>   
>
>   
> Why does the plugin mechanism need to do a diff?Is that to apply the 
> changes, or just to know what to commit?If it’s the latter, just stop 
> doing that.Memory is cheap; commit everything.So what if undo 
> replaces a bunch of stuff that didn’t actually change.
>   
>
>   
> Cheers,
>   
> Jeff.
>   
>
>   
>   
>
>   
> >   
> > On 6 Mar 2018, at 09:02, miles mccoo    wrote:
> >   
> >   
> >   
> > Thanks all for your replies.  
> >
> >   
> > I like the plugin mechanism. It does some nice things for python folks. 
> > Refresh, undo, garbage collection (I think). I want to see it succeed.
> >   
> >
> >   
> > From reading Orson's mail, I think I wasn't entirely clear, so let me try 
> > to fix that first.
> >   
> >
> >   
> >
> >   
> > The plugin mechanism tries to track the changes of a python plugin. In the 
> > c++ world, developers are expected to inform BOARD_COMMIT that something 
> > has changed. The plugin infrastructure does this for you. One could compare 
> > it to garbage collection. My interpretation of how this is done is simple: 
> > before a plugin runs, make a list of all design objects. zones, tracks, 
> > modules, nets... after the plugin completes, do a "diff".
> >   
> >
> >   
> > This is mostly fine with the exception of removed items.
> >   
> >
> >   
> > The problem with removed items is how do you do a diff on a deleted, memory 
> > managed, cleaned up object? Perhaps that memory now contains a different 
> > kind of object. Perhaps it's been reallocated to a similar object as before.
> >   
> >
> >   
> >
> >   
> >
> >   
> > as it stands now, any plugin that removes items from a board item container 
> > will likely fail. It's not quite a crash, but it has a similar feel to the 
> > user.
> >   
> >
> >   
> >
> >   
> >
> >   
> > Solutions. I can think of four.   
> >   
> >
> >   
> > solution 1. Why is the plugin mechanism in the business of tracking 
> > changes? Shouldn't BOARD_COMMIT just magically happen whenever a c++ 
> > instance is modified. I brought this up in a previous thread[1] and various 
> > reasons were given why this isn't desirable.
> >   
> >
> >   
> > solution 2. Same as #1 except BC magic only happens on python API calls. 
> > The plugin mechanism would no longer do diffs. Just add BC checkpoints. 
> > This is probably a lot of work. I might be willing to do this work but it 
> > would take time. [2]
> >   
> >
> >   
> > solution 3. easy to implement. turn 

Re: [Kicad-developers] Handling invalid characters in symbol/component LIB_IDs

[Maciej Sumiński]

Attached a small project to observe the problem/test the patches. There
are two libraries inside:
- slash.lib contains one symbol with '/' in its LIB_ID
- slash_conflict.lib contains two symbols that result in a LIB_ID clash
(RELAY_Hongfa_HF115F/012-1H3T and RELAY_Hongfa_HF115F_012-1H3T).

Normally you can use slash.lib, but if you want to check what happens in
case of a conflict, then use the other one.

On 03/06/2018 02:55 PM, Maciej Sumiński wrote:
> I am trying to find a reasonable way to handle symbol and components
> with invalid characters in their LIB_IDs (see bug report #1752419 [1]).
> While now it is impossible to create such LIB_IDs, we need to handle
> documents that had been created before the restriction was introduced.
> 
> LIB_IDs in SCH_COMPONENTS will have illegal characters replaced on load,
> but it is not the case for LIB_{PART,ALIAS} classes. Due to that:
> 
> - Symbol-component links are broken (e.g. component with LIB_ID
> 'Test/Name' will change to 'Test_Name', but the corresponding LIB_PART
> will remain 'Test/Name'.
> 
> - It is impossible to place/edit such symbols.
> 
> The simplest solution is to process LIB_{PART,ALIAS} LIB_IDs in the same
> way as id done for SCH_COMPONENTs, so they become valid names that match
> SCH_COMPONENTs using them (see the attached patches). There are two
> drawbacks:
> 
> - Changing names that user had previously assigned, which might be
> annoying if LIB_IDs are used e.g. to create BOMs. Personally I would use
> the value field that accepts all characters for this purpose.
> 
> - Naming conflicts may occur (e.g. both 'Test/Name' and 'Test:Name' will
> be changed to 'Test_Name', but I believe it is a rare case.
> 
> Any thoughts? I believe a more elegant solution will be implemented once
> the new schematic file format is ready.
> 
> Cheers,
> Orson
> 
> 1. https://bugs.launchpad.net/kicad/+bug/1752419
> 
> 
> 
> ___
> 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
> 



slash_test.tar.bz2
Description: BZip2 compressed data


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

[Kicad-developers] Handling invalid characters in symbol/component LIB_IDs

[Maciej Sumiński]

I am trying to find a reasonable way to handle symbol and components
with invalid characters in their LIB_IDs (see bug report #1752419 [1]).
While now it is impossible to create such LIB_IDs, we need to handle
documents that had been created before the restriction was introduced.

LIB_IDs in SCH_COMPONENTS will have illegal characters replaced on load,
but it is not the case for LIB_{PART,ALIAS} classes. Due to that:

- Symbol-component links are broken (e.g. component with LIB_ID
'Test/Name' will change to 'Test_Name', but the corresponding LIB_PART
will remain 'Test/Name'.

- It is impossible to place/edit such symbols.

The simplest solution is to process LIB_{PART,ALIAS} LIB_IDs in the same
way as id done for SCH_COMPONENTs, so they become valid names that match
SCH_COMPONENTs using them (see the attached patches). There are two
drawbacks:

- Changing names that user had previously assigned, which might be
annoying if LIB_IDs are used e.g. to create BOMs. Personally I would use
the value field that accepts all characters for this purpose.

- Naming conflicts may occur (e.g. both 'Test/Name' and 'Test:Name' will
be changed to 'Test_Name', but I believe it is a rare case.

Any thoughts? I believe a more elegant solution will be implemented once
the new schematic file format is ready.

Cheers,
Orson

1. https://bugs.launchpad.net/kicad/+bug/1752419
From b3061c2f8c4ec2723b93e58c7a6c0d09ef15298b Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Tue, 6 Mar 2018 10:11:54 +0100
Subject: [PATCH 1/4] Added ReplaceIllegalFileNameChars() for wxString&

---
 common/string.cpp  | 37 ++---
 include/kicad_string.h |  1 +
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/common/string.cpp b/common/string.cpp
index 8f35b83d6..8932fbc18 100644
--- a/common/string.cpp
+++ b/common/string.cpp
@@ -482,8 +482,9 @@ wxString GetIllegalFileNameWxChars()
 
 bool ReplaceIllegalFileNameChars( std::string* aName, int aReplaceChar )
 {
-bool  changed = false;
-std::string   result;
+bool changed = false;
+std::string result;
+result.reserve( aName->length() );
 
 for( std::string::iterator it = aName->begin();  it != aName->end();  ++it )
 {
@@ -503,7 +504,37 @@ bool ReplaceIllegalFileNameChars( std::string* aName, int aReplaceChar )
 }
 
 if( changed )
-*aName =  result;
+*aName = result;
+
+return changed;
+}
+
+
+bool ReplaceIllegalFileNameChars( wxString& aName, int aReplaceChar )
+{
+bool changed = false;
+wxString result;
+result.reserve( aName.Length() );
+
+for( wxString::iterator it = aName.begin();  it != aName.end();  ++it )
+{
+if( strchr( illegalFileNameChars, *it ) )
+{
+if( aReplaceChar )
+result += aReplaceChar;
+else
+result += wxString::Format( "%%%02x", *it );
+
+changed = true;
+}
+else
+{
+result += *it;
+}
+}
+
+if( changed )
+aName = result;
 
 return changed;
 }
diff --git a/include/kicad_string.h b/include/kicad_string.h
index abf6a8200..3a4f45fbe 100644
--- a/include/kicad_string.h
+++ b/include/kicad_string.h
@@ -172,6 +172,7 @@ wxString GetIllegalFileNameWxChars();
  * @return true if any characters have been replaced in \a aName.
  */
 bool ReplaceIllegalFileNameChars( std::string* aName, int aReplaceChar = 0 );
+bool ReplaceIllegalFileNameChars( wxString& aName, int aReplaceChar = 0 );
 
 #ifndef HAVE_STRTOKR
 // common/strtok_r.c optionally:
-- 
2.13.3

From f7a0ee82a6ea32d0c68c97c26079feed2ada61d3 Mon Sep 17 00:00:00 2001
From: Maciej Suminski 
Date: Tue, 6 Mar 2018 11:09:11 +0100
Subject: [PATCH 2/4] Replace illegal characters in LIB_{ALIAS,PART} LIB_IDs

Schematic components have illegal characters replaced during load,
leading to broken component-symbol links. To avoid this, library symbols
should have their names fixed in the same way.
---
 eeschema/class_libentry.cpp | 23 ---
 eeschema/class_libentry.h   |  2 +-
 eeschema/lib_field.cpp  | 16 ++--
 3 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/eeschema/class_libentry.cpp b/eeschema/class_libentry.cpp
index 4f7f8807b..09bab9467 100644
--- a/eeschema/class_libentry.cpp
+++ b/eeschema/class_libentry.cpp
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -67,7 +68,7 @@ LIB_ALIAS::LIB_ALIAS( const wxString& aName, LIB_PART* aRootPart ):
 EDA_ITEM( LIB_ALIAS_T ),
 shared( aRootPart )
 {
-name = aName;
+SetName( aName );
 }
 
 
@@ -118,6 +119,13 @@ PART_LIB* LIB_ALIAS::GetLib()
 }
 
 
+void LIB_ALIAS::SetName( const wxString& aName )
+{
+name = aName;
+ReplaceIllegalFileNameChars( name, '_' );
+}
+
+
 bool LIB_ALIAS::operator==( const wxChar* aName ) const
 {
 return name == aName;
@@ -275,21 

Re: [Kicad-developers] [PATCH] Fix depency bug introduced in RPATH patch

[Wayne Stambaugh]

I merged your patch.  Thanks!


Wayne

On 3/5/2018 7:52 PM, hauptmech wrote:
> The attached patch may fix the build error seen after the RPATH 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

Re: [Kicad-developers] [fun feature request] Create PCB from schematic with one click :)

[Nick Østergaard]

There is an option in pcbnew to delete all tracks already...

2018-03-06 9:13 GMT+01:00 Ingo Kletti :

>
> Am 05.03.2018 um 19:07 schrieb Andy Peters:
>
>> I'm guessing auto-routers appeal to hobbyists rather than professionals.
>>>
>>
>> How many questions on forums do you see from hobbyists asking about how
>> to autoroute, or wondering if the results from the autorouter are good?
>>
>
> A great deal of my day job is supporting students working on layouts.
> Almost every second layout that someone wants advice on is done using the
> autorouter although they have been told to do it manually.
>
> Since they also ignored all advice and documentation on design rules and
> component placement, these layouts are a complete mess.
>
> Therefore a feature that I'd like to see is "select all traces" -> "delete
> all traces" ;-)
>
> All jokes aside: I'd also vote for not investing manpower in autorouting.
>
>
>
> ___
> 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] Deletion in plugins causing trouble

[Jeff Young]

Hi Miles,

I wasn’t around for the first discussion on the topic, but one of the reasons 
(1) doesn’t work terribly well is that it’s not enough to know what changed; 
one also has to know how to group the changes into individual undo/redo steps.  
It sounds like the plugin infrastructure accomplishes this by the 
over-simplification that a plugin does discrete operations (ie: one plugin call 
== one undo step).

Why does the plugin mechanism need to do a diff?  Is that to apply the changes, 
or just to know what to commit?  If it’s the latter, just stop doing that.  
Memory is cheap; commit everything.  So what if undo replaces a bunch of stuff 
that didn’t actually change.

Cheers,
Jeff.


> On 6 Mar 2018, at 09:02, miles mccoo  wrote:
> 
> Thanks all for your replies.
> 
> I like the plugin mechanism. It does some nice things for python folks. 
> Refresh, undo, garbage collection (I think). I want to see it succeed.
> 
> From reading Orson's mail, I think I wasn't entirely clear, so let me try to 
> fix that first.
> 
> 
> The plugin mechanism tries to track the changes of a python plugin. In the 
> c++ world, developers are expected to inform BOARD_COMMIT that something has 
> changed. The plugin infrastructure does this for you. One could compare it to 
> garbage collection. My interpretation of how this is done is simple: before a 
> plugin runs, make a list of all design objects. zones, tracks, modules, 
> nets... after the plugin completes, do a "diff".
> 
> This is mostly fine with the exception of removed items.
> 
> The problem with removed items is how do you do a diff on a deleted, memory 
> managed, cleaned up object? Perhaps that memory now contains a different kind 
> of object. Perhaps it's been reallocated to a similar object as before.
> 
> 
> 
> as it stands now, any plugin that removes items from a board item container 
> will likely fail. It's not quite a crash, but it has a similar feel to the 
> user.
> 
> 
> 
> Solutions. I can think of four. 
> 
> solution 1. Why is the plugin mechanism in the business of tracking changes? 
> Shouldn't BOARD_COMMIT just magically happen whenever a c++ instance is 
> modified. I brought this up in a previous thread[1] and various reasons were 
> given why this isn't desirable.
> 
> solution 2. Same as #1 except BC magic only happens on python API calls. The 
> plugin mechanism would no longer do diffs. Just add BC checkpoints. This is 
> probably a lot of work. I might be willing to do this work but it would take 
> time. [2]
> 
> solution 3. easy to implement. turn off deletion on calls to remove if 
> currently running a plugin
> plugin gets a boolean: isPluginActive. set/unset around the call to actual 
> python run code.
> add pcbnew.isPluginActive() to python api. (I could imagine this could have 
> other uses)
> the remove code looks at isPluginActive to decide whether to set isown. (that 
> code is actually python, not swig)
> I have #3 implemented and my plugins no longer crash. See attached patch for 
> if folks agree it is an acceptable stopgap.
> 
> solution 4. probably not the direction I would go but a way to enable python 
> memory management and do the plugin diff thing. Basically, give each object 
> some sort of unique id. (could be useful for other things). In addition to 
> holding a list of object pointers, plugin infrastructure would hold a list of 
> object ids.
> 
> 
> Given the ease with which a plugin can hit this issue and given how long it 
> would take to get #2 right, I guess I'm recommending the changes of that 
> attached patch for #3.
> 
> Miles
> 
> [1] https://lists.launchpad.net/kicad-developers/msg32063.html 
> 
> [2] I think my personal opinion is that #1 is superior over #2. Python people 
> shouldn't have to care but why is it that c++ should or want to? Yes, I read 
> the arguments from the previous thread but I'm not convinced. I'm also just a 
> kicad spectator, so there's a lot I don't know.
> 
> 
> 
> 
> 
> On Fri, Mar 2, 2018 at 2:47 PM, Wayne Stambaugh  > wrote:
> LOL, I just replied to Miles.  Thanks Orson for helping out!
> 
> On 3/2/2018 8:36 AM, Maciej Sumiński wrote:
> > Hi Miles,
> >
> > I suppose the silence in the thread indicates there are not many
> > developers knowing the Python scripting interface inside out. Since you
> > are both studying the scripting interface and developing own scripts, it
> > is quite possible you are the most competent person to give us an advice
> > on how to proceed. See some comments below, but I am neither a Python
> > script developer nor a scripting interface maintainer, so I might be
> > lacking some basic knowledge here.
> >
> > On 02/28/2018 05:12 PM, miles mccoo wrote:
> >> So I'm plugin-ifying my python scripts (the mechanism is awesome). One of
> >> the plugins deletes some stuff and that is causing trouble.
> >>
> >>
> >>
> 

Re: [Kicad-developers] Deletion in plugins causing trouble

[miles mccoo]

Thanks all for your replies.

I like the plugin mechanism. It does some nice things for python folks.
Refresh, undo, garbage collection (I think). I want to see it succeed.

>From reading Orson's mail, I think I wasn't entirely clear, so let me try
to fix that first.


The plugin mechanism tries to track the changes of a python plugin. In the
c++ world, developers are expected to inform BOARD_COMMIT that something
has changed. The plugin infrastructure does this for you. One could compare
it to garbage collection. My interpretation of how this is done is simple:
before a plugin runs, make a list of all design objects. zones, tracks,
modules, nets... after the plugin completes, do a "diff".

This is mostly fine with the exception of removed items.

The problem with removed items is how do you do a diff on a deleted, memory
managed, cleaned up object? Perhaps that memory now contains a different
kind of object. Perhaps it's been reallocated to a similar object as before.



*as it stands now, any plugin that removes items from a board item
container will likely fail*. It's not quite a crash, but it has a similar
feel to the user.



Solutions. I can think of four.

solution 1. Why is the plugin mechanism in the business of tracking
changes? Shouldn't BOARD_COMMIT just magically happen whenever a c++
instance is modified. I brought this up in a previous thread[1] and various
reasons were given why this isn't desirable.

solution 2. Same as #1 except BC magic only happens on python API calls.
The plugin mechanism would no longer do diffs. Just add BC checkpoints.
This is probably a lot of work. I might be willing to do this work but it
would take time. [2]

solution 3. easy to implement. turn off deletion on calls to remove if
currently running a plugin

   - plugin gets a boolean: isPluginActive. set/unset around the call to
   actual python run code.
   - add pcbnew.isPluginActive() to python api. (I could imagine this could
   have other uses)
   - the remove code looks at isPluginActive to decide whether to set
   isown. (that code is actually python, not swig)

I have #3 implemented and my plugins no longer crash. *See attached patch
for if folks agree it is an acceptable stopgap.*

solution 4. probably not the direction I would go but a way to enable
python memory management and do the plugin diff thing. Basically, give each
object some sort of unique id. (could be useful for other things). In
addition to holding a list of object pointers, plugin infrastructure would
hold a list of object ids.


*Given the ease with which a plugin can hit this issue and given how long
it would take to get #2 right, I guess I'm recommending the changes of that
attached patch for #3.*

Miles

[1] https://lists.launchpad.net/kicad-developers/msg32063.html
[2] I think my personal opinion is that #1 is superior over #2. Python
people shouldn't have to care but why is it that c++ should or want to?
Yes, I read the arguments from the previous thread but I'm not convinced.
I'm also just a kicad spectator, so there's a lot I don't know.





On Fri, Mar 2, 2018 at 2:47 PM, Wayne Stambaugh 
wrote:

> LOL, I just replied to Miles.  Thanks Orson for helping out!
>
> On 3/2/2018 8:36 AM, Maciej Sumiński wrote:
> > Hi Miles,
> >
> > I suppose the silence in the thread indicates there are not many
> > developers knowing the Python scripting interface inside out. Since you
> > are both studying the scripting interface and developing own scripts, it
> > is quite possible you are the most competent person to give us an advice
> > on how to proceed. See some comments below, but I am neither a Python
> > script developer nor a scripting interface maintainer, so I might be
> > lacking some basic knowledge here.
> >
> > On 02/28/2018 05:12 PM, miles mccoo wrote:
> >> So I'm plugin-ifying my python scripts (the mechanism is awesome). One
> of
> >> the plugins deletes some stuff and that is causing trouble.
> >>
> >>
> >>
> >> I'm not sure how to fix the root cause. Hence this mail.
> >>
> >>
> >>
> >> The plugin just deletes Edge.Cuts[1]:
> >> for d in board.GetDrawings():
> >> if (d.GetLayerName() == 'Edge.Cuts'):
> >> board.Remove(d)
> >>
> >>
> >>
> >> in board_item_container.i, I see this (with stuff deleted):
> >> %rename(RemoveNative)BOARD_ITEM_CONTAINER::Remove;
> >> def Remove(self,item):
> >> self.RemoveNative(item)
> >> item.thisown=1
> >>
> >>
> >> Setting thisown tells, python "you own it". Delete it when you're done.
> >> Which it does.
> >>
> >>
> >> The problem this causes is that the plugin mechanism saves a list of all
> >> objects before running the plugin and then checks if any of them has a
> null
> >> list after (ie is it still in the design).
> >
> > Is this mechanism implemented to handle memory leaks? If so, would not
> > it be sufficient to stick to 'thisown' flag on Remove() calls or is
> > there another way objects might be destroyed using 

Re: [Kicad-developers] [fun feature request] Create PCB from schematic with one click :)

[Rob Maris]

Am 06.03.2018, 09:13 Uhr, schrieb Ingo Kletti :



Since they also ignored all advice and documentation on design rules and
component placement, these layouts are a complete mess.


Apparently, many students believe that computers who beat chess world champions 
are also able to autoroute and even autoplace world class as well...
Try to motivate them by telling them that humans still by far outperform 
computers on autorouting. They should even be happy about that.

Regards,
Rob

___
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] [fun feature request] Create PCB from schematic with one click :)

[Ingo Kletti]

Am 05.03.2018 um 19:07 schrieb Andy Peters:

I'm guessing auto-routers appeal to hobbyists rather than professionals.


How many questions on forums do you see from hobbyists asking about how to 
autoroute, or wondering if the results from the autorouter are good?


A great deal of my day job is supporting students working on layouts. 
Almost every second layout that someone wants advice on is done using 
the autorouter although they have been told to do it manually.


Since they also ignored all advice and documentation on design rules and 
component placement, these layouts are a complete mess.


Therefore a feature that I'd like to see is "select all traces" -> 
"delete all traces" ;-)


All jokes aside: I'd also vote for not investing manpower in autorouting.


___
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