Interactive tracing ...

[Andreas Leitgeb]

I've got a program that searches a large search-space
for some "solution", and this search can take a lot of time.
The search is done with a recursive function. At the moment
I have an if-statement that causes some progress information
to be written out only at a certain recursion level.

What I really want is, that the program just runs quietly,
and when I press <Enter>-key (or perhaps at regular wallclock
time intervalls), it should answer me with snapshot progress
information and continue.

I believe I will have to spawn a second thread that will
just wait for input from stdin, and set some volatile boolean
variable to true, and the recursive function in the main
thread would check this variable at appropriate times, and
if it is set, then print out the info and unset it. I don't
really care that - if I press <Enter> twice faster than the
other thread sees it - I will still only see one reaction,
but apart from that, is there anything else I should look
out for?

If instead I polled stdin for available data inside the
main (and only) thread, would it necessarily make it all
slower, or is there a way to do a real quick-check for
available data on a stream, that would be at least almost
as efficient as checking the volatile variable?

PS: Btw., it's a console-app without GUI.

 

[Knute Johnson]

I've got a program that searches a large search-space
for some "solution", and this search can take a lot of time.
The search is done with a recursive function. At the moment
I have an if-statement that causes some progress information
to be written out only at a certain recursion level.

What I really want is, that the program just runs quietly,
and when I press <Enter>-key (or perhaps at regular wallclock
time intervalls), it should answer me with snapshot progress
information and continue.

I believe I will have to spawn a second thread that will
just wait for input from stdin, and set some volatile boolean
variable to true, and the recursive function in the main
thread would check this variable at appropriate times, and
if it is set, then print out the info and unset it. I don't
really care that - if I press <Enter> twice faster than the
other thread sees it - I will still only see one reaction,
but apart from that, is there anything else I should look
out for?

If instead I polled stdin for available data inside the
main (and only) thread, would it necessarily make it all
slower, or is there a way to do a real quick-check for
available data on a stream, that would be at least almost
as efficient as checking the volatile variable?

PS: Btw., it's a console-app without GUI.

Look at the code below. The BufferedReader is created from System.in
and then is blocked in the loop until a line terminator is received,
<ENTER>. It is simple and should do what you want. If you are using
1.6 you can look at the Console class. It has some convenient methods
to get Readers and Writers for the console.

import java.io.*;

public class test {
public static void main(String[] args) {
Runnable r = new Runnable() {
public void run() {
try {
BufferedReader br = new BufferedReader(
new InputStreamReader(System.in));
while (true) {
// blocks until newline is received

br.readLine();
// set your flag here
}
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
};
new Thread(r).start();
}
// your other code can go here
}

 

[Andreas Leitgeb]

Look at the code below. ...
Runnable r = new Runnable() {
public void run() {
try {
BufferedReader br = new BufferedReader(
new InputStreamReader(System.in));
[while(1)-loop for br.readLine&flag-setting]
} catch (IOException ioe) { ioe.printStackTrace(); }
}
};
new Thread(r).start();

Thanks a lot. I (almost) took it "as is", except for the following
two changes:
while (br.readLine() != null) { flag=true; }
(to make sure, that EOF on stdin will not cause a busy loop)
and
Thread t=new Thread(r); t.setDaemon(true); t.start();
(daemonizing the thread, so it will not keep the prog running after
the main thread is done.)

Especially finding the right stacking of streams and readers is something
that would have taken me a lot of time to get right - Thanks for saving me
that work!

 

[Mark Space]

Especially finding the right stacking of streams and readers is something
that would have taken me a lot of time to get right - Thanks for saving me
that work!

This is perennial complaint of mine as well.

In general, the Stream classes are older, and there were some
deficiencies found. So therefore the Reader and Writer classes were
introduced.

To bridge the two, use InputStreamReader and OutputStreamWriter. These
both go from an older style IO (the Stream) to the newer version
(Readers and Writers), just what you would expect for a class system
that's been upgraded.

Check out this tutorial, paying particular attention to the the section
on Character Streams. That's where the important bit is.

<http://java.sun.com/docs/books/tutorial/essential/io/index.html>

After that, you just look up which IO Stream does what you want, which
Reader or Writer gives you the final result you want, and put those two
together with an IO Stream Reader/writer object if needed. Notice that
this is just what Knute has done.

Sometimes, you put a BufferedReader or -Writer in between a outer
Reader/Writer and the IO Stream Reader/Writer. These last two
paragraphs will get you 90% of what you need from Java IO.

P.S. _Learning Java_ by O'Reilly. It goes into all this. ;-)

 

[Andreas Leitgeb]

This is perennial complaint of mine as well.
In general, the Stream classes are older, ...

The Stream classes may be slightly older, in that it took all the way until
Java 1.1 [1] until they introduced Readers and Writers, but by no means does
that mean that Streams are deficient or no longer relevant. (What
"deficiencies" were found in Streams, anyway?)

I guess he means the unlucky decision to add a (since deprecated) readLine()
to the *InputStream-family.

The real difference, and the important one, is that Streams handle bytes and
Readers/Writers handle characters and their encodings.

So far it's clear, but it's not trivially obvious which *Reader class
can be wrapped on what *Stream class, and what interims-wrappers I need
to be finally able to read a whole line (->BufferedReader) from System.in .

I love the Scanner, though. Just pass it a File or System.in or a
String, and you get all the tokens you want.