Smalltalk › Squeak › Squeak - Dev

Stdio updates

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Chris Cunnington

Stdio updates

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.

Chris

David T. Lewis

Re: Stdio updates

On Sun, Jan 23, 2011 at 11:00:18PM -0500, Chris Cunnington wrote:
>
> 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:).

If you are using unix/linux, then you can just open a file stream
on /dev/tty. Be sure to flush after writes.

You also have these:

OSProcess class>>debugMessage: aString
"Print aString on standard output. The debug message is prefixed with the
identity of the process in which the method is being evaluated, and the
identity of the object which received the message. Useful for debugging
timing or deadlock problems."

OSProcess class>>trace
"Print the sender's context on standard output. The debug message is
prefixed with the identity of the process in which the method is being
evaluated, and the identity of the object which received the message.
Useful for debugging timing or deadlock problems."

OSProcess class>>trace: debugMessageString
"Print trace information followed by a debug message"

> I'm haunted by the idea of creating a command line Squeak interface.

ExternalCommandShell class>>start
<http://wiki.squeak.org/squeak/6023>

Dave

Levente Uzonyi-2

Re: Stdio updates

In reply to this post by Chris Cunnington

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
>
>
>
>
>
>
>

Eliot Miranda-2

Re: Stdio updates

On Sun, Jan 23, 2011 at 8:34 PM, Levente Uzonyi <[hidden email]> wrote:

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.

Excellent!

Thanks, Levente.

Levente

Chris