Ronald Oussoren added the comment:
Do the tests work properly from an installed python framework?
That doesn't immediately help with the normal way of running tests, but might
point to a way forward. The major difference with normal installs is that the
python interpreter is started in a
Mark Roseman added the comment:
Just to note, this remains a PITA. To run gui tests on macOS from a terminal
window seems to require commenting out the SetFrontProcess() call. A better
replacement is needed as noted in the previous discussion, as well this call
was deprecated in OS X 10.9
Jessica McKellar added the comment:
Some IRC discussion about what contributors should do while this is unresolved,
and the bigger plan for comprehensively addressing this:
01:53 ned_deily jesstess, saw your nosy on Issue17496. Beware that it's
really a can of worms and definitely was
Changes by Jessica McKellar jessica.mckel...@gmail.com:
--
nosy: +jesstess
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17496
___
___
Ned Deily added the comment:
(See also Issue18604 which has refactored this area.)
--
keywords: -easy
versions: +Python 3.5 -Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17496
Ronald Oussoren added the comment:
To respond to my own message: running a small Tcl script is not good enough,
the process environment of python itself is also important.
In particular, GUI frameworks only work from inside an application bundle (or
by using some undocumented private APIs)
Ronald Oussoren added the comment:
The attached patch start wish and stops it by sending the 'exit' command. With
the patch I can run the tk tests without getting a skip. I cannot easily test
if the patch also does the right thing on buildbots, but have high hopes. I
did check that just
Ned Deily added the comment:
Um, yes, my tired eyes did skip over those added lines. Thanks, Glyph, and
sorry, Alex.
While the suggested change solves the issue for the non-framework build case,
it appears to introduce new problems. For one, with the current skip test, it
is possible to run
Ned Deily added the comment:
Granted, the current test is a kludge. We could make it a bigger kludge by
trying launchctl first and if it fails move on to the current ctypes-based
tests. Any better options?
--
___
Python tracker
Ronald Oussoren added the comment:
A small helper program that does the equavalent of this should also work:
import Cocoa
Cocoa.NSWindow.alloc().initWithContentRect_styleMask_backing_defer_(((10, 10),
(100, 100)), 0, 0, 0)
If this code raises an exception you cannot create windows, if it
Ronald Oussoren added the comment:
Wouldn't it be better to check for the actual problem, that is use subprocess
to start a small Tcl script that creates a window and check if that crashes?
That way the code for disabling the test doesn't have to try to guess whether
or not Tk will crash in
Glyph Lefkowitz added the comment:
Wouldn't it be better to check for the actual problem, that is use subprocess
to start a small Tcl script that creates a window and check if that crashes?
Yes, this sounds great. Doing it with Tcl means that we're not invoking any of
the problematic code
New submission from Alex Gaynor:
If I run:
$ python -mtest.test_tk
I get a skip, after speaking with people familiar with OS X, it appears that
the condition for the skip uses old Carbon APIs, which are totally deprecated
under 64-bit. Attached is a patch which should work.
--
Ned Deily added the comment:
The test for the condition was added to solve the problem reported in
Issue8716. The Tk crash for test_ttk_guionly reported there still occurs on a
current 10.8 system with the Apple-supplied Cocoa Tk under the same conditions,
that is, when running the tests
Glyph Lefkowitz added the comment:
Hi Ned,
It seems from your comment that you didn't read the patch. Alex added a
simpler check via launchctl, rather than by framework symbol groveling :). He
didn't remove the check.
It should be functionally identical to what's there now, but much
15 matches
Mail list logo
