[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Readline and StringIO

e

8/27/2006 9:51:00 PM

It is currently not possible to substitute $stdout or
$stdin with a StringIO when using the Readline library
($stderr seems to be fine) due to a T_FILE check in
readline.c.

Can someone come up with a reason why this might be
required before I change it and submit a patch?

While I am at it, I suppose I will try to provide an
additional method for getting the full line of input.

--
Posted via http://www.ruby-....
7 Answers

Robert Klemme

8/27/2006 10:01:00 PM

0

Eero Saynatkari wrote:
> It is currently not possible to substitute $stdout or
> $stdin with a StringIO when using the Readline library
> ($stderr seems to be fine) due to a T_FILE check in
> readline.c.
>
> Can someone come up with a reason why this might be
> required before I change it and submit a patch?
>
> While I am at it, I suppose I will try to provide an
> additional method for getting the full line of input.

Um, I don't understand why you would want to do that. You are talking
about GNU readline, aren't you? AFAIK this lib is for interactive
editing input - something you cannot do with a StringIO anyway. Did I
miss something?

Kind regards

robert

e

8/27/2006 10:15:00 PM

0

Robert Klemme wrote:
> Eero Saynatkari wrote:
>> It is currently not possible to substitute $stdout or
>> $stdin with a StringIO when using the Readline library
>> ($stderr seems to be fine) due to a T_FILE check in
>> readline.c.
>>
>> Can someone come up with a reason why this might be
>> required before I change it and submit a patch?
>>
>> While I am at it, I suppose I will try to provide an
>> additional method for getting the full line of input.
>
> Um, I don't understand why you would want to do that. You are talking
> about GNU readline, aren't you? AFAIK this lib is for interactive
> editing input - something you cannot do with a StringIO anyway. Did I
> miss something?

Unit-testing a program that is supposed to be
interactive. StringIO can would be a fairly simple
way of providing specific input and being able to
predict the output. This is possible with files as
well, if a bit less wieldy :)

> Kind regards
>
> robert


--
Posted via http://www.ruby-....

e

8/27/2006 10:21:00 PM

0

Eero Saynatkari wrote:
> Robert Klemme wrote:
>> Eero Saynatkari wrote:
>>> It is currently not possible to substitute $stdout or
>>> $stdin with a StringIO when using the Readline library
>>> ($stderr seems to be fine) due to a T_FILE check in
>>> readline.c.
>>>
>>> Can someone come up with a reason why this might be
>>> required before I change it and submit a patch?
>>>
>>> While I am at it, I suppose I will try to provide an
>>> additional method for getting the full line of input.
>>
>> Um, I don't understand why you would want to do that. You are talking
>> about GNU readline, aren't you? AFAIK this lib is for interactive
>> editing input - something you cannot do with a StringIO anyway. Did I
>> miss something?
>
> Unit-testing a program that is supposed to be
> interactive. StringIO can would be a fairly simple
> way of providing specific input and being able to
> predict the output. This is possible with files as
> well, if a bit less wieldy :)

Come to think of it, might make such input redirection
possible in irb also (if using --readline).

>> Kind regards
>>
>> robert


--
Posted via http://www.ruby-....

Robert Klemme

8/28/2006 9:12:00 AM

0

On 28.08.2006 00:20, Eero Saynatkari wrote:
> Eero Saynatkari wrote:
>> Robert Klemme wrote:
>>> Eero Saynatkari wrote:
>>>> It is currently not possible to substitute $stdout or
>>>> $stdin with a StringIO when using the Readline library
>>>> ($stderr seems to be fine) due to a T_FILE check in
>>>> readline.c.
>>>>
>>>> Can someone come up with a reason why this might be
>>>> required before I change it and submit a patch?
>>>>
>>>> While I am at it, I suppose I will try to provide an
>>>> additional method for getting the full line of input.
>>> Um, I don't understand why you would want to do that. You are talking
>>> about GNU readline, aren't you? AFAIK this lib is for interactive
>>> editing input - something you cannot do with a StringIO anyway. Did I
>>> miss something?
>> Unit-testing a program that is supposed to be
>> interactive. StringIO can would be a fairly simple
>> way of providing specific input and being able to
>> predict the output. This is possible with files as
>> well, if a bit less wieldy :)
>
> Come to think of it, might make such input redirection
> possible in irb also (if using --readline).

You can use fork with a temporary file that is used as input. Even more
appropriate for testing interactive applications might be something like
expect or the Ruby version of it.

Kind regards

robert

e

8/28/2006 2:26:00 PM

0

Robert Klemme wrote:
> On 28.08.2006 00:20, Eero Saynatkari wrote:
>>>>>
>>> well, if a bit less wieldy :)
>>
>> Come to think of it, might make such input redirection
>> possible in irb also (if using --readline).
>
> You can use fork with a temporary file that is used as input. Even more
> appropriate for testing interactive applications might be something like
> expect or the Ruby version of it.

Not sure if expect will work on output streams (though
I will take a look) and yes, I am aware that this can
be done with files (which is what I am doing currently).

I was merely wondering if there is any reason for the
T_FILE check in Readline (as opposed to a more permissive
one) since that would be the easier solution.

> Kind regards
>
> robert


--
Posted via http://www.ruby-....

David Vallner

8/28/2006 2:56:00 PM

0

Eero Saynatkari wrote:
> I was merely wondering if there is any reason for the
> T_FILE check in Readline (as opposed to a more permissive
> one) since that would be the easier solution.

Change the check and see if there is a reason?

Personally, I'd avoid unit-testing with simulating interactive input.
Unless you're unit-testing the readline library / binding. Maybe you're
missing an abstraction layer between user input and your program logic?

At least I thought unit testing was supposed to test the core logic
modules, where you can just feed them with your specific data or
environment. Testing at the interface level doesn't seem like
unit-testing to me, and you probably want tools like expect to get
decent coverage from that approach.

David Vallner

e

8/28/2006 3:18:00 PM

0

David Vallner wrote:
> Eero Saynatkari wrote:
> > I was merely wondering if there is any reason for the
>> T_FILE check in Readline (as opposed to a more permissive
>> one) since that would be the easier solution.
>
> Change the check and see if there is a reason?
>
> Personally, I'd avoid unit-testing with simulating interactive input.
> Unless you're unit-testing the readline library / binding. Maybe you're
> missing an abstraction layer between user input and your program logic?

I am actually trying to test output which is also not possible.

> At least I thought unit testing was supposed to test the core logic
> modules, where you can just feed them with your specific data or
> environment. Testing at the interface level doesn't seem like
> unit-testing to me, and you probably want tools like expect to get
> decent coverage from that approach.

I dunno, I see nothing wrong with testing with correct/incorrect
IO for those parts which access the streams directly. The alternative
would be using some type of mocking but, well, that would not work
either.

> David Vallner


--
Posted via http://www.ruby-....