[issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail

2014-04-28 Thread Shiz

Shiz added the comment:

Ah, yes, if it's not actually mandated by POSIX, something like 
HAVE_PASSWD_PW_GECOS would be more appropriate. I'll rework the patch into 
something more generic.

--

___
Python tracker 
<http://bugs.python.org/issue20306>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.

2014-07-29 Thread Shiz

New submission from Shiz:

Currently, when cross-compiling, the configure script doesn't take $HOSTPYTHON 
into account when determining $PYTHON_FOR_BUILD. This can lead to a wrong 
Python interpreter being used for several critical cross-compilation stages, 
leading to compilation errors[1].

Attached is a patch which makes it take $HOSTPYTHON into account, thus solving 
said issues, diffed against the current hg tip, 723e0a7c4914.

[1]: https://github.com/rave-engine/python3-android/issues/1 (the last issue in 
the report)

--
components: Cross-Build
files: Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection.patch
keywords: patch
messages: 224230
nosy: shiz
priority: normal
severity: normal
status: open
title: Use $HOSTPYTHON when determining candidate interpreter for 
$PYTHON_FOR_BUILD.
type: enhancement
versions: Python 3.5
Added file: 
http://bugs.python.org/file36150/Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection.patch

___
Python tracker 
<http://bugs.python.org/issue22100>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.

2014-07-29 Thread Shiz

Changes by Shiz :


--
versions: +Python 3.3, Python 3.4

___
Python tracker 
<http://bugs.python.org/issue22100>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.

2014-07-31 Thread Shiz

Shiz added the comment:

After some further investigation it seems the which-clause fails when given a 
relative path. Since we should expect $HOSTPYTHON to be present in the first 
place, I modified the patch a bit to special-case the $HOSTPYTHON check, and 
fall back on the other interpreters as checked before.

--
Added file: 
http://bugs.python.org/file36181/Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection-v2.patch

___
Python tracker 
<http://bugs.python.org/issue22100>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue22100] Use $HOSTPYTHON when determining candidate interpreter for $PYTHON_FOR_BUILD.

2014-08-04 Thread Shiz

Shiz added the comment:

And a last tiny fix: on a lot of systems (except apparently the system I was 
using for my main testing), a freshly-built HOSTPYTHON will be confused to look 
for libraries, and the invocation will fail because it can't bootstrap itself. 
Point it to the current Python tree for libraries.

--
Added file: 
http://bugs.python.org/file36247/Python-hg-723e0a7c4914-fix-PYTHON_FOR_BUILD-detection-v3.patch

___
Python tracker 
<http://bugs.python.org/issue22100>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20305] Android's incomplete locale.h implementation prevents compilation

2014-01-19 Thread Shiz

New submission from Shiz:

As a result of Android's relatively incomplete locale.h implementation[1], some 
functions are not defined and some standard structs are lacking fields (e.g. 
decimal_point, thousand_sep).
This prevents proper cross-compilation using the Android NDK[2] from succeeding.

Attached is a patch which works around the various issues posed by Android's 
locale.h implementation, mainly involving falling back to default locale 
values, causing compilation in that department for the author to succeed.

[1]: https://groups.google.com/forum/#!topic/android-ndk/PBK4KkRpDoU
[2]: https://developer.android.com/tools/sdk/ndk/index.html

--
components: Cross-Build
files: Python-3.4.0tip-workaround-android-locale-issues.patch
keywords: patch
messages: 208486
nosy: shiz
priority: normal
severity: normal
status: open
title: Android's incomplete locale.h implementation prevents compilation
type: compile error
versions: Python 3.4
Added file: 
http://bugs.python.org/file33549/Python-3.4.0tip-workaround-android-locale-issues.patch

___
Python tracker 
<http://bugs.python.org/issue20305>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20305] Android's incomplete locale.h implementation prevents cross-compilation

2014-01-19 Thread Shiz

Changes by Shiz :


--
title: Android's incomplete locale.h implementation prevents compilation -> 
Android's incomplete locale.h implementation prevents cross-compilation

___
Python tracker 
<http://bugs.python.org/issue20305>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20306] Lack of pw_gecos field in Android's struct passwd causes cross-compilation for the pwd module to fail

2014-01-19 Thread Shiz

New submission from Shiz:

As the title states, mkpwent() in pwdmodule.c accesses `pw_gecos`, which is not 
defined for struct passwd in Bionic, Android's C library.

Attached is a patch that works around the issue by setting the field to None on 
Android.

--
components: Cross-Build
files: Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch
keywords: patch
messages: 208487
nosy: shiz
priority: normal
severity: normal
status: open
title: Lack of pw_gecos field in Android's struct passwd causes 
cross-compilation for the pwd module to fail
type: compile error
versions: Python 3.4
Added file: 
http://bugs.python.org/file33550/Python-3.4.0tip-workaround-android-missing-pw_gecos-field.patch

___
Python tracker 
<http://bugs.python.org/issue20306>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail

2014-01-19 Thread Shiz

New submission from Shiz:

Bionic, Android's C library, fails to expose the SYS_* constants used for the 
syscall(1) interface, which causes compilation of the _posixsubprocess module 
to fail as it directly attempts to call SYS_getdents64.

Attached is an experimental patch that manually defines SYS_getdents64 from 
Bionic's internals.

--
components: Cross-Build
files: Python-3.4.0tip-expose-SYS_getdents64-on-android.patch
keywords: patch
messages: 208488
nosy: shiz
priority: normal
severity: normal
status: open
title: Android's failure to expose SYS_* system call constants causes 
_posixsubprocess cross-compilation to fail
type: compile error
versions: Python 3.4
Added file: 
http://bugs.python.org/file33551/Python-3.4.0tip-expose-SYS_getdents64-on-android.patch

___
Python tracker 
<http://bugs.python.org/issue20307>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail

2014-01-19 Thread Shiz

Shiz added the comment:

I of course meant the syscall(2) interface, not syscall(1).

--

___
Python tracker 
<http://bugs.python.org/issue20307>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20305] Android's incomplete locale.h implementation prevents cross-compilation

2014-01-20 Thread Shiz

Shiz added the comment:

I managed to cross-compile Python 3.3.3 for arm-linux-androideabi (using the 
Android NDK r9c) with the patches in this issue, issue 20306 and issue 20307. 
It did require a small additional patch which addressed the fact that the host 
system can't run the generated parser generator, which I'll make an issue for 
as soon as I refactored the patch. The patch allows the user to specify a host 
parser generator that points to a compiled version of pgen that is runnable on 
the host through the HOSTPGEN environment variable in ./configure.

Compiling the tip proved somewhat harder as the cross-compilation requires a 
host Python of the same version, which I didn't have. I formatted a patch which 
allows the user to supply a special host python path using the HOSTPYTHON 
environment variable to ./configure. I'll make an issue for that soon, and will 
bundle it with the HOSTPGEN patch if it's seen as a sufficient approach.

As far as maintaining an Android port for CPython goes; I may be interested in 
this as I'd need to regularly use it anyway. Can anyone tell me what the 
possibilities are here?

Since in the meanwhile the tip was updated to unconditionally include locale.h 
in Python/fileutils.c according to issue 19036, here's an updated patch for 
this issue that applies cleanly against the tip.

--
Added file: 
http://bugs.python.org/file33569/Python-3.4-d51d6f1f9db8-workaround-android-locale-issues.patch

___
Python tracker 
<http://bugs.python.org/issue20305>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20305] Android's incomplete locale.h implementation prevents cross-compilation

2014-01-20 Thread Shiz

Shiz added the comment:

>   c) Many (or all) core committers did not have access to the platform
>  in question.

I'd say Android is quite a common platform these days, although I'd concur that 
it's not particularly easy to run Python OOTB on. :)

>Wikipedia claims that "QEMU also powers the Android emulator which is part of
>the Android SDK."  Can you run a build slave with network access and also run
>the test suite in this emulator?

I've been looking into this, and the only option provided by the Android NDK 
involves cross-compiling Python on a regular machine. This would require some 
custom commands before and in between the builds, to build a host Python first, 
then cross-compile the Android Python, and then start the emulator, transfer 
the binaries there and run the tests over adb. Can buildbot provide 
functionality so this can be configured on-slave, or would it require setting 
up a seperate master?

--

___
Python tracker 
<http://bugs.python.org/issue20305>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail

2014-01-20 Thread Shiz

Shiz added the comment:

That's probably a good idea. Fixed patch attached.

--
Added file: 
http://bugs.python.org/file33584/Python-3.4.0tip-expose-SYS_getdents64-on-android-v2.patch

___
Python tracker 
<http://bugs.python.org/issue20307>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20307] Android's failure to expose SYS_* system call constants causes _posixsubprocess cross-compilation to fail

2014-01-20 Thread Shiz

Shiz added the comment:

Please take note of the discussion in issue 20305 if you were planning to merge 
this, by the way.

--

___
Python tracker 
<http://bugs.python.org/issue20307>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25468] PyTraceBack_Print()/_Py_DisplaySourceLine() should take custom loaders into account

2015-10-25 Thread Shiz

New submission from Shiz:

Currently, when an error occurs in a module loaded through a loader in 
sys.meta_path with no direct file name correlation on the filesystem, the 
traceback source line is empty as such:

  File "/Users/mark/Development/Projects/Rave/rave/rave/game.py", line 65, in 
run   
self.window.render(None)

  File "/.modules/sdl2/video/window.py", line 86, in render 

  File "/.modules/sdl2/video/window.py", line 259, in swap  

KeyboardInterrupt   

While the filename has no direct mapping on the file system, what it can do is 
just do the equivalent of module.__loader__.get_source('module') to retrieve 
the source code to find the appropriate line in, and only if that fails fall 
back on trying to interpret the module file name as a normal file system path.

--
components: Interpreter Core
messages: 253400
nosy: shiz
priority: normal
severity: normal
status: open
title: PyTraceBack_Print()/_Py_DisplaySourceLine() should take custom loaders 
into account
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 
<http://bugs.python.org/issue25468>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23773] importlib does not properly remove frames when invoking external import hooks

2015-03-24 Thread Shiz

New submission from Shiz:

When adding a custom module loader to sys.meta_path, importlib does not 
properly remove its frames before invoking it. This results in a weird 
traceback with importlib._bootstrap frames in if an error occurs during 
load_module(), like such:

Traceback (most recent call last):
  File "/Users/mark/Development/Projects/rave/rave/bootstrap/__init__.py", line 
102, in bootstrap_game
__import__(MODULE_PACKAGE + '.' + mod.replace('.py', ''))
  File "", line 2237, in _find_and_load
  File "", line 2226, in _find_and_load_unlocked
  File "", line 1200, in _load_unlocked
  File "", line 1129, in _exec
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in 
exec_module
super().exec_module(module)
  File "/.modules/opengl/__init__.py", line 1, in 
from . import common, core3
  File "", line 2237, in _find_and_load
  File "", line 2226, in _find_and_load_unlocked
  File "", line 1200, in _load_unlocked
  File "", line 1129, in _exec
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in 
exec_module
super().exec_module(module)
  File "/.modules/opengl/core3/__init__.py", line 11, in 
from .texture import Texture, Image
  File "", line 2237, in _find_and_load
  File "", line 2226, in _find_and_load_unlocked
  File "", line 1200, in _load_unlocked
  File "", line 1129, in _exec
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in 
exec_module
super().exec_module(module)
  File "/.modules/opengl/core3/texture.py", line 8, in 
raise ValueError

Attached is a patch against the current hg head that makes sure module loaders 
are invoked through _call_with_frames_removed, so that the output becomes a lot 
more readable:

Traceback (most recent call last):
  File "/Users/mark/Development/Projects/rave/rave/bootstrap/__init__.py", line 
102, in bootstrap_game
__import__(MODULE_PACKAGE + '.' + mod.replace('.py', ''))
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in 
exec_module
super().exec_module(module)
  File "/.modules/opengl/__init__.py", line 1, in 
from . import common, core3
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in 
exec_module
super().exec_module(module)
  File "/.modules/opengl/core3/__init__.py", line 11, in 
from .texture import Texture, Image
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in 
exec_module
super().exec_module(module)
  File "/.modules/opengl/core3/texture.py", line 8, in 
raise ValueError
ValueError

Ideally it would remove the calls /within/ the module loader itself too, but I 
do not see an easy way to do this without changing the entire 
_call_with_frames_removed semantics. This fixes most of the issues, though.

--
components: Library (Lib)
files: cpython-3ac58de829ef-fix-external-module-loader-call-traceback.patch
keywords: patch
messages: 239219
nosy: shiz
priority: normal
severity: normal
status: open
title: importlib does not properly remove frames when invoking external import 
hooks
type: behavior
versions: Python 3.4, Python 3.5
Added file: 
http://bugs.python.org/file38681/cpython-3ac58de829ef-fix-external-module-loader-call-traceback.patch

___
Python tracker 
<http://bugs.python.org/issue23773>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23773] importlib does not properly remove frames when invoking external import hooks

2015-04-13 Thread Shiz

Shiz added the comment:

Ah, that is a very good point. I'll run the suite as soon as I find the time 
and will report back.

--

___
Python tracker 
<http://bugs.python.org/issue23773>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com