Stdin/stdout/stderr support

 
I have implemented direct support for std streams:

http://squeakvm.org/svn/squeak/branches/olpc/platforms/Cross/plugins/FilePlugin/sqFilePluginBasicPrims.c

This will catch filenames like "/dev/stderr" and connect the real  
stderr instead (also preventing to close these).

This file pattern is in usage already, e.g.

http://lists.squeakfoundation.org/pipermail/beginners/2007-April/002268.html

In OLPC we used this to log errors (we added FileStream class>>stderr  
etc.) because SqueakDebug.log is in an unaccessible place, but using  
the /dev/stderr symlink is broken by the security architecture, so I  
need to access the actual stderr.

Any objections to make this go into the trunk Cross platform dir?

- Bert -

 
2008/8/29 Bert Freudenberg <[hidden email]>:
yes. In windows you can't open '/dev/stderr'
but you can open it if you using an stdio library. like fopen(...)

In libc they are defined as a 'well-known' file handles = 0,1,2 which
is stand for stdin, stdout and stderr correspondingly.

And i'm completely with you. Squeak should have support for standard
input/output streams.

> - Bert -
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

 

Am 29.08.2008 um 20:15 schrieb Igor Stasenko:

That file is not used on Windows.

- Bert -

 
2008/8/29 Bert Freudenberg <[hidden email]>: i mean that its better to use file handles which is available on all
platforms. and they actually should be open at the process startup


--
Best regards,
Igor Stasenko AKA sig.

 
Am 29.08.2008 um 22:18 schrieb Igor Stasenko:
>
> i mean that its better to use file handles which is available on all
> platforms. and they actually should be open at the process startup

Maybe you misunderstood my patch then.

If the image tries to open a file named "/dev/stderr" then the VM now  
actually returns the pre-opened stderr rather than opening the named  
file. So this is independent of whether a file named "/dev/stderr"  
actually does exists or not, and it uses the proper file handles.

- Bert -

 
On Fri, Aug 29, 2008 at 10:38:18PM +0200, Bert Freudenberg wrote:
Yes this will work, but I agree with Igor.

This approach seems too platform-specific to be included in ./Cross.
It relies on file path name conventions that apply to some (not all)
Unix systems, and that do not make sense on other platforms. It introduces
hidden and undocumented behavior (I will not allow you to close the file
stream if you happen to have referred to it by some particular path name).

Given that folks agree that the concept of stdin/stdout/stderr should
be supported in Squeak, then there is no reason not to implement it in
a way that makes sense on all platforms.  A set of three optional primitives
is sufficient, and will provide the same access mechanism regardless of platform.

For example, here is the Windows implementation from OSPP:

/* Answer a two element array containing the sqFile data structure representing
        standard output stream for my OS process, and a flag (true or false) to indicate
        whether the sqFile data structure contains a valid HANDLE. If no standard output
        stream is available for this OS process, the sqFile data structure will contain an
        invalid HANDLE value, which will result in failures on subsequent accesses. */

EXPORT(sqInt) primitiveGetStdOutput(void) {
    sqInt thisSession;
    HANDLE invalid;
    sqInt result;
    HANDLE handle;
    SQFile *file;
    sqInt fileOop;

        thisSession = sessionIdentifierFrom(interpreterProxy->stackObjectValue(0));
        invalid = INVALID_HANDLE_VALUE;
        result = interpreterProxy->instantiateClassindexableSize(interpreterProxy->classArray(), 2);
        fileOop = interpreterProxy->instantiateClassindexableSize(interpreterProxy->classByteArray(), fileRecordSize());
        file = interpreterProxy->arrayValueOf(fileOop);
        handle = GetStdHandle(STD_OUTPUT_HANDLE);
        if (handle != invalid) {
                interpreterProxy->stObjectatput(result, 2, interpreterProxy->trueObject());
        } else {
                interpreterProxy->stObjectatput(result, 2, interpreterProxy->falseObject());
        }
        file->file = handle;
        file->sessionID = thisSession;
        file->writable = 1;
        file->lastOp = 0;
        interpreterProxy->stObjectatput(result, 1, fileOop);
        interpreterProxy->pop(2);
        interpreterProxy->push(result);
}

 
2008/8/30 David T. Lewis <[hidden email]>:
pushRemappableOop(result)

>        fileOop = interpreterProxy->instantiateClassindexableSize(interpreterProxy->classByteArray(), fileRecordSize());

result = popRemappableOop();

Good, but maybe it can be more simplier?
Just return a valid file handle on success, or fail primitive if not.
Also, it can be a single prim (primitiveGetStdFileHandle) , with
additional argument indicating which std stream to return e.g.
0 - for stdin
1 - for stdout
2 - for stderr


--
Best regards,
Igor Stasenko AKA sig.

 
On Sat, Aug 30, 2008 at 04:43:46PM +0300, Igor Stasenko wrote:
>  
> 2008/8/30 David T. Lewis <[hidden email]>:
> >
> > For example, here is the Windows implementation from OSPP:
> >
>
> Good, but maybe it can be more simplier?
> Just return a valid file handle on success, or fail primitive if not.

Sure. That's what I did for the Unix flavor, and I don't recall why
I did it differently for win32. I think that it was a convenient way
to tell whether the Windows console was open or not.

> Also, it can be a single prim (primitiveGetStdFileHandle) , with
> additional argument indicating which std stream to return e.g.
> 0 - for stdin
> 1 - for stdout
> 2 - for stderr

I preferred the three separate methods versus "magic numbers", but
either way is fine.

One other thing I might mention. The stdin stream is dangerous because
it will hang the image on a blocking read if no data is available.
For OSPP I added primitives to set nonblocking I/O, and this would
need to be addressed if stdin access is made part of the normal VM.

Dave

 

Am 31.08.2008 um 22:36 schrieb David T. Lewis:


Also, the standard behavior is to seek to the beginning of the file.  
For stderr and stdout this should not happen.

I'd prefer a single primitive instead of three (which admittedly is  
more clean than a magic filename).

- Bert -

 
On Sat, Aug 30, 2008 at 04:43:46PM +0300, Igor Stasenko wrote: Here is an implementation that works on Unix, Mac OS X, and Windows.
It's basically taken from OSProcessPlugin, with the Windows primitives
cleaned up per your (sig) suggestion. I kept separate primitives
for the three streams though, just because I personally prefer it
that way (it's easy to change of course).

>From the preambles:

'From Squeak3.9 of 7 November 2006 [latest update: #7067] on 7 September 2008 at 9:51:03 am'!
"Change Set: FilePluginExtension-dtl
Date: 7 September 2008
Author: David T. Lewis

FilePlugin extensions to support access to stdio streams, based on OSPP
implementation.  The added primitives are #primitiveGetStdOutHandle,
#primitiveGetStdErrHandle, and  #primitiveGetStdErrHandle. Unix, OS X,
and Windows platforms are supported (or RiscOS, the default FilePlugin
is used, and these primitives are not available).

The extensions are implemented in subclasses of FilePlugin. No external
support code is required. If a recent version of VMMaker from SqueakSource
is used, the VMMaker tool will automatically select the correct class for
translation on Unix, Mac or Windows (otherwise the correct class must be
selected manually in the VMMaker tool).

On Windows, the standard streams are associated with a console. Two
additional primitives are provided for Windows to open and close the console.
Some modification to the win32 support code will be required to allow
registration of the standard input/output/error handles. For demonstration
purposes, the registry may simply be disabled in the support code
(sqWin32HandleTable.h)."!

'From Squeak3.9 of 7 November 2006 [latest update: #7067] on 3 September 2008 at 6:08:39 am'!
"Change Set: StandardStream-dtl
Date: 3 September 2008
Author: David T. Lewis

Provide access to stdin, stdout, stderr based on platform specific extensions
to FilePlugin.  The primitives are similar to those in OSProcessPlugin."!

- Dave