On 4/6/11 12:00 PM, [email protected] wrote: > Send Urwid mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.excess.org/mailman/listinfo/urwid > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Urwid digest..." > > > Today's Topics: > > 1. How to use raw_display.Screen from within rerouted pipe > (W. Cole Davis) > 2. Re: How to use raw_display.Screen from within rerouted pipe > (Ian Ward) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 5 Apr 2011 17:24:22 -0400 > From: "W. Cole Davis"<[email protected]> > Subject: [Urwid] How to use raw_display.Screen from within rerouted > pipe > To: [email protected] > Message-ID:<[email protected]> > Content-Type: text/plain; charset="ISO-8859-1"; format=flowed > > Hi all, been playing with urwid for a few days and from what I see it > will really suit my needs for a terminal interface to a prototype > project I'm working on. We are writing an application using mpi4py to > distribute some significant calculations to a cluster. The only node > displaying the interface is the head-node and this is already setup and > working. The problem is that when executing under mpi it seems to use a > non-default descriptor as it reroutes piped communications to a separate > buffer on the head-node (from all children too) and this screws up > urwid. I've been over and over the reference and examples I could find > but none seem to show anyone dealing with this type of issue. > > I looked at the source for the raw_display class and it assumes the fd > is '0' for default sys.stdin I'm guessing? Is there a way that I can > specify the terminal/buffer using core urwid functionality? It seemed > like, since when using MainLoop you can set a specific "Screen" object > but I cannot figure out how to create a custom one. > > Any help would be much appreciated. The actual (and vague) error I'm > seeing is: > > File > "/usr/lib64/python2.4/site-packages/urwid-0.9.9.1-py2.4-linux-x86_64.egg/urwid/main_loop.py", > line 170, in run > > self.screen.run_wrapper(self._run) > > File > "/usr/lib64/python2.4/site-packages/urwid-0.9.9.1-py2.4-linux-x86_64.egg/urwid/raw_display.py", > line 233, in run_wrapper > > self.start(alternate_buffer) > > File > "/usr/lib64/python2.4/site-packages/urwid-0.9.9.1-py2.4-linux-x86_64.egg/urwid/raw_display.py", > line 180, in start > > self._old_termios_settings = termios.tcgetattr(0) > > termios.error: (22, 'Invalid argument') > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 06 Apr 2011 09:24:05 -0400 > From: Ian Ward<[email protected]> > Subject: Re: [Urwid] How to use raw_display.Screen from within > rerouted pipe > To: [email protected] > Message-ID:<[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > W. Cole Davis wrote on 2011-04-05 17:24: >> Hi all, been playing with urwid for a few days and from what I see it >> will really suit my needs for a terminal interface to a prototype >> project I'm working on. We are writing an application using mpi4py to >> distribute some significant calculations to a cluster. The only node >> displaying the interface is the head-node and this is already setup and >> working. The problem is that when executing under mpi it seems to use a >> non-default descriptor as it reroutes piped communications to a separate >> buffer on the head-node (from all children too) and this screws up >> urwid. I've been over and over the reference and examples I could find >> but none seem to show anyone dealing with this type of issue. >> >> I looked at the source for the raw_display class and it assumes the fd >> is '0' for default sys.stdin I'm guessing? Is there a way that I can >> specify the terminal/buffer using core urwid functionality? It seemed >> like, since when using MainLoop you can set a specific "Screen" object >> but I cannot figure out how to create a custom one. >> >> Any help would be much appreciated. The actual (and vague) error I'm >> seeing is: >> >> File >> "/usr/lib64/python2.4/site-packages/urwid-0.9.9.1-py2.4-linux-x86_64.egg/urwid/main_loop.py", >> line 170, in run >> >> self.screen.run_wrapper(self._run) >> >> File >> "/usr/lib64/python2.4/site-packages/urwid-0.9.9.1-py2.4-linux-x86_64.egg/urwid/raw_display.py", >> line 233, in run_wrapper >> >> self.start(alternate_buffer) >> >> File >> "/usr/lib64/python2.4/site-packages/urwid-0.9.9.1-py2.4-linux-x86_64.egg/urwid/raw_display.py", >> line 180, in start >> >> self._old_termios_settings = termios.tcgetattr(0) >> >> termios.error: (22, 'Invalid argument') > Hello, > > If you change the 0 to sys.stdin.fileno() does it work for you? > > Ian > > > > > ------------------------------ > > _______________________________________________ > Urwid mailing list > [email protected] > http://lists.excess.org/mailman/listinfo/urwid > > > End of Urwid Digest, Vol 67, Issue 2 > ************************************ I apologize for the delayed response to your quick one. Unfortunately the change to sys.stdin.fileno() does not change the problem because it returns the same value. I think there might be a flaw in my approach to attempting to use urwid here in a non-conventional way so let me explain further.
I have a Python project that is originally executed by mpi using the SPMD model. So the application is run on multiple processes across multiple nodes. The application determines what type of node it is on and executes the application path appropriate for its type. In fact the only node that acts differently from the rest is on the head-node. The head-node is the only node to import and execute urwid, but mpi routes all of the application output (stdout, stdin, stderr...) back to the head-node (which is great) but it also pipes the head-nodes output to a separate output buffer. I believe this is what causes the problem. Is there was a way for me to interface with the raw_display.Screen object to create one with the correct fd (which I would determine) prior to it running its own start? Seems improbable considering its built into its constructor. In almost all examples where I see urwid used it is run as the primary application loop with all functionality and logic declared within its scope. I'm interested in using it as a separate object/process which is started by the main-loop of the top-level application. When I run some test code in a single process on the head-node it works fine. It is when run by mpi that the problem arises. Cole _______________________________________________ Urwid mailing list [email protected] http://lists.excess.org/mailman/listinfo/urwid
