I did switch the application from wx.lib.iewin to wx.lib.iewin_old and the problem disappeared. I am going to do a little more research, but maybe someone who understands the differences between old and new iewin module could shed some light on this. I am not a Windows programming expert, but think I understand a little about the change when I read the code.
For us, the old iewin code is giving us the functionality we need (at least in testing), so that will be the solution for now unless someone can tell me why the old version might not be appropriate.
I will definitely be getting back to this because we intend to use the .pdf module also in a later version and looking at the code, I think we have the same problem. I suspect it has something to do with the way the comtypes module behaves.
I am having a problem building an executable with py2exe that imports wx.lib.iewin.
I’ve been doing exactly that with a large app, with no problems. However, when I try your little test script, I find that py2exe uses about 50% CPU (maybe because I have dual cores), and runs a long, long time…but it eventually terminates and appears to work.
It may well get caught in a loop, but terminate eventually.
Indeed, that’s what I found with my larger app – it took very long for py2exe to run – I thought it was 'cause the app is big and complex, with lots of modules, and my laptop is painfully slow, but it looks like it may be an issue with that module.
I did switch the application from wx.lib.iewin to wx.lib.iewin_old and the problem disappeared. I am going to do a little more research, but maybe someone who understands the differences between old and new iewin module could shed some light on this. I am not a Windows programming expert, but think I understand a little about the change when I read the code.
For us, the old iewin code is giving us the functionality we need (at least in testing), so that will be the solution for now unless someone can tell me why the old version might not be appropriate.
I will definitely be getting back to this because we intend to use the .pdf module also in a later version and looking at the code, I think we have the same problem. I suspect it has something to do with the way the comtypes module behaves.
One of the modules generated by comtypes is very huge. Py2exe may be choking on that.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
One of the modules generated by comtypes is very huge. Py2exe may be choking on that.
could be. Does anyone know if py2exe has anything similar for py2app's "recipes"? It may be possible to have it not try to parse out comtypes stuff, but rather just be told what it include if comtypes is there.
Just a thought,
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
One of the modules generated by comtypes is very huge. Py2exe may be choking on that.
could be. Does anyone know if py2exe has anything similar for py2app's "recipes"? It may be possible to have it not try to parse out comtypes stuff, but rather just be told what it include if comtypes is there.
There was talk about having 'recipes' but I don't think they made it yet.
I just did a little test script which does:
import wx
import wx.lib.iewin
print 'we did the import'
and then created a setup.py using Gui2Exe. The first compile took 19 sec on a Windows Vista machine (dual core 1.86Ghz and 4GB memory), the second compile took 10 seconds (regards if I selected clean dist/build folder or not under options).
I use wx.lib.iewin in my shareware and I do not see any long delay there either - at least nothing which I noticed when I recently added this to my shareware).
So, maybe there is some other stuff which causes a long delay - maybe a py2exe version issue (see below I use a relatively old one as I have had no time/need to upgrade).
Attached is the setup.py generated by Gui2Exe.
Werner
P.S. some version info:
# Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
# wxPython 2.8.9.1, Boa Constructor 0.6.1
trying to run a one liner that just imports that file through py2exe creates the problem. I suspect that letting it run long enough would eventually go to conclusion. Unfortunately we do our build on a relatively low power machine and probably can’t change that any time soon (startups don’t have much money).
Does anyone know if there is a technique to tell py2exe to “put this in your output, but don’t bother to analyze it”? If so, I can manually include this file and any relevant dependencies.
One of the modules generated by comtypes is very huge. Py2exe may be choking on that.
could be. Does anyone know if py2exe has anything similar for py2app’s “recipes”? It may be possible to have it not try to parse out comtypes stuff, but rather just be told what it include if comtypes is there.
There was talk about having ‘recipes’ but I don’t think they made it yet.
I just did a little test script which does:
import wx
import wx.lib.iewin
print ‘we did the import’
and then created a setup.py using Gui2Exe. The first compile took 19 sec on a Windows Vista machine (dual core 1.86Ghz and 4GB memory), the second compile took 10 seconds (regards if I selected clean dist/build folder or not under options).
I use wx.lib.iewin in my shareware and I do not see any long delay there either - at least nothing which I noticed when I recently added this to my shareware).
So, maybe there is some other stuff which causes a long delay - maybe a py2exe version issue (see below I use a relatively old one as I have had no time/need to upgrade).
Attached is the setup.py generated by Gui2Exe.
Werner
P.S. some version info:
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)]
Robin got me on the right track here.
comtypes\gen\_3050F1C5_98B5_11CF_BB82_00AA00BDCE0B_0_4_0.py
is a 60,000+ file. the .pyc is over 1.4Mb
trying to run a one liner that just imports that file through py2exe creates the problem. I suspect that letting it run long enough would eventually go to conclusion. Unfortunately we do our build on a relatively low power machine and probably can't change that any time soon (startups don't have much money).
Does anyone know if there is a technique to tell py2exe to "put this in your output, but don't bother to analyze it"? If so, I can manually include this file and any relevant dependencies.
--
Mike Conley
You probably need to run this problem by the guys on the py2exe list. They can tell you if there's a switch to do something like that.
- Mike
···
On Sat, Apr 11, 2009 at 6:04 AM, Werner F. Bruhin > <werner.bruhin@free.fr <mailto:werner.bruhin@free.fr>> wrote:
Christopher Barker wrote:
Robin Dunn wrote:
One of the modules generated by comtypes is very huge.
Py2exe may be choking on that.
could be. Does anyone know if py2exe has anything similar for
py2app's "recipes"? It may be possible to have it not try to
parse out comtypes stuff, but rather just be told what it
include if comtypes is there.
There was talk about having 'recipes' but I don't think they made
it yet.
I just did a little test script which does:
import wx
import wx.lib.iewin
print 'we did the import'
and then created a setup.py using Gui2Exe. The first compile took
19 sec on a Windows Vista machine (dual core 1.86Ghz and 4GB
memory), the second compile took 10 seconds (regards if I selected
clean dist/build folder or not under options).
I use wx.lib.iewin in my shareware and I do not see any long delay
there either - at least nothing which I noticed when I recently
added this to my shareware).
So, maybe there is some other stuff which causes a long delay -
maybe a py2exe version issue (see below I use a relatively old one
as I have had no time/need to upgrade).
Attached is the setup.py generated by Gui2Exe.
Werner
P.S. some version info:
# Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32
bit (Intel)]
# wxPython 2.8.9.1, Boa Constructor 0.6.1
