Ronald Oussoren added the comment:
Are you on macOS 10.15 or later? If so, this is a duplicate of issue40477.
A workaround mentioned in that issue is to make sure that Terminal.app is open.
--
type: crash -> behavior
___
Python tracker
<
Ronald Oussoren added the comment:
FWIW, I'm experimenting with using Scripting Bridge instead of raw Apple Events
in Python Laucher. Mostly to check if that fixes the issue because I can run
scripts in Terminal using Scripting Bridge from a Python script using PyObjC.
Scripting B
Ronald Oussoren added the comment:
It looks like this is related to code signing and entitlements, in particular:
* On my system Terminal.app is in the "Automation" list in the Security &
Privacy control panel, and none of the installed Python Launchers are
* The script l
Ronald Oussoren added the comment:
Pfff Apple's documentation is too incomplete.
In recent versions the apple events entitlement only works when the program
also has an NSAppleEventsUsageDescription key in Info.plist with a string value
that describes why it needs the entitlement,
Ronald Oussoren added the comment:
The script seems to work fine for me, python 3.10.1 on macOS 12.1. I used the
python.org installer.
Did you install Python from source or using the installer? What's the output of
``python3 -m test.pythoninfo``, in particular the lines related to Tcl/
Ronald Oussoren added the comment:
I don't know why it doesn't work for you. The version of Tk looks recent enough.
As I mentioned before I don't see this problem using the script in your initial
message, it works fine both with and without changing the size of the window.
Ronald Oussoren added the comment:
I agree with Terry. This requires a clear proposal that describes the behaviour
and differences with ABC-s.
I'm closing this issue for now.
--
nosy: +ronaldoussoren
resolution: -> later
stage: -> resolved
status: ope
Ronald Oussoren added the comment:
Part of the problem here is that most keys in the result of
sysconfig.get_config_vars() are copied as-is from the CPython Makefile and
pyconfig.h header file.
The keys copied from the Makefile are in a lot of cases not useful for users of
python because
Ronald Oussoren added the comment:
The libraries you mention are 3th party projects. Please check with the
project first.
I've look at the GitHub repository for libmobiledevice and have no idea how
they determine the compiler flags for Python. As mentioned in an earlier
version &q
Ronald Oussoren added the comment:
> My understanding of the resolution of this ticket is that it is still not
> possible to use setrlimit with RLIMIT_STACK to raise the soft stack limit.
> Is that correct?
Yes, the code in msg324731 still fails. We're still using the mechan
Ronald Oussoren added the comment:
This is most likely a problem with PyQt6. Please ask that project first (with a
clearer description of what goes wrong and on which platforms).
--
nosy: +ronaldoussoren
resolution: -> third party
stage: -> resolved
status: open -&g
Ronald Oussoren added the comment:
The touch method combines the mode you specify with the active umask (set by
os.umask()). This is fairly standard behaviour for Unix APIs that accept a
file mode.
This is documented at:
https://docs.python.org/3/library/pathlib.html#pathlib.Path.touch
Change by Ronald Oussoren :
--
components: +macOS
nosy: +ronaldoussoren
___
Python tracker
<https://bugs.python.org/issue46548>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
Python's is behaving as expected here (but see below): the slots definition
tells the interpreter which attribute names can be set on an instance and
"__slots__" is not one of those attributes in your code. "a.__slots__ += ..."
Ronald Oussoren added the comment:
Error output when running the script:
2022-02-01 22:15:32.213 Python[5468:5726153] ApplePersistenceIgnoreState:
Existing state will not be touched. New state will be written to
/var/folders/d3/rc5nx4v12y96knh2px3bpqscgn/T/org.python.python.savedState
Ronald Oussoren added the comment:
The last bit of the call stack according to lldb:
* thread #2, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00018b3419b8 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00018b374eb0 libsystem_pth
Ronald Oussoren added the comment:
If I interpret the information I posted earlier correctly this is a bug in
Tkinter, it calls a non-existing Objecive-C method (``-[NSApplication
macOSVersion]``) and that results in an uncaught Objective-C exception and
hence an abort().
BTW. All of this
Ronald Oussoren added the comment:
Oops, sorry: In Tk itself.
--
___
Python tracker
<https://bugs.python.org/issue46573>
___
___
Python-bugs-list mailin
Ronald Oussoren added the comment:
I've done some more research and this is an integration issue between pyglet
and Tk. In particular:
* Both pyglet and Tk use AppKit to implement their GUI
* AppKit uses an NSApplication class, and in particular a singleton instance of
that clas
Ronald Oussoren added the comment:
W.r.t. augmented assignments, this is a good blog post about how they work
under the hood: https://snarky.ca/unravelling-augmented-arithmetic-assignment/
--
___
Python tracker
<https://bugs.python.org/issue46
Ronald Oussoren added the comment:
There's a use case for using a dict for __slots__, pydoc will use a dict value
for the slots as a mapping from attribute name to attribute documentation.
Because of that it is not really worthwhile to transform the value of __slots__
during
Ronald Oussoren added the comment:
Categories make it possible to add methods to an existing class, but not new
attributes. The latter shouldn't be a problem in principle for an
NSApplication subclass because only a single instance of the application class
will get created and you m
Ronald Oussoren added the comment:
Something I forgot to mention: I don't think this is a bug in Tk now that I've
looked into this more deeply.
The integration problem between Tk and other users of the Cocoa event loop is
unfortunate but
Ronald Oussoren added the comment:
The default start method for multirprocessing was changed from "fork" to
"spawn" on macOS. This was done because the "fork" method can easily be
triggered into causing hard crashes (on macOS), in particular when the parent
Ronald Oussoren added the comment:
This is not a bug in CPython, at best this can be a feature request to make it
possible to pickle lambda's (which IMHO is unlikely to happen).
The "fork" and "spawn" start methods result in different behaviour in how data
is c
New submission from Ronald Oussoren :
In python3.10 and earlier "python3 -m venv something" creates
"something/bin/python" as a symlink to the interpreter itself.
In python3.11 (a5) the same command no longer creates "something/bin/python",
but only the &quo
Ronald Oussoren added the comment:
This is be related to how the virtual environment is populated. In 3.10 the
"python3.10" name in the environment is a symlink to sys.executable. In 3.10
"Python" (not the capital) is a symlink to the binary in Python.app and
"py
Ronald Oussoren added the comment:
The root cause likely is the calculation of sys._base_executable. In 3.10 this
is {sys.prefix}/bin/python3.10, while in 3.11 this is
{sys.prefix}/Resources/Python.app/Contents/MacOS/Python.
The venv library uses the incorrect value and therefore creates an
Ronald Oussoren added the comment:
The change to _base_executable is the real problem. Venv creates the correct
directory structure if I add a sitecustomize.py to the python path that sets
_base_executable to the correct value.
# sitecustomize
import sys
sys._base_executable
New submission from Ronald Oussoren :
The following crashes the interpreter in Python 3.11, and works fine in older
versions:
# --- script.py
import types
class MyModule (types.ModuleType):
__slots__ = (
"_MyModule__a",
"_MyModule__b",
)
def
Ronald Oussoren added the comment:
This is with python 3.11 alpha 5 using the installer for macOS.
--
___
Python tracker
<https://bugs.python.org/issue46
Ronald Oussoren added the comment:
The crash itself happens during garbage collection:
% python3.11 -Xdev t.py
(master)pyobjc-8
Fatal Python error: Segmentation
Ronald Oussoren added the comment:
The debug build seems to indicate that slot memory is not initiated properly, a
stack trace (note the argument to visit_validate at frame #7):
* frame #0: 0x00019b60d9b8 libsystem_kernel.dylib`__pthread_kill + 8
frame #1: 0x00019b640eb0
Ronald Oussoren added the comment:
Again without diving deep I've constructed a test case that is probably
relevant. I've pasted the diff below because I'm not yet convinced that it is
correct (in particular the value for "argv0". This would also require a se
Ronald Oussoren added the comment:
> This is marked as a release blocker so I am holding the alpha release on
> this. Is there anything we can do to unblock this issue?
I marked the issue as a release blocker because it must not end up in a beta
release, its probably not worth it to h
Ronald Oussoren added the comment:
@Pablo: this is a possible release blocker, hard crash for code that works in
earlier releases.
That said, I have a workaround on my end and IMHO a fix could wait for the next
alpha.
--
nosy: +pablogsal
Ronald Oussoren added the comment:
I don't feel qualified to review the PR, but can confirm that this PR fixes
this issue as well as the crash in PyObjC that I extracted my reproducer from.
--
___
Python tracker
<https://bugs.py
New submission from Ronald Oussoren :
The script below fails with an assertion error with python 3.11a5+ (current
trunk) when build with --with-pydebug:
# BEGIN OF FILE
class String(str):
__slots__ = ()
name = String("hello")
class Bag:
pass
o = Bag()
setattr(o, name, 42)
Ronald Oussoren added the comment:
A hard crash seems wrong to me, and I'm not convinced yet that checking that
the type of the attribute name is exactly string is correct.
Found while debugging a crash in PyObjC's testsuite, PyObjC uses a subclass of
str to represent Objective
Ronald Oussoren added the comment:
This is probably not a bug in python, but a change in system behaviour.
In particular, I've used the lsof command to check the open files for the
syslogd proces on a macOS 10.13 and 12.2 system. On the former syslogd has
/var/run/syslog open, on the l
New submission from Ronald Oussoren :
In a static type when the "tp_name" is set to a fully qualified name (such as
"my.package.TypeName") the "__qualname__" returns the unqualified name
("TypeName") instead of the fully qualified name.
The type&#x
Ronald Oussoren added the comment:
You're right. I was sure that __qualname__ included the module name, but PEP
3155 is clear about actual semantics.
Sorry about the noise.
--
resolution: -> not a bug
stage: test needed -> resolved
status: ope
Ronald Oussoren added the comment:
Your PR fixed the issue for me.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Ronald Oussoren added the comment:
I have a patch that seems to do the right thing. It required adding
WITH_NEXT_FRAMEWORK to the globals when evaluating getpath.py to detect this
scenario.
There probably should be more tests, in particular a test for a virtual
environment using a
Ronald Oussoren added the comment:
This is also dodgy:
test_framework_macos (test.test_getpath.MockGetPathTests) ... Read link from
/Library/Frameworks/Python.framework/Versions/9.8/Resources/Python.app/Contents/MacOS/Python
Check if
/Library/Frameworks/Python.framework/Versions/9.8
Ronald Oussoren added the comment:
I'm now in the fun position where the code works, but the test test_getpath.py
fails.
The test case below tries to test a venv in a framework build, but somehow
fails to calculate prefix and exec_prefix correctly. The calculation does work
when us
Ronald Oussoren added the comment:
I've attached a new patch file with some more tweaks, including the additional
test case from msg414665.
I've pretty sure that the changes to getpath.py are slightly worse in the new
version, but aren't fully correct in the initial version
Ronald Oussoren added the comment:
Why does you patch test for -mno-fused-madd? If it isn't actually needed
for something I'd rather not have that logic in the configure file,
determining which bits of that file are actually needed for supported
OS-es is hard enough as it is.
Ronald Oussoren added the comment:
jyasskin: could you test apple_gcc_flags.diff? That's a version of your
patch where configure tests if GCC supports -Wno-long-double and -no-
cpp-precomp.
NOTE: the patch doesn't update configure, you'll have to run autoconf
after applying
Changes by Ronald Oussoren:
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1779871>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python
Changes by Ronald Oussoren:
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1779871>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python
New submission from Ronald Oussoren:
Py_Finalize cleans up the thread state by first calling _PyGILState_Fini
and then calling PyInterpreterState_Clear. The latter can cause user
code to run, which could use the GILState API and this then causes a
crash.
The attached file 'threads.py&#x
Ronald Oussoren added the comment:
I don't have a patch. I don't even know enough of the threading
infrastructure to know if this really a bug or if it is a bug in my
code.
I'll work on a patch this weekend, if changing the order of calls to
PyGILState_Fini and PyInterpr
Ronald Oussoren added the comment:
The attached patch fixes the crash, but I haven't verified if the patch
is actually correct.
With this patch some PyThread API's are called after PyInterpreterState_Clear
and I don't know if it is valid to do so. All
unittests pass fin
Ronald Oussoren added the comment:
This is not a mac-specific issue, the script happens to be mac-specific
because that's how I found the issue.
Amaury's patch adds a unittest that reproduces the problem in a
platform-indepenent way using ctypes.
The _PyGILState_Fini function m
New submission from Ronald Oussoren :
Could you please add some more information on how I can reproduce this issue?
--
stage: -> test needed
type: -> behavior
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
On 11 Oct, 2011, at 22:28, Ned Deily wrote:
>
> Ned Deily added the comment:
>
> I forgot to mention that one advantage of using another framework and root
> location, say, under your home directory somewhere, is that it is unnecessary
Ronald Oussoren added the comment:
There's little chance that Apple will fix this issue in their build (at least
not until Lion+1 gets released) because this is not a security bug. Their
breaking of 2.7 in Lion is probably due to lack of review for their collection
of patches, and i
New submission from Ronald Oussoren :
test_ctypes fails when building and testing on OSX 10.7 (Lion).
This is likely caused by changes in the compiler w.r.t. the calling convention.
I've worked around this problem in PyObjC, and will try to port that
workaround to ctypes.
BTW. Using -
Ronald Oussoren added the comment:
I should have included the failures in my first message, sorry about that.
IIRC the workaround in PyObjC I mention in my initial message does explicit
sign extension when needed.
W.r.t to the first couple of failures, not that:
struct.unpack(&#
New submission from Ronald Oussoren :
A number of Carbon wrapper modules don't build on OSX 10.7:
$ make
...
Failed to build these modules:
_Fm_Qd_Qdoffs
This is with '--with-universal-archs=intel', which worked fine on OSX 10.6.
A sh
Ronald Oussoren added the comment:
_Fm fails because the wrapped functionality is no longer present in the Headers
(last seen in the QD.framework headers in the 10.6 SDK)
likewise for _Qdoffs and _Qd.
The attached patch changed the preprocessor guards around these bindings from
#ifndef
Ronald Oussoren added the comment:
The bug in the 'gcc' command is still present when using Xcode 4.2.1 (that is,
the attached unicode.c miscompiles with "gcc -O3").
Clang (again from Xcode 4.2.1) compiles the file correctly, but fails to do a
proper build the last few li
Ronald Oussoren added the comment:
He's probably referring to this fragment in setup.py:
if platform == 'darwin':
# This should work on any unixy platform ;-)
# If the user has bothered specifying additional -I and -L flags
# in OPT
Ronald Oussoren added the comment:
The version of clang included in Xcode 4.2.1 (the current release) still
miscompiles Python 3.3 and both C files included in this issue.
The same is true for the Xcode 4.3 beta.
Python 2.7 seems to work fine with the same compiler, either because we don&#
Ronald Oussoren added the comment:
I've filed an issue in Apple's tracker, #10667893. Filing more issues would be
helpful, if more issues in their tracker mention this bug it is more likely to
get fixed.
--
___
Python trac
Ronald Oussoren added the comment:
I've found a bug in the curses module that is causing problems:
diff --git a/Modules/_cursesmodule.c b/Modules/_cursesmodule.c
--- a/Modules/_cursesmodule.c
+++ b/Modules/_cursesmodule.c
@@ -2056,7 +2056,8 @@
{"encoding"
Ronald Oussoren added the comment:
Both clang and llvm-gcc had problems, the llvm-gcc problem is still there and
is caused by a compiler bug. There is nothing we can do about that beyond
warning Apple.
It's also pretty clear that llvm-gcc (and gcc in general) is on the way out as
the s
Ronald Oussoren added the comment:
I don't agree that distutils should autodetect architectures, that can result
in silent behavior changes when you built extensions and assume ppc support
will get compiled in.
We should probably start to mention the intel only builds more promin
Ronald Oussoren added the comment:
What 10.7? ;-) Please remember 10.7 is under NDA, and as such shouldn't be
discussed in public.
As I mentioned earlier: the 32-bit build should be deprecated and is only
needed for older machines, anyone running modern machines can install OSX 10.6
Ronald Oussoren added the comment:
Steffen: _mac_ver_xml should not be dropped, it is a perfectly fine way to
determine the system version. Discussing it is also off-topic for this issue,
please keep the discussion focussed.
Wrt. mailing Apple: I wouldn't expect and answer. Is
Ronald Oussoren added the comment:
steffen: I have no idea what you are trying to say in your last message. Could
you please try to stay on topic.
--
___
Python tracker
<http://bugs.python.org/issue11
Ronald Oussoren added the comment:
I haven't tested yet, but feel free to commit and I'll fix any OSX issues later.
--
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
I agree with Ned, the changes to the environment should only be done in
subprocesses started by distutils.
The patch looks fine, but I haven't tested the patches yet.
--
___
Python tracker
Ronald Oussoren added the comment:
python2.7 has MacOS.WMAvailable(). When that function returns False the
Tkinter tests should be disabled.
The function is not available in Python 3, but is easy enough to implement
using ctypes.
--
___
Python
Ronald Oussoren added the comment:
Waiting for a new version of boost probably won't help: this is an
incompatibility between a redefinition of ctypes macros in pyport.h and
definitions in the C++ header .
I barely use C++ at this time and don't know how to tweak the headers to a
Ronald Oussoren added the comment:
This is almost certainly a bug in Tk. What OSX version are you using, and
which python installer did you use?
One thing you could try is installing a matching copy of ActiveState's Tk (8.4
for the 32-bit build, 8.5 for intel-only builds of python 2.
Ronald Oussoren added the comment:
Have you checked if -fwrapv is in the list of compiler arguments in the
generated makefile?
There is an open issue about adding that flag when clang is used as the
compiler (the flag is already used for gcc). The flag is necessary because the
example code
Ronald Oussoren added the comment:
Clang has an option "-fcatch-undefined-behavior" that might help in locating
other locations where we use undefined behavior.
--
___
Python tracker
<http://bugs.python.o
Ronald Oussoren added the comment:
Barry: I agree with Ned that this is low-risk patch.
The patch changes a default return value in a code-path that is used on OSX
10.3 to make it the same as the default value on the code-path for other OSX
releases.
I'm therefore +1 on applying thi
Ronald Oussoren added the comment:
Assigning to myself because I intend to work on this.
More questions: does the error occur on the 10.6 machine you used to do the
build or another machine?
Is MACOSX_DEPLOYMENT_TARGET set in the environment when you run the command
that gives the error
Ronald Oussoren added the comment:
I won't have time to look at this until sunday.
Alexander Belopolsky wrote these patch tests. Alexanders: do you have time to
look into this?
--
nosy: +belopolsky
___
Python tracker
<http://bugs.py
Ronald Oussoren added the comment:
Could this be related to Issue5154?
I've noticed in the past that some asyncore/asychat tests print stacktraces as
well, all of them in the testcases that use poll instead of select.
--
___
Python tracker
Ronald Oussoren added the comment:
I think there is a missing '0' in the failing line:
Index: Lib/test/test_socket.py
===
--- Lib/test/test_socket.py (revision 84079)
+++ Lib/test/test_socket.py (working copy)
Ronald Oussoren added the comment:
There is one thing I don't understand about these tests: they basicly only seem
to test if the function implements the right interface (argument counts and the
structure of the return value).
Shouldn't the tests also test if the behaviour is som
Ronald Oussoren added the comment:
issue9047 is related to the issue Stefan mentions
--
___
Python tracker
<http://bugs.python.org/issue9189>
___
___
Python-bug
Ronald Oussoren added the comment:
I agree with Antoine that this would be useful functionality and that matching
"the" shell is futile here.
A quick check on an old linux server: bash and ksh do brace expansion before
expanding '*', but that csh does both at the same
Ronald Oussoren added the comment:
I can reproduce this with a script that builds and installs a couple of python
versions, annoyingly enough I don't understand why that code fails.
In particular, in my script the run of python that fails is started with this
code:
lg.debug("
Ronald Oussoren added the comment:
This (untested) patch should fix the issue:
Index: Lib/sysconfig.py
===
--- Lib/sysconfig.py(revision 84147)
+++ Lib/sysconfig.py(working copy)
@@ -295,9 +295,8
Ronald Oussoren added the comment:
I now understand why my script fails, and it is caused by this issue.
The sysconfig.py code has another major issue: the use of os.putenv. This
changes the environment, without changing os.environ. The use of os.putenv
should be replaced by setting keys in
Ronald Oussoren added the comment:
I don't understand why distutils won't even get documentation updates.
Bob's report is about undocumented functionality that is used in real life and
was the best way to install python distributions in a self-contained way before
setuptoo
Ronald Oussoren added the comment:
This is the same issue as #6763.
The root cause of this issue is that the default stack size for threads other
than the main thread is small.
One way to fix this issue is to increase the default stacksize for new threads
Ronald Oussoren added the comment:
$ python2.7 test/test_asyncore.py -v
test_closeall (__main__.HelperFunctionTests) ... ok
test_closeall_default (__main__.HelperFunctionTests) ... ok
test_compact_traceback (__main__.HelperFunctionTests) ... ok
test_readwrite (__main__.HelperFunctionTests
Ronald Oussoren added the comment:
This is still a problem.
Technically this only works accidently with a framework build, code that
expects that '_environ' is defined in a shared library on OSX is broken.
--
___
Python trac
Ronald Oussoren added the comment:
In python 2.x 'MacOS.WMAvailable()' returns True if the windowserver is
available.
The whole MacOS extension is gone in 3.x, although it should be easy enough to
reimplement WMAvailable() us
New submission from Ronald Oussoren :
The attached file 'manifest-test.zip' is a small distutils project that
demonstrates a problem I have with the sdist command.
The archive contains a directory 'sandbox' that is not mentioned in MANIFEST.in
or anywhere in setup.py. Wh
Ronald Oussoren added the comment:
Fixing the alloc_closure error is easy enough:
Index: ../setup.py
===
--- ../setup.py (revision 84528)
+++ ../setup.py (working copy)
@@ -1653,7 +1653,9 @@
'_c
Ronald Oussoren added the comment:
I'm looking into this issue.
One problem is that the version of libffi used on OSX is no longer in sync with
the version that is used on other platforms. The version that is used on OSX
does not have some of the symbols expected by ctypes, su
Ronald Oussoren added the comment:
Łukasz' patch fixes the issue for me.
As the patch only affects code-paths used on OSX (patches to the libffi version
for OSX and an #ifdef that makes OSX use ffi_prep_closure instead of
ffi_prep_closure_loc) I intend to commit the patch later today
Ronald Oussoren added the comment:
Thanks! That patch fixes the issue for me and I will commit it later today.
--
___
Python tracker
<http://bugs.python.org/issue9
1 - 100 of 2445 matches
Mail list logo
