classification
Title: HAVE_PY_SET_53BIT_PRECISION for m68k
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, BreamoreBoy, benjamin.peterson, georg.brandl, larry, loewis, mark.dickinson, mirabilos, pitrou, python-dev, schwab, skrah, tim.peters
Priority: normal Keywords: patch

Created on 2014-03-13 07:54 by schwab, last changed 2014-04-17 16:43 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
m68k-float-prec.patch schwab, 2014-03-14 06:43 Patch to implement HAVE_PY_SET_53BIT_PRECISION for m68k review
Messages (68)
msg213359 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-13 07:54
m68k has the same problem as x86 with excess floating point precision.  The attached patch implements the necessary support for HAVE_PY_SET_53BIT_PRECISION.
msg213420 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-03-13 17:27
Technically I guess this counts as a new feature.  It would be painful to have to wait for 3.5, though.  I wonder whether we can sneak this in after 3.4 is released?

Is the __mc68000__ #define specific to gcc?
msg213426 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-13 17:58
I don't know of any other compiler on m68k.
msg213430 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2014-03-13 18:16
Mark Dickinson <report@bugs.python.org> wrote:
> I wonder whether we can sneak this in after 3.4 is released?

+1. m68k affects a relatively small group of people, and Andreas Schwab is
the gcc m68k port maintainer, so ...
msg213431 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-03-13 18:19
Does Python still officially support m68k?
msg213519 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-14 06:43
I have modified the patch to include a configure check to set HAVE_GCC_ASM_FOR_MC68881 and use that instead of __mc68000__.
msg213531 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-03-14 10:13
I don't think fixing bugs on a specific architecture counts as a new feature.

> Does Python still officially support m68k?

Certainly not. We haven't had any 68k buildbot in ages (not sure we ever had any, actually).

Andreas, have you signed a contributor's agreement? You can do it online at http://www.python.org/psf/contrib/contrib-form/
msg213540 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-03-14 12:54
I'm happy to accept the change for 3.4.1, but I'm not going to cherry-pick a fix for an unsupported platform after rc3.
msg214606 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-03-23 16:53
It strikes me as strange that we'd allow code churn for an unsupported platform, can someone explain the rationale behind this please.
msg214607 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-23 16:57
What do you mean with code churn?
msg214609 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-03-23 17:00
Code churn is defined as lines added, modified or deleted to a file from one version to another.
msg214611 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-23 17:03
That's a very broad definition, I didn't know that python is such a hostile environment.
msg214612 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2014-03-23 17:06
Ignore Mark Lawrence.
msg214613 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2014-03-23 17:10
@Mark, I don't understand why you ask this question after several positive responses of Python committers (Mark, Stefan, Larry).

@Andreas, as far as I recall, we have always welcomed patches for officially unsupported platforms, certainly as long as they only introduce special code for that platform, as is the case here.
msg214616 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-03-23 17:17
I love you as well Benjamin :)

To be serious I think we're talking at cross purposes.  I'm not against this patch.  Code churn often gets mentioned here as a reason for not doing what is proposed.  Changing code for an unsupported platform just struck me as odd.  So if somebody explains that we're doing it for the very good reasons x, y and z I'll be perfectly happy.
msg214617 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2014-03-23 17:25
So far there are only very few m68k patches.  Additionally, the patches are well researched and sometimes highlight ANSI C violations.

The submitters of the patches are highly competent and apparently take testing seriously.  I see no reason to reject the patches.
msg214618 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2014-03-23 17:26
With respect, Mark, I think you should leave these considerations to the committers.
msg214619 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-03-23 17:31
Great, you ask a simple, straight forward question and get told to go away.  I'll therefore leave everything to the committers, including the roughly 4500 open issues and the other 40 languishing.
msg214638 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-03-23 21:51
Since 3.4 and 3.5 are different code bases, I assume you'd be willing to check this in for both.  Assuming that's the case, please tick the 3.5 version too.
msg214641 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2014-03-23 22:10
Mark, I already gave a reason, which was apparently not good enough for you.  Nobody told you to go away from the tracker, but it's not constructive to ask for reasons why a particular patch is accepted or rejected, by the release manager no less, if you're not the original author.  (Except if you want to discuss policy, in which case the tracker is the wrong place to do it.)
msg214643 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-03-23 22:21
I've asked a simple question and I've *NOT* had an answer.  Antoine's response to Larry's question "Does Python still officially support m68k?" is certainly pertinent "Certainly not. We haven't had any 68k buildbot in ages (not sure we ever had any, actually)."  The more I see here, the more laughable I think the situation is.  Core devs have time to spend on an issue for an unsuppoorted platform, but don't have the time to support the 4500 issues that are presumably aimed at supported platforms.  What gives?
msg214644 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-03-23 22:24
> I've asked a simple question and I've *NOT* had an answer.

Can we move along, please?
msg214645 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2014-03-23 22:30
> Can we move along, please?

Indeed.  Further discussion, if felt to be really necessary, should take place on python-dev.
msg214646 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-03-23 22:38
BreamoreBoy: Support for this patch comes from several properties of the patch and the way it is stated that make it easy to like it. It is well-researched, well-presented, and clearly can't have negative impact on the systems that *are* supported. This is different from the other thousands of issues which are much more difficult to rule on.

There is, of course, the standing ruling from Guido that we shouldn't let new support for minority platforms in, and phase out any such existing support that is already in the code base. By that policy, Andreas would have to support his own fork of Python.
msg214665 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-03-24 02:07
Martin: I hadn't realized there was such a rule from Guido.  Can you cite where he said that?

Obviously I didn't mind accepting this patch, as it looks like it would have roughly zero maintenance cost for anyone who doesn't care about 68k.  But if Guido has said "we don't accept patches for unsupported platforms", I may have to reverse my decision.
msg214676 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-03-24 09:56
> I don't think fixing bugs on a specific architecture counts as a new feature.

It's not really a bugfix, though.  Python 3.4 *should* (I'm not in a position to check, but Andreas may be) be behaving as designed on m68k: the configure script will correctly determine that there's a potential issue with double rounding, and since it doesn't currently know of any way to control the FPU precision setting on m68k, it'll set the environment variables up so that the legacy floating-point repr code is used.  The built Python should function as normal, expect that sys.float_repr_style will be 'legacy' instead of 'short', and we won't get the (primarily cosmetic) benefits of the short float repr.

This patch then changes the part where Python doesn't know how to change the precision, allowing it to use David Gay's short float repr code instead of the legacy code.  So I see it as an enhancement rather than a bugfix.

And this would actually be a somewhat significant behaviour change: on m68k with Python 3.4.0, we'd see:

>>> 1.1
1.1000000000000001

and (if this patch went into the 3.4 branch), on Python 3.4.1 we'd see instead:

>>> 1.1
1.1

The behaviour of string formatting and the round function would also change in edge cases.

There's an argument that the number of users affected by this change is likely to be tiny, so changing this in 3.4.1 is unlikely to break people's code.  But the tininess of the userbase is equally the basis of an argument that the change isn't at all urgent, and those affected can wait for Python 3.5 or patch their copy of Python; I don't see a really good reason to break the policy about new features on bugfix branches for this particular issue.

Given all that, I don't think it would be appropriate to include the change in Python 3.4.1.  I'd personally like to see it go into Python 3.5, but that's dependent on the outcome of the "we don't accept patches for unsupported platforms" discussion (which is orthogonal to the 'is this an enhancement or a bugfix' discussion).
msg214677 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-24 10:28
It's not just cosmetic, it's breaking the testsuite back and forth.
msg214678 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-03-24 10:36
> It's not just cosmetic, it's breaking the testsuite back and forth.

Sure; those are really bugs in the tests, though: no test should be blindly assuming that the short float repr is in use.  It sounds as though we're missing some skip decorators.
msg214679 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-03-24 10:38
Though depending on what the test failures look like, some of them may be indications of issues elsewhere.

Is there already an issue open for the failing tests?
msg214680 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-24 10:48
I didn't bother since this one fixes it for me (and also other python modules).  IMHO it's the correct way to fix it, since no other architecture except these two will have the problem.  Since you say the non-short-float code is legacy this will make it also possible to drop it.

FWIW, I don't really care which version will carry the patch, since I can apply it locally anyway.  But I don't want to carry it indefinitely.
msg214681 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-03-24 10:52
> Since you say the non-short-float code is legacy this will make it also possible to drop it.

That's unfortunately not true (much as I'd like it to be).  Even with this patch, there may still be non-gcc / x86 combinations where we potentially need the fallback code.
msg214682 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-24 10:57
I guess they will get fixed over time, or declared unsupported. :-)
msg214683 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-03-24 11:15
> I guess they will get fixed over time, or declared unsupported. :-)

Yes, probably.  I'd fully support a move to get rid of that legacy code in Python 3.5.  That would definitely require a python-dev discussion, though (and possibly a PEP): up until now the policy has been that Python just works with whatever floating-point format the platform's C double provides, with no assumptions about IEEE 754, etc.

I think we've mostly fixed the issues on mainstream platforms (e.g., Sun and Intel compilers on x86).  Probably the most troublesome remaining case is ARM / OABI, where I think we still don't have code to deal with the mixed-endian (more strictly, little-endian swapped words) format for C doubles.  There are some online environments (Python via JavaScript, etc.) that also currently use the legacy code.
msg214718 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-03-24 20:17
It sounds like this definitely won't happen for 3.4.  And if Guido has indeed declared "no code for unsupported platforms", it won't happen for 3.5 either.
msg214719 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-24 20:36
That's what I call hostile.
msg214720 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2014-03-24 20:40
This is a short and straightforward patch that improves the Python experience for m86k users. I think it should be applied.
msg214722 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-03-24 20:49
I agree that it's a short and straightforward patch, and as stated I wouldn't mind accepting it.  However, I don't make a habit of going against Guido's rulings.
msg214723 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2014-03-24 20:50
Well, no one has produced a reference for this phantom announcement.
msg214724 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-03-24 20:52
That's why I haven't said firmly yes or no yet.  I expect to see Guido in just over two weeks, and if nothing turns up by then I'll ask him in person.  Is anybody here in a hurry?
msg214725 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2014-03-24 20:54
I don't want to scare away contributors.
msg214729 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2014-03-24 21:20
In the absence of Guido here, I'll channel him ;-)  "The problem" with oddball platforms has been that some require major changes in many parts of the interpreter, and then all the added cruft complicates life for every maintainer, while few people benefit and the oddball platform typically has only one maintainer who vanishes for long stretches.

Guido would not object to this small, simple, well-motivated and isolated patch.  At least he wouldn't object on the basis of "it's an unsupported platform".

I don't object either ;-)
msg214730 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-03-24 21:21
> That's why I haven't said firmly yes or no yet.  I expect to see Guido
> in just over two weeks, and if nothing turns up by then I'll ask him
> in person.

It's a minor patch for a niche platform. What exactly is the point of
asking Guido in person? At worse, shoot him an e-mail. I would expect
the answer to be "I don't care".
msg214734 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-03-24 21:32
It seems it wasn't actually a formal ruling (although I took it for that); see for yourself - or better, ask Guido what he thinks about this topic today:

https://mail.python.org/pipermail/python-3000/2007-August/009692.html
https://mail.python.org/pipermail/python-dev/2009-January/085064.html

There might be more postings on the topic which I can't find now.
msg214744 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-03-24 21:56
What triggered my interpretation might have been this conversation:

https://mail.python.org/pipermail/python-dev/2002-May/023998.html
https://mail.python.org/pipermail/python-dev/2002-May/024006.html
msg214748 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-24 22:18
We are actually talking about Linux here, I assume everyone knows what that is :-)

Also the patch is 2 files changed, 32+ (if you ignore the autoconf generated files), which is quite a bit smaller than the final version of the atheos patch (which is 19 files changed, 544+, 15-, also generated files ignored).
msg214755 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2014-03-24 23:05
Benjamin Peterson <report@bugs.python.org> wrote:
> I don't want to scare away contributors.

I think this is a very important point. Initially I was skeptical about m68k,
too (msg182388), but I've completely changed my opinion due to the nature
of the patches.

So far, the m68k issues were about C-standard compliance and timing assumptions
in tests.

This one is a small patch that won't affect anything else.

My experience with exotic Linux ports (Debian SPARC, etc.) is that the Python
test suite works rather well out of the box.  So I don't expect to have a flood
of posixmodule.c patches or similar (perhaps Andreas can confirm that).
msg214771 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2014-03-25 00:27
On Mon, Mar 24, 2014, at 14:56, Martin v. Löwis wrote:
> 
> Martin v. Löwis added the comment:
> 
> What triggered my interpretation might have been this conversation:
> 
> https://mail.python.org/pipermail/python-dev/2002-May/023998.html
> https://mail.python.org/pipermail/python-dev/2002-May/024006.html

In this case, though, the patch gets accepted:
https://mail.python.org/pipermail/python-dev/2002-May/024036.html
msg214895 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-03-26 11:26
(And hooray for that, given the meteoric rise of AtheOS. :| )

I'm going to go way out on a limb and say that Guido hasn't made a pronouncement here.  Also, the discussions cited by Martin are about entire new platforms (AtheOS, Haiku), whereas what we're talking about here is an additional architecture for an existing platform (m68k on linux).

So I'm going to use my best judgement.  I'm willing to accept the patch for 3.5, provided that:

  * it's understood that m68k is not an officially supported
    platform, and

  * this is sufficient, we won't need loads of other m68k support
    patches.  (As the saying goes, this patch should not be a
    "foot in the door".)

I do have two questions:

* With this patch applied, how much of the test suite passes?

* Is there a way that the configure check could be skipped on non-m68k
  platforms?  Because 99.999999% of the time, that check is irrelevant,
  and configure is already slow enough.

  Could you possibly just drop the GCC check?  Do you genuinely support
  m68k on linux using revisions of GCC that don't support inline
  assembly?


Finally, Mark Dickinson is right: since this patch changes behavior in an incompatible way, it's not permissible to check it in for 3.4.  Sorry.
msg215057 - (view) Author: Andreas Schwab (schwab) * Date: 2014-03-28 16:08
342 tests OK.
2 tests altered the execution environment:
    test_site test_warnings
33 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
    test_dbm_ndbm test_devpoll test_idle test_ioctl test_kqueue
    test_msilib test_ossaudiodev test_pep277 test_readline
    test_smtpnet test_socketserver test_sqlite test_ssl test_startfile
    test_tcl test_timeout test_tk test_ttk_guionly test_ttk_textonly
    test_unicode_file test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
msg215470 - (view) Author: mirabilos (mirabilos) Date: 2014-04-03 21:35
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.)
msg215475 - (view) Author: Andreas Schwab (schwab) * Date: 2014-04-03 22:13
> 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.
msg215477 - (view) Author: mirabilos (mirabilos) Date: 2014-04-03 22:42
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 ;)
msg215480 - (view) Author: Andreas Schwab (schwab) * Date: 2014-04-03 23:18
There is no excuse for using a broken emulator.
msg215482 - (view) Author: mirabilos (mirabilos) Date: 2014-04-03 23:42
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.
msg215495 - (view) Author: Andreas Schwab (schwab) * Date: 2014-04-04 06:55
Finn Thain <fthain@telegraphics.com.au> writes:

> until Aranym gets fixed.

Aranym *is* fixed.

Andreas.
msg215498 - (view) Author: mirabilos (mirabilos) Date: 2014-04-04 08:06
Andreas Schwab dixit:

>Finn Thain <fthain@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.7386@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 ;)
msg215501 - (view) Author: Andreas Schwab (schwab) * Date: 2014-04-04 08:21
The fixed version is here: git://git.code.sf.net/p/aranym/code

Andreas.
msg215503 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2014-04-04 09:18
If the asm instructions silently fail, I'd say add a test to ./configure
that detects the broken versions of the emulator in question.

Or don't bother and tell people to use the proper version of
the emulator.
msg215505 - (view) Author: Andreas Schwab (schwab) * Date: 2014-04-04 09:39
There is nothing that fails.  The emulator has always correctly implemented the insn.
msg215566 - (view) Author: mirabilos (mirabilos) Date: 2014-04-04 21:30
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 ;)
msg215567 - (view) Author: mirabilos (mirabilos) Date: 2014-04-04 21:42
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 ;)
msg215569 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-04-04 21:48
> I retract my veto.

You don't have a "veto".  Only Guido has that.

Anyhow you have yet to reply to Mr. Schwab's assertion:

> The emulator has always correctly implemented the insn.

If that's true, then I don't understand what this whole argument is about.
msg215825 - (view) Author: Andreas Schwab (schwab) * Date: 2014-04-09 16:38
The only problem is that under some conditions involving denormalized numbers the result may lose a bit of precision.  But that is mostly irrelevant for this issue, at least it wouldn't make it worse than it is now.
msg215827 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-04-09 17:23
> under some conditions involving denormalized numbers the result may lose a bit of precision

That sounds like a non-issue for this application: the dtoa.c computations are careful to avoid subnormals in intermediate computations.

If mirabilos has withdrawn his objection, is there anything blocking applying this for 3.5?
msg216623 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2014-04-16 23:19
Okay, I say let's check this in.  If mirabilos can cite problems it causes we can revert it.

Andreas, is there someone who would normally check this in for you, or should I do it?
msg216624 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2014-04-16 23:23
Larry Hastings <report@bugs.python.org> wrote:
> Andreas, is there someone who would normally check this in for you, or should I do it?

Traditionally Mark commits the floating point stuff. :)
msg216651 - (view) Author: Roundup Robot (python-dev) Date: 2014-04-17 04:00
New changeset c2f6551c9eaf by Benjamin Peterson in branch 'default':
support setting fpu precision on m68k (closes #20904)
http://hg.python.org/cpython/rev/c2f6551c9eaf
msg216708 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-04-17 16:43
Yay! Thanks, Benjamin.
History
Date User Action Args
2014-05-13 22:30:38skrahlinkissue18062 superseder
2014-04-17 16:43:03mark.dickinsonsetmessages: + msg216708
2014-04-17 04:00:54python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg216651

resolution: fixed
stage: patch review -> resolved
2014-04-16 23:23:00skrahsetmessages: + msg216624
2014-04-16 23:19:17larrysetmessages: + msg216623
2014-04-09 17:23:26mark.dickinsonsetmessages: + msg215827
2014-04-09 16:38:29schwabsetmessages: + msg215825
2014-04-04 21:48:09larrysetmessages: + msg215569
2014-04-04 21:42:22mirabilossetmessages: + msg215567
2014-04-04 21:30:20mirabilossetmessages: + msg215566
2014-04-04 09:39:23schwabsetmessages: + msg215505
2014-04-04 09:18:15skrahsetmessages: + msg215503
2014-04-04 08:21:12schwabsetmessages: + msg215501
2014-04-04 08:06:20mirabilossetmessages: + msg215498
2014-04-04 06:55:45schwabsetmessages: + msg215495
2014-04-03 23:42:21mirabilossetmessages: + msg215482
2014-04-03 23:18:33schwabsetmessages: + msg215480
2014-04-03 22:42:18mirabilossetmessages: + msg215477
2014-04-03 22:13:16schwabsetmessages: + msg215475
2014-04-03 21:35:23mirabilossetnosy: + mirabilos
messages: + msg215470
2014-03-28 16:08:13schwabsetmessages: + msg215057
2014-03-26 11:26:43larrysetmessages: + msg214895
2014-03-25 00:27:56benjamin.petersonsetmessages: + msg214771
2014-03-24 23:05:51skrahsetmessages: + msg214755
2014-03-24 22:18:50schwabsetmessages: + msg214748
2014-03-24 21:56:00loewissetmessages: + msg214744
2014-03-24 21:32:40loewissetmessages: + msg214734
2014-03-24 21:21:05pitrousetmessages: + msg214730
2014-03-24 21:20:34tim.peterssetmessages: + msg214729
2014-03-24 20:54:41benjamin.petersonsetmessages: + msg214725
2014-03-24 20:52:20larrysetmessages: + msg214724
2014-03-24 20:50:42benjamin.petersonsetmessages: + msg214723
2014-03-24 20:49:56larrysetmessages: + msg214722
2014-03-24 20:40:09benjamin.petersonsetmessages: + msg214720
2014-03-24 20:36:38schwabsetmessages: + msg214719
2014-03-24 20:17:32larrysetmessages: + msg214718
versions: - Python 3.4
2014-03-24 11:15:15mark.dickinsonsetmessages: + msg214683
2014-03-24 10:58:13Arfreversetnosy: + Arfrever
2014-03-24 10:57:21schwabsetmessages: + msg214682
2014-03-24 10:52:43mark.dickinsonsetmessages: + msg214681
2014-03-24 10:48:48schwabsetmessages: + msg214680
2014-03-24 10:38:43mark.dickinsonsetmessages: + msg214679
2014-03-24 10:36:53mark.dickinsonsetmessages: + msg214678
2014-03-24 10:28:57schwabsetmessages: + msg214677
2014-03-24 09:56:50mark.dickinsonsetmessages: + msg214676
2014-03-24 02:07:34larrysetmessages: + msg214665
2014-03-23 22:38:32loewissetnosy: + loewis
messages: + msg214646
2014-03-23 22:30:44georg.brandlsetmessages: + msg214645
2014-03-23 22:24:58pitrousetmessages: + msg214644
2014-03-23 22:21:50BreamoreBoysetmessages: + msg214643
2014-03-23 22:10:31georg.brandlsetmessages: + msg214641
2014-03-23 22:08:45skrahsetstage: patch review
versions: + Python 3.5, - Python 3.3
2014-03-23 21:51:51larrysetmessages: + msg214638
2014-03-23 17:31:25BreamoreBoysetmessages: + msg214619
2014-03-23 17:26:35georg.brandlsetmessages: + msg214618
2014-03-23 17:25:15skrahsetmessages: + msg214617
2014-03-23 17:17:59BreamoreBoysetmessages: + msg214616
2014-03-23 17:10:47georg.brandlsetnosy: + georg.brandl
messages: + msg214613
2014-03-23 17:06:01benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg214612
2014-03-23 17:03:37schwabsetmessages: + msg214611
2014-03-23 17:00:17BreamoreBoysetmessages: + msg214609
2014-03-23 16:57:02schwabsetmessages: + msg214607
2014-03-23 16:53:56BreamoreBoysetnosy: + BreamoreBoy
messages: + msg214606
2014-03-23 16:47:09schwabsetversions: + Python 3.4
2014-03-23 16:46:03schwabsetfiles: - m68k-float-prec.patch
2014-03-14 12:54:04larrysetmessages: + msg213540
2014-03-14 10:13:48pitrousetnosy: + pitrou
messages: + msg213531
2014-03-14 06:43:37schwabsetfiles: + m68k-float-prec.patch

messages: + msg213519
2014-03-13 18:19:24larrysetnosy: + larry
messages: + msg213431
2014-03-13 18:16:01skrahsetmessages: + msg213430
2014-03-13 17:58:02schwabsetmessages: + msg213426
2014-03-13 17:27:53mark.dickinsonsetmessages: + msg213420
2014-03-13 08:00:31pitrousetnosy: + tim.peters, mark.dickinson, skrah
2014-03-13 07:54:56schwabcreate