Phoenix newbie problem

wxPython Dev
1

You can use the Dependency Walker tool to look at the wxPython _core.pyd file and see what DLL it may not be finding.

···

On 1/8/13 1:41 PM, jimmy@cs.cofc.edu wrote:

I downloaded the daily build of Phoenix last weekend and dropped the wx
folder into C:\Python33\lib\site-packages. When I say "import wx" I get
the following:

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32
bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "C:\Python33\lib\site-packages\wx\__init__.py", line 17, in <module>
     from wx.core import *
   File "C:\Python33\lib\site-packages\wx\core.py", line 6, in <module>
     from ._core import *
ImportError: DLL load failed: The specified module could not be found.

The wx folder has a lot of .dll's, and the README file says that I don't
need to move them anywhere on Windows.
Can somebody tell me what I did wrong? This is on Windows XP sp3.

Thanks, I hope I didn't pick the wrong place to ask a question like this.

--
Robin Dunn
Software Craftsman

2

There are several: MSVCP90.dll and MSVCR90.dll seem to be part of Microsoft C++
IESHIMS.dll and WER.dll are present on a Windows 7 machine that I have access to but not on my XP machine.
PYTHON32.dll ---- my machine has PYTHON33.dll since I have Python 3.3 installed

The obvious solution is to use a Windows 7 machine that has Microsoft C++ installed.

Is the dependence on a particular release of Python (3.2 in this case) necessary, or is it a temporary thing while you’re still working on this?

thanks

···

On Wednesday, January 9, 2013 11:02:49 AM UTC-5, Robin Dunn wrote:

On 1/8/13 1:41 PM, ji…@cs.cofc.edu wrote:

I downloaded the daily build of Phoenix last weekend and dropped the wx

folder into C:\Python33\lib\site-packages. When I say “import wx” I get

the following:

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32

bit (In

tel)] on win32

Type “help”, “copyright”, “credits” or “license” for more information.

import wx

Traceback (most recent call last):

File “”, line 1, in

File “C:\Python33\lib\site-packages\wx_init_.py”, line 17, in 

 from wx.core import *

File “C:\Python33\lib\site-packages\wx\core.py”, line 6, in 

 from ._core import *

ImportError: DLL load failed: The specified module could not be found.

The wx folder has a lot of .dll’s, and the README file says that I don’t

need to move them anywhere on Windows.

Can somebody tell me what I did wrong? This is on Windows XP sp3.

Thanks, I hope I didn’t pick the wrong place to ask a question like this.

You can use the Dependency Walker tool to look at the wxPython _core.pyd
file and see what DLL it may not be finding.

–
Robin Dunn

Software Craftsman

http://wxPython.org

3

There are several: MSVCP90.dll and MSVCR90.dll seem to be part of
Microsoft C++

Those would likely be included and installed correctly once we have a normal installer. I'll see if it will work to just add the CRT assembly to the zip file in the meantime.

IESHIMS.dll and WER.dll are present on a Windows 7 machine that I have
access to but not on my XP machine.

These are probably dynamically imported by other MS DLLs and probably won't be needed if they are not already on the system IIRC.

PYTHON32.dll ---- my machine has PYTHON33.dll since I have Python 3.3
installed

The obvious solution is to use a Windows 7 machine that has Microsoft
C++ installed.

Is the dependence on a particular release of Python (3.2 in this case)
necessary, or is it a temporary thing while you're still working on this?

Yes, that dependency is a necessary one. The Major.Minor releases of Python are not binary compatible with each other, so there could be things that the extension module is looking for which is not present or has changed somehow in a newer Python DLL. I plan on adding some more Python 3.3 builders when I get a large enough block of free time. Also for Windows x64.

···

On 1/16/13 5:08 PM, jimmy@cs.cofc.edu wrote:

--
Robin Dunn
Software Craftsman

4

There is now, as of Python 3.2, a python stable API. Meaning that
there would be one build of phoenix for all 3.x versions (excluding
3.0, and 3.1).

I don't know whether phoenix as it is now is compatible with the
restricted api set or not, though I'm sure with a bit of work it could
be made so.

I wouldn't mind helping with porting to the stable api as it is
something I would be interested in at some point.

Sam

···

On 17 January 2013 02:47, Robin Dunn <robin@alldunn.com> wrote:

Yes, that dependency is a necessary one. The Major.Minor releases of Python
are not binary compatible with each other, so there could be things that the
extension module is looking for which is not present or has changed somehow
in a newer Python DLL. I plan on adding some more Python 3.3 builders when
I get a large enough block of free time. Also for Windows x64.

5

(Note: PEP 384 is about a stable ABI, B for Binary, machine-code level.

Python API is already a stable one… at the C level)

Is there a single module in the world that uses the stable ABI?

Some time ago I tried with an “easy” module:

http://mail.python.org/pipermail/python-dev/2011-October/113829.html

lzma is simple module: pass strings, work on memory, and return strings.

But the result was not great…

It’s possible that the situation improved since then,

but phoenix is very far from this stable ABI.

As an example, did you notice in siplib.c, how sipWrapperType_alloc

overrides the tp_alloc of metaclasses?

···

2013/1/17 Sam Partington sam.partington@gmail.com

On 17 January 2013 02:47, Robin Dunn robin@alldunn.com wrote:

Yes, that dependency is a necessary one. The Major.Minor releases of Python

are not binary compatible with each other, so there could be things that the

extension module is looking for which is not present or has changed somehow

in a newer Python DLL. I plan on adding some more Python 3.3 builders when

I get a large enough block of free time. Also for Windows x64.

There is now, as of Python 3.2, a python stable API. Meaning that

there would be one build of phoenix for all 3.x versions (excluding

3.0, and 3.1).

I don’t know whether phoenix as it is now is compatible with the

restricted api set or not, though I’m sure with a bit of work it could

be made so.

http://www.python.org/dev/peps/pep-0384/

I wouldn’t mind helping with porting to the stable api as it is

something I would be interested in at some point.

–
Amaury Forgeot d’Arc

6

(Note: PEP 384 is about a stable ABI, B for Binary, machine-code level.
Python API is already a stable one... at the C level)

Yes sorry, I wasn't clear. It is an API which defines a stable ABI.

Is there a single module in the world that uses the stable ABI?
Some time ago I tried with an "easy" module:
[Python-Dev] Using PEP384 Stable ABI for the lzma extension module
lzma is simple module: pass strings, work on memory, and return strings.
But the result was not great...

Yes I read that thread.

I have done a proof of concept on one of our internal extensions, it
went fairly smoothly. It was probably easier for two reasons :

1) because of a previous effort of mine to make our code lookup Py_
symbol addresses using GetProcAddres/dlsym. As a result I had already
removed nearly all uses of the macro accessors.

2) Our extension is designed to be exposed to several different
scripting languages, through COM on windows, tcl, and swig for most
others, and as such all of our Py access code is isolated in one
fairly straightforward C file, and apart from a few callbacks all of
our interaction is value type based.

Phoenix would be a very different proposition of course.

It's possible that the situation improved since then,
but phoenix is *very* *far* from this stable ABI.
As an example, did you notice in siplib.c, how sipWrapperType_alloc
overrides the tp_alloc of metaclasses?

I haven't looked at any of the sip wrapping stuff in phoenix as yet,
(we are still on classic wxPython).

However in that particular case you can set tp_alloc using the
PyType_Slot mechanism.

Sam

···

On 17 January 2013 11:10, Amaury Forgeot d'Arc <amauryfa@gmail.com> wrote:

7

Yes, but the base class’ slot (PyType_Type.tp_alloc) is not accessible.

And the definition of _sipWrapperType looks difficult to fix: PyHeapTypeObject

is not exposed either (or only as an opaque structure).

It seems impossible to inherit a core type with the limited API.

···

2013/1/17 Sam Partington sam.partington@gmail.com

On 17 January 2013 11:10, Amaury Forgeot d’Arc amauryfa@gmail.com wrote:

(Note: PEP 384 is about a stable ABI, B for Binary, machine-code level.

Python API is already a stable one… at the C level)

Yes sorry, I wasn’t clear. It is an API which defines a stable ABI.

Is there a single module in the world that uses the stable ABI?

Some time ago I tried with an “easy” module:

http://mail.python.org/pipermail/python-dev/2011-October/113829.html

lzma is simple module: pass strings, work on memory, and return strings.

But the result was not great…

Yes I read that thread.

I have done a proof of concept on one of our internal extensions, it

went fairly smoothly. It was probably easier for two reasons :

  1. because of a previous effort of mine to make our code lookup Py_

symbol addresses using GetProcAddres/dlsym. As a result I had already

removed nearly all uses of the macro accessors.

  1. Our extension is designed to be exposed to several different

scripting languages, through COM on windows, tcl, and swig for most

others, and as such all of our Py access code is isolated in one

fairly straightforward C file, and apart from a few callbacks all of

our interaction is value type based.

Phoenix would be a very different proposition of course.

It’s possible that the situation improved since then,

but phoenix is very far from this stable ABI.

As an example, did you notice in siplib.c, how sipWrapperType_alloc

overrides the tp_alloc of metaclasses?

I haven’t looked at any of the sip wrapping stuff in phoenix as yet,

(we are still on classic wxPython).

However in that particular case you can set tp_alloc using the

PyType_Slot mechanism.

–
Amaury Forgeot d’Arc

8

I dropped wx into site-packages on a couple of our lab machines that have Python3.2 and Windows 7, and “import wx” went just fine. I’m working on getting a Windows 7 machine for my office. That should fix my problem.

thanks

···

On Wednesday, January 16, 2013 9:47:28 PM UTC-5, Robin Dunn wrote:

On 1/16/13 5:08 PM, ji…@cs.cofc.edu wrote:

There are several: MSVCP90.dll and MSVCR90.dll seem to be part of

Microsoft C++

Those would likely be included and installed correctly once we have a
normal installer. I’ll see if it will work to just add the CRT assembly
to the zip file in the meantime.

IESHIMS.dll and WER.dll are present on a Windows 7 machine that I have

access to but not on my XP machine.

These are probably dynamically imported by other MS DLLs and probably
won’t be needed if they are not already on the system IIRC.

PYTHON32.dll ---- my machine has PYTHON33.dll since I have Python 3.3

installed

The obvious solution is to use a Windows 7 machine that has Microsoft

C++ installed.

Is the dependence on a particular release of Python (3.2 in this case)

necessary, or is it a temporary thing while you’re still working on this?

Yes, that dependency is a necessary one. The Major.Minor releases of
Python are not binary compatible with each other, so there could be
things that the extension module is looking for which is not present or
has changed somehow in a newer Python DLL. I plan on adding some more
Python 3.3 builders when I get a large enough block of free time. Also
for Windows x64.

–
Robin Dunn

Software Craftsman

http://wxPython.org