Anyone has run wxPython from an embedding python interpreter under Mac OSX?

Hi, I need to run wxPython python script code inside the GDB’s embedding python interpreter. (actually the python script is a python’s pretty printer to visualize some data through wxPython and Matpoltlib)

But I see the error message:

This program needs access to the screen. Please run with a Framework build of python, and only when you are logged in on the main display of your Mac.

After that, GDB just quit.

I know that there is a good article which mention some similar issue:
wxPythonVirtualenvOnMac - wxPyWiki - wxPythonVirtualenvOnMac - wxPyWiki

Yes, with the above link, I can correctly run wxPython script under the virtual environment. But if you look deeper to the methods, I see that it just wrap the an application bundled version of python. But actually, I don’t have a application bundle version of GDB.

To demonstrate this issue, I can even create a very simple command line application which mentioned in the python’s official document:
5. Embedding Python in Another Application — Python 2.7.10 documentation - 5. Embedding Python in Another Application — Python 2.7.18 documentation
But the result command line application can only run non-GUI python script. Any GUI python script will cause the similar error message as shown above.

So, maybe, one method is that I would like to the GDB(GDB is a command line application) to an application bundle?

BTW: I have asked questions in stackoverflow, but I don’t see any answers.

1, mac osx does not allow me to run any GUI python scripts in an embedding python interpreter - http://stackoverflow.com/questions/33293428/mac-osx-does-not-allow-me-to-run-any-gui-python-scripts-in-an-embedding-python-i

2, Is it possible to conver a command line application to an application bundle under OSX - python - Is it possible to convert a command line application to an application bundle under OSX - Stack Overflow

I hope I can get some help here in this forum, thanks.

Asmwarrior

You are fighting a battle against your tools here, and the tools are
going to win. They don’t know how to compromise.
I think you’re going to need to think about your problem in a
different way. What’s the point of this? GDB is not a tool that
one uses in production – it is a development/debugging tool. It
hardly seems worth the trouble to invent an entire hacked up
framework just to make a few commands work during debugging. If you
need to verify some data visually, it would be much less work just
to use GDB to export the raw numeric data to a text file, and feed
that text file to a Matplotlib application running separately.

···

asm warrior wrote:

    Hi, I need to run wxPython python script code inside the GDB's

embedding python interpreter. (actually the python script is a
python’s pretty printer to visualize some data through wxPython
and Matpoltlib)

    But I see the error message:
      This program needs access to the screen.

Please run with a Framework build of python, and only when you
are logged in on the main display of your Mac.

      After that, GDB just quit.
-- Tim Roberts, Providenza & Boekelheide, Inc.

timr@probo.com

HI, Tim, thanks for the reply.

Yes, I can use the suggest way you mentioned, but it may lose some convenience. Export the data, then visualize the data in another process need two steps. In-fact, the python pretty printer created myself combines the two steps in a single python script, and the script is used to visualize in memory images. See the link here about my pretty printer: https://sourceforge.net/projects/visualdebugger/. The good thing is, I can use this pretty printer in either Windows or Linux system without any problems. That’s just run wxPython and Matplotlib inside GDB’s embedding python interpreter.

Back to my issue, firstly, I thought it could be easy to deploy the same script under Mac OSX, but I was wrong, since OSX has some limits to access the GUI code from command line applications.

While handling this issue for days, I notice that the native Python executable supplied by OSX have the ability to access the screen. I found this by running the method mentioned in wxPythonVirtualenvOnMac - wxPyWiki, through the vmmap $pid command, the pid is the running python process. I can also run wxPython scripts directly under the global python interrupter without any virtual environment. The actual python executable file locates inside the some folder named: Python.app/Contents/MacOS/python. It looks like this executable also contains an rocket kind icon.

So, that’s came the idea, if I can create a similar thing like GDB.app, and I can run the actual GDB executable from the application bundle, I may solve the issue. GDB is built myself under OSX, but it looks like GDB is a command line application, all I need is a “application bundle” similar like the system supplied python.

Thanks.
Asmwarrior

···

On Saturday, October 24, 2015 at 1:38:39 AM UTC+8, Tim Roberts wrote:

asm warrior wrote:

    Hi, I need to run wxPython python script code inside the GDB's

embedding python interpreter. (actually the python script is a
python’s pretty printer to visualize some data through wxPython
and Matpoltlib)

    But I see the error message:
      This program needs access to the screen.

Please run with a Framework build of python, and only when you
are logged in on the main display of your Mac.

      After that, GDB just quit.
You are fighting a battle against your tools here, and the tools are

going to win. They don’t know how to compromise.

I think you're going to need to think about your problem in a

different way. What’s the point of this? GDB is not a tool that
one uses in production – it is a development/debugging tool. It
hardly seems worth the trouble to invent an entire hacked up
framework just to make a few commands work during debugging. If you
need to verify some data visually, it would be much less work just
to use GDB to export the raw numeric data to a text file, and feed
that text file to a Matplotlib application running separately.

-- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

I dig into the wxPython’s source code, and I see that the error message comes from here:
wxPython-src-3.0.2.0/wxPython/src/osx_cocoa/_core.py

class App(wx.PyApp):
“”"
The wx.App class represents the application and is used to:

  * bootstrap the wxPython system and initialize the underlying
    gui toolkit
  * set and get application-wide properties
  * implement the windowing system main message or event loop,
    and to dispatch events to window instances
  * etc.

Every application must have a ``wx.App`` instance, and all
creation of UI objects should be delayed until after the
``wx.App`` object has been created in order to ensure that the gui
platform and wxWidgets have been fully initialized.

Normally you would derive from this class and implement an
``OnInit`` method that creates a frame and then calls
``self.SetTopWindow(frame)``.
"""

outputWindowClass = PyOnDemandOutputWindow

def __init__(self,
             redirect=False,
             filename=None,
             useBestVisual=False,
             clearSigInt=True):
    """
    Construct a ``wx.App`` object.  

    :param redirect: Should ``sys.stdout`` and ``sys.stderr`` be
        redirected?  Defaults to False. If ``filename`` is None
        then output will be redirected to a window that pops up
        as needed.  (You can control what kind of window is created
        for the output by resetting the class variable
        ``outputWindowClass`` to a class of your choosing.)

    :param filename: The name of a file to redirect output to, if
        redirect is True.

    :param useBestVisual: Should the app try to use the best
        available visual provided by the system (only relevant on
        systems that have more than one visual.)  This parameter
        must be used instead of calling `SetUseBestVisual` later
        on because it must be set before the underlying GUI
        toolkit is initialized.

    :param clearSigInt: Should SIGINT be cleared?  This allows the
        app to terminate upon a Ctrl-C in the console like other
        GUI apps will.

    :note: You should override OnInit to do applicaition
        initialization to ensure that the system, toolkit and
        wxWidgets are fully initialized.
    """
   
    wx.PyApp.__init__(self)

    # make sure we can create a GUI
    if not self.IsDisplayAvailable():
       
        if wx.Platform == "__WXMAC__":
            msg = """This program needs access to the screen.

Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac."""

``

While, the actual test code was inside the file:
wxPython-src-3.0.2.0/wxPython/src/helpers.cpp

//----------------------------------------------------------------------
// Function to test if the Display (or whatever is the platform equivallent)
// can be connected to. This is accessable from wxPython as a staticmethod of
// wx.App called DisplayAvailable().

bool wxPyTestDisplayAvailable()
{
#ifdef WXGTK
Display* display;
display = XOpenDisplay(NULL);
if (display == NULL)
return false;
XCloseDisplay(display);
return true;
#endif

#ifdef WXMAC
// This is adapted from Python’s Mac/Modules/MacOS.c in the
// MacOS_WMAvailable function.
bool rv;
ProcessSerialNumber psn;

/*
** This is a fairly innocuous call to make if we don't have a window
** manager, or if we have no permission to talk to it. It will print
** a message on stderr, but at least it won't abort the process.
** It appears the function caches the result itself, and it's cheap, so
** no need for us to cache.
*/

#ifdef kCGNullDirectDisplay
/* On 10.1 CGMainDisplayID() isn’t available, and
** kCGNullDirectDisplay isn’t defined.
*/
if (CGMainDisplayID() == 0) {
rv = false;
} else
#endif
{
// Also foreground the application on the first call as a side-effect.
if (GetCurrentProcess(&psn) < 0 || SetFrontProcess(&psn) < 0) {
rv = false;
} else {
rv = true;
}
}
return rv;
#endif

#ifdef WXMSW
// TODO…
return true;
#endif
}

``

So, normally, we use the function named CGMainDisplayID, The document is here:Quartz Display Services Reference - [https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/#//apple_ref/c/func/CGMainDisplayID](https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/#//apple_ref/c/func/CGMainDisplayID)
I’m not sure, if GDB becomes an application bundle, it can return an valid CGDirectDisplayID ?`

`Thanks

Asmwarrior

The Python.org build of Python for OS-X has an ugly hack to allow it to run GUI apps. You could maybe replicate it with gdb’s embeddd Python.

See the source code and the python Mac list archives for some discussion.

Another option is to take a look at the different kludge that Anaconda’s Python does for OS-X – I think it’s almost as simple as putting the executable in an app bundle.

https://www.continuum.io/downloads

Try installing it and see what pythonw is actually linked to.

CHB

···

On Oct 23, 2015, at 4:53 PM, asm warrior asmwarrior@gmail.com wrote:

I dig into the wxPython’s source code, and I see that the error message comes from here:
wxPython-src-3.0.2.0/wxPython/src/osx_cocoa/_core.py

class App(wx.PyApp):
“”"
The wx.App class represents the application and is used to:

  * bootstrap the wxPython system and initialize the underlying
    gui toolkit
  * set and get application-wide properties
  * implement the windowing system main message or event loop,
    and to dispatch events to window instances
  * etc.

Every application must have a ``wx.App`` instance, and all
creation of UI objects should be delayed until after the
``wx.App`` object has been created in order to ensure that the gui
platform and wxWidgets have been fully initialized.

Normally you would derive from this class and implement an
``OnInit`` method that creates a frame and then calls
``self.SetTopWindow(frame)``.
"""

outputWindowClass = PyOnDemandOutputWindow

def __init__(self,
             redirect=False,
             filename=None,
             useBestVisual=False,
             clearSigInt=True):
    """
    Construct a ``wx.App`` object.  

    :param redirect: Should ``sys.stdout`` and ``sys.stderr`` be
        redirected?  Defaults to False. If ``filename`` is None
        then output will be redirected to a window that pops up
        as needed.  (You can control what kind of window is created
        for the output by resetting the class variable
        ``outputWindowClass`` to a class of your choosing.)

    :param filename: The name of a file to redirect output to, if
        redirect is True.

    :param useBestVisual: Should the app try to use the best
        available visual provided by the system (only relevant on
        systems that have more than one visual.)  This parameter
        must be used instead of calling `SetUseBestVisual` later
        on because it must be set before the underlying GUI
        toolkit is initialized.

    :param clearSigInt: Should SIGINT be cleared?  This allows the
        app to terminate upon a Ctrl-C in the console like other
        GUI apps will.

    :note: You should override OnInit to do applicaition
        initialization to ensure that the system, toolkit and
        wxWidgets are fully initialized.
    """
   
    wx.PyApp.__init__(self)

    # make sure we can create a GUI
    if not self.IsDisplayAvailable():
       
        if wx.Platform == "__WXMAC__":
            msg = """This program needs access to the screen.

Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.“”"

``

While, the actual test code was inside the file:
wxPython-src-3.0.2.0/wxPython/src/helpers.cpp

//----------------------------------------------------------------------
// Function to test if the Display (or whatever is the platform equivallent)
// can be connected to. This is accessable from wxPython as a staticmethod of
// wx.App called DisplayAvailable().

bool wxPyTestDisplayAvailable()
{
#ifdef WXGTK
Display* display;
display = XOpenDisplay(NULL);
if (display == NULL)
return false;
XCloseDisplay(display);
return true;
#endif

#ifdef WXMAC
// This is adapted from Python’s Mac/Modules/MacOS.c in the
// MacOS_WMAvailable function.
bool rv;
ProcessSerialNumber psn;

/*
** This is a fairly innocuous call to make if we don't have a window
** manager, or if we have no permission to talk to it. It will print
** a message on stderr, but at least it won't abort the process.
** It appears the function caches the result itself, and it's cheap, so
** no need for us to cache.
*/

#ifdef kCGNullDirectDisplay
/* On 10.1 CGMainDisplayID() isn’t available, and
** kCGNullDirectDisplay isn’t defined.
*/
if (CGMainDisplayID() == 0) {
rv = false;
} else
#endif
{
// Also foreground the application on the first call as a side-effect.
if (GetCurrentProcess(&psn) < 0 || SetFrontProcess(&psn) < 0) {
rv = false;
} else {
rv = true;
}
}
return rv;
#endif

#ifdef WXMSW
// TODO…
return true;
#endif
}

``

So, normally, we use the function named CGMainDisplayID, The document is here:Quartz Display Services Reference - [https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/#//apple_ref/c/func/CGMainDisplayID](https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/Quartz_Services_Ref/#//apple_ref/c/func/CGMainDisplayID)
I’m not sure, if GDB becomes an application bundle, it can return an valid CGDirectDisplayID ?`

`Thanks

Asmwarrior

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

The Python.org build of Python for OS-X has an ugly hack to allow it to run GUI apps. You could maybe replicate it with gdb’s embeddd Python.

See the source code and the python Mac list archives for some discussion.

Hi, CHB, thanks for the reply.
I did subscribe to the pythonmac-sig maillist, and I have posted an email to that maillist several days ago, but sadly, I see my post is not appeared in that maillist, maybe, the email is not approved by the administer of that maillist. Maybe, I need to try send an email again. Search on that maillist achieve doesn’t give me much useful results. (blindly reviewing all the python.org’s source code to find how they workaround this issue may take too much time)

Another option is to take a look at the different kludge that Anaconda’s Python does for OS-X – I think it’s almost as simple as putting the executable in an app bundle.

https://www.continuum.io/downloads

Try installing it and see what pythonw is actually linked to.

You mean that I need to check the pythonw executable supplied by Anaconda’s Python, and see what’s dependency (shared library) it depends on?
I haven’t try it yet, but I do check what my build GDB’s dependencies.

lydeMBP:~ ly$ otool -L /usr/local/Cellar/gdb/7.10/bin/gdb
/usr/local/Cellar/gdb/7.10/bin/gdb:
/usr/local/opt/readline/lib/libreadline.6.dylib (compatibility version
   6.0.0, current version 6.3.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current
version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1153.18.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python
(compatibility version 2.7.0, current version 2.7.10)
/usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 7.2.0)

``

This is what I mentioned in my post to GDB maillist: asm warrior - How to build GDB under OSX which links to the Python.framework

It looks like GDB is linked to the system’s python framework, this is the pre-installed python distribution by Apple(I’m using Mac OSX 10.11), my guess is that the IsDisplayAvailable function checking is mainly focused on the host application, not the shared libraries. I can’t find the source code of Anaconda’s Python distribution, so I don’t know how they workaround this issue.

I think it’s almost as simple as putting the executable in an app bundle.

That’s the point I want to achieve, to promote the privilege of the host GDB by creating an app bundle, I just don’t know how to do it.

Thanks.
Asmwarrior

···

On Saturday, October 24, 2015 at 8:39:11 AM UTC+8, Chris Barker - NOAA Federal wrote:

See the source code and the python Mac list archives for some discussion.

Hi, CHB, thanks for the reply.
I did subscribe to the pythonmac-sig maillist, and I have posted an email
to that maillist several days ago, but sadly, I see my post is not appeared
in that maillist, maybe, the email is not approved by the administer of
that maillist.

That's odd -- I don't think it's moderated. But at anyrate, here is the
thread where we discussed this a while back.

https://mail.python.org/pipermail/pythonmac-sig/2014-August/024078.html

HTH,

-Chris

···

On Fri, Oct 23, 2015 at 7:45 PM, asm warrior <asmwarrior@gmail.com> wrote:

Maybe, I need to try send an email again. Search on that maillist achieve
doesn't give me much useful results. (blindly reviewing all the python.org's
source code to find how they workaround this issue may take too much time)

Another option is to take a look at the different kludge that Anaconda's
Python does for OS-X -- I think it's almost as simple as putting the
executable in an app bundle.

Download Anaconda Distribution | Anaconda

Try installing it and see what pythonw is actually linked to.

You mean that I need to check the pythonw executable supplied by
Anaconda's Python, and see what's dependency (shared library) it depends
on?
I haven't try it yet, but I do check what my build GDB's dependencies.

lydeMBP:~ ly$ otool -L /usr/local/Cellar/gdb/7.10/bin/gdb
/usr/local/Cellar/gdb/7.10/bin/gdb:
/usr/local/opt/readline/lib/libreadline.6.dylib (compatibility version
   6.0.0, current version 6.3.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current
version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
(compatibility version 150.0.0, current version 1153.18.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python
(compatibility version 2.7.0, current version 2.7.10)
/usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 7.2.0)

This is what I mentioned in my post to GDB maillist:
asm warrior - How to build GDB under OSX which links to the Python.framework

It looks like GDB is linked to the system's python framework, this is the
pre-installed python distribution by Apple(I'm using Mac OSX 10.11), my
guess is that the IsDisplayAvailable function checking is mainly focused on
the host application, not the shared libraries. I can't find the source
code of Anaconda's Python distribution, so I don't know how they workaround
this issue.

I think it's almost as simple as putting the executable in an app bundle.

That's the point I want to achieve, to promote the privilege of the host
GDB by creating an app bundle, I just don't know how to do it.

Thanks.
Asmwarrior

--
You received this message because you are subscribed to the Google Groups
"wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Hello, Chris, thanks for the link in pythonmac-sig maillist, I have carefully read that thread(especially the reply from Ned Deily), I think I need to construct an app bundle directory to wrap the gdb command line executable, and to see whether it works OK or not. Redirect the calling python script to some frameworked python can not be used in my case, since here I use the embedded python interpreter inside the gdb.

I will report back here about the process and result.

Thanks.
Asmwarrior

···

On Tuesday, November 3, 2015 at 8:45:10 AM UTC+8, Chris Barker wrote:

On Fri, Oct 23, 2015 at 7:45 PM, asm warrior asmwa...@gmail.com wrote:

See the source code and the python Mac list archives for some discussion.

Hi, CHB, thanks for the reply.
I did subscribe to the pythonmac-sig maillist, and I have posted an email to that maillist several days ago, but sadly, I see my post is not appeared in that maillist, maybe, the email is not approved by the administer of that maillist.

That’s odd – I don’t think it’s moderated. But at anyrate, here is the thread where we discussed this a while back.

https://mail.python.org/pipermail/pythonmac-sig/2014-August/024078.html

HTH,

-Chris