Re: [Kicad-developers] SWIG binding
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: 1) Better quality 2) Avoiding breaking changes to API users 3) Tests can serve as a documentation point and contract on what we expose, and how we do it. If you need to change a test in a backwards incompatible way: it's time to write a notice (in other projects where I work we document every breaking change to APIs, and try to provide a deprecation warning and support for 1 stable release (where that's possible). May be it's time to start increasing the testing surface. [1] https://git.launchpad.net/kicad/tree/qa/testcases [2] http://ci.kicad-pcb.org/view/KiCad%20builds/job/kicad-qa/2001/console (look for test.py) On Mon, Sep 19, 2016 at 4:20 PM, Wayne Stambaugh wrote: > 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 ___ 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
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
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
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&S 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
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&S 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
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
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 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
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
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 code tight, with a gen
Re: [Kicad-developers] SWIG binding
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
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
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
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
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
Re: [Kicad-developers] SWIG binding
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 > > 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