Simple New Ruby Programmer Problem with $stdin.gets

[Mason Kelsey]

[Note: parts of this message were removed to make it a legal post.]

I'm having difficulty getting any command to work to pick up input from a
screen or what looks like a DOS box when I run a script from SciTE. In the
following code, which you will recognize as a slightly modified
"basic_client. rb" from Chapter 12 of Beginning Ruby:

require 'bot'
#bot = Bot.newname => ARGV[0], :data_file => ARGV[1])
bot = Bot.newname => "No Sam", :data_file => "bot_data")
puts bot.greeting
while input = $stdin.gets and input.chomp != 'end'
puts '>> ' + bot.response_to(input)
end
puts bot.farewell

I get the the thing that looks like a DOS Box appear but it is locked up and
I am unable to input anything. When I kill it by clicking on the close
button, I get the message:

ruby basic_client.rb Hi. I'm No Sam. Want to chat?
Exit code: -1073741510

I have tried just using the gets by itself without the $stdin. with the same
failure. Do I have to execute this from outside of SciTE? Then where? I
am running Windows XP. Unfortunately, "Beginning Ruby" does a lite job on
input from monitors. The way gets is described, on page 203 of the book,
just does not work.

Anyway, what is the point for SciTE to display the thing that looks like a
DOS Box if it is always locked up?

I bet that the problem is something stupid I am not noticing. Enjoy
revealing my ignorance! And thanks.

No Sam

 

[7stud --]

Do I have to execute this from outside of SciTE?

I don't know anything about Scite, but you should learn to use "the
command" line before using a text editor to run programs.

Then where?
I
am running Windows XP. Unfortunately, "Beginning Ruby" does a lite job
on
input from monitors.

Computer programs don't get input from terminals; programs get input
from *keyboards* (or files). Output is what goes to *monitors* (or
files). Review p. 6-7 on using a command window to run programs from
"the command line".

The way gets is described, on page 203 of the
book,
just does not work.

I think you mean page 230 for anyone reading along.

Anyway, what is the point for SciTE to display the thing that looks like
a
DOS Box if it is always locked up?

I don't know. That might be a question better asked in the Scite user's
forum, however you might get lucky here.

 

[7stud --]

Computer programs don't get input from terminals; ..

That should read:

Computer programs don't get input from monitors; ..

 

[Mason Kelsey]

[Note: parts of this message were removed to make it a legal post.]

Sorry for the typo; I didn't mean "monitor". I'm a retired programmer, a
Dilbert dinosaur, and certainly know that inputs don't come from monitors.
The first computer I worked on had vacuum tubes and 1K of mainframe memory!
Having been in the field for 36 years before my retirement in 2001, the term
terminal used to be used in the distant past for a monitor/keyboard combo or
a teletype machine, typically with acoustic phone couples for the
connections to the mainframe. Clearly that is not how some use the term
terminal any more. So the world changes, what else is new?

I tried using the run/cmd that you suggested, and it does work. Thank you.
But I assume most Ruby programmers don't work in the run/cmd environment,
what I call the DOS Box. If so that is a serious step backwards by about 28
years. I actually had to use the "dir" and "cd" commands to get to the
subdirectory where my rb files were. I haven't used them in so many years I
have forgotten how many have passed. DOS commands, today! What a
disappointment! How primitive!

I did mean page 203, where the gets command is used, without the $stdin.
Page 230 is about SQLite. This is not an SQL problem. It is curious that
the gets command does not work from within SciTE.

But, finally, you say there is a SciTE forum!? Great! I just did a Google
search to find it myself. It is at http://www.nabble.com/SciTE-f14248.html for
anyone who is interested. I will be taking my question there.

Thanks for your reply,

No Sam

 

[7stud --]

I tried using the run/cmd that you suggested, and it does work. Thank
you.
But I assume most Ruby programmers don't work in the run/cmd
environment,
what I call the DOS Box. If so that is a serious step backwards by
about 28
years.

I'm not sure what most ruby programmers do. But I think a lot of ruby
programmers use the command line to run programs. A lot of the answers
posted on this forum show the commands used to run a program on the
command line--although the open source world is heavily biased towards
unix/linux, so it is a unix/linux command line rather than a windows
command window.

IDE's are not so important for scripting languages. All you need is a
text editor that provides syntax highlighting and automatic indenting.
Obviously, as programs get longer and more complex a good IDE can be
helpful to navigate around the code.

I did mean page 203, where the gets command is used, without the $stdin.
Page 230 is about SQLite.

Then I would guess you have the 2nd edition, which you neglected to
mention.

that
the gets command does not work from within SciTE.

You have a gui, Scite, that is trying to run another gui, a dos command
window, in another thread. In my experience, open source text editors
often have trouble doing that, and then throw in windows, and you have a
recipe for disaster. You do know how eff'ed up windows is don't you?

 

[Markus Roberts]

But I assume most Ruby programmers don't work in the run/cmd

environment,
what I call the DOS Box. If so that is a serious step backwards by
about 28
years.

Only if you consider windows a step forward.

-- MarkusQ

P.S. In my experience, programmers (esp. serious programmers) spend a
lot of their time in command line environments, not so much in GUIs,
and avoid wizards and web apps like the plague. Users, on the other
hand, do the converse. It's a matter of which party takes the
initiative; do you want the computer to lead you by the hand or to
quietly do your bidding?

 

[Siep Korteling]

I'm having difficulty getting any command to work to pick up input from
a
screen or what looks like a DOS box when I run a script from SciTE. In
the
following code, which you will recognize as a slightly modified
"basic_client. rb" from Chapter 12 of Beginning Ruby:

require 'bot'
#bot = Bot.newname => ARGV[0], :data_file => ARGV[1])
bot = Bot.newname => "No Sam", :data_file => "bot_data")
puts bot.greeting
while input = $stdin.gets and input.chomp != 'end'
puts '>> ' + bot.response_to(input)
end
puts bot.farewell

I get the the thing that looks like a DOS Box appear but it is locked up
and
I am unable to input anything. When I kill it by clicking on the close
button, I get the message:

ruby basic_client.rb Hi. I'm No Sam. Want to chat?
Exit code: -1073741510

I have tried just using the gets by itself without the $stdin. with the
same
failure. Do I have to execute this from outside of SciTE? Then where?
I
am running Windows XP. Unfortunately, "Beginning Ruby" does a lite job
on
input from monitors. The way gets is described, on page 203 of the
book,
just does not work.

Anyway, what is the point for SciTE to display the thing that looks like
a
DOS Box if it is always locked up?

I bet that the problem is something stupid I am not noticing. Enjoy
revealing my ignorance! And thanks.

No Sam

On windows and using Scite, this simple code has the same behaviour:

puts "What is your name? "
answer = gets
puts "Hi, #{answer}. (any key to exit)"
gets

This however does work:

STDOUT.sync = true #no buffering
puts "What is your name? "
answer = gets
puts "Hi, #{answer}. (any key to exit)"
gets

If you run this from Scite, the output appears in the left pane. There
is no prompt, but the input should be typed there also.

hth,

Siep

 

[Mark]

I tried using the run/cmd that you suggested, and it does work. Thank
you. But I assume most Ruby programmers don't work in the run/cmd
environment, what I call the DOS Box. If so that is a serious step
backwards by about 28 years.

Not to me it isn't.

I actually had to use the "dir" and "cd"
commands to get to the subdirectory where my rb files were. I haven't
used them in so many years I have forgotten how many have passed. DOS
commands, today! What a disappointment! How primitive!

I should start walking on all 4's again then ;-)

 

[Jason Stewart]

Sorry for the typo; I didn't mean "monitor". =A0I'm a retired programmer,= a
Dilbert dinosaur, and certainly know that inputs don't come from monitors=

 

[Mason Kelsey]

[Note: parts of this message were removed to make it a legal post.]

I see no point in getting into a spitting contest over which OS is best or
whether open source is better than commercially available software. All OS
have their limitations, just as all languages do too. I just consider it
the mark of a professional programmer to work with any environment. I have
had experience working in a UNIX environment, when I worked for Bank of
America and later as a contractor for Schwab. Working with vi, a
mode controlled line editor, was not a pleasant experience, since I was used
to a full screen editor, like TSO on an IBM mainframe. Because of that
experience, I don't consider any OS to be the ultimate OS. I've worked
through more than 10 in my career. Programmers, myself included, tend to
like and think superior what they are used to. So it is understandable that
programmers trained in academic environments that expose the student to only
UNIX would tend to succumb to a UNIX bias. The obvious gravity of open
source code is that it is FREE (although not to the developer). Academic
environments, looking for ways to be cost effective, would naturally welcome
open source. But students usually don't realize that a professor's bias can
also cover up the professor's ignorance of other systems. So a UNIX bias
can become a self-perpetuating bias, just as a Windows bias can do the same
thing. After all, it does take a lot of time and energy to become
comfortable with another system. Yet the world changes in unexpected
ways and leaves those who think that their OS is the center of the
world with less job opportunities. The best heuristics seem to be "Be
Adaptable" and "Don't waste your time scorning an OS for whatever reason".
I am happy that you enjoy working with UNIX.

I think the best solution to my original question, although I have not
verified it yet, is to move from SciTE to a commercially available IDE for
the Windows environment. I checked the SCiTE forum and found that I was not
the only person puzzled and put off by the gets limitation, and that it
wasn't just a Windows issue. SciTE was a freebie that downloads when I
installed Ruby on my Windows XP system and it has its limitations that I
immediately ran into. Thanks again, for your comments. Yeah, 2nd
edition. The world changes as we speak.

No Sam

 

[S.D]

I see no point in getting into a spitting contest over which OS is best or
whether open source is better than commercially available software. All OS
have their limitations, just as all languages do too. I just consider it
the mark of a professional programmer to work with any environment. I have
had experience working in a UNIX environment, when I worked for Bank of
America and later as a contractor for Schwab. Working with vi, a
mode controlled line editor, was not a pleasant experience, since I was used
to a full screen editor, like TSO on an IBM mainframe. Because of that
experience, I don't consider any OS to be the ultimate OS. I've worked
through more than 10 in my career. Programmers, myself included, tend to
like and think superior what they are used to. So it is understandable that
programmers trained in academic environments that expose the student to only
UNIX would tend to succumb to a UNIX bias. The obvious gravity of open
source code is that it is FREE (although not to the developer). Academic
environments, looking for ways to be cost effective, would naturally welcome
open source. But students usually don't realize that a professor's bias can
also cover up the professor's ignorance of other systems. So a UNIX bias
can become a self-perpetuating bias, just as a Windows bias can do the same
thing. After all, it does take a lot of time and energy to become
comfortable with another system. Yet the world changes in unexpected
ways and leaves those who think that their OS is the center of the
world with less job opportunities. The best heuristics seem to be "Be
Adaptable" and "Don't waste your time scorning an OS for whatever reason".
I am happy that you enjoy working with UNIX.

I think the best solution to my original question, although I have not
verified it yet, is to move from SciTE to a commercially available IDE for
the Windows environment. I checked the SCiTE forum and found that I was not
the only person puzzled and put off by the gets limitation, and that it
wasn't just a Windows issue. SciTE was a freebie that downloads when I
installed Ruby on my Windows XP system and it has its limitations that I
immediately ran into. Thanks again, for your comments. Yeah, 2nd
edition. The world changes as we speak.

No Sam

I'm not sure what most ruby programmers do. But I think a lot of ruby
programmers use the command line to run programs. A lot of the answers
posted on this forum show the commands used to run a program on the
command line--although the open source world is heavily biased towards
unix/linux, so it is a unix/linux command line rather than a windows
command window.

IDE's are not so important for scripting languages. All you need is a
text editor that provides syntax highlighting and automatic indenting.
Obviously, as programs get longer and more complex a good IDE can be
helpful to navigate around the code.


Then I would guess you have the 2nd edition, which you neglected to
mention.


You have a gui, Scite, that is trying to run another gui, a dos command
window, in another thread. In my experience, open source text editors
often have trouble doing that, and then throw in windows, and you have a
recipe for disaster. You do know how eff'ed up windows is don't you?

For a great (ableit, a long) read on this topic, check out:

http://adam.shand.net/iki/library/in_the_beginning_was_the_command_line/

Morlocks and Eloi, what a great analogy!

 

[spiralofhope]

This however does work:

STDOUT.sync = true #no buffering

Aha! I don't use Scite any more, but when I did I always wondered why
I could never 'gets' user input. Thanks.

 

[Aldric Giacomoni]

So now we've changed to "What's a good editor for Ruby". I'll chip in
with my usual two answers:
For a good, free, open-source, cross-platform IDE, use Netbeans. For the
same but as an extendable text editor.. Use gVim I think you may like
Netbeans better.

 

[Michael Tomer]

Aldric, I always liked Scite because it's so tiny. Netbeans (and other
IDEs like Microsoft Visual Studio, etc.) strike me as being far more
than I need. The only features I really want in a code editor are text
highlighting and soft-tabs. Regex for search/replace is also nice.

However, I'd like to make sure that I'm not writing off IDEs without
giving them a fair shake. What sorts of IDE features do you find useful
when working with Ruby?

Mason, if you're programming Ruby on Windows without problems, then all
the power to you. However, most of us have switched because it helps us
avoid serious configuration issues. For instance, installing Libxml on
Windows took me a few days of Google searches. Installing Libxml on
Linux took one command, and it was over in 10 seconds. The same is true
of virtually every library I've ever come across. I've probably lost
weeks of my life trying to figure out how to get various libraries
working in Windows. Linux is almost always painless.

Don't get me wrong, I'm not an OS bigot. I use Windows, Linux and OSX on
a daily basis. However, when I develop, I do it on Linux/OSX. It saves
me a lot of pain.

Also, I work in a mainframe shop right now (We make banking software,
actually). I suspect that you're like a lot of my COBOL programming
co-workers in that you aren't really sure what open source software is
all about. For me, the most important thing is that I can fix any
problems I come across. When I'm on the mainframe and I run into a bug
in an IBM utility, I'm screwed. I can either try to get IBM to fix it,
which is probably never going to happen, or I can jump through hoops to
try to work around the bug.

If I'm working on a piece of open source software and I run into a bug,
I open the source code and fix it. When I'm done, I submit my changes to
the development team, and it usually gets rolled up into the main
version in a matter of hours. It's very liberating to squash the bugs
myself, rather than waiting for someone else to do it for me.