ok, there's a solution for that - the gist of the solution is already
implemented in things like Apache Runtime and Apache2 (modules), and
is an extremely common standard technique implemented in OS kernels.
the old school name for it is vector tables.
We might be able to do that in Python
ironically, i started out with the intent of going for python2N.dll
interoperability. then i noticed that all the other mingw ports
dropped the total-inclusion-of-all-modules because you _can_.
What modules are built in and what modules are external doesn't affect
interoperability wrt.
Luke Kenneth Casson Leighton wrote:
[SNIP]
python.exe (say, the official one) loads
python25.dll. Then, an import is made of a ming-wine extension, say
foo.pyd, which is linked with libpython2.5.dll, which then gets loaded.
Voila, you have two interpreters in memory, with different type objects,
[SNIP]
No, Python 2.5 is linked with msvcr71.dll.
ehn? i don't see that anywhere in any PC/* files - i do see that
there's a dependency on .NET SDK 1.1 which uses msvcr71.dll
Take a look at PCbuild/pythoncore.vcproj. It says
Version=7.10
This is how you know VS 2003 was used to
Hello,
On Wed, Jan 21, 2009 at 22:07, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:
On Wed, Jan 21, 2009 at 7:42 PM, Martin v. Löwis mar...@v.loewis.de wrote:
sorry, martin - i thought the win32 builds generated python25.lib,
python25.dll
Correct.
and python25.def
No.
so as to fit
On Wed, Jan 21, 2009 at 9:13 PM, Martin v. Löwis mar...@v.loewis.de wrote:
ok, so - different from what's being generated by ./configure under
msys under wine or native win32 - what's being generated (libpython 2
. 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin
environment.
On Thu, Jan 22, 2009 at 9:18 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
or, is the .pyd loading a bit cleverer (or perhaps a bit less
cleverer) than i'm expecting it to be?
On Windows, you must turn on the --enable_shared option if you want to
build extension modules.
You could take
I can't comment on that, because I don't know what your port does.
Does it not produce a .dll containing the majority of Python?
no, it contains the minimal necessary amount of python modules,
exactly like when python is built using cygwin. actualy, there's a
few modules that _have_ to be
On Thu, Jan 22, 2009 at 6:43 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I can't comment on that, because I don't know what your port does.
Does it not produce a .dll containing the majority of Python?
no, it contains the minimal necessary amount of python modules,
exactly like when python
there are already no less than _four_ mingw ports of python, of varying
degrees.
* http://jove.prohosting.com/iwave/ipython/pyMinGW.html
Ok, this one builds pythonXY, so it tries to be compatible with the
official distribution (although it seems to link against MSVCRT.dll)
*
That doesn't really matter, I guess. An extension module build by your
port will either fail to load into the regular Python (if
libpython2.5.dll is not found), or load and then crash (because it uses
a different copy of the Python runtime). Likewise vice versa.
excellent, excellent that's
am i right?
You should test that. I'm not sure whether it will crash (in particular,
it might not on load), but it *might* crash, or fail in strange ways
(e.g. when it checks whether something is a string, and decides it is
not, because it is looking at the other PyString_Type)
and if
This doesn't seem to be distributing binaries.
sourceforge page. i checked the statistics, there don't seem to be
very many hits (sorry to hear that don, if you're reading this!) ok.
there _is_ a sourceforge page,... yep, downloads here:
On Thu, Jan 22, 2009 at 8:17 PM, Martin v. Löwis mar...@v.loewis.de wrote:
am i right?
You should test that. I'm not sure whether it will crash (in particular,
it might not on load), but it *might* crash, or fail in strange ways
(e.g. when it checks whether something is a string, and decides
On Thu, Jan 22, 2009 at 8:22 PM, Martin v. Löwis mar...@v.loewis.de wrote:
This doesn't seem to be distributing binaries.
sourceforge page. i checked the statistics, there don't seem to be
very many hits (sorry to hear that don, if you're reading this!) ok.
there _is_ a sourceforge
mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_
python25.dll (or libpython2.N.dll and python2N.dll) will they?
Of course they will! python.exe (say, the official one) loads
python25.dll. Then, an import is made of a ming-wine extension, say
foo.pyd, which is linked with
Luke Kenneth Casson Leighton wrote:
On Wed, Jan 21, 2009 at 9:13 PM, Martin v. Löwis mar...@v.loewis.de wrote:
ok, so - different from what's being generated by ./configure under
msys under wine or native win32 - what's being generated (libpython 2
. 5 . a and libpython 2 . 5 . dll . a) is
Luke Kenneth Casson Leighton wrote:
version. I hope that users will understand that it is disjoint from
the python.org version (as they seem to understand fine for the
Cygwin build, which already picks up its extension modules also from
a disjoint location, which helps to keep the two separate).
On Thu, Jan 22, 2009 at 9:09 PM, Martin v. Löwis mar...@v.loewis.de wrote:
mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_
python25.dll (or libpython2.N.dll and python2N.dll) will they?
Of course they will!
yeah, silly - i worked that out juust after i pressed send.
On Fri, Jan 23, 2009 at 6:36 AM, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:
On Thu, Jan 22, 2009 at 9:09 PM, Martin v. Löwis mar...@v.loewis.de wrote:
mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_
python25.dll (or libpython2.N.dll and python2N.dll) will they?
On Thu, Jan 22, 2009 at 10:16 PM, Mark Hammond skippy.hamm...@gmail.com wrote:
On 23/01/2009 7:01 AM, Luke Kenneth Casson Leighton wrote:
That doesn't really matter, I guess. An extension module build by your
port will either fail to load into the regular Python (if
libpython2.5.dll is not
It only becomes a problem when someone wants to both support Windows
users of their extension modules with pre-built binaries, but *also*
doesn't want to set up the appropriate environment for building such
binaries (currently a minimum bar of Visual Studio Express on a Windows
VM instance).
On Tue, Jan 20, 2009 at 9:19 PM, Martin v. Löwis mar...@v.loewis.de wrote:
That's a non-starter for anyone who incorporates Python in an existing
MSVC-based development environment.
surely incorporating libpython2.5.dll.a or libpython2.6.dll.a, along
with the .def and the importlib that's
next task: beat the crap out of libmsvcr80.a and /mingw/include/*.h,
repeat until success.
https://sourceforge.net/tracker/index.php?func=detailaid=2134161group_id=2435atid=352435
roumen, it looks like you've been and done that, already - thank you!
sorry, martin - i thought the win32 builds generated python25.lib,
python25.dll
Correct.
and python25.def
No.
so as to fit into the 8.3 filename convention.
No. It generates python25.lib because that's the import library
for python25.dll. It calls it python25.dll because the lib prefix
On Wed, Jan 21, 2009 at 7:42 PM, Martin v. Löwis mar...@v.loewis.de wrote:
sorry, martin - i thought the win32 builds generated python25.lib,
python25.dll
Correct.
and python25.def
No.
so as to fit into the 8.3 filename convention.
No. It generates python25.lib because that's the
ok, so - different from what's being generated by ./configure under
msys under wine or native win32 - what's being generated (libpython 2
. 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin
environment.
therefore, there's absolutely no doubt that the two are completely
folks, hi,
this is a fairly important issue for python development
interoperability - martin mentioned that releases of mingw-compiled
python, if done with a non-interoperable version of msvcrt, would
cause much mayhem.
well, compiling python on mingw with msvcr80 _can_ be done; using it
can also
On Tue, Jan 20, 2009 at 08:02, Luke Kenneth Casson Leighton
luke.leigh...@googlemail.com wrote:
of course - if python for win32 ENTIRELY DROPPED msvc as a development
platform, and went for an entirely free software development
toolchain, then this problem goes away.
That's a non-starter for
Tim Lesher wrote:
On Tue, Jan 20, 2009 at 08:02, Luke Kenneth Casson Leighton
luke.leigh...@googlemail.com wrote:
of course - if python for win32 ENTIRELY DROPPED msvc as a development
platform, and went for an entirely free software development
toolchain, then this problem goes away.
Luke Kenneth Casson Leighton schrieb:
of course - if python for win32 ENTIRELY DROPPED msvc as a development
platform, and went for an entirely free software development
toolchain, then this problem goes away.
thoughts, anyone?
That's not going to happen anytime soon. As long as Microsoft
On Tue, Jan 20, 2009 at 1:11 PM, Tim Lesher tles...@gmail.com wrote:
On Tue, Jan 20, 2009 at 08:02, Luke Kenneth Casson Leighton
luke.leigh...@googlemail.com wrote:
of course - if python for win32 ENTIRELY DROPPED msvc as a development
platform, and went for an entirely free software
On Tue, Jan 20, 2009 at 6:18 AM, Luke Kenneth Casson Leighton
l...@lkcl.net wrote:
yeah they said the same thing about gas ovens, too. not the nazi
gas ovens, the phrase my mother used to say if someone stuck their
head in a gas oven, would you do the same?.
I don't know who is forcing you
Luke Kenneth Casson Leighton wrote:
i'd say great - but given a choice of impressive profile guided
optimisation plus a proprietary compiler, proprietary operating system
_and_ being forced to purchase a system _capable_ of running said
proprietary compiler, said proprietary operating system,
That's a non-starter for anyone who incorporates Python in an existing
MSVC-based development environment.
surely incorporating libpython2.5.dll.a or libpython2.6.dll.a, along
with the .def and the importlib that's generated with dlldump, unless
i'm missing something, would be a simple
Luke Kenneth Casson Leighton wrote:
this is a fairly important issue for python development
interoperability - martin mentioned that releases of mingw-compiled
python, if done with a non-interoperable version of msvcrt, would
cause much mayhem.
well, compiling python on mingw with msvcr80 _can_
36 matches
Mail list logo
