"Sven Van Caekenberghe"<[email protected]> 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.

Reply via email to