[ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler
Feature Requests item #1348719, was opened at 2005-11-05 00:58
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470
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: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David McNab (davidmcnab)
Assigned to: Nobody/Anonymous (nobody)
Summary: please support the free visual studio sdk compiler
Initial Comment:
Hi,
I noticed, with some pain, that while pythons 2.1 to
2.3 are built with msvc6, and allow for easy
compilation of extensions.
However, the official binary distro of python2.4 for
windows is built with ms vs .net 2003 (version 7.1).
I've tried using the .net framework sdk compiler:
(http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en)
also the Visual C++ Toolkit:
(http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en)
but in both cases, distutils complains that it can't
find a suitable compiler ("error: Python was built with
version 7.1 of visual studio...").
I did some hacking on distutils/msvccompiler.py, and
noticed that this module is searching for certain
registry keys that are only written by the non-free
Visual Studio .NET 2003 compiler.
As it is, this situation imposes on developers a
deterrent against upgrading to python 2.4. There are
millions of msvc6 installations out there, but for
many, the cost of upgrading to msvs .net 2003 is
prohibitive.
I have considered building python2.4 from source using
msvc6 (I notice the project/workspace files are present
in the source), but feel this is unwise because I could
end up building extension modules that are
binary-incompatible with everyone else's python2.4
I (and countless others, I'm sure) would really
appreciate it if the python devs could rework things to
make it possible to build python2.4 extensions using
the free ms compilers mentioned above).
Cheers
david
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-11-08 09:03
Message:
Logged In: YES
user_id=21627
I disagree that one of the reasons to use VC 7.1 was that a
free Microsoft compiler was available - it was never one of
the reasons why I considered switching. Instead, the reasons
were:
- MS no longer ships VC6, so many users only had VC7.1 and
where requesting that this was used,
- VC 7.1 solves a few problems, most notably, IPv6 support
can be built with that compiler, but not with VC6, and
people where requesting IPv6 support on Windows.
So I agree that this request should be closed; I personally
have no plans to work on it for the next few years.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-08 07:21
Message:
Logged In: YES
user_id=341410
I'm not sure this request should be closed. One of the
reasons that Python 2.4 compilation was switched to the 7.1
compiler was that it was supposed to be possible to compile
Python and extension modules with the free .net compiler.
If users cannot compile with the free .net compiler right
now, then it seems that there is a bit of a problem.
--
Comment By: David McNab (davidmcnab)
Date: 2005-11-08 04:00
Message:
Logged In: YES
user_id=35522
Thank you for your reply.
In desperation, I started downloading an evaluation version
of msvs.net 2003 from bittorrent.
But before the download was even halfway complete, I had
already installed mingw on my winbox and sorted out the
intricacies of compiling 3rd party libs, and building
working python extensions, using only mingw.
As a result, I am now free of the shackles of proprietary MS
toolchains, and am comfortable with mingw - especially since
most of the multiplatform 3rd party libs I've seen offer
good build support for MinGW. All my extensions, and others'
extensions I'm using, are now building quite happily with MinGW.
>From this perspective, I no longer have interest in being
able to build extensions with MS tools - freeware MSVC
compilers or otherwise. In fact, depending on a proprietary
toolchain to build Free/Opensource software now feels
ludicrous. Therefore, I'd be perfectly comfortable if you
want to close this support ticket.
Cheers
David
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-11-08 00:26
Message:
Logged In: YES
user_id=21627
I don't understand your remark " and allow for easy
compilation of extensions". Don't you need a copy of VC6 for
that? I don't understand how this is inherently different
from VC.NET 2003... only that Microsoft don't l
[ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler
Feature Requests item #1348719, was opened at 2005-11-04 23:58
Message generated for change (Comment added) made by kylotan
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470
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: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David McNab (davidmcnab)
Assigned to: Nobody/Anonymous (nobody)
Summary: please support the free visual studio sdk compiler
Initial Comment:
Hi,
I noticed, with some pain, that while pythons 2.1 to
2.3 are built with msvc6, and allow for easy
compilation of extensions.
However, the official binary distro of python2.4 for
windows is built with ms vs .net 2003 (version 7.1).
I've tried using the .net framework sdk compiler:
(http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en)
also the Visual C++ Toolkit:
(http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en)
but in both cases, distutils complains that it can't
find a suitable compiler ("error: Python was built with
version 7.1 of visual studio...").
I did some hacking on distutils/msvccompiler.py, and
noticed that this module is searching for certain
registry keys that are only written by the non-free
Visual Studio .NET 2003 compiler.
As it is, this situation imposes on developers a
deterrent against upgrading to python 2.4. There are
millions of msvc6 installations out there, but for
many, the cost of upgrading to msvs .net 2003 is
prohibitive.
I have considered building python2.4 from source using
msvc6 (I notice the project/workspace files are present
in the source), but feel this is unwise because I could
end up building extension modules that are
binary-incompatible with everyone else's python2.4
I (and countless others, I'm sure) would really
appreciate it if the python devs could rework things to
make it possible to build python2.4 extensions using
the free ms compilers mentioned above).
Cheers
david
--
Comment By: B Sizer (kylotan)
Date: 2005-11-08 10:07
Message:
Logged In: YES
user_id=206950
I was under the impression that it was possible to build
Python extensions using the free MS tools. Several people in
comp.lang.python have said as much. The original poster of
this bug may wish to check
http://www.vrplumber.com/programming/mstoolkit/ for further
details.
However, if it is now not the case, it is imperative that
someone addresses this. There is little point having a free
language if it requires a non-free compiler (in either sense
of the word) to build the extensions.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-11-08 08:03
Message:
Logged In: YES
user_id=21627
I disagree that one of the reasons to use VC 7.1 was that a
free Microsoft compiler was available - it was never one of
the reasons why I considered switching. Instead, the reasons
were:
- MS no longer ships VC6, so many users only had VC7.1 and
where requesting that this was used,
- VC 7.1 solves a few problems, most notably, IPv6 support
can be built with that compiler, but not with VC6, and
people where requesting IPv6 support on Windows.
So I agree that this request should be closed; I personally
have no plans to work on it for the next few years.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-08 06:21
Message:
Logged In: YES
user_id=341410
I'm not sure this request should be closed. One of the
reasons that Python 2.4 compilation was switched to the 7.1
compiler was that it was supposed to be possible to compile
Python and extension modules with the free .net compiler.
If users cannot compile with the free .net compiler right
now, then it seems that there is a bit of a problem.
--
Comment By: David McNab (davidmcnab)
Date: 2005-11-08 03:00
Message:
Logged In: YES
user_id=35522
Thank you for your reply.
In desperation, I started downloading an evaluation version
of msvs.net 2003 from bittorrent.
But before the download was even halfway complete, I had
already installed mingw on my winbox and sorted out the
intricacies of compiling 3rd party libs, and building
working python extensions, using only mingw.
As a result, I am now free of the shackles of proprietary MS
toolchains, and am comfortable with mingw - especially since
most of the multiplatform 3rd party libs I've seen offer
good build support for MinGW. All my extensions, and others'
extensions I'm using, are now building quite happily with MinGW.
>From this perspective, I no longer have interest in being
able to bu
[ python-Bugs-1348477 ] pydoc seems to run some scripts!
Bugs item #1348477, was opened at 2005-11-04 17:10 Message generated for change (Comment added) made by olly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 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: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Olly Betts (olly) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc seems to run some scripts! Initial Comment: Ubuntu 5.10 "Breezy Badger" Linux 2.6.10 Python 2.4.2 Running pydoc on some scripts (for example regextest.py as supplied with python) just seems to hang: pydoc /usr/share/doc/python2.4/examples/Demo/comparisons/regextest.py Feeding it EOF (Ctrl-D) makes it actually generate documentation and exit. But as well as showing the documentation, I get output which appears to be the script actually having run with itself as an argument! -- >Comment By: Olly Betts (olly) Date: 2005-11-08 11:09 Message: Logged In: YES user_id=14972 So I guess this is a bug report for that missing check in regextest.py in the python distribution. Is running a script which is missing this check an inherent feature of how pydoc works then? -- Comment By: Bob Ippolito (etrepum) Date: 2005-11-08 02:45 Message: Logged In: YES user_id=139309 Some scripts are broken, this one is missing a check to see if it's a script or a module: if __name__ == "__main__": main() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1341031 ] mmap does not accept length as 0
Bugs item #1341031, was opened at 2005-10-28 15:26
Message generated for change (Comment added) made by liturgist
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470
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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap does not accept length as 0
Initial Comment:
Creating an mmap object does not accept a length
parameter of zero on Linux FC4 and Cygwin. However, it
does on Windows XP.
$ ls -al t.dat
-rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat
$ python
Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import mmap
>>> fp = open('t.dat', 'rb')
>>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ)
Traceback (most recent call last):
File "", line 1, in ?
EnvironmentError: [Errno 22] Invalid argument
>>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ)
>>> b.size()
64
=
$ ls -al .profile
-rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile
$ python
Python 2.4.1 (#1, Jul 19 2005, 14:16:43)
[GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import mmap
>>> fp = open('.profile', 'rb')
>>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ)
Traceback (most recent call last):
File "", line 1, in ?
EnvironmentError: [Errno 22] Invalid argument
>>> b = mmap.mmap(fp.fileno(), 1920,
access=mmap.ACCESS_READ)
>>> b.size()
1920
--
>Comment By: liturgist (liturgist)
Date: 2005-11-08 09:16
Message:
Logged In: YES
user_id=197677
If the file was created by another process or specified as a
parameter, the code might not be free to write into it.
Asking os.stat() for the file size works on both platforms.
I have not tested on any other platform, but I do not see
any reason it would not work.
fp = open(fn, 'rb')
b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size,
access=mmap.ACCESS_READ)
Even if the file were just created, surely asking os.stat()
for the file size would not have more overhead than writing
to the file. Does it?
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-08 00:17
Message:
Logged In: YES
user_id=341410
On Windows and Linux, I have been able to map positive,
nonzero portions of files for quite some time. The only
use-case I can see in using an mmap of size 0 is if the file
was just created, and a user wanted to immediately resize
the mmap to be larger.
This can be worked-around with a simple fp.write('\0'),
followed by a mmap call with size 1. Resize as
desired/necessary.
--
Comment By: liturgist (liturgist)
Date: 2005-10-28 16:09
Message:
Logged In: YES
user_id=197677
It would be helpful to creating cross-platform code for all
platforms to have the same requirements. If this is marked
as Not-A-Bug, then how about changing it to a documentation
bug so that and example could be provided?
fp = open(fn, 'rb')
b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size,
access=mmap.ACCESS_READ)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1348477 ] pydoc seems to run some scripts!
Bugs item #1348477, was opened at 2005-11-04 12:10 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 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: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Olly Betts (olly) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc seems to run some scripts! Initial Comment: Ubuntu 5.10 "Breezy Badger" Linux 2.6.10 Python 2.4.2 Running pydoc on some scripts (for example regextest.py as supplied with python) just seems to hang: pydoc /usr/share/doc/python2.4/examples/Demo/comparisons/regextest.py Feeding it EOF (Ctrl-D) makes it actually generate documentation and exit. But as well as showing the documentation, I get output which appears to be the script actually having run with itself as an argument! -- >Comment By: Bob Ippolito (etrepum) Date: 2005-11-08 11:13 Message: Logged In: YES user_id=139309 pydoc imports modules, it doesn't run scripts. It just so happens that regextest isn't written correctly and does things it shouldn't do when imported. You should file a new bug on regextest.py, or at least change the summary accordingly... but a new bug would end up in the summary again, and would be more likely to be fixed. -- Comment By: Olly Betts (olly) Date: 2005-11-08 06:09 Message: Logged In: YES user_id=14972 So I guess this is a bug report for that missing check in regextest.py in the python distribution. Is running a script which is missing this check an inherent feature of how pydoc works then? -- Comment By: Bob Ippolito (etrepum) Date: 2005-11-07 21:45 Message: Logged In: YES user_id=139309 Some scripts are broken, this one is missing a check to see if it's a script or a module: if __name__ == "__main__": main() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1351545 ] win32serviceutil bug
Bugs item #1351545, was opened at 2005-11-08 17:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351545&group_id=5470 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: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Graber (tgraber_us) Assigned to: Nobody/Anonymous (nobody) Summary: win32serviceutil bug Initial Comment: When trying to call service restart or start, the following error message is received. The utility is not handling embeded spaces in the SERVICE_NAME. error: Traceback (most recent call last): File "C:\Python24\Tools\scripts\serviceinfo.py", line 23, in ? service_info(action, machine, service) File "C:\Python24\Tools\scripts\serviceinfo.py", line 11, in service_info win32serviceutil.RestartService(service, machine) File "C:\Python24\lib\site-packages\win32 \lib\win32serviceutil.py", line 409, in RestartService raise win32service.error, (hr, name, msg) pywintypes.error: (1060, 'OpenService', 'The specified service does not exist as an installed service.') Service entry on server using sc query: SERVICE_NAME: JDEdwards OneWorld XE B733 Queue DISPLAY_NAME: JDEdwards OneWorld XE B733 Queue TYPE : 110 WIN32_OWN_PROCESS (interactive) STATE : 4 RUNNING (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE: 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351545&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1341031 ] mmap does not accept length as 0
Bugs item #1341031, was opened at 2005-10-28 13:26
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470
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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap does not accept length as 0
Initial Comment:
Creating an mmap object does not accept a length
parameter of zero on Linux FC4 and Cygwin. However, it
does on Windows XP.
$ ls -al t.dat
-rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat
$ python
Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import mmap
>>> fp = open('t.dat', 'rb')
>>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ)
Traceback (most recent call last):
File "", line 1, in ?
EnvironmentError: [Errno 22] Invalid argument
>>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ)
>>> b.size()
64
=
$ ls -al .profile
-rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile
$ python
Python 2.4.1 (#1, Jul 19 2005, 14:16:43)
[GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import mmap
>>> fp = open('.profile', 'rb')
>>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ)
Traceback (most recent call last):
File "", line 1, in ?
EnvironmentError: [Errno 22] Invalid argument
>>> b = mmap.mmap(fp.fileno(), 1920,
access=mmap.ACCESS_READ)
>>> b.size()
1920
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-08 10:11
Message:
Logged In: YES
user_id=341410
According to the documentation, in Windows, passing a
'length' of 0 will map the entire file. On 'Unix', it does
not discuss what happens when you use a length of 0.
The behavior on undefined arguments in the case of linux
could almost be expected (though perhaps should be clarified
in documentation), and being that the 'cygwin' platform
isn't Windows (it's a unix-like environment in Windows),
expecting it to perform like Windows, is probably
Wasn't your bug report that you could not map 0 bytes from
the file, or that passing '0' did not do what you expected
on Linux and/or cygwin? If so, then maybe the documentation
should be updated.
To respond to "wouldn't os.stat(filename).st_size be good to
pass during mmap creation time?" Of course, I do that
myself, and I would expect most sane people to do the same.
os.fstat(fp.fileno()).st_size also works.
So, what is your bug report again, and why is this bug
report open?
--
Comment By: liturgist (liturgist)
Date: 2005-11-08 07:16
Message:
Logged In: YES
user_id=197677
If the file was created by another process or specified as a
parameter, the code might not be free to write into it.
Asking os.stat() for the file size works on both platforms.
I have not tested on any other platform, but I do not see
any reason it would not work.
fp = open(fn, 'rb')
b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size,
access=mmap.ACCESS_READ)
Even if the file were just created, surely asking os.stat()
for the file size would not have more overhead than writing
to the file. Does it?
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-07 22:17
Message:
Logged In: YES
user_id=341410
On Windows and Linux, I have been able to map positive,
nonzero portions of files for quite some time. The only
use-case I can see in using an mmap of size 0 is if the file
was just created, and a user wanted to immediately resize
the mmap to be larger.
This can be worked-around with a simple fp.write('\0'),
followed by a mmap call with size 1. Resize as
desired/necessary.
--
Comment By: liturgist (liturgist)
Date: 2005-10-28 14:09
Message:
Logged In: YES
user_id=197677
It would be helpful to creating cross-platform code for all
platforms to have the same requirements. If this is marked
as Not-A-Bug, then how about changing it to a documentation
bug so that and example could be provided?
fp = open(fn, 'rb')
b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size,
access=mmap.ACCESS_READ)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archi
[ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler
Feature Requests item #1348719, was opened at 2005-11-05 00:58
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470
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: Distutils
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: David McNab (davidmcnab)
Assigned to: Nobody/Anonymous (nobody)
Summary: please support the free visual studio sdk compiler
Initial Comment:
Hi,
I noticed, with some pain, that while pythons 2.1 to
2.3 are built with msvc6, and allow for easy
compilation of extensions.
However, the official binary distro of python2.4 for
windows is built with ms vs .net 2003 (version 7.1).
I've tried using the .net framework sdk compiler:
(http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en)
also the Visual C++ Toolkit:
(http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en)
but in both cases, distutils complains that it can't
find a suitable compiler ("error: Python was built with
version 7.1 of visual studio...").
I did some hacking on distutils/msvccompiler.py, and
noticed that this module is searching for certain
registry keys that are only written by the non-free
Visual Studio .NET 2003 compiler.
As it is, this situation imposes on developers a
deterrent against upgrading to python 2.4. There are
millions of msvc6 installations out there, but for
many, the cost of upgrading to msvs .net 2003 is
prohibitive.
I have considered building python2.4 from source using
msvc6 (I notice the project/workspace files are present
in the source), but feel this is unwise because I could
end up building extension modules that are
binary-incompatible with everyone else's python2.4
I (and countless others, I'm sure) would really
appreciate it if the python devs could rework things to
make it possible to build python2.4 extensions using
the free ms compilers mentioned above).
Cheers
david
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-11-08 19:51
Message:
Logged In: YES
user_id=21627
As the OP points out, you can use a free compiler (mingw).
I'm closing this report: if somebody with an actual, current
need has the wish that Python is changed in some precise and
verifiable way, please submit a new report. There is no
point in guessing what does and doesn't work.
People who are experimenting with this are encouraged to
propose patches, of course.
--
Comment By: B Sizer (kylotan)
Date: 2005-11-08 11:07
Message:
Logged In: YES
user_id=206950
I was under the impression that it was possible to build
Python extensions using the free MS tools. Several people in
comp.lang.python have said as much. The original poster of
this bug may wish to check
http://www.vrplumber.com/programming/mstoolkit/ for further
details.
However, if it is now not the case, it is imperative that
someone addresses this. There is little point having a free
language if it requires a non-free compiler (in either sense
of the word) to build the extensions.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-11-08 09:03
Message:
Logged In: YES
user_id=21627
I disagree that one of the reasons to use VC 7.1 was that a
free Microsoft compiler was available - it was never one of
the reasons why I considered switching. Instead, the reasons
were:
- MS no longer ships VC6, so many users only had VC7.1 and
where requesting that this was used,
- VC 7.1 solves a few problems, most notably, IPv6 support
can be built with that compiler, but not with VC6, and
people where requesting IPv6 support on Windows.
So I agree that this request should be closed; I personally
have no plans to work on it for the next few years.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-08 07:21
Message:
Logged In: YES
user_id=341410
I'm not sure this request should be closed. One of the
reasons that Python 2.4 compilation was switched to the 7.1
compiler was that it was supposed to be possible to compile
Python and extension modules with the free .net compiler.
If users cannot compile with the free .net compiler right
now, then it seems that there is a bit of a problem.
--
Comment By: David McNab (davidmcnab)
Date: 2005-11-08 04:00
Message:
Logged In: YES
user_id=35522
Thank you for your reply.
In desperation, I started downloading an evaluation version
of msvs.net 2003 from bittorrent.
But before the download was even hal
[ python-Bugs-1341031 ] mmap does not accept length as 0
Bugs item #1341031, was opened at 2005-10-28 15:26
Message generated for change (Comment added) made by liturgist
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470
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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap does not accept length as 0
Initial Comment:
Creating an mmap object does not accept a length
parameter of zero on Linux FC4 and Cygwin. However, it
does on Windows XP.
$ ls -al t.dat
-rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat
$ python
Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import mmap
>>> fp = open('t.dat', 'rb')
>>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ)
Traceback (most recent call last):
File "", line 1, in ?
EnvironmentError: [Errno 22] Invalid argument
>>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ)
>>> b.size()
64
=
$ ls -al .profile
-rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile
$ python
Python 2.4.1 (#1, Jul 19 2005, 14:16:43)
[GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import mmap
>>> fp = open('.profile', 'rb')
>>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ)
Traceback (most recent call last):
File "", line 1, in ?
EnvironmentError: [Errno 22] Invalid argument
>>> b = mmap.mmap(fp.fileno(), 1920,
access=mmap.ACCESS_READ)
>>> b.size()
1920
--
>Comment By: liturgist (liturgist)
Date: 2005-11-08 13:15
Message:
Logged In: YES
user_id=197677
The bug report is still right here in this listing.
What are the possible solutions?
1) Not have the Windows version map the entire file length.
Could break existing code, so not likely.
2) Have the UNIX version map the entire file when a length
of 0 is passed. Since the fp is passed, the code can get
length from os.fstat(fp.fileno()).st_size. There could be
some code handling this exception whose operation would
change if this modification were made.
3) Modify the documentation to be more explicit about valid
and invalid length values on the UNIX version. Providing
and example using fp.fstat(fp.fileno()).st_size would be
very helpful.
I see the third option as the only viable path at this
point. Letting the Windows path use zero as a magic
indicator is an impediment to writing cross-platform code.
An example in the documentation of how it could be done is
sorely needed.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-08 12:11
Message:
Logged In: YES
user_id=341410
According to the documentation, in Windows, passing a
'length' of 0 will map the entire file. On 'Unix', it does
not discuss what happens when you use a length of 0.
The behavior on undefined arguments in the case of linux
could almost be expected (though perhaps should be clarified
in documentation), and being that the 'cygwin' platform
isn't Windows (it's a unix-like environment in Windows),
expecting it to perform like Windows, is probably
Wasn't your bug report that you could not map 0 bytes from
the file, or that passing '0' did not do what you expected
on Linux and/or cygwin? If so, then maybe the documentation
should be updated.
To respond to "wouldn't os.stat(filename).st_size be good to
pass during mmap creation time?" Of course, I do that
myself, and I would expect most sane people to do the same.
os.fstat(fp.fileno()).st_size also works.
So, what is your bug report again, and why is this bug
report open?
--
Comment By: liturgist (liturgist)
Date: 2005-11-08 09:16
Message:
Logged In: YES
user_id=197677
If the file was created by another process or specified as a
parameter, the code might not be free to write into it.
Asking os.stat() for the file size works on both platforms.
I have not tested on any other platform, but I do not see
any reason it would not work.
fp = open(fn, 'rb')
b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size,
access=mmap.ACCESS_READ)
Even if the file were just created, surely asking os.stat()
for the file size would not have more overhead than writing
to the file. Does it?
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-08 00:17
Message:
Logged In: YES
user_id=341410
On Windows and Linux, I have been able to map positive,
nonzero portions of files for quite some time. The only
use-case I can see in using an mmap
[ python-Bugs-1341031 ] mmap does not accept length as 0
Bugs item #1341031, was opened at 2005-10-28 13:26
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470
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: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap does not accept length as 0
Initial Comment:
Creating an mmap object does not accept a length
parameter of zero on Linux FC4 and Cygwin. However, it
does on Windows XP.
$ ls -al t.dat
-rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat
$ python
Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import mmap
>>> fp = open('t.dat', 'rb')
>>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ)
Traceback (most recent call last):
File "", line 1, in ?
EnvironmentError: [Errno 22] Invalid argument
>>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ)
>>> b.size()
64
=
$ ls -al .profile
-rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile
$ python
Python 2.4.1 (#1, Jul 19 2005, 14:16:43)
[GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import mmap
>>> fp = open('.profile', 'rb')
>>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ)
Traceback (most recent call last):
File "", line 1, in ?
EnvironmentError: [Errno 22] Invalid argument
>>> b = mmap.mmap(fp.fileno(), 1920,
access=mmap.ACCESS_READ)
>>> b.size()
1920
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-08 11:37
Message:
Logged In: YES
user_id=341410
You could just pass fp.fstat(fp.fileno()).st_size to all of
your instances, not just the unix ones.
Right now, Python exposes the underlying mmap
implementation. Windows automatically handles the
statting/etc., for using the full size of the file in an
mmap. Other platforms don't.
While it would seem reasonable to have the unix specific
implementation automatically perform an os.fstat(), actually
calling the requisite code in os from mmapmodule.c is a pain
in the ass (in my experience), and duplicating the code in
mmapmodule.c is a poor idea.
I would suggest you offer a documentation patch in the patch
tracker to state the behavior of Unix mmap and suggested
cross-platform workarounds.
--
Comment By: liturgist (liturgist)
Date: 2005-11-08 11:15
Message:
Logged In: YES
user_id=197677
The bug report is still right here in this listing.
What are the possible solutions?
1) Not have the Windows version map the entire file length.
Could break existing code, so not likely.
2) Have the UNIX version map the entire file when a length
of 0 is passed. Since the fp is passed, the code can get
length from os.fstat(fp.fileno()).st_size. There could be
some code handling this exception whose operation would
change if this modification were made.
3) Modify the documentation to be more explicit about valid
and invalid length values on the UNIX version. Providing
and example using fp.fstat(fp.fileno()).st_size would be
very helpful.
I see the third option as the only viable path at this
point. Letting the Windows path use zero as a magic
indicator is an impediment to writing cross-platform code.
An example in the documentation of how it could be done is
sorely needed.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-11-08 10:11
Message:
Logged In: YES
user_id=341410
According to the documentation, in Windows, passing a
'length' of 0 will map the entire file. On 'Unix', it does
not discuss what happens when you use a length of 0.
The behavior on undefined arguments in the case of linux
could almost be expected (though perhaps should be clarified
in documentation), and being that the 'cygwin' platform
isn't Windows (it's a unix-like environment in Windows),
expecting it to perform like Windows, is probably
Wasn't your bug report that you could not map 0 bytes from
the file, or that passing '0' did not do what you expected
on Linux and/or cygwin? If so, then maybe the documentation
should be updated.
To respond to "wouldn't os.stat(filename).st_size be good to
pass during mmap creation time?" Of course, I do that
myself, and I would expect most sane people to do the same.
os.fstat(fp.fileno()).st_size also works.
So, what is your bug report again, and why is this bug
report open?
--
Comment By: liturgist (liturgist)
Date: 2005-11-08 07:1
[ python-Bugs-1351692 ] Switch to make pprint.pprint display ints and longs in hex
Bugs item #1351692, was opened at 2005-11-08 13:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351692&group_id=5470 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: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x1,0x10010)) # and this: [0x1L, 0x10001L, 0x10002L, 0x10003L, 0x10004L, 0x10005L, 0x10006L, 0x10007L, 0x10008L, 0x10009L, 0x1000AL, 0x1000BL, 0x1000CL, 0x1000DL, 0x1000EL, 0x1000FL] >>> Thanks, --MH -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351692&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1351707 ] zipimport produces incomplete IOError instances
Bugs item #1351707, was opened at 2005-11-08 16:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&group_id=5470 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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport produces incomplete IOError instances Initial Comment: The get_data() method on the zipimport.zipimporter object produces IOError exceptions that only have an error message. It should use PyErr_SetFromErrnoWithFilename() instead of PyErr_Format() for IOError exceptions. This should be fixed for both Python 2.4.3 and 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1324176 ] fix for ms stdio tables
Feature Requests item #1324176, was opened at 2005-10-11 22:46
Message generated for change (Comment added) made by kotk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470
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: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vambola Kotkas (kotk)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for ms stdio tables
Initial Comment:
Hopefully its right tracker for such request.
I am mainly C++ developer but recently it become
desirable to embed python as python24.dll into my
existing app to make some of features scriptable. I don't
want it to have any visible UI or to deal with GUI or the
like.
However ms has made it so that each dll has its own rtl
ioinfo table that is loaded at program start. In other
words .. some other dll or exe itself cannot simply
redirect python24.dll stdin stdout stderr runtime. It
probably has to be done from within python for these
redirections to really take effect. I think it is actually very
simple to fix that dll problem on C level by making some
callable thing into python24.dll that does nothing but
fixes dlls ioinfo table to contain real stdio for the
process. Example:
#include
#include
void Py_FixMSstdioPITA(void)
{
/*fix stdin*/
HANDLE hReal = GetStdHandle
(STD_INPUT_HANDLE);
HANDLE hKnown = _get_osfhandle(_fileno
(stdin));
int Number;
if (hReal != hKnown && hReal !=
INVALID_HANDLE_VALUE)
{
Number = _open_osfhandle
(hReal, _O_BINARY|_O_RDONLY);
_dup2(Number,_fileno(stdin));
}
/*fix stdout*/
hReal = GetStdHandle
(STD_OUTPUT_HANDLE);
hKnown = _get_osfhandle(_fileno(stdout));
if (hReal != hKnown && hReal !=
INVALID_HANDLE_VALUE)
{
Number = _open_osfhandle
(hReal, _O_BINARY|_O_WRONLY);
_dup2(Number,_fileno(stdout));
}
/*fix stderr*/
hReal = GetStdHandle
(STD_ERROR_HANDLE);
hKnown = _get_osfhandle(_fileno(stderr));
if (hReal != hKnown && hReal !=
INVALID_HANDLE_VALUE)
{
Number = _open_osfhandle
(hReal, _O_BINARY|_O_WRONLY);
_dup2(Number,_fileno(stderr));
}
}
I want just call it from outside after any io redirection
done in my code ... so python has his stdio all right and
done.
If something like this is already implemented there in
similar or some other way then sorry didnt find it. If its
agains general python ideology of some sort then sorry
didnt know of it. Let me know please.
Best wishes,
Vambola Kotkas
--
>Comment By: Vambola Kotkas (kotk)
Date: 2005-11-09 02:32
Message:
Logged In: YES
user_id=698026
Yes, first i did use that function in my application but it
surprizingly did not help. Googling about python IO
redirection indicated that some others have had similar
difficulties. So i debugged around and noticed that the very
table that my above function was meant to fix (possibly right
that it was named __pioinfo ... MS maps windows handles to
CRT FILE pointers there) had various locations. Maybe it was
because compiler /M option differed between the module
where i did IO redirection and with what python24.dll was
compiled. Like... say msvcr71d.dll was loaded for it but
msvcr71.dll loaded for python24.dll? :-/ I check it over again
when i get time.
Thanks.
--
Comment By: Vambola Kotkas (kotk)
Date: 2005-11-09 02:32
Message:
Logged In: YES
user_id=698026
Thank you.
I've moved this feature request to PEP 42, "Feature Requests".
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-11-08 01:36
Message:
Logged In: YES
user_id=21627
I don't understand the remark "has its own rtl ioinfo
table". ioinfo is a type - what table are you referring to?
If you are talking about __pioinfo: this certainly isn't
defined per DLL. Instead, each copy of the MS C runtime has
one copy. Python (in 2.4) uses msvcr71.dll. So as long as
you also link against msvcr71.dll, you can modify the CRT
that Python uses without modifying python24.dll.
IOW, you can use your function in your application, and be done.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1324176 ] fix for ms stdio tables
Feature Requests item #1324176, was opened at 2005-10-11 22:46
Message generated for change (Comment added) made by kotk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470
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: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vambola Kotkas (kotk)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for ms stdio tables
Initial Comment:
Hopefully its right tracker for such request.
I am mainly C++ developer but recently it become
desirable to embed python as python24.dll into my
existing app to make some of features scriptable. I don't
want it to have any visible UI or to deal with GUI or the
like.
However ms has made it so that each dll has its own rtl
ioinfo table that is loaded at program start. In other
words .. some other dll or exe itself cannot simply
redirect python24.dll stdin stdout stderr runtime. It
probably has to be done from within python for these
redirections to really take effect. I think it is actually very
simple to fix that dll problem on C level by making some
callable thing into python24.dll that does nothing but
fixes dlls ioinfo table to contain real stdio for the
process. Example:
#include
#include
void Py_FixMSstdioPITA(void)
{
/*fix stdin*/
HANDLE hReal = GetStdHandle
(STD_INPUT_HANDLE);
HANDLE hKnown = _get_osfhandle(_fileno
(stdin));
int Number;
if (hReal != hKnown && hReal !=
INVALID_HANDLE_VALUE)
{
Number = _open_osfhandle
(hReal, _O_BINARY|_O_RDONLY);
_dup2(Number,_fileno(stdin));
}
/*fix stdout*/
hReal = GetStdHandle
(STD_OUTPUT_HANDLE);
hKnown = _get_osfhandle(_fileno(stdout));
if (hReal != hKnown && hReal !=
INVALID_HANDLE_VALUE)
{
Number = _open_osfhandle
(hReal, _O_BINARY|_O_WRONLY);
_dup2(Number,_fileno(stdout));
}
/*fix stderr*/
hReal = GetStdHandle
(STD_ERROR_HANDLE);
hKnown = _get_osfhandle(_fileno(stderr));
if (hReal != hKnown && hReal !=
INVALID_HANDLE_VALUE)
{
Number = _open_osfhandle
(hReal, _O_BINARY|_O_WRONLY);
_dup2(Number,_fileno(stderr));
}
}
I want just call it from outside after any io redirection
done in my code ... so python has his stdio all right and
done.
If something like this is already implemented there in
similar or some other way then sorry didnt find it. If its
agains general python ideology of some sort then sorry
didnt know of it. Let me know please.
Best wishes,
Vambola Kotkas
--
>Comment By: Vambola Kotkas (kotk)
Date: 2005-11-09 05:12
Message:
Logged In: YES
user_id=698026
Right, python24.dll is compiled with /MD option. I was testing
it under debug version and that is compiled with /MDd option.
When i change the compiler option /MDd to /MD in my apps
debug version then the function works outside too.
Thanks
--
Comment By: Vambola Kotkas (kotk)
Date: 2005-11-09 02:32
Message:
Logged In: YES
user_id=698026
Yes, first i did use that function in my application but it
surprizingly did not help. Googling about python IO
redirection indicated that some others have had similar
difficulties. So i debugged around and noticed that the very
table that my above function was meant to fix (possibly right
that it was named __pioinfo ... MS maps windows handles to
CRT FILE pointers there) had various locations. Maybe it was
because compiler /M option differed between the module
where i did IO redirection and with what python24.dll was
compiled. Like... say msvcr71d.dll was loaded for it but
msvcr71.dll loaded for python24.dll? :-/ I check it over again
when i get time.
Thanks.
--
Comment By: Vambola Kotkas (kotk)
Date: 2005-11-09 02:32
Message:
Logged In: YES
user_id=698026
Thank you.
I've moved this feature request to PEP 42, "Feature Requests".
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-11-08 01:36
Message:
Logged In: YES
user_id=21627
I don't understand the remark "has its own rtl ioinfo
table". ioinfo is a type - what table are you referring to?
If you are talking about __pioinfo: this certainly isn't
defined per DLL. Instead, each copy of the MS C runtime has
one copy. Python (in 2.4) uses msvcr71.dll. So as long as
you also link against msvcr71.dll, you can modify the CRT
that Python uses without modifying python24.dll.
IOW, you can use your function in your application, and be done.
-
[ python-Feature Requests-1324176 ] fix for ms stdio tables
Feature Requests item #1324176, was opened at 2005-10-11 21:46
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470
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: Windows
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Vambola Kotkas (kotk)
Assigned to: Nobody/Anonymous (nobody)
Summary: fix for ms stdio tables
Initial Comment:
Hopefully its right tracker for such request.
I am mainly C++ developer but recently it become
desirable to embed python as python24.dll into my
existing app to make some of features scriptable. I don't
want it to have any visible UI or to deal with GUI or the
like.
However ms has made it so that each dll has its own rtl
ioinfo table that is loaded at program start. In other
words .. some other dll or exe itself cannot simply
redirect python24.dll stdin stdout stderr runtime. It
probably has to be done from within python for these
redirections to really take effect. I think it is actually very
simple to fix that dll problem on C level by making some
callable thing into python24.dll that does nothing but
fixes dlls ioinfo table to contain real stdio for the
process. Example:
#include
#include
void Py_FixMSstdioPITA(void)
{
/*fix stdin*/
HANDLE hReal = GetStdHandle
(STD_INPUT_HANDLE);
HANDLE hKnown = _get_osfhandle(_fileno
(stdin));
int Number;
if (hReal != hKnown && hReal !=
INVALID_HANDLE_VALUE)
{
Number = _open_osfhandle
(hReal, _O_BINARY|_O_RDONLY);
_dup2(Number,_fileno(stdin));
}
/*fix stdout*/
hReal = GetStdHandle
(STD_OUTPUT_HANDLE);
hKnown = _get_osfhandle(_fileno(stdout));
if (hReal != hKnown && hReal !=
INVALID_HANDLE_VALUE)
{
Number = _open_osfhandle
(hReal, _O_BINARY|_O_WRONLY);
_dup2(Number,_fileno(stdout));
}
/*fix stderr*/
hReal = GetStdHandle
(STD_ERROR_HANDLE);
hKnown = _get_osfhandle(_fileno(stderr));
if (hReal != hKnown && hReal !=
INVALID_HANDLE_VALUE)
{
Number = _open_osfhandle
(hReal, _O_BINARY|_O_WRONLY);
_dup2(Number,_fileno(stderr));
}
}
I want just call it from outside after any io redirection
done in my code ... so python has his stdio all right and
done.
If something like this is already implemented there in
similar or some other way then sorry didnt find it. If its
agains general python ideology of some sort then sorry
didnt know of it. Let me know please.
Best wishes,
Vambola Kotkas
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-11-09 06:28
Message:
Logged In: YES
user_id=21627
It normally shouldn't happen that you get two copies of
msvcr71.dll. To analyse this problem, you should look at
your application in depends.exe; if it shows different
versions of the CRT, you lose. In your case, it would have
shown both msvcr71.dll and msvcr71d.dll, each having its own
notion of stdio.
Never ever mix different CRT versions. It will not only not
work; it may even crash.
Closing this as "works for me".
--
Comment By: Vambola Kotkas (kotk)
Date: 2005-11-09 04:12
Message:
Logged In: YES
user_id=698026
Right, python24.dll is compiled with /MD option. I was testing
it under debug version and that is compiled with /MDd option.
When i change the compiler option /MDd to /MD in my apps
debug version then the function works outside too.
Thanks
--
Comment By: Vambola Kotkas (kotk)
Date: 2005-11-09 01:32
Message:
Logged In: YES
user_id=698026
Yes, first i did use that function in my application but it
surprizingly did not help. Googling about python IO
redirection indicated that some others have had similar
difficulties. So i debugged around and noticed that the very
table that my above function was meant to fix (possibly right
that it was named __pioinfo ... MS maps windows handles to
CRT FILE pointers there) had various locations. Maybe it was
because compiler /M option differed between the module
where i did IO redirection and with what python24.dll was
compiled. Like... say msvcr71d.dll was loaded for it but
msvcr71.dll loaded for python24.dll? :-/ I check it over again
when i get time.
Thanks.
--
Comment By: Vambola Kotkas (kotk)
Date: 2005-11-09 01:32
Message:
Logged In: YES
user_id=698026
Thank you.
I've moved this feature request to PEP 42, "Feature Requests".
--
[ python-Bugs-1351545 ] win32serviceutil bug
Bugs item #1351545, was opened at 2005-11-08 09:52 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351545&group_id=5470 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: Python Library >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Graber (tgraber_us) >Assigned to: Neal Norwitz (nnorwitz) Summary: win32serviceutil bug Initial Comment: When trying to call service restart or start, the following error message is received. The utility is not handling embeded spaces in the SERVICE_NAME. error: Traceback (most recent call last): File "C:\Python24\Tools\scripts\serviceinfo.py", line 23, in ? service_info(action, machine, service) File "C:\Python24\Tools\scripts\serviceinfo.py", line 11, in service_info win32serviceutil.RestartService(service, machine) File "C:\Python24\lib\site-packages\win32 \lib\win32serviceutil.py", line 409, in RestartService raise win32service.error, (hr, name, msg) pywintypes.error: (1060, 'OpenService', 'The specified service does not exist as an installed service.') Service entry on server using sc query: SERVICE_NAME: JDEdwards OneWorld XE B733 Queue DISPLAY_NAME: JDEdwards OneWorld XE B733 Queue TYPE : 110 WIN32_OWN_PROCESS (interactive) STATE : 4 RUNNING (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE: 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-08 22:44 Message: Logged In: YES user_id=33168 This bug is in win32all (win32com or whatever the package is called). It's not a standard part of Python. You will need to file a bug report with whoever distributes the package. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351545&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1350188 ] "setdlopenflags" leads to crash upon "import"
Bugs item #1350188, was opened at 2005-11-07 03:26
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470
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: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: John Pye (jdpipe)
Assigned to: Neal Norwitz (nnorwitz)
Summary: "setdlopenflags" leads to crash upon "import"
Initial Comment:
While playing around with correct values of the
dl.RTLD_ flags in the dl module, I found that I
could crash python as follows:
python -v
[...]
>>> import sys; import dl
dlopen("/usr/lib/python2.4/lib-dynload/dlmodule.so", 2);
import dl # dynamically loaded from
/usr/lib/python2.4/lib-dynload/dlmodule.so
>>> sys.setdlopenflags(15)
>>> import ascend
# ascend.pyc matches ascend.py
import ascend # precompiled from ascend.pyc
dlopen("./_ascend.so", f);
python: Objects/stringobject.c:105:
PyString_FromString: Assertion `str != ((void *)0)' failed.
Aborted
JP
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-08 23:03
Message:
Logged In: YES
user_id=33168
Thanks!
I don't have ascend.so. I tried importing time and it
crashed hard. I checked in a fix for me. Let me know if it
doesn't fix the problem for you.
Committed revision 41412.
Committed revision 41413. (2.4)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1348477 ] pydoc seems to run some scripts!
Bugs item #1348477, was opened at 2005-11-04 09:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 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: Demos and Tools Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Olly Betts (olly) >Assigned to: Neal Norwitz (nnorwitz) Summary: pydoc seems to run some scripts! Initial Comment: Ubuntu 5.10 "Breezy Badger" Linux 2.6.10 Python 2.4.2 Running pydoc on some scripts (for example regextest.py as supplied with python) just seems to hang: pydoc /usr/share/doc/python2.4/examples/Demo/comparisons/regextest.py Feeding it EOF (Ctrl-D) makes it actually generate documentation and exit. But as well as showing the documentation, I get output which appears to be the script actually having run with itself as an argument! -- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-08 23:09 Message: Logged In: YES user_id=33168 I'm feeling generous tonight. :-) Thanks for the report. I updated regextest program. Committed revision 41414. Committed revision 41415. (2.4) -- Comment By: Bob Ippolito (etrepum) Date: 2005-11-08 08:13 Message: Logged In: YES user_id=139309 pydoc imports modules, it doesn't run scripts. It just so happens that regextest isn't written correctly and does things it shouldn't do when imported. You should file a new bug on regextest.py, or at least change the summary accordingly... but a new bug would end up in the summary again, and would be more likely to be fixed. -- Comment By: Olly Betts (olly) Date: 2005-11-08 03:09 Message: Logged In: YES user_id=14972 So I guess this is a bug report for that missing check in regextest.py in the python distribution. Is running a script which is missing this check an inherent feature of how pydoc works then? -- Comment By: Bob Ippolito (etrepum) Date: 2005-11-07 18:45 Message: Logged In: YES user_id=139309 Some scripts are broken, this one is missing a check to see if it's a script or a module: if __name__ == "__main__": main() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
