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