Hi Alistair, On Fri, May 11, 2018 at 03:09:20PM +0200, Alistair Grant wrote: > Hi Dave, > > On 11 May 2018 at 03:58, David T. Lewis <[email protected]> wrote: > > 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. > > Are the two primitives that were added to the VM a couple of months > ago (primitiveConnectToFileDescriptor & primitiveConnectToFile) enough > to allow AttachableFileStream to be removed?
No, I was referring only to the actual file stream hierarchy. Long ago, I tapped into StandardFileStream with some subclasses that do useful things for OSProcess. That is clearly a hack, and I'm sure we could do better. Having said that, I have not looked at Pharo 7 yet so maybe I don't know what I'm talking about ;-) > > Also, borrowing primitiveSQFileSetNonBlocking from OSProcess I was > able to open a named pipe and read from it in a non-blocking way using > the standard Pharo 7 file stream (BinaryFileStream). I'd like to look > at getting AsyncFile working with it, but that's a long way down the > ToDo list. Good, primitiveSQFileSetNonBlocking certainly should work for that, and I'm glad to hear that it does. Dave > > HTH, > Alistair
