[wxPython] TypeError: Only 1 wxApp per process!

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[wxPython] TypeError: Only 1 wxApp per process!

Riaan Booysen
Hi,

I'm working on a wxPython debugger. It's basically a port of the
debugger in IDLE. The basics are going, stack locals, globals and it
traces thru plain python but I can't debug wxPython applications.
I've run into a problem I can see no workaround or simple solution
for: The IDE needs an wxApp object and the application being debugged
needs one, but this is not allowed :(

I can appreciate that for almost any other type of app this is a very
reasonable restriction, but this is a reflective problem.
One of the practical problems with more than one instance of an wxApp
object would be how to manage two MainLoop()s without using threads.
I don't even have this requirement as I'd be satisfied with the two
wxApp objects alternately calling MainLoop(), ExitMainLoop() as the
tracing switches between IDE and the app being debugged. In this way
only one wxApp needs a running MainLoop.

Are there any other fundamental problems with running more then one
wxApp and what are wxWindows debuggers doing? I suppose compiled
programs would always run in their own process.

If there are no workarounds I am going to run the debugger as a
separate app and connect to it with sockets. The debugger frame
would be a visual client for a non visual debugger server running
the app being debugged.
This would have the funky benefit of automagically being a remote
debugger and of course, core dumps wouldn't take the IDE with it,
but it would mean alot more work than just running two wxApps
in the current code.

Help and suggestions would be greatly appreciated.

Riaan

_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users



Reply | Threaded
Open this post in threaded view
|

Re: [wxPython] TypeError: Only 1 wxApp per process!

Robin Dunn
> Are there any other fundamental problems with running more then one
> wxApp

Yes.  The creation of the wxApp is when a lot of the per-process resources
are created in wxWindows.  I don't see an easy way around it.

> and what are wxWindows debuggers doing?

There aren't any yet.


> I suppose compiled
> programs would always run in their own process.

Yep.


>
> If there are no workarounds I am going to run the debugger as a
> separate app and connect to it with sockets. The debugger frame
> would be a visual client for a non visual debugger server running
> the app being debugged.
> This would have the funky benefit of automagically being a remote
> debugger and of course, core dumps wouldn't take the IDE with it,
> but it would mean alot more work than just running two wxApps
> in the current code.


That is what I had planned on doing when I sketched out an IDE a while back.
I think the benefits of a remote debugger are well worth the effort.

There is another idea that I had about a week ago that would probably work.
Whe the debugger is preparing to start a new app, it can replace the wxApp
class in the wxPython.wx module with some class that belongs to the debugger.

    wxPython.wx.wxApp = wxDebuggedChildApp

When the instance is created then the debugger can take control and start
stepping through the OnInit method.  When SetTopWindow is called the debugger
can keep track of the window that is given and assume that the app is ended
when that window closes.  The debugger can take control again when MainLoop
is called, or maybe just let it be a no-op and return to the IDE's event
loop.


--
Robin Dunn
Software Craftsman
[hidden email]
http://AllDunn.com/robin/
http://AllDunn.com/wxPython/  Check it out!



_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users



Reply | Threaded
Open this post in threaded view
|

Re: [wxPython] TypeError: Only 1 wxApp per process!

Riaan Booysen


Robin Dunn wrote:

>
> There is another idea that I had about a week ago that would probably work.
> Whe the debugger is preparing to start a new app, it can replace the wxApp
> class in the wxPython.wx module with some class that belongs to the debugger.
>
>     wxPython.wx.wxApp = wxDebuggedChildApp
>
> When the instance is created then the debugger can take control and start
> stepping through the OnInit method.  When SetTopWindow is called the debugger
> can keep track of the window that is given and assume that the app is ended
> when that window closes.  The debugger can take control again when MainLoop
> is called, or maybe just let it be a no-op and return to the IDE's event
> loop.

This works very well and it's a great temporary solution in the mean
while. Any application interacting with it's app object would not behave
correctly unless you gave wxDebuggedChildApp identical behaviour to
wxApp. Currently it's basically just got wxApp's interface copied
from wx.py. I still intend to do the remote debugger at some stage.
On windows the starting of the remote debugged application is the first
hurdle I see. Will probably need a tiny sort of orb running that starts
requested file as a debugging server.

And now for something completely different, is there anyway to find out
the resolution/size of the screen?

Riaan

_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users