> > A cleaner Pharo will help there. > > To be frank, I found later Pharo releases not inspiring. Bigger, bigger and > bigger with added code, protocol changes, and bugs at will. It is becoming > too complicated for a hobby use of it.
It’s quite a moving target with so many fundamental changes (GIT being one, Bootstrap another huge one). But I have the opposite impression (of course I don’t have to maintain a big project like yours - I wouldn’t say you’re the hobby user :) ). But I really find P6 more consistent than what I used to try in the past (last squeaks up to 3.9 and firsts pharo). And the bootstrapping of P7 will (I think) finally solve big image issues (allowing to build cleaner distributions). I believe it will be a huge step forward. At least for me and especially to convince others to try out Pharo. I just dream of having a network of small images running and communicating, eventually accessed and programmed by a larger developper image (with TelePharo). I haven’t tried the bootstrap yet but sure in the future. Plus I have the impression Morphic mess is about to be solved. What’s more problematic to me (as I guess for newcomers) is to find the ‘good’ packages'. For instance, I’m still puzzled when I have to choose between OSProcess and OSSubprocess (and sometimes depending on loaded projects, we need both…). > > I decided I will not finish porting DrGeo to P6 or P7, and it will likely die > with P3. > > Pharo should have been clean up to the bones before adding. It was the > initial moto, no? I have the (naive) impression that bootstrap will help a lot here, so be patient ;). Maybe porting to P7/P8 will be more appropriate. What I would like, is a kind of notation for package to know its state and usage possibilities. We see for instance that several I18N exists already (but not 100% integrated hence this post)... My 2 cents, Cédrick OT question: Would it be possible in the future to generate a bootstrap image of a given program from a bigger developer image containing running program (like if running tests where activating all code dependancies ? … like tracing usage… I guess this is not trivial at all ! I guess this is particularly difficult to trace all use cases and as dynamically bound, it sure must be hard). > > > Le 10/11/2017 à 11:14, Marcus Denker a écrit : >> It would be nice if someone who uses it would take the lead >> so we can improve the default that is shipped with Pharo. > > -- > Dr. Geo > http://drgeo.eu > > >
