On Wed, Dec 23, 2015 at 7:46 PM, [email protected] <[email protected]> wrote: > > Pharo follows Smalltalk which uses a global object named Smalltalk which in > fact is an instance of SmalltalkImage, confusing if you ask me.
I also have felt that same impedance mismatch in the naming, but I thought the accessors were deliberately moved to the instance side to help (maybe later) to minimise global state. So I am guessing that adding class-side accessors is a step backwards - but maybe System class could provide a singleton instance of itself. cheers -ben > > I would add a simple class named System which have class-side accessors for > static global things like > > image => links to the old Smalltalk > stdin > stdout > session > environment for ENV vars > workingDirectory accessing the process working directory $PWD > 'pid' > > That's a very easy thing to do, but IMO it will help anybody coming from > outside smalltalk to easily find these things. Probably there are more > things that would fit here. > > > I'd like to have that. > > The discussion involved Camillo who was very into these topics. His > Pinocchio work seemed to have contributions that can be useful of the CLI > support for Pharo. > > Phil > >> >> >>> >>> and just btw, mildly interesting is using sockets rather than pipes >>> for interprocess communication [l] >>> >>> [j] >>> http://stackoverflow.com/questions/3884103/can-popen-make-bidirectional-pipes-like-pipe-fork >>> [k] http://stackoverflow.com/questions/6743771/popen-alternative >>> [l] >>> http://stackoverflow.com/questions/25161377/open-a-cmd-program-with-full-functionality-i-o/25177958#25177958 >>> >> >> Thanks. I will check that on a second step ;) >> >>> >>> > >>> > 2) We believe that there is a large number of OSProcess users that use >>> > OSProcess only for executing OS commands AND popen() approach would be >>> > more >>> > than enough (we will do a survey about this). So, a very simply >>> > solution via >>> > FFI for these users rather than having all OSProcess, Command Shell, >>> > the >>> > plugins etc, may be worth. >>> > >>> > What do you think? >>> > >>> >> >>> >> Now, given some of the difficulties seen when dealing with external >>> >> processes, I'd be wary of the "async" side of things. Random failures >>> >> seemingly linked to signal loss are certainly not something I'd like >>> >> to >>> >> debug. >>> >> >>> > >>> > Indeed, it won't be easy I guess. But sometimes the process you execute >>> > may >>> > take quite some time and blocking the VM for that period is not a good >>> > choice. So... what would you prefer to solve that? Do you prefer >>> > image-based >>> > pooling as OSProcess does when IOPlugin is not used? >>> >>> >>> How much might your work overlap with the Threaded FFI project for >>> Cog?... >>> ..."The Cog VM is single-threaded, providing green threads to the >>> Smalltalk level, as do most Smalltalk VMs. There is a prototype >>> subclass of the CoInterpreter, CoInterpreterMT, which provides a >>> Python-like multi-threaded VM where any number of threads can share >>> the VM with only one running the VM at any one time. This uses an >>> extremely simple low-level scheme for releasing and re-acquiring >>> ownership of the VM designed by David Simmons. This results in any >>> and all FFI calls being non-blocking since there is such a low >>> overhead to making a non-blocking FFI call that all FFI calls can be >>> non-blocking. Eliot has worked on this, implementing the prototype >>> and the reentrant FFI plugin it requires. But this needs to be >>> revived. It would be a really powerful enhancement." >>> >> >> Well, Eliot said I may need to give a hand to them in order to finish the >> Threaded FFI. However, I am still not 100% certain if the threaded FFI calls >> to read from pipes would be worth. Eliot said that yes. Anyway, once I have >> the first version working I will digest this and goes to the next level and >> see how I can make things better than polling, if polling proves to be a >> problem. >> >> >>> >>> cheers -ben >>> >>> P.S. Just another article warning against mixing fork and >>> multiple-threads (which it seems posix_spawn may avoid)... >>> >>> http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them >>> >> >> Thanks for the reference. >> >> Cheers, >> >> -- >> Mariano >> http://marianopeck.wordpress.com > >
