Jon,

I've asked Reece to make Seth's recommended change to lower the merge
impact so it will probably be a while until thus is completed.  Go ahead
and cherry-pick the backlog from 5.1.

Thanks,

Wayne

On 5/26/19 3:54 PM, Jon Evans wrote:
> Hi Reece, Wayne, Seth,
> 
> Can you clarify the path forward here?  Are we going to merge the second
> patchset and then do follow-ons to take care of the issues Seth raised,
> or will there be another full patchset coming?
> I have a backlog of things to cherry-pick from 5.1 to master that I've
> been holding on to until this is resolved.
> 
> Thanks,
> -Jon
> 
> On Sun, May 26, 2019 at 2:08 PM Reece R. Pollack <re...@his.com
> <mailto:re...@his.com>> wrote:
> 
>     So _now_ it occurs to me that what I should have done was create
>     classes derived from UNIT_BINDER that handle the different types of
>     data (X-abs, Y-abs, X-rel, Y-rel) and instantiated those, rather
>     than adding a parameter to the UNIT_BINDER class.
> 
>     However, that would have also required changing UNIT_BINDER to
>     accept and return /double/ values rather than /int/ to avoid the
>     /int/ -> /double/ -> /int/ -> /double/ conversion sequence
>     formatting for display, and /double/ -> /int/ -> /double/ -> /int/
>     conversions parsing from display.
> 
>     Maybe I'll do that another time. Too many changes too late for this
>     iteration, I think.
> 
>     On 5/26/19 11:01 AM, Reece Pollack wrote:
>>     The specific problem with UNIT_BINDER is that it doesn't know what
>>     sort of data it's handling. It could be a value like a track width
>>     which shouldn't be altered,  a relative coordinate delta which may
>>     need a sign flip, or an absolute coordinate which needs both
>>     translation and sign flip. Nor does it know whether relative or
>>     absolute coordinate is an X or a Y axis. Thus it must either have
>>     a parameter identifying the type of data it's handling or a
>>     different set of methods to transfer that data in or out based on
>>     the type. I chose a constructor parameter, and I chose to pass an
>>     object implemented to handle that type of data.
>>
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     Post to     : kicad-developers@lists.launchpad.net
>     <mailto: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

Reply via email to