-
Notifications
You must be signed in to change notification settings - Fork 326
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restructuring for File.read #3390
Conversation
6dfa047
to
333eee3
Compare
853341b
to
bc1e221
Compare
60fabec
to
deedea3
Compare
distribution/lib/Standard/Table/0.0.0-dev/src/Io/File_read.enso
Outdated
Show resolved
Hide resolved
@@ -153,14 +238,67 @@ public static String from_codepoints(int[] codepoints) { | |||
return new String(codepoints, 0, codepoints.length); | |||
} | |||
|
|||
private static CharBuffer resize(CharBuffer old) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DRY?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
felt the generic solution wasn't very clean:
private static <T extends Buffer> T resize(T old, IntFunction<T> allocate, BiConsumer<T, T> put) {
int n = old.capacity();
int new_n = 2*n + 1;
T o = allocate.apply(new_n);
old.flip();
put.accept(o, old);
return o;
}
as Buffer doesn't have put
or allocate
. But happy to switch to generic if you think better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would actually argue for having the two specializations.
Maybe it is premature optimization, but feels like having ByteBuffer
or CharBuffer
directly can allow the JVM to statically resolve the methods to be used whereas having the closures it may not realise this is possible, at least that quickly. And it may be important because encoding is quite a primitive operation, which can work with quite big amounts of data and so performance is valuable here.
But if @hubertp you think it shouldn't matter much (I don't have enough JVM experience to judge if the overhead of closures here is noticeable or not), then I agree that a generic solution is more elegant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
don't think it will have any performance overhead as just method references being passed - does make it slightly cleaner to only have the method once.
The Buffer
class is ancient so not thought about for this stuff!
4b06815
to
8da4ac3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but some changes are needed.
distribution/lib/Standard/Base/0.0.0-dev/src/Data/Text/Encoding.enso
Outdated
Show resolved
Hide resolved
distribution/lib/Standard/Base/0.0.0-dev/src/Data/Text/Encoding.enso
Outdated
Show resolved
Hide resolved
distribution/lib/Standard/Base/0.0.0-dev/src/Data/Text/Extensions.enso
Outdated
Show resolved
Hide resolved
distribution/lib/Standard/Table/0.0.0-dev/src/Io/File_Format.enso
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great now, as long as tests go through should be good to go :)
Restructuring tests.
Change log
Example update
Co-authored-by: Radosław Waśko <[email protected]>
Co-authored-by: Radosław Waśko <[email protected]>
Add UTF 16 and Windows tests
81d77d9
to
16d67ac
Compare
Pull Request Description
Text.bytes
,Text.from_bytes
with Encoding supportFile.read
toFile.read_text
File.write
toFile.write_text
File.read_text
andFile.write_text
Checklist
Please include the following checklist in your PR:
./run dist
and./run watch
.