Changes by Ronald Oussoren <[EMAIL PROTECTED]>:
--
assignee: jackjansen ->
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1724366>
_
___
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
Closing as this doesn't seem really useful anyway and nobody responded to
my question if the issue is still relevant.
--
resolution: -> wont fix
status: open -> closed
___
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
I've tested the patch on 10.4.10 as wel as 10.5.2 and it returns the right
version on both platforms.
Commited as revision 62854 (trunk) and 62855 (python2.5 branch)
--
assignee: jackjansen -> ronaldoussoren
resolut
Ronald Oussoren <[EMAIL PROTECTED]> added the comment:
On 21 Oct, 2008, at 22:57, Roumen Petrov wrote:
>
> It is possible gcc to compile for multiple architectures at same
> time ?
Yes. Apple's gcc driver knows how to deal with
Ronald Oussoren added the comment:
On 28 Dec, 2008, at 16:38, Benjamin Peterson wrote:
>
> Benjamin Peterson added the comment:
>
> I applied the patch for #4060 in r67982.
I've backported that to 2.6-maint in r67987.
>
>
> I would still like to know what difference
Ronald Oussoren added the comment:
I've committed the patch with some documentation in r67988, with a
backport to 2.6.x in r67989. r67990 (not backported) is a minor update
of the patch, it adds explicit support code for all three variants that
are configurable through the configure s
New submission from Ronald Oussoren :
I needed the attached patch to install a framework build of Python3 (py3k
branch), otherwise the 'regen' script wouldn't start to build Lib/plat-
mac.
I haven't applied the patch to the repository because I don't know if
there
Ronald Oussoren added the comment:
The issue is caused by lack of support for building .dylibs in
configure.in and Makefile.pre.in. AFAIK this has never worked on OSX.
Fixing that is not entirely trivial (did I mention configure.in is rather
crufty?).
The attached patch should fix that (the
Ronald Oussoren added the comment:
"make frameworkinstall" should be deprecated anyway, AFAIK it should be
possible to use "make install" or "make altinstall" for framework
installs as well. That latter should make it possible to install
multiple versions
Ronald Oussoren added the comment:
Can you reproduce this problem with the installer for Python 2.6?
___
Python tracker
<http://bugs.python.org/issue1738250>
___
___
Pytho
Ronald Oussoren added the comment:
Never mind, the patch won't work. Python's build procedure on unix-y
platforms assumes that the suffix for shared libraries is the same as that
for python extentions. That's not true on OSX :-(
I'm working
Changes by Ronald Oussoren :
Removed file: http://bugs.python.org/file12496/issue4472.patch
___
Python tracker
<http://bugs.python.org/issue4472>
___
___
Python-bug
Ronald Oussoren added the comment:
I've uploaded a new version of issue4472.patch that seems to do the trick:
this supports --enable-shared and also still works without that flag.
Added file: http://bugs.python.org/file12497/issue4472.patch
___
P
Ronald Oussoren added the comment:
"SO=.dylib" is needed in the makefile to ensure that "make install"
works and to ensure that the libpython shared library is build with the
right suffix (OSX uses .dylib for shared libraries).
The code in distutils.sysconfig is nece
Ronald Oussoren added the comment:
A --enable-framework and --enable-shared are mutable exclusive. You
either have a regular unix build or a Python.framework.
As to the SO update: the only way to avoid my change is yet another
variable in the makefile. The "altbininstall" target as
Ronald Oussoren added the comment:
Skip:
* GCC always generates position-independent code on OSX
* I'll look in the test issue, that's probably caused by a broken
definition for RUNSHARED.
Roumen:
* The SHLIB_EXT definition in pyconfig.h is an issue. And I have to
agree that &qu
Ronald Oussoren added the comment:
LDLIBRARY is indeed a good variable to use.
I've applied issue447-v2.patch in r68146. Backported to 2.6.x in r68147.
Added file: http://bugs.python.org/file12535/issue4472-v2.patch
___
Python tracker
Changes by Ronald Oussoren :
--
resolution: accepted -> fixed
status: open -> pending
___
Python tracker
<http://bugs.python.org/issue4472>
___
___
Pyth
Ronald Oussoren added the comment:
I've ported the fix to the trunk in r68149
___
Python tracker
<http://bugs.python.org/issue4780>
___
___
Python-bugs-list m
Ronald Oussoren added the comment:
I can confirm that this issue is fixed.
--
resolution: works for me -> fixed
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
Fixed in r68150 (python-trunk), r68151 (python 2.6.x), r68152 (python
3.x).
Could someone that actually has Fink installed confirm that the issue is
actually fixed? My patch consists of changing 'cp' to '/bin/cp' to ensure
that the
Ronald Oussoren added the comment:
This is almost certainly a Tk issue and hence not something we can fix.
I'm not closing the bug though because I no too little of Tk to be sure.
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.py
Ronald Oussoren added the comment:
I located the problem, it's in the configure line:
./configure --with-framework-name=Python64 --
with-universal-archs=all --enable-framework --enable-
universalsdk=MACOSX_DEPLOYMENT_TARGET=10.5
That's wrong because the argument for --enable-un
Ronald Oussoren added the comment:
The lack of a preferences menu is a bug: the current revisions of python
contain some code to detect a recent version of Tcl/Tk, used to create the
Preferences... menu in different way. Sadly enough this code is buggy, the
end result is that you will not
Ronald Oussoren added the comment:
Closing because zappyfiles.py is no longer part of the python distribution
--
nosy: +ronaldoussoren
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
I won't commit this patch because I cannot reproduce the problem.
The python trunk works fine for my in these build configurations: unix-
build (static library), unix-build (shared library), framework build.
All of this on OSX 10.5.
Can you please pr
Ronald Oussoren added the comment:
Fixed in r68156 (including testcase). Annoyingly enough only
GetCreatorAndType needed fixing, SetCreatorAndType already did the right
thing (makeing the two functions inconsistent with each other).
Won't fix for earlier releases, this might break exi
Ronald Oussoren added the comment:
Fixed in r68158.
--
nosy: +ronaldoussoren
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
Fixd in r68159
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
I've applied this patch in r68160.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ronald Oussoren added the comment:
Fixed this issue in r68161 by porting the solution for this in os.mkdirs
to macostools.
--
nosy: +ronaldoussoren
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.p
Ronald Oussoren added the comment:
I've applied this patch. If I understand things correctly that should
fix the cygwin issue.
Index: Makefile.pre.in
===
--- Makefile.pre.in (revision 68149)
+++ Makefile.pre.in (wo
Ronald Oussoren added the comment:
I agree with Bob's last response. Futhermore bundlebuilder is deprecated,
use py2app instead.
--
nosy: +ronaldoussoren
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://b
Ronald Oussoren added the comment:
Closing this issue as bundlebundler is deprecated.
--
nosy: +ronaldoussoren
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
Fixed in r68163
--
nosy: +ronaldoussoren
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
Fixed in r68163
--
nosy: +ronaldoussoren
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
Closed as won't fix because bundlebuilder is deprecated and it is rather
unlikely that anyone will spent time on this feature request.
--
nosy: +ronaldoussoren
resolution: -> wont fix
status: open -
Ronald Oussoren added the comment:
The manpage for writev(2) mentions #include . Adding a #include
for is the right fix after all...
___
Python tracker
<http://bugs.python.org/issue4
Ronald Oussoren added the comment:
This is a bug, I'm working on a fix.
___
Python tracker
<http://bugs.python.org/issue5143>
___
___
Python-bugs-list mailing list
Ronald Oussoren added the comment:
The quick fix is to convert "p" to a wchar_t (using mbstowcs), see
patch-mbstowcs.txt.
However, I don't think this is the right fix. AFAIK this environment
variable is only used by .app bundles created by bundlebuilder.py which
is no lon
Changes by Ronald Oussoren :
Added file: http://bugs.python.org/file12930/patch-remove-PYTHONEXECUTABLE.txt
___
Python tracker
<http://bugs.python.org/issue5143>
___
___
Ronald Oussoren added the comment:
Please let me know if second patch (patch-remove-PYTHONEXECUTABLE.txt)
fixes the issue for you as well, if it does I'll commit it to the 3.x
branch (and add an item to the NEWS file).
--
resolution: ->
Ronald Oussoren added the comment:
I've fixed this for 3.1 in r69532. Fixed for 3.0 in r69533 (backport of
the other patch).
The actual checkin is based on "patch-nad0014-py3k-30.txt", but with some
minor tweaks (I use "idlelib.macosxSupport.runningAsOSXApp" througho
Ronald Oussoren added the comment:
Applied the patch as r69534 (3.1) and r69534 (3.0)
--
nosy: +ronaldoussoren
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
Applied as r69536 (3.1) and r69537 (3.0)
--
nosy: +ronaldoussoren
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
I don't like this patch because it could grow the users profile without
bounds when switching back and forth between two python versions.
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.py
Ronald Oussoren added the comment:
Applied patch for 3.1 (r69538) and 3.0 (r69539).
--
nosy: +ronaldoussoren
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
I've applied both the fix and tests in r69540 (3.1) and r69541 (3.0)
--
status: open -> closed
___
Python tracker
<http://bugs.python.or
Ronald Oussoren added the comment:
I've committed the ronald-configDialog.patch to 3.1 and 3.0. This does
mostly the same as Kevin's patch, but only on OSX (that is, I check for
OSX and don't add the padding arguments in that case).
I haven't applied Kevin's patch a
Ronald Oussoren added the comment:
Committed as r69544 (3.1) and r69545 (3.0)
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue5
Ronald Oussoren added the comment:
reopened because this issue was only fixed for python 3.x
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
Reopened the issue because it is only fixed for 3.x at the moment.
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
I agree that we need a better solution to select which version of Python
is the default one of your path.
One way to do that is to have a tool that can change the "Current" link
inside the framework, that way we could have
/Library/
New submission from Ronald Oussoren :
The Mac port of Python contains a binary named "PythonLauncher" which
can be used as the association of ".py" and ".pyw" files. This program
will launch the script (either in a Terminal window or without a
window).
In hindsi
Ronald Oussoren added the comment:
WITH_NEXT_FRAMEWORK is a compile time option, I've added it to globals in
values like PREFIX are added. That way the python code can behave differently
for framework builds (which appears to be needed).
There are two big problems with my pa
Ronald Oussoren added the comment:
I've updated the title to better reflect the actual problem.
An update on the current state of this issue:
I haven't looked at the code for a couple of days because because I got stuck.
With a fresh mind I've continued debugging and n
Ronald Oussoren added the comment:
issue33955 is an older issue about implementing the current functionality for
this on macOS, which has an API for querying stack limits.
--
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.
Ronald Oussoren added the comment:
> However, it's the site.py module that actually updates sys.prefix for the
> venv. So you may just be inspecting at the wrong point? Or possibly it's in a
> codepath that doesn't run on macOS because *previously* it was being set
Ronald Oussoren added the comment:
venv requiring site isn't really a problem, although it is a bit weird that
sys.prefix changes when using the -S flag.
--
___
Python tracker
<https://bugs.python.org/is
Ronald Oussoren added the comment:
One consideration is support for older LTS distributions of Linux, RHEL/Centos
7 appears to ship with Tcl/Tk 8.5.
The system install of Tcl/Tk on macOS is also 8.5, but that variant has too
many bugs to try to support it.
--
nosy: +ronaldoussoren
Change by Ronald Oussoren :
--
keywords: +patch
pull_requests: +30047
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31958
___
Python tracker
<https://bugs.python.org/issu
Ronald Oussoren added the comment:
Terry: tkinter on macOS already effectively does not support Tk 8.5, or
basically anything bug the latest 8.6.x release. That's because older versions
have too many bugs that affect Python users, which mostly show up on our
tracker as bug reports
New submission from Ronald Oussoren :
Arm based Mac systems have several types of cores: performance cores and
efficiency cores. The system has no way to directly specify which core a
particular proces or thread uses, but programs can use an API for setting the
QOS class of a thread that
Ronald Oussoren added the comment:
> For example, using a priority policy that actually uses QOS attribute :)
How would that look?
The QOS class is already a high level interface that affects a number of
low-level polices. The classes are comprehensively documented in sys/qos.h.
In sh
Ronald Oussoren added the comment:
I agree. I'm working on a PR to expose this platform specific functionality in
the threading module. It would have been nice if other platforms had similar
functionality, but they don't.
Emulating the API is possible, but a project in its own
Ronald Oussoren added the comment:
A "problem" with CryptoKit is that it is a swift-only framework, which makes
using those APIs harder from C code (not impossible).
The older Security framework also contains crypto APIs, but seems to have less
support for modern algorithms (e.g.
Ronald Oussoren added the comment:
SecDigestTransformCreate() is probably a relevant API to look into, this seems
to be supported from 10.7 until now.
A major disadvantage for us of this API is that it is a CoreFoundation API and
because of that is problematic in pre-forking scenario&#
Ronald Oussoren added the comment:
The problem you should look into is why the _posixsubprocess doesn't build, the
message about msvcrt is a red herring due to the way subprocess.py is
structured.
Also compare the pyconfig.h files created for the two single architecture
builds, maybe
Ronald Oussoren added the comment:
> If we want to respect sizeof(max_align_t) alignment, we can compute
> sizeof(max_align_t) in configure and uses the result in obmalloc.c. I expect
> that it's either 16 or 32, so we can maybe just hardcode ALIGNMENT_SHIFT
> using so
Ronald Oussoren added the comment:
I had a similar problem during EuroPython, but that was when I had anaconda on
my machine. I've since removed it because generally don't use it but had it
installed for a training session.
I haven't tried to reproduce, but also don&#x
Ronald Oussoren added the comment:
A followup question: How can I determine the exact version of Tk?
--
___
Python tracker
<https://bugs.python.org/issue37
Ronald Oussoren added the comment:
I'd prefer a solution that uses symbols where the are available (weak linking).
That way users on newer systems can use all functionality available there,
without having multiple binaries.
I've done this in the past for older macOS versions,
Ronald Oussoren added the comment:
Interestingly enough both users in the py2app issue I mentioned use the
python.org installer to install Python.
One of them mentions this only happens when py2app is used, and that the script
works fine outside of an app.
I'll look into this to
Ronald Oussoren added the comment:
The py2app issue I mentioned is not relevant for this issue.
A simple tkinter runs fine with Python 3.7 (64-bit, 3.7.4, Python.org
installer), the same script causes a WindowServer crash (SEGV) when bundled
with py2app.
This is definitely a bug in macOS
Ronald Oussoren added the comment:
Does this application use Tkinter?
If so, this is a duplicate of #37833, and a bug in macOS triggered by (amongst
others) anaconda but (AFAIK) not by the Python.org installer.
The "logout" is a crash in the WindowServer proces, which is some
Ronald Oussoren added the comment:
I'd increase the default stack size for FreeBSD as well. AFAIK FreeBSD uses
clang as the default compiler like macOS, and it is therefore likely that the
two platforms have similar stack usage for similar code.
BTW. I can provide a PR for this but c
Ronald Oussoren added the comment:
@raymond, as to your question in msg350586: The release installers are
generally build on the oldest release of the OS targeted by the installer.
That's to ensure that the binaries actually work there.
It should be possible to build on newer releases
Ronald Oussoren added the comment:
What issues to you see?
What operating system and version are you on?
How did you install Python?
Note that Python 3.8 is still in beta and therefore a lot of 3th party
libraries do no yet have binary wheels available. You therefore likely need a
Ronald Oussoren added the comment:
Thanks for the update.
What's the error message you get when using pip to install?
--
___
Python tracker
<https://bugs.python.org/is
Ronald Oussoren added the comment:
Ana,
The error in "piperroroutput.txt" points to the issue Mark mentioned in
msg351131: the current release of Numpy is not compatible with Python 3.8, but
the tip of the tree on GitHub is.
I can install Numpy from the repository:
$ python
Ronald Oussoren added the comment:
New changeset ce81a925ef2d466b0d801deaba9af44a0dfc2aa1 by Ronald Oussoren (Jon
Janzen) in branch 'master':
bpo-36409: Remove old plistlib API deprecated in 3.4 (GH-15615)
https://github.com/python/cpython/commit/ce81a925ef2d466b0d801deaba9af4
Ronald Oussoren added the comment:
I think it is unlikely that the timeouts on Azure CI are related to this change.
--
___
Python tracker
<https://bugs.python.org/issue18
Ronald Oussoren added the comment:
New changeset 24b11b8c95e96cf9c93fb7fc253e6e96506f2d77 by Ronald Oussoren (Jon
Janzen) in branch 'master':
bpo-38053 Update documentation for plistlib (GH-15727)
https://github.com/python/cpython/commit/24b11b8c95e96cf9c93fb7fc253e6e
Change by Ronald Oussoren :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue38053>
___
___
Ronald Oussoren added the comment:
I don't think this is a bug.
def func():
print(var)
This captures the globals at the time of definition, that is "global"
references are resolved using the func.__globals__ attribute which is the
globals dictionary at the time the func
Ronald Oussoren added the comment:
Looking at the stack trace this is a similar issue as the "no_proxy" one, but
in some sense worse because it happens when just calling a regular unix API
(not an Apple framework API).
The first few lines of the stack trace are for code in th
Ronald Oussoren added the comment:
W.r.t. the deprecated APIs in getpath.c: Issue15498
That issue contains an ancient patch to switch to non-deprecated APIs, but we
haven't had time yet to fully test these. The issue also mentions that Apple's
install of Python already switched
Ronald Oussoren added the comment:
What's the value of PyGILState_Check() before the call to PyGILState_Ensure()?
PyGILState_Ensure() and PyGILState_Release() should bracket code where you're
not sure about the current GIL state, but need the GIL. The Release function
only
Ronald Oussoren added the comment:
I don't think this is a bug:
- PyGILState_Ensure() acquires the GIL when it is not already acquired (and can
be called without checking).
It cannot acquire the GIL when some other thread has already taken the GIL, but
wait until the GIL is rel
Ronald Oussoren added the comment:
I'm afraid it will be close to impossible to determine what's going on without
a reproducer.
There's not enough context in the issue to understand the report, in particular
what the main thread is doing and how that's releasing the GIL
Ronald Oussoren added the comment:
The attached code creates a static (global) C++ object that owns a reference to
a Python object, and releases that reference in its destructor. That destructor
runs at program termination, which is after interpreter shutdown (that is after
Py_FinalizeEx is
Ronald Oussoren added the comment:
If this is a Tk issue we should report it in their bug tracker.
I'm definitely against switching to an older version of Tk, the most recent
release fixes a lot of problems with Tk on macOS. Correctness before
performance.
How bad is the perfor
Ronald Oussoren added the comment:
One thing to look into: there appears to be a tk 8.6.11.1 release, I have no
idea what changed in this micro release.
--
___
Python tracker
<https://bugs.python.org/issue43
Ronald Oussoren added the comment:
As you note in the title this is a 32-bit overflow in the statvfs system API,
the struct it uses contains 32-bit values.
--
___
Python tracker
<https://bugs.python.org/issue43
Ronald Oussoren added the comment:
```pdb.run(...)``` is ends up in ```bdb.Bdb.run```, which uses compile and exec
to run the code.
And indeed:
>>> compile("1+2" * 100, "-", "exec")
zsh: segmentation fault python3.9
--
components:
Ronald Oussoren added the comment:
There is a block of NUL bytes at the end of the JSON data structure
The output of "od -c pico-hard.json" ends with:
0046340s e c t i o n N o t e s " : [ ]
0046360, " t y p e O f S e
New submission from Ronald Oussoren :
I'm currently converting some extensions of my own to vectorcall and an
annoying change between the old call protocol and vectorcall is that the latter
has no public equivalent to the PyArg_Parse family of functions.
There is "_PyArg_ParseStac
Change by Ronald Oussoren :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue44214>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Ronald Oussoren :
I've installed python 3.9.5 using the universal2 installer on my M1 MacBook.
Debugging this python using lldb doesn't work because the debugger cannot
attach to the (newly launched) binary. This appears to be due to a missing
entitlement in
Ronald Oussoren added the comment:
Annoyingly the keywords variant is the most interesting to expose :-) due to
the complexity of correctly interpreting keyword arguments.
I agree that we should be careful in exposing the APIs using _PyArg_Parser,
although it should be easer to expose it
501 - 600 of 2445 matches
Mail list logo
