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 <s...@hillbrand.org> 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 < > anlutse...@gmail.com>: > >> 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 <anlutse...@gmail.com> >> 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 <stambau...@gmail.com> >>> 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 <stambau...@gmail.com >>>> > <mailto:stambau...@gmail.com>> 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 >>>> > <stambau...@gmail.com <mailto:stambau...@gmail.com> >>>> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> >>>> wrote: >>>> > > >>>> > > On 7/31/2018 1:13 PM, Seth Hillbrand wrote: >>>> > > > >>>> > > > >>>> > > > Am Di., 31. Juli 2018 um 07:31 Uhr schrieb Wayne Stambaugh >>>> > > > <stambau...@gmail.com <mailto:stambau...@gmail.com> >>>> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>> >>>> > > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com> >>>> > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>>: >>>> > > > >>>> > > > 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@lists.launchpad.net >>>> > <mailto:kicad-developers@lists.launchpad.net> >>>> > > <mailto:kicad-developers@lists.launchpad.net >>>> > <mailto:kicad-developers@lists.launchpad.net>> >>>> > > Unsubscribe : https://launchpad.net/~kicad-developers >>>> > <https://launchpad.net/%7Ekicad-developers> >>>> > > <https://launchpad.net/%7Ekicad-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