Re: How to decompile an exe file compiled by py2exe?
Leo Jay wrote: > Dear All, > > I lost my source code because of my incaution. > so anyone can tell me how to decompile the exe file compiled by py2exe? > > Thanks. > > -- > Best Regards, > Leo Jay In older versions of py2exe (haven't tried it for new ones) I only had to drag the py2exe created file to my zip archiever program window. That somehow got the program to treat the py2exe application as a zip archieve effectively decompressing it right there in the window of the program. This enabled me to extract the files if I wish to do so to any place I want. This is also valid, I noted, for the binary distributions created for windows by the distutils. -- http://mail.python.org/mailman/listinfo/python-list
ANN: pyMinGW support for Python 2.4.2 (final) is available
This is to inform those interested in compiling Python in MinGW that an updated version of pyMinGW is now available. Get it from here: http://jove.prohosting.com/iwave/ipython/pyMinGW.html Regards Khalid -- http://mail.python.org/mailman/listinfo/python-list
Re: pyMinGW support for Python 2.4.2 (final) is available
This is a free site. To generate ad revenues, I suppose, they make those zip files available through multiple clicking, so as to eliminate direct linking. And who can blame them. Using Firefox, I am able to download the zip files after exactly clicking on the page you mention twice, pausing between clicks until the page loads. I think they set a cookie or something and then test it is there. Using IE6 the matter is more involved. I have to click that link on the page you mention and when my download accelerator starts (that was a zip file download remember?) I redirect the download to the browser because the download is actually a HTML page. This I had to do probably three or four times until I was presented with IE's Save dialog. I am sorry for the trouble, but this is something we need to live with for now and which I cannot fix without relocating pyMinGW. Regards Khalid -- http://mail.python.org/mailman/listinfo/python-list
Re: protecting the python code.
nell wrote: > Hi all, > I've developed a testing application in python, and should supply it in > a way that no one (lets say they are regular users) will understand it > and edit it. > The application source is all python but we expose a UI written in C# > that go over all our code and expose to user functions (Indicated with > a special prefix). > So the problem on one hand is protecting the source and make it less > accessible ond on the other hand to make it available for the UI. > 10x in advance You basically have two options: 1. Use Pyrex to compile your application to be used as (a) module(s). 2. Use Pyrex to compile your application and embed Python in it. The first option is probably the easier of the two, and it only requires that you install Pyrex (http://nz.cosc.canterbury.ac.nz/~greg/python/Pyrex/) and that you study the Docs and the Demos in their respective directories. The second option is more involved but is still possible. You need to follow this: http://lists.copyleft.no/pipermail/pyrex/2004-June/000822.html Many people use Pyrex to write Python extensions only. But given the obvious absence of competitors to address the issue of the protecting of python code, for whatever reason, then I think it is safe to say that Pyrex is now in a unique position to address that issue as well. Please be kindly reminded that even py2exe-- although a great undertaking-- is not AFAIK currrently that protective of your code-- not that it ever claimed it is so-- as draging the resulting exe file to your zip archiever will reveal the python code inside your exe file. And so in short: try the Pyrex way. Regards, Khalid -- http://mail.python.org/mailman/listinfo/python-list
pickle, cPickle, & HIGHEST_PROTOCOL
I wonder if someone can explain what is wrong here. I am pickling a
list of dictionaries (see code attached) and unpickling it back using
the HIGHEST_PROTOCOL of pickle and cPickle. I am getting an error
message and trace backs if the list exceeds eight items. Whether I use
pickle or cPickle does not matter, i.e., the eight number causes a
problem in both modules, although the trace backs are of course
dissimilar.
This pickling and unpickling of the list of dictionaries worked when I
stopped using the HIGHEST_PROTOCOL in both modules (pickle and
cPickle), which got Python to use the ASCII format (I suppose) as I can
read the pickled data.
This behavior was observed in Python 2.3.4 (final), and 2.4 (final) on
Win98.
Any comments?
Regards,
Khalid
# Sample program tester.py begin
!
! import pickle as pkl
! import os
! #-
! def test_pickle():
!fn = 'rkeys.txt'
!f = file(fn, 'r')
!lines = f.readlines()
!f.close()
!_test_list = []
!for line in lines:
!sline = line.split(',')
!#print sline
!key, value = sline[0], sline[1].strip()
!_test_dict = {}
!_test_dict[key] = value
!_test_list.append(_test_dict)
!
!# Let's see the contents of our object
!print _test_list
!
!# Then pickle it
!f = file('pkl_' + fn, 'w')
!pkl.dump(_test_list, f, pkl.HIGHEST_PROTOCOL)
!f.close()
!
!# Empty it
!_test_list = []
!print _test_list
!
!# Unpickling object here:
!f = file('pkl_' + fn, 'r')
!_test_list = pkl.load(f)
!f.close()
!
!# See contents after loading
!print _test_list
!#-
!if __name__ == '__main__':
! test_pickle()
!
!# Sample program end
# Contents of file rkeys.txt (without the triple quotes):
"""
'1','v1'
'2','v2'
'3','v3'
'4','v4'
'5','v5'
'6','v6'
'7','v7'
'8','v8'
'9','v9'
"""
# Output (without the triple quotes)
# Using "import pickle as pkl":
"""
[{"'1'": "'v1'"}, {"'2'": "'v2'"}, {"'3'": "'v3'"}, {"'4'": "'v4'"},
{"'5'": "'v5'"}, {"'6'": "'v6'"}, {"'7'": "'v7'"}, {"'8'": "'v8'"},
{"'9'": "'v9'"}]
[]
!Traceback (most recent call last):
! File "tester.py", line 41, in ?
!test_pickle()
! File "tester.py", line 34, in test_pickle
!_test_list = pkl.load(f)
! File "D:\PY23\PYTHON\DIST\SRC\lib\pickle.py", line 1390, in load
!return Unpickler(file).load()
! File "D:\PY23\PYTHON\DIST\SRC\lib\pickle.py", line 872, in load
!dispatch[key](self)
! File "D:\PY23\PYTHON\DIST\SRC\lib\pickle.py", line 1189, in
load_binput
!i = ord(self.read(1))
!TypeError: ord() expected a character, but string of length 0 found
"""
# Output (without the triple quotes)
# Using "import cPickle as pkl":
"""
[{"'1'": "'v1'"}, {"'2'": "'v2'"}, {"'3'": "'v3'"}, {"'4'": "'v4'"},
{"'5'": "'v5'"}, {"'6'": "'v6'"}, {"'7'": "'v7'"}, {"'8'": "'v8'"},
{"'9'": "'v9'"}]
[]
!Traceback (most recent call last):
! File "tester.py", line 41, in ?
!test_pickle()
! File "tester.py", line 34, in test_pickle
!_test_list = pkl.load(f)
!EOFError
"""
# Output (without the triple quotes)
# Using "import cPickle as pkl", or "import pickle as pkl"
# but _not_ using the HIGHEST_PROTOCOL:
"""
[{"'1'": "'v1'"}, {"'2'": "'v2'"}, {"'3'": "'v3'"}, {"'4'": "'v4'"},
{"'5'": "'v5'"}, {"'6'": "'v6'"}, {"'7'": "'v7'"}, {"'8'": "'v8'"},
{"'9'": "'v9'"}]
[]
[{"'1'": "'v1'"}, {"'2'": "'v2'"}, {"'3'": "'v3'"}, {"'4'": "'v4'"},
{"'5'": "'v5'"}, {"'6'": "'v6'"}, {"'7'": "'v7'"}, {"'8'": "'v8'"},
{"'9'": "'v9'"}]
"""
--
http://mail.python.org/mailman/listinfo/python-list
ANN: Binary Distribution of pyMinGW-241
This is to inform those interested in Python and MinGW that a binary distribution of pyMinGW-241 is now available. This is mainly a packaging of the March release in binary form for those who are finding it difficult to build Python or its standard extensions in MinGW. WHAT'S INSIDE - - pyMinGW-License - pyMinGW-Readme - Python-License - python.exe - python24.dll - pythonw.exe - w9xpopen.exe - python_icon.exe + Dlls: - tcl84.dll - tclpip84.dll - tk84.dll - zlib.pyd - _bsddb.pyd - _socket.pyd (Without IPv6 support, as MinGW still lacks it) - _ssl.pyd - _testcapi.pyd - _tkinter.pyd - bz2.pyd - pyexpat.pyd - select.pyd - unicodedata.pyd - winsound.pyd + Include: pyconfig.h + Lib: + distutils + command - build_ext.py - ccompiler.py - cygwinccompiler.py - unixccompiler.py + Libs: - libpython24.a + tcl: + tcl84 + tk84 Get it from here: http://jove.prohosting.com/iwave/ipython/pyMinGW.html Regards Khalid -- http://mail.python.org/mailman/listinfo/python-list
Re: First release of Shed Skin, a Python-to-C++ compiler.
Mark Dufour wrote: > After nine months of hard work, I am proud to introduce my baby to the > world: an experimental Python-to-C++ compiler. Good work. I have good news and bad news. First the good news: ShedSkin (SS) more or less works on Windows. After patching gc6.5 for MinGW, building it, and testing it on WinXP with some succuess, and after patching my local copy of SS, I can get the test.py to compile from Python to C++, and it seems that I can get almost all the unit tests in unit.py to pass. Here is what I used: 1. shedskin-0.0.1 2. pyMinGW patched and MinGW compiled Python 2.4.1 from CVS: Python 2.4.1+ (#65, Aug 31 2005, 22:34:14) [GCC 3.4.4 (mingw special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> 3. MinGW 3.4.4: g++ -v Reading specs from e:/UTILIT~1/PROGRA~1/MINGW/BIN/../lib/gcc/mingw32/3.4.4/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.4 (mingw special) 4. Also using: - mingw-runtime 3.8 - w32api-3.3 - binutils-2.16.91-20050827-1 - gc6.5 (Bohem GC) locally patched Now the bad news. Four tests in Unit.py fail, brief output is as follows[1]. [SKIP 19532 lines] *** tests failed: 4 [(60, '__class__ and __name__ attributes'), (85, 'ifa: mixing strings and lists of strings in the same list'), (122, 'neural network simulator XXX later: recursive customization, plus some small fixes'), (124, 'small factorization program by Rohit Krishna Kumar')] Moreover, and since the GC system you used only works in "recent versions of Windows", it follows that this solution will not work in all versions. I tested it on Win98 and both GC tests and SS's unit.py tests crash; although SS can still seem to compile the tests to C++. At any rate, if anyone is interested in the patches they can be downloaded from [2]. Regards, Khalid [1] The entire output of unit.py can also be found at [2] [2] http://jove.prohosting.com/iwave/ipython/Patches.html -- http://mail.python.org/mailman/listinfo/python-list
Re: python callbacks and windows
[EMAIL PROTECTED] wrote: > I was wondering if anyone could point me to an example. Currently i > have a c++ program which calls and c++ dll (i created both). The dll > uses SendMessage to pass messages back to the calling .exe, and the > .exe process the messages in it's Windows Procedure function > WindProc(). > > What i want is to receive these messages ( the contents of each message > will be plain text), in python using a callback (i think this is what i > need). > > I don't know whether (or if it's possible) to implement the windows > procedure and stuff in python, eliminating the need for the .exe > altogether. > > or should i do it the other way, to add a callback function in python, > and for the windows procedure in the .exe to call this python callback? > > in any case, some simple code examples would be great. > > cheers. What you ask for is somewhat hard to find easy answers for. But here is something that might help: 1. Example of Python function to a C library as a callback: http://groups.google.com/group/comp.lang.python/browse_thread/thread/cd4a6aa29e75e72d/6c8eeeffba9fa14b?lnk=st&q=%22Python+function+to+a+C+library+as+a+callback%22&rnum=1&hl=en#6c8eeeffba9fa14b 2. Venster, a highly native Windows GUI toolkit for Python based on the ctypes ffi library: http://venster.sourceforge.net/htdocs/index.html Khalid -- http://mail.python.org/mailman/listinfo/python-list
Re: First release of Shed Skin, a Python-to-C++ compiler.
Mark Dufour wrote:
> Thank you so much for your efforts!
Don't mention it.
> I will try to download your patches this afternoon on a roommate's Windows
> computer, and try to see if I can fix the remaining tests.
>
Okay. An update.
- Test (124, 'small factorization program by Rohit Krishna Kumar') now
passes on Windows. My mistake in my patching of SS header files. The
patch is now updated. Please download again if you have an earlier
copy.
- Test (122, 'neural network simulator XXX later: recursive
customization, plus some small fixes') was not really failing, it was
just not passing. :)
You see the Python version calls random like so:
self.weight = (random()-0.5)/2 # [float]
And testing output for random generated values is not going to make the
test pass. So if we change that line to a random value generated by
Python in the same way like so:
self.weight = (0.88996634365870131-0.5) # [float]
We have then output from Python like so:
[[0.97483328216510368], [0.50575070454495774], [0.50047176765739709],
[0.93429133063585856], [0.50083898389362214], [0.98098364981984132],
[0.5033858371718114], [0.94838636704849744], [0.50002510730868799],
[0.50910910041727786], [0.5128172933740105], [0.50010155471769424]]
and from the compiled SS generated C++ files like so:
[[0.974833], [0.505751], [0.500472], [0.934291], [0.500839],
[0.980984], [0.503386], [0.948386], [0.500025], [0.509109], [0.512817],
[0.500102]]
Which is okay I guess, wouldn't you agree?
- On to Test (85, 'ifa: mixing strings and lists of strings in the same
list'). It is still failing. It is crashing in the compiled C++
generated from SS. But did you know that the test in pure Python is
crashing as well?
"""
#test03.py
#('ifa: mixing strings and lists of strings in the same list', '''
def row_perm_rec():
hoppa_row = 'impossible' # [str]
hoppa_row = [] # [list(str)]
a = hoppa_row# [pyobj]
hoppa_row.extend(a) # []
hoppa_row.append('u')# []
return hoppa_row # [pyobj]
a = [[7]]# [list(list(int))]
s = row_perm_rec() # [pyobj]
puzzleboard = [['']] # [list(list(str))]
puzzleboard[1][1] = s[1] # [str]
#''', '''
#check('s', ['pyobj'])
#check('a', ['list(list(int))'])
#check('puzzleboard', ['list(list(str))'])
#output()
"""
Running that file produces this error in all Python versions I have.:
Traceback (most recent call last):
File "test03.py", line 15, in ?
puzzleboard[1][1] = s[1] # [str]
IndexError: list index out of range
- Finally Test (60, '__class__ and __name__ attributes') needs
patience. :) In Python it outputs the following:
__main__.evert
evert
instance
equal str!
In the compiled C++ generated by SS it outputs the following:
class evert
evert
class evert
evert
equal!
[Big nasty crash]
So there. :)
Regards,
Khalid
--
http://mail.python.org/mailman/listinfo/python-list
Re: Shed Skin under Windows and OSX
Mark Dufour wrote: > > By the way, I read in your blog that you would be releasing a windows > > intaller soon. > > Have you, or anyone else, managed to do it? > > I just finished making a 20 MB (!) package for Windows XP (I'm not > sure which older versions of Windows it will run on.) It includes the > Boehm garbage collector and a C++ compiler (MingW), which hopefully > will make it really easy to create executables. However, I'm not > releasing it until somebody with XP can test it for me :-) If you'd > like to try what I have so far, please download > http://kascade.org/shedskin-0.0.2.zip, unzip it and follow some simple > steps in the README file. I would really like to know about anything > that doesn't work, or is unclear! > > BTW, I also fixed all OSX problems, but I'm waiting for a friend to > give it a final test. > > What kind of program would you like to compile? > > > thanks! > mark. Here is the very end of a very long output of unit.py run in Python 2.4.1 on WinXP Pro SP2: [generating c++ code..] *** compiling & running.. rm test.o test.exe g++ -O3 -IG:/Downloads/Temp/ss2/shedskin -c test.cpp g++ -O3 -IG:/Downloads/Temp/ss2/shedskin test.o G:/Downloads/Temp/ss2/shedskin/libss.a -lgc -o test output: [3, 3, 3, 1097, 70201] *** success: small factorization program by Rohit Krishna Kumar 124 *** no failures, yay! :) Well done. So what was causing that crash in test '__class__ and __name__ attributes' after all? I'll also try to test it on Win98. Regards, Khalid -- http://mail.python.org/mailman/listinfo/python-list
ANN: pyMinGW support for Python 2.3.5 (final) is available
This is to inform those interested in compiling Python in MinGW that an updated version of pyMinGW is now available. Get it from here: http://jove.prohosting.com/iwave/ipython/pyMinGW.html Regards Khalid -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: pyMinGW support for Python 2.3.5 (final) is available
Nick Craig-Wood wrote: > A.B., Khalid <[EMAIL PROTECTED]> wrote: > > This is to inform those interested in compiling Python in MinGW that > > an updated version of pyMinGW is now available. > > Ha anyone tried cross compiling python with mingw? At work we compile > our software for lots of platforms (including windows) on a linux > build host. The windows builds are done with a mingw cross compiler. > It would be interesting if we could do this with python + extensions > also. > > -- > Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick Hello Nick, I haven't tried it; but could this be of any help? http://tinyurl.com/58n5k -- http://mail.python.org/mailman/listinfo/python-list
Re: - E02 - Support for MinGW Open Source Compiler
Pat wrote: > There have been extensive discussions about these issues on the > Python-Dev mailing list over the past couple of months (mostly in > December, but continuing to the present - see > http://mail.python.org/pipermail/python-dev/2004-December/thread.html > as a starting point), which seem to have fizzled out or at least > haven't resolved much. The discussions made reference to work that has > already been done to allow Python to be compiled with minGW: > > pyMinGW is a patch to Python source that aims to get Python to compile > under MinGW > > http://jove.prohosting.com/iwave/ipython/pyMinGW.html > > I've not seen any commentary on the quality of this patch, so that > doesn't appear to be the reason it hasn't been officially adopted. > Reading all the threads from Python-Dev has not enlightened me at all > as to what the underlying reason is for not adopting these changes. > Maybe there are good reasons, I just couldn't find them, and I'm > usually pretty good with Google. If passing all the regression tests of the official Windows Python distribution is an indication of the quality of patch-- and pyMinGW patched and MinGW built Python does pass all of them-- then one is inclined to say that pyMinGW is a good patch. The reason why it is, on the other hand, not included in the official distribution is threefold. 1. Contrary to what many might imagine, I don't think enough people use MinGW to frankly justify any extra effort beyond pyMinGW. 2. Given number 1 above, this patch, I believe, and I could be mistaken, must not rush to be included in Python's core; people like your esteemed person should test it (note that it is designed not to interfere with your trusted and working official Python, if any); it is only when enough people do such testing that there will be a case for it to be included in Python's core. 3. Finally. there is nothing wrong with third-party patches if they get the job done, which I believe is the case with pyMinGW. Regards, Khalid -- http://mail.python.org/mailman/listinfo/python-list
Re: - E02 - Support for MinGW Open Source Compiler
Ilias Lazaridis wrote: > The first step is to make a pyMinGW project. > You are mistaken. The first steps are the following: 1) Realizing that a project _must_ start not because you want it to, but because those who are willing to work on it think it is worth the extra effort for it to. 2) Realizing that what best scratches your back is non other than your own nails. No one is going to do any extra effort for you (or anyone else for that matter) if they have some good reason not to. And both the author of pyMinGW and Tim have already given enough reasons for those who wondered why there is no official Python support for the MinGW compiler earlier in this very thread. 3) Realizing that there _is_ already a project called pyMinGW! That it does not fit your requirements-- whatever these maybe-- is an altogether different issue. The fact of the matter remains that a project _does_ exist, one which people (including myself) do in fact use; and because it does exist there is no reason to "make" it. > If one is intrested, he has possibly more luck [than I had] to convince > the author of pyMinGW. Of what? To make pyMinGW? To do extra work to your liking that was shown to be nnnecessary especially when pyMinGW can currently get the job done? Let alone the free compiler available for all to use? Whether you realize it or not, those who are interested will download pyMinGW and will test it and they will use it if they find it useful. It is their choice to do so. It is apparent that not only have you not done that, but that you also seem not interested in doing so. That too is your choice. I suspect that no one is going to lose sleep over either choice. I hope I don't come across as condescending, which I hope I never am, but I know I won't. Life goes on. Khalid -- pyMinGW: http://jove.prohosting.com/iwave/ipython/pyMinGW.html -- http://mail.python.org/mailman/listinfo/python-list
Re: - E02 - Support for MinGW Open Source Compiler
Ilias Lazaridis wrote: > A.B., Khalid wrote: > > Ilias Lazaridis wrote: > > > >>The first step is to make a pyMinGW project. > > > > You are mistaken. The first steps are the following: > [...] - (nonrelevant comments) > > > 3) Realizing that there _is_ already a project called pyMinGW! That it > > does not fit your requirements-- whatever these maybe-- is an > > altogether different issue. The fact of the matter remains that a > > project _does_ exist, one which people (including myself) do in fact > > use; and because it does exist there is no reason to "make" it. > [...] > > I've already understood your viewpoint. You just say that you do. Your repeating the same arguments using the same logic testifies that you don't. > > My requirements about an open-source project (or sub-project) are very > simple: Your "requirements" are just what they are, _your_ requirements. And since they are so, maybe you'd like to address them yourself instead of continuing to complain how "your requirements" (simple or otherwise) are not being met and that hence the author of this project is this, and/or the entire language is that. Enough said here. > You have the right to refuse this. > > I (and any other reader) have the right to derive our conclusions about > you and the reasons that you refuse a _real_ collaborative work. Of course I have the right to do what I like (and as regards pyMinGW this was explained earlier in this thread); your mere pronunciation that I have that right neither subtracts nor adds to it one iota. And it seems to me that the community has indeed reached some conclusions which any reasonable person with a fair grasp of English can quickly identify from the nature of their responses to you, here and elsewhere. > > You already found the mingw-patch for building python. It is > > added/managed/maintained by community members. > > This is a one-man-show, which does not invite to open collaboration > (feedback is requested to closed email): > > http://groups-beta.google.com/group/comp.lang.python/msg/98fa42dabff68db2 > > python [foundation, crew, dictator, ...] should engourage open > collaboration, should engourage _collaboration_. Oh well, I hope it would not come as a shock to you that pyMinGW does allow collaboration. Here is a quote from the pyMinGW-24 changes document: - pyMinGW-24-0064: Dec 11th, 2004 - [1] Included \PC\pyconfig.h in the Python24.iss. Thanks to Matthias Gondan for the report and the fix. Quoted from http://jove.prohosting.com/iwave/ipython/pyMinGW-24.html So you see, the collaborative effort is there. It is just not responding to "your requirements" to your liking that is bothering you! Now if you want to continue complaining about how "your requirements" are not being met, by volunteers who make their work available for free in their spare time, to your liking, go ahead. Knock yourself out. Khalid -- pyMinGW: http://jove.prohosting.com/iwave/ipython/pyMinGW.html -- http://mail.python.org/mailman/listinfo/python-list
ANN: pyMinGW support for Python 2.4.1 (final) is available
This is to inform those interested in compiling Python in MinGW that an updated version of pyMinGW is now available. Get it from here: http://jove.prohosting.com/iwave/ipython/pyMinGW.html Regards Khalid -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.4 killing commercial Windows Python development ?
Tony Meyer wrote: > [problems with dependency on msvr71.dll snipped] > > One option is to create a Windows Python 2.4 installer that includes a > Python not built with MSVC7 - for example gcc or MSVC6 - which doesn't have > the dependency on mscvr71.dll. Both VC6 and gcc are feasible, although > there may be a reasonable amount of work required. > > If the installer proved popular, then I'm sure the python-dev people could > be convinced (for 2.5, perhaps) that there should be an official release of > this type, much like there's a separate 64 bit installer available. > (Assuming that patches could be submitted that made the build process as > seamless as the existing one). > > This seems a much more achievable goal than anything involving a meeting > with Microsoft... > > =Tony.Meyer Kindly note that the Python source distribution does include project files for building Python 2.4 with MSVC6. Add to that the fact that with pyMinGW[1] one can build yet another Windows distribution not dependent on mscvr71.dll and some of the logic about not upgrading to Python 2.4, IMHO, just goes away. An official release of installers for either or both versions would I think complicate matters: more choices translate to more confusion. Needless to say that extension authors (for Python 2.4) would then need to make two binaries for every extension they release for Python 2.4: one for the mscvr71.dll dependent Python distribution, and another one for the mscvrt.dll dependent version(s). This I think would hurt Python and its users. The solution is to have those that know enough to really need to build Python on their own according to their requirments. They would then have to deal with compiling the Python 2.4 extensions themselves, of course. But this would make things simple and hopefully address the needs of everyone. Regards, Khalid [1] pyMinGW: http://jove.prohosting.com/iwave/ipython/pyMinGW.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Get OS name
codecraig wrote: > my requirements for getting the OS info havent changed. My first > message says "How can I get the OS Name, such as "Windows XP Pro"." > that's what I wanted all along. > > thanks for the information anyway, i believe platform is better than my > previous approach. > > thanks Please note that platform appears to require win32api to be in your system. The following is the code from \Lib\platform.py. The function that gets the data sets these values as default [Code from platform.py] def win32_ver(release='',version='',csd='',ptype=''): [/Code] And will return empty strings in case win32api is not found: [Code from platform.py] # Import the needed APIs try: import win32api except ImportError: return release,version,csd,ptype [/Code from platform.py] Accordingly, my Python 2.3.5 final which has win32api installed can get the platform answer right: $ /py23/python/dist/src/MinGW/python -i Python 2.3.5 (#62, Feb 12 2005, 02:56:20) [GCC 3.4.2 (mingw-special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> print platform.system(), platform.release() Windows 98 >>> But where I don't have win32api installed, my Python does not know that answer you seek: $ /py25/python/dist/src/MinGW/python -i Python 2.5a0 (#65, Apr 12 2005, 20:22:54) [GCC 3.4.2 (mingw-special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> print platform.system(), platform.release() Windows >>> Regards, Khalid -- http://mail.python.org/mailman/listinfo/python-list
Re: (Python newbie) Using XP-SP2/MSVC6: No Python24_d.lib, winzip barfs on Python-2.4.1.tar, cannot download bzip2
Bill Davy wrote: > I downlaoded and installed > http://www.python.org/ftp/python/2.4.1/python-2.4.1.msi > > I'm trying to build an extension using SWIG 1.3.24 and the linker needs > python24_d.lib (I do not have the DLL either). I've not found it in any of > the > downloads. > > So I tried to download the source to build it myself. Of > http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tar.bz2 and > http://www.python.org/ftp/python/2.4.1/Python-2.4.1.tgz, WinZip (9.0 SR1) > just says "Error reading header after processing 0 entries". > > Additionally, I've had no joy downloading the unzipper > (ftp://sources.redhat.com/pub/bzip2/v102/bzip2-102-x86-win32.exe) from the > site cited for the unzipper (http://sources.redhat.com/bzip2/). It flashed > up a > black console window momentarily. > > Oh, this is so frustrating! :-( > > Can anyone point me in the right direction? > > And then I can get to grips with my work. > > tia > Bill I am no expert in MSVC6, but it sounds like maybe you need to supply the no-debug switch in your extention setup.py file: /d NDEBUG. In case that does not work and help on this is not forthcoming, you can always try pyMinGW[1]. Regards, Khalid [1] pyMinGW: http://jove.prohosting.com/iwave/ipython/pyMinGW.html -- http://mail.python.org/mailman/listinfo/python-list
Re: (Python newbie) Using XP-SP2/MSVC6: No Python24_d.lib, winzip barfs on Python-2.4.1.tar, cannot download bzip2
Okay, let me have another stap at this. As you have probably noticed MSVC6 is no longer actively supported as far as Python 2.4 goes. The official distribution of Python 2.4 for Windows is built using MSVC7.1 (or whatever you wish to call it). We are told that building C extensions with MSVC6 for use in the official Python 2.4 (which uses the MSVCR71) is not safe, and mixing the different runtime libraries that your extension (or my extension) with that which official Python 2.4 uses will/might cause crashes. Google around for details on this. So, what to do? You seem to have four options. 1. Get and use the MSVC7.1 compiler. 2. Get and use the freely distributed MS compiler. 3. Download the Python source[1] and compile it yourself in MSVC6 (there are project files in the source to enable you to do that). Then use your MSVC6 to create the extension. 4. Get and use MinGW and pyMinGW[2] Regards, Khalid [1] Check to see if your archiever tool is working, or get the source from CVS. [2] pyMinGW: http://jove.prohosting.com/iwave/ipython/pyMinGW.html -- http://mail.python.org/mailman/listinfo/python-list
Re: With pyMinGW
[EMAIL PROTECTED] wrote: > To use Pyrex, SWIG and the like on a Win2K I have followed this way: > > http://jove.prohosting.com/iwave/ipython/pyMinGW.html > > I already had MinGW 3.4.2, so I have decompressed the Python 2.4.2 > sources, I have merged in the pyMinGW patch, and I have run the global > compilation with: > > make -f python24.mak all > > It has compiled most things, but not zlibmodule.c > It has stopped the compilation with: > > c:\..\bin\dllwrap.exe: no export definition file provided. > Creating one, but that may not be what you want > make[1]: Leaving directory `/.../PyminGW/Python-2.4.2/MinGW' > make -f zlib.mak > make[1]: Entering directory `/.../PyminGW/Python-2.4.2/MinGW' > gcc.exe -c ../Modules/zlibmodule.c -o ../Modules/zlibmodule.o > -I"../Include" -I"../Pc" -I"../../../d > ist/zlib-1.2.3" -Wall -s -DNDEBUG -D_USRDLL -O2 > ../Modules/zlibmodule.c:8:18: zlib.h: No such file or directory > ../Modules/zlibmodule.c:66: error: syntax error before "z_stream" > > ... etc etc. > > Anyway, probably 98% was compiled and this Python works, I have tried > the standard tests and most of them pass. > Then I have downloaded the pyMinGW Extensions V. 0.0.6.6, so zip and > other things now work. > > The link to the Tcl-Tkinter extension doesn't work (the free site > hosting the file doesn't accept this file format anymore), so I cannot > use Tkinter. > > I have decompressed SWIG and put it in a temporary Path. > > I have then tried a basic SWIG example, (called example) coming from > this obsolete but probably still interesting page: > http://sebsauvage.net/python/mingw.html > > But I have had problems durign the module creation: > > C:\...\PyminGW\Python-2.4.2\MinGW>python setup.py build -cmingw32 > running build > running build_ext > building 'example' extension > swigging example.i to example_wrap.c > C:\...\PyminGW\swigwin-1.3.28\swig.exe -python -o example_wrap.c > example.i > creating build > creating build\temp.win32-2.4 > creating build\temp.win32-2.4\Release > C:\..\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Ic:\python24\include > -Ic:\pytho > n24\PC -c example_wrap.c -o build\temp.win32-2.4\Release\example_wrap.o > example_wrap.c: In function `My_variable_set': > example_wrap.c:2550: error: `My_variable' undeclared (first use in this > function) > > ... ecc. > > > So I have had 3 problems, maybe some of you can suggest me how to solve > some of them. > > (Can the standard Python site accept to distribuite an installer with > MinGW-compiled Python + minGW + SWIG for people using Windows that want > such system prebuilt? Maybe me or another person can assemble it). > > Thank you, > bearophile It seems you may be using an old version of pyMinGW, because in the one I have the directory issue of zlib was fixed and the relevant part dealing with include directories in zlib.mak should read now as follows: LIBS = -L. -lpython24 -L"../../../dist/zlib-1.2.3" -lz --image-base,0x1e1B INCS = -I"../Include" -I"../Pc" -I"../../../dist/zlib-1.2.3" CXXINCS = -I"../Include" -I"../Pc" -I"../../../dist/zlib-1.2.3" The idea is to make INCS point at the location of your zlib sources. As to the Tkinter-Tcl point, then please remember that this was a binary build extension distribution that had nothing to do with the core Python that pyMinGW is supposed to address. And if you download the extension sources then you can certainly build the libraries yourself, and then the python extensions, especially since you have make files ready to use for the later in the pyMinGW sources. The binary distribution was meant to make things a bit easier for people, but since the site stopped the hosting of zip files and since many people do not download that particular file anyway when it was hosted elsewhere, letting the file expire (inactive files are removed after one week from last download), then I hope you'd agree it would be much work for me to keep track of expired and unexpired files and so keep on uploading the files. As to your SWIG problem, then I suggest you look into the pyMinGW's extensions' directory. There you will find two examples of building C and CPP extensions using SWIG and MinGW. Regards, Khalid pyMinGW: http://jove.prohosting.com/iwave/ipython/pyMinGW.html -- http://mail.python.org/mailman/listinfo/python-list
Re: With pyMinGW
[EMAIL PROTECTED] wrote: > Thank you for your answers, Khalid. > > > It seems you may be using an old version of pyMinGW, > > I have downloaded it yesterday from your site. > > > > the relevant part dealing with include directories in zlib.mak > > should read now as follows: > > I have checked, and that relevant part is the same in my zlib.mak. > > > > but since the site stopped the hosting of zip files and since many > > people do not download that particular file anyway when it was hosted > > elsewhere, letting the file expire (inactive files are removed after > > one week from last download), then I hope you'd agree it would be much > > work for me to keep track of expired and unexpired files and so keep on > > uploading the files. > > You can probably remove the dead link from your page. > (Maybe I can build a complete package (with Tkinter, minGW and Swig > too), and put it in some official Python site.) > > > > As to your SWIG problem, then I suggest you look into the pyMinGW's > > extensions' directory. There you will find two examples of building C > > and CPP extensions using SWIG and MinGW. > > I don't want to use/waste too much of your time, I have succed with the > C++ example, but the C example has given me some problems: > > C:\...\PyminGW\Python-2.4.2\MinGW\Extensions\pyExt_C_exmaple>python24 > setupMingW.py build --compile > r=mingw32 > running build > running build_ext > building '_example' extension > swigging example.i to example_wrap.c > C:\...\PyminGW\swigwin-1.3.28\swig.exe -python -o example_wrap.c > example.i > C:\..\bin\gcc.exe -mno-cygwin -mdll -O2 -Wall -s > -IC:\...\PyminGW\Python-2.4 > .2\include -IC:\...\PyminGW\Python-2.4.2\PC -c example_wrap.c -o > build\temp.win32-2.4\Release\examp > le_wrap.o > example_wrap.c: In function `PySwigClientData_New': > example_wrap.c:1205: warning: dereferencing type-punned pointer will > break strict-aliasing rules > example_wrap.c: In function `PySwigObject_own': > example_wrap.c:1456: warning: dereferencing type-punned pointer will > break strict-aliasing rules > example_wrap.c:1456: warning: dereferencing type-punned pointer will > break strict-aliasing rules > example_wrap.c: In function `My_variable_set': > example_wrap.c:2515: error: `My_variable' undeclared (first use in this > function) > > Bye, > bearophile You are using the C example extension found in pyMinGW, right? It builds fine here, of course using the "python setup.py build" command. $ python setupMinGW.py build running build running build_ext building '_example' extension swigging example.i to example_wrap.c d:\MISC\PROGRAMS\SWIG-1.3.21\swig.exe -python -o example_wrap.c example.i creating build creating build\temp.win32-2.4 creating build\temp.win32-2.4\Release e:\UTILIT~1\PROGRA~1\MINGW\BIN\gcc.exe -mno-cygwin -mdll -O2 -Wall -s -IG:\PROJS\PY24\PYTHON\DIST\SRC\include -IG:\PROJS\PY24\PYTHON\DIST\SRC\PC -c example_wrap.c -o build\temp.win32-2.4\Release\example_wrap.o example_wrap.c:187: warning: 'SWIG_Python_TypeDynamicCast' defined but not used example_wrap.c:199: warning: 'SWIG_Python_TypeName' defined but not used example_wrap.c:205: warning: 'SWIG_Python_TypeQuery' defined but not used example_wrap.c:551: warning: 'SWIG_Python_MustGetPtr' defined but not used example_wrap.c:559: warning: 'SWIG_Python_ConvertPacked' defined but not used e:\UTILIT~1\PROGRA~1\MINGW\BIN\gcc.exe -mno-cygwin -mdll -O2 -Wall -s -IG:\PROJS\PY24\PYTHON\DIST\SRC\include -IG:\PROJS\PY24\PYTHON\DIST\SRC\PC -c example.c -o build\temp.win32-2.4\Release\example.o writing build\temp.win32-2.4\Release\_example.def creating build\lib.win32-2.4 e:\UTILIT~1\PROGRA~1\MINGW\BIN\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.4\Release\example_wrap.o build\temp.win32-2.4\Release\example.o build\temp.win32-2.4\Release\_example.def -LG:\PROJS\PY24\PYTHON\DIST\SRC\libs -LG:\PROJS\PY24\PYTHON\DIST\SRC\PCBuild -lpython24 -o build\lib.win32-2.4\_example.pyd And copying that _example.pyd from the build directory just created to our current directory so that python can see it, we can load that extension fine as well: $ python -i Python 2.4.2 (#67, Nov 8 2005, 10:12:11) [GCC 3.4.2 (mingw-special)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import example as ex >>> dir(ex) ['__builtins__', '__doc__', '__file__', '__name__', '_example', '_newclass', '_object', '_swig_getattr', '_swig_setattr', 'cvar', 'fact', 'fib', 'get_time', 'hello', 'my_mod'] >>> ex.hello() 'Hi there!' >>> ex.fact(4) 24 >>> Regards, Khalid -- http://mail.python.org/mailman/listinfo/python-list
Re: THREADS use 100 % CPU all the time
On Apr 11, 2:38 am, [EMAIL PROTECTED] wrote: > Hi all, > > I have a application where I use different threads. actually all is > working - BUT I just discovered that the [b]CPU is always 100 % [/ > b]used. > > on the 32-bit machine athlon XP, as well as on the amd 64-bit AMD > Athlon(TM) 64 X2 Dual-Core. > > I have to admit I'm not used to threads. I actually use a thirdparty > scheduler [url]http://www.webwareforpython.org/TaskKit/Docs/Source/ > Docs/TaskKit.Scheduler.html[/url] > but I checked and a very simple exampe with threading gives me also > all the time 100% CPU. > > [code] > > import threading, time > > class TestThread ( threading.Thread ): > def run ( self ): > print 'TEST' > > t = TestThread() > t.start() > > while (True): > pass > > [/code] > > Does anyone know how to run this without consuming all CPU. > > regards, > > MJ You need your program to sleep a while to allow a switch to other tasks. Like so: ### import threading, time class TestThread(threading.Thread): def run(self): print 'TEST' t = TestThread() t.start() while (True): time.sleep(0.01) pass ### Regards -- http://mail.python.org/mailman/listinfo/python-list
