> Luke Kenneth Casson Leighton schrieb:
> > i mean... has anyone _written_ a third party module that returns
> > Py_None on a c-code module and had it compiled on windows?
> Lot's of people have written 3rd party extensions that work on Windows
> and can return a Py_No
> On Sun, Jan 25, 2009 at 9:01 AM, Matthieu Brucher
> wrote:
> > 2009/1/25 Luke Kenneth Casson Leighton :
> >> according to the wikipedia entry on dlls, dlls do not support data,
> >> only functions.
> >
> > What do you mean by "not support da
On Sun, Jan 25, 2009 at 3:55 PM, Roumen Petrov
wrote:
> Luke Kenneth Casson Leighton wrote:
>>>>
>>>> [SNIP]
>>>> Yes it is enough to encapsulate memory allocation and file functions
>>>> into
>>>> python shared library. The py
On Sun, Jan 25, 2009 at 4:33 PM, Luke Kenneth Casson Leighton
wrote:
>> Info: resolving __Py_NoneStruct by linking to __imp___Py_NoneStruct
>> (auto-import)
>
> by no small coincidence, every single module with which we've had
> difficulties in the mingw port - _sre
> here is a starting list of data items which will require "getter"
> functions, found just by creating a posixmodule.pyd:
>
> Info: resolving __Py_NoneStruct by linking to __imp___Py_NoneStruct
> (auto-import)
by no small coincidence, every single module with which we've had
difficulties in the
On Sun, Jan 25, 2009 at 3:58 PM, Luke Kenneth Casson Leighton
wrote:
> according to the wikipedia entry on dlls, dlls do not support data,
> only functions. which would explain two things:
> 1) why certain modules are forcibly linked into pythonNN.dll
> 2) why attempts to move
according to the wikipedia entry on dlls, dlls do not support data,
only functions. which would explain two things:
1) why certain modules are forcibly linked into pythonNN.dll
2) why attempts to move them out of pythonNN.dll cause runtime crashes.
so i will continue the experiment, and remove all
> Have you made some benchmarks like pystone?
> Cheers,
> Cesare
Cesare, hi, thanks for responding: unfortunately, there's absolutely
no point in making any benchmark figures under an emulated environment
which does things like take 2 billion instruction cycles to start up a
program named "c:/msy
> decoupling posixmodule.c from pythonNN.dll leaves the possibility to
> make python independent of msvcrt versioning.
>
> it would need to be a custom-compiled .pyd module, due to the early
> dependency.
>
> i'll see if this is possible.
i'd added PyExc_OSError, for example, as data exported fro
>> [SNIP]
>> Yes it is enough to encapsulate memory allocation and file functions into
>> python shared library. The python provide memory allocation functions, but
>> not all modules use them. File functions are hiden by posixmodule and python
>> modules can't use them.
>
> except ... posixmodule
http://bugs.python.org/issue5046
mingw+msys port which was previously done against python-2.5.2 has
been brought forward to latest subversion r68884. the primary reason
for initially doing python 2.5.2 was to 1) "stay out of the way" of
primary python development 2) provide some hope for those pe
>> but basically, not only is this technique nothing new - it's in use in
>> Apache RunTime, FreeDCE, the NT Kernel, the Linux Kernel - but also
> This look like simple RPC implemantation.
yep.
> If I remember well SUN-RPC assign number to program, function, version.
yep - i forgot about that
On Fri, Jan 23, 2009 at 10:48 PM, Roumen Petrov
wrote:
>>> 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, w
On Fri, Jan 23, 2009 at 8:08 AM, "Martin v. Löwis" wrote:
>> 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
On Thu, Jan 22, 2009 at 10:16 PM, Mark Hammond 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
>
On Fri, Jan 23, 2009 at 6:36 AM, Luke Kenneth Casson Leighton
wrote:
> On Thu, Jan 22, 2009 at 9:09 PM, "Martin v. Löwis" wrote:
>>> mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_
>>> python25.dll (or libpython2.N.dll and python2N.dll)
On Thu, Jan 22, 2009 at 9:09 PM, "Martin v. Löwis" 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".
> python.e
On Thu, Jan 22, 2009 at 8:22 PM, "Martin v. Löwis" 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 page,... yep,
On Thu, Jan 22, 2009 at 8:17 PM, "Martin v. Löwis" 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 it is
> no
On Thu, Jan 22, 2009 at 7:40 PM, "Martin v. Löwis" wrote:
>> 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 distrib
> 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
> 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).
yes i made the default insta
On Thu, Jan 22, 2009 at 6:43 PM, "Martin v. Löwis" 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 is b
On Thu, Jan 22, 2009 at 9:18 AM, Amaury Forgeot d'Arc
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 the cygwin
On Wed, Jan 21, 2009 at 9:13 PM, "Martin v. Löwis" 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.
>>
>> ther
On Wed, Jan 21, 2009 at 7:42 PM, "Martin v. Löwis" 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 impor
> http://bugs.python.org/issue5010
correction: that's http://bugs.python.org/issue5026 apologies for the mix-up.
also,for the msvcrt80 build, it is _essential_ that you use a patched
version of mingw32-runtime, see:
https://sourceforge.net/tracker/index.php?func=detail&aid=2134161&group_id=2435&a
this is a progress report on compiling python using entirely free
software tools, no proprietary compilers or operating systems
involved, yet still linking and successfully running with msvcr80
assemblies. manifests and rc files, which are compiled to internal
resources, have been added.
various s
> next task: beat the crap out of libmsvcr80.a and /mingw/include/*.h,
> repeat until success.
https://sourceforge.net/tracker/index.php?func=detail&aid=2134161&group_id=2435&atid=352435
roumen, it looks like you've been and done that, already - thank you!
_
On Tue, Jan 20, 2009 at 9:19 PM, "Martin v. Löwis" 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 generate
> 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 instanc
could someone kindly send me the assembly files that are created by a
proprietary win32 build of python2.5, 2.6 and trunk, the ones used to
create the dll _and_ the python.exe
many thanks.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On Tue, Jan 20, 2009 at 1:11 PM, Tim Lesher wrote:
> On Tue, Jan 20, 2009 at 08:02, Luke Kenneth Casson Leighton
> wrote:
>> of course - if python for win32 ENTIRELY DROPPED msvc as a development
>> platform, and went for an entirely free software development
>> toolchain
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 b
folks, hi,
after some quiet advice i've tracked down a method for compiling
python2.5 using msvcr80 that _will_ actually work both under native
win32 and also under wine, but it's a _bit_ dodgy, as i couldn't track
down where you're supposed to put Microsoft.VC80.CRT, except in the
path of the appl
this was found as part of the regression tests, compiling python under
wine under msys with mingw32. test_maxint64 failed. i tracked it
down to the assumption that a long will fit into 32-bits, which
obviously... it won't! the simplest case is to add a test for the
length of the data string bein
folks, hi,
http://bugs.winehq.org/show_bug.cgi?id=16982 related to this:
from array import array
TESTFN = "testfile.txt"
def fail(x):
print x
testlines = [
"spam, spam and eggs\n",
"eggs, spam, ham and spam\n",
"saussages, spam, spam and eggs\n",
"spam, ham, spam and eggs\n"
> About 5 test fail in emulated environment due bugs in emulator.
oh - nearly forgot: several of the ctypes tests fail quite spectacularly :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
hiya roumen, good to hear from you - i've been merging in the work
that you did, on mingw native-and-cross compiles. got a couple of
questions, will post them in the bugreport ok?
On Sat, Jan 17, 2009 at 3:16 PM, Roumen Petrov
wrote:
> Luke Kenneth Casson Leighton wrote:
> [SNIP
http://bugs.python.org/issue4956
uhn... weird bug, totally left-field scenario (using python under msys
under wine under linux) but this rather strange scenario has a
situation where loading the filename from the command line cannot be
done until _after_ PyInitialize is called. prior to PyInitial
> practical decision, due to /bin/sh.exe messing around and stopping
> python.exe from running! (under cmd.exe it's fine. i have to do a
> bit more investigation:
http://bugs.python.org/issue4956
found it.
___
Python-Dev mailing list
Python-Dev@python
no, the above subject-line is not a joke: i really _have_ successfully
built python2.5.2 by installing wine on linux, then msys under wine,
and then mingw32 compiler - no, not the linux mingw32-cross-compiler,
the _native_ mingw32 compiler that runs under msys, and then hacking
things into submissi
On Thu, Jan 8, 2009 at 9:07 PM, "Martin v. Löwis" wrote:
>> i'd just ... much rather be completely independent of proprietary
>> software when it comes to building free software.
>
> I guess my question is then: why do you want to use Windows in the
> first place?
ha ha :) the same question wa
> next bug: distutils.sysconfig.get_config_var('srcdir') is returning None (!!)
ok ... actually, that's correct. oops.
sysconfig.get_config_vars() only returns these, on win32:
{'EXE': '.exe', 'exec_prefix': 'Z:\\mnt\\src\\python2.5-2.5.2',
'LIBDEST': 'Z:\\mnt\\src\\python2.5-2.5.2\\Lib', 'pr
> anyway, i'm floundering around a bit and making a bit of a mess of the
> code, looking for where LONG_MAX is messing up.
fixed with this:
PyObject *
PyInt_FromSsize_t(Py_ssize_t ival)
{
if ((long)ival >= (long)LONG_MIN && (long)ival <= (long)LONG_MAX)
{
return PyInt_FromLong((l
On Thu, Jan 8, 2009 at 1:11 PM, David Cournapeau wrote:
> On Thu, Jan 8, 2009 at 9:42 PM, Simon Cross
> wrote:
>> On Sat, Jan 3, 2009 at 11:22 PM, Luke Kenneth Casson Leighton
>> wrote:
>>> secondly, i want a python25.lib which i can use to cross-compile
>>
On Thu, Jan 8, 2009 at 12:42 PM, Simon Cross
wrote:
> On Sat, Jan 3, 2009 at 11:22 PM, Luke Kenneth Casson Leighton
> wrote:
>> secondly, i want a python25.lib which i can use to cross-compile
>> modules for poor windows users _despite_ sticking to my principles and
>> k
On Sat, Jan 3, 2009 at 9:22 PM, Luke Kenneth Casson Leighton
wrote:
> hey, has anyone investigated compiling python2.5 using winegcc, under wine?
some people might find this kind of thing amusing. it's considered in
very obtuse circles to be "progress"... :)
l...@gonzalez:
hey, has anyone investigated compiling python2.5 using winegcc, under wine?
i'm presently working my way through it, just for kicks, and was
wondering if anyone would like to pitch in or stare at the mess under
a microscope.
it's not as crazed as it sounds. cross-compiling python2.5 for win32
wit
http://groups.google.com/group/pyjamas-dev/browse_thread/thread/5e14ac70508112e5/53ca0b8190f35e21?hl=en#53ca0b8190f35e21
may be of interest to some people.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
my apologies, i found the issue "closed" after doing a search for my
own work, requiring (again) the telnetlib code for yet another
project.
since 2001, the work done has been reimplemented time and time again,
by different individuals, in different projects, in different ways,
all solving exactly
51 matches
Mail list logo
