[issue2142] difflib.unified_diff(...) produces invalid patches
Trent Mick added the comment: c.f. some discussion on python-dev here: http://mail.python.org/pipermail/python-dev/2010-October/104501.html -- ___ Python tracker <http://bugs.python.org/issue2142> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] difflib.unified_diff(...) produces invalid patches
Changes by Trent Mick : -- assignee: -> trentm ___ Python tracker <http://bugs.python.org/issue2142> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8029] bug in 2to3 dealing with "print FOO, " followed by "sys.stdout.write('')"
New submission from Trent Mick :
According to
http://docs.python.org/reference/simple_stmts.html#the-print-statement the
following with result in the print statement NOT printing a trailing space:
import sys
print u"ASD",; sys.stdout.write(u"")
However, 2to3 currently translates this to:
import sys
print("ASD", end=' '); sys.stdout.write("")
It *should* translate to:
import sys
print("ASD", end='')
You can also see the discussion of this on this lib3to2 bug report:
http://bitbucket.org/amentajo/lib3to2/issue/13/print-3-end-isnt-translated-properly
and translation of this between 2to3 and 3to2 here:
http://pythontranslationparty.appspot.com/6004/
--
components: 2to3 (2.x to 3.0 conversion tool)
messages: 100194
nosy: trentm
severity: normal
status: open
title: bug in 2to3 dealing with "print FOO," followed by "sys.stdout.write('')"
___
Python tracker
<http://bugs.python.org/issue8029>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate Python interpreter (so 3.1's idle.bat does not accidently use python26.exe)
Changes by Trent Mick : -- nosy: +trentm ___ Python tracker <http://bugs.python.org/issue6378> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used for 'runtime_library_dirs'
Trent Mick added the comment: Tarek, This should not affect anyone using gcc or g++ on AIX because of this check just before the lines added by this patch: elif compiler[:3] == "gcc" or compiler[:3] == "g++": return "-Wl,-R" + dir The intention of the patch is to fix linker argument handling with NOT using gcc, i.e. when using IBM's native AIX compiler. -- ___ Python tracker <http://bugs.python.org/issue6164> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char (same with context_diff)
Trent Mick added the comment: Here is a new patch that also fixes the same issue in difflib.context_diff() and adds a couple test cases. -- stage: test needed -> patch review title: naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char -> naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char (same with context_diff) Added file: http://bugs.python.org/file14082/python_difflib_no_eol.patch ___ Python tracker <http://bugs.python.org/issue2142> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3073] Cookie.Morsel breaks in parsing cookie values with whitespace
Changes by Trent Mick <[EMAIL PROTECTED]>: -- nosy: +trentm ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3073> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC
Trent Mick <[EMAIL PROTECTED]> added the comment: > What if you compile using 'gcc -arch ppc64 main.c'? $ gcc -arch ppc64 main.c $ ./a.out sizeof(_Bool) is 1 As you figured out. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC
Trent Mick <[EMAIL PROTECTED]> added the comment:
> I get:
>
> sizeof(_Bool)=4 bytes
>
> on a G4 PPC.
Same thing on a G5 PPC:
$ cat main.c
#include
int main(void) {
printf("sizeof(_Bool) is %d\n", sizeof(_Bool));
}
$ gcc main.c
$ ./a.out
sizeof(_Bool) is 4
--
title: PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS
X/PowerPC -> PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS
X/PowerPC
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4060>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC
Trent Mick <[EMAIL PROTECTED]> added the comment: > Added file: http://bugs.python.org/file11723/pymacconfig.h.patch I'll test that on my end tomorrow -- though it looks like it will work fine. Thanks. -- title: PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC -> PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
=?utf-8?q?[issue4060]_PyUnicode=5FDecodeUTF16(..., =09byteorder=3D0)_gets_it_wrong_on_Mac_OS_X/PowerPC?=
Changes by Trent Mick <[EMAIL PROTECTED]>: -- keywords: +patch Added file: http://bugs.python.org/file11720/issue4060_macosx_endian.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
=?utf-8?q?[issue4060]_PyUnicode=5FDecodeUTF16(..., =09byteorder=3D0)_gets_it_wrong_on_Mac_OS_X/PowerPC?=
Trent Mick <[EMAIL PROTECTED]> added the comment: > BTW: Does this simplified approach really work for Python on Mac OS X It works for Python 2.5: http://svn.python.org/view/*checkout*/python/branches/release25-maint/configure.in?rev=66299 search for "BIGENDIAN". ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
=?utf-8?q?[issue4060]_PyUnicode=5FDecodeUTF16(..., =09byteorder=3D0)_gets_it_wrong_on_Mac_OS_X/PowerPC?=
Trent Mick <[EMAIL PROTECTED]> added the comment: > Does this also affect sys.byteorder and the struct module ? Doesn't seem to affect sys.byteorder: $ /usr/bin/python -c "import sys; print sys.byteorder" big $ python2.6 -c "import sys; print sys.byteorder" big > I think those would be more important to get right than the UTF-16 > codec, since this only uses the native byte ordering for increased > performance and compatibility with other OS tools. Since UTF-16 is not > wide-spread on Mac OS X, it's not so much an issue... It is an issue for Python extensions that use that API. For example, it is the cause of recent Komodo builds not starting Mac OS X/PowerPC (http://bugs.activestate.com/show_bug.cgi?id=79366) because the PyXPCOM extension and embedded Python 2.6 build was getting UTF-16 data mixed up when talking with Mozilla APIs. it would be on > Windows. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC
Trent Mick <[EMAIL PROTECTED]> added the comment:
This also shows up in the byte ordering that Python uses to encode utf-16:
$ uname -a
Darwin sphinx 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00
PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
$ python2.6 -c "import codecs; codecs.open('26.txt', 'w',
'utf-16').write('hi')"
$ od -cx 26.txt
000 377 376 h \0 i \0
fffe68006900
006
$ /usr/bin/python -c "import codecs; codecs.open('system.txt', 'w',
'utf-16').write('hi')"
$ od -cx system.txt
000 376 377 \0 h \0 i
feff00680069
006
The BOM here ensures, of course, that this is still valid UTF-16
content, but the difference in behaviour here btwn Python versions might
not be intended.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4060>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4060] PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC
New submission from Trent Mick <[EMAIL PROTECTED]>: Revision 63955 removed a block from configure.in (and effectively from pyconfig.h.in) having to do with endianness that results in an incorrect setting for "WORDS_BIGENDIAN" in Universal builds on Mac OS X. The removed part was this: > AH_VERBATIM([WORDS_BIGENDIAN], > [ > /* Define to 1 if your processor stores words with the most significant byte > first (like Motorola and SPARC, unlike Intel and VAX). > > The block below does compile-time checking for endianness on platforms > that use GCC and therefore allows compiling fat binaries on OSX by using > '-arch ppc -arch i386' as the compile flags. The phrasing was choosen > such that the configure-result is used on systems that don't use GCC. > */ > #ifdef __BIG_ENDIAN__ > #define WORDS_BIGENDIAN 1 > #else > #ifndef __LITTLE_ENDIAN__ > #undef WORDS_BIGENDIAN > #endif > #endif]) This used to allow "WORDS_BIGENDIAN" to be correct for all parts of a universal Python build done via `gcc -arch i386 -arch ppc ...`. This was originally added for issue 1471883 (see msg50040 for a discussion of this particular bit). The result of this bug is that Python extensions using either of the following to get native byte ordering for UTF-16 decoding: PyUnicode_DecodeUTF16(..., byteorder=0); PyUnicode_DecodeUTF16Stateful(..., byteorder=0, ...); on Mac OS X/PowerPC with a universal build built on Intel hardware (most such builds) will get the wrong byte-ordering. The fix is to restore that section to configure.in and re-run autoconf and autoheader. Ronald, Was there are particular reason that this block was removed from configure.in (and pyconfig.h.in)? I'd like to hear comments from either Ronald or Martin, and then I can commit the fix. -- components: Unicode messages: 74398 nosy: loewis, ronaldoussoren, trentm severity: normal status: open title: PyUnicode_DecodeUTF16(..., byteorder=0) gets it wrong on Mac OS X/PowerPC type: behavior versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4060> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3905] subprocess failing in GUI applications on Windows
Trent Mick <[EMAIL PROTECTED]> added the comment: The failure is in the DuplicateHandle call that subprocess makes on, in this case, the stdin handle (as returned by `GetStdHandle(STD_INPUT_HANDLE)`) call earlier. Two cases here: 1. When this is run in a subsystem:windows process (like PythonWin or IDLE) that is launched from Windows Explorer (e.g. from a Start Menu shortcut or Desktop shortcut) then `GetStdHandle(STD_INPUT_HANDLE)` returns None. [http://msdn.microsoft.com/en-us/library/ms683231(VS.85).aspx] > If an application does not have associated standard handles, > such as a service running on an interactive desktop, and has > not redirected them, the return value is NULL. In this case you *don't* get the error that Todd described, because the code path taken in subprocess.py then use CreatePipe for the `p2cread` variable on which `DuplicateHandle` is called. 2. However, when the subsystem:windows process is launched from the cmd.exe shell the `GetStdHandle` call returns a value -- in Todd's and my testing, the value 3. The code path in subprocess.py then calls `DuplicateHandle` on this in `Popen._make_inheritable`. This fails with traceback Todd posted. My *guess* at what the problem is stems from this comment in the MSDN docs on console handles: [http://msdn.microsoft.com/en-us/library/ms682075(VS.85).aspx] > A process can use the DuplicateHandle function to create a > duplicate console handle that has different access or > inheritability from the original handle. Note, however, > that a process can create a duplicate console handle only > for its own use. This differs from other handle types (such > as file, pipe, or mutex objects), for which DuplicateHandle > can create a duplicate that is valid for a different process. My guess is that the stdin handle (3) is inherited from the shell (cmd.exe) and attempting to `DuplicateHandle` on it violates the clause that you can on dupe a console handle of your own. I'm not sure of that though. Anyone else have more light to shed on this? If this is the case I'm not sure what a possible or good solution could be for subprocess. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3905> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick <[EMAIL PROTECTED]> added the comment: Thanks Ronald. Any comment on http://bugs.python.org/msg69936 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3381> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick <[EMAIL PROTECTED]> added the comment: This bug should be re-opened. The patch to configure.in wasn't quite right. I'm attaching a slight fix. `autoconf`ing removes one level of square brackets in the 'sed' command to create $tgt. (Q about the issue tracker: I'm unable to change the "Status" field on this bug. I'm guessing that is "by design", right? I.e., only certain people have the privs to change bug status?) -- keywords: +patch type: -> compile error Added file: http://bugs.python.org/file10956/issue3381_configure_fix.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3381> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955
Trent Mick <[EMAIL PROTECTED]> added the comment: > The current trunk should be correct, there are no explicit calls to the > arch command left, all go through the configure replacement magic. $ svn info Path: . URL: svn+ssh://[EMAIL PROTECTED]/python/trunk/Mac Repository Root: svn+ssh://[EMAIL PROTECTED] Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 65091 Node Kind: directory Schedule: normal Last Changed Author: ronald.oussoren Last Changed Rev: 65091 Last Changed Date: 2008-07-17 22:48:03 -0700 (Thu, 17 Jul 2008) Properties Last Updated: 2008-07-17 22:55:32 -0700 (Thu, 17 Jul 2008) [EMAIL PROTECTED]:~/src/python/Mac] $ svn up Makefile.in At revision 65091. [EMAIL PROTECTED]:~/src/python/Mac] $ grep "arch -" Makefile.in $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(srcdir)/scripts/BuildApplet.py \ $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(CACHERSRC) -v $(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST) Apologies if I am missing something. Your patches for issue 3381 did not include a change to Mac/Makefile.in. Trent ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick <[EMAIL PROTECTED]> added the comment: Ronald, The @ARCH_RUN_32BIT@ also needs to be added to two places in Mac/Makefile.in (as indicated in issue 3393), no? Would you like me to make that change? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3381> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955
Trent Mick <[EMAIL PROTECTED]> added the comment: Alternative potential solution: use the ARCHPREFERENCE environment variable as described in the Mac OS X 10.5 arch man page. Ronald, if you could test if that works for you on 10.5, then presumably setting that environment var would be safely ignored on Mac OS X <10.5. Thoughts? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955
Trent Mick <[EMAIL PROTECTED]> added the comment: Similar change in Mac/IDLE/Makefile.in: - --- python/trunk/Mac/IDLE/Makefile.in (original) +++ python/trunk/Mac/IDLE/Makefile.in Thu Jun 5 14:58:24 2008 @@ -42,7 +42,7 @@ $(srcdir)/../Icons/PythonSource.icns \ $(srcdir)/../Icons/PythonCompiled.icns Info.plist rm -fr IDLE.app - $(RUNSHARED) $(BUILDPYTHON) $(BUNDLEBULDER) \ + $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(BUNDLEBULDER) \ --builddir=. \ --name=IDLE \ --link-exec \ - ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3393] `cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955
New submission from Trent Mick <[EMAIL PROTECTED]>: http://svn.python.org/view?rev=63955&view=rev "MacOS X: Enable 4-way universal builds ..." This revision made the following change to Mac/Makefile.in: http://svn.python.org/view/python/trunk/Mac/Makefile.in?rev=63955&view=diff&r1=63955&r2=63954&p1=python/trunk/Mac/Makefile.in&p2=/python/trunk/Mac/Makefile.in The last hunk (part of the "installmacsubtree" target) and a bit of the preceding hunk uses `arch` with arguments: - install_BuildApplet: - $(RUNSHARED) $(BUILDPYTHON) $(srcdir)/scripts/BuildApplet.py \ + $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(srcdir)/scripts/BuildApplet.py \ --destroot "$(DESTDIR)" \ - --python $(INSTALLED_PYTHONAPP) \ + --python=$(prefix)/Resources/Python.app/Contents/MacOS/$(PYTHONFRAMEWORK)`test -f "$(DESTDIR)$(prefix)/Resources/Python.app/Contents/MacOS/$(PYTHONFRAMEWORK)-32" && echo "-32"` \ --output "$(DESTDIR)$(PYTHONAPPSDIR)/Build Applet.app" \ $(srcdir)/scripts/BuildApplet.py @@ -225,7 +279,7 @@ done - $(RUNSHARED) $(BUILDPYTHON) $(CACHERSRC) -v $(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST) + $(RUNSHARED) arch -ppc -i386 $(BUILDPYTHON) $(CACHERSRC) -v $(DESTDIR)$(MACLIBDEST) $(DESTDIR)$(MACTOOLSDEST) $(RUNSHARED) $(BUILDPYTHON) -Wi -tt $(compileall) -d $(MACTOOLSDEST) -x badsyntax $(DESTDIR)$(MACTOOLSDEST) $(RUNSHARED) $(BUILDPYTHON) -O -Wi -tt $(compileall) -d $(MACTOOLSDEST) -x badsyntax $(DESTDIR)$(MACTOOLSDEST) - That form of calling `arch` is only supported on Mac OS X 10.5 (Leopard), I believe. -- $ sw_vers ProductName:Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S2167 $ man arch | cat ARCH(1) BSD General Commands Manual ARCH(1) NAME arch -- print architecture type SYNOPSIS arch DESCRIPTION The arch command displays the machine's architecture type. SEE ALSO machine(1) Mac OS August 20, 1997 Mac OS -- Here is the current man page for arch (I had to look to try to see what Ronald was trying to do with the Makefile change) :) http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/arch.1.html I don't fully understand why the "arch -ppc -i386" is necessary for "$(BUILDPYTHON)". I'm not sure what the easiest solution to this would be... or if supporting "make frameworkinstallframework" (which eventually calls this target) on Mac OS X <10.5 is considered important enough. Perhaps a new [EMAIL PROTECTED]@ could be added to Mac/Makefile.in with the associated configure support to have that be blank unless `--with-universal-archs=all` was specified? -- components: Build messages: 69890 nosy: ronaldoussoren, trentm severity: normal status: open title: `cd Mac && make installmacsubtree` fails on Mac OS X < 10.5 because of r63955 type: compile error versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3393> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick <[EMAIL PROTECTED]> added the comment: > Yet another version: configure-patch-3381-2.txt is a slight enhancement > of the first version. Ronald, Did that accidentally not get attached? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3381> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
Trent Mick <[EMAIL PROTECTED]> added the comment: > BTW. Feel free to commit if the patch works for you, I'm rather swamped > at work and won't be able to test on 10.4 anytime soon. Thanks for the quick patches. Other than verifying that `configure && make` works on 10.4 what specifically should I do "to ensure that tests are done using the right SDK" (as you said in an earlier comment)? -- title: `./configure --enable-framework --enable-universalsdk` fails because of change in r63997 -> `./configure --enable-framework --enable-universalsdk` fails because of change in r63997 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3381> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3381] `./configure --enable-framework --enable-universalsdk` fails because of change in r63997
New submission from Trent Mick <[EMAIL PROTECTED]>:
Configuring with "--enable-universalsdk" fails on Mac OS X 10.4/x86
because of a change in r63997. This in the python trunk (i.e. the 2.6 tree).
The failure looks like this:
$ ./configure --enable-framework --enable-universalsdk
...
checking for log1p... no
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for wchar_t... yes
checking size of wchar_t... configure: error: cannot compute sizeof
(wchar_t)
See `config.log' for more details.
And the appropriate details in config.log are:
...
configure:21540: checking size of wchar_t
configure:21875: gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk conftest.c >&5
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
/usr/bin/ld: -syslibroot: multiply specified
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//cctmsJ7u.out (No such file or
directory)
configure:21878: $? = 1
configure: program exited with status 1
configure: failed program was:
...
The command being run:
gcc -o conftest -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2 -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk conftest.c
is "$ac_link". Here is a dump of relevant variables at that point in
"configure":
--
LDFLAGS is "-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk "
CFLAGS is "-arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -O2"
CPPFLAGS is ""
CC is "gcc"
ac_link is "$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
conftest.$ac_ext $LIBS >&5"
--
The problem is that r63997
(http://mail.python.org/pipermail/python-checkins/2008-June/070612.html)
added this line to "configure.in" for Mac OS X:
CFLAGS="${UNIVERSAL_ARCH_FLAGS} -isysroot ${UNIVERSALSDK} ${CFLAGS}"
That results in the failure above: "ld" complaining about
-isysroot/-syslibroot being specified twice on the command line.
Ronald,
What was the "build issue on OSX 10.4" that the was meant to be fixed.
Can it be fixed without that "configure" change to "CFLAGS"?
--
components: Build
messages: 69805
nosy: ronaldoussoren, trentm
severity: normal
status: open
title: `./configure --enable-framework --enable-universalsdk` fails because of
change in r63997
versions: Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3381>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char
Trent Mick added the comment: At a glance I suspect this patch will work back to Python 2.3 (when difflib.unified_diff() was added). I haven't looked at the Py3k tree yet. Note: This *may* also applied to difflib.context_diff(), but I am not sure. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2142> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char
Trent Mick added the comment: Attached is a patch against the Python 2.6 svn trunk for this. -- versions: +Python 2.3, Python 2.4, Python 2.6 Added file: http://bugs.python.org/file9460/python_difflib_unified_diff.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2142> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2142] naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char
New submission from Trent Mick:
When comparing content with difflib, if the resulting diff covers the
last line of one or both of the inputs that that line doesn't end with
an end-of-line character(s), then the generated diff lines don't include
an EOL. Fair enough.
Naive (and I suspect typical) usage of difflib.unified_diff(...) is:
diff = ''.join(difflib.unified_diff(...))
This results in an *incorrect* unified diff for the conditions described
above.
>>> from difflib import *
>>> gen = unified_diff("one\ntwo\nthree".splitlines(1),
..."one\ntwo\ntrois".splitlines(1))
>>> print ''.join(gen)
---
+++
@@ -1,3 +1,3 @@
one
two
-three+trois
The proper behaviour would be:
>>> gen = unified_diff("one\ntwo\nthree".splitlines(1),
..."one\ntwo\ntrois".splitlines(1))
>>> print ''.join(gen)
---
+++
@@ -1,3 +1,3 @@
one
two
-three
\ No newline at end of file
+trois
\ No newline at end of file
I *believe* that "\ No newline at end of file" are the appropriate
markers -- that tools like "patch" will know how to use. At least this
is what "svn diff" generates.
I'll try to whip up a patch.
Do others concur that this should be fixed?
--
components: Library (Lib)
messages: 62543
nosy: trentm
severity: normal
status: open
title: naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs
with inputs that don't end with end-of-line char
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2142>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
