> On 17 Aug 2017, at 17:37, Alistair Grant <[email protected]> wrote: > > On Thu, Aug 17, 2017 at 11:54:57AM +0200, Pavel Krivanek wrote: >> >> >> 2017-08-17 10:44 GMT+02:00 Torsten Bergmann <[email protected]>: >> >> Hi, >> >> even when contributing to Pharo 7.0 is still very very cumbersome I was >> able >> to sort out most of the problems and contribute already a few smaller >> things. >> >> Unfortunately there is not much communication on what is currently in the >> pipe >> or planned on easing the process - which can easily lead to the impression >> that we do not really move or slow us down. >> >> I know step by step it goes and at least we have again the build process >> rolling >> https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is- >> starting-to-roll-for-real/ >> >> Nonetheless one of my PRs was already integrated and the integration of my >> WebBrowser >> package is still in the pipe (https://github.com/pharo-project/pharo/pull/ >> 193) >> >> The descriptions from Guille helped me - but there are still things I need >> answers to: >> >> 1. Will or is it still possible to automatically update" an image in >> Pharo >> 7 >> or in the future? >> The World menu entry "System" -> "System update" has been removed? >> >> Is this temporary of will it return once we know how it could be done >> again? >> >> >> You can update your image in Iceberg by switching to the updated #development >> branch and then to reload all packages. In most cases it will probably work >> fine but it does not know the right packages loading order, does not know >> changes in the packages structure etc. >> And some updates cannot be done at all (e.g. >> https://github.com/pharo-project/ >> pharo/pull/205). So you can expect troubles. >> With Cargo we can get smoother updating process but trying to maintain it now >> would be IMHO waste of resources. >> >> -- Pavel > > If the order is important... > > Iceberg models the commits, so it should be possible to start at the > head and trace back to the commit used to build the image. The > resulting list of commits could then be loaded in the correct order. > (I don't know if this would help in the case of PR #205)
heh… no. Order of commits has nothing to do with order of loading packages. also: - class initialization has to happen - migrate changed instances needs to be prepared pre and post change. while most of the time update packages “just works”, the case of slots for example will not work no matter the loading order, because we need to ensure some pre actions and post actions to happen. I’m playing with the idea to extend iceberg with the capability of processing some information at package and class level (in package with manifests and in classes with class methods). Like adding #iceLoad, #iceUpdate methods (or #iceUpdateBefore and #iceUpdateAfter) so we can handle this… but this will not happen immediately (in case we decide it worths to have it) :) > > Just to add a positive note to the conversation: I'm not very > knowledgable about git, but it seems to be the best source control tool > by far (based on my limited experience), and I've seen steady > improvement in Iceberg since Esteban indicated that it would be the > basis of source control for Pharo. What I've seen so far makes me think > that we are going down a good path, even if it is taking longer we would > like and is causing some pain along the way. nice! and yes, this kind of changes take a lot of time… we are always too optimists and when we said “at least 3 months” we should have said double that time… but I’m happy with things as they are starting to fit. And in a couple of months we will be a full speed :) cheers! Esteban > > > Cheers, > Alistair >
