392 posts
Location
Christchurch, New Zealand
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.
2447 posts
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.
392 posts
Location
Christchurch, New Zealand
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?
808 posts
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.
997 posts
Location
Wellington, New Zealand
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.
808 posts
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.
7508 posts
Location
Australia
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!
278 posts
Posted 03 February 2013 - 07:10 AM
File API w/ Seek/FlushOkay, a bit more elaboration:
I've already made this, and you can find it with the link above.
2447 posts
Posted 04 February 2013 - 12:02 AM
The wiki isn't always up to date. flush() DOES exist. Check "whatsnew" to find out.
1548 posts
Location
That dark shadow under your bed...
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
392 posts
Location
Christchurch, New Zealand
Posted 05 February 2013 - 12:05 PM
WOOO! Flush exists!
All we need now is faster binary reading/writing!
2447 posts
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.
392 posts
Location
Christchurch, New Zealand
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?