"Sven Van Caekenberghe"<sven at beta9.be> wrote:
> Thank you for all this work, this is a really interesting project, I am glad you are putting in the effort to bring this to Pharo/Squeak.

Thanks. It's Nicolas who deserves the praise. I'm just trying to help out.

> ...
> I tried to look at one of the others XTFileReadingWritingTest>>#testWriteFromCollectionAt
> 
> 	| data |
> 	data := #[1 2 3 4 5 6 7].
> 	self assert: (self output write: 4 from: data at: 1) = 4.
> 	self assert: (self input read: 4) = (data first: 4).
> 	self assert: (self output write: 3 from: data at: 5) = 3.
> 	self assert: (self input read: 3) = (data last: 3)
> 
> The failure is at the last assertion. If I understand the code correctly, you write to a file in 2 steps (and yes the file contains the data). The input stream is created lazily, after the first write. But it seems strange to me to expect an open reading file stream to see newly written data ? Closing/reopening input works as expected. So you are also testing a particular OS feature here IMHO. Maybe this works on some OS's but it does not seem to work for me (Mac OS X, Cog VM), but other elements might be involved (caching/buffering at various levels, vm, primitives, ..).

The intent of the test certainly is that the data would be visible. It's the same generic test we run across all the terminals. I can't give any authoritative statement whether it should work with files everywhere or not, but I can say that it does work across Linux, Windows and OSX in VW. I think the key aspect of this tests is that it's the same process doing the reading and writing. Actually maybe it's even that it must be the same descriptor. I'll have to take a closer look to see what's going on, but it seems to pass for me with Pharo (1.1.1 or 1.2, cog or standard VM) on Linux. I can test it on Windows as well, but I don't have OSX available for this. Does anyone know if it is reasonable to expect it to work on OSX ? I'm certainly not bent on keeping the test that way, our primary goal is to test the API on all terminals. But if it is meant to work this way even on files, then we probably should keep it that way.