kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

As usual, I forgot to hit Reply-all :-)

On 15/01/2013, at 00:04, Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx> wrote:

> 
> 
> On 14/01/2013, at 22:59, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> 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 <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
>>> 
>>>   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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>   <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>   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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>> 
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>