The [IO/A spec][1] for `read` is as follows:
> Read up to n bytes from the stream, or until the end of the stream
> has been reached. [If] n is null, reads up to the block size of the
> underlying device, or up to 1024 bytes if the block size is not
> discernible. If n is not specified, this method always reads the
> full stream until its end is reached. ...
Since discovering the block size of the underlying device is
non-trivial, we will just default to 1024.
**NOTE**
The initial implementation of `File::read()` saves the current
(original) position, seeks to the beginning of the stream,
`readAll`s to the end, and then resets to the original position.
I think that this behavior is unexpected and should be changed--it
should read from the current position to the end of the stream and
stay there. The user should explicitly `seek` to the beginning of
the stream when necessary.
With the current implementation, the user should note that the
position *will not change* after calling `read()` with no arguments.
[1]: http://wiki.commonjs.org/wiki/IO/A#Instance_Methodshttp://code.google.com/p/phantomjs/issues/detail?id=938
When set to "true", any page that gets created, is
owned by the "page" that control it's lifetime.
Also, the pages can be found in the "page.pages[]" array.
Default value is "true".
Addresses [Issue #151](http://code.google.com/p/phantomjs/issues/detail?id=151)
CommonJS proposal: http://wiki.commonjs.org/wiki/Filesystem/A.
It's called "raw".
http://code.google.com/p/phantomjs/issues/detail?id=400
Squashed commit of the following:
commit dd5fab4778bb7b67f1eca26a07d430aadd458c6e
Author: Milian Wolff <milian.wolff@kdab.com>
Date: Thu Feb 23 16:19:21 2012 +0100
the "mode" string is now properly parsed, and not only the first
char evaluated. This allows us to do fancy things like
fs.open(file, "rw+"); // read/write/append
Furthermore .read() is adapted such that it will always return the
full file contents, no matter where we have seeked to before (i.e.
by passing + we seek to the end, hence read() would always return
an empty string).
To open a binary file, pass "b" in the mode string to fs.open, e.g.:
fs.open(file, "rb"); // read binary
fs.open(file, "wb"); // write binary
fs.open(file, "rwb+"); // read/write binary, append
alternatively, one can use these shortcuts:
fs.write(file, contents, "b"); // write binary
fs.read(file, "b"); // read binary
Unit tests are extended and the echoToFile.js example fixed (it did not
close the file, which lead to the contents never getting written
on-disk since flush() is never called).
Also note that the FileSystem::open method was cleaned up and at least
one memory leak (if QFile* could not open) was fixed. The code should
now also be more C++-like.
commit 41139951138491459accefab22d48eba7b0b9900
Author: Milian Wolff <milian.wolff@kdab.com>
Date: Wed Feb 15 16:39:23 2012 +0100
use QString instead of QByteArray for raw binary data
QByteArray is simply unusable in JavaScript, since functions like
e.g. window.btoa expect a string. Also there is no sane way to
create a byte array in javascript, as ArrayBuffer e.g. is not
supported by QScript (at least there is no conversion in place).
If we use QString and some custom read/write code this all works
as expected though, we can use window.btoa to base64 encode binary
data and we can create random binary data using String.fromCharCode
also adds a unit test
commit e45673486ef27daf916902153217f9e5001b68c9
Author: Milian Wolff <milian.wolff@kdab.com>
Date: Wed Feb 15 14:39:15 2012 +0100
make it possible to read/write raw/binary files
this adds File::readRaw and File::writeRaw functions,
as well as 'shimmed' versions FS::readRaw and FS::writeRaw
these functions directly use QFile and QByteArray instead of
QTextStream and QString, making it possible to read and write
binary data, e.g. images and such.
execjosh