Re: [Python-Dev] I would like an svn account
Steve Holden writes: > Hey, isn't Ubuntu Debian-based? ... Ouch. I don't actually use Ubuntu, but when everybody on my local LUG list from the "Linux should be Windows but cheaper" newbies to former NetBSD developers is grouching about upgrade hell, I don't see any real benefits to be gained. You're still going to need to go with a "don't think about fixing what ain't broke, and even if it's just kinda broke, Just Say No to that upgrade dope" policy. No, something has to be done about the "no upgrades" policy, or it's not worth switching from Debian stable. ___ 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] ParseTuple question
On 4/01/2009 9:29 PM, Ulrich Eckhardt wrote: If I'm still misunderstanding, can you be more specific about the exact problem (ie, the exact function you are referring to, and how you intend calling it)? trunk/_fileio.c/fileio_init() Let's leave aside that you can also pass a filedescriptor, that function either takes a string or a Unicode string as first parameter. Now, under CE, I always need a 'wchar_t*' in order to open a file, how would I get at that easiest? My approach now is to simply use "O" as format specifier for the filename and then take a look at the object's type. If it is a char-string, I have to convert (under CE) or call the char-API (desktop MS Windows), if it is a Unicode string, I can use it as it is. IIUC, the block: #ifdef MS_WINDOWS if (widename != NULL) self->fd = _wopen(widename, flags, 0666); else #endif self->fd = open(name, flags, 0666); ... Would probably need to change - instead of falling back to plain open(), if widename is NULL you would need to use MultiByteToWideChar before calling _wopen(). This assumes the unicode CRT is available of course - if not, I guess you'd need to call the win32 api instead of _wopen. Alternatively, the PyArg_ParseTuple() call could possibly be changed to use the 'e' format string Hoping-that-was-what-you-were-asking, ly, 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] I would like an svn account
2009/1/4 Brett Cannon : > Bazaar has been backwards-compatible with everything from my > understanding, so any changes they have made to the repository layout > or network protocol they use should not be an issue regardless of what > client or server versions are being used. As for the version number, > the team does monthly releases, so it has nothing to do with stability > and more with their timed release schedule. As far as I am aware (and it's not based on much practical experience, so I could be wrong) the big issue with older Bazaar formats is that they are substantially slower. And there's some sort of interoperability constraint that I don't understand, which means that, although newer clients can read from older servers, the fact that the server uses an older format means that the slowness affects the client (it may be that it's possible to get around this with some level of juggling at the client). It would be very useful to have a good statement of the impact of different client/server versions. > As for Mercurial, I have been told their repository layout has not > changed since their first release and updates have been more about bug > fixes and speed improvements. According to Mercurial compatibility rules, - New Mercurial should always be able to read old Mercurial repositories - Old Mercurial should always be able to pull from new Mercurial servers - Old Mercurial should break with a meaningful error message if it can't read a new Mercurial repository which basically means, the server version used will not affect the client and you will always be able to upgrade the server version without pain (point 2, "pull", is about client/server interaction). The last point states that you can even *down*grade the server with minimal pain (for *real* conservatives :-)) In practical terms Mercurial is 100% compatible back to at least June 2007 (version 0.9.4, the earliest documented at http://www.selenic.com/mercurial/wiki/index.cgi/WhatsNew). Paul. ___ 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] python.org OS
Aahz writes: > all. Because I was lazy, last weekend I finally did a two-stage upgrade > from 7.10 to 8.04 and then 8.10, with zero noticeable problems. The scary one is two independent reports of fstab corruption in the 8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from CD, mounting the partition, and editing fstab: the editor saves but the fstab returns to the original corrupt state upon reboot. Several reports of inability to use formerly working Japanese input methods. Several reports of formerly working xorg.conf suddenly reverting to VESA 1024x768x8 (or worse). I don't use Ubuntu so this is all hearsay, but I do trust the ex-NetBSD dev to be reporting accurately. He's only having problems with his custom X11 keymap getting trashed, and something else relatively minor with Xorg. And for that ML this is huge; I don't recall so many screams on a commercial vendor upgrade since Red Hat went from HJ Liu libc to glibc 2. ___ 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] ParseTuple question
[sorry, dropped one pair of mails off the list, hence also the overquoting] On Sunday 04 January 2009 01:07:08 Mark Hammond wrote: > > > On 'normal' windows you generally would need to use > > > WideCharToMultiByte() to get a 'char *' version of your wchar > > > string but I expect you already know that, so I doubt I understand > > > the question... > > > > Actually, I want the exact opposite. > > I'm not sure you can get it though :) Unless you can change Python itself, > you will be forced to convert filenames etc back and forward from wide to > narrow strings. This should roundtrip OK for all character in the current > code set. > > > 'char' strings under CE are mostly useless, in particular for > > filenames. Actually, they are useless under MS Windows in general, > > at least for the versions supported by Python 2.6/3.0, they all use > > UTF-16, only the desktop variants still have backward compatibility > > code to use 'char' strings, though with restricted functionality. > > Exactly - but for python 2.6, we are still somewhat forced to use that > 'char *' API in many cases. If the API didn't offer the automatic unicode > conversion, we would most likely have needed to implement it ourselves. > > > So, point is that I need a UTF-16 string in a function that might > > get either a string or a Unicode string. Preferably, I'd like to take > > the way that poses least resistance, so which one would you suggest? > > I'm not with you still: if a Python implemented function accepts either > string or unicode, then your utf16 string is perfect - its already unicode. > On the other hand, I thought you were faced with a Python function which, > as currently implemented, only accepts whatever the 's' format string > accepts. Such a function only accepts real PyString objects, so attempts at > passing it unicode will be futile. Obviously you could modify it to accept > a unicode, but clearly that would also mean adjusting everything that uses > the existing 'char *', which may end up fanning out to much more than you > expect. > > If I'm still misunderstanding, can you be more specific about the exact > problem (ie, the exact function you are referring to, and how you intend > calling it)? trunk/_fileio.c/fileio_init() Let's leave aside that you can also pass a filedescriptor, that function either takes a string or a Unicode string as first parameter. Now, under CE, I always need a 'wchar_t*' in order to open a file, how would I get at that easiest? My approach now is to simply use "O" as format specifier for the filename and then take a look at the object's type. If it is a char-string, I have to convert (under CE) or call the char-API (desktop MS Windows), if it is a Unicode string, I can use it as it is. Uli ___ 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] How to configure with icc on Mac?
>> CC=icc ./configure --prefix=$HOME/tmp/icc-python >> >> That failed computing the size of size_t because it tries to incorrectly link >> with -lgcc_s. Martin> Can you provide the relevant section of config.log? What is the Martin> precise command that configure is invoking, and what is the Martin> precise error message that icc reports? Sorry, should have been more complete in my report. I configured with CC='icc' ../configure --prefix=$HOME/tmp/icc-python --without-gcc That officially succeeds but is worthless because it overrode CC=icc from the command line with CC=cc. On my Mac cc == gcc. So, I fix that, at least temporarily, to demonstrate the error I'm getting, run autoreconf then repeat the above configure line. The failure is ... configure:10332: checking size of size_t configure:10637: icc -o conftest -g -O2 conftest.c >&5 ld: library not found for -lgcc_s configure:10641: $? = 1 configure: program exited with status 1 configure: failed program was: ... with fairly innocuous conftest.c source. BTW, I'm using autoconf 2.63. >> That failed because of a bug in configure.in: >> >> case $withval in >> no) CC=cc >> without_gcc=yes;; >> yes)CC=gcc >> without_gcc=no;; >> *) CC=$withval >> without_gcc=$withval;; >> >> It ignores the CC value on the command line. Martin> I don't think it is a bug. --without-gcc *overrides* the CC Martin> environment variable, rather than ignoring it. I don't think that's right. There's no telling what the non-gcc compiler is called. As far as I can tell you can't give any arguments to --without-gcc. All values I tried yielded errors: % ../configure --prefix=$HOME/tmp/icc-python --without-gcc=yes configure: error: invalid package name: gcc=yes % ../configure --prefix=$HOME/tmp/icc-python --without-gcc=icc configure: error: invalid package name: gcc=icc The only way I can see to tell it what compiler to use is to set CC and have the configure script use it. 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] python.org OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 4, 2009, at 11:26 AM, Stephen J. Turnbull wrote: Aahz writes: all. Because I was lazy, last weekend I finally did a two-stage upgrade from 7.10 to 8.04 and then 8.10, with zero noticeable problems. The scary one is two independent reports of fstab corruption in the 8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from CD, mounting the partition, and editing fstab: the editor saves but the fstab returns to the original corrupt state upon reboot. Several reports of inability to use formerly working Japanese input methods. Several reports of formerly working xorg.conf suddenly reverting to VESA 1024x768x8 (or worse). Just as a data point, we routinely upgrade our Ubuntu desktop machines as soon as the next version goes beta, exactly so we can help smooth out any hitches long before our users do. Some of us tend to be conservative, some radical, but we have a fairly wide range of systems and close interaction with our distro team. At any one time I have four or more Ubuntu boxes (servers, laptops, VMs, desktops) and I tend to upgrade them one at a time. For me, servers have been the easiest to upgrade. I've never had a problem with the OS specifically. I have had problems with certain applications (e.g. Moin) where it's usually a matter of sussing out all the new configuration changes, but I'm not sure you can avoid that. On the desktops, IME the most troublesome part is always X, mostly because it's a nightmare in its own right :) but also because my proprietary hardware drivers lag behind. I've had one or two problems with wireless. I've never had a problem with some of the crazier things I try, like encrypted file systems. Remember too, these are all beta upgrades. I'm not shy about contacting our excellent support team about these problems.I usually hold back at least one VM to upgrade to final, and that's always gone easier than any other OS, reflecting Aahz's experience. I don't doubt that people have problems upgrading, in fact for anything as complex as an operating system, it would be impossible to avoid. I'm biased of course, but I have to say our distro team does an excellent job here. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSWDnlnEjvBPtnXfVAQLIbwP+MiYoO0eBm77dc/nfyjHp593C1+CyprCQ 9TMNI5O5sD5VdiXWuhO5XSn6hvTf7tgZ4pAAQgYhcgapEoG3rYCjQ5RGs4jSdQTs SxLptzj4U2gODRFMNCOBspQf97krSGxp1UKFzRujUvPJP3NQw7Xp90FkT/rjLd3N iCAlNWtp2Hs= =FzKC -END PGP SIGNATURE- ___ 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] How to configure with icc on Mac?
>> ... >> configure:10332: checking size of size_t >> configure:10637: icc -o conftest -g -O2 conftest.c >&5 >> ld: library not found for -lgcc_s Martin> I think you have the source of the problem right there: your icc Martin> installation is broken. It is unable to build even trivial Martin> programs. Hmmm... All I did was download the installer from Intel's site and run it. Martin> To confirm this theory, take the source of the program, and Martin> invoke it with the very same command line. If it gives you the Martin> same error, then this has nothing to do with autoconf, or Martin> Python, or anything: that command line *must* work, or else the Martin> compiler is useless. Martin> Apparently, icc choses to invoke ld(1) with an option -lgcc_s, and Martin> apparently, ld(1) can't find the library. Why icc choses to do so, Martin> and why ld(1) can't find it, I don't know - this is a question to Martin> ask on Macintosh or icc mailing lists. I'll take a look at that. Thanks. Martin> I don't think it is a bug. --without-gcc *overrides* the CC Martin> environment variable, rather than ignoring it. >> >> I don't think that's right. There's no telling what the non-gcc compiler is >> called. Martin> Correct. To specify a different compiler, set the CC environment Martin> variable, and don't pass the --without-gcc flag. Hmmm, OK... Why do we need two ways to spell "don't use gcc"? 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] I would like an svn account
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 4, 2009, at 4:21 AM, Stephen J. Turnbull wrote: Steve Holden writes: Hey, isn't Ubuntu Debian-based? ... Ouch. I don't actually use Ubuntu, but when everybody on my local LUG list from the "Linux should be Windows but cheaper" newbies to former NetBSD developers is grouching about upgrade hell, I don't see any real benefits to be gained. You're still going to need to go with a "don't think about fixing what ain't broke, and even if it's just kinda broke, Just Say No to that upgrade dope" policy. No, something has to be done about the "no upgrades" policy, or it's not worth switching from Debian stable. One interesting thing about Ubuntu is that you can hook into the Personal Package Archives feature on Launchpad, so if you want to track newer versions of individual packages than either the distro or backports provides, you can do so using the standard package manager, with dependency tracking, etc. It's up to the PPA owner to make sure new releases are available to address things like security concerns and such. The bzr team is pretty good about that (I regularly run bzr from a PPA on my Ubuntu machines). B. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSWDt2HEjvBPtnXfVAQKjGwP8DHd+vp7ELDEtMNBZxNIktPJXAbYOtnP2 uSvueN3TIoguTtCLTMKuObhHems9bttIodroWxLQ4/8hGEAI3yPS7FTadxdO00hK FjJQffKaEaGOQ/bKdr/nTxCvArfzhYCSwSfYMFsq/85roM3UpsHirT9oyWjWyJIw p5nOczWAi70= =opqm -END PGP SIGNATURE- ___ 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] python.org OS
I missed the beginning here; oh well. On Sun, Jan 4, 2009 at 9:51 AM, Aahz wrote: > On Sun, Jan 04, 2009, Stephen J. Turnbull wrote: >> Steve Holden writes: >>> >>> Hey, isn't Ubuntu Debian-based? ... >> >> Ouch. I don't actually use Ubuntu, but when everybody on my local LUG >> list from the "Linux should be Windows but cheaper" newbies to former >> NetBSD developers is grouching about upgrade hell, I don't see any >> real benefits to be gained. You're still going to need to go with a >> "don't think about fixing what ain't broke, and even if it's just >> kinda broke, Just Say No to that upgrade dope" policy. In my experience, Ubuntu tends to stray away from the Way Things Are Traditionally Done, and this can be problematic, sometimes. Because they change things so drastically, they can do some pretty neat stuff, but if I decide I want to tweak something on my own, I usually find that they haven't provided a mechanism for changing something they've already changed (or at least not for a few releases). So, I blunder on ahead and mess with it, and when it comes time to upgrade, their scripts are expecting it to be the way they left it, but obviously it isn't that way, so it breaks horribly. Of course, if you aren't trying to mess with all manner of weird things (I think my latest trouble came from messing with pam and shared memory to get my audio software to run smoothly), it should be perfectly stable and upgradable. -- Cheers, Leif ___ 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] How to configure with icc on Mac?
On Sun, Jan 4, 2009 at 12:05 PM, wrote: > Hmmm, OK... Why do we need two ways to spell "don't use gcc"? Think of it like the two keys to the atom bomb. :-P -- Cheers, Leif ___ 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] How to configure with icc on Mac?
I downloaded an evaluation copy of the Intel compiler for Mac and tried (so
far unsuccessfully) to configure with it. I have tried:
CC=icc ./configure --prefix=$HOME/tmp/icc-python
That failed computing the size of size_t because it tries to incorrectly link
with -lgcc_s.
Then I tried forcing it to not use gcc:
CC=icc ./configure --without-gcc --prefix=$HOME/tmp/icc-python
That failed because of a bug in configure.in:
case $withval in
no) CC=cc
without_gcc=yes;;
yes)CC=gcc
without_gcc=no;;
*) CC=$withval
without_gcc=$withval;;
It ignores the CC value on the command line. I fixed that like so:
case $withval in
no) CC=${CC:-cc}
without_gcc=yes;;
yes)CC=gcc
without_gcc=no;;
*) CC=$withval
without_gcc=$withval;;
and reran autoconf. Now I'm back to the -lgcc_s problem. "gcc_s" is not
mentioned in configure. It's accessed implicitly. Poking around in the icc
man page didn't yield any obvious clues. (I did try using the -gcc-name and
-gxx-name flags. They didn't help.) Is there some way to configure Python
for use with icc on a Mac?
Thanks,
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] How to configure with icc on Mac?
> CC=icc ./configure --prefix=$HOME/tmp/icc-python > > That failed computing the size of size_t because it tries to incorrectly link > with -lgcc_s. Can you provide the relevant section of config.log? What is the precise command that configure is invoking, and what is the precise error message that icc reports? > That failed because of a bug in configure.in: > > case $withval in > no) CC=cc > without_gcc=yes;; > yes)CC=gcc > without_gcc=no;; > *) CC=$withval > without_gcc=$withval;; > > It ignores the CC value on the command line. I don't think it is a bug. --without-gcc *overrides* the CC environment variable, rather than ignoring it. 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] How to configure with icc on Mac?
>> ...
>> configure:10332: checking size of size_t
>> configure:10637: icc -o conftest -g -O2 conftest.c >&5
>> ld: library not found for -lgcc_s
Martin> I think you have the source of the problem right there: your icc
Martin> installation is broken. It is unable to build even trivial
Martin> programs.
Martin> To confirm this theory, take the source of the program, and
Martin> invoke it with the very same command line. If it gives you the
Martin> same error, then this has nothing to do with autoconf, or
Martin> Python, or anything: that command line *must* work, or else the
Martin> compiler is useless.
It compiled without error. Hmmm...
I added -v to the command. it does indeed ask for libgcc_s though it
specifies it with a version number:
ld -lcrt1.10.5.o -dynamic -arch x86_64 -weak_reference_mismatches
non-weak -o conftest
/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-//iccTRv8HW.o
-L/opt/intel/Compiler/11.0/056/lib -L/usr/lib/i686-apple-darwin9/4.0.1/
-L/usr/lib/ -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/x86_64
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1/
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../..
/opt/intel/Compiler/11.0/056/lib/libimf.a
/opt/intel/Compiler/11.0/056/lib/libsvml.a
/opt/intel/Compiler/11.0/056/lib/libipgo.a
/opt/intel/Compiler/11.0/056/lib/libdecimal.a
/opt/intel/Compiler/11.0/056/lib/libirc.a -lgcc_s.10.5 -lgcc
-lSystemStubs -lmx -lSystem /opt/intel/Compiler/11.0/056/lib/libirc.a
/opt/intel/Compiler/11.0/056/lib/libirc_s.a -ldl
This is from the same shell where the configure run failed so I'm fairly
certain it can't be related to a different set of environment variables.
The only possible environment change would seem to be something configure
imposed. I added -v to the ac_link command to see what it was generating
for the ld command:
ld -lcrt1.o -dynamic -arch x86_64 -weak_reference_mismatches non-weak
-macosx_version_min 10.3 -o conftest
/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-//iccTIMK7D.o
-L/opt/intel/Compiler/11.0/056/lib -L/usr/lib/i686-apple-darwin9/4.0.1/
-L/usr/lib/ -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/x86_64
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1/
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../..
/opt/intel/Compiler/11.0/056/lib/libimf.a
/opt/intel/Compiler/11.0/056/lib/libsvml.a
/opt/intel/Compiler/11.0/056/lib/libipgo.a
/opt/intel/Compiler/11.0/056/lib/libdecimal.a
/opt/intel/Compiler/11.0/056/lib/libirc.a -lgcc_s -lgcc -lSystemStubs
-lmx -lSystem /opt/intel/Compiler/11.0/056/lib/libirc.a
/opt/intel/Compiler/11.0/056/lib/libirc_s.a -ldl
I searched back through config.log looking for gcc_s. I noticed that the
ld command used for -fno-strict-aliasing linked against -lgcc_s.10.5 but
that the check for -Olimit 1500 linked against -lgcc_s. In between there is
this block of code:
# Calculate the right deployment target for this build.
#
cur_target=`sw_vers -productVersion | sed
's/\(10\.[[0-9]]*\).*/\1/'`
if test ${cur_target} '>' 10.2; then
cur_target=10.3
fi
if test "${UNIVERSAL_ARCHS}" = "all"; then
# Ensure that the default platform for a 4-way
# universal build is OSX 10.5, that's the first
# OS release where 4-way builds make sense.
cur_target='10.5'
fi
CONFIGURE_MACOSX_DEPLOYMENT_TARGET=${MACOSX_DEPLOYMENT_TARGET-${cur_target}}
# Make sure that MACOSX_DEPLOYMENT_TARGET is set in the
# environment with a value that is the same as what we'll use
# in the Makefile to ensure that we'll get the same compiler
# environment during configure and build time.
MACOSX_DEPLOYMENT_TARGET="$CONFIGURE_MACOSX_DEPLOYMENT_TARGET"
export MACOSX_DEPLOYMENT_TARGET
EXPORT_MACOSX_DEPLOYMENT_TARGET=''
I stuck in an echo after the export statement:
...
checking whether icc accepts -fno-strict-aliasing... yes
>>> 10.3
checking whether icc accepts -OPT:Olimit=0... (cached) no
...
When I installed Xcode I didn't include the 10.3 stuff since I don't run
that version anymore, so it's quite possible I have a somehow "deficient"
Xcode install. Still, the 10.3 stuff is not installed by default these days
so it shouldn't be required.
This code looks suspicious:
if test ${cur_target} '>' 10.2; then
cur_target=10.3
fi
If I comment it out configure succeeds. This code dates from r65061 which
states:
#3381 fix framework builds on 10.4
Maybe it should be
if test ${cur_target} '>' 10.2 -a ${cur_t
Re: [Python-Dev] How to configure with icc on Mac?
> ... > configure:10332: checking size of size_t > configure:10637: icc -o conftest -g -O2 conftest.c >&5 > ld: library not found for -lgcc_s I think you have the source of the problem right there: your icc installation is broken. It is unable to build even trivial programs. To confirm this theory, take the source of the program, and invoke it with the very same command line. If it gives you the same error, then this has nothing to do with autoconf, or Python, or anything: that command line *must* work, or else the compiler is useless. Apparently, icc choses to invoke ld(1) with an option -lgcc_s, and apparently, ld(1) can't find the library. Why icc choses to do so, and why ld(1) can't find it, I don't know - this is a question to ask on Macintosh or icc mailing lists. > Martin> I don't think it is a bug. --without-gcc *overrides* the CC > Martin> environment variable, rather than ignoring it. > > I don't think that's right. There's no telling what the non-gcc compiler is > called. Correct. To specify a different compiler, set the CC environment variable, and don't pass the --without-gcc flag. 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] python.org OS
Stephen J. Turnbull wrote: > And for that ML this is huge; I don't recall so many screams on a > commercial vendor upgrade since Red Hat went from HJ Liu libc to glibc > 2. I've had problems with Kubuntu's graphical updater crashing, but never anything a "sudo apt-get dist-upgrade" didn't fix. Although I'm still on Kubuntu 8.04 - KDE 4 isn't far enough along for me to consider switching to 8.10, so I probably won't be upgrading again until the next LTS release. (Also, if the infrastructure committee *do* consider using Ubuntu for any of the python.org servers, then the LTS releases are the ones that should probably be considered, rather than the 6-monthly ones). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] python.org OS
On Sun, Jan 04, 2009, Stephen J. Turnbull wrote: > Steve Holden writes: >> >> Hey, isn't Ubuntu Debian-based? ... > > Ouch. I don't actually use Ubuntu, but when everybody on my local LUG > list from the "Linux should be Windows but cheaper" newbies to former > NetBSD developers is grouching about upgrade hell, I don't see any > real benefits to be gained. You're still going to need to go with a > "don't think about fixing what ain't broke, and even if it's just > kinda broke, Just Say No to that upgrade dope" policy. What kind of upgrade hell are you talking about? I have used several different Linux distributions, Windows, and OS X, and I have to say that upgrading Ubuntu has been by far the easist and least painful of them all. Because I was lazy, last weekend I finally did a two-stage upgrade from 7.10 to 8.04 and then 8.10, with zero noticeable problems. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "roses are reddish, violets are bluish, Chanukah is 8 days, don't you wish you were Jewish?" ___ 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] How to configure with icc on Mac?
Martin v. Löwis schrieb: >> ... >> configure:10332: checking size of size_t >> configure:10637: icc -o conftest -g -O2 conftest.c >&5 >> ld: library not found for -lgcc_s > > I think you have the source of the problem right there: your icc > installation is broken. It is unable to build even trivial programs. > > To confirm this theory, take the source of the program, and invoke > it with the very same command line. If it gives you the same error, > then this has nothing to do with autoconf, or Python, or anything: > that command line *must* work, or else the compiler is useless. > > Apparently, icc choses to invoke ld(1) with an option -lgcc_s, and > apparently, ld(1) can't find the library. Why icc choses to do so, > and why ld(1) can't find it, I don't know - this is a question to > ask on Macintosh or icc mailing lists. > >> Martin> I don't think it is a bug. --without-gcc *overrides* the CC >> Martin> environment variable, rather than ignoring it. >> >> I don't think that's right. There's no telling what the non-gcc compiler is >> called. > > Correct. To specify a different compiler, set the CC environment > variable, and don't pass the --without-gcc flag. If I read that code correctly, you can also do ./configure --with-gcc=icc which is however not much less confusing. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] I would like an svn account
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 3, 2009, at 11:29 PM, Steve Holden wrote: Brett Cannon wrote: [...] I have been using bzr for all of my importlib work. It's worked out well sans the problem that SOMEONE Barry has not upgraded the bzr installation to support the newest wire protocol. If you think *that's* a problem try getting him to write a simple bloody blog entry ... Ouch. That's the thanks I get. And you didn't even post a url to help increase my net.fame. i-can-say-this-now-the-entry-is-published-ly y'rs - steve B. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSWDr/XEjvBPtnXfVAQJu0gQAqBnayG5cwKJ7N7FRFRoaaeyT38xKjnZ0 Y1l8qKWx1ErN92rKPfeVf28XAqxaedE9rNUOPd2PVOEjU61Pbf7mHEY7yjFk7jZT nuHoAuvTUPh8Ip5nkVmfh4LzpX6Z/3uuP5+aMz1QI0nREXok9pPTtKsktZo4UiLU CJrk/Gzpl+g= =Y8O9 -END PGP SIGNATURE- ___ 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] I would like an svn account
Disclaimer: I'm a member of the team working with Brett on the DVCS PEP, and definitely pro-DVCS (specifically working on the git parts). "Martin v. Löwis" writes: > If "switching to a modern DVCS" means that users now need to start > compiling their VCS before they can check out Python, It doesn't mean that. All of the DVCS contenders have Windows and Mac OS installers (usually from 3rd parties, but working closely with the core). For *nix users, does anybody really use a vanilla Debian stable for a development workstation? Everybody else has reasonably fresh versions available via the standard package manager, even Debian Lenny. > I don't think we should switch to a modern DVCS. Such a system must > be mature, and if it isn't included in Debian stable, it can't be > mature (and free software). The versions in Debian stable were all usable for their time, but this is a rapidly developing field, even when, like Subversion, your goal is to refactor software designed in the early 1990s! "It's in Debian stable" is an excessively strict standard for the client's version. > In the specific case, if a decision is made to switch to bazaar, and > bzr 1.5 is recent enough, then I'd be happy to upgrade to testing > (although 1.5 is also available from backports, and already installed; > stable has *bzr 0.11*). Since lenny was frozen, bzr managed to release > 5 minor versions (so it is 1.10 now); this makes me very worried > whether this software is mature. The bzr team is experimenting with a time-based release process; the rate at which minor versions appear should not worry you. More important is the count of new repository formats. There are about 5 currently in common use. Great efforts are made to keep them interoperable, though some are not. Python should avoid use of those for the near future but I don't think it should be considered a showstopper. ___ 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] py3k, bad sys.path and abort()
Mark Hammond schrieb: > Would it be practical and desirable to handle this situation more > gracefully, possibly just leaving sys.std* set to None and letting > whatever exceptions then occur happen as normal without terminating the > process? Given it is an edge-case, I thought I'd open it here for > discussion before putting work into a patch or opening a bug. It's probably more helpful to keep the stderrprinter objects (Object/fileobject.c) than setting stderr and stdout to None. At least you can print something to stderr and stdout. On the other hand neither GUI apps nor NT services have standard streams. You'll probably get it right :) Christian ___ 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] How to configure with icc on Mac?
Martin v. Löwis v.loewis.de> writes: > > Correct. To specify a different compiler, set the CC environment > variable, and don't pass the --without-gcc flag. Perhaps --without-gcc should be removed, if it's both useless and misleading? (note: I don't have an interest in the matter) ___ 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] How to configure with icc on Mac?
> This code looks suspicious:
>
> if test ${cur_target} '>' 10.2; then
> cur_target=10.3
> fi
>
> If I comment it out configure succeeds. This code dates from r65061
No, it dates from r45800:
r45800 | ronald.oussoren | 2006-04-29 13:31:35 +0200 (Sa, 29. Apr 2006)
| 2 lines
Patch 1471883: --enable-universalsdk on Mac OS X
I think the intention is that the binaries built work on OSX 10.3 and
later, hence OSX_DEPLOYMENT_TARGET is set to 10.3.
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] How to configure with icc on Mac?
> Perhaps --without-gcc should be removed, if it's both useless and misleading? > (note: I don't have an interest in the matter) I had the same thought. 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
[Python-Dev] Why is there still a PRINT_EXPR opcode in Python 3?
Since print is now a builtin function why is there still a PRINT_EXPR opcode? 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] Wrong buildbot page for 3.x-stable
> Isn't the latter supposed to point to the py3k branch buildbots? Thanks for pointing that out - it is fixed now. 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] Why is there still a PRINT_EXPR opcode in Python 3?
On Sun, Jan 4, 2009 at 5:28 PM, wrote: > Since print is now a builtin function why is there still a PRINT_EXPR > opcode? I believe it's used in the interactive interpreter to display the repr of an expression. -- Regards, Benjamin ___ 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] Why is there still a PRINT_EXPR opcode in Python 3?
>> Since print is now a builtin function why is there still a PRINT_EXPR >> opcode? Benjamin> I believe it's used in the interactive interpreter to display Benjamin> the repr of an expression. Wouldn't it make more sense for the interactive interpreter to call print(repr(expr)) ? 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] Why is there still a PRINT_EXPR opcode in Python 3?
On Sun, Jan 4, 2009 at 5:36 PM, wrote: > >>> Since print is now a builtin function why is there still a PRINT_EXPR >>> opcode? > >Benjamin> I believe it's used in the interactive interpreter to display >Benjamin> the repr of an expression. > > Wouldn't it make more sense for the interactive interpreter to call > >print(repr(expr)) I'm not sure about the reasoning for keeping PRINT_EXPR alive. When I look at the code of PyRun_InteractiveOne, it seems it should be possible to kill it off. -- Regards, Benjamin ___ 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] I would like an svn account
Barry Warsaw wrote: > On Jan 3, 2009, at 11:29 PM, Steve Holden wrote: > >> Brett Cannon wrote: >> [...] >>> I have been using bzr for all of my importlib work. It's worked out >>> well sans the problem that SOMEONE Barry has not >>> upgraded the bzr installation to support the newest wire protocol. >>> >> If you think *that's* a problem try getting him to write a simple bloody >> blog entry ... > > Ouch. That's the thanks I get. And you didn't even post a url to help > increase my net.fame. > http://onyourdesktop.blogspot.com/2008/12/barry-warsaw.html always-willing-to-oblige-ly yr's - steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] python.org OS
Stephen J. Turnbull wrote: > Aahz writes: > > > all. Because I was lazy, last weekend I finally did a two-stage upgrade > > from 7.10 to 8.04 and then 8.10, with zero noticeable problems. > > The scary one is two independent reports of fstab corruption in the > 8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from > CD, mounting the partition, and editing fstab: the editor saves but > the fstab returns to the original corrupt state upon reboot. > > Several reports of inability to use formerly working Japanese input > methods. Several reports of formerly working xorg.conf suddenly > reverting to VESA 1024x768x8 (or worse). > You can add my name to those reporting inexplicable reversion of video settings. I'm getting tired of it seeing a 640 x 480 screen. > I don't use Ubuntu so this is all hearsay, but I do trust the > ex-NetBSD dev to be reporting accurately. He's only having problems > with his custom X11 keymap getting trashed, and something else > relatively minor with Xorg. > > And for that ML this is huge; I don't recall so many screams on a > commercial vendor upgrade since Red Hat went from HJ Liu libc to glibc > 2. Ubuntu is a victim of its own success. They now have to deal with the same diversity of hardware environments as Windows. I hope that Canonical will find a way to stabilize things. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.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] How to configure with icc on Mac?
s...@pobox.com writes: > >> That failed because of a bug in configure.in: > >> > >> case $withval in > >> no) CC=cc > >> without_gcc=yes;; > >> yes)CC=gcc > >> without_gcc=no;; > >> *) CC=$withval > >> without_gcc=$withval;; > >> > >> It ignores the CC value on the command line. > > Martin> I don't think it is a bug. --without-gcc *overrides* the CC > Martin> environment variable, rather than ignoring it. > > I don't think that's right. There's no telling what the non-gcc compiler is > called. As far as I can tell you can't give any arguments to --without-gcc. That's right. The theory is that there's a vendor default compiler installed as "cc" on PATH, and there's GCC. configure tries to encourage use of GCC, but you can use the vendor compiler with --without-gcc, which is 100% equivalent to --with-gcc=no. But you *can* give arguments to --with-gcc. If you want to use a different compiler, use --with-gcc=a-different-compiler. If autoconf and configure.in are written correctly, GCC-dependent features will be bracketed with case "$without_gcc" in no ) gcc* ) # test for and configure GCC feature here ;; icc* ) # optional # test for and configure similar icc feature here ;; * ) # test for and configure similar portable feature here ;; Don't flame me if you agree with me that this is a poor interface. The option should be --with-compiler, of course. ___ 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] python.org OS
Barry Warsaw writes: > > The scary one is two independent reports of fstab corruption in the > > 8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from > > CD, mounting the partition, and editing fstab: the editor saves but > > the fstab returns to the original corrupt state upon reboot. > For me, servers have been the easiest to upgrade. I've never had a > problem with the OS specifically. I have had problems with certain > applications [...]. On the desktops, IME the most troublesome part > is always X, [...]. This certainly conforms to what I've seen on that LUG list. Since nobody on that list is running Ubuntu server, the "scary one" (quoted above) can probably be discounted, too. That looks like some user-friendliness run amok. ___ 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] python.org OS
On Sun, Jan 4, 2009 at 8:51 PM, Steve Holden wrote:
> Ubuntu is a victim of its own success. They now have to deal with the
> same diversity of hardware environments as Windows. I hope that
> Canonical will find a way to stabilize things.
I think it's actually worse. Microsoft can always (and, in my
experience, often does) restrict their support to hardware sets
approved for "Windows ver. N". Custom-built or upgraded
("tampered-with") boxes often get worse (or no) support than OEM
boxes. Linux distributions, on the other hand, are expected to
provide support for any hardware. In this respect, since Ubuntu has a
larger user base, and therefore a larger range of hardware sets, yes,
their job is difficult, but I'm not sure this is a victimization,
rather more of an inherent issue exacerbated by its success. Either
way, it does kind of suck.
On Sun, Jan 4, 2009 at 11:26 PM, Stephen J. Turnbull wrote:
> This certainly conforms to what I've seen on that LUG list. Since
> nobody on that list is running Ubuntu server, the "scary one" (quoted
> above) can probably be discounted, too. That looks like some
> user-friendliness run amok.
True, most of the upgrade problems deal with packages that aren't in
the server install. This should be an easy one, but now I'd ask, why
not use Debian instead?
--
Cheers,
Leif
___
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
