This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
NeverCast's profile picture

FileHandle.flush()

Started by NeverCast, 31 January 2013 - 07:38 AM
NeverCast #1
Posted 31 January 2013 - 08:38 AM
Hello,

I don't normally make suggestions because I'm very content with CC the way it is, however, I would like a way to flush to a file without having to close and reopen a file handle to do so.

I want to make a running log of everything that happens in my program, for debugging and reporting purposes.
If my program was to crash I want the log to certainly be stored. But it seems even if the handle to a file is lost, and it's supposedly disposed. The stream is not flushed or closed, so anything written is lost.

The alternative to this would be to open and close the file every time I call the log() function. But that seems disgustingly inefficient.
I also realize I could run the main content of my code in a protected call, but again it feels unnecessary and not entirely fool proof.

I would like the ability to flush the stream when I need to.
The close() functionality should remain the same so that no existing program is required to change anything, the buffered stream will still flush on close. This is just so I can have a constant running log file handle.

( Also flush on dispose of the handle would be a great addition, if possible by the LuaJ VM, I assume but am not certain that there is some table disposed listener event thing of sorts somewhere. )

Regards,
NeverCast.
Cloudy #2
Posted 31 January 2013 - 09:00 AM
Already exists. Close will occur on shut down of the computer. Whether flush occurs on Garbage Collection is up to Java.
NeverCast #3
Posted 31 January 2013 - 11:35 AM
So in the case of an error it is required to reboot the computer to flush any open handles?
ElvishJerricco #4
Posted 02 February 2013 - 04:53 PM
So are you suggesting something like this?


file = fs.open("file", "w")
file.write("text")
file.flush()
file.write("text2")
file.close()

That could be very useful. I do like that. And while we're at it, file seeking would be incredibly handy. I don't think Java has any native support for file seeking but that could be worked around I'm sure.
immibis #5
Posted 02 February 2013 - 06:14 PM
So are you suggesting something like this?


file = fs.open("file", "w")
file.write("text")
file.flush()
file.write("text2")
file.close()

That could be very useful. I do like that. And while we're at it, file seeking would be incredibly handy. I don't think Java has any native support for file seeking but that could be worked around I'm sure.
It does.
ElvishJerricco #6
Posted 02 February 2013 - 06:59 PM
So are you suggesting something like this?


file = fs.open("file", "w")
file.write("text")
file.flush()
file.write("text2")
file.close()

That could be very useful. I do like that. And while we're at it, file seeking would be incredibly handy. I don't think Java has any native support for file seeking but that could be worked around I'm sure.
It does.

I didn't know about this class! That's very useful.
theoriginalbit #7
Posted 03 February 2013 - 03:29 AM
-snip-
Is this for what I think it is for?

Already exists.
Wait, wait, wait … flush exists? O.o Wiki states it doesn't!
KillaVanilla #8
Posted 03 February 2013 - 07:10 AM
File API w/ Seek/Flush

Okay, a bit more elaboration:
I've already made this, and you can find it with the link above.
Cloudy #9
Posted 04 February 2013 - 12:02 AM
The wiki isn't always up to date. flush() DOES exist. Check "whatsnew" to find out.
KaoS #10
Posted 04 February 2013 - 05:18 AM
ok, I just have to say that this is awesome… CC devs rock :)/> I didn't even know
NeverCast #11
Posted 05 February 2013 - 12:05 PM
WOOO! Flush exists!

All we need now is faster binary reading/writing!
Cloudy #12
Posted 06 February 2013 - 01:13 AM
WOOO! Flush exists!

All we need now is faster binary reading/writing!

Yep, planned - will probably look into that today, maybe provide small replacement files for people to test.
NeverCast #13
Posted 07 February 2013 - 10:19 AM
My CCTube transcoder suffers from the binary writing, The transcoding is actually faster than the writing. So I could write some os.clock() tests to compare.
Once it's ready that is, but judging from discussions this morning it could be a little while longer, correct?