Avoiding breaking changes can be handled by increasing the testing surface,
kicad-python has testing, but it's not currently being executed on every commit.
While the native bindings are being tested on every commit by the
kicad-ci [1] [2]:
Increasing the test surface could be useful in many ways
On 9/19/2016 9:52 AM, Michael Steinberg wrote:
> Hello Wayne, Torsten & All,
>
>
> Am 19.09.2016 um 15:17 schrieb Wayne Stambaugh:
>> I'm going to make an executive decision here so this doesn't drag on.
>> In short, swig stays. Any other python bindings would either be on top
>> of or along sid
Hello Wayne, Torsten & All,
Am 19.09.2016 um 15:17 schrieb Wayne Stambaugh:
I'm going to make an executive decision here so this doesn't drag on.
In short, swig stays. Any other python bindings would either be on top
of or along side current swig bindings. Swig is a valid tool for
generating
I'm going to make an executive decision here so this doesn't drag on.
In short, swig stays. Any other python bindings would either be on top
of or along side current swig bindings. Swig is a valid tool for
generating scripting language bindings. Lots of other projects use it
with great success s
Hi Tom & Michael,
I'm using the scripting interface quite often and had never that much trouble with it.
The currently missing std::unique_ptr is not an argument, it is still possible to use it, see
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
I'm quite
That sounds to me like it would make sense use kicad-python such that we
can get yhe external API defined, and _ideally_ we could do whatever
internally to kicad, let that be swig replacement or not.
I suspect that having the external API defined would make it easier to find
a better implementatio
Hello all!
Am 17.09.2016 um 23:39 schrieb Cirilo Bernardo:
On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski
mailto:tomasz.wlostow...@cern.ch>> wrote:
[...]
I agree with all that as well. I think the best thing to do is create
a PCB API
which provides C bindings and people can make
On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski <
tomasz.wlostow...@cern.ch> wrote:
> On 16.09.2016 18:01, Michael Steinberg wrote:
> > Hello all,
> >
> > when activating python bindings on my msvc build with a few refactor
> > commits applied, it came to my attention that SWIG simply does not
A transition time as wayne suggests could be a reasonable thing, with
enough time,
and a proper deprecation notice users would be able to transition into a new API
(please consider looking at [1], I spent quite a long time modeling that based
on the initial work of Piers Titus van der Torren)
Let
On 9/16/2016 2:13 PM, Michael Steinberg wrote:
> Hello Wayne,
>
>> Yet. I'm sure they are going to have to implement it at some point.
>> You can always write your own swig wrapper something like this:
>> http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
>>
> They ha
On Fri, Sep 16, 2016 at 08:13:13PM +0200, Michael Steinberg wrote:
> Hello Wayne,
>
> >Yet. I'm sure they are going to have to implement it at some point.
> >You can always write your own swig wrapper something like this:
> >http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-wi
Hello Wayne,
Yet. I'm sure they are going to have to implement it at some point.
You can always write your own swig wrapper something like this:
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
They had 5+ years to add support, they didn't. So I wouldn't count on
On 9/16/2016 12:01 PM, Michael Steinberg wrote:
> Hello all,
>
> when activating python bindings on my msvc build with a few refactor
> commits applied, it came to my attention that SWIG simply does not
> support std::unique_ptr.
Yet. I'm sure they are going to have to implement it at some point
2016-09-16 18:08 GMT+02:00 Tomasz Wlostowski :
> On 16.09.2016 18:01, Michael Steinberg wrote:
>> Hello all,
>>
>> when activating python bindings on my msvc build with a few refactor
>> commits applied, it came to my attention that SWIG simply does not
>> support std::unique_ptr.
>>
>> With this m
On 16.09.2016 18:01, Michael Steinberg wrote:
> Hello all,
>
> when activating python bindings on my msvc build with a few refactor
> commits applied, it came to my attention that SWIG simply does not
> support std::unique_ptr.
>
> With this message I want to ask what is the common view whether i
Hello all,
when activating python bindings on my msvc build with a few refactor
commits applied, it came to my attention that SWIG simply does not
support std::unique_ptr.
With this message I want to ask what is the common view whether it is
okay to have SWIG thumbscrew the project's source
16 matches
Mail list logo
