Re: [Pharo-project] [Pharo-users] 1.4 update is broken do not use it
On Aug 1, 2011, at 6:27 PM, Torsten Bergmann wrote:
Marcus wrote:
so now updating from https://gforge.inria.fr/frs/download.php/28827/Pharo-1.4-14065.zip
Is this a core or a full image? If core (which one can use to update further) shouldnt this be reflected in the ZIP's name?
In 1.4, there is only one image. This simplifies everything....
OK, but then two questions regarding the above image:
- what is the intention? Provide only the core image in the future? Will ConfigurationOfPharo still be maintained to be able to build a dev image?
The intention is that maintaining two images is one too much. -> We need to test two images -> We track bugs in two categories (see my old mails, very confusing "X bugs here, Z bugs open there") -> We have two completely different ways of how fixes get into the system. And the one fo the ConfigurationOfPharo is really complex to get even a trivial change in. In addtion, it complicates many things: -> the story gets complex. Two downloads. Which do I take? Just look at pharo-project.org. Too complex. -> The Full image can not be updated. That alone is a killer. -> We maintain two browsers -> ..... It's not sustainable. It should be noted that the ConfigurationOfPharo was broken for far too many days, and fixing takes too much effort. The idea is *not* that this one image has the functionality of the old Core image. The idea instead is to have *one* image that is the one that everyone uses and that is the best development environment that we can do.
- why is the provided image a Cog only image (was not able to open it with the standard VM, so it looks like it was saved with Cog) Is this intended?
I have only one VM on my machine. So this lead to the problem that I updated the image for download with that VM.... and I forgot that there is problem. This happend in 1.2 and in 1.3 and in 1.4, and I am tired of it. I am too dumb, I will never get it right. This is again is a question of complexity: Something that is so complex needs to be simplified. We can not support all old VMs forever. New VMs can load the new image format. One of the ideas of 1.4 is that besides one Image, we will have "one" set of VMs. The ones build by the Jenkins/Hudson. They run the new image format. The rule is: for version X of Pharo, use version X of the VM. This solves another problem: Moving to the Future. E.g. the new VMs support better finalization, yet the image needs to be compatible forever to the old code. The new VMs support Ephemerons. Do we ever want to use them? An images where they are active will not run on the old VMs. Being able to move forward on the VM side is very, very important. It makes no sense to be backward *and* forward compatible forever. Marcus -- Marcus Denker -- http://marcusdenker.de
+1 And we will do our best to get the best out of us. And people should join if they want more. Stef
so now updating from https://gforge.inria.fr/frs/download.php/28827/Pharo-1.4-14065.zip
Is this a core or a full image? If core (which one can use to update further) shouldnt this be reflected in the ZIP's name?
In 1.4, there is only one image. This simplifies everything....
OK, but then two questions regarding the above image:
- what is the intention? Provide only the core image in the future? Will ConfigurationOfPharo still be maintained to be able to build a dev image?
The intention is that maintaining two images is one too much.
-> We need to test two images -> We track bugs in two categories (see my old mails, very confusing "X bugs here, Z bugs open there") -> We have two completely different ways of how fixes get into the system. And the one fo the ConfigurationOfPharo is really complex to get even a trivial change in.
In addtion, it complicates many things:
-> the story gets complex. Two downloads. Which do I take? Just look at pharo-project.org. Too complex. -> The Full image can not be updated. That alone is a killer. -> We maintain two browsers -> .....
It's not sustainable.
It should be noted that the ConfigurationOfPharo was broken for far too many days, and fixing takes too much effort.
The idea is *not* that this one image has the functionality of the old Core image. The idea instead is to have *one* image that is the one that everyone uses and that is the best development environment that we can do.
- why is the provided image a Cog only image (was not able to open it with the standard VM, so it looks like it was saved with Cog) Is this intended?
I have only one VM on my machine. So this lead to the problem that I updated the image for download with that VM.... and I forgot that there is problem. This happend in 1.2 and in 1.3 and in 1.4, and I am tired of it.
I am too dumb, I will never get it right.
This is again is a question of complexity: Something that is so complex needs to be simplified.
We can not support all old VMs forever. New VMs can load the new image format.
One of the ideas of 1.4 is that besides one Image, we will have "one" set of VMs. The ones build by the Jenkins/Hudson. They run the new image format.
The rule is: for version X of Pharo, use version X of the VM.
This solves another problem: Moving to the Future. E.g. the new VMs support better finalization, yet the image needs to be compatible forever to the old code. The new VMs support Ephemerons. Do we ever want to use them? An images where they are active will not run on the old VMs.
Being able to move forward on the VM side is very, very important. It makes no sense to be backward *and* forward compatible forever.
Marcus
-- Marcus Denker -- http://marcusdenker.de
participants (2)
-
Marcus Denker -
Stéphane Ducasse