Re: [Kicad-developers] SWIG binding

[Wayne Stambaugh]

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 side current swig bindings.  Swig is a valid tool for
>> generating scripting language bindings.  Lots of other projects use it
>> with great success so it can't be all bad.  We already have a large
>> investment of time in the current swig bindings along with lots of
>> project and user scripts that use them.  I do not want to discard that
>> investment of time and effort.  If anyone feels so inclined to write
>> some other python interface, there cannot be namespace clashes with the
>> current python bindings.
>>
>> On 9/19/2016 5:49 AM, "Torsten Hüter" wrote:
>>> 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 sure that in the future almost any C++ 11 features will be
>>> supported by swig.
>>> Pybind is - as you have written - generatorless, in my opinion this is
>>> exactly the downside.
>>> You have to write wrappers yourself, while with swig you're simply
>>> including headers in the *.i files.
>>>   
> 
> I'm fine with staying with SWIG (See I also added it in the points of
> possible options twice). But still I'm left with contradicting
> statements about the stability of the blobs the current SWIG headers
> spit out. While Wayne's main point is that we cannot break existing
> scripts, Thorsten says that is no problem at all. If refactoring and
> exporting it like usual is no problem, then I have nothing left to
> argument about, because the initial problem I was addressing was
> non-existant to begin with (I'd like that, because it means no work!).
> If that is not the case, just saying SWIG stays is fixing the
> technicality, but not the specified API concerns imho.
> 
> Michael
> 

I'm not suggesting that we will always have absolute api stability.  I'm
not sure that is even realistic.  I can't think of a project of any
significance that's been around for any length of time who's api didn't
break something at some point.  Yes, event the C language had it's
moments way back when.  There may be occasions when we have to break
existing behavior.  However, most of the low level objects in pcbnew
have not changed significantly over the last few years.  We've added new
functions to the api but we haven't made major changes to the existing
api.  I don't remember anyone ever complaining about this but I may have
missed it.

___
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

Re: [Kicad-developers] SWIG binding

[Michael Steinberg]

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 scripting language bindings.  Lots of other projects use it
with great success so it can't be all bad.  We already have a large
investment of time in the current swig bindings along with lots of
project and user scripts that use them.  I do not want to discard that
investment of time and effort.  If anyone feels so inclined to write
some other python interface, there cannot be namespace clashes with the
current python bindings.

On 9/19/2016 5:49 AM, "Torsten Hüter" wrote:

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 sure that in the future almost any C++ 11 features will be

supported by swig.
Pybind is - as you have written - generatorless, in my opinion this is
exactly the downside.
You have to write wrappers yourself, while with swig you're simply
including headers in the *.i files.
  


I'm fine with staying with SWIG (See I also added it in the points of 
possible options twice). But still I'm left with contradicting 
statements about the stability of the blobs the current SWIG headers 
spit out. While Wayne's main point is that we cannot break existing 
scripts, Thorsten says that is no problem at all. If refactoring and 
exporting it like usual is no problem, then I have nothing left to 
argument about, because the initial problem I was addressing was 
non-existant to begin with (I'd like that, because it means no work!). 
If that is not the case, just saying SWIG stays is fixing the 
technicality, but not the specified API concerns imho.


Michael

___
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

Re: [Kicad-developers] SWIG binding

[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 scripting language bindings.  Lots of other projects use it
with great success so it can't be all bad.  We already have a large
investment of time in the current swig bindings along with lots of
project and user scripts that use them.  I do not want to discard that
investment of time and effort.  If anyone feels so inclined to write
some other python interface, there cannot be namespace clashes with the
current python bindings.

On 9/19/2016 5:49 AM, "Torsten Hüter" wrote:
> 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 sure that in the future almost any C++ 11 features will be
> supported by swig.
> Pybind is - as you have written - generatorless, in my opinion this is
> exactly the downside.
> You have to write wrappers yourself, while with swig you're simply
> including headers in the *.i files.
>  
> --
>  
> About the pythonish API:
> Although this sounds good, I'm sceptical - simply because the very
> limited ressources of the KiCad developers,
> something like this has to be regularly maintained. This means
> documentation too, both C++ and Python.
>  
> As Miguel has written, there is already some work by Piers Titus van der
> Torren, see
> https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py
>  
> I've not used that, because I've found it easy enough to work with the
> swigged functions.
> Even when internals are refactored, in most cases I've found it easy to
> adapt my scripts, this is only an issue between
> the releases - even with an abstraction layer you don't know if
> something has to be changed.
>  
> Python helper functions would be nice, but I'd still like to have full
> access to as much as possible PCBNEW methods.
>  
> --
>  
> In my opinion the work should be invested elsewhere - for instance a
> launcher for python scripts is missing.
> Sure there is a console, but ideally I'd like to press a button, a
> keystroke or similar to launch my script.
> Also several functions are not yet wrapped, like the P router or the
> tool framework (working with selections etc.).
>  
> Thanks,
> Torsten
>  
>> 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 code, considering
>> there are alternative generators, and generatorless libraries like
>> pybind11. Of those alternatives I would *personally* prefer the latter,
>> as it is no black box and the binding generation is part of the normal
>> c++ source code.
>> There's been a discussion on the irc channel regardings this and also
>> the dependency on having wx exported as well. So I thought the logical
>> consequence would be to broaden the audience and move the discussion here.
> 
> Hi Michael,
> 
> It may sound controversial, but I'd say using SWIG is a bad idea: we
> expose for the people the internal APIs of pcbnew that we intend to
> refactor in the near future. Any change to the BOARD storage model means
> a change to the scripting API. IMHO we should have a more pythonish API
> that hides all C++ stuff from the python side completely and is
> independent from the changes in pcbnew's core.
> 
> Cheers,
> Tom
>  
> 
> 
> ___
> 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

Re: [Kicad-developers] SWIG binding

[Torsten Hüter]

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 sure that in the future almost any C++ 11 features will be supported by swig.
Pybind is - as you have written - generatorless, in my opinion this is exactly the downside.

You have to write wrappers yourself, while with swig you're simply including headers in the *.i files.

 

--

 

About the pythonish API:

Although this sounds good, I'm sceptical - simply because the very limited ressources of the KiCad developers,
something like this has to be regularly maintained. This means documentation too, both C++ and Python.

 

As Miguel has written, there is already some work by Piers Titus van der Torren, see
https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py

 

I've not used that, because I've found it easy enough to work with the swigged functions.
Even when internals are refactored, in most cases I've found it easy to adapt my scripts, this is only an issue between

the releases - even with an abstraction layer you don't know if something has to be changed.

 

Python helper functions would be nice, but I'd still like to have full access to as much as possible PCBNEW methods.

 

--

 

In my opinion the work should be invested elsewhere - for instance a launcher for python scripts is missing.
Sure there is a console, but ideally I'd like to press a button, a keystroke or similar to launch my script.

Also several functions are not yet wrapped, like the P router or the tool framework (working with selections etc.).

 

Thanks,
Torsten


 



> 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 code, considering
> there are alternative generators, and generatorless libraries like
> pybind11. Of those alternatives I would *personally* prefer the latter,
> as it is no black box and the binding generation is part of the normal
> c++ source code.
> There's been a discussion on the irc channel regardings this and also
> the dependency on having wx exported as well. So I thought the logical
> consequence would be to broaden the audience and move the discussion here.

Hi Michael,

It may sound controversial, but I'd say using SWIG is a bad idea: we
expose for the people the internal APIs of pcbnew that we intend to
refactor in the near future. Any change to the BOARD storage model means
a change to the scripting API. IMHO we should have a more pythonish API
that hides all C++ stuff from the python side completely and is
independent from the changes in pcbnew's core.

Cheers,
Tom
 




___
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

Re: [Kicad-developers] SWIG binding

[Nick Østergaard]

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 implementation and tests. But I warn you, I am by no means an
expert in this kind of work.

Den 18/09/2016 16.15 skrev "Michael Steinberg" :

> Hello all!
> Am 17.09.2016 um 23:39 schrieb Cirilo Bernardo:
>
>
>
> On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski <
> 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 whatever scripting
> language API on top of that; this way there will be a much more uniform
> scheme for everyone. I was thinking about this while working on the STEP
> exporter but the more I looked at things, the bigger the job became.
> Eventually I thought it would take me a year or even more hacking at it
> part-time so I put it on the deferred list of things to do. Until we have
> such
> an API, I think things will be a bit of a mess. On the other hand some
> people want a scripting API now and can't wait for some part-time coder
> to come up with something in a year or two.
>
>
> So I conclude that we pretty much all agree it's a bad idea to export a
> rather unconstrained set of internals to python or any scripting. I think
> we also agree that we can't just drop the current state immediately. Beside
> these points I see a set of diverging technical strategies to implement it
> the right way (tm):
>
> 1.) Keep SWIG, wrap the output on the python side to a specified API
> 2.) Drop SWIG and interface with python.h ourselves without convenience
> libraries
> 3.) Drop SWIG, implement a C-API, write bindings in any language vs. C-API
> 4.) Drop SWIG, use compiler-based c++ bindings adhering the specified API
> (pybind11-like), using wrappers where necessary
>
> What has not been mentioned for completeness:
> 5.) Keep SWIG, use a constrained export set possibly using wrappers to
> adhere the specified API
>
> Anything missing from the list?
>
> Of course every alternative takes a specified API for granted, where we
> haven none, yet. I cannot compare the techniques at the current point of
> time, since I simply have no experience creating a C-API for C++ code.
> Where some stuff seems obvious as how to get right, I need to think about
> technicalities of how to implement move-semantics, smart-pointers, etc.. I
> have some experience using techniques like pybind11 or luabind, where one
> doesn't have these problems, because C++ is not stripped away at the
> binding level. So I'll have to delve into it and play around creating a
> super-limited sample binding in every alternative just to come to a
> personal conclusion.
> While the C-API seems like being the best solution technically, we'd need
> to develop the C-part and also convenience wrappers on the Python side just
> to be on par with the current state, right? Will there be enough developers
> with enough time to pull that off, I fear I doubt that, but as I said, I'll
> need to play around with this. It is however possible to create a binding
> vs. "the specified API" without taking this route, and it is also possible
> to switch the implementation technique later without changing the
> experienced binding semantics.
> Just how large of a deprecation-timespan would you think is necessary to
> make such changes? I think there are "some" devs who are eager to go in and
> refactor quite some parts, but we simply cannot do this right now due to
> this problem. So we're pretty much in a state where we can only add stuff
> on top, right, where adding already means fixing it for the future, too?
>
> Cheers!
> Michael
>
> ___
> 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

Re: [Kicad-developers] SWIG binding

[Michael Steinberg]

Hello all!

Am 17.09.2016 um 23:39 schrieb Cirilo Bernardo:



On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski 
> 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 whatever scripting
language API on top of that; this way there will be a much more uniform
scheme for everyone. I was thinking about this while working on the STEP
exporter but the more I looked at things, the bigger the job became.
Eventually I thought it would take me a year or even more hacking at it
part-time so I put it on the deferred list of things to do. Until we 
have such

an API, I think things will be a bit of a mess. On the other hand some
people want a scripting API now and can't wait for some part-time coder
to come up with something in a year or two.



So I conclude that we pretty much all agree it's a bad idea to export a 
rather unconstrained set of internals to python or any scripting. I 
think we also agree that we can't just drop the current state 
immediately. Beside these points I see a set of diverging technical 
strategies to implement it the right way (tm):


1.) Keep SWIG, wrap the output on the python side to a specified API
2.) Drop SWIG and interface with python.h ourselves without convenience 
libraries

3.) Drop SWIG, implement a C-API, write bindings in any language vs. C-API
4.) Drop SWIG, use compiler-based c++ bindings adhering the specified 
API (pybind11-like), using wrappers where necessary


What has not been mentioned for completeness:
5.) Keep SWIG, use a constrained export set possibly using wrappers to 
adhere the specified API


Anything missing from the list?

Of course every alternative takes a specified API for granted, where we 
haven none, yet. I cannot compare the techniques at the current point of 
time, since I simply have no experience creating a C-API for C++ code. 
Where some stuff seems obvious as how to get right, I need to think 
about technicalities of how to implement move-semantics, smart-pointers, 
etc.. I have some experience using techniques like pybind11 or luabind, 
where one doesn't have these problems, because C++ is not stripped away 
at the binding level. So I'll have to delve into it and play around 
creating a super-limited sample binding in every alternative just to 
come to a personal conclusion.
While the C-API seems like being the best solution technically, we'd 
need to develop the C-part and also convenience wrappers on the Python 
side just to be on par with the current state, right? Will there be 
enough developers with enough time to pull that off, I fear I doubt 
that, but as I said, I'll need to play around with this. It is however 
possible to create a binding vs. "the specified API" without taking this 
route, and it is also possible to switch the implementation technique 
later without changing the experienced binding semantics.
Just how large of a deprecation-timespan would you think is necessary to 
make such changes? I think there are "some" devs who are eager to go in 
and refactor quite some parts, but we simply cannot do this right now 
due to this problem. So we're pretty much in a state where we can only 
add stuff on top, right, where adding already means fixing it for the 
future, too?


Cheers!
Michael
___
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

Re: [Kicad-developers] SWIG binding

[Cirilo Bernardo]

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
> > 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 code, considering
> > there are alternative generators, and generatorless libraries like
> > pybind11. Of those alternatives I would *personally* prefer the latter,
> > as it is no black box and the binding generation is part of the normal
> > c++ source code.
> > There's been a discussion on the irc channel regardings this and also
> > the dependency on having wx exported as well. So I thought the logical
> > consequence would be to broaden the audience and move the discussion
> here.
>
> Hi Michael,
>
> It may sound controversial, but I'd say using SWIG is a bad idea: we
> expose for the people the internal APIs of pcbnew that we intend to
> refactor in the near future. Any change to the BOARD storage model means
> a change to the scripting API. IMHO we should have a more pythonish API
> that hides all C++ stuff from the python side completely and is
> independent from the changes in pcbnew's core.
>
> Cheers,
> Tom
>
>
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 whatever scripting
language API on top of that; this way there will be a much more uniform
scheme for everyone. I was thinking about this while working on the STEP
exporter but the more I looked at things, the bigger the job became.
Eventually I thought it would take me a year or even more hacking at it
part-time so I put it on the deferred list of things to do. Until we have
such
an API, I think things will be a bit of a mess. On the other hand some
people want a scripting API now and can't wait for some part-time coder
to come up with something in a year or two.

- Cirilo



>
> >
> > Cheers!
> > Michael
> >
> >
> > ___
> > 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
>
___
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

Re: [Kicad-developers] SWIG binding

[Miguel Angel Ajo Pelayo]

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 me add some notes to the discussion as author of the bindings (the
guilty one ;-) ):

  At the time when I started working on the bindings, I was only able to
recognise two options that were suitable for us, we either a) built our own
bindings manually with C, or b) we had swig, which at that time, was the
same solution that wxWidgets was using. I remember I examined other
automated binding solutions, but having wxWidgets compatibility was a
strong point, it all got discussed in the community and we weighted our
development capacity.

  Also, we had the future eventual change to python3, that may be easier
with an automated tool (I agree, I'm very optimistic sometimes)

  So we picked that path, and I made an initial version, eventually we
got wxpython support contributed, the wx console for python, etc...
around that time my contributions decreased / disappeared because I
had two wonderful daughters (one after another) and I'm still trying to
recover from that.

Around that time, we also started to recognise two things:

   a) The bindings, even if limited in scope to some objects, were troublesome
because any refactor on the objects could break external users of the API.
IMO, that's something the users must understand and accept that eventual
breaking changes will happen to the API.

   b) The bindings didn't allow users to access objects in a python-like and
easy way, all was cluttered with the creation of objects which had to be
passed around.

   c) The documentation was for the C++ side, not for Python.


So, we weighted in again the possibility of writing native bindings, but we
realised that it was easier to layer on top of swig, and do all the
heavy-lifting
of providing a consistent API in python [1].


So we had:

kicad objects <--- swig API bindings <--- kicad-python < user

If any breaking change happens in kicad objects, the kicad-python wrapper
is updated and the user doesn't need to change anything.

While the old users still had access to the swig bindings (knowing that
those could eventually break), they had the chance to pick up something
better.

Some examples here:

Docs: 
http://ci.kicad-pcb.org/view/KiCad's%20pythonic%20python%20API/job/kicad-python/ws/doc/build/html/index.html

https://github.com/KiCad/kicad-python/blob/master/kicad/pcbnew/board.py

https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py


Now, I'm not an active developer (for now) but, I know that you'll take wise
decisions, of course feel free to reuse that -and ask me anything you need-,
keep building on swig, or not and take any other direction. I will be happy
to see anyone stepping in to handle all this work and provide a consistent,
easy to use API for KiCad.


Best regards,
Miguel Ángel.









On Fri, Sep 16, 2016 at 8:30 PM, Wayne Stambaugh  wrote:
> 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 had 5+ years to add support, they didn't. So I wouldn't count on it.
>>> As some of you may or may not know, the new wxpython project phoenix is
>>> using sip instead of swig so that in and of itself may put us in a
>>> position where we have to change to sip.  I would rather wait and see
>>> what shakes out with the new wxpython implementation rather than head
>>> down a path that only has to be changed yet again.
>> And another break, will we support SWIG, SIP and an interop layer?
 With this message I want to ask what is the common view whether it is
 okay to have SWIG thumbscrew the project's source code, considering
 there are alternative generators, and generatorless libraries like
 pybind11. Of those alternatives I would *personally* prefer the latter,
 as it is no black box and the binding generation is part of the normal
 c++ source code.
>>> Honestly, changing scripting language generators does not thrill me at
>>> this point in the project.  It would most likely break all of the python
>>> scripting work done thus far which would create a lot backlash.
>> It will only get worse as time is passing by building upon the current
>> state.
>>
>> I think we need
>> 1) a specified python API
>> 2) adapters that match the specified API to the source code
>> 3) Helpers to generate the necessary binding from the API adapters. This
>> can be done with the aid of libraries or manually.
>>
>> It seems none of that is currently available, the current unspecified
>> API holds the source 

Re: [Kicad-developers] SWIG binding

[Wayne Stambaugh]

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 had 5+ years to add support, they didn't. So I wouldn't count on it.
>> As some of you may or may not know, the new wxpython project phoenix is
>> using sip instead of swig so that in and of itself may put us in a
>> position where we have to change to sip.  I would rather wait and see
>> what shakes out with the new wxpython implementation rather than head
>> down a path that only has to be changed yet again.
> And another break, will we support SWIG, SIP and an interop layer?
>>> With this message I want to ask what is the common view whether it is
>>> okay to have SWIG thumbscrew the project's source code, considering
>>> there are alternative generators, and generatorless libraries like
>>> pybind11. Of those alternatives I would *personally* prefer the latter,
>>> as it is no black box and the binding generation is part of the normal
>>> c++ source code.
>> Honestly, changing scripting language generators does not thrill me at
>> this point in the project.  It would most likely break all of the python
>> scripting work done thus far which would create a lot backlash.
> It will only get worse as time is passing by building upon the current
> state.
> 
> I think we need
> 1) a specified python API
> 2) adapters that match the specified API to the source code
> 3) Helpers to generate the necessary binding from the API adapters. This
> can be done with the aid of libraries or manually.
> 
> It seems none of that is currently available, the current unspecified
> API holds the source code tight, with a generator that hinders
> refactoring to modern c++ style. So we only lose on both sides.
> 
> Michael
> 

The only way I could get behind this if it's implemented separately from
and in addition to the current swig wrappers.  This would preserve the
investment folks have in their existing python scripts and they could
decide which bindings they prefer.  Forcing this kind of change on users
generally doesn't end well.

___
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

Re: [Kicad-developers] SWIG binding

[Chris Pavlina]

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-with-swig
> They had 5+ years to add support, they didn't. So I wouldn't count on it.
> >As some of you may or may not know, the new wxpython project phoenix is
> >using sip instead of swig so that in and of itself may put us in a
> >position where we have to change to sip.  I would rather wait and see
> >what shakes out with the new wxpython implementation rather than head
> >down a path that only has to be changed yet again.
> And another break, will we support SWIG, SIP and an interop layer?
> >>With this message I want to ask what is the common view whether it is
> >>okay to have SWIG thumbscrew the project's source code, considering
> >>there are alternative generators, and generatorless libraries like
> >>pybind11. Of those alternatives I would *personally* prefer the latter,
> >>as it is no black box and the binding generation is part of the normal
> >>c++ source code.
> >Honestly, changing scripting language generators does not thrill me at
> >this point in the project.  It would most likely break all of the python
> >scripting work done thus far which would create a lot backlash.
> It will only get worse as time is passing by building upon the current
> state.
> 
> I think we need
> 1) a specified python API
> 2) adapters that match the specified API to the source code
> 3) Helpers to generate the necessary binding from the API adapters. This can
> be done with the aid of libraries or manually.
> 
> It seems none of that is currently available, the current unspecified API
> holds the source code tight, with a generator that hinders refactoring to
> modern c++ style. So we only lose on both sides.

Agreed. We _already_ risk breaking a lot of scripts and generating
backlash any time we change something, because our script "API" is just
bindings on the internals.

Bear in mind, if we replace it with something else, we can add the new
API without removing the old one immediately, and migrate gradually.

> 
> Michael
> 
> 
> 
> ___
> 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

Re: [Kicad-developers] SWIG binding

[Michael Steinberg]

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 it.

As some of you may or may not know, the new wxpython project phoenix is
using sip instead of swig so that in and of itself may put us in a
position where we have to change to sip.  I would rather wait and see
what shakes out with the new wxpython implementation rather than head
down a path that only has to be changed yet again.

And another break, will we support SWIG, SIP and an interop layer?

With this message I want to ask what is the common view whether it is
okay to have SWIG thumbscrew the project's source code, considering
there are alternative generators, and generatorless libraries like
pybind11. Of those alternatives I would *personally* prefer the latter,
as it is no black box and the binding generation is part of the normal
c++ source code.

Honestly, changing scripting language generators does not thrill me at
this point in the project.  It would most likely break all of the python
scripting work done thus far which would create a lot backlash.
It will only get worse as time is passing by building upon the current 
state.


I think we need
1) a specified python API
2) adapters that match the specified API to the source code
3) Helpers to generate the necessary binding from the API adapters. This 
can be done with the aid of libraries or manually.


It seems none of that is currently available, the current unspecified 
API holds the source code tight, with a generator that hinders 
refactoring to modern c++ style. So we only lose on both sides.


Michael



___
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

Re: [Kicad-developers] SWIG binding

[Wayne Stambaugh]

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.
You can always write your own swig wrapper something like this:
http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig

As some of you may or may not know, the new wxpython project phoenix is
using sip instead of swig so that in and of itself may put us in a
position where we have to change to sip.  I would rather wait and see
what shakes out with the new wxpython implementation rather than head
down a path that only has to be changed yet again.

> 
> With this message I want to ask what is the common view whether it is
> okay to have SWIG thumbscrew the project's source code, considering
> there are alternative generators, and generatorless libraries like
> pybind11. Of those alternatives I would *personally* prefer the latter,
> as it is no black box and the binding generation is part of the normal
> c++ source code.

Honestly, changing scripting language generators does not thrill me at
this point in the project.  It would most likely break all of the python
scripting work done thus far which would create a lot backlash.

> There's been a discussion on the irc channel regardings this and also
> the dependency on having wx exported as well. So I thought the logical
> consequence would be to broaden the audience and move the discussion here.
> 
> Cheers!
> Michael
> 
> 
> ___
> 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

Re: [Kicad-developers] SWIG binding

[Nick Østergaard]

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 message I want to ask what is the common view whether it is
>> okay to have SWIG thumbscrew the project's source code, considering
>> there are alternative generators, and generatorless libraries like
>> pybind11. Of those alternatives I would *personally* prefer the latter,
>> as it is no black box and the binding generation is part of the normal
>> c++ source code.
>> There's been a discussion on the irc channel regardings this and also
>> the dependency on having wx exported as well. So I thought the logical
>> consequence would be to broaden the audience and move the discussion here.
>
> Hi Michael,
>
> It may sound controversial, but I'd say using SWIG is a bad idea: we
> expose for the people the internal APIs of pcbnew that we intend to
> refactor in the near future. Any change to the BOARD storage model means
> a change to the scripting API. IMHO we should have a more pythonish API
> that hides all C++ stuff from the python side completely and is
> independent from the changes in pcbnew's core.
>

There have been some work towards an other API like,
https://github.com/KiCad/kicad-python

But it seems that it needs participants to define the API. Above seems
to be a wrapper on the kicad API to write python scripts against. The
idea seems that it should be easier to update the wrapper to match
kicad, rather than rewriting every script that depends on kicad.

I don't say that either tool is the correct solution or not, I just
suggest that someone is needed to actually define the API also.

> Cheers,
> Tom
>
>
>>
>> Cheers!
>> Michael
>>
>>
>> ___
>> 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

___
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