Re: [Python-Dev] configure error: "rm: conftest.dSYM: is a directory"
On Sat, Apr 5, 2008 at 9:17 PM, <[EMAIL PROTECTED]> wrote: > I just noticed this error message during configure: > > checking whether gcc accepts -Olimit 1500... no > checking whether gcc supports ParseTuple __format__... no > checking whether pthreads are available without options... yes > checking whether g++ also accepts flags for thread support... no > checking for ANSI C header files... rm: conftest.dSYM: is a directory > rm: conftest.dSYM: is a directory > yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > > Note the "rm: conftest.dSYM: is a directory". This occurred a few times > during the configure process. Didn't cause it to conk out, but is annoying. I am assuming this is on your OS X machine, Skip? I have been getting that message for a while on my OS X machine as well. Same with some linking message when building ctypes. Never bothered to debug them since they never seemed to affect anything. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove "current" Windows executables from Lib/distutils/command in svn?
> As another alternative to providing a separate AMD64 binary, you could > also try to make the existing binary work properly on Win64, and tell > it with a config flag whether to look for Win32 or Win64 (or either) > on the target system. I'm afraid that isn't an option for me in the short term. Should I just check-in my cross-compilation patch as it stands then? Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] configure error: "rm: conftest.dSYM: is a directory"
>> Note the "rm: conftest.dSYM: is a directory". This occurred a few >> times during the configure process. Didn't cause it to conk out, but >> is annoying. Brett> I am assuming this is on your OS X machine, Skip? Yes, sorry. I forgot to mention that. As long as someone else sees it and feels fine to ignore it, I'm fine with it. I suspect it's a configure problem anyway, not a Python problem. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove "current" Windows executables from Lib/distutils/command in svn?
>> As another alternative to providing a separate AMD64 binary, you could >> also try to make the existing binary work properly on Win64, and tell >> it with a config flag whether to look for Win32 or Win64 (or either) >> on the target system. > > I'm afraid that isn't an option for me in the short term. Should I just > check-in my cross-compilation patch as it stands then? Sure, go ahead. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r62129 - in python/trunk: PCbuild/debug.vsprops PCbuild/kill_python.c PCbuild/kill_python.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj PCbuild/release.vsprops Tools/buildbot/M
Fixed in r62193. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Trent Nelson [EMAIL PROTECTED] Sent: 04 April 2008 20:41 To: "Martin v. Löwis" Cc: Christian Heimes; python-dev@python.org Subject: Re: [Python-Dev] r62129 - in python/trunk: PCbuild/debug.vsprops PCbuild/kill_python.c PCbuild/kill_python.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj PCbuild/release.vsprops Tools/buildbot/Makefile Tools/buildbot/build-amd64.bat Tools/buildbo... Ok, I'll change the approach this weekend. Trent. From: "Martin v. Löwis" [EMAIL PROTECTED] Sent: 04 April 2008 19:57 To: Trent Nelson Cc: Christian Heimes; python-dev@python.org Subject: Re: [Python-Dev] r62129 - in python/trunk: PCbuild/debug.vsprops PCbuild/kill_python.c PCbuild/kill_python.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj PCbuild/release.vsprops Tools/buildbot/Makefile Tools/buildbot/build-amd64.bat Tools/buildbo... > What do others that do Windows development think? I don't have a > problem changing the build behaviour if the approach I've taken is > generally disliked. I think kill_python should only ever be invoked in the build slaves; it should *not* be part of the regular build. If developers find they can't build because some files are still open, they should kill the processes themselves. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/tnelson%40onresolve.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] socket.SOL_REUSEADDR: different semantics between Windows vs Unix (or why test_asynchat is sometimes dying on Windows)
I've attached a patch (http://bugs.python.org/file9966/trunk.2550.patch) to issue 2550 that addresses the original problem here: test_support.bind_port() potentially returning ports that have already been bound to. The patch updates the tests that relied on this method, such that they call it with the new calling convention (test_ftplib, test_httplib, test_socket, test_ssl_socket, test_asynchat, test_telnetlib). Any objections to the patch? Would like to commit it sooner rather than later, as it'll fix my buildbots from wedging on test_asynchat at the very least. Trent. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Trent Nelson [EMAIL PROTECTED] Sent: 05 April 2008 18:22 To: Jean-Paul Calderone; python-dev@python.org Subject: Re: [Python-Dev] socket.SOL_REUSEADDR: different semantics between Windows vs Unix (or why test_asynchat is sometimes dying on Windows) > >"With TCP, we are never able to start multiple servers that bind > > the same IP address and same port: a completely duplicate binding. > > That is, we cannot start one server that binds 198.69.10.2 port 80 > > and start another that also binds 198.69.10.2 port 80, even if we > > set the SO_REUSEADDR socket option for the second server." > Notice that the quoted text explains that you cannot start multiple > servers that etc. Since you didn't call listen on either socket, it's > arguable that you didn't start any servers, so there should be no > surprise regarding the behavior. Try adding listen calls at various > places in the example and you'll see something different happen. I agree in principle, Stevens says nothing about what happens if you *do* try and bind two sockets on two identical host/port addresses. Even so, test_support.bind_port() makes an assumption that bind() will raise EADDRINUSE if the port is not available, which, as has been demonstrated, won't be the case on Windows or Linux. > FWIW, AIUI, SO_REUSEADDR behaves just as described in the above quote > on Linux/BSD/UNIX/etc. On Windows, however, that option actually means > something quite different. It means that the address should be stolen > from any process which happens to be using it at the moment. Probably explains why the python process wedges when this happens on Windows... > There is another option, SO_EXCLUSIVEADDRUSE, only on Windows I think, > which, AIUI, makes it impossible for another process to steal the port > using SO_REUSEADDR. Nod, if SO_EXCLUSIVEADDRUSE is used instead in the code I posted, Windows raises EADDRINUSE on the second bind(). I don't have access to any Linux boxes at the moment, so I can't test what sort of error is raised with the example I posted if listen() and accept() are called on the two sockets bound to identical addresses. Can anyone else shed some light on this? I'd be interested in knowing if the process wedges on Linux as badly as it does on Windows (to the point where it's not respecting ctrl-c or sigkill). Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/tnelson%40onresolve.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New project : Spyke python-to-C compiler
Note this message has been posted to numpy-discussion and python-dev. Sorry for the multiple posting but I thought both python devs and numpy users will be interested. If you believe your list should not receive this email, let me know. Also I just wanted to introduce myself since I may ask doubts about Python and Numpy internals from time to time :) Hi. I am a student at Univ of Alberta doing my masters in computing science. I am writing a Python-to-C compiler as one part of my thesis. The compiler, named Spyke, will be made available in a couple of weeks and is geared towards scientific applications and will therefore focus mostly on needs of scientific app developers. What is Spyke? In many performance critical projects, it is often necessary to rewrite parts of the application in C. However writing C wrappers can be time consuming. Spyke offers an alternative approach. You add annotations to your Python code as strings. These strings are discarded by the Python interpreter but these are interpreted as types by Spyke compiler to convert to C. Example : "int -> int" def f(x): return 2*x In this case the Spyke compiler will consider the string "int -> int" as a decalration that the function accepts int as parameter and returns int. Spyke will then generate a C function and a wrapper function. This idea is directly copied from PLW (Python Language Wrapper) project. Once Python3k arrives, much of these declarations will be moved to function annotations and class decorators. This way you can do all your development and debugging interactively using the standard Python interpreter. When you need to compile to C, you just add type annotations to places that you want to convert and invoke spyke on the annotated module. This is different from Pyrex because Pyrex does not accept Python code. With Spyke, your code is 100% pure python. Spyke has basic support for functions and classes. Spyke can do very basic type inference for local variables in function bodies. Spyke also has partial support for homogenous lists and dictionaries and fixed length tuples. One big advantage of Spyke is that it understands at least part of numpy. Numpy arrays are treated as fundamental types and Spyke knows what C code to generate for slicing/indexing of numpy arrays etc. This should help a lot in scientific applications. Note that Spyke can handle only a subset of Python. Exceptions, iterators, generators, runtime code generation of any kind etc is not handled. Nested functions will be added soon. I will definitely add some of these missing features based on what is actually required for real world Python codes. Currently if Spyke does not understand a function, it just leaves it as Python code. Classes can be handled but special methods are not currently supported. The support of classes is a little brittle because I am trying to resolve some issues b/w old and new style of classes. Where is Spyke? Spyke will be available as a binary only release in a couple of weeks. I intend to make it open source after a few months. Spyke is written in Python and Java and should be platform independant. I do intend to make the source open in a few months. Right now its undergoing very rapid development and has negligible amounts of documentation so the source code right now is pretty useless to anyone else anyway. I need help: However I need a bit of help. I am having a couple of problems : a) I am finding it hard to get pure Python+NumPy testing codes. I need more codes to test the compiler. Developing a compiler without a test-suite is kind of useless. If you have some pure Python codes which need better performance, please contact me. I guarantee that your codes will not be released to public without your permission but might be referenced in academic publications. I can also make the compiler available to you hopefully after 10th of April. Its kind of unstable currently. I will also need your help in annotating the provided testing codes since I probably wont know what your application is doing. b) Libraries which interface with C/C++ : Many codes in SciPy for instance have mixed language codes. Part of the code is written in C/C++. Spyke only knows how to annotated Python codes. For C/C++ libraries wrapped into Python modules, Spyke will therefore need to know at least 2 things : i) The mapping of a C function name/struct etc to Python ii) The type information of the said C function. There are many many ways that people interact with C code. People either write wrappers manually, or use autogenerated wrappers using SWIG or SIP Boost.Python etc., use Pyrex or Cython while some people use ctypes. I dont have the time or resources to support these multitude of methods. I considered trying to parse the C code implementing wrappers but its "non-trivial" to put it mildly. Parsing only SWIG generated code is another possibility but its still hard. Another approach that I am
Re: [Python-Dev] Remove "current" Windows executables from Lib/distutils/command in svn?
Martin v. Löwis schrieb: >> I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and >> enable the building of that project by default in the standard build process >> (and I'll setup the x64 build of the executable similarly). > > There are two issues here: > a) how does the binary get into the release tarball? You might argue >that it doesn't have to, as it is sufficient when it is included in >the Windows installer, however, as currently implemented, >bdist_wininst also runs on Unix, and people use it that way. > b) IIRC, upx was used to compress these executables. I don't think the >the current build process covers this, yet (but then, the current >binaries might not be compressed with upx anymore, either - not >sure whether that would be a bug). Of course, upx would probably >not currently apply to Win64-amd64. I did not compress them with upx anymore because of licensing issues with the upx-created executables, but I do not remember the details anymore. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
