On Wed, May 09, 2018 at 01:41:47PM +0200, Thierry Goubier wrote:
> 2018-05-09 13:14 GMT+02:00 Sven Van Caekenberghe <[email protected]>:
> > You mean you made a subclass of StandardFilestream yourself ?
>
> There are a few subclasses of StandardFileStream in OSProcess:
> AttachableFileStream, AsyncFileReadStream and
> BufferedAsyncFileReadStream. They will need to be ported.
>
> > If yes, can you describe briefly why you did so ?
>
> As far as my analysis go, AttachableFileStream refers to and
> manipulates the underlying ioHandle of a unix pipe stream,
> AsyncFileReadStream interacts with the asynchronous io extensions of
> the vm to observe that io handle, and a BufferedAsyncFileReadStream
> add a thread-safe, buffered, blocking API for smalltalk processe on
> top.
That's right.
I'm sorry I have not been keeping up with this discussion, but one thought
that comes to mind - the AttachableFileStream hierarchy is something that
would better be replaced by some kind of delegation. It was a hack that I
did a long time ago to allow OSProcess to work without modifying the base
image. But since then, we have added multibyte characters and streams, and
we have different file and stream models in Squeak/Pharo/Cuis (Cuis is an
important target platform from my POV).
I don't have a solution in mind, my sense is that if we find a way to make
AttachableFileStream go away, then that solution would very likely make
it unnecessary to develop and maintain separate Squeak/Pharo/Cuis forks
moving forward.
Note that the only fundamental thing that AttachableFileStream does is this:
AttachableFileStream class>>name: aSymbolOrString attachTo: anIOHandle
writable: readWriteFlag
"Create a new instance attached to anIOHandle, where anIOHandle
represents an open IO channel. For write streams, this represents two
Smalltalk streams which write to the same OS file or output stream,
presumably with interleaved output. The purpose of this method is to
permit a FileStream to be attached to an existing IOHandle, such as
the IOHandle for standard input, standard output, and standard error."
^ (super basicNew
name: aSymbolOrString
attachTo: anIOHandle
writable: readWriteFlag) initialize
The method comment refers to "IOHandle" which was another old project I was
doing, but IOHandle basically means the #fileID field of a file stream.
If it was just AttachableFileStream that needed to be refactored out of
existence,
it would be easy. But I later added quite a bit a behavior to
BufferedAsyncFileReadStream
and I'm not sure what might be needed to make this work properly.
Sven, I suspect that you are the most knowledgeable in this area, so any
suggestions would be welcome.
Apologies once again for not keeping up with this, but I am glad to see the
discussion.
Dave
