[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Martin v. Löwis added the comment: This issue remains as "won't fix". ARM is supported; just OABI is not, and never will be. If anybody needs that, they will have to maintain their own fork of Python. -- ___ Python tracker

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Dickinson added the comment: [Dirkjan] > Could we reconsider ARM support at this time? Note that it's just the Linux old ABI (OABI) that needs this patch; ARM / Linux using the new family of ABIs (EABI) should be fine. IIUC, this old ABI is being phased out, but I have no idea what the

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Dirkjan Ochtman added the comment: Could we reconsider ARM support at this time? Seems like ARM support has been surging over the past few years, and it's becoming more supported by Linux distributions. Seems like a pity to leave a patch like this out here. -- nosy: +djc

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Nir Soffer added the comment: As someone who has to develop on ARM OABI, I find this won't fix policy rather frustrating. If you happen to need this patch on 2.7, this is the same patch as arm-float2.diff, which can be applied cleanly to release 2.7.2. Changes from arm-float2.diff: - Remove

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Dickinson added the comment: Thanks Martin and Mark Miller for the comments and testing. I'm going to close this as "won't fix". This doesn't preclude ARM OABI becoming a supported platform at some point in the future, just not right now. -- resolution: -> wont fix status: open

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Changes by Martin v. Löwis : -- versions: -Python 2.5, Python 2.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Miller added the comment: The new patch works correctly, by the way, on ARMv4L and ARMv5L OABI boards. ___ Python tracker ___ ___ Pytho

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Miller added the comment: I am in a position to test as much as needed. I am attempting to get Gentoo's ARM/MIPS/Embedded distribution up to date on Python, and noticed this build break. (Typically most embedded architectures are several releases behind.) I'll try this new patch right now.

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Martin v. Löwis added the comment: > I'm still not sure whether this can be a candidate 2.6 and 3.0. Martin, > do you have any thoughts on this? I think this qualifies as a new port. In the past, we have avoided adding new ports in bugfix releases. As for adding it to 2.7/3.1: I'm also skept

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Dickinson added the comment: I think my -1 for adding the new format was premature: I was hoping to find a way to fix marshal for the 'unknown' format, but the cleanest solution does indeed appear to be to add the mixed-endian format. And apart from the Python/compile.c oddity I can't

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Dickinson added the comment: We still need to fix the compile failure somehow, though... Mark, is there any way you can isolate the test(s) in test_float that are causing compile failure? I'm suspicious of test_inf_as_str and test_nan_as_str. Does test_float compile if you remove these

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Dickinson added the comment: > native endianness support in the struct module comes to mind Sorry: ignore that. The patch already covers this, since the struct module just uses _PyFloat_{Unp,P}ack8. ___ Python tracker

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Dickinson added the comment: Thanks, Mark. A few comments: - The patch seems incomplete. There are other places in the source tree that care about endianness. I haven't done a thorough search, but the native endianness support in the struct module comes to mind. There are also some

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Miller added the comment: The following is where it fails un-patched: Compiling /usr/local/lib/python2.6/test/test_float.py ... Traceback (most recent call last): File "/usr/local/lib/python2.6/compileall.py", line 156, in exit_status = int(not main()) File "/usr/local/lib/python2

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Dickinson added the comment: I'll take a look at this, provided Tim doesn't mind me stealing his issue. (Please steal it back if so.) Mark, could you please post the output from test_float? -- assignee: tim_one -> marketdickinson nosy: +marketdickinson __

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Mark Miller added the comment: This still occurs in the latest SVN checkout, and is preventing Python from building on ARMV4L and ARMV5L OABI, dying during the test_float.py compilation. The patch appears to solve this problem, however I have not run a full suite of tests to ensure it doesn't ha

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Aurelien Jarno <[EMAIL PROTECTED]> added the comment: AFAIK, this "mixed-endian" format is only used on little endian ARM (old-ABI only). That is true that IEEE 754 does not specify any format. I used the big and little endian code as a template to add the "ARM format", hence IEEE in the nam

[issue1762561] unable to serialize Infinity or NaN on ARM using marshal

Martin v. Löwis added the comment: I'm not sure like the naming of the format. "mixed-endian" could mean anything. I doubt IEEE specifies this as a possible byte representation (but then, I'm uncertain whether IEEE specifies big-endian and little-endian, either). One option would be to call it "