sending input to an embedded application

[George Oliver]

hi, I'm a novice programmer trying to better define a hobby project
I'm thinking of.

What I would like to do is take a program and embed it or put it
within a Python-run GUI, using the GUI just to capture and send input
to the application, and display the ouput.

Specifically I want to use a Python module such as wxPython, pygame or
pyglet to build the UI, capture key presses, and then send a string to
the program, an interactive fiction interpreter; the reason for this
is that the interpreter on its own doesn't have the capability to
recognize certain key presses on the keyboard. I thought that writing
a middle layer rather than a brand new interpreter would be easier for
someone of my skill level.

The interpreter would send its output to the Python GUI. The GUI then
would be as light/translucent as possible, just accepting input,
sending it to the interpreter, and displaying the output as if you
were just running the interpreter by itself.

As I don't really know the issues involved, I'm hoping someone can
point me in the right direction. Do people 'frame' programs with
something like wxPython or pygame and use the frame to capture and
pass along input, and receive and display the output?


thanks, George

 

[Uwe Schmitt]

hi, I'm a novice programmer trying to better define a hobby project
I'm thinking of.

What I would like to do is take a program and embed it or put it
within a Python-run GUI, using the GUI just to capture and send input
to the application, and display the ouput.

Specifically I want to use a Python module such as wxPython, pygame or
pyglet to build the UI, capture key presses, and then send a string to
the program, an interactive fiction interpreter; the reason for this
is that the interpreter on its own doesn't have the capability to
recognize certain key presses on the keyboard. I thought that writing
a middle layer rather than a brand new interpreter would be easier for
someone of my skill level.

The interpreter would send its output to the Python GUI. The GUI then
would be as light/translucent as possible, just accepting input,
sending it to the interpreter, and displaying the output as if you
were just running the interpreter by itself.

As I don't really know the issues involved, I'm hoping someone can
point me in the right direction. Do people 'frame' programs with
something like wxPython or pygame and use the frame to capture and
pass along input, and receive and display the output?

thanks, George

Which interface does your interpreter provide ? Just commandline or
can you access by other methods ?

http://sourceforge.net/projects/pexpect/ might help you

Greetings, Uwe

 

[mefyl]

Which interface does your interpreter provide ? Just commandline or
can you access by other methods ?

http://sourceforge.net/projects/pexpect/ might help you

Although Pexpect looks more advanced and complete, you might want to take a
look at popen* modules. It enables you to easily run a subprocess, feed him
data on stdin, retrieve output from stdout/stderr, and wait for its
completion.

http://docs.python.org/lib/module-popen2.html

 

[Matthew Fitzgibbons]

Although Pexpect looks more advanced and complete, you might want to take a
look at popen* modules. It enables you to easily run a subprocess, feed him
data on stdin, retrieve output from stdout/stderr, and wait for its
completion.

http://docs.python.org/lib/module-popen2.html

I believe the subprocess module is the recommended module to use now.

-Matt

 

[norseman]

I believe the subprocess module is the recommended module to use now.

-Matt

=====================================

HUMMMMMM!



#
print "popen3 run"
########## from existing python docs:
from popen2 import *

r,w,e= popen3('dmesg | grep hda')
print r.read()


print "subprocess run"
########## from existing python docs:
# "... Replacing older functions with the subprocess module..."
from subprocess import *

p1 = Popen(["dmesg"], stdout=PIPE)
p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
output = p2.communicate()[0]
#documentation quits

print p2.communicate()

#
""" Why do children insists on making things more complicated
than necessary? If the stated bragging rights of Python
is that one writes less code to accomplish more, then I
have to say "bullshit", just count the printable characters.

to write less would be to change something like this:
try:
f = open(arg, 'r')
except IOError:
print 'cannot open', arg
else:
print arg, 'has', len(f.readlines()), 'lines'
f.close()
### I have to guess what type error to code for and I'll need another
module to decode what actually went wrong.


to this:
if (fd = os.open(filename, 'O_RDRW|O_BINARY, 0666) == -1)
...handle it
if fd.err.type == THIS #catagory
if fd.err == this #specific
do this
etc.
## just to see what went wrong? print fd.err.type, fd.err
else: #just to match above
continue processing
### error reporting actually usefull

who says fd cannot be simple interger or pointer to error block
depending on whether it's valid or not? The bonus is, if there is
no trap it will stop anyway first time fd is used as a file number.
The crash usually actually points to the correct place.

All that aside: subprocess seems to have a problem:

"""
# When I run the above I get:

==============
PY:> py test.py
popen3 run
ide0: BM-DMA at 0x1400-0x1407, BIOS settings: hdaMA, hdbio
hda: ST9160821A, ATA DISK drive
hda: attached ide-disk driver.
hda: host protected area => 1
hda: cannot use LBA48 - capacity reset from 312581808 to 268435456
hda: 268435456 sectors (137439 MB) w/8192KiB Cache, CHS=19457/255/63,
UDMA(100)
hda: hda1 hda2 hda3 < hda5 hda6 hda7 hda8 >

subprocess run
('', None)
PY:>
=============

Note subprocess yields unexpected answer. Probably needs better
documentation and less typing.

The "PY:> " is result of script to change to dir python and set the PATH
py is copy of python renamed to afford less typing. (Unix vs Microsoft)

Note: without lots of extra effort, the piping only works for commands
like grep that are built to accept redirected I/O. I have yet to get it
to work with the GUI type. Those need special things implanted at
compile time because they don't use or even want the command line
interface. Typically they are "Point'n'Click" or take a hike. GUIs are
visually more appealing but don't play well in the production world.

Steve
(e-mail address removed)