On Wed, May 09, 2018 at 01:41:47PM +0200, Thierry Goubier wrote:
2018-05-09 13:14 GMT+02:00 Sven Van Caekenberghe <sven@stfx.eu>:
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