Re: [Kicad-developers] VECTOR2I and VECTOR2D

[hauptmech]

Hi Tom,

On 23/06/2019 4:10 AM, Tomasz Wlostowski wrote:

On 22/06/2019 17:41, Reece R. Pollack wrote:

While it is true that you can add two point coordinates and multiply by
scalar 0.5 to get the midpoint, this is not true in the general case for
arbitrary scalar multipliers. However, calculating the vector distance
between two points, multiplying the vector by a scalar, then adding the
resulting vector distance to the first point /does/ work in the general
case.

This is exactly the sort of bug that can be avoided by not allowing
arbitrary operations on random vectors.

I've never experienced a bug caused by mixing points/vectors together,
at least in the math code. For passing coordinates/measurements from/to
the GUI it might make sense to create custom types. Moreover, most if
not all geometry libraries I've known used the same class for points and
vectors. Single class for both is IMHO Occam's razor approach. As Seth
already remarked, I would like to hear a solid argument for splitting
point/vector classes, otherwise it looks like bikeshedding to me.


While it's cool that you have such a strong grasp of geometry operations 
and how they map to linear algebra, not everyone is at your level. 
Potential contributors to Kicad will have all sorts of backgrounds and 
be in the process of learning about geometry and or linear algebra. The 
math vector + geometric point VECTOR2 class technically works, but 
creates friction because to use it confidently one needs to read the 
class code and know a bit about how geometry operations are mapped to 
vector operations.


Splitting the classes into Vector, Point, and Delta (Spatial Vector), 
and restricting the behavior of each to match their math and geometry 
counterparts, will make it much easier for others to learn and come 
onboard.


Meanwhile, since you don't use spatial vectors erroneously, you won't 
see any new compiler errors, but people who are still learning about 
geometry will get useful feedback.


-Hauptmech



Tom

PS1. I'm surprised no one yet noticed the VECTOR2<> class has public x/y
  members, which is an unforgivable violation of the tenets of classical
OO design :-)

PS2. There are some more serious OOD violations in KiCad codebase. Would
anybody here volunteer to refactor the diamond in EDA_TEXT derivatives,
DRAWSEGMENT/EDGE_MODULE classes or global variables in eeschema?

___
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] VECTOR2I and VECTOR2D

[Seth Hillbrand]

A specification for substantial changes like this should document 
clearly the hierarchy of inheritance, each class's functions and 
expected returns.  There are some very good references out there on how 
to write specs [1][2][3].


This is not to dismiss Reece's suggestion.  I think it is a good one and 
potentially quite beneficial long-term.  I also think Reece is 
approaching this the right way by writing a short e-mail to the list 
first before pouring effort into the spec.  I'm not quite certain 
whether Reece is suggesting that he'd like to make this change or 
whether it is being proposed as a wishlist item for future work.  If it 
is the former, it needs a spec.  If it is the latter, we can do that 
when it is on someone's to-do list.


Best-
Seth

[1] 
https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/
[2] 
https://books.google.com/books/about/Specification_by_Example.html?id=5F5PYgEACAAJ

[3] https://codeburst.io/on-writing-tech-specs-6404c9791159

On 2019-06-22 21:37, hauptmech wrote:

Isn't Reece's original post the spec? In summary, the name VECTOR is
confusing and the type structure could be expanded on to offer more
compile time checks. He proposes a KiPoint and KiDelta, and describes
their behavior clearly enough for anyone that does geometry
calculations. What's missing from the spec?



On 23/06/2019 2:52 AM, Seth Hillbrand wrote:

On 2019-06-21 22:54, Reece R. Pollack wrote:

Doing this now, before we go too far down the path of replacing
wxWidgets types with non-OOB arrays would enhance readability and 
make

the code more robust. Using VECTOR2I is going the wrong way.


Hi Reece-

Codebase cleaning like you suggest can go a long way toward improving 
sustainability and readability.  But done the wrong way, it will have 
the opposite effect as we fight with return types that aren't fully 
matched.


Before we decide to do this type of deep plumbing on the KiCad 
innards, I'd love to see the proposed specification for what's being 
implemented.  Otherwise, this'll be a bike shedding discussion.


-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




___
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] VECTOR2I and VECTOR2D

[hauptmech]

Isn't Reece's original post the spec? In summary, the name VECTOR is 
confusing and the type structure could be expanded on to offer more 
compile time checks. He proposes a KiPoint and KiDelta, and describes 
their behavior clearly enough for anyone that does geometry 
calculations. What's missing from the spec?




On 23/06/2019 2:52 AM, Seth Hillbrand wrote:

On 2019-06-21 22:54, Reece R. Pollack wrote:

Doing this now, before we go too far down the path of replacing
wxWidgets types with non-OOB arrays would enhance readability and make
the code more robust. Using VECTOR2I is going the wrong way.


Hi Reece-

Codebase cleaning like you suggest can go a long way toward improving 
sustainability and readability.  But done the wrong way, it will have 
the opposite effect as we fight with return types that aren't fully 
matched.


Before we decide to do this type of deep plumbing on the KiCad 
innards, I'd love to see the proposed specification for what's being 
implemented.  Otherwise, this'll be a bike shedding discussion.


-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




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

[jp charras]

Le 22/06/2019 à 20:23, Jeff Young a écrit :
> Hi JP,
> 
> Can you point me to some of the clearance violation issues?
> 
> I’m aware of the one where a track that goes within the thermal clearance 
> radius can produce a DRC error, but I’d consider that what DRC is for.  But 
> it sounds like there are others?
> 
> Thanks,
> Jeff.
> 

This is a corner case.
I'll send a board that exhibit this issue tomorrow.


-- 
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] 6.0 Zone filling differences

[Jeff Young]

Hi JP,

Can you point me to some of the clearance violation issues?

I’m aware of the one where a track that goes within the thermal clearance 
radius can produce a DRC error, but I’d consider that what DRC is for.  But it 
sounds like there are others?

Thanks,
Jeff.


> On 22 Jun 2019, at 18:58, jp charras  wrote:
> 
> Le 22/06/2019 à 18:37, Jeff Young a écrit :
>> New, higher-performance bits in, with some (perhaps all) of the bugs fixed.
>> 
>> Testing would be appreciated.
>> 
>> Cheers,
>> Jeff.
>> 
> 
> Hi Jeff,
> 
> Usually, when 2 bugs are fixed, one new bug is created.
> 
> Thermal stubs are missing for pads having a different size in X and Y
> direction.
> They are missing for the biggest direction.
> 
> Apart from that:
> * The calculation time is bigger than the current algo, but no longer
> blocking (for instance 2 sec instead of less than 1 sec in a bad case).
> * Much more annoying, the thermal stubs can create DRC issues:
> They do not always respect the zone clearance, and in some cases do not
> respect the netclass clearance.
> 
> They also create some shape artifacts.
> They are of course not the same as the current algo, but they exist.
> 
> -- 
> 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] 6.0 Zone filling differences

[jp charras]

Le 22/06/2019 à 18:37, Jeff Young a écrit :
> New, higher-performance bits in, with some (perhaps all) of the bugs fixed.
> 
> Testing would be appreciated.
> 
> Cheers,
> Jeff.
> 

Hi Jeff,

Usually, when 2 bugs are fixed, one new bug is created.

Thermal stubs are missing for pads having a different size in X and Y
direction.
They are missing for the biggest direction.

Apart from that:
* The calculation time is bigger than the current algo, but no longer
blocking (for instance 2 sec instead of less than 1 sec in a bad case).
* Much more annoying, the thermal stubs can create DRC issues:
They do not always respect the zone clearance, and in some cases do not
respect the netclass clearance.

They also create some shape artifacts.
They are of course not the same as the current algo, but they exist.

-- 
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] 6.0 Zone filling differences

[Nick Østergaard]

Ok, I guess that is the safest option and if one requires a track there one
could just draw it manually.

lør. 22. jun. 2019 18.52 skrev Jeff Young :

> Yes.
>
> On 22 Jun 2019, at 17:39, Nick Østergaard  wrote:
>
> Ah, ok, it os the chamfers. I didn't realise that.  What are you
> proposing, to remove the spoke if the zone does not touch?
>
> lør. 22. jun. 2019 18.36 skrev Jeff Young :
>
>> There’s no piece of the zone in the middle; that’s just the chamfers on
>> the ends of the spokes.
>>
>> The zone doesn’t go between the two pads because their thermal relief
>> value doesn’t allow enough room.
>>
>> Cheers,
>> Jeff.
>>
>>
>> On 22 Jun 2019, at 17:04, Nick Østergaard  wrote:
>>
>> Mmm, I am not sure I under stamd that screenshot. Why are the zone not
>> touchimg the thermal track between the pads while it looks like there is a
>> part of zone area on the middle of the thermal track?
>>
>> lør. 22. jun. 2019 17.58 skrev Jeff Young :
>>
>>> Our current algorithm will produce thermal connections between two pads
>>> (with no connections to the zone):
>>>
>>>
>>> I assume no one will lose any sleep over dropping those?
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> On 21 Jun 2019, at 19:49, Jean-Paul Louis  wrote:
>>>
>>> Wayne,
>>>
>>> Except in very hugh frequency design (higher UHF spectrum, microwaves
>>> and millimeter waves)
>>> were chamfers can create more problems than they solve.
>>>
>>> This chamfer should be user optional, the best being individual part
>>> layout optional.
>>>
>>> Just my extra data point,
>>>
>>> Jean-Paul
>>> N1JPL
>>>
>>>
>>> On Jun 21, 2019, at 8:05 AM, Wayne Stambaugh 
>>> wrote:
>>>
>>> Jeff,
>>>
>>> Users are going to expect chamfering if there is an option for it.  I
>>> don't see how you are going to avoid adding chamfering to the spokes
>>> unless we decide to do away with chamfering as an option.  I don't think
>>> that's good idea because right angles on board geometry is generally
>>> frowned upon.
>>>
>>> Wayne
>>>
>>> On 6/20/19 4:24 PM, Jeff Young wrote:
>>>
>>> Turns out there’s a slightly unintended side effect.
>>>
>>> Before:
>>>
>>> Note the two truncated thermal spokes to the surface-mount pads at the
>>> lower right.
>>>
>>> After:
>>>
>>>
>>>
>>>
>>> The bug is fixed, but not that the junctions between the spokes and the
>>> zone body are no longer chamfered.
>>>
>>> I’d say the “after” is better in that respect too, but again it’s
>>> definitely different.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> Jeff.
>>>
>>>
>>> On 20 Jun 2019, at 19:50, Reece Pollack >> > wrote:
>>>
>>> Memory is the second thing to go as one ages.
>>>
>>> I can't remember what the first one is.
>>>
>>> 
>>> *From: *"Jeff Young" mailto:j...@rokeby.ie
>>> >>
>>> *To: *"jp charras" mailto:jp.char...@wanadoo.fr
>>> >>
>>> *Cc: *"KiCad Developers" >> >> >>
>>> *Sent: *Thursday, June 20, 2019 2:46:58 PM
>>> *Subject: *Re: [Kicad-developers] 6.0 Zone filling differences
>>>
>>> Wow.  That’s sobering.  I wrote the board outline clearance changes….
>>>
>>> Age sucks.
>>>
>>>
>>>   On 20 Jun 2019, at 19:04, jp charras >>   > wrote:
>>>
>>>   Le 20/06/2019 à 19:24, Jeff Young a écrit :
>>>
>>>   I believe we now have a warning, but I can’t remember what
>>>   change it was for.  I thought it was for the outline changes,
>>>   but from what I can find on the mailing list archive it looks
>>>   like we were satisfied that one wouldn’t change anything.
>>>
>>>   So remind me what the warning is for?
>>>
>>>
>>>   AFAIK, it is for board outline clearance change (taking in accounf or
>>>   not the edge cut graphic items thickness, if I correctly remember).
>>>   Zone outline changes (only activated if the kicad_advanced
>>>   "ForceThickZones=0" option enables it), do not need any warning.
>>>
>>>
>>>   The reason behind this request is that I have a new fill
>>>   algorithm which fixes a long-standing bug regarding one pad’s
>>>   thermal ring knocking out another pad’s thermal spoke.  It
>>>   also allows thermal spokes on custom pad shapes (and would
>>>   allow us to support custom number of spokes if we wished).
>>>
>>>   While this should only change zone fills which would have been
>>>   considered errors in the past, it nevertheless changes them.
>>>What’s the prescription for that?
>>>
>>>   Cheers,
>>>   Jeff.
>>>
>>>
>>>
>>>
>>>   --
>>>   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] 6.0 Zone filling differences

[Jeff Young]

Yes.

> On 22 Jun 2019, at 17:39, Nick Østergaard  wrote:
> 
> Ah, ok, it os the chamfers. I didn't realise that.  What are you proposing, 
> to remove the spoke if the zone does not touch?
> 
> lør. 22. jun. 2019 18.36 skrev Jeff Young  >:
> There’s no piece of the zone in the middle; that’s just the chamfers on the 
> ends of the spokes.
> 
> The zone doesn’t go between the two pads because their thermal relief value 
> doesn’t allow enough room.
> 
> Cheers,
> Jeff.
> 
> 
>> On 22 Jun 2019, at 17:04, Nick Østergaard > > wrote:
>> 
>> Mmm, I am not sure I under stamd that screenshot. Why are the zone not 
>> touchimg the thermal track between the pads while it looks like there is a 
>> part of zone area on the middle of the thermal track?
>> 
>> lør. 22. jun. 2019 17.58 skrev Jeff Young > >:
>> Our current algorithm will produce thermal connections between two pads 
>> (with no connections to the zone):
>> 
>> 
>> 
>> I assume no one will lose any sleep over dropping those?
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 21 Jun 2019, at 19:49, Jean-Paul Louis >> > wrote:
>>> 
>>> Wayne,
>>> 
>>> Except in very hugh frequency design (higher UHF spectrum, microwaves and 
>>> millimeter waves)
>>> were chamfers can create more problems than they solve.
>>> 
>>> This chamfer should be user optional, the best being individual part layout 
>>> optional.
>>> 
>>> Just my extra data point,
>>> 
>>> Jean-Paul
>>> N1JPL
>>> 
>>> 
 On Jun 21, 2019, at 8:05 AM, Wayne Stambaugh >>> > wrote:
 
 Jeff,
 
 Users are going to expect chamfering if there is an option for it.  I
 don't see how you are going to avoid adding chamfering to the spokes
 unless we decide to do away with chamfering as an option.  I don't think
 that's good idea because right angles on board geometry is generally
 frowned upon.
 
 Wayne
 
 On 6/20/19 4:24 PM, Jeff Young wrote:
> Turns out there’s a slightly unintended side effect.
> 
> Before:
> 
> Note the two truncated thermal spokes to the surface-mount pads at the
> lower right.
> 
> After:
> 
> 
> 
> 
> The bug is fixed, but not that the junctions between the spokes and the
> zone body are no longer chamfered.
> 
> I’d say the “after” is better in that respect too, but again it’s
> definitely different.
> 
> Thoughts?
> 
> Cheers,
> Jeff.
> 
> 
>> On 20 Jun 2019, at 19:50, Reece Pollack > 
>> >> wrote:
>> 
>> Memory is the second thing to go as one ages.
>> 
>> I can't remember what the first one is.
>> 
>> 
>> *From: *"Jeff Young" mailto:j...@rokeby.ie> 
>> >>
>> *To: *"jp charras" mailto:jp.char...@wanadoo.fr> 
>> >>
>> *Cc: *"KiCad Developers" > 
>> > >>
>> *Sent: *Thursday, June 20, 2019 2:46:58 PM
>> *Subject: *Re: [Kicad-developers] 6.0 Zone filling differences
>> 
>> Wow.  That’s sobering.  I wrote the board outline clearance changes….
>> 
>> Age sucks.
>> 
>> 
>>   On 20 Jun 2019, at 19:04, jp charras > 
>>   >> wrote:
>> 
>>   Le 20/06/2019 à 19:24, Jeff Young a écrit :
>> 
>>   I believe we now have a warning, but I can’t remember what
>>   change it was for.  I thought it was for the outline changes,
>>   but from what I can find on the mailing list archive it looks
>>   like we were satisfied that one wouldn’t change anything.
>> 
>>   So remind me what the warning is for?
>> 
>> 
>>   AFAIK, it is for board outline clearance change (taking in accounf or
>>   not the edge cut graphic items thickness, if I correctly remember).
>>   Zone outline changes (only activated if the kicad_advanced
>>   "ForceThickZones=0" option enables it), do not need any warning.
>> 
>> 
>>   The reason behind this request is that I have a new fill
>>   algorithm which fixes a long-standing bug regarding one pad’s
>>   thermal ring knocking out another pad’s thermal spoke.  It
>>   also allows thermal spokes on custom pad shapes (and would
>>   allow us to support custom number of spokes if we wished).
>> 
>>   While this should only change zone fills which would have been
>>   considered errors in the past, it nevertheless 

Re: [Kicad-developers] 6.0 Zone filling differences

[Nick Østergaard]

Ah, ok, it os the chamfers. I didn't realise that.  What are you proposing,
to remove the spoke if the zone does not touch?

lør. 22. jun. 2019 18.36 skrev Jeff Young :

> There’s no piece of the zone in the middle; that’s just the chamfers on
> the ends of the spokes.
>
> The zone doesn’t go between the two pads because their thermal relief
> value doesn’t allow enough room.
>
> Cheers,
> Jeff.
>
>
> On 22 Jun 2019, at 17:04, Nick Østergaard  wrote:
>
> Mmm, I am not sure I under stamd that screenshot. Why are the zone not
> touchimg the thermal track between the pads while it looks like there is a
> part of zone area on the middle of the thermal track?
>
> lør. 22. jun. 2019 17.58 skrev Jeff Young :
>
>> Our current algorithm will produce thermal connections between two pads
>> (with no connections to the zone):
>>
>>
>> I assume no one will lose any sleep over dropping those?
>>
>> Cheers,
>> Jeff.
>>
>>
>> On 21 Jun 2019, at 19:49, Jean-Paul Louis  wrote:
>>
>> Wayne,
>>
>> Except in very hugh frequency design (higher UHF spectrum, microwaves and
>> millimeter waves)
>> were chamfers can create more problems than they solve.
>>
>> This chamfer should be user optional, the best being individual part
>> layout optional.
>>
>> Just my extra data point,
>>
>> Jean-Paul
>> N1JPL
>>
>>
>> On Jun 21, 2019, at 8:05 AM, Wayne Stambaugh 
>> wrote:
>>
>> Jeff,
>>
>> Users are going to expect chamfering if there is an option for it.  I
>> don't see how you are going to avoid adding chamfering to the spokes
>> unless we decide to do away with chamfering as an option.  I don't think
>> that's good idea because right angles on board geometry is generally
>> frowned upon.
>>
>> Wayne
>>
>> On 6/20/19 4:24 PM, Jeff Young wrote:
>>
>> Turns out there’s a slightly unintended side effect.
>>
>> Before:
>>
>> Note the two truncated thermal spokes to the surface-mount pads at the
>> lower right.
>>
>> After:
>>
>>
>>
>>
>> The bug is fixed, but not that the junctions between the spokes and the
>> zone body are no longer chamfered.
>>
>> I’d say the “after” is better in that respect too, but again it’s
>> definitely different.
>>
>> Thoughts?
>>
>> Cheers,
>> Jeff.
>>
>>
>> On 20 Jun 2019, at 19:50, Reece Pollack > > wrote:
>>
>> Memory is the second thing to go as one ages.
>>
>> I can't remember what the first one is.
>>
>> 
>> *From: *"Jeff Young" mailto:j...@rokeby.ie
>> >>
>> *To: *"jp charras" mailto:jp.char...@wanadoo.fr
>> >>
>> *Cc: *"KiCad Developers" > > >>
>> *Sent: *Thursday, June 20, 2019 2:46:58 PM
>> *Subject: *Re: [Kicad-developers] 6.0 Zone filling differences
>>
>> Wow.  That’s sobering.  I wrote the board outline clearance changes….
>>
>> Age sucks.
>>
>>
>>   On 20 Jun 2019, at 19:04, jp charras >   > wrote:
>>
>>   Le 20/06/2019 à 19:24, Jeff Young a écrit :
>>
>>   I believe we now have a warning, but I can’t remember what
>>   change it was for.  I thought it was for the outline changes,
>>   but from what I can find on the mailing list archive it looks
>>   like we were satisfied that one wouldn’t change anything.
>>
>>   So remind me what the warning is for?
>>
>>
>>   AFAIK, it is for board outline clearance change (taking in accounf or
>>   not the edge cut graphic items thickness, if I correctly remember).
>>   Zone outline changes (only activated if the kicad_advanced
>>   "ForceThickZones=0" option enables it), do not need any warning.
>>
>>
>>   The reason behind this request is that I have a new fill
>>   algorithm which fixes a long-standing bug regarding one pad’s
>>   thermal ring knocking out another pad’s thermal spoke.  It
>>   also allows thermal spokes on custom pad shapes (and would
>>   allow us to support custom number of spokes if we wished).
>>
>>   While this should only change zone fills which would have been
>>   considered errors in the past, it nevertheless changes them.
>>What’s the prescription for that?
>>
>>   Cheers,
>>   Jeff.
>>
>>
>>
>>
>>   --
>>   Jean-Pierre CHARRAS
>>
>>   ___
>>   Mailing list: https://launchpad.net/~kicad-developers
>>   Post to : kicad-developers@lists.launchpad.net
>>   > >
>>   Unsubscribe : https://launchpad.net/~kicad-developers
>>   More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> > >
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> ___
>> Mailing list: 

Re: [Kicad-developers] 6.0 Zone filling differences

[Jeff Young]

New, higher-performance bits in, with some (perhaps all) of the bugs fixed.

Testing would be appreciated.

Cheers,
Jeff.


> On 22 Jun 2019, at 17:36, Jeff Young  wrote:
> 
> There’s no piece of the zone in the middle; that’s just the chamfers on the 
> ends of the spokes.
> 
> The zone doesn’t go between the two pads because their thermal relief value 
> doesn’t allow enough room.
> 
> Cheers,
> Jeff.
> 
> 
>> On 22 Jun 2019, at 17:04, Nick Østergaard > > wrote:
>> 
>> Mmm, I am not sure I under stamd that screenshot. Why are the zone not 
>> touchimg the thermal track between the pads while it looks like there is a 
>> part of zone area on the middle of the thermal track?
>> 
>> lør. 22. jun. 2019 17.58 skrev Jeff Young > >:
>> Our current algorithm will produce thermal connections between two pads 
>> (with no connections to the zone):
>> 
>> 
>> 
>> I assume no one will lose any sleep over dropping those?
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 21 Jun 2019, at 19:49, Jean-Paul Louis >> > wrote:
>>> 
>>> Wayne,
>>> 
>>> Except in very hugh frequency design (higher UHF spectrum, microwaves and 
>>> millimeter waves)
>>> were chamfers can create more problems than they solve.
>>> 
>>> This chamfer should be user optional, the best being individual part layout 
>>> optional.
>>> 
>>> Just my extra data point,
>>> 
>>> Jean-Paul
>>> N1JPL
>>> 
>>> 
 On Jun 21, 2019, at 8:05 AM, Wayne Stambaugh >>> > wrote:
 
 Jeff,
 
 Users are going to expect chamfering if there is an option for it.  I
 don't see how you are going to avoid adding chamfering to the spokes
 unless we decide to do away with chamfering as an option.  I don't think
 that's good idea because right angles on board geometry is generally
 frowned upon.
 
 Wayne
 
 On 6/20/19 4:24 PM, Jeff Young wrote:
> Turns out there’s a slightly unintended side effect.
> 
> Before:
> 
> Note the two truncated thermal spokes to the surface-mount pads at the
> lower right.
> 
> After:
> 
> 
> 
> 
> The bug is fixed, but not that the junctions between the spokes and the
> zone body are no longer chamfered.
> 
> I’d say the “after” is better in that respect too, but again it’s
> definitely different.
> 
> Thoughts?
> 
> Cheers,
> Jeff.
> 
> 
>> On 20 Jun 2019, at 19:50, Reece Pollack > 
>> >> wrote:
>> 
>> Memory is the second thing to go as one ages.
>> 
>> I can't remember what the first one is.
>> 
>> 
>> *From: *"Jeff Young" mailto:j...@rokeby.ie> 
>> >>
>> *To: *"jp charras" mailto:jp.char...@wanadoo.fr> 
>> >>
>> *Cc: *"KiCad Developers" > 
>> > >>
>> *Sent: *Thursday, June 20, 2019 2:46:58 PM
>> *Subject: *Re: [Kicad-developers] 6.0 Zone filling differences
>> 
>> Wow.  That’s sobering.  I wrote the board outline clearance changes….
>> 
>> Age sucks.
>> 
>> 
>>   On 20 Jun 2019, at 19:04, jp charras > 
>>   >> wrote:
>> 
>>   Le 20/06/2019 à 19:24, Jeff Young a écrit :
>> 
>>   I believe we now have a warning, but I can’t remember what
>>   change it was for.  I thought it was for the outline changes,
>>   but from what I can find on the mailing list archive it looks
>>   like we were satisfied that one wouldn’t change anything.
>> 
>>   So remind me what the warning is for?
>> 
>> 
>>   AFAIK, it is for board outline clearance change (taking in accounf or
>>   not the edge cut graphic items thickness, if I correctly remember).
>>   Zone outline changes (only activated if the kicad_advanced
>>   "ForceThickZones=0" option enables it), do not need any warning.
>> 
>> 
>>   The reason behind this request is that I have a new fill
>>   algorithm which fixes a long-standing bug regarding one pad’s
>>   thermal ring knocking out another pad’s thermal spoke.  It
>>   also allows thermal spokes on custom pad shapes (and would
>>   allow us to support custom number of spokes if we wished).
>> 
>>   While this should only change zone fills which would have been
>>   considered errors in the past, it nevertheless changes them.
>>What’s the prescription for that?
>> 
>>   Cheers,

Re: [Kicad-developers] 6.0 Zone filling differences

[Jeff Young]

There’s no piece of the zone in the middle; that’s just the chamfers on the 
ends of the spokes.

The zone doesn’t go between the two pads because their thermal relief value 
doesn’t allow enough room.

Cheers,
Jeff.


> On 22 Jun 2019, at 17:04, Nick Østergaard  wrote:
> 
> Mmm, I am not sure I under stamd that screenshot. Why are the zone not 
> touchimg the thermal track between the pads while it looks like there is a 
> part of zone area on the middle of the thermal track?
> 
> lør. 22. jun. 2019 17.58 skrev Jeff Young  >:
> Our current algorithm will produce thermal connections between two pads (with 
> no connections to the zone):
> 
> 
> 
> I assume no one will lose any sleep over dropping those?
> 
> Cheers,
> Jeff.
> 
> 
>> On 21 Jun 2019, at 19:49, Jean-Paul Louis > > wrote:
>> 
>> Wayne,
>> 
>> Except in very hugh frequency design (higher UHF spectrum, microwaves and 
>> millimeter waves)
>> were chamfers can create more problems than they solve.
>> 
>> This chamfer should be user optional, the best being individual part layout 
>> optional.
>> 
>> Just my extra data point,
>> 
>> Jean-Paul
>> N1JPL
>> 
>> 
>>> On Jun 21, 2019, at 8:05 AM, Wayne Stambaugh >> > wrote:
>>> 
>>> Jeff,
>>> 
>>> Users are going to expect chamfering if there is an option for it.  I
>>> don't see how you are going to avoid adding chamfering to the spokes
>>> unless we decide to do away with chamfering as an option.  I don't think
>>> that's good idea because right angles on board geometry is generally
>>> frowned upon.
>>> 
>>> Wayne
>>> 
>>> On 6/20/19 4:24 PM, Jeff Young wrote:
 Turns out there’s a slightly unintended side effect.
 
 Before:
 
 Note the two truncated thermal spokes to the surface-mount pads at the
 lower right.
 
 After:
 
 
 
 
 The bug is fixed, but not that the junctions between the spokes and the
 zone body are no longer chamfered.
 
 I’d say the “after” is better in that respect too, but again it’s
 definitely different.
 
 Thoughts?
 
 Cheers,
 Jeff.
 
 
> On 20 Jun 2019, at 19:50, Reece Pollack  
> >> wrote:
> 
> Memory is the second thing to go as one ages.
> 
> I can't remember what the first one is.
> 
> 
> *From: *"Jeff Young" mailto:j...@rokeby.ie> 
> >>
> *To: *"jp charras" mailto:jp.char...@wanadoo.fr> 
> >>
> *Cc: *"KiCad Developers"  
>  >>
> *Sent: *Thursday, June 20, 2019 2:46:58 PM
> *Subject: *Re: [Kicad-developers] 6.0 Zone filling differences
> 
> Wow.  That’s sobering.  I wrote the board outline clearance changes….
> 
> Age sucks.
> 
> 
>   On 20 Jun 2019, at 19:04, jp charras  
>   >> wrote:
> 
>   Le 20/06/2019 à 19:24, Jeff Young a écrit :
> 
>   I believe we now have a warning, but I can’t remember what
>   change it was for.  I thought it was for the outline changes,
>   but from what I can find on the mailing list archive it looks
>   like we were satisfied that one wouldn’t change anything.
> 
>   So remind me what the warning is for?
> 
> 
>   AFAIK, it is for board outline clearance change (taking in accounf or
>   not the edge cut graphic items thickness, if I correctly remember).
>   Zone outline changes (only activated if the kicad_advanced
>   "ForceThickZones=0" option enables it), do not need any warning.
> 
> 
>   The reason behind this request is that I have a new fill
>   algorithm which fixes a long-standing bug regarding one pad’s
>   thermal ring knocking out another pad’s thermal spoke.  It
>   also allows thermal spokes on custom pad shapes (and would
>   allow us to support custom number of spokes if we wished).
> 
>   While this should only change zone fills which would have been
>   considered errors in the past, it nevertheless changes them.
>What’s the prescription for that?
> 
>   Cheers,
>   Jeff.
> 
> 
> 
> 
>   -- 
>   Jean-Pierre CHARRAS
> 
>   ___
>   Mailing list: https://launchpad.net/~kicad-developers 
> 
>   Post to : kicad-developers@lists.launchpad.net 
> 

Re: [Kicad-developers] VECTOR2I and VECTOR2D

[Tomasz Wlostowski]

On 22/06/2019 17:41, Reece R. Pollack wrote:
> 
> While it is true that you can add two point coordinates and multiply by
> scalar 0.5 to get the midpoint, this is not true in the general case for
> arbitrary scalar multipliers. However, calculating the vector distance
> between two points, multiplying the vector by a scalar, then adding the
> resulting vector distance to the first point /does/ work in the general
> case.
> 
> This is exactly the sort of bug that can be avoided by not allowing
> arbitrary operations on random vectors.

I've never experienced a bug caused by mixing points/vectors together,
at least in the math code. For passing coordinates/measurements from/to
the GUI it might make sense to create custom types. Moreover, most if
not all geometry libraries I've known used the same class for points and
vectors. Single class for both is IMHO Occam's razor approach. As Seth
already remarked, I would like to hear a solid argument for splitting
point/vector classes, otherwise it looks like bikeshedding to me.

Tom

PS1. I'm surprised no one yet noticed the VECTOR2<> class has public x/y
 members, which is an unforgivable violation of the tenets of classical
OO design :-)

PS2. There are some more serious OOD violations in KiCad codebase. Would
anybody here volunteer to refactor the diamond in EDA_TEXT derivatives,
DRAWSEGMENT/EDGE_MODULE classes or global variables in eeschema?

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

[Nick Østergaard]

Mmm, I am not sure I under stamd that screenshot. Why are the zone not
touchimg the thermal track between the pads while it looks like there is a
part of zone area on the middle of the thermal track?

lør. 22. jun. 2019 17.58 skrev Jeff Young :

> Our current algorithm will produce thermal connections between two pads
> (with no connections to the zone):
>
>
> I assume no one will lose any sleep over dropping those?
>
> Cheers,
> Jeff.
>
>
> On 21 Jun 2019, at 19:49, Jean-Paul Louis  wrote:
>
> Wayne,
>
> Except in very hugh frequency design (higher UHF spectrum, microwaves and
> millimeter waves)
> were chamfers can create more problems than they solve.
>
> This chamfer should be user optional, the best being individual part
> layout optional.
>
> Just my extra data point,
>
> Jean-Paul
> N1JPL
>
>
> On Jun 21, 2019, at 8:05 AM, Wayne Stambaugh  wrote:
>
> Jeff,
>
> Users are going to expect chamfering if there is an option for it.  I
> don't see how you are going to avoid adding chamfering to the spokes
> unless we decide to do away with chamfering as an option.  I don't think
> that's good idea because right angles on board geometry is generally
> frowned upon.
>
> Wayne
>
> On 6/20/19 4:24 PM, Jeff Young wrote:
>
> Turns out there’s a slightly unintended side effect.
>
> Before:
>
> Note the two truncated thermal spokes to the surface-mount pads at the
> lower right.
>
> After:
>
>
>
>
> The bug is fixed, but not that the junctions between the spokes and the
> zone body are no longer chamfered.
>
> I’d say the “after” is better in that respect too, but again it’s
> definitely different.
>
> Thoughts?
>
> Cheers,
> Jeff.
>
>
> On 20 Jun 2019, at 19:50, Reece Pollack  > wrote:
>
> Memory is the second thing to go as one ages.
>
> I can't remember what the first one is.
>
> 
> *From: *"Jeff Young" mailto:j...@rokeby.ie
> >>
> *To: *"jp charras" mailto:jp.char...@wanadoo.fr
> >>
> *Cc: *"KiCad Developers"   >>
> *Sent: *Thursday, June 20, 2019 2:46:58 PM
> *Subject: *Re: [Kicad-developers] 6.0 Zone filling differences
>
> Wow.  That’s sobering.  I wrote the board outline clearance changes….
>
> Age sucks.
>
>
>   On 20 Jun 2019, at 19:04, jp charras> wrote:
>
>   Le 20/06/2019 à 19:24, Jeff Young a écrit :
>
>   I believe we now have a warning, but I can’t remember what
>   change it was for.  I thought it was for the outline changes,
>   but from what I can find on the mailing list archive it looks
>   like we were satisfied that one wouldn’t change anything.
>
>   So remind me what the warning is for?
>
>
>   AFAIK, it is for board outline clearance change (taking in accounf or
>   not the edge cut graphic items thickness, if I correctly remember).
>   Zone outline changes (only activated if the kicad_advanced
>   "ForceThickZones=0" option enables it), do not need any warning.
>
>
>   The reason behind this request is that I have a new fill
>   algorithm which fixes a long-standing bug regarding one pad’s
>   thermal ring knocking out another pad’s thermal spoke.  It
>   also allows thermal spokes on custom pad shapes (and would
>   allow us to support custom number of spokes if we wished).
>
>   While this should only change zone fills which would have been
>   considered errors in the past, it nevertheless changes them.
>What’s the prescription for that?
>
>   Cheers,
>   Jeff.
>
>
>
>
>   --
>   Jean-Pierre CHARRAS
>
>   ___
>   Mailing list: https://launchpad.net/~kicad-developers
>   Post to : kicad-developers@lists.launchpad.net
>    >
>   Unsubscribe : https://launchpad.net/~kicad-developers
>   More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
>  >
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> 

Re: [Kicad-developers] 6.0 Zone filling differences

[Jeff Young]

Our current algorithm will produce thermal connections between two pads (with 
no connections to the zone):



I assume no one will lose any sleep over dropping those?

Cheers,
Jeff.


> On 21 Jun 2019, at 19:49, Jean-Paul Louis  wrote:
> 
> Wayne,
> 
> Except in very hugh frequency design (higher UHF spectrum, microwaves and 
> millimeter waves)
> were chamfers can create more problems than they solve.
> 
> This chamfer should be user optional, the best being individual part layout 
> optional.
> 
> Just my extra data point,
> 
> Jean-Paul
> N1JPL
> 
> 
>> On Jun 21, 2019, at 8:05 AM, Wayne Stambaugh  wrote:
>> 
>> Jeff,
>> 
>> Users are going to expect chamfering if there is an option for it.  I
>> don't see how you are going to avoid adding chamfering to the spokes
>> unless we decide to do away with chamfering as an option.  I don't think
>> that's good idea because right angles on board geometry is generally
>> frowned upon.
>> 
>> Wayne
>> 
>> On 6/20/19 4:24 PM, Jeff Young wrote:
>>> Turns out there’s a slightly unintended side effect.
>>> 
>>> Before:
>>> 
>>> Note the two truncated thermal spokes to the surface-mount pads at the
>>> lower right.
>>> 
>>> After:
>>> 
>>> 
>>> 
>>> 
>>> The bug is fixed, but not that the junctions between the spokes and the
>>> zone body are no longer chamfered.
>>> 
>>> I’d say the “after” is better in that respect too, but again it’s
>>> definitely different.
>>> 
>>> Thoughts?
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> 
 On 20 Jun 2019, at 19:50, Reece Pollack >>> > wrote:
 
 Memory is the second thing to go as one ages.
 
 I can't remember what the first one is.
 
 
 *From: *"Jeff Young" mailto:j...@rokeby.ie>>
 *To: *"jp charras" mailto:jp.char...@wanadoo.fr>>
 *Cc: *"KiCad Developers" >>> >
 *Sent: *Thursday, June 20, 2019 2:46:58 PM
 *Subject: *Re: [Kicad-developers] 6.0 Zone filling differences
 
 Wow.  That’s sobering.  I wrote the board outline clearance changes….
 
 Age sucks.
 
 
   On 20 Jun 2019, at 19:04, jp charras >>>   > wrote:
 
   Le 20/06/2019 à 19:24, Jeff Young a écrit :
 
   I believe we now have a warning, but I can’t remember what
   change it was for.  I thought it was for the outline changes,
   but from what I can find on the mailing list archive it looks
   like we were satisfied that one wouldn’t change anything.
 
   So remind me what the warning is for?
 
 
   AFAIK, it is for board outline clearance change (taking in accounf or
   not the edge cut graphic items thickness, if I correctly remember).
   Zone outline changes (only activated if the kicad_advanced
   "ForceThickZones=0" option enables it), do not need any warning.
 
 
   The reason behind this request is that I have a new fill
   algorithm which fixes a long-standing bug regarding one pad’s
   thermal ring knocking out another pad’s thermal spoke.  It
   also allows thermal spokes on custom pad shapes (and would
   allow us to support custom number of spokes if we wished).
 
   While this should only change zone fills which would have been
   considered errors in the past, it nevertheless changes them.
What’s the prescription for that?
 
   Cheers,
   Jeff.
 
 
 
 
   -- 
   Jean-Pierre CHARRAS
 
   ___
   Mailing list: https://launchpad.net/~kicad-developers
   Post to : kicad-developers@lists.launchpad.net
   
   Unsubscribe : https://launchpad.net/~kicad-developers
   More help   : https://help.launchpad.net/ListHelp
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: 

Re: [Kicad-developers] VECTOR2I and VECTOR2D

[Tomasz Wlostowski]

On 22/06/2019 16:32, hauptmech wrote:
> After reading through vector2d.h and matrix3x3.h, I agree with Reece
> more or less. There is ambiguity in the word vector, between math
> vectors, spatial vectors, and c++ vectors. Context implies that VECTOR2
> refers math vectors, but then MATRIX3x3 * VECTOR2 is allowed which
> violates expectations.  POINT2 and SE2 or HOMOGENEOUS2  would set
> expectations better.

Actually, the name MATRIX3x3 name is a bit misleading - it actually
represents a 2D affine transform. Anybody willing to send a patch
renaming it to XFORM2D or something more descriptive? :)

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] VECTOR2I and VECTOR2D

[Reece R. Pollack]

On 6/22/19 10:52 AM, Seth Hillbrand wrote:

On 2019-06-21 22:54, Reece R. Pollack wrote:

Doing this now, before we go too far down the path of replacing
wxWidgets types with non-OOB arrays would enhance readability and make
the code more robust. Using VECTOR2I is going the wrong way.


Hi Reece-

Codebase cleaning like you suggest can go a long way toward improving 
sustainability and readability.  But done the wrong way, it will have 
the opposite effect as we fight with return types that aren't fully 
matched.


Before we decide to do this type of deep plumbing on the KiCad 
innards, I'd love to see the proposed specification for what's being 
implemented.  Otherwise, this'll be a bike shedding discussion.


I've been in far too many "code reviews" where the focus became the 
naming of variables and not on the algorithm being implemented. So I 
agree with your comment in principle.


That said, the lack of type specificity already makes portions of our 
code hard to maintain. The DIALOG_GRAPHIC_ITEM_PROPERTIES class already 
reuses the m_endX UNIT_BINDER to represent both the X-axis endpoint of 
an object and the radius of a circle. This requires special handling 
when performing display origin transforms because the X-axis endpoint 
requires origin transformation while the circle radius does not. This 
illustrates the risk of treating everything as "just a pair of numbers" 
because it's "easy".


I'm not suggesting rushing into a major change. But replacing a 
descriptive object like wxPoint with a non-descriptive object like 
VECTOR2I isn't an improvement. Especially when its implementation is 
somewhat non-intuitive, as Hauptmech points out.


-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

Re: [Kicad-developers] VECTOR2I and VECTOR2D

[Reece R. Pollack]

On 6/22/19 3:09 AM, Greg Smith wrote:
Adding two points and dividing by two results in a point that is 
minimally equidistant from both points (I.e. The midpoint of the line 
formed by the points).


While it is true that you can add two point coordinates and multiply by 
scalar 0.5 to get the midpoint, this is not true in the general case for 
arbitrary scalar multipliers. However, calculating the vector distance 
between two points, multiplying the vector by a scalar, then adding the 
resulting vector distance to the first point /does/ work in the general 
case.


This is exactly the sort of bug that can be avoided by not allowing 
arbitrary operations on random vectors.


If finding the midpoint between two points proves to be a common 
operation, and is found to be too costly to implement in the general 
fashion, then a special method for determining the midpoint can be 
provided that calculates it in the optimal fashion.


___
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] VECTOR2I and VECTOR2D

[Seth Hillbrand]

On 2019-06-21 22:54, Reece R. Pollack wrote:

Doing this now, before we go too far down the path of replacing
wxWidgets types with non-OOB arrays would enhance readability and make
the code more robust. Using VECTOR2I is going the wrong way.


Hi Reece-

Codebase cleaning like you suggest can go a long way toward improving 
sustainability and readability.  But done the wrong way, it will have 
the opposite effect as we fight with return types that aren't fully 
matched.


Before we decide to do this type of deep plumbing on the KiCad innards, 
I'd love to see the proposed specification for what's being implemented. 
 Otherwise, this'll be a bike shedding discussion.


-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] Additional parameters on simulation dialog

[Seth Hillbrand]

On 2019-06-21 15:00, Sylwester Kocjan wrote:

Hi,

I prepared some changes in KiCad simulation dialog. They are about
additional simulation parameters. According to tutorial, which I've
found on website, I store them on GitHub repository in branch
"Sim_InitialConditions_SK" here:

https://github.com/skocjan/kicad_initialconditions.git

Could you please have a look and do some review if possible? I'd be
grateful for feedback if these changes are OK. In future I'd like to
implement OP analysis using some controls I've added
(https://bugs.launchpad.net/kicad/+bug/1821360).

Additionally I also prepared polish translation for new strings.

My aim was to make simulation with arbitrary initial conditions
possible (additionally I added other options). Right now it is possible
to enable checkbox UIC on TRAN tab, but there is no possibility to set
IC to any arbitrary value in element properties. I'm afraid it will
involve change in .sch format. Please take note that it is also
possible to define initial conditions for entire nodes instead of
capacitors or inductors (for example: ".ic v(11)=5 v(4)=-5 v(2)=2.2",
see ngspice manual, chapter 15.2.2). It is also a challenge.

So in current state we can use for initial conditions results of .OP
analysis or default zero.

From my point of view these are the topics, which should be taken into
account during review:
- in simulation code sometimes there is used '\n', sometimes "\r\n".
Maybe it should be unified? Is there a common definition for newline in
wxWidgets?
- I added .option savecurrents: someone added TODO that it doesn't
work. Maybe should we hide this control?
- something happened to colours on dialog windows, see attached image.
I don't know what is it and how to fix it. seems to be unrelated to my
changes, but maybe I'm wrong? (this is visible on Ubuntu 18.04)
- some feedback regarding how to add IC field to capacitors, inductors
or nodes will be very appreciated ;)

Limitations of my changes:
- parsing SPICE .options is not implemented (in bool
DIALOG_SIM_SETTINGS::parseCommand( const wxString& aCommand ))

Best regards,
Sylwek


Hi Sylwek-

I've had a look through the changes and they generally look good.  There 
are a few minor formatting issues that you'll want to address such as 
tabs being used instead of spaces and two blank lines between functions 
in .cpp files.


- It looks like retval in DIALOG_SIM_SETTINGS::TransferDataToWindow() 
isn't getting initialized properly.
- Are the "," replacements in DIALOG_SIM_SETTINGS::updateNetlistOpts() 
there to provide support for alternate locales?


To your questions:
- In KiCad's codebase, \n is standard.  But we don't really worry about 
the generated files or formbuilder files.  I'll write up a 
.gitattributes file to control this so that its transparent in the 
future.
- The color is, I think, a function of your GTK scheme.  On my machine 
the tab panels are white and not grey.  This is true not just for your 
changes.
- The IC field could be added as a key-value parameter in the existing 
format.  Something like SPICE_IC and then pairs of values "[1 0.5]; [2 
0]" where the first element in each pair is the node number and the 
second is the IC.


Thank you very much for taking the time to work on improving this area 
of KiCad!  It will be greatly appreciated by many of our users.


Best-
Seth

___
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] VECTOR2I and VECTOR2D

[hauptmech]

After reading through vector2d.h and matrix3x3.h, I agree with Reece 
more or less. There is ambiguity in the word vector, between math 
vectors, spatial vectors, and c++ vectors. Context implies that VECTOR2 
refers math vectors, but then MATRIX3x3 * VECTOR2 is allowed which 
violates expectations.  POINT2 and SE2 or HOMOGENEOUS2  would set 
expectations better.


If you are working with homogeneous coordinates and want to operate at 
the math vector & matrix level of abstraction (often my preference) then 
using a VECTOR3 would be clearer than hacking a VECTOR2.



-Hauptmech

On 22/06/2019 9:28 PM, Tomasz Wlostowski wrote:

On 22/06/2019 09:09, Greg Smith wrote:


I think the biggest point I am making is that, mathematically, a point
is identical to a vector from 0,0.


Hi Greg & Reece,

This is precisely the reason why we don't have separate point and vector
classes.

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




___
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] VECTOR2I and VECTOR2D

[Reece R. Pollack]

The evolution from untyped variables to weakly-typed variables to 
strongly-typed variables to OOP techniques has never been about what is 
easiest for the programmer nor fastest running. It's about producing 
correct, reliable, maintainable software. The argument that "it'll be 
too slow" is almost never true and then almost always easily addressed.


On 6/22/19 3:09 AM, Greg Smith wrote:
In addition, treating points as vectors make a variety of required 
transformations much easier. Wrapping the two numbers in an object 
that disallows common transformations, calculations, and combinations 
seems unnecessary and will result in significantly slower code.



___
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] VECTOR2I and VECTOR2D

[Tomasz Wlostowski]

On 22/06/2019 09:09, Greg Smith wrote:

> 
> I think the biggest point I am making is that, mathematically, a point
> is identical to a vector from 0,0.
> 

Hi Greg & Reece,

This is precisely the reason why we don't have separate point and vector
classes.

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] VECTOR2I and VECTOR2D

[Greg Smith]

In graphics/CAD packages, a point can be considered a vector from point 0,0. 
This is an interpretation that makes sense to me. Adding two points and 
dividing by two results in a point that is minimally equidistant from both 
points (I.e. The midpoint of the line formed by the points). In addition, 
treating points as vectors make a variety of required transformations much 
easier. Wrapping the two numbers in an object that disallows common 
transformations, calculations, and combinations seems unnecessary and will 
result in significantly slower code.

I think the biggest point I am making is that, mathematically, a point is 
identical to a vector from 0,0.

Greg S.

> On Jun 21, 2019, at 10:04 PM, Reece R. Pollack  wrote:
> 
> Whoops, hit "send" too soon. "Is a simple array" is obviously incorrect. My 
> point was the lack of descriptiveness is a problem. The absence of 
> differentiation between a location and a distance is a missed opportunity. 
> And the abuse of the type as a loosely-related pair of values should be 
> considered a bug.
> 
>> On 6/21/19 10:54 PM, Reece R. Pollack wrote:
>> A while back, Jeff emailed me a note suggesting that KiCad was trying to 
>> decouple from the wxWidgets type wxPoint except where needed in the UI code. 
>> He suggested that I should use VECTOR2I instead.
>> 
>> I understand and support the desire to decouple from wxWidgets. However, 
>> looking at the implementation of vector2d.h I was surprised to discover that 
>> VECTOR2I is a simple array of int like I would find in an old Fortran 
>> program. It's not even a C structure, let alone a well-defined C++ object.
>> 
>> One of the goals of object-oriented programming is to create descriptive 
>> objects. Programmers can tell what an object represents by looking at the 
>> name and implementation of the object. Well-crafted object help avoid 
>> programming errors that could result from performing undefined operations or 
>> using data from incompatible objects. In geometry, if we subtract the 2d 
>> location of one point from the 2d location of another point the result is a 
>> 2d vector describing the distance between these points. However, this vector 
>> is not a point. In OOP this vector should be a different object than a point.
>> 
>> The wxWidgets objects wxPoint and wxRealPoint are descriptively named, 
>> though poorly implemented. Aside from where code abuses these, they clearly 
>> represent locations.  Replacing these with non-OOB typedefs such as VECTOR2I 
>> removes the clarity that a variable is intended to represent a location. The 
>> name is not descriptive of a location. There is no sanity check to prevent 
>> performing a nonsensical operation like adding two locations. It tells the 
>> programmer nothing about whether a variable contains a location, a length, 
>> or just two loosely-related values.
>> 
>> Rather than replacing wxPoint with VECTOR2I, let us consider how we can make 
>> our code more object-oriented rather than more Fortran-like. I believe we 
>> should replace wxPoint and wxRealPoint with KiCad-specific objects. These 
>> objects should be named such that they clearly indicate that they of 
>> represent locations rather than a simple array of integer values. They 
>> should be implemented such that nonsensical operations are prohibited and 
>> sanity checks put in place where possible. For example, attempting to add 
>> two locations should result in a compile-time error. Additional objects 
>> should be defined to represent the delta between two locations, and the 
>> operations of adding a delta to a location should result in a location.
>> 
>> Just for discussion, let's assume the replacement for wxPoint is named 
>> KiPoint. The result of subtracting two KiPoint objects would be another 
>> object called KiDelta. Adding two KiPoint objects should be undefined, and 
>> result in a compile-time error, as this is a nonsense operation.  Adding a 
>> KiPoint and a KiDelta should return a KiPoint. We should never abuse a 
>> KiPoint to represent anything else, such as using the X value as the radius 
>> of a circle as is currently done. I suspect most of the places where this 
>> would be much more than a mechanical substitution is a place where the code 
>> abuses the type or is a latent bug.
>> 
>> Doing this now, before we go too far down the path of replacing wxWidgets 
>> types with non-OOB arrays would enhance readability and make the code more 
>> robust. Using VECTOR2I is going the wrong way.
>> 
>> -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 :