As usual, I forgot to hit Reply-all :-) On 15/01/2013, at 00:04, Miguel Angel Ajo Pelayo <[email protected]> wrote:
> > > On 14/01/2013, at 22:59, Wayne Stambaugh <[email protected]> wrote: > >> On 1/14/2013 3:12 AM, Miguel Angel Ajo Pelayo wrote: >>> It's two different problems, >>> >>> 1) the fixswigimports.py fix the way swig (inside pcbnew.py) loads >>> pcbnew.so/pyd <http://pcbnew.so/pyd> internally, the swig generated .py >>> has problems to support "internal" (inside your own program) object >>> bindings. It's documented, but not widespread used. We fix it to make it >>> work in both cases, when doing "import pcbnew" from inside an >>> scripting-pcbnew and when doing import pcbnew from >>> standalone/commandline python. >>> >>> 2) At the time we started with scripting, I raised some discussion about >>> this topic, and thought that python2.x has more widespread library >>> support (compared to python 3 advantages). >> >> I'll take a look at it and see if I can make the KiCad scripting work on >> Python 2 & 3. I may have to write some creative CMake code to get it to >> work but it should be possible. > > It might require also some work in initialization of the python engine (may > be more), > because they are initialized in a different way. Python 2 initializes as an > static interpreter > (only one for your process), and Python 3 initializes as an object, so you > can have > many in interpreters in your project, also calls to python api could differ, > but not sure. > >> >> I have a quick question regarding the KICAD_SCRIPTIN_WXPYTHON option. >> When this option is enabled, is wxPython.h included in any of the SWIG >> generated code. I did quick grep of the scripting folders and didn't >> see wxPython.h included anywhere so the only other place I can think >> that it would end up is in the SWIG generated code. If it's not, that >> will make life a whole lot easier. If it is, building wxPython on >> Windows to install the development files is proving to be painful. >> > > I don't understand exactly what you mean. > > The include to wxpython It's outside the pcbnew directory in > <kicadroot>/scripting/python_scripting.h, > the wxpython thing is used to be able to create widgets/dialogs from python > that can be > referenced/used in C++, or the other way around. Also for the nice pycrust > shell. > > >>> >>> >>> It's also true, that, if we made the move now, and having phoenix in >>> place, it could be less disruptive if we find ourselves forced to move >>> into python3 at some moment in time. >>> >>> Anyway, that most probably would force us to move our wrappers into SIP >>> and get the both "wrappings" (internal wrapping, external wrapping). >>> >>> I'm not really opposed to do it, or do some testing, but I'm really >>> concerned about: >>> >>> 1) SIP support (no so widespread support at swig, that will let us work >>> with other languages too) >>> 2) SIP internal/external wrapping >>> 3) Phoenix real support. (is it only a test branch or will it be >>> supported in time?, it could also become the main branch at some time..) >> >> Even if Phoenix becomes the default way to build wxPython, I see no >> reason to switch from SWIG to SIP. SWIG gives use the opportunity to >> support other scripting languages. SIP appears to be a Python only code >> generator. > > I think you're right > >> >>> 4) My time has become a little scarce: I have challenging big projects >>> for this year, and also a new (first) daughter, which I love, but it's a >>> time black hole 8] >> >> There is no better way to spend your time than with your family. > > Everything must be kept in a balance :-) > >> >>> >>> >>> I think I dropped all my thoughts about the topic. :-) >>> >>> >>> >>> >>> 2013/1/14 Dick Hollenbeck <[email protected] <mailto:[email protected]>> >>> >>> On 01/13/2013 06:57 PM, Wayne Stambaugh wrote: >>>> On 1/13/2013 4:58 PM, Miguel Angel Ajo Pelayo wrote: >>>>>> The CMake module you were looking for is FindPythonInterp which >>> finds the Python interpreter and sets the PYTHON_EXECUTABLE >>> variable. You can define a specific Python version by setting >>> PythonInterp_FIND_VERSION. I still have some validation to do on >>> Linux when both Python3 and Python2 are installed just to make sure >>> everything works as expected. >>>>>> >>>>>> Also found that using "#!/usr/bin/env python2" in >>> fixswigimports.py breaks the windows build so I am currently working >>> on a solution to this problem. I changed python2 to python and it >>> fixes the build on windows but may cause problems for Linux. I'm >>> thinking since the python interpreter is being called to run this >>> script that the "#!/usr/bin/env python2" line is even necessary. >>>>>> Is there any reason to run this script outside of the KiCad >>> scripting build? >>>>> It's only needed when we make a scripting build and the pcbnew.py >>> is regenerated. It will fix the way it looks for _pcbnew.so / .pyd >>> so when running from a pcbnew with embedded python, it won't >>>>> reload the DLL and use the internal swigs to pcbnew objects. >>>>> >>>>>> If not, then I should be able to safely remove this from >>> fixswigimports.py. If it cannot be removed, I may have to use CMake >>> to generate this file on the fly to add the correct Python >>> environment string to the beginning of the file. >>>>> May be we can just call $PYTHON_EXECUTABLE fixswigimports.py, >>> most probably this little script will run within python3, but not sure. >>>> The last I recall is that code generated by SWIG is not yet compatible >>>> with Python 3. That's why Python 2 is still required to build >>> wxPython. >>>> It's been a while since I've used SWIG so maybe that has changed. >>>> Until I see a wxPython release built against Python 3, I'll stick with >>>> Python 2. >>> >>> Swig is there now: >>> >>> http://www.swig.org/Doc1.3/Python.html#Python_python3support >>> >>> wxpython for python 3.x is known as Phoenix, and it is also probably >>> build-able at this time. >>> >>> >>> But they did not do the interface to C++ in Phoenix using SWIG. >>> >>> >>> >>> https://groups.google.com/forum/?fromgroups=#!topic/wxpython-users/p69PjUnMN-c >>> >>> Used SIP instead: >>> >>> http://riverbankcomputing.co.uk/software/sip/intro >>> >>> In any case it looks like python 3.x is an option, as it should be, >>> since its about 5 >>> years old or more. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : [email protected] >>> <mailto:[email protected]> >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >>> >>> -- >>> >>> Miguel Angel Ajo Pelayo >>> http://www.nbee.es >>> +34 636 52 25 69 >>> skype: ajoajoajo >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
