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

[asm warrior]

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 - http://wiki.wxpython.org/wxPythonVirtualenvOnMac

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 - https://docs.python.org/2/extending/embedding.html
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 - http://stackoverflow.com/questions/33302266/is-it-possible-to-conver-a-command-line-application-to-an-application-bundle-und

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

Asmwarrior

[Tim Roberts]

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.

[asm warrior]

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 http://wiki.wxpython.org/wxPythonVirtualenvOnMac, 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

[asm warrior]

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

I'm not sure, if GDB becomes an application bundle, it can return an valid CGDirectDisplayID ?

Thanks

Asmwarrior


[Chris Barker - NOAA Federal]

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

--
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-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[asm warrior]

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

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: https://sourceware.org/ml/gdb/2015-10/msg00085.html

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

 

[Chris Barker]

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

 

--

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-user...@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....@noaa.gov

[asm warrior]

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

 

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