kicad-developers team mailing list archive

[Andrew Lutsenko <anlutsenko@xxxxxxxxx>]

Sure,

Afaik, 5.0.1 can be expected to be released in couple months vs undefined
5.1 release date (my current gut feeling is 6-12 months, feel free to
correct me). The main reason I would like to see this patch in 5.0.1 is to
not have to ask users of my plugin to run nightlies for a year.
I provided pre-built patched python bindings for win64 but can't do it for
every platform.

My patch also can hardly be classified as a "feature" since it is
essentially not new code, only swig config change. In some lens it also
fixes a regression since in KiCad 4 you could read all footprint pads from
python and in 5 you currently can't.

But I admit that I'm biased :)

On Wed, Aug 8, 2018 at 4:48 PM Seth Hillbrand <seth@xxxxxxxxxxxxx> wrote:

> Hi Andrew-
>
> No bother at all.  Sorry for the slow responses.  Feel free to keep asking
> if you don't get an answer.
>
> The recent change was a regression in v5 vs v4.  The difference is in
> where we draw the feature vs. bug fix line.  Can you give a bit more
> information about why 5.0.1 is important vs. 5.1?  Unless Wayne wants to
> jump in give the green light, this feels like a feature that could wait.
>
> -Seth
>
> Am Mi., 8. Aug. 2018 um 16:16 Uhr schrieb Andrew Lutsenko <
> anlutsenko@xxxxxxxxx>:
>
>> Hi Seth,
>>
>> Sorry to be repeating myself but since I didn't get any response I
>> assumed this just slipped through everyone's attention.
>>
>> I noticed that a fix of very similar scope to mine was pushed to both dev
>> and 5.0 branches (Re-add missing SWIG zone filler).
>> Can my patch be pushed to 5.0 too, please?
>>
>> Regards,
>> Andrew
>>
>> On Fri, Aug 3, 2018 at 11:03 AM Andrew Lutsenko <anlutsenko@xxxxxxxxx>
>> wrote:
>>
>>> Awesome, thanks!
>>> Qa machine seems happy too.
>>>
>>> So is there any chance of this getting into 5.0 branch?
>>>
>>> I published my plugin earlier here
>>> https://github.com/openscopeproject/InteractiveHtmlBom
>>>
>>> And it generated a fair amount of interest on kicad.info
>>>
>>> https://forum.kicad.info/t/interactive-html-bom-plugin-for-kicad-5-0/11713
>>>
>>> Plugin doesn't require this patch but without it it can't render custom
>>> shape pads and any graphics on copper/silkscreen.
>>> Would be great to see this in 5.0.1 but I understand if you only want to
>>> put critical fixes in that release.
>>>
>>> Regards,
>>> Andrew
>>>
>>> On Fri, Aug 3, 2018 at 5:35 AM Wayne Stambaugh <stambaughw@xxxxxxxxx>
>>> wrote:
>>>
>>>> Andrew,
>>>>
>>>> I merged your patch into the development branch of KiCad.  Thank you for
>>>> your contribution to KiCad.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> On 7/31/2018 5:34 PM, Andrew Lutsenko wrote:
>>>> > Removing or renaming operator<< does not work because it is used by
>>>> > boost test suite in qa/geometry/test_fillet.cpp
>>>> >
>>>> > But I found an easier solution. There is no need to have friend
>>>> > declaration in VECTOR2 class at all because it's fields are public
>>>> anyway.
>>>> > I removed that declaration but kept operator<< implementation and that
>>>> > compiles just fine. Tested on debian8 and msys2.
>>>> >
>>>> > If this solution is acceptable to you, see my amended patch attached.
>>>> >
>>>> > Andrew
>>>> >
>>>> >
>>>> > On Tue, Jul 31, 2018 at 1:01 PM Wayne Stambaugh <stambaughw@xxxxxxxxx
>>>> > <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>> >
>>>> >     If option 2 is the only option that works, please make sure to
>>>> set the
>>>> >     minimum swig version in the cmake file that finds swig.  I would
>>>> rather
>>>> >     the config fail then the build fail because an unusable version
>>>> of swig
>>>> >     is found.
>>>> >
>>>> >     On 7/31/2018 2:57 PM, Andrew Lutsenko wrote:
>>>> >     > I will test later today both options
>>>> >     > 1. Removing VECTOR2::operator<< or renaming it to str() if it's
>>>> used.
>>>> >     > 2. Upgrading to swig 3.0.10 from backports.
>>>> >     >
>>>> >     > Hopefully first is doable and would be transparent for users.
>>>> >     > Second one should definitely solve the issue and I feel like
>>>> >     compared to
>>>> >     > other hoops a user has to jump through to make KiCad compile on
>>>> >     debian8
>>>> >     > this would not be the worst.
>>>> >     >
>>>> >     > Regards,
>>>> >     > Andrew
>>>> >     >
>>>> >     > On Tue, Jul 31, 2018 at 11:32 AM Wayne Stambaugh
>>>> >     <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>>>> >     > <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>
>>>> wrote:
>>>> >     >
>>>> >     >     On 7/31/2018 1:13 PM, Seth Hillbrand wrote:
>>>> >     >     >
>>>> >     >     >
>>>> >     >     > Am Di., 31. Juli 2018 um 07:31 Uhr schrieb Wayne Stambaugh
>>>> >     >     > <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>>>> >     <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>>>> >     >     <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>
>>>> >     <mailto:stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>>>:
>>>> >     >     >
>>>> >     >     >     On 7/31/2018 8:33 AM, Carsten Schoenert wrote:
>>>> >     >     >     > Am 31.07.18 um 17:50 schrieb Andrew Lutsenko:
>>>> >     >     >     > ...
>>>> >     >     >     >> Can swig on the qa machine be updated? Or better
>>>> yet
>>>> >     can you
>>>> >     >     >     upgrade to
>>>> >     >     >     >> debian 9? Debian 9 has swig 3.0.10 and compiles
>>>> this
>>>> >     just fine.
>>>> >     >     >     >> Aside from this debian 8 is very old and should be
>>>> done
>>>> >     >     away with
>>>> >     >     >     anyway
>>>> >     >     >     >> because of security, old compilers, etc.
>>>> >     >     >     >
>>>> >     >     >     > Argumentation by missing security isn't a valid
>>>> >     choice, even
>>>> >     >     now the
>>>> >     >     >     > ELTS team is taking care of security updates, old
>>>> versions
>>>> >     >     can be
>>>> >     >     >     solved
>>>> >     >     >     > by using backports, even swig has 3.0.10 in
>>>> >     >     jessie-backports. I agree
>>>> >     >     >     > that GCC wont become any version updates for Jessie.
>>>> >     >     >     >
>>>> >     >     >     > But there are still users out there which use
>>>> Jessie based
>>>> >     >     desktops.
>>>> >     >     >     >
>>>> >     >     >
>>>> >     >     >     I'm siding with Carsten on this.  There are people who
>>>> >     prefer
>>>> >     >     stable
>>>> >     >     >     computing platforms and I want to avoid making kicad
>>>> only
>>>> >     >     build on the
>>>> >     >     >     latest distros.  I prefer that we keep as large of a
>>>> target
>>>> >     >     audience as
>>>> >     >     >     possible.  How difficult would it be to change the
>>>> >     >     SHAPE_LINE_CHAIN
>>>> >     >     >     object (actually its the VECTOR2 object that causes
>>>> the swig
>>>> >     >     issue) so
>>>> >     >     >     that older versions of swig don't choke on it?  I
>>>> would be
>>>> >     >     open to that
>>>> >     >     >     solution.
>>>> >     >     >
>>>> >     >     >     Cheers,
>>>> >     >     >
>>>> >     >     >     Wayne
>>>> >     >     >
>>>> >     >     >
>>>> >     >     > ​I'm not sure I follow the discussion.  I thought Carsten
>>>> >     was saying
>>>> >     >     > that jessie-backports does have SWIG 3.0.10 and so we can
>>>> >     upgrade swig
>>>> >     >     > on the kicad-qa​ without changing to a newer debian.
>>>> >     >
>>>> >     >     I was operating under the assumption that not every user
>>>> will
>>>> >     track or
>>>> >     >     want to track Debian backports so in this case the user
>>>> would
>>>> >     still only
>>>> >     >     have the older version of swig.  The line of code that is
>>>> >     causing swig
>>>> >     >     to choke is the VECTOR2 << operator which I'm almost sure is
>>>> >     being used
>>>> >     >     for debugging output and therefore could easily be removed
>>>> without
>>>> >     >     issue.  I'm not sure that there are not other swig related
>>>> >     issues in the
>>>> >     >     SHAPE_LINE_CHAIN implementation this change may not be
>>>> >     enough.  If we
>>>> >     >     are going to use a version of swig that works with the
>>>> current
>>>> >     code, we
>>>> >     >     should set the cmake find package minimum version of swig to
>>>> >     the correct
>>>> >     >     version.  I'm fine either way.  Others may not be fine with
>>>> this.
>>>> >     >
>>>> >     >     >
>>>> >     >     > @Andrew - can you compile your changes on debian 8 using
>>>> the
>>>> >     swig from
>>>> >     >     > backports as Carsten described?  If not, then this is
>>>> moot and
>>>> >     >     we'd need
>>>> >     >     > to look at a SWIG-specific VECTOR2, an outcome that might
>>>> be
>>>> >     long-term
>>>> >     >     > problematic.
>>>> >     >     >
>>>> >     >     > -S
>>>> >     >
>>>> >     >     _______________________________________________
>>>> >     >     Mailing list: https://launchpad.net/~kicad-developers
>>>> >     <https://launchpad.net/%7Ekicad-developers>
>>>> >     >     <https://launchpad.net/%7Ekicad-developers>
>>>> >     >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>> >     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>>> >     >     Unsubscribe : https://launchpad.net/~kicad-developers
>>>> >     <https://launchpad.net/%7Ekicad-developers>
>>>> >     >     <https://launchpad.net/%7Ekicad-developers>
>>>> >     >     More help   : https://help.launchpad.net/ListHelp
>>>> >     >
>>>> >
>>>>
>>>