1) I haven't forgotten about Liam's IOStream patch, and I'm still thinking about it. Just a few comments:
- stdin/stdout aren't necessarily connected to files - they could be sockets or pipes - so calling them FileStreams is a bit of a misnomer. Also, I'm trying to consider how the various byte array input / output streams are going to fit into the picture.
- I'm also thinking about how file read operations are going to work in a mult-threaded context. Reading from a file into a buffer is probably going to go like this: 1) pin the buffer in memory. 2) Tell the GC that that it's OK to do collections while we're waiting for the i/o to complete. 3) Do the actual read, 4) Tell the GC that the read is done, and that it should only do collections when we say it's OK, and finally 5) unpin the buffer. The main idea is that the garbage collector should be able to do collection cycles while we're waiting for the i/o to complete. Note that none of these issues should affect the current design at all, I'm just thinking about the future.
- For reading lines terminated by newline, it's a shame that we can't use the underlying fgets() function, which is likely to be much more efficient and will take advantage of buffering in the FILE object. Unfortunately, fgets doesn't support universal newlines.
- File paths: I'm in the Python / C# camp that believes that a file path is just a plain old string (with a bunch of utility functions for operating on them), vs. the Java camp that says that a path is a special kind of object (class File). Note that I feel somewhat differently when it comes to URLs, since they are much more complicated entities.
2) I have a fix for the UpCast bug, but I haven't pushed the changes out yet, mainly because I haven't written tests for it.
3) You may notice that there's a new option in the top-level CMakeLists.txt for building tartc and tartln with clang, if it's available. Everything compiles OK (and clang is both stricter and has better diagnostics than gcc.) Unfortunately, there's some weird runtime incompatibility - it crashes when the clang-compiled tartc tries to call into the gcc-compiled LLVM libraries. I haven't had too much time to think about this.
4) I still have the annoying problem of all Tart unit tests crashing on 32-bit OS X systems. This is difficult to debug due to the fact that DWARF stlll isn't working on those platforms either.
5) I also have not checked in a new feature whereby the compiler knows where the standard libraries are installed, and automatically adds them to the list of module import paths unless -nostdlib is specified on the command line.
--
-- Talin
No comments:
Post a Comment