Front page | perl.module-authors |
Postings from November 2009
[My apologies for taking so long to reply.] On Sat, Oct 10, 2009 at 04:57:21PM -0500, Jonathan Rockway wrote: > Maybe. You are writing an application that makes use of "unusual" IO > patterns (i.e., something more complex than readline on stdin and print > on stdout; something like curses, Term::Readkey, whatever...), and you > want to be able to test in an environment that replicates sitting at a > terminal. Yeah, something like that. (For me, it was a character device connected via a serial link, but I assume that terminal display would be the typical case.) Term::Readkey is a good example, as it currently lacks any automated tests. Writing tests for such modules is quite a pain; this would attempt to make it a little bit less painful. > That makes sense, although I think you could repurpose > POE::Wheel::Run or AnyEvent::Subprocess for this. Thanks for the idea, but I don't think that event dispatching would work in such a case. The problem is that you have to surrender control to the subroutine you are testing, so you can't rely on a run() loop. > Does your test and the code you're testing run in the same process? Yes, but the test relies on a subprocess to handle the communication asynchronously. (I suppose I could've used signals or threads instead, but they both feel "icky" in Perl.) > Do you worry about deadlocking in that case? Yes. :) > I don't see how a regular pipe/socket would not be applicable, unless > you actually want input cooking or something else that the TTY > provides. (And yes, you often want this.) The module I was writing did expect to be able to call tcsetattr(). > Just a tip for future posters; a long email about your code *might* be > enough information, but you can say a lot more in fewer characters if > you just link to your github repository :) I was kinda waiting for confirmation on the usefulness of this module before setting up a public repo. In the meantime, I'll attach the current code, in hope that it will clear any confusion. (Yes, the blocking read() ought to be replaced by a proper select().) -- Maybe it's time to break that. -- Larry Wall in <199710311718.JAA19082@wall.org>Thread Previous