On Sun, 23 Jan 2011, Chris Cunnington wrote:

>
> It looks to me as though you've moved the three handles from 
> StandardFileStream to FileStream.
> Could you perhaps give an example or two?
>
> Since playing with MicroSqueak I've been staring with covetous eyes at 
> Interpreter>>print: which is nothing more than printf(). I want to be able to 
> print output not to a log file, but back to the terminal. MicroSqueak does 
> that with #primitiveExitToDebugger (which uses #printCallStackFrom:).
>
> I figure printf() is a great candidate for a simple FFI hack. I could create 
> a method called #terminal: (instead of #log:).
>
> I'm haunted by the idea of creating a command line Squeak interface. (FWIW 
> the input would be passive: a drop folder. Create a process with 
> FileDirectory to see if anything has been added to a directory every five 
> seconds. It has? Stream it up to Compiler evaluate:.) Then a person could 
> write a script in vi, cp it to the drop folder, and know it was working in a 
> headless image by the output sent back to terminal by #terminal:.
>
> Any examples to show how to use what you've just created would be greatly 
> appreciated.

It does the same as Eliot's original implementation with the following 
differences:
- The API (and the implementation) is in FileStream
- You get the same object if you use "FileStream stdin", 
"StandardFileStream stdin" or "MultiByteFileStream stdin" to access the 
streams.
- The streams are encoded using the platform's default TextConverter by 
default. This means that the class of the streams is MultiByteFileStream 
in the default case.
- There's automatic line end conversion installed by default: crlf for 
windows, lf for other platforms (as discussed earlier).
- You can turn on/off the text encoding and the line end conversion by 
changing the value of the "Encode and decode the contents of stdio files."
preference. This will change the class of the streams to 
StandardFileStream. This is useful when you want to access the raw
streams.

Due to the migration code, images shouldn't break if they're already using 
StandardFileStream based stdio streams. Users of CrLfFileStream based 
stdio streams may experience problems and have to manually fix their code 
and probably the streams too after (or before) updating.

Just like with any other FileStreams, concurrent access to the stdio 
streams is not supported.


Levente

>
> Chris
>
>
>
>
>
>
>