Hi Alistair, 2018-05-09 16:06 GMT+02:00 Alistair Grant <akgrant0...@gmail.com>: > > > On Wed., 9 May 2018, 13:49 Sven Van Caekenberghe, <s...@stfx.eu> wrote: >> >> >> >> > On 9 May 2018, at 13:41, Thierry Goubier <thierry.goub...@gmail.com> >> > wrote: >> > >> > 2018-05-09 13:14 GMT+02:00 Sven Van Caekenberghe <s...@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. >> >> Yes, they will have to be ported. >> >> If it were me (but I haven't looked at the code) I would not inherit from >> those classes, but from a simpler Stream class, possibly even none. The >> stream API is actually quite small (or it should be). >> >> Inheritance is an implementation technique, inheriting from a complex >> class can be hard, unless the superclass was really designed with that >> purpose. >> >> All this, IMHO. > > > > I agree that these classes will need to be ported, just a little food > for thought: > > I believe OSProcess is currently common between Squeak and Pharo - this > porting will require that OSProcess is forked for Pharo, so the two > implementations will start to diverge unless someone actively keeps them > in sync. (Please don't read this as a negative judgement, it is > just a statement of my understanding of the situation).
I agree with your statement. Since I need OSProcess, I will probably undertake this, even if I don't see exactly how this would be done in the context of the development process of OSProcess today. The easiest would be to have a compatibility package loaded for OSProcess on Pharo > 70XXX; the hard part will be whether that XXX will be clearly known. > There are a number of plugin primitives that Dave added to OSProcess > because FilePlugin didn't meet his requirements. Some of the recent > changes made to FilePlugin reduce the need for additional primitives (it > is possible to connect to an existing file or file descriptor, #atEnd > works for pipes), and I think there are additional enhancements that can > be made which would reduce the number even further (mark files as > non-blocking) (but I haven't looked in to it properly and would want to > get Dave's input first). Agreed, and, yes, I've been loosely following what you were doing in this area. Anything that can improve Pharo robustness in that area will be appreciated, I had far too many lockups in the past to be happy with it. I'm a bit worried about VM changes now; I've played a bit too much with downloading my own VM from bintray for compensate for stability issues of the blessed VMs, so I'm not sure to be able to track custom OSProcess configurations depending on the presence of specific primitives in the VM... sort of like running a configure script for compiling a C library. Regards, Thierry > > Cheers, > Alistair >
