On Tue, Jun 07, 2016 at 01:22:04PM +0200, Thierry Goubier wrote:
2016-06-07 11:47 GMT+02:00 Peter Uhnak <i.uhnak@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