file.close() while running

P

(-Peter-)

Hi..

I'm currently simulating some physics with a java program.

The results is printed to a file line by line.

The program takes several hours to run, so I would like to look at the
output as soon as it has been calculated.

Can I do something so that the files closes after each cycle in the
program, so that I'm able to read it?

/Peter
 
C

Christian

(-Peter-) said:
Hi..

I'm currently simulating some physics with a java program.

The results is printed to a file line by line.

The program takes several hours to run, so I would like to look at the
output as soon as it has been calculated.

Can I do something so that the files closes after each cycle in the
program, so that I'm able to read it?

/Peter

you can open a file and read it while it is being written to..
What you probably want is calling flush()/force() on your
stream/FileChannel so anything still cached is written out so you
actually can see it with other programs.
 
A

Arne Vajhøj

(-Peter-) said:
I'm currently simulating some physics with a java program.

The results is printed to a file line by line.

The program takes several hours to run, so I would like to look at the
output as soon as it has been calculated.

Can I do something so that the files closes after each cycle in the
program, so that I'm able to read it?


On some platform you may be able to read it using simply
by having your program call flush frequently and then
view the file the usual way.

If you need to do it portable I believe you would have to
close the file one file and open another file.

Arne
 
P

(-Peter-)

you can open a file and read it while it is being written to..
What you probably want is calling flush()/force() on your
stream/FileChannel so anything still cached is written out so you
actually can see it with other programs.

can you explain how to actually do this?

/peter
 
C

Chase Preuninger

Just when you are finished writing just close the file. But when you
go to write again use a Random access file to append the new data. Or
you could use one of those streams that I can't remember the name of
that acts like one stream but copies the data into two so you could
give it a FileOutputStream to your file and one to System.out so the
console would be an exact copy of your file. I prefer the second one.
 
R

Roedy Green

Can I do something so that the files closes after each cycle in the
program, so that I'm able to read it?

you can use flush, but the file stays open. You could output to the
console.
 
B

BTDTGTTS

(-Peter-) said:
Hi..

I'm currently simulating some physics with a java program.

The results is printed to a file line by line.

The program takes several hours to run, so I would like to look at the
output as soon as it has been calculated.

Can you not deal with this through your OS? Under linux try the "tail"
command. Don't know about Windows though, but you can download some unix
utilities that have been complied for windows e.g
http://www.tailforwin32.sourceforge.net

HTH
 
K

Knute Johnson

(-Peter-) said:
Hi..

I'm currently simulating some physics with a java program.

The results is printed to a file line by line.

The program takes several hours to run, so I would like to look at the
output as soon as it has been calculated.

Can I do something so that the files closes after each cycle in the
program, so that I'm able to read it?

/Peter

Why don't you just display the output in a window as well as writing it
to the file? If there is too much data to look at on the screen or you
need to get another application on it, close the file at each stage and
make a working copy, you can have the program notify you when they are
ready. There is a lot of noise here for a really simple problem.
 
C

Christian

(-Peter-) said:
can you explain how to actually do this?

/peter
if you for example have something like

BufferedOutputStream buf = new BufferedOutputstream(new
FileOutputStream(file)));

buf.write(foo);
buf.flush(); //flush so eventually cached bytes are written to the
underlying stream i.e. file
 
B

BTDTGTTS

BufferedOutputStream buf = new BufferedOutputstream(new
FileOutputStream(file)));

buf.write(foo);
buf.flush(); //flush so eventually cached bytes are written to the
underlying stream i.e. file

OK - I'm going to bite & show my ignorance 'cos I haven't read the source,
but surely a BufferedOutputStream must eventually write to to the uderlying
stream when when the buffer is full. I know that then OS issues come into
play, but even the OS has to write at some point.
 
M

Mike Schilling

Lew said:
I never used an MKS product that I liked.

I used to use the utilities (I think the package was called the MKS
toolkit) and found them much more stable and less buggy than the
Cygwin versions..
 
M

Mike Schilling

Arne said:
Cygwin also has more stuff.

And all the cygwin stuff is the original stuff build
from the same source as on Linux.

Right, which means that Cygwin deals with Windows idiosyncracies (line
termination, drive letters, extensions like .bat and .exe, etc.) less
effectively than MKS does.
 
M

Mike Schilling

Lew said:
I don't know how effectively MKS utilities deal with those things, so I
can't speak to the comparison, but the Cygwin utilities don't have
problems with those things.

I recently installed Cygwin on a new PC, copied over my standard shell
scripts, started it up, and nothing worked. Cygwin insisted that they
contained illegal characters. What the .... Oh, right, Cygwin needs to be
configured to understand CR/LF terminators.

I have a number of scripts that find interesting files and pass their name
as arguments to different utility programs. So long as I stay within the
Cygwin world it all works great, but once I use non-Cygwin programs (gvim,
javac, perforce, etc.) I have to remember to use the cygpath utility to
convert /cygdrive/d//dir/foo.bar to d:\dir\foo.bar. That is, rather than
being able to simply

alias vi gvim

I need the following:

export SHELL=c:/cygwin/bin/tcsh
args=""
for arg in $*
do
arg=`cygpath -w $arg`
args="$args $arg"
done
C:/Program\ Files/Vim/vim70/gvim.exe $args
 
C

Christian

BTDTGTTS said:
OK - I'm going to bite & show my ignorance 'cos I haven't read the source,
but surely a BufferedOutputStream must eventually write to to the uderlying
stream when when the buffer is full. I know that then OS issues come into
play, but even the OS has to write at some point.
yes eventually it must.
Though if for example his prolgram only makes small outputs like one
line of text.. or say 100 bytes per hour..
then the stream might not write to disc for several hours.
The buffered stream will only write when its buffer is filled up.
Assume a buffersize of 512Byte that makes 6 hours.

Christian


Christian
 
B

BTDTGTTS

Christian said:
yes eventually it must.
Though if for example his prolgram only makes small outputs like one
line of text.. or say 100 bytes per hour..
then the stream might not write to disc for several hours.
The buffered stream will only write when its buffer is filled up.
Assume a buffersize of 512Byte that makes 6 hours.

I take your point. As a follow up, is BufferedOutputStream.flush() a request
or an instruction? Or is it OS dependant?
 
M

Mark Thornton

BTDTGTTS said:
I take your point. As a follow up, is BufferedOutputStream.flush() a request
or an instruction? Or is it OS dependant?

BufferedOuputStream.flush ensures that all data is flushed to the stream
which it wraps and flush is called in turn. If the underlying stream is
a FileOutputStream, then the data will reach the operating system and
the OS flush method called (if applicable). However this does not imply
that file metadata (length, modification time) is updated. Windows is an
operating system where flushing the data is not sufficient to update the
metadata. As a result applications which are 'watching' the file for any
change may not see any change at the earliest possible time. To force
the metadata to be updated without closing the file, use
FileChannel.force(true).

Mark Thornton
 
A

Arne Vajhøj

Mike said:
Right, which means that Cygwin deals with Windows idiosyncracies (line
termination, drive letters, extensions like .bat and .exe, etc.) less
effectively than MKS does.

Which must mean that Cygwin is better for nix emulation but MKS
is better for win integration.

Arne
 
M

Mike Schilling

Arne said:
Which must mean that Cygwin is better for nix emulation but MKS
is better for win integration.

That's my impression, yes. Since what I want is a useful set of tools
for Windows development, MKS is the superior toolset. Though MKS is
pricey and Cygwin is, well, free.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,011
Latest member
AjaUqq1950

Latest Threads

Top