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 me
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
co
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 distingu
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')
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
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
mirabilos added the comment:
Just for the record, please do not assume all shells behave like GNU bash.
--
nosy: +mirabilos
___
Python tracker
<http://bugs.python.org/issue22
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
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
mirabilos added the comment:
Andreas Schwab dixit:
>Finn Thain 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 Lin
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
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 whic
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
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
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
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 t
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.000
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 se
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 c
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
>precisio
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-
mirabilos added the comment:
Okay, then I’ll ignore those for now. Thanks!
--
___
Python tracker
<http://bugs.python.org/issue18063>
___
___
Python-bugs-list m
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
mirabilos added the comment:
Sure (attached).
--
Added file: http://bugs.python.org/file30374/after-patch-1.txt
___
Python tracker
<http://bugs.python.org/issue18
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.
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 verbos
mirabilos added the comment:
Yes, that's in test_sys.
--
___
Python tracker
<http://bugs.python.org/issue18063>
___
___
Python-bugs-list mailing list
Unsubsc
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
<h
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
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
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
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
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/py
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
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" - f
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
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
<http://bugs.python.
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
<http://bugs.python.org/issue17
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
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
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
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,
//mirab
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". Ru
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__
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 u
45 matches
Mail list logo
