On Tue, Jun 07, 2016 at 01:22:04PM +0200, Thierry Goubier wrote: > 2016-06-07 11:47 GMT+02:00 Peter Uhnak <i.uh...@gmail.com>: > > > It's strange that I was using GitFileTree over OSProcess for a long time > > without issue and yet every time I tried to use OSProcess directly I had > > this locking up. > > > > > Yes. This is a bit worrying; the low-level OSProcess call was a bit of a > stopgap while waiting for either OSProcess or the vm to sort the underlying > issue (which is more significant than just my use); that it locks up under > normal use is not good and should be reported. > > I allways considered GitFileTree to be a heavy hitter on OSProcess, running > hundreds of external commands to load a complex project, so that if I would > lock up, it wouldn't be a normal pattern of use. > > > > > > > So I am asking polite to the pharo developers team if there are plans to > > > provide a stable solution for calling external programs as described. > > > > > > My production system will be a windows system, so I need this for > > windows, > > > too. > > > As far as I understand, the new OSSubprocess is (currently) only for > > unix. > > > > Yes, there's ProcessWrapper for Windows. > > > > An alternative approach might be to use direct FFI calls, e.g. > > > > MyClass class>>system: > > system: command > > "Perform OS system() call." > > > > ^ self ffiCall: #(int system #(char * command)) module: LibC > > > > And then you can do MyClass system: 'cp a.pdf b.pdf'. > > > > Although it still locks up my image from time to time… but at least order > > of magnite less. > > > > Than GitFileTree or OSProcess? Still, you get lockups... which isn't good.
No, GitFileTree never locked up my image. This was always my use. Peter
