[wingide-users] __import__ 64bit package in Wing

John Burnett JBurnett at blizzard.com
Thu May 15 11:22:15 MDT 2008


ShowMessageDialog isn't quite what I need (was hoping for a modal dialog
I could control via script, to update progress, close it, have a working
cancel button, etc).  It's not really important though... for now I'm
just throwing up a dialog saying "this'll take a while, see the messages
window for more info".

As for the stdout updating - no source here.  I had to deal with
something similar to this a long time ago and remember it being a pain
then as well, so... no thanks, I'm punting :).  I'll just print a bunch
of "."'s as a poor-man's progress bar for now...

Thanks for the help!

John



-----Original Message-----
From: Wingware Support [mailto:support at wingware.com] 
Sent: Thursday, May 15, 2008 7:46 AM
To: John Burnett
Cc: wingide-users at wingware.com
Subject: Re: [wingide-users] __import__ 64bit package in Wing

John Burnett wrote:
> Using a separate process sounded a bit too overboard, but since it was
a
> good learning exercise, I tried it :).  Launching the other python
with
> AsyncExecuteCommandLineE seems to work fine, but it brought up two
> questions:
> 
> -Since this is a long running process, it would be nice to have
> something indicate that it's still working.  Is there any sort of "I'm
> busy" dialog I can throw up and tear down when I'm done?  In this
case,
> I really do want to block the GUI until it's done, but in a "nice" way
> (so you can still pump messages if needed or whatever).

CAPIApplication's ShowMessageDialog is probably what you want.

> -In the meantime, I'm using simple prints, and hoping the user has the
> Messages tool up.  However, the stdout member of the handler returned
by
> AsyncExecuteCommandLineE doesn't seem to update as the process goes.
> I'm doing this:
> 
> ####
> handler = app.AsyncExecuteCommandLineE(pythonExePath, pythonDir,
myEnv,
> __file__)
> def poll():
>   done = handler.Iterate()
>   if done:
>     res = handler.Terminate()
>     print res
>     return 0
>   else:
>     print handler.stdout
>     return 1
> app.InstallTimeout(500, poll)
> ####
> 
> ...and what I'm seeing is a constant printing of "[]" (from the
repeated
> "print handler.stdout" calls).  Then, when the process is done, I get
> all my prints dumped at once (from the "print res" call).
> 
> Any ideas?  (Almost there! :)

It may be that the buffer size on stdout in the subprocess is set to
something
other than un-buffered?

Looking at this, I noticed that on non-Windows, we're incorrectly
setting buffer
size to 100000 bytes, but on Windows this is ignored and the pipes on
the IDE
side are always unbuffered.  So if you're still working on Windows, this
is
probably an issue in your subprocess, but this stuff can be enough of a
pain
that I may be missing something else.

One test would be to set up something outside of Wing where you have
more
control over pipes and see if you're able to get unbuffered output w/o
modifying the subprocess.

I remember beating my head against this quite a bit in the
implementation
of Wing's OS Commands tool.  If you have the Wing sources, look in
edit/cap_oscommands.py and wingutils/spawn.py.

-- 

Stephan Deibel
Wingware | Python IDE
Advancing Software Development

www.wingware.com



More information about the wingide-users mailing list