2014-05-20 4:42 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>:

Some students have also tried to update Pharo using the update stream. Is this still used? Should nt it be removed

Alexandre

How I see it: Pharo team wants to perform deep changes into the system. Pharo team wants to perform those changes fast, and not be swamped like they think squeak is (it sure was! but let's say that Squeak values backward compatibility which is naturally a drag). It might be difficult/take a long time to find a way to perform these changes in a reproducible way in customers' images. So the philosophy it let updateStream tools available, but do not bother with update stream if it's too difficult. It's without any guaranty and I often saw it fail (once every few dozens of updates...) I'd say keep it as is. Nicolas

...

Le 19-05-2014 à 15:49, kilon alios <kilon.alios@gmail.com> a écrit :

I felt adventurous today, so I said what the hell lets try to update Pharo with the updater tool. So I used world menu navigated to system and choose software update. And after a long download and method's compiling the attached image appeared :)

<Screen Shot 2014-05-19 at 22.46.28.png>

Hi Nicolas, I completely agree with you. I was wondering what is the relevance of having the “Software update” menu entry if it does not work? Maybe it should be simply removed? It will make menu shorter and less error prone. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On May 20, 2014, at 1:49 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:

2014-05-20 4:42 GMT+02:00 Alexandre Bergel <alexandre.bergel@me.com>: Some students have also tried to update Pharo using the update stream. Is this still used? Should nt it be removed

Alexandre

How I see it:

Pharo team wants to perform deep changes into the system. Pharo team wants to perform those changes fast, and not be swamped like they think squeak is (it sure was! but let's say that Squeak values backward compatibility which is naturally a drag).

It might be difficult/take a long time to find a way to perform these changes in a reproducible way in customers' images. So the philosophy it let updateStream tools available, but do not bother with update stream if it's too difficult. It's without any guaranty and I often saw it fail (once every few dozens of updates...)

I'd say keep it as is.

Nicolas

...

Le 19-05-2014 à 15:49, kilon alios <kilon.alios@gmail.com> a écrit :

I felt adventurous today, so I said what the hell lets try to update Pharo with the updater tool. So I used world menu navigated to system and choose software update. And after a long download and method's compiling the attached image appeared :)

<Screen Shot 2014-05-19 at 22.46.28.png>

2014-05-20 17:21 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

If we are prepared to see it failing, it does not really matter, it's in the contract... The only problem is to be aware of this contract and avoid negative impression. Maybe an advanced menu triggered by some preference?

Or a one liner: Smalltalk upgrade Possible with a warning (muteable) to avoid unintended executions, and enable unattended (i.e. scripted) upgrades. Regards.

On 05/20/2014 04:00 PM, Esteban A. Maringolo wrote:

2014-05-20 17:21 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:

...

If we are prepared to see it failing, it does not really matter, it's in the contract... The only problem is to be aware of this contract and avoid negative impression. Maybe an advanced menu triggered by some preference?

Or a one liner: Smalltalk upgrade

Possible with a warning (muteable) to avoid unintended executions, and enable unattended (i.e. scripted) upgrades.

Regards.

Or even also something like Smalltalk snapshotAndUpgrade or Smalltalk saveImageAndUpgrade That way the images current state is saved or snapshotted and if the upgrade messes everything up, you are back to where you were before the upgrade. Just a thought. Jimmie

yeah I think "Update" needs to be removed from World Menu. Imagine first time trying Pharo and you exploring the World Menu which is the No 1 thing a newcomer does , you find Update and use it and BOOM! this happens. I would not blame that person if he / she says "fuck this" and removes Pharo from his/her system. Its not just that it brakes Pharo , it makes you really worried what else it may do to your system. I think also that even if its hidden it should always display a message like "Update may really brake your Pharo image, make sure you saved your image before proceeding . You want to save now ? " and offer an option to save image. Now with configurations being so popular maybe a method that will iterate through all Configurations , update them and then load their packages, may be the way to go for an update. That means that we need also to create some guidelines on how configurations should be created to make the experience smoother. On Wed, May 21, 2014 at 1:11 PM, stepharo <stepharo@free.fr> wrote:

We would love to have a real update but I'm sure that you realize that something we are modifying the system that modify the methods modifying the system.

So we should probably remove the software update button. Now if somebody wants to work on an infrastructure supporting real atomic load.

Stef PS: the last time I updated my iPhone it blocked and I had to fully reinstall everything. And once when I updated my mac my mouse got blocked forever on the left top corner.

But not also... Because right now the way changes are integrated is using the same update mechanism if I'm not mistaken. The very challenge of the update is that you are updating your image, which has your objects, and your changes! So, what if you made some changes in the core classes? update may fail on merge or even remove your changes. If you keep your method you may lose a bugfix If there was a rename of that method you changed? what should the update do? If you configured some shortcuts? the update may reset them The changesets? they may be reset And the list goes on... On Wed, May 21, 2014 at 2:49 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:

2014-05-21 7:11 GMT-03:00 stepharo <stepharo@free.fr>:

...

So we should probably remove the software update button.

+1

...

Stef PS: the last time I updated my iPhone it blocked and I had to fully reinstall everything. And once when I updated my mac my mouse got blocked forever on the left top corner.

You might be one of the lots of unlucky persons that got issues while updating iOS/MacOS, but sill you probably represent less than the 1% of the total userbase (of which the rest updated with no issues).

The hard thing here is Pharo tries to update itself while running, it is like trying to modify a plane while flying.

Esteban A. Maringolo

Hi All, On Wed, May 21, 2014 at 3:11 AM, stepharo <stepharo@free.fr> wrote:

We would love to have a real update but I'm sure that you realize that something we are modifying the system that modify the methods modifying the system.

but we've been doing that for years. It used to be tricky using change sets, but Monticello's update scheme means it is very simple.

So we should probably remove the software update button. Now if somebody wants to work on an infrastructure supporting real atomic load.

I don't think one needs atomic load to do this. It is very nice to have but Monticello's update scheme is sufficient.

Stef PS: the last time I updated my iPhone it blocked and I had to fully reinstall everything. And once when I updated my mac my mouse got blocked forever on the left top corner.

But I can't remember the last time an update for Squeak failed and the updates are of the cool kind you mention. Personally I think having an update system is a *really important* facility in a development environment. It means I can keep my personal working environment up-to-date. That means I'm more likely to be able to contribute my own improvements to the system.

I worked for a long time with VisualWorks which has a closed development cycle, and doesn't support anything like update. Keeping up to date was always slightly tedious (one had to do things like export one's own stuff and import it into the latest image, etc). Since I've been using Squeak I've understood how superior the Monticello scheme is. So I would urge you to /not/ remove the update button, and instead educate people in the process so that potentially dangerous changes are done properly (by defining baselines, a.k.a. updates in Monticello) and hence preserve the valuable ability to keep one's own image up-to-date. -- best, Eliot

2014-05-22 6:56 GMT+01:00 Freemail <nicolaihess@web.de>:

Are we talking about the update menu item in the system menu?

Yes.

I don't understand this discussion, I always use this menu item for updating the image. I thought this is the nomal way.

So did I when I first discovered Pharo.

And I never had any problems with that .

You are a very lucky person :D (maybe it works because I use it regulary)

Even if that was a solution, it´s not good enough..

How do you keep the image up to date?

I would answer "by using the system update, which, sadly, may or may not work for you at any particular point in time with any particular image". Somebody else may answer "make configurations for your packages and set up a CI job to create images for you". Which is *not* updating the image at all. Cheers, Sergi

On Thu, May 22, 2014 at 1:37 AM, phil@highoctane.be <phil@highoctane.be>wrote:

On Thu, May 22, 2014 at 1:18 AM, Eliot Miranda <eliot.miranda@gmail.com>wrote:

...

Hi All,

On Wed, May 21, 2014 at 3:11 AM, stepharo <stepharo@free.fr> wrote:

...

We would love to have a real update but I'm sure that you realize that something we are modifying the system that modify the methods modifying the system.

but we've been doing that for years. It used to be tricky using change sets, but Monticello's update scheme means it is very simple.

...

So we should probably remove the software update button. Now if somebody wants to work on an infrastructure supporting real atomic load.

I don't think one needs atomic load to do this. It is very nice to have but Monticello's update scheme is sufficient.

...

Stef PS: the last time I updated my iPhone it blocked and I had to fully reinstall everything. And once when I updated my mac my mouse got blocked forever on the left top corner.

But I can't remember the last time an update for Squeak failed and the updates are of the cool kind you mention. Personally I think having an update system is a *really important* facility in a development environment. It means I can keep my personal working environment up-to-date. That means I'm more likely to be able to contribute my own improvements to the system.

I worked for a long time with VisualWorks which has a closed development cycle, and doesn't support anything like update. Keeping up to date was always slightly tedious (one had to do things like export one's own stuff and import it into the latest image, etc). Since I've been using Squeak I've understood how superior the Monticello scheme is. So I would urge you to /not/ remove the update button, and instead educate people in the process so that potentially dangerous changes are done properly (by defining baselines, a.k.a. updates in Monticello) and hence preserve the valuable ability to keep one's own image up-to-date.

Mmh, it depends on how one considers images I guess. If the project can be loaded based on a fresh image an packages (and configurations etc), images are throwaway things.

Do I really have to defend image usage? Would you rebuild your laptop every night throwing away all your state? The synergy between the system's tools and its image is clear. Because the system operates on itself and provides persistence there is more ability and incentive to improve it.

Using that approach (with the CI), one can recreate images easily. Okay, it may mean a couple of minutes to rebuild but there are weird behaviors when one messes with an image too much during development (as Ron commented with change sets).

Also, when does one updates? Updates on a fresh Pharo30 interest me. But not on my dev image as there are a ton of packages loaded, some slices packed on top to deal with some extra stuff. No wonder that updates on top of that aren,'t going to fly.

Really? I regularly update my work image and it works well and I've lots loaded above it. If things break then fix them. Don't throw away value just because there are problems. That;s a race for the bottom that I see all too often in this community. It's the same refrain as "we should try to be as similar to the rest of the world as possible" and that leads to being the same as the rest of the world, which results in being redundant.

And Monticello is indeed super cool. Not always that cool with filtree:// based repos but that is maybe because I do not grasp it all properly right now (facing trouble with the metadata style files on merge with Git - yes,filetree here, not gitfiletree - looking scary).

Phil

...

-- best, Eliot

-- best, Eliot