[issue46700] wrong nomenclature (options vs. arguments) in argparse
mirabilos added the comment:
Hm, the change helps indeed. I did this in my code:
p = argparse.ArgumentParser(description='…', add_help=False)
g = p.add_argument_group('Options')
g.add_argument('-h', action='help', help='show this help message and exit')
g.add_argument(………
g = p.add_argument_group('Arguments')
g.add_argument('file', ………
args = p.parse_args()
Maybe adjust the documentation to match? As it stands,
https://docs.python.org/3/library/argparse.html is somewhat helpful, but
https://docs.python.org/3/howto/argparse.html is totally confusing.
--
___
Python tracker
<https://bugs.python.org/issue46700>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46701] cannot use typographical quotation marks in bug description
New submission from mirabilos : When trying to use typographical quotation marks (U+201C, U+201D) in the Comment field trying to submit a bug here, I get a red-background error message saying: Error: 'utf8' codec can't decode bytes in position 198-199: invalid continuation byte -- messages: 412953 nosy: mirabilos priority: normal severity: normal status: open title: cannot use typographical quotation marks in bug description ___ Python tracker <https://bugs.python.org/issue46701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46700] wrong nomenclature (options vs. arguments) in argparse
New submission from mirabilos :
The argparse documentation and tutorial as well as its default option groups
speak of "positional arguments" and "optional arguments". These are not used
correctly, though.
Elements of the argument vector (past item #0) are distinguished as options and
(positional) arguments.
Options are either flags (ls "-l", cmd "/c") or GNU long options ("--help").
They are usually optional ("[-h]") but may be mandatory (such as -o/-i/-p for
cpio(1)). They may have option arguments (cpio(1) "-H format").
Arguments (also called positional arguments) may be mandatory ("file") or
optional ("[file]"). They are also called operands (mostly in POSIX, not very
common).
The argparse documentation confused the hell out of me at first because I only
saw argument documentation and could not find option documentation…
--
components: Library (Lib)
messages: 412952
nosy: mirabilos
priority: normal
severity: normal
status: open
title: wrong nomenclature (options vs. arguments) in argparse
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue46700>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46695] _io_TextIOWrapper_reconfigure_impl errors out too early
New submission from mirabilos :
The following is not possible:
with open('/tmp/x.ssv', 'r', newline='\n') as f:
f.readline()
# imagine a library call boundary here
if hasattr(f, 'reconfigure'):
f.reconfigure(newline='\n')
The .reconfigure() call would not do anything, but it errors out nevertheless,
simply because it is called (from reading the
_io_TextIOWrapper_reconfigure_impl code in Modules/_io/textio.c).
Unfortunately, I *have* to call this in my library because I have to rely on
“newline='\n'” behaviour (the hasattr avoids erroring out on binary streams),
and the normal behaviour of erroring out if it’s too late to change is also
good for me.
But the behaviour of erroring out if called at all when anything has already
been read is a problem. This can easily be solved without breaking backwards
compatibility, as the operation is a nop.
To clarify: I wish for…
with open('/tmp/x.ssv', 'r', newline='\n') as f:
f.readline()
# imagine a library call boundary here
if hasattr(f, 'reconfigure'):
f.reconfigure(newline='\n')
… to work, but for…
with open('/tmp/x.ssv', 'r') as f:
f.readline()
# imagine a library call boundary here
if hasattr(f, 'reconfigure'):
f.reconfigure(newline='\n')
… (line 1 is the only changed one) to continue to error out.
--
components: IO
messages: 412935
nosy: mirabilos
priority: normal
severity: normal
status: open
title: _io_TextIOWrapper_reconfigure_impl errors out too early
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue46695>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23332] datetime.isoformat() - explicitly mark UTC string as such
mirabilos added the comment: Hm, RFCs are just RFCs and not standards, they can recommend whatever they want, and they can (and do) contradict each other. I’ve seen things (mostly related to eMail and PIM synchronisation) that require ‘Z’ for UTC proper. Additionally, +00:00 can be UTC, but it can also be British Winter Time, or DST of UTC-1. ‘Z’ is clear. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23332] datetime.isoformat() - explicitly mark UTC string as such
mirabilos added the comment: There’s another minor bug here: UTC should append “Z”, not “+00:00”, which other timezones at that offset can do. Agreed about no timezone being “floating” time in many instances, e.g. the iCalendar format uses that. -- nosy: +mirabilos ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22187] commands.mkarg() buggy in East Asian locales
mirabilos added the comment: Just for the record, please do not assume all shells behave like GNU bash. -- nosy: +mirabilos ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22187 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
mirabilos added the comment: Andreas Schwab dixit: Finn Thain fth...@telegraphics.com.au writes: Sorry, what? You seek to veto an upstream Python bug fix because it will lead to correct binaries that a certain emulator can't handle? That Yes, because of the value ARAnyM has for Linux/m68k development and especially testing – for example, considering that there are no porterboxen, we can, currently, just tell people needing one to install a VM themselves, and even provide images from which to start. Furthermore, Andreas' bug fix was to be merged for python 3.5. Debian is not obliged to use that version with that patch up until Aranym gets Debian is consistent across architectures. (Well, mostly.) This patch changes a known-good but less optimal behaviour (using the old dtoa routines) by behaviour that matches the other architectures even better but only iff the FPU (FPU emulation) supports changing precision. Which it didn’t last time I looked. fixed. Aranym *is* fixed. What *precise* version of ARAnyM is the first to have been released with a fix for this issue? I never got any response to my message to upstream in which I asked for a release: pine.bsm.4.64l.1403211905340.7...@herc.mirbsd.org (No response *at all*, mind you. Not even an ACK or “no”.) Once we do have a fixed version, we can communicate that around. (Note that “have” includes having e.g. backports to stable and several old *buntu versions at least.) bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
mirabilos added the comment: Stefan Krah dixit: If the asm instructions silently fail, I'd say add a test to ./configure that detects the broken versions of the emulator in question. No, the problem is at runtime: Debian is a binary distro, and thus, packages can get built and/or used on either ARAnyM, Amiga, Atari, Macintosh, and in theory VME machines, and maybe Q40/Q60, and maybe UAE (Amiga emulator). bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
mirabilos added the comment: Andreas Schwab dixit: The fixed version is here: git://git.code.sf.net/p/aranym/code That’s a source repository. I was asking for released tarballs that have been packaged. But clearly I have been outvoted by the m68k porters. So please feel free to go ahead and break Debian/m68k on released ARAnyM. I retract my veto. bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
mirabilos added the comment: Veto on m68k-float-prec.patch for Linux/m68k for now. Reasoning is same as in #18062 (thanks skrah for linking it): Enabling this *will* break Python on Linux/m68k on the most widespread emulator in all released versions of that emulator (ARAnyM) because the emulator does not handle reducing precision correctly. The same applies to all other m68k OSes running in ARAnyM (FreeMiNT comes to mind, I believe it could run Python). I think this could be applied when a released version of ARAnyM that works correctly even with this patch is in, say, Debian oldstable and RHEL, or something like that. The problem here is that this *will* create a run-time issue. (I had prepared a similar patch, but decided to fix the old dtoa code instead due to the emulator issue.) -- nosy: +mirabilos ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
mirabilos added the comment: Andreas Schwab dixit: Andreas Schwab added the comment: Enabling this *will* break Python on Linux/m68k ??? It will not of course, it will *fix* it. You have no idea what you are talking about. No: it will break Debian/m68k which heavily uses Python, because: - on real metal m68k, the asm function will be tested and work, so it will be used, including the new dtoa code - the binaries with that will be uploaded to the archive - now, on emulated m68k (ARAnyM), those binaries will use the new dtoa code instrad of the old one, but the asm instructions to change FPU precision will SILENTLY FAIL, which will lead to incorrect results bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20904] HAVE_PY_SET_53BIT_PRECISION for m68k
mirabilos added the comment: Andreas Schwab dixit: There is no excuse for using a broken emulator. Sure, if nobody releases a fixed version… and even then, there’s got to be a grace period. I say that if you break ARAnyM you kill off Debian/m68k on ARAnyM (and I’ll have to shut down my buildd, too). http://bugs.python.org/issue20904 bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20904 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18062] m68k FPU precision issue
mirabilos added the comment: Mark Dickinson dixit: If there are tests failing with the 'legacy' mode, that may just indicate buggy tests that haven't been properly marked as depending on the short float repr. (E.g., by decorating with I think that’s what we’re seeing here. Python 3.3.1 (default, May 10 2013, 02:52:57) [GCC 4.6.3] on linux Type help, copyright, credits or license for more information. import sys sys.float_repr_style 'legacy' Andreas Schwab dixit: What is the exact sequence of fpu insns? That’s all gcc-generated code and a system header… In main (after commenting out the second getcw and printf): jsr runtests #APP | 34 x.c 1 fmove.l %fpcr, %d2 | 0 2 #NO_APP move.l %d2,-4(%fp) move.l #128,-8(%fp) #APP | 40 x.c 1 fmove.l -8(%fp), %fpcr | 0 2 #NO_APP jsr runtests And the subroutine: runtests: link.w %fp,#-24 move.l %d3,-(%sp) move.l %d2,-(%sp) move.l #1072693247,-8(%fp) move.l #-1,-4(%fp) move.l -8(%fp),%d0 move.l -4(%fp),%d1 fmovecr #0x32,%fp0 move.l %d1,-(%sp) move.l %d0,-(%sp) fmove.d (%sp)+,%fp1 fdiv.x %fp1,%fp0 fmove.d %fp0,-(%sp) move.l (%sp)+,%d0 move.l (%sp)+,%d1 move.l %d0,-16(%fp) move.l %d1,-12(%fp) move.l -16(%fp),%d2 move.l -12(%fp),%d3 move.l -16(%fp),%a0 move.l -12(%fp),%a1 move.l #1072693248,%d0 clr.l %d1 move.l %a1,-(%sp) move.l %a0,-(%sp) fmove.d (%sp)+,%fp0 move.l %d1,-(%sp) move.l %d0,-(%sp) fmove.d (%sp)+,%fp1 fcmp.x %fp1,%fp0 fjne .L2 move.l #.LC0,%d0 jra .L3 .L2: move.l #.LC1,%d0 .L3: move.l #.LC2,%d1 move.l %d3,-(%sp) move.l %d2,-(%sp) move.l %d0,-(%sp) move.l %d1,-(%sp) jsr printf lea (16,%sp),%sp move.l #1128383353,-8(%fp) move.l #937459712,-4(%fp) move.l #1074266106,-16(%fp) move.l #-1043161657,-12(%fp) move.l -8(%fp),%a0 move.l -4(%fp),%a1 move.l -16(%fp),%d0 move.l -12(%fp),%d1 move.l %a1,-(%sp) move.l %a0,-(%sp) fmove.d (%sp)+,%fp0 move.l %d1,-(%sp) move.l %d0,-(%sp) fmove.d (%sp)+,%fp1 fadd.x %fp1,%fp0 fmove.d %fp0,-(%sp) move.l (%sp)+,%d0 move.l (%sp)+,%d1 move.l %d0,-24(%fp) move.l %d1,-20(%fp) move.l -24(%fp),%a0 move.l -20(%fp),%a1 move.l -24(%fp),%d0 move.l -20(%fp),%d1 move.l %d1,-(%sp) move.l %d0,-(%sp) fmove.d (%sp)+,%fp0 fcmp.d #0x4341c37937e08002,%fp0 fjne .L4 move.l #.LC0,%d0 jra .L5 .L4: move.l #.LC1,%d0 .L5: move.l #.LC3,%d1 move.l %a1,-(%sp) move.l %a0,-(%sp) move.l %d0,-(%sp) move.l %d1,-(%sp) jsr printf lea (16,%sp),%sp move.l -32(%fp),%d2 move.l -28(%fp),%d3 unlk %fp rts bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18062] m68k FPU precision issue
mirabilos added the comment: Laurent Vivier dixit: BTW, the result on a real CPU (68040) is : 68881 even ;-) test#1 fail: 1.0E+00 test#2 fail: 1.00040E+16 changing FPU control word from to 0080 = 0080 test#1 good: 1.00022E+00 test#2 good: 1.00020E+16 Thanks, that’s what I was guessing. I get similar results on i386. Now as additional data point, UAE/WinUAE/etc. would be interesting. Even so, I’d be very reluctant to add this code to Python to make it change the FPU mode, because Python is heavily used in Debian, and getting varying results between emulation and bare metal is something we’d like to not have… bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18061] m68k Python 3.3 test results
mirabilos added the comment: Serhiy Storchaka dixit: Do you run tests as root? Yes. Well, this is issue17746. OK, I’ll re-run the tests as regular user (need to create one… ☺) and with all those fixes applied, then we’ll have a look again. (This will take a while.) Thanks, //mirabilos -- Natureshadow Oh, ich hab mim Bauch Mittelklick gemacht, als ich nach dem Kaffee gegriffen habe… mirabilos Cool, ich hab ne neue eMail-Signatur Natureshadow Sag doch sowas nich, wenn ich den Kaffee in der Hand habe! Gib mir nen Lappen! Schnell! Das kommt aber nicht mit in die Signatur! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18062] m68k FPU precision issue
mirabilos added the comment: Laurent Vivier dixit: For the etc ;-) , in Qemu, I have: Hm, I thought qemu did not emulate an MMU? bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18062] m68k FPU precision issue
mirabilos added the comment: Eero Tamminen dixit: Now as additional data point, UAE/WinUAE/etc. would be interesting. I built the test with fpu_control.h header from eglibc, using Sparemint GCC 2.9.5 (with 2010 binutils) and MiNTlib. When it's Nice ;) I.e. it seems that WinUAE FPU emulation is also lacking FPUCW change handling (for precision). (Hatari's WinUAE CPU core code was synched with upstream last year.) OK, thanks. I’d just say let’s say changing FPU precision is not part of the target we support. (Funnily enough, ColdFire according to the ’net has (unchangeable) 64-bit precision… maybe let’s just say precision on m68k in general is not defined.) bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18061] m68k Python 3.3 test results
New submission from mirabilos:
Hi!
As a followup to http://bugs.python.org/issue17237 I took the tree of Python
3.3.1 I had compiled already, with the patch that was eventually committed for
issue17237, and ran the testsuite. Since I used configure flags to get it
compiled quickly, it probably lacks functionality that’s normally there, so
some tests got omitted.
The result of normally running the testsuite is attached as file; I can re-run
any test verbosely, just ask ;-)
I can immediately say something to some failures:
① On m68k, the 68881 FPU, similar to the i8087 FPU, internally operates on
80-bit precision, which means that the “old” dtoa code is used. Contrarily to
i8087, we do not want to disable that mode because that is not fully supported
in some environments; especially, at least the most wide-spread emulator had
bugs wrt. that. (Do note that, when you disable 80-bit precision on i8087, you
get double-rounding as the only the mantisse, not the exponent, is bit-reduced,
anyway. So I believe that you should not restrict the i8087 to 64-bit precision
either.)
That’s responsible for test_optparse, test_difflib, maybe test_cmath,
definitely test_format, test_types, test_math… ouch, quite some.
It would be interesting to see what happens when you take a normal i386 (not
amd64 or x32) Linux host and compile py3k with SSE disabled (to force it to use
the normal i80387 FPU), and disable HAVE_GCC_ASM_FOR_X87 so that
X87_DOUBLE_ROUNDING is defined, because that’s what we have on m68k, and see
whether the failure mode is the same. If so, you can then probably relatively
easily fix those.
root@ara3:~/P-without-block # fgrep X87 pyconfig.h
/* #undef HAVE_GCC_ASM_FOR_X87 */
#define X87_DOUBLE_ROUNDING 1
② This one is pretty severe: AssertionError: 42 != 44 : wrong size for class
'BaseException': got 42, expected 44
On m68k, “natural” alignment is *not* used: instead of aligning 4-byte
quantities on 4-byte boundaries, for almost all types, only a minimum alignment
of 2 bytes is used; this also has effect on struct padding, array padding, and
things like that.
As shown in
https://mail.gnome.org/archives/commits-list/2012-February/msg02332.html fixing
this is a “simple” matter of making these invalid assumptions explicit. To that
effect, take Include/pyerrors.h and change
#define PyException_HEAD PyObject_HEAD PyObject *dict;\
PyObject *args; PyObject *traceback;\
PyObject *context; PyObject *cause;\
char suppress_context;
to
#define PyException_HEAD PyObject_HEAD PyObject *dict;\
PyObject *args; PyObject *traceback;\
PyObject *context; PyObject *cause;\
char suppress_context; char padding1[3];
i.e. add the padding that’s implicit on “natural alignment” platforms (a
padding1[1] is implicit on m68k). Do *not* use -malign-int because that changes
the ABI, and you probably won’t be able to make libc or syscalls any more…
However, this brings us to a problem with that solution (which I’d still prefer
over everything else) in Debian (hence, putting doko on Cc), which I’ll
demonstrate on the shortest struct I could find in that file, but applies to
e.g. PyImportErrorObject too:
typedef struct {
PyException_HEAD
PyObject *code;
} PySystemExitObject;
The “code” member of this struct is aligned with only *one* byte of padding,
instead of three. This means that, when we apply this bugfix, that the
published ABI changes: currently, sizeof(PySystemExitObject) is (8
(PyObject_HEAD) + 4 (dict) + 4 (args) + 4 (traceback) + 4 (context) + 4 (cause)
+ 1 (suppress_context) + 1 padding + 4 (code)) = 34; after the fact, it will be
36, and the offsetof(code) will have changed.
I’ll leave the understanding of these implications, and how they can best be
handled in the distribution, to doko, because he’s probably the man who
understands it best. I guess we need versioned dependencies or ABI virtual
dependencies, since python3.3 is already uploaded, but some packages have
already been built against it (probably not too difficult to identify them).
Or we can only get this fixed in python3.4 – no idea when that will land in
Debian, or whether it’ll become the default python3 provider shortly.
③ As for any other failures, I don’t directly have an idea, but I guess we can
work on them. I’d somewhat prefer to do that *after* the FPU precision-related
bugs have been fixed, though, as it’ll reduce the noise, and possibly
followup-errors. (Maybe I should even, for running the tests, fix the alignment
issue locally in the tree.)
--
components: Interpreter Core
files: results.txt
messages: 189997
nosy: doko, mirabilos, pitrou, skrah
priority: normal
severity: normal
status: open
title: m68k Python 3.3 test results
versions: Python 3.3
Added file: http://bugs.python.org/file30371/results.txt
[issue18062] m68k FPU precision issue
New submission from mirabilos: Hi, splitting off issue18061 by request of pitrou: FPU precision issue: MC68881 FPU, similar to Intel 80387, uses 80-bit precision internally. We do not want to change it to 64-bit because it’s not supported in all environments. Can probably be reproduced on i386 (with disabled SSE); fixing this in general would allow keeping the FPUCW on i387 unchanged too. See issue18061 for details. -- components: Interpreter Core messages: 18 nosy: mirabilos priority: normal severity: normal status: open title: m68k FPU precision issue versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18063] m68k struct alignment issue vs. PyException_HEAD
New submission from mirabilos: Hi, splitting off issue18061 by request of pitrou: struct alignment issue: PyException_HEAD misses explicit alignment instruction; uses invalid (non-portable) alignment assumptions. ABI change on m68k. See issue18061 for details. -- components: Interpreter Core messages: 19 nosy: mirabilos priority: normal severity: normal status: open title: m68k struct alignment issue vs. PyException_HEAD versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18061] m68k Python 3.3 test results
mirabilos added the comment: OK sure; I put the two I identified already into issue18062 and issue18063; we can then retry here after those get fixed (I’ll just resend results from a patched tree then). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18063] m68k struct alignment issue vs. PyException_HEAD
mirabilos added the comment: Yes, that's in test_sys. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18063] m68k struct alignment issue vs. PyException_HEAD
mirabilos added the comment: struct.calcsize(PPnP5Pb) 37 struct.calcsize(PPnP5Pi) 40 struct.calcsize(PPnP5Pb0P) 38 struct.calcsize(PPnP5Pi0P) 40 I already offered to re-run tests in verbose mode “on request” if needed, but the results.txt I attached to issue18061 contains them for test_sys (it apparently got re-run verbosely automatically). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18062] m68k FPU precision issue
mirabilos added the comment: We do not want to change it to 64-bit because it’s not supported in all environments. Does this also apply to changing the precision temporarily? Yes, that’s precisely what’s not working on the most widespread emulator, at the very least. (I have working code for that, in three(!) variants, but it just ignores those requests to change precision.) I think FPU is the one thing current m68k emulators do the worst… the responses I got from the mailing list back then said so, anyway. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18063] m68k struct alignment issue vs. PyException_HEAD
mirabilos added the comment: Sure (attached). -- Added file: http://bugs.python.org/file30374/after-patch-1.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18063] m68k struct alignment issue vs. PyException_HEAD
mirabilos added the comment: Include/unicodeobject.h has the same problem; its “state” member currently allocates 8 bit, which is only padded up to 16 bit. asciifields = nnbP makes that work too; result attached as after-patch-2.txt Will just changing the testsuite to match reality be enough, or are there any other internal assumptions about this type of thing, like we had with issue17237 earlier? Thanks for your quick responses! -- Added file: http://bugs.python.org/file30375/after-patch-2.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18063] m68k struct alignment issue vs. PyException_HEAD
mirabilos added the comment: Okay, then I’ll ignore those for now. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18061] m68k Python 3.3 test results
mirabilos added the comment: Serhiy Storchaka dixit: About test_shutil failure. What filesystem are used? /dev/root on / type ext3 (rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,nodelalloc,data=ordered) Do you run tests as root? Yes. Is m68k big-endian? Yes: ILP32 big-endian, 2-byte aligned. bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18061 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18062] m68k FPU precision issue
mirabilos added the comment:
mirabilos dixit:
mirabilos added the comment:
Yes, that’s precisely what’s not working on the most widespread
emulator, at the very least. (I have working code for that, in
three(!) variants, but it just ignores those requests to change
precision.)
Here’s the Python testcase made into a standalone test:
-BEGIN cutting here may damage your screen surface-
#include stdio.h
#include stdlib.h
#include math.h
#ifndef __MirBSD__
#include fpu_control.h
#endif
void runtests(void);
void
runtests(void)
{
volatile double x, y, z;
/* 1./(1-2**-53) - 1+2**-52 (correct), 1.0 (double rounding) */
x = 0.99989; /* 1-2**-53 */
y = 1./x;
printf(test#1 %s: %.17E\n, (y == 1.) ? fail : good, y);
/* 1e16+2.9 - 1e16+2. (correct), 1e16+4. (double rounding) */
x = 1e16;
y = 2.9;
z = x + y;
printf(test#2 %s: %.17E\n, z == 1e16+4. ? fail : good, z);
}
int
main(void) {
#ifdef _FPU_SETCW
fpu_control_t cwold, cwnew, cwgot;
#endif
runtests();
#if (defined(__i386__) || defined(__m68k__)) defined(_FPU_SETCW)
_FPU_GETCW(cwold);
#ifdef __i386__
cwnew = 0x127f;
#else
cwnew = _FPU_RC_NEAREST | _FPU_DOUBLE;
#endif
_FPU_SETCW(cwnew);
_FPU_GETCW(cwgot);
printf(changing FPU control word from %08X to %08X = %08X\n,
cwold, cwnew, cwgot);
runtests();
#endif
return (0);
}
-END cutting here may damage your screen surface-
Here’s the result of running it on the latest ARAnyM, which
did get MPFR-based FPU emulation bugfixes, but apparently
still ignores any FPUCW changes (or, at least the ones relating
to precision):
root@ara3:~ # ./a.out
test#1 fail: 1.0E+00
test#2 fail: 1.00040E+16
changing FPU control word from to 0080 = 0080
test#1 fail: 1.0E+00
test#2 fail: 1.00040E+16
bye,
//mirabilos
--
Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL.
-- Henry Nelson, March 1999
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18062
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18062] m68k FPU precision issue
mirabilos added the comment: Stefan Krah dixit: fixing this in general would allow keeping the FPUCW on i387 unchanged too. Actually dtoa.c (which is used on i387) explicitly requires to change the control word. Right. By fixing the “older” code, i386 is not required to change the FPUCW any more and can use it too. The problem with changing the FPUCW on i387 is that it changes from 64/15 bit mantissa/exponent to 53/15 bit which is still not the 53/11 bit of IEEE double, so you *still* get double- rounding issues (with denormal numbers only, I guess) because the internal precision is still higher. And on m68k we simply cannot afford to change the FPUCW because that will cause runtime failures on some implementations. Looking at the test results, it seems to me that a couple of tests could be skipped if PY_NO_SHORT_FLOAT_REPR is defined, i.e.the failures are fully expected. Ah okay. Not sure about the lgamma etc. failures though, perhaps that's an emulator bug. If I can get self-contained test cases (preferably in C because that makes it easier for others to test), I can ask people who run real bare-metal Atari or Amiga to test them. Or you can ask on debian-...@lists.debian.org for testers. I guess a python2.6 runnable testcase would be okay, even for those running an a bit older “base system”. (I admit mine is not really up to date either, just the build chroots, because of the post-release unfreeze upload peak and related transitions.) bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18062 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Right, keeping it simple helps in preventing accidents, and the code block looks full of magic enough as-is. Maybe add a comment block that says: /* * m68k is a bit different from most architectures in that objects * do not use natural alignment - for example, int and long are * only aligned at 2-byte boundaries. Tests have shown that skipping * the optimised version will even speed up m68k, so we #ifdef * for the odd duck out here. */ Then we have an in-situ documentation point for why that ifdef is there and why m68k is “the odd duck” and this whitelist method is used. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Thanks Antoine! Now, for “finishing up” this… to follow up on Stefan’s comment… is there any way I can run the testsuite from an installed Python (from the Debian packages)? (I build the packages with disabled testsuite, to get the rest of the system running again, since python3.3 was recently made required and we had never built it before.) Otherwise I guess I could run “make test” on one of the earlier trees I used for the timing… but that machine is currently building six Linux kernel flavours from the src:linux package and thus will not be available for the next one and a half week or so… -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Antoine Pitrou dixit: python -m test (with any options you might like), but we don't No, I tried that (as it was the only thing I could find on the ’net as well) on an i386 system and only get: tglase@tglase:~ $ python2.7 -m test /usr/bin/python2.7: No module named test.__main__; 'test' is a package and cannot be directly executed 1|tglase@tglase:~ $ python3.2 -m test /usr/bin/python3.2: No module named test.__main__; 'test' is a package and cannot be directly executed Same when adding ‘-h’. bye, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Antoine Pitrou dixit: (note, on 2.7, it's python -m test.regrtest) That indeed does things. So I had mistaken them for the same problem. Ah, that's because the system Python install doesn't include the test suite. Perhaps you have to install an additional package, python-dev perhaps? tglase@tglase:~ $ l /usr/lib/python2.7/test/ __init__.py pystone.py* regrtest.py* test_support.py __init__.pyc pystone.pyc regrtest.pyc test_support.pyc tglase@tglase:~ $ l /usr/lib/python3.2/test/ __init__.py __pycache__/ pystone.py* regrtest.py* support.py Maybe it’s just not packaged… these are all I can find, and installing python3.2-dev doesn’t fix it. Oh well, then it’ll just have to wait. Do you have a preferred place where I can submit the test results, as it’s getting very off-topic here? bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Hi again, sorry for being a bit late in following up to this. Here are the results for the two runs you requested; these were done on the same machine, intermixed (the first one cache-clean, the second and third run subsequently (so that the third run is cache-filled)). I used static builds. For the “without assert”, I get approximately 570 usec per loop consistently: (590,580), (570,570), (560,580), (570,560) Interestingly enough, there seems to be no preference either way (ASCII or UTF-8). For the “without the whole if‥endif block”, I get mixed results: (650,540), (690,530), (520,530), (650,540) Interesting here is that the third run of them both has a lower ASCII than UTF-8 time, the others don’t – but the UTF-8 run is the second in a row, so cache might be of an issue. Repeating the runs, I get (560,590), (540,530) for the second case, and (760,570), (590,660) for the first case breaking its “consistently 570 usec” streak. Error of measurement may be large, thus. Which supports your suspicion that the optimised case may not be needed at all. Matthias asked me to provide links how to set up an Atari VM with Debian unstable and a clean/minimal unstable chroot, since there’s much use of Ubuntu here who ship ARAnyM (I even filed a Sync Request so that the latest release got a fixed version ☺). https://wiki.debian.org/Aranym/Quick#download has got pointers for the first part (setting up an ARAnyM VM), and https://wiki.debian.org/M68k/Installing contains the whole documentation (we cannot currently use d-i but people are working on it). http://people.debian.org/~tg/f/20121227/m68k-buildd.tgz is the output of “debootstrap --variant=buildd” and as such should be usable in either cowbuilder or sbuild. Considering that we *only* have unstable available, you may want to be careful when upgrading ;) but an apt-get update should work out of the box (takes a few minutes). The VMs have 768+14 MiB RAM each in the sample configuration (maxed out), which makes them use a bit less than 1 GiB on the host side. A 3 GHz host CPU is of benefit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Antoine: precisely. Serhiy: sure. The times are now in msec per loop. I did three subsequent runs, so the second and third tuple are cache-warm. Without assert: (89,88), (87,87), (89,86) Without block : (79,78), (78,78), (79,78) And in a second run: Without assert: (87,88), (87,88), (92,87) Without block : (111,91), (78,85), (79,79) This means that, again, removing the “optimised” code speeds up operations (on this particular slow architecture. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: file30203/ascii_decode_nonaligned.patch is potentially a nop (the struct being a multiple of, in the m68k case 4, bytes is not an indicator of whether to skip it). I think we can be bold and put #if !defined(__m68k__) and #endif around the entire block and, should there ever be another architecture with similar issues, whitelist them there. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Currently 22; it will increase to 24 if a few more bits are added. That’s why I said it’s “fragile” magic. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment:
I’m currently thinking this patch.
(Will need another day or so for compiles to finish, though.)
--
Added file: http://bugs.python.org/file30210/python3.3_3.3.1-1+m68k.1.debdiff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17237
___diff -u python3.3-3.3.1/debian/changelog python3.3-3.3.1/debian/changelog
--- python3.3-3.3.1/debian/changelog
+++ python3.3-3.3.1/debian/changelog
@@ -1,3 +1,9 @@
+python3.3 (3.3.1-1+m68k.1) unreleased; urgency=low
+
+ * Employ m68k build fix (see issue17237)
+
+ -- Thorsten Glaser t...@mirbsd.de Fri, 10 May 2013 23:39:11 +0200
+
python3.3 (3.3.1-1) unstable; urgency=low
* Python 3.3.1 release.
diff -u python3.3-3.3.1/debian/patches/series.in
python3.3-3.3.1/debian/patches/series.in
--- python3.3-3.3.1/debian/patches/series.in
+++ python3.3-3.3.1/debian/patches/series.in
@@ -55,0 +56 @@
+m68k-buildfix.diff
only in patch2:
unchanged:
--- python3.3-3.3.1.orig/debian/patches/m68k-buildfix.diff
+++ python3.3-3.3.1/debian/patches/m68k-buildfix.diff
@@ -0,0 +1,18 @@
+--- a/Objects/unicodeobject.c
b/Objects/unicodeobject.c
+@@ -4661,6 +4661,7 @@ ascii_decode(const char *start, const ch
+ const char *p = start;
+ const char *aligned_end = (const char *) _Py_ALIGN_DOWN(end, SIZEOF_LONG);
+
++#if !defined(__m68k__)
+ #if SIZEOF_LONG = SIZEOF_VOID_P
+ assert(_Py_IS_ALIGNED(dest, SIZEOF_LONG));
+ if (_Py_IS_ALIGNED(p, SIZEOF_LONG)) {
+@@ -4686,6 +4687,7 @@ ascii_decode(const char *start, const ch
+ return p - start;
+ }
+ #endif
++#endif
+ while (p end) {
+ /* Fast path, see in STRINGLIB(utf8_decode) in stringlib/codecs.h
+for an explanation. */
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: + dest is always aligned on common platforms + (if sizeof(PyASCIIObject) is divisible by SIZEOF_LONG). Actually, that’s the part that is not true. On m68k, and perfectly permitted by the C standard, even a 24-byte object has only a guaranteed alignment of 2 bytes (or one, if it’s a char array) in the normal case (contains integers and pointers, nothing special). We patched out this bogus assumption from things like glib already ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment:
Serhiy Storchaka dixit:
mirabilos, if you are motivated enough, do the following. Compile two
Python executables - one with deleted assert, and second with deleted
a block between #if SIZEOF_LONG = SIZEOF_VOID_P and #endif. Run
following microbenchmarks for both executables:
./python -m timeit -s x=b'A'*1 x.decode('ascii')
./python -m timeit -s x=b'A'*1 x.decode('utf-8')
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17237
___
Thanks, will actually do that, just not before the weekend,
dayjob’s keeping me busy, and I need to be careful to not
burn out myself in the evening too.
Which tree should I build? A release (if so, which)? Or
some CVS branch?
Do note we clock at roughly 1000 pystones for the fastest
machines… yes 1000 not 1.
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17237
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: Serhiy Storchaka dixit: Which tree should I build? A release (if so, which)? Or some CVS branch? It doesn't matter. Erm, still, which one do I build? Not 3.2 because it obviously works, at least as packaged in Debian. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: @skrah: “I don't think we should support this platform officially.” Please don’t break what works. We have almost complete (about three quarters of roughly 10'000 source packages) Debian unstable working on m68k, with several versions of Python in use. Thanks! @pitrou: “x86 can align on a byte boundary and doesn't trigger the assert.” That’s because most compilers on i386 do “natural alignment” – in fact, most compilers on most platforms do. “natural alignment” means 4-byte quantities get aligned on 4-byte boundaries, 8-byte quantities on 8-byte boundaries, etc. On m68k, the lowest alignment for almost all larger-than-a-byte data types is 2 byte, even though that one is strict. This means that, for example, an int is often only 2-byte aligned. @alanh: “GCC has the -malign-int but mentions this isn't in best interest of m68k ABI compatibility if it's used.” Indeed, because that would break the C and kernel/syscall ABI. @all: what _precisely_ is the assertion needed to check for? @pitrou: “since it is there to warn about misalignment on platforms which *are* alignment-sensitive” Well, m68k is. Just the numbers differ. (It also has int, long and pointer at 32 bit.) We had a similar issue in the Linux kernel, where it used the lower two bits of an address for flags (urgh…) which could only be solved by using GCC’s __attribute__((__aligned__(4))) on the quantities in question, but that may or may not be the required case here, which is why I’m asking. I can test any trees on my VMs, but that takes a day or two, of course, at 50-200 BogoMIPS. You can do that yourself by running a VM as well, the Debian Wiki has instructions, if anyone is interested. Otherwise, it’ll just get tested as soon as it hits Debian (unstable, usually we don’t build experimental packages except on explicit request by the packagers, due to lack of time / horsepower)… Thanks doko for linking this issue! -- nosy: +mirabilos ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17237] m68k aligns on 16bit boundaries.
mirabilos added the comment: @pitrou: As for performance, 2-byte and 4-byte are the same on m68k, given that they usually have RAM which doesn’t benefit from that kind of alignment, and systems that are structured accordingly. The “best” cpp define I don’t know, but my system defines __m68k__ and Alan would probably be able to say whether this is defined on ColdFire, too. @skrah: No, I specifically did not say that ☺ But it works pretty damn well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17237 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
