Hi Sean
On Fri, May 18, 2018 at 9:49 PM, Sean P. DeNigris <s...@clipperadams.com>
wrote:
> Guillermo Polito wrote
> > If you have any issues…
>
> IMHO the biggest issue is incompatibility with OSProcess. This seems not to
> matter when one is loading Project A depending on OSSP in a clean image,
> but
> the second one tries to load Project A into an image where Project B
> already
> depends on OSP - KABOOM! Game over.
>
Well, I cannot say much about why this happens. I've seen it happening, but
I try not to depend on projects using OSProcess in that case.
Can we also say the same the other way around?
If we have OSSubprocess loaded and I download a project using OSProcess,
does it break the same?
I understand that the incompatibilities bother, but putting all the fault
in OSSubprocess and not in OSProcess seems not fair :).
Maybe both should be modified to be compatible? Dunno...
> On a more philosophical note, I never understood why OSSP was created in
> the
> first place since we have OSP;
I cannot answer this, I'll let Mariano or somebody from the Pharo board on
this one.
> and especially why the API is different,
> making switching more difficult.
I found OSProcess API particularly bad. It's never clear to me whether to
use OSProcess, PipeableSomething or CommandWhatever (I don't even remember
the names of the things that **do work** and I have to look them every
time).
To be fair, to me even sometimes OSProcess is too verbose. Most people only
want to do
output := OSProcess executeCommand: 'ls'.
Blocking. Recovering stdout. And that's all.
So in that sense, I think that letting us move on and rethink the API is
not bad at all...
Then, we can think on providing some compatibility layer to help people in
migrating.
So, if anyone want to take action on this point...
I'm sure there was a good reason to do
> OSSP, but it might be helpful to clarify in the docs (so tradeoffs between
> OSP and OSSP can be understood by prospective users).
>
Well from a technical point of view, if you want to choose from one or
another today I'd say:
- OSSP is written mostly in FFI, what means that it is easier to modify
and ship.
- I'm sure OSSP works: it has way more tests and we are using it for
several projects ourselves. (Please notice I do not say that OSP does not
work, I say I have no way to be sure that it works because tests do not
run). So we are eating our own food:
- we use them to run iceberg tests
- pillar is using it to compile pdfs
I've put myself quite some effort to have a working CI, with stress
tests, 64bits. I've just tried to run OSP tests and they do not even run in
Pharo because they use FileDirectory (and even latest version is updated to
work on Cuis)... Having a compatibility layer to make such a project run on
squeak, cuis and Pharo looks like a gigantic task for a project that seems
so core to me.
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>
>
--
Guille Polito
Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille
CRIStAL - UMR 9189
French National Center for Scientific Research - *http://www.cnrs.fr
<http://www.cnrs.fr>*
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
