Having taken a look at this briefly (as it was put on the Trello), there is some layering of abstraction over ports that makes it hard to do this efficiently in the R3-Alpha code. Basically the read requests go out and then come back with a block of data, perhaps limited to some size. For a feature like this you need some kind of buffering or chunking, as the OS itself only gives you back blocks.
Doing it inefficiently--e.g. reading the whole file and then breaking it into lines, and then extracting the data--is certainly easy but likely to dissatisfy many people who would use the feature (and they could have done that themselves).
Updating the layer that implements the reading so that it did something like take a parameter which was the character (or characters) you want to look for to stop it from reading would be possible. The code could be split into multiple requests in the A_READ action on files at a higher level, though this would add complexity.
The Ren-C answer on this is likely that the "REBREQ"-based I/O system ("Rebol requests" to devices) needs to be replaced with something else, and a bridge built to maintained codebases for basic I/O--more like what Node.JS did. So investing in improving the protocol as it stands is not a priority.
But if a motivated individual were to address it in the existing code, that would probably be a good thing. If doing it by reading the whole file and breaking it into lines would be a "good enough for now" situation for many people, someone could do that without too much effort.
Submitted by: Hostilefork
(Note: This issue comes from Ashley Truter. It was added to the Ren-C Trello, but is more appropriately put in the Rebol3 issues DB.)
Test file
%foo.txt:If you READ/LINES/PART on it, then it interprets the part count as characters:
Desired behavior is to assume you want the count to be of lines, so that should be:
Imported from: https://github.com/rebol/rebol-issues/issues/2255
Comments:
Having taken a look at this briefly (as it was put on the Trello), there is some layering of abstraction over ports that makes it hard to do this efficiently in the R3-Alpha code. Basically the read requests go out and then come back with a block of data, perhaps limited to some size. For a feature like this you need some kind of buffering or chunking, as the OS itself only gives you back blocks.
Doing it inefficiently--e.g. reading the whole file and then breaking it into lines, and then extracting the data--is certainly easy but likely to dissatisfy many people who would use the feature (and they could have done that themselves).
Updating the layer that implements the reading so that it did something like take a parameter which was the character (or characters) you want to look for to stop it from reading would be possible. The code could be split into multiple requests in the A_READ action on files at a higher level, though this would add complexity.
The Ren-C answer on this is likely that the "REBREQ"-based I/O system ("Rebol requests" to devices) needs to be replaced with something else, and a bridge built to maintained codebases for basic I/O--more like what Node.JS did. So investing in improving the protocol as it stands is not a priority.
But if a motivated individual were to address it in the existing code, that would probably be a good thing. If doing it by reading the whole file and breaking it into lines would be a "good enough for now" situation for many people, someone could do that without too much effort.