Andrew,
I went ahead an merged this into the 5.0 branch since it does restore
the version 4 behavior.
Thanks,
Wayne
On 8/8/2018 8:12 PM, Andrew Lutsenko wrote:
> 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
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
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,
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
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
>
>
Am Di., 31. Juli 2018 um 14:35 Uhr schrieb Andrew Lutsenko <
anlutse...@gmail.com>:
> 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
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
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
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
On 7/31/2018 1:13 PM, Seth Hillbrand wrote:
>
>
> Am Di., 31. Juli 2018 um 07:31 Uhr schrieb Wayne Stambaugh
> 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
Am Di., 31. Juli 2018 um 07:31 Uhr schrieb Wayne Stambaugh <
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
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
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
Hi Nick,
Oh, my apologies. Gmail decided to chuck Seth's last message into spam for
whatever reason.
Seth,
I did quite a bit of digging and testing on debian8 VM.
Issue is not gcc, it's because of old swig.
This was fixed in swig 3.0.6, see
Hi Andrew
Seth already shared the build log.
tir. 31. jul. 2018 05.29 skrev Andrew Lutsenko :
> I just noticed that my patch was reverted with reference to a build
> failure with gcc 4.9.2
>
> Could you share the error messages too?
> Also curios which platform uses such ancient compiler. I
I just noticed that my patch was reverted with reference to a build failure
with gcc 4.9.2
Could you share the error messages too?
Also curios which platform uses such ancient compiler. I tried msys2, it
only has gcc back to 5.1 and even debian stable uses 6.3.
I'm more than willing to put in
Hi Andrew-
Unfortunately your patch did not compile correctly in our qa system. It
compiled for me (Linux/gcc 6) with only normal SWIG warnings but the qa
system uses a different setup and encountered an error. You can view the
output here: http://ci.kicad-pcb.org/job/kicad-qa/4415/
I suspect
Thank you Seth,
Any chance this can be pushed to 5.0 branch too?
> Keep in mind that the SWIG-based interface will (hopefully) be retired
soon in favor of a fully-abstracted KiCad scripting language.
Oh. When that happens there hopefully will be a transition period to give
plugin writers a
This compiles cleanly and does not appear to have negative side effects so
I pushed it. I made a small change to the boilerplate in math.i.
Keep in mind that the SWIG-based interface will (hopefully) be retired soon
in favor of a fully-abstracted KiCad scripting language. But since that
goal is
Hi Andrew,
Many of the folks on this list may be taking a break after this past
weekend's release. Please do not take a few day's silence right now as any
sort of sign. :)
Adam
On Tue, Jul 24, 2018, 10:29 PM Andrew Lutsenko wrote:
> Hello,
>
> Can someone take a look at my patch please?
>
Hello,
Can someone take a look at my patch please?
It's my first so if I didn't submit it correctly please bear with me, I
believe I did everything according to developers documentation.
It would be great to see this in next release. Patch applies cleanly to
both 5.0 branch and master.
Regards,
I figured it out, please see attached patch for the fix.
On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko
wrote:
> I tried adding this in kicad.i
>
> #include
> %include
>
> It compiles and SHAPE_LINE_CHAIN type shows up in pcbnew.py
>
> But I need VECTOR2I as well to get the actual
22 matches
Mail list logo
