Ray Donnelly added the comment:
I took the liberty of filing this: https://bugs.python.org/issue40263
Cheers.
--
nosy: +Ray Donnelly
___
Python tracker
<https://bugs.python.org/issue26
Ray Donnelly added the comment:
https://github.com/python/cpython/pull/19501
--
___
Python tracker
<https://bugs.python.org/issue40263>
___
___
Python-bug
Change by Ray Donnelly :
--
nosy: +Ray.Donnelly
nosy_count: 5.0 -> 6.0
pull_requests: +18852
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19501
___
Python tracker
<https://bugs.python.org/i
Change by Ray Donnelly :
--
keywords: +patch
Added file:
https://bugs.python.org/file49057/-Fix-off-by-one-error-in-_winapi_WaitForMultipleObjec.patch
___
Python tracker
<https://bugs.python.org/issue40
Change by Ray Donnelly :
Removed file:
https://bugs.python.org/file49056/-bpo-26903-Limit-ProcessPoolExecutor-to-61-workers-on-Windows.patch.ref
___
Python tracker
<https://bugs.python.org/issue40
Ray Donnelly added the comment:
See my proposed patch. I am happy to make a PR on github for this too if people
agree it's the right fix.
--
Added file:
https://bugs.python.org/file49056/-bpo-26903-Limit-ProcessPoolExecutor-to-61-workers-on-Windows.patch.ref
New submission from Ray Donnelly :
See attached reproducer
--
components: Interpreter Core, Windows
files: ppe.py
messages: 366258
nosy: Ray Donnelly, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Follow on bug from https
Ray Donnelly added the comment:
.. and alternative to my ACP idea would be to use `GetACP()` or
`getfilesystemencoding()` .. or? Suggestions welcome!
--
___
Python tracker
<https://bugs.python.org/issue36
New submission from Ray Donnelly :
Hi all,
I'd like to entertain some discussion around the idea of calling CreateProcessW
instead of CreateProcess on Windows.
I've written a patch as a proof of concept and I would love to get some
feedback. I guess I've broken the normal ACP
Ray Donnelly added the comment:
Thanks Steve, the sys.path value from the first comment can be discarded, it
was running the wrong Python!
The 'old' mechanism (which my patch reverts to) does copy all the necessary
DLLs already. I released builds with this patch now and venv works fine
Change by Ray Donnelly :
--
title: venv doesn't do what it claims to do (apears not to work at all?) ->
venv doesn't work on Windows when no venvlauncher executable present
___
Python tracker
<https://bugs.python.org/issu
Ray Donnelly added the comment:
The commit that my patch modifies is:
https://github.com/python/cpython/commit/1c3de541e64f75046b20cdd27bada1557e550bcd
Cheers.
--
___
Python tracker
<https://bugs.python.org/issue35
Ray Donnelly added the comment:
Bit of an update to this, I'm re-opening it as there appears to be a regression
from Python 3.7.1 to 3.7.2 for the case when there is no venvlauncher.exe
present (i.e. when there are no python{w,}.exes in Lib\venv\scripts\nt). The
old code of copying
Ray Donnelly added the comment:
I found the executable is in the `Scripts` directory, closing. The real issue
I'm facing is on Anaconda Distribution's build of Python 3 which I'm updating
to 3.7.2.
Closing,
Cheers!
--
stage: -> resolved
status: open ->
New submission from Ray Donnelly :
Happy New Year!
I'm not sure if this is a misunderstanding on my part, a docs bug or a code bug.
At https://docs.python.org/3/library/venv.html we see:
"The solution for this problem is to create a virtual environment, a
self-contained directory
Change by Ray Donnelly <rdonne...@anaconda.com>:
--
nosy: +Ray Donnelly
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33232>
___
Ray Donnelly <rdonne...@anaconda.com> added the comment:
.. though I will also ask the scons people to change this to use pushd and %CD%
instead. Even if you were to make Python capable of handling such bad input,
who knows what other programs will fail, and build systems should be
New submission from Ray Donnelly <rdonne...@anaconda.com>:
Over on the Anaconda Distribution we received a (private) bug report about a
crash when trying to use scons. I thought initially it was due to one of our
patches but I tested it out with official CPython and also with Win
Ray Donnelly added the comment:
Yes, patches are still required.
Mainly Roumen's big patch [1] and then a load more too. Matthias Klose has
merged a few cross compilation patches.
Here my project with patches for 3.3.0 and an emphasis on cross:
https://github.com/mingwandroid/crucifixion
Ray Donnelly added the comment:
Great Roumen, please split into new issues then make a new overall tracking
issue, then this one can be left for historians and archaeologists.
For Posix installation scheme I've got:
https://github.com/niXman/mingw-builds/blob/master/patches/Python-3.3.0/0050
Ray Donnelly added the comment:
Thank you Matthias!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16235
___
___
Python-bugs-list mailing list
Ray Donnelly added the comment:
When I say “our patches” I mean mine and Alexey Pavlov’s jointly maintained
patch-set.
I hope you don’t mind that I find you saying:
I tried some of these patches, but they aren't very organinzed. I really need
some docemntaiton to better understand what each
Ray Donnelly added the comment:
Re: basing the patches against the latest master branch or targeting released
versions, I wasn't clear enough about my thinking.
For sure, when trying to get any patches merged, the submitted patch must be
re-based (forward ported) and tested against the master
Ray Donnelly added the comment:
Roumen, I think it would be really great if you could split
py3k-20121004-MINGW.patch up into separate bits.
The pthread stuff and libffi stuff being two obvious candidates for atomic
parts.
--
___
Python tracker
Ray Donnelly added the comment:
Great. My only query is whether the changes to sed will work on non-GNU sed.
It used to be like:
sed in out
you've now got:
sed in out
I'm not saying it won't work, I'm not in a position to check, but I think it's
safer to keep
Ray Donnelly added the comment:
Good work Jason,
I think it would be great if everyone could collaborate better with this stuff;
I'm as guilty as the next person on that score though. I might have been able
to save you some effort by pointing you at either:
https://github.com/mingwandroid
Ray Donnelly added the comment:
New patch attached:
LIBPL changed to a more direct AC_SUBST and PLATINCDIR used for --includes and
--cflags.
--
Added file: http://bugs.python.org/file28164/-add-python-config-sh.patch
___
Python tracker rep
New submission from Ray Donnelly:
I'm submitting this patch as it was suggested I do so by Antoine Pitrou on
#python-dev. As such, it's more a point of discussion than a patch I'm trying
to get merged (for one thing, my build is a MinGW GCC compiled and I've not
considered the MSVC Windows
Ray Donnelly added the comment:
I should have checked the situation better, it is indeed towards the back end
of a series of patches to enable MinGW compilation, so the issue is irrelevant
without the preceding patches.
Sorry for the noise.
--
resolution: - invalid
Ray Donnelly added the comment:
I've addressed everything (local, ABIFLAGS) except the platform includes.
AFAICT, platform includes only differs from includes during the Python build
phase. This script can only be run post-install.
I also added --extension-suffix, tidied it up and allowed
Ray Donnelly added the comment:
is there a need for the built vs. installed prefix?
this is logic not found in the python implementation.
what is this supposed to do?
You are right, it is not found in the original python implementation, but I
feel that it's useful. Without it, you
Ray Donnelly added the comment:
hmm, but python.pc, _sysconfigdata.py and Makefile still have this
information.
In my experience, as long as PYTHONHOME is set correctly before the Python .so,
.dll or .dylib is loaded then everything works correctly.
From what I've seen, .pc files are also
Ray Donnelly added the comment:
I agree in principle about not having to maintain two implementations but I
would worry about breaking external packages that depend on the python
implementation.
In the meantime, please find an updated version of this patch that adds support
for --configdir
Ray Donnelly added the comment:
I also checked the Windows releases and python-config isn't included. However,
I don't think there's a good reason for that. python-config would in theory
work fine if people wanted to link their programs to Python on Windows, as
would python-config.sh given
Ray Donnelly added the comment:
A small question about the patch, why this case in the cross_arch function:
From a real Mac Book Pro:
$ uname -a
Darwin MACBOOKPRO.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23
16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
$ /usr/bin
Changes by Ray Donnelly mingw.andr...@gmail.com:
Removed file: http://bugs.python.org/file27641/0010-DARWIN-CROSS.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16291
Ray Donnelly added the comment:
Here's the darwin cross enabling portion. I've also removed the warnings fixes
from it as they're not relevant.
--
title: Fix some general cross compile issues and some darwin specific ones.
Tested with build=linux, host=darwin - Enable darwin-host
New submission from Ray Donnelly:
I've fixed up the very few missing configure bits and one issue with
PYTHON_FOR_BUILD using srcdir instead of builddir. I also rolled in a simple
warning fix that I ran into (the #ifdef HAVE_CHROOT added to posixmodule.c)
configured with:
$srcdir/configure
New submission from Ray Donnelly:
This patch fixes 2 cross compilation bugs and improves a comment.
--
components: Cross-Build
files: 0005-cross-fixes.patch
keywords: patch
messages: 173423
nosy: Ray.Donnelly, doko
priority: normal
severity: normal
status: open
title: Cross compilation
Ray Donnelly added the comment:
It seems to me that such an animal would be fragile and incomplete at best.
There's no reason for it to be either fragile or incomplete. My cross builds
have a goal of being comprehensive.
Python builds on OS X normally require certain OS X frameworks outside
Changes by Ray Donnelly mingw.andr...@gmail.com:
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16292
___
___
Python-bugs-list
New submission from Ray Donnelly:
Creates python-config.sh which aims to behave exactly the same as python-config
except it doesn't depend on a Python interpreter on the build machine (only
depends on a posixy shell, tested with bash, dash, MSYS-bash).
I use this for cross compiling gdb
Ray Donnelly mingw.andr...@gmail.com added the comment:
For me, it's all about being able to build useful software. I like Python a
lot, but my goal is and has always been cross compilation of gdb with Python
support. To that end, if I have to maintain some out of tree patches for 2.7.3
Ray Donnelly mingw.andr...@gmail.com added the comment:
I'm not personally interested in Cygwin (it's too slow for my liking) and I've
spent a lot of time patching and building software to avoid forcing people to
use it (no offence meant to Cygwin people, I can see the value of it, but IMHO
Ray Donnelly mingw.andr...@gmail.com added the comment:
Thanks Matthias, I might wait until b2 (or rc1) before I rebase my patches,
just because I'm so unfamiliar with Mercurial.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Ray Donnelly mingw.andr...@gmail.com added the comment:
NCURSES_INTERNALS stuff appears to be redundant:
Mac OS X curses.h, Linux curses.h and Windows PDCurses.h don't reference it,
nor does the Python 3.3.0b1 source code. Of course, I haven't checked any other
systems.
However: see http
Ray Donnelly mingw.andr...@gmail.com added the comment:
Re Android
Ah of course. In that case, there's always the NDK built by Dmitry (his latest
is v7 AFAIK):
http://www.crystax.net/en/android/ndk
--
___
Python tracker rep...@bugs.python.org
http
Ray Donnelly mingw.andr...@gmail.com added the comment:
Thanks for the details. I've got more fixes but I want to get the whole thing
building (at least) before I post them.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Ray Donnelly mingw.andr...@gmail.com:
Added file:
http://bugs.python.org/file25761/python-py3k-20120318-MINGW-330a2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3871
Changes by Ray Donnelly mingw.andr...@gmail.com:
Added file:
http://bugs.python.org/file25762/python-py3k-20120318-CROSS-330a2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3754
Ray Donnelly mingw.andr...@gmail.com added the comment:
Hi Roumen,
Many thanks for your patches, I've been using a 2.7.1 version of your patches
for Python integration with GDB (pretty-printing) of my own version of the
Android NDK for ages now (part of the Necessitas Qt project) and I really
Changes by Ray Donnelly mingw.andr...@gmail.com:
Added file:
http://bugs.python.org/file25764/python-py3k-20120318-MINGW-330a2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3871
Changes by Ray Donnelly mingw.andr...@gmail.com:
Removed file:
http://bugs.python.org/file25764/python-py3k-20120318-MINGW-330a2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3871
Ray Donnelly mingw.andr...@gmail.com added the comment:
Although mainly focussed on MinGW, I've begun adding Darwin cross support. I've
also built Darwin cross compilers. The latest Linux version can be found at:
http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42
Ray Donnelly mingw.andr...@gmail.com added the comment:
Hi Éric,
Do you mean this bit?:
diff -urN a/Lib/distutils/cygwinccompiler.py b/Lib/distutils/cygwinccompiler.py
--- a/Lib/distutils/cygwinccompiler.py 2012-05-30 07:33:00.234438631 +0100
+++ b/Lib/distutils/cygwinccompiler.py 2012-05-30
55 matches
Mail list logo
