pywin32-bugs Mailing List for Python for Windows Extensions (Page 39)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2009-12-07 10:37:54
|
Bugs item #2908261, was opened at 2009-12-03 17:52 Message generated for change (Comment added) made by sreichelt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Sebastian Reichelt (sreichelt) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation exception with wxPython via ActiveScript Initial Comment: Hello! After years of using PyWin32 successfully via ActiveScript, we (PTV AG) are now experiencing some crashes in certain situations. While trying to debug these, we found several access violation exceptions that seem to happen deep inside some Windows code after importing wxPython, creating a wx app object, and then closing the session. Although they don't actually lead to visible crashes - apparently they are caught somewhere - we suspect that they may be related to other crashes that we do see but for which we don't have any simple test case. One way to reliably reproduce the access violation is to open a standard "open file" dialog afterwards, as in the attached test case (compilable with VS 2005, but small enough to be easily portable, hopefully). It is probably easiest to tell the VS debugger to stop at all Windows exceptions. The access violation does not happen in our program if the dialog is opened before the script ends (i.e., while the script is waiting for some input), so we think it might be some cleanup code that destroys part of the host program's state. Of course, we have no idea whether PyWin32 or wxPython causes the problem, or whether PyWin32 is simply incompatible with wxPython (that's why I'm posting here first, just in case it's already known), or whether this access violation is really the cause for our crashes in other situations. But since it does indicate that something is broken, and we have no better guess at the moment, we are putting all of our hope into the idea that this can be fixed, and that the fix will also free us of the actual crashes. For the record, we have tried versions 212 and 214 of PyWin32, with Python 2.5 32-bit and 2.6 64-bit, different versions of wxPython including the latest, and both debug and release builds of our program. The symptoms are always the same, except that on 32-bit, the debugger does not show any meaningful call stack entries. If you have any idea how to debug this, that could help us already. In any case, thanks for making app scripting using Python possible in the first place! Best regards, Sebastian Reichelt ---------------------------------------------------------------------- Comment By: Sebastian Reichelt (sreichelt) Date: 2009-12-07 11:37 Message: Well, the test case is a two-line script. Yes, technically it could be called a wx app. In fact, all scripts that use wx seem to cause this problem. But that's also one of the reasons why I would like to figure out if it's a pywin32 issue first. Did you get a chance to run the test case? In any case, thanks for your help so far. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-04 23:42 Message: It isn't clear to me how you are using pywin32 here - if it is a wx app which crashes, you are probably best off looking for help on the wx list ---------------------------------------------------------------------- Comment By: Sebastian Reichelt (sreichelt) Date: 2009-12-04 11:43 Message: I don't think I have any Python-implemented shell extensions installed, and looking at the DLLs that are loaded when the file dialog opens, I can't see anything related to Python. So I think the test case should hopefully work even on a clean Windows installation (oh - we are using Vista, btw - forgot that) with just Python, PyWin32, and wxPython. But: python26.dll, pythoncom26.dll, and pywintypes26.dll are never unloaded after the script exits. It's the same with an empty script, though. Does this already indicate a problem? Are we making a mistake in the way we use ActiveScript, maybe? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-03 22:45 Message: Do you have any Python implemented shell extensions (eg, Tortoise HG or Tortoise BZR?). I'd suggest you look in the debugger to try and work out if the file open dialog is causing another Python interpreter to be loaded into the process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-06 22:12:20
|
Bugs item #2909712, was opened at 2009-12-07 05:29 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2909712&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Klaus Noekel (kahlbutz) Assigned to: Nobody/Anonymous (nobody) Summary: win32com.client.Dispatch fails if called in thread Initial Comment: I would like to create COM objects via win32com.client.Dispatch in several threads to take advantage of multithreading. However, the same call that succeeds in the main thread fails when executed within a worker thread. The error message is: Exception in thread Thread-3: Traceback (most recent call last): File "C:\Python25\Lib\threading.py", line 486, in __bootstrap_inner self.run() File "C:\daten\PTV\Visum Misc\threadtest.py", line 12, in run XL = win32com.client.Dispatch("Excel.Application") # this one fails File "c:\Python25\lib\site-packages\win32com\client\__init__.py", line 95, in Dispatch dispatch, userName = dynamic._GetGoodDispatchAndUserName(dispatch,userName,clsctx) File "c:\Python25\lib\site-packages\win32com\client\dynamic.py", line 98, in _GetGoodDispatchAndUserName return (_GetGoodDispatch(IDispatch, clsctx), userName) File "c:\Python25\lib\site-packages\win32com\client\dynamic.py", line 78, in _GetGoodDispatch IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx, pythoncom.IID_IDispatch) com_error: (-2147221008, 'CoInitialize wurde nicht aufgerufen.', None, None) The last line translates as "CoInitialize was not called". Why can't I create COM objects from worker threads? Or what do I have to do to make it work? Thanks for any advice! Klaus ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-07 09:12 Message: You need to call CoInitialize from each thread. You also need to follow all other COM threading rules (eg, you can't pass COM objects between threads without jumping through hoops, etc) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2909712&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-06 18:29:21
|
Bugs item #2909712, was opened at 2009-12-06 19:29 Message generated for change (Tracker Item Submitted) made by kahlbutz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2909712&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Klaus Noekel (kahlbutz) Assigned to: Nobody/Anonymous (nobody) Summary: win32com.client.Dispatch fails if called in thread Initial Comment: I would like to create COM objects via win32com.client.Dispatch in several threads to take advantage of multithreading. However, the same call that succeeds in the main thread fails when executed within a worker thread. The error message is: Exception in thread Thread-3: Traceback (most recent call last): File "C:\Python25\Lib\threading.py", line 486, in __bootstrap_inner self.run() File "C:\daten\PTV\Visum Misc\threadtest.py", line 12, in run XL = win32com.client.Dispatch("Excel.Application") # this one fails File "c:\Python25\lib\site-packages\win32com\client\__init__.py", line 95, in Dispatch dispatch, userName = dynamic._GetGoodDispatchAndUserName(dispatch,userName,clsctx) File "c:\Python25\lib\site-packages\win32com\client\dynamic.py", line 98, in _GetGoodDispatchAndUserName return (_GetGoodDispatch(IDispatch, clsctx), userName) File "c:\Python25\lib\site-packages\win32com\client\dynamic.py", line 78, in _GetGoodDispatch IDispatch = pythoncom.CoCreateInstance(IDispatch, None, clsctx, pythoncom.IID_IDispatch) com_error: (-2147221008, 'CoInitialize wurde nicht aufgerufen.', None, None) The last line translates as "CoInitialize was not called". Why can't I create COM objects from worker threads? Or what do I have to do to make it work? Thanks for any advice! Klaus ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2909712&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-04 22:42:43
|
Bugs item #2908261, was opened at 2009-12-04 03:52 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Sebastian Reichelt (sreichelt) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation exception with wxPython via ActiveScript Initial Comment: Hello! After years of using PyWin32 successfully via ActiveScript, we (PTV AG) are now experiencing some crashes in certain situations. While trying to debug these, we found several access violation exceptions that seem to happen deep inside some Windows code after importing wxPython, creating a wx app object, and then closing the session. Although they don't actually lead to visible crashes - apparently they are caught somewhere - we suspect that they may be related to other crashes that we do see but for which we don't have any simple test case. One way to reliably reproduce the access violation is to open a standard "open file" dialog afterwards, as in the attached test case (compilable with VS 2005, but small enough to be easily portable, hopefully). It is probably easiest to tell the VS debugger to stop at all Windows exceptions. The access violation does not happen in our program if the dialog is opened before the script ends (i.e., while the script is waiting for some input), so we think it might be some cleanup code that destroys part of the host program's state. Of course, we have no idea whether PyWin32 or wxPython causes the problem, or whether PyWin32 is simply incompatible with wxPython (that's why I'm posting here first, just in case it's already known), or whether this access violation is really the cause for our crashes in other situations. But since it does indicate that something is broken, and we have no better guess at the moment, we are putting all of our hope into the idea that this can be fixed, and that the fix will also free us of the actual crashes. For the record, we have tried versions 212 and 214 of PyWin32, with Python 2.5 32-bit and 2.6 64-bit, different versions of wxPython including the latest, and both debug and release builds of our program. The symptoms are always the same, except that on 32-bit, the debugger does not show any meaningful call stack entries. If you have any idea how to debug this, that could help us already. In any case, thanks for making app scripting using Python possible in the first place! Best regards, Sebastian Reichelt ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-05 09:42 Message: It isn't clear to me how you are using pywin32 here - if it is a wx app which crashes, you are probably best off looking for help on the wx list ---------------------------------------------------------------------- Comment By: Sebastian Reichelt (sreichelt) Date: 2009-12-04 21:43 Message: I don't think I have any Python-implemented shell extensions installed, and looking at the DLLs that are loaded when the file dialog opens, I can't see anything related to Python. So I think the test case should hopefully work even on a clean Windows installation (oh - we are using Vista, btw - forgot that) with just Python, PyWin32, and wxPython. But: python26.dll, pythoncom26.dll, and pywintypes26.dll are never unloaded after the script exits. It's the same with an empty script, though. Does this already indicate a problem? Are we making a mistake in the way we use ActiveScript, maybe? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-04 08:45 Message: Do you have any Python implemented shell extensions (eg, Tortoise HG or Tortoise BZR?). I'd suggest you look in the debugger to try and work out if the file open dialog is causing another Python interpreter to be loaded into the process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-04 17:24:12
|
Bugs item #2908939, was opened at 2009-12-04 11:24 Message generated for change (Tracker Item Submitted) made by beef623 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908939&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: beef (beef623) Assigned to: Nobody/Anonymous (nobody) Summary: Installer Crashes in Windows 7 Initial Comment: The installer crashes with a Visual C++ runtime error near the end of the installation process in Windows 7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908939&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-04 10:43:05
|
Bugs item #2908261, was opened at 2009-12-03 17:52 Message generated for change (Comment added) made by sreichelt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sebastian Reichelt (sreichelt) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation exception with wxPython via ActiveScript Initial Comment: Hello! After years of using PyWin32 successfully via ActiveScript, we (PTV AG) are now experiencing some crashes in certain situations. While trying to debug these, we found several access violation exceptions that seem to happen deep inside some Windows code after importing wxPython, creating a wx app object, and then closing the session. Although they don't actually lead to visible crashes - apparently they are caught somewhere - we suspect that they may be related to other crashes that we do see but for which we don't have any simple test case. One way to reliably reproduce the access violation is to open a standard "open file" dialog afterwards, as in the attached test case (compilable with VS 2005, but small enough to be easily portable, hopefully). It is probably easiest to tell the VS debugger to stop at all Windows exceptions. The access violation does not happen in our program if the dialog is opened before the script ends (i.e., while the script is waiting for some input), so we think it might be some cleanup code that destroys part of the host program's state. Of course, we have no idea whether PyWin32 or wxPython causes the problem, or whether PyWin32 is simply incompatible with wxPython (that's why I'm posting here first, just in case it's already known), or whether this access violation is really the cause for our crashes in other situations. But since it does indicate that something is broken, and we have no better guess at the moment, we are putting all of our hope into the idea that this can be fixed, and that the fix will also free us of the actual crashes. For the record, we have tried versions 212 and 214 of PyWin32, with Python 2.5 32-bit and 2.6 64-bit, different versions of wxPython including the latest, and both debug and release builds of our program. The symptoms are always the same, except that on 32-bit, the debugger does not show any meaningful call stack entries. If you have any idea how to debug this, that could help us already. In any case, thanks for making app scripting using Python possible in the first place! Best regards, Sebastian Reichelt ---------------------------------------------------------------------- Comment By: Sebastian Reichelt (sreichelt) Date: 2009-12-04 11:43 Message: I don't think I have any Python-implemented shell extensions installed, and looking at the DLLs that are loaded when the file dialog opens, I can't see anything related to Python. So I think the test case should hopefully work even on a clean Windows installation (oh - we are using Vista, btw - forgot that) with just Python, PyWin32, and wxPython. But: python26.dll, pythoncom26.dll, and pywintypes26.dll are never unloaded after the script exits. It's the same with an empty script, though. Does this already indicate a problem? Are we making a mistake in the way we use ActiveScript, maybe? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-03 22:45 Message: Do you have any Python implemented shell extensions (eg, Tortoise HG or Tortoise BZR?). I'd suggest you look in the debugger to try and work out if the file open dialog is causing another Python interpreter to be loaded into the process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-03 21:46:00
|
Bugs item #2908261, was opened at 2009-12-04 03:52 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sebastian Reichelt (sreichelt) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation exception with wxPython via ActiveScript Initial Comment: Hello! After years of using PyWin32 successfully via ActiveScript, we (PTV AG) are now experiencing some crashes in certain situations. While trying to debug these, we found several access violation exceptions that seem to happen deep inside some Windows code after importing wxPython, creating a wx app object, and then closing the session. Although they don't actually lead to visible crashes - apparently they are caught somewhere - we suspect that they may be related to other crashes that we do see but for which we don't have any simple test case. One way to reliably reproduce the access violation is to open a standard "open file" dialog afterwards, as in the attached test case (compilable with VS 2005, but small enough to be easily portable, hopefully). It is probably easiest to tell the VS debugger to stop at all Windows exceptions. The access violation does not happen in our program if the dialog is opened before the script ends (i.e., while the script is waiting for some input), so we think it might be some cleanup code that destroys part of the host program's state. Of course, we have no idea whether PyWin32 or wxPython causes the problem, or whether PyWin32 is simply incompatible with wxPython (that's why I'm posting here first, just in case it's already known), or whether this access violation is really the cause for our crashes in other situations. But since it does indicate that something is broken, and we have no better guess at the moment, we are putting all of our hope into the idea that this can be fixed, and that the fix will also free us of the actual crashes. For the record, we have tried versions 212 and 214 of PyWin32, with Python 2.5 32-bit and 2.6 64-bit, different versions of wxPython including the latest, and both debug and release builds of our program. The symptoms are always the same, except that on 32-bit, the debugger does not show any meaningful call stack entries. If you have any idea how to debug this, that could help us already. In any case, thanks for making app scripting using Python possible in the first place! Best regards, Sebastian Reichelt ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-04 08:45 Message: Do you have any Python implemented shell extensions (eg, Tortoise HG or Tortoise BZR?). I'd suggest you look in the debugger to try and work out if the file open dialog is causing another Python interpreter to be loaded into the process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-03 16:52:07
|
Bugs item #2908261, was opened at 2009-12-03 17:52 Message generated for change (Tracker Item Submitted) made by sreichelt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sebastian Reichelt (sreichelt) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation exception with wxPython via ActiveScript Initial Comment: Hello! After years of using PyWin32 successfully via ActiveScript, we (PTV AG) are now experiencing some crashes in certain situations. While trying to debug these, we found several access violation exceptions that seem to happen deep inside some Windows code after importing wxPython, creating a wx app object, and then closing the session. Although they don't actually lead to visible crashes - apparently they are caught somewhere - we suspect that they may be related to other crashes that we do see but for which we don't have any simple test case. One way to reliably reproduce the access violation is to open a standard "open file" dialog afterwards, as in the attached test case (compilable with VS 2005, but small enough to be easily portable, hopefully). It is probably easiest to tell the VS debugger to stop at all Windows exceptions. The access violation does not happen in our program if the dialog is opened before the script ends (i.e., while the script is waiting for some input), so we think it might be some cleanup code that destroys part of the host program's state. Of course, we have no idea whether PyWin32 or wxPython causes the problem, or whether PyWin32 is simply incompatible with wxPython (that's why I'm posting here first, just in case it's already known), or whether this access violation is really the cause for our crashes in other situations. But since it does indicate that something is broken, and we have no better guess at the moment, we are putting all of our hope into the idea that this can be fixed, and that the fix will also free us of the actual crashes. For the record, we have tried versions 212 and 214 of PyWin32, with Python 2.5 32-bit and 2.6 64-bit, different versions of wxPython including the latest, and both debug and release builds of our program. The symptoms are always the same, except that on 32-bit, the debugger does not show any meaningful call stack entries. If you have any idea how to debug this, that could help us already. In any case, thanks for making app scripting using Python possible in the first place! Best regards, Sebastian Reichelt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-03 14:07:40
|
Bugs item #2907614, was opened at 2009-12-02 17:27 Message generated for change (Comment added) made by marvingreenberg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: marvin greenberg (marvingreenberg) Assigned to: Nobody/Anonymous (nobody) Summary: PYWIN32 not identifying current WINVER correctly (v214) Initial Comment: I'm building python from source, then using that build to build pywin32 from source (to satisfy some requirements of our build environment). This succeeds fine when the build machine is XP SP2 with VIsualStudio VC90, but when the installed dev env is VC80 it fails. Python builds and installs fine. PYWIN32 builds, but as it builds there are a variety of messages "Unable to import verstamp, no version info will be added" Googling seems to indicate this issue has been resolved, and there is not any error copying, e.g. pywintypes, like "copying build\temp.win32-2.6\Release\win32\src\pywintypes26.lib -> build\temp.win32-2.6\Release\pywintypes.lib" When PYWIN32 gets to trying to build win32process extensions, I get win32/src/win32process_py2_swig.cpp(2635) : error C2065: 'THREAD_MODE_BACKGROUND_BEGIN' : undeclared identifier win32/src/win32process_py2_swig.cpp(2637) : error C2065: 'THREAD_MODE_BACKGROUND_END' : undeclared identifier I also get warnings like: "cl : Command line warning D9002 : ignoring unknown option '/YXPyWinTypes.h' PyACL.cpp" Which all seems to imply WINVER is being set to the wrong value. And indeed early in the build process, I see "Found version 0x500 in C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\WinResrc.h" Now my VIsual Studio IDE is up to date, and XP SP2 should be 0x500. Is this some problem with how I'm building PYWIN32 preventing some internal logic from correctly identifying the build platform? Is there some way to force PYWIN32 to target a specific windows platform? (I've tried setting CL to /DWINVER=0x502 to no avail) My actual command line, run under cygwin (yes...) is: export PATH='/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/vcpackages:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin/prerelease:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/SDK/v2.0/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/usr/bin'; /cygdrive/c/buildhome/all/xp-vc80/python-vtrunk-2.6.4/build/python setup.py install using the local built and installed python. ---------------------------------------------------------------------- >Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-03 14:07 Message: Unsupported configuration. ---------------------------------------------------------------------- Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-03 14:06 Message: I sort of suspected that would be the response, but completely understand. I was hoping this might have been some simple oversight (which hope had been essentially extinguished after looking at the complexity of setup.py). Thanks. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-02 21:43 Message: Note that Python 2.,6 is officially built using VS2008. Re not finding the SDK, you may need to set the MSSDK environment variable to point at your SDK. ---------------------------------------------------------------------- Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-02 21:16 Message: There is a typo above -- the expected winver for XP SP2 is 0x502. ---------------------------------------------------------------------- Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-02 18:25 Message: Debugging setup.py a bit, find_platform_sdk_dir() is returning None. None of the registry keys or paths exists. Windows.h is only found under the Microsoft Visual Studio 8/VC/PlatformSDK/Include ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-03 14:06:12
|
Bugs item #2907614, was opened at 2009-12-02 17:27 Message generated for change (Comment added) made by marvingreenberg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Pending Resolution: None Priority: 5 Private: No Submitted By: marvin greenberg (marvingreenberg) Assigned to: Nobody/Anonymous (nobody) Summary: PYWIN32 not identifying current WINVER correctly (v214) Initial Comment: I'm building python from source, then using that build to build pywin32 from source (to satisfy some requirements of our build environment). This succeeds fine when the build machine is XP SP2 with VIsualStudio VC90, but when the installed dev env is VC80 it fails. Python builds and installs fine. PYWIN32 builds, but as it builds there are a variety of messages "Unable to import verstamp, no version info will be added" Googling seems to indicate this issue has been resolved, and there is not any error copying, e.g. pywintypes, like "copying build\temp.win32-2.6\Release\win32\src\pywintypes26.lib -> build\temp.win32-2.6\Release\pywintypes.lib" When PYWIN32 gets to trying to build win32process extensions, I get win32/src/win32process_py2_swig.cpp(2635) : error C2065: 'THREAD_MODE_BACKGROUND_BEGIN' : undeclared identifier win32/src/win32process_py2_swig.cpp(2637) : error C2065: 'THREAD_MODE_BACKGROUND_END' : undeclared identifier I also get warnings like: "cl : Command line warning D9002 : ignoring unknown option '/YXPyWinTypes.h' PyACL.cpp" Which all seems to imply WINVER is being set to the wrong value. And indeed early in the build process, I see "Found version 0x500 in C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\WinResrc.h" Now my VIsual Studio IDE is up to date, and XP SP2 should be 0x500. Is this some problem with how I'm building PYWIN32 preventing some internal logic from correctly identifying the build platform? Is there some way to force PYWIN32 to target a specific windows platform? (I've tried setting CL to /DWINVER=0x502 to no avail) My actual command line, run under cygwin (yes...) is: export PATH='/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/vcpackages:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin/prerelease:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/SDK/v2.0/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/usr/bin'; /cygdrive/c/buildhome/all/xp-vc80/python-vtrunk-2.6.4/build/python setup.py install using the local built and installed python. ---------------------------------------------------------------------- Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-03 14:06 Message: I sort of suspected that would be the response, but completely understand. I was hoping this might have been some simple oversight (which hope had been essentially extinguished after looking at the complexity of setup.py). Thanks. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-02 21:43 Message: Note that Python 2.,6 is officially built using VS2008. Re not finding the SDK, you may need to set the MSSDK environment variable to point at your SDK. ---------------------------------------------------------------------- Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-02 21:16 Message: There is a typo above -- the expected winver for XP SP2 is 0x502. ---------------------------------------------------------------------- Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-02 18:25 Message: Debugging setup.py a bit, find_platform_sdk_dir() is returning None. None of the registry keys or paths exists. Windows.h is only found under the Microsoft Visual Studio 8/VC/PlatformSDK/Include ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-02 21:43:00
|
Bugs item #2907614, was opened at 2009-12-03 04:27 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: marvin greenberg (marvingreenberg) Assigned to: Nobody/Anonymous (nobody) Summary: PYWIN32 not identifying current WINVER correctly (v214) Initial Comment: I'm building python from source, then using that build to build pywin32 from source (to satisfy some requirements of our build environment). This succeeds fine when the build machine is XP SP2 with VIsualStudio VC90, but when the installed dev env is VC80 it fails. Python builds and installs fine. PYWIN32 builds, but as it builds there are a variety of messages "Unable to import verstamp, no version info will be added" Googling seems to indicate this issue has been resolved, and there is not any error copying, e.g. pywintypes, like "copying build\temp.win32-2.6\Release\win32\src\pywintypes26.lib -> build\temp.win32-2.6\Release\pywintypes.lib" When PYWIN32 gets to trying to build win32process extensions, I get win32/src/win32process_py2_swig.cpp(2635) : error C2065: 'THREAD_MODE_BACKGROUND_BEGIN' : undeclared identifier win32/src/win32process_py2_swig.cpp(2637) : error C2065: 'THREAD_MODE_BACKGROUND_END' : undeclared identifier I also get warnings like: "cl : Command line warning D9002 : ignoring unknown option '/YXPyWinTypes.h' PyACL.cpp" Which all seems to imply WINVER is being set to the wrong value. And indeed early in the build process, I see "Found version 0x500 in C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\WinResrc.h" Now my VIsual Studio IDE is up to date, and XP SP2 should be 0x500. Is this some problem with how I'm building PYWIN32 preventing some internal logic from correctly identifying the build platform? Is there some way to force PYWIN32 to target a specific windows platform? (I've tried setting CL to /DWINVER=0x502 to no avail) My actual command line, run under cygwin (yes...) is: export PATH='/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/vcpackages:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin/prerelease:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/SDK/v2.0/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/usr/bin'; /cygdrive/c/buildhome/all/xp-vc80/python-vtrunk-2.6.4/build/python setup.py install using the local built and installed python. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-03 08:43 Message: Note that Python 2.,6 is officially built using VS2008. Re not finding the SDK, you may need to set the MSSDK environment variable to point at your SDK. ---------------------------------------------------------------------- Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-03 08:16 Message: There is a typo above -- the expected winver for XP SP2 is 0x502. ---------------------------------------------------------------------- Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-03 05:25 Message: Debugging setup.py a bit, find_platform_sdk_dir() is returning None. None of the registry keys or paths exists. Windows.h is only found under the Microsoft Visual Studio 8/VC/PlatformSDK/Include ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-02 21:16:17
|
Bugs item #2907614, was opened at 2009-12-02 17:27 Message generated for change (Comment added) made by marvingreenberg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: marvin greenberg (marvingreenberg) Assigned to: Nobody/Anonymous (nobody) Summary: PYWIN32 not identifying current WINVER correctly (v214) Initial Comment: I'm building python from source, then using that build to build pywin32 from source (to satisfy some requirements of our build environment). This succeeds fine when the build machine is XP SP2 with VIsualStudio VC90, but when the installed dev env is VC80 it fails. Python builds and installs fine. PYWIN32 builds, but as it builds there are a variety of messages "Unable to import verstamp, no version info will be added" Googling seems to indicate this issue has been resolved, and there is not any error copying, e.g. pywintypes, like "copying build\temp.win32-2.6\Release\win32\src\pywintypes26.lib -> build\temp.win32-2.6\Release\pywintypes.lib" When PYWIN32 gets to trying to build win32process extensions, I get win32/src/win32process_py2_swig.cpp(2635) : error C2065: 'THREAD_MODE_BACKGROUND_BEGIN' : undeclared identifier win32/src/win32process_py2_swig.cpp(2637) : error C2065: 'THREAD_MODE_BACKGROUND_END' : undeclared identifier I also get warnings like: "cl : Command line warning D9002 : ignoring unknown option '/YXPyWinTypes.h' PyACL.cpp" Which all seems to imply WINVER is being set to the wrong value. And indeed early in the build process, I see "Found version 0x500 in C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\WinResrc.h" Now my VIsual Studio IDE is up to date, and XP SP2 should be 0x500. Is this some problem with how I'm building PYWIN32 preventing some internal logic from correctly identifying the build platform? Is there some way to force PYWIN32 to target a specific windows platform? (I've tried setting CL to /DWINVER=0x502 to no avail) My actual command line, run under cygwin (yes...) is: export PATH='/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/vcpackages:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin/prerelease:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/SDK/v2.0/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/usr/bin'; /cygdrive/c/buildhome/all/xp-vc80/python-vtrunk-2.6.4/build/python setup.py install using the local built and installed python. ---------------------------------------------------------------------- >Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-02 21:16 Message: There is a typo above -- the expected winver for XP SP2 is 0x502. ---------------------------------------------------------------------- Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-02 18:25 Message: Debugging setup.py a bit, find_platform_sdk_dir() is returning None. None of the registry keys or paths exists. Windows.h is only found under the Microsoft Visual Studio 8/VC/PlatformSDK/Include ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-02 18:26:01
|
Bugs item #2907614, was opened at 2009-12-02 17:27 Message generated for change (Comment added) made by marvingreenberg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: marvin greenberg (marvingreenberg) Assigned to: Nobody/Anonymous (nobody) Summary: PYWIN32 not identifying current WINVER correctly (v214) Initial Comment: I'm building python from source, then using that build to build pywin32 from source (to satisfy some requirements of our build environment). This succeeds fine when the build machine is XP SP2 with VIsualStudio VC90, but when the installed dev env is VC80 it fails. Python builds and installs fine. PYWIN32 builds, but as it builds there are a variety of messages "Unable to import verstamp, no version info will be added" Googling seems to indicate this issue has been resolved, and there is not any error copying, e.g. pywintypes, like "copying build\temp.win32-2.6\Release\win32\src\pywintypes26.lib -> build\temp.win32-2.6\Release\pywintypes.lib" When PYWIN32 gets to trying to build win32process extensions, I get win32/src/win32process_py2_swig.cpp(2635) : error C2065: 'THREAD_MODE_BACKGROUND_BEGIN' : undeclared identifier win32/src/win32process_py2_swig.cpp(2637) : error C2065: 'THREAD_MODE_BACKGROUND_END' : undeclared identifier I also get warnings like: "cl : Command line warning D9002 : ignoring unknown option '/YXPyWinTypes.h' PyACL.cpp" Which all seems to imply WINVER is being set to the wrong value. And indeed early in the build process, I see "Found version 0x500 in C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\WinResrc.h" Now my VIsual Studio IDE is up to date, and XP SP2 should be 0x500. Is this some problem with how I'm building PYWIN32 preventing some internal logic from correctly identifying the build platform? Is there some way to force PYWIN32 to target a specific windows platform? (I've tried setting CL to /DWINVER=0x502 to no avail) My actual command line, run under cygwin (yes...) is: export PATH='/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/vcpackages:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin/prerelease:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/SDK/v2.0/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/usr/bin'; /cygdrive/c/buildhome/all/xp-vc80/python-vtrunk-2.6.4/build/python setup.py install using the local built and installed python. ---------------------------------------------------------------------- >Comment By: marvin greenberg (marvingreenberg) Date: 2009-12-02 18:25 Message: Debugging setup.py a bit, find_platform_sdk_dir() is returning None. None of the registry keys or paths exists. Windows.h is only found under the Microsoft Visual Studio 8/VC/PlatformSDK/Include ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-02 17:27:49
|
Bugs item #2907614, was opened at 2009-12-02 17:27 Message generated for change (Tracker Item Submitted) made by marvingreenberg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: marvin greenberg (marvingreenberg) Assigned to: Nobody/Anonymous (nobody) Summary: PYWIN32 not identifying current WINVER correctly (v214) Initial Comment: I'm building python from source, then using that build to build pywin32 from source (to satisfy some requirements of our build environment). This succeeds fine when the build machine is XP SP2 with VIsualStudio VC90, but when the installed dev env is VC80 it fails. Python builds and installs fine. PYWIN32 builds, but as it builds there are a variety of messages "Unable to import verstamp, no version info will be added" Googling seems to indicate this issue has been resolved, and there is not any error copying, e.g. pywintypes, like "copying build\temp.win32-2.6\Release\win32\src\pywintypes26.lib -> build\temp.win32-2.6\Release\pywintypes.lib" When PYWIN32 gets to trying to build win32process extensions, I get win32/src/win32process_py2_swig.cpp(2635) : error C2065: 'THREAD_MODE_BACKGROUND_BEGIN' : undeclared identifier win32/src/win32process_py2_swig.cpp(2637) : error C2065: 'THREAD_MODE_BACKGROUND_END' : undeclared identifier I also get warnings like: "cl : Command line warning D9002 : ignoring unknown option '/YXPyWinTypes.h' PyACL.cpp" Which all seems to imply WINVER is being set to the wrong value. And indeed early in the build process, I see "Found version 0x500 in C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include\WinResrc.h" Now my VIsual Studio IDE is up to date, and XP SP2 should be 0x500. Is this some problem with how I'm building PYWIN32 preventing some internal logic from correctly identifying the build platform? Is there some way to force PYWIN32 to target a specific windows platform? (I've tried setting CL to /DWINVER=0x502 to no avail) My actual command line, run under cygwin (yes...) is: export PATH='/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/vc/vcpackages:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin/prerelease:/cygdrive/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 8/SDK/v2.0/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/usr/bin'; /cygdrive/c/buildhome/all/xp-vc80/python-vtrunk-2.6.4/build/python setup.py install using the local built and installed python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2907614&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-02 10:50:14
|
Patches item #2896861, was opened at 2009-11-13 08:36 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2896861&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Sridhar Ratnakumar (nearfar) >Assigned to: Mark Hammond (mhammond) Summary: AutoDuck Py3k port Initial Comment: Hey Mark, This is Sridhar from ActiveState. Since Trent is involved with Komodo, I am working on ActivePython these days. While working on supporting pywin32 for ActivePython-3.x, I had to port AutoDuck to Python 3.1. I'm attaching the patch here. Please review. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-02 21:50 Message: Hi Sridhar, Thanks! I just checked this in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2896861&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-01 10:51:29
|
Bugs item #2906625, was opened at 2009-12-01 19:57 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906625&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: jpiron (jpiron) Assigned to: Nobody/Anonymous (nobody) Summary: Windows service with logging to FILES module Initial Comment: Dears, I'm sorry to reopen this bug, but the former was closed abruptly... The last paragraph is about the log-to-files-that-fails part. When I try to use the logging module in a script that is called by a general script intended to create a windows service that runs the script in a separated thread, I get an IOError: Bad file descriptor For exemple, I have a script that polls a value and logs it every second. It runs flawlessly alone and in debug mode in a service. But once it is started normally. the log process is successfull several times (8 for exemple, and always 8) and the next time, the IOError is raised. I ave tried with several handlers: RotatingFileHandler, FileHandler, and even StreamHandler, with different polling times, different numberd of successive writes and some other parameters. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-01 21:51 Message: I closed the bug after indicating the problem. Note that stdio buffering is what causes the problem to fail after what appears to be 8 log calls (but in reality, it fails after a fixed number of bytes are written). Unless you can show this is a problem with pywin32's service support, I'll be forced to close this bug eventually too... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906625&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-12-01 08:57:59
|
Bugs item #2906625, was opened at 2009-12-01 08:57 Message generated for change (Tracker Item Submitted) made by jpiron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906625&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: jpiron (jpiron) Assigned to: Nobody/Anonymous (nobody) Summary: Windows service with logging to FILES module Initial Comment: Dears, I'm sorry to reopen this bug, but the former was closed abruptly... The last paragraph is about the log-to-files-that-fails part. When I try to use the logging module in a script that is called by a general script intended to create a windows service that runs the script in a separated thread, I get an IOError: Bad file descriptor For exemple, I have a script that polls a value and logs it every second. It runs flawlessly alone and in debug mode in a service. But once it is started normally. the log process is successfull several times (8 for exemple, and always 8) and the next time, the IOError is raised. I ave tried with several handlers: RotatingFileHandler, FileHandler, and even StreamHandler, with different polling times, different numberd of successive writes and some other parameters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906625&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-11-30 23:25:56
|
Bugs item #2905909, was opened at 2009-11-30 22:10 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2905909&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: assert sys.modules[modname] is old_mod error in pywintypes Initial Comment: When running Apache+Mod Python (Python 2.4), I was getting this error - [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] Traceback (most recent call last): [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1537, in HandlerDispatch\n default=default_handler, arg=req, silent=hlist.silent) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1229, in _process_target\n result = _execute_target(config, req, object, arg) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1128, in _execute_target\n result = object(arg) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\modpython.py", line 228, in handler\n return ModPythonHandler()(req) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\modpython.py", line 201, in __call__\n response = self.get_response(request) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\base.py", line 73, in get_response\n response = middleware_method(request) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\middleware.py", line 10, in process_request\n engine = import_module(settings.SESSION_ENGINE) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\utils\\importlib.py", line 35, in import_module\n __import__(name) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\backends\\db.py", line 2, in ?\n from django.contrib.sessions.models import Session [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\models.py", line 4, in ?\n from django.db import models [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\db\\models\\__init__.py", line 12, in ?\n from django.db.models.fields.files import FileField, ImageField [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\db\\models\\fields\\files.py", line 8, in ?\n from django.core.files.storage import default_storage [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\files\\storage.py", line 7, in ?\n from django.core.files import locks, File [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\files\\locks.py", line 25, in ?\n import pywintypes [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\win32\\lib\\pywintypes.py", line 124, in ?\n __import_pywin32_system_module__("pywintypes", globals()) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\win32\\lib\\pywintypes.py", line 114, in __import_pywin32_system_module__\n assert sys.modules[modname] is old_mod [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] AssertionError With PythonDebug = On, assert took effect. I removed it and it worked without any issues. I found that another user - <a href="http://markmail.org/message/hqnf6obaillzspxj#query:assert%20sys.modules[modname]%20is%20old_mod+page:1+mid:nahkqunchycwqtd4+state:results">here</a> also has the same issue. He solved it by going back a version. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-01 10:25 Message: My concern is that assertion may be indicating pywintypesxx.dll has been loaded twice by the process, causing subtle problems with the types. It would be interesting to know what the __file__ attribute is on the 2 objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2905909&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-11-30 23:18:25
|
Bugs item #2906084, was opened at 2009-12-01 03:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906084&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: jpiron (jpiron) Assigned to: Nobody/Anonymous (nobody) Summary: Windows service with logging module Initial Comment: Dears, When I try to use the logging module in a script that is called by a general script intended to create a windows service that runs the script in a separated thread, I get an IOError: Bad file descriptor For exemple, I have a script that polls a value and logs it every second. It runs flawlessly alone and in debug mode in a service. But once it is started normally. the log process is successfull several times (8 for exemple, and always 8) and the next time, the IOError is raised. I ave tried with several handlers: RotatingFileHandler, FileHandler, and even StreamHandler, with different polling times, different numberd of successive writes and some other parameters. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-01 10:18 Message: Services do not have valid sys.stdout or sys.stderr objects. As the logging module uses these by default, it fails. There is nothing suitable python can provide instead of those handles, so the solution is to log to a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906084&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-11-30 16:56:44
|
Bugs item #2906084, was opened at 2009-11-30 16:56 Message generated for change (Tracker Item Submitted) made by jpiron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906084&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: jpiron (jpiron) Assigned to: Nobody/Anonymous (nobody) Summary: Windows service with logging module Initial Comment: Dears, When I try to use the logging module in a script that is called by a general script intended to create a windows service that runs the script in a separated thread, I get an IOError: Bad file descriptor For exemple, I have a script that polls a value and logs it every second. It runs flawlessly alone and in debug mode in a service. But once it is started normally. the log process is successfull several times (8 for exemple, and always 8) and the next time, the IOError is raised. I ave tried with several handlers: RotatingFileHandler, FileHandler, and even StreamHandler, with different polling times, different numberd of successive writes and some other parameters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906084&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-11-30 11:10:50
|
Bugs item #2905909, was opened at 2009-11-30 11:10 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2905909&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: assert sys.modules[modname] is old_mod error in pywintypes Initial Comment: When running Apache+Mod Python (Python 2.4), I was getting this error - [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] Traceback (most recent call last): [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1537, in HandlerDispatch\n default=default_handler, arg=req, silent=hlist.silent) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1229, in _process_target\n result = _execute_target(config, req, object, arg) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1128, in _execute_target\n result = object(arg) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\modpython.py", line 228, in handler\n return ModPythonHandler()(req) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\modpython.py", line 201, in __call__\n response = self.get_response(request) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\base.py", line 73, in get_response\n response = middleware_method(request) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\middleware.py", line 10, in process_request\n engine = import_module(settings.SESSION_ENGINE) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\utils\\importlib.py", line 35, in import_module\n __import__(name) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\backends\\db.py", line 2, in ?\n from django.contrib.sessions.models import Session [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\models.py", line 4, in ?\n from django.db import models [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\db\\models\\__init__.py", line 12, in ?\n from django.db.models.fields.files import FileField, ImageField [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\db\\models\\fields\\files.py", line 8, in ?\n from django.core.files.storage import default_storage [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\files\\storage.py", line 7, in ?\n from django.core.files import locks, File [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\files\\locks.py", line 25, in ?\n import pywintypes [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\win32\\lib\\pywintypes.py", line 124, in ?\n __import_pywin32_system_module__("pywintypes", globals()) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\win32\\lib\\pywintypes.py", line 114, in __import_pywin32_system_module__\n assert sys.modules[modname] is old_mod [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] AssertionError With PythonDebug = On, assert took effect. I removed it and it worked without any issues. I found that another user - <a href="http://markmail.org/message/hqnf6obaillzspxj#query:assert%20sys.modules[modname]%20is%20old_mod+page:1+mid:nahkqunchycwqtd4+state:results">here</a> also has the same issue. He solved it by going back a version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2905909&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-11-25 02:39:22
|
Bugs item #2903518, was opened at 2009-11-24 21:39 Message generated for change (Tracker Item Submitted) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2903518&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: ISAPI script fails when a period is in the script name Initial Comment: I stumbled across this problem when working on an isapi wsgi script for MoinMoin. The other scripts in MoinMoin use the format "moin.foo.py" so I created "moin.isapi-wsgi.py", but I couldn't get it to work (500 Server Error when launching the app but before anything in the script is run). I determined that if I renamed the script to moin_isapi-wsgi.py it would work. I suspect this is either a limitation of IIS that it doesn't accept periods in the extension filename (except before 'dll') or because the pywin32 isapi.dll doesn't support a period in the filename. In either case, it would be nice if PyWin32 would handle this case more gracefully, either by adapting the filename of the DLL created or addressing the underlying support of periods in the filename. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2903518&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-11-19 20:43:03
|
Bugs item #2900706, was opened at 2009-11-19 21:30 Message generated for change (Comment added) made by arve_knudsen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2900706&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Arve Knudsen (arve_knudsen) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to build against debug Python Initial Comment: I am unable to build against debug-build of Python 2.6, using VC++ 2008 on Windows 7 x64. The build stops like this: C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe -nologo -manifest build\temp.win32-2.6-pydebug\Debug\win32/src\win32event_d.pyd.manifest -outputresource:build\lib.win32-2.6-pydebug\win32\win32event_d.pyd;2 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "build\lib.win32-2.6-pydebug\win32\win32event_d.pyd". The process cannot access the file because it is being used by another process. I can resume the build, then it fails on another target. ---------------------------------------------------------------------- >Comment By: Arve Knudsen (arve_knudsen) Date: 2009-11-19 21:43 Message: Nevermind, I found out it was due to antivirus filesystem monitoring. ---------------------------------------------------------------------- Comment By: Arve Knudsen (arve_knudsen) Date: 2009-11-19 21:30 Message: My build command: python_d .\setup.py build -g ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2900706&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-11-19 20:30:48
|
Bugs item #2900706, was opened at 2009-11-19 21:30 Message generated for change (Comment added) made by arve_knudsen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2900706&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arve Knudsen (arve_knudsen) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to build against debug Python Initial Comment: I am unable to build against debug-build of Python 2.6, using VC++ 2008 on Windows 7 x64. The build stops like this: C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe -nologo -manifest build\temp.win32-2.6-pydebug\Debug\win32/src\win32event_d.pyd.manifest -outputresource:build\lib.win32-2.6-pydebug\win32\win32event_d.pyd;2 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "build\lib.win32-2.6-pydebug\win32\win32event_d.pyd". The process cannot access the file because it is being used by another process. I can resume the build, then it fails on another target. ---------------------------------------------------------------------- >Comment By: Arve Knudsen (arve_knudsen) Date: 2009-11-19 21:30 Message: My build command: python_d .\setup.py build -g ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2900706&group_id=78018 |
From: SourceForge.net <no...@so...> - 2009-11-19 20:30:04
|
Bugs item #2900706, was opened at 2009-11-19 21:30 Message generated for change (Tracker Item Submitted) made by arve_knudsen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2900706&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arve Knudsen (arve_knudsen) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to build against debug Python Initial Comment: I am unable to build against debug-build of Python 2.6, using VC++ 2008 on Windows 7 x64. The build stops like this: C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe -nologo -manifest build\temp.win32-2.6-pydebug\Debug\win32/src\win32event_d.pyd.manifest -outputresource:build\lib.win32-2.6-pydebug\win32\win32event_d.pyd;2 mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "build\lib.win32-2.6-pydebug\win32\win32event_d.pyd". The process cannot access the file because it is being used by another process. I can resume the build, then it fails on another target. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2900706&group_id=78018 |