2 May
2016
2 May
'16
10:05 a.m.
OSProcess is used for providing a quick way to link to VerveineJ in
MooseImportFromVerveineJWizard. If we port this code to OSSubprocess, we
can adopt it. Any takers?
Moose also depends on ZeroConf, which uses OSProcess through CommandShell.
Although this is quite confusing… ZeroConf depends on CommandShell but it
loads just the ConfigurationOfCommandShell, not the package; instead it
uses OSProcess directly (with specifying dependency on OSProcess).
If we can't have coexistence then we are introducing fragility into the
system. As a user loading a package X you have no way of knowing if it will
break unless you investigate the whole dependency tree.
So maybe both OSProcess and OSSubprocess should at the very least
#preLoadDoIt: check whether the other is in the system and refuse to
install, or ask the user for confirmation?
On Sat, Apr 30, 2016 at 6:33 PM, Thierry Goubier <thierry.goubier(a)gmail.com>
wrote:
Le 30/04/2016 17:53, Peter Uhnák a écrit :
On Sat, Apr 30, 2016 at 5:14 PM, Thierry Goubier
<thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
Hi Peter,
Le 29/04/2016 18:22, Peter Uhnák a écrit :
Welp apparenty GitFileTree has already switched to OSSubprocess…
which
means that since I use Moose I can no longer commit my code…
which is
fun. -_-
For Pharo 5.0, I've pushed both #dev and #stable versions of
GitFileTree which will reuse either OSProcess or OSSubprocess if it
is already loaded and will avoid reloading OSSubprocess over
OSProcess.
Could you try with Moose to see if it solves the problem you have?
Just tell how it goes.
This indeed solves the Moose + Git problem, thanks!
It took me a lot longer to get all the Baselines/Configurations aligned
properly (as well as testing and tuning the SmalltalkCI configuration) than
writing/recovering the code.
Git makes child play of recovering a years' old version of a method :)
Although the underlying problem still remains… which I don't understand,
so I guess I will have to take a look to learn a
bit.
Because imagine a year from now someone else comes along with a new
library, or OS(Sub)Process goes through a backwards-incompatible rewrite
into OS(Sub)Process2 and suddenly we are where we started...
Well, there isn't much we can do about that.
Pharo and some of the underlying components change over time, and stuff
needs to be maintained/adjusted to make the transition. Making APIs
perfectly stable contradict the ability of Pharo to evolve.
Thierry
Peter
Thierry
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev