Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
Hi all, I just downloaded Pharo 2.0 on a Windows machine, unpacked it, ran it and from the world menu selected System -> Software Update but bumped into an exception: <stacktrace> Error: Unable to resolve ConfigurationOfFuel GoferConfigurationReference(Object)>>error: GoferConfigurationReference(GoferReference)>>resolveWith: Gofer>>resolved in Block: [:each | each resolveWith: self] Array(SequenceableCollection)>>collect: Gofer>>resolved GoferLoad>>initializeOn: GoferLoad class(GoferOperation class)>>on: Gofer>>execute:do: Gofer>>execute: Gofer>>load ScriptLoader>>update20608 UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: DoItDeclaration>>import CodeImporter>>evaluateDeclarations in Block: [:decl | value := decl import] OrderedCollection>>do: CodeImporter>>evaluateDeclarations CodeImporter class>>evaluateReadStream: ChangeSet class>>newChangesFromStream:named: in Block: [| newStream |... BlockClosure>>ensure: ChangeSet class>>newChangesFromStream:named: UpdateStreamer>>elementaryReadServerUpdates: in Block: [| docQueue docQueueSema |... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: UpdateStreamer>>elementaryReadServerUpdates: UpdateStreamer>>elementaryReadServerUpdates UpdateStreamer>>updateFromServer in Block: [self elementaryReadServerUpdates] </stacktrace> This is an ablsolutely fresh Pharo instance. Am I doing anything wrong? How can I resolve this? TIA, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Hi Bahman, Pharo 2.0 is released, if you load the latest version from the website, you should not have to do any system updates. That being said, the bug should not happen. Sven On 03 Nov 2013, at 07:10, Bahman Movaqar <Bahman@BahmanM.com> wrote:
Hi all,
I just downloaded Pharo 2.0 on a Windows machine, unpacked it, ran it and from the world menu selected System -> Software Update but bumped into an exception:
<stacktrace>
Error: Unable to resolve ConfigurationOfFuel
GoferConfigurationReference(Object)>>error: GoferConfigurationReference(GoferReference)>>resolveWith: Gofer>>resolved in Block: [:each | each resolveWith: self] Array(SequenceableCollection)>>collect: Gofer>>resolved GoferLoad>>initializeOn: GoferLoad class(GoferOperation class)>>on: Gofer>>execute:do: Gofer>>execute: Gofer>>load ScriptLoader>>update20608 UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: DoItDeclaration>>import CodeImporter>>evaluateDeclarations in Block: [:decl | value := decl import] OrderedCollection>>do: CodeImporter>>evaluateDeclarations CodeImporter class>>evaluateReadStream: ChangeSet class>>newChangesFromStream:named: in Block: [| newStream |... BlockClosure>>ensure: ChangeSet class>>newChangesFromStream:named: UpdateStreamer>>elementaryReadServerUpdates: in Block: [| docQueue docQueueSema |... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: UpdateStreamer>>elementaryReadServerUpdates: UpdateStreamer>>elementaryReadServerUpdates UpdateStreamer>>updateFromServer in Block: [self elementaryReadServerUpdates]
</stacktrace>
This is an ablsolutely fresh Pharo instance. Am I doing anything wrong? How can I resolve this?
TIA,
-- Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
no you dont do anything wrong, unfortunately from what I have been told the update process is broken. Right now the best choices is to download directly from pharo website http://www.pharo-project.org/pharo-download this will get you the latest release from the version you choose there is also Pharo Launcher http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher Pharo Launcher advantages over downloading directly from the pharo website is that it allows you with one click to download specific release and also custom images that contain specific libraries. It also helps you manage your image files, delete them, rename them , etc. I assume that most likely Pharo Launcher will replace the pharo update process but automatically getting the latest release, at some point in the future. In any case getting latest release is a very easy process. On Sun, Nov 3, 2013 at 11:24 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Bahman,
Pharo 2.0 is released, if you load the latest version from the website, you should not have to do any system updates.
That being said, the bug should not happen.
Sven
On 03 Nov 2013, at 07:10, Bahman Movaqar <Bahman@BahmanM.com> wrote:
Hi all,
I just downloaded Pharo 2.0 on a Windows machine, unpacked it, ran it and from the world menu selected System -> Software Update but bumped into an exception:
<stacktrace>
Error: Unable to resolve ConfigurationOfFuel
GoferConfigurationReference(Object)>>error: GoferConfigurationReference(GoferReference)>>resolveWith: Gofer>>resolved in Block: [:each | each resolveWith: self] Array(SequenceableCollection)>>collect: Gofer>>resolved GoferLoad>>initializeOn: GoferLoad class(GoferOperation class)>>on: Gofer>>execute:do: Gofer>>execute: Gofer>>load ScriptLoader>>update20608 UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: DoItDeclaration>>import CodeImporter>>evaluateDeclarations in Block: [:decl | value := decl import] OrderedCollection>>do: CodeImporter>>evaluateDeclarations CodeImporter class>>evaluateReadStream: ChangeSet class>>newChangesFromStream:named: in Block: [| newStream |... BlockClosure>>ensure: ChangeSet class>>newChangesFromStream:named: UpdateStreamer>>elementaryReadServerUpdates: in Block: [| docQueue docQueueSema |... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: UpdateStreamer>>elementaryReadServerUpdates: UpdateStreamer>>elementaryReadServerUpdates UpdateStreamer>>updateFromServer in Block: [self elementaryReadServerUpdates]
</stacktrace>
This is an ablsolutely fresh Pharo instance. Am I doing anything wrong? How can I resolve this?
TIA,
-- Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
On 03 Nov 2013, at 10:54, kilon alios <kilon.alios@gmail.com> wrote:
no you dont do anything wrong, unfortunately from what I have been told the update process is broken. Right now the best choices is to download directly from pharo website
The problem is that how images are used is shifting: People used to use an image for a long time, updating the base from time to time while their code was in the image. These days, what people do is to have an automatic (and well defined) process that build a fresh image on -> base system is updated -> Own code commit So e.g. I never retain images after I finish something. I commit, wait for the build system to tell me everything is green, and I throw the image away. Images are transient things. This in turn means nobody uses updating, and this means that it is not tested. and everything not tested brakes after a whileâ¦. (In turn, everything we want to be sure works needs to be tested after every commit, but testing âupdating every old version to the newestâ is not really testable, anaywayâ¦) When we move to an image-bootstrap for the development of Pharo itself (I guess in Pharo4), we should really check what and how (and if) we support updating existing images, or if we declare the image to be something that *always* be the result of a deterministic build process⦠Marcus
On 03 Nov 2013, at 12:37, Marcus Denker <marcus.denker@inria.fr> wrote:
When we move to an image-bootstrap for the development of Pharo itself (I guess in Pharo4), we should really check what and how (and if) we support updating existing images, or if we declare the image to be something that *always* be the result of a deterministic build processâ¦
Yes, a base image should be exactly that !
But marcus we are doing update all the time because this is the way we push new updates daily. So I do not understand why this would be different?
no you dont do anything wrong, unfortunately from what I have been told the update process is broken. Right now the best choices is to download directly from pharo website
The problem is that how images are used is shifting: People used to use an image for a long time, updating the base from time to time while their code was in the image.
These days, what people do is to have an automatic (and well defined) process that build a fresh image on -> base system is updated -> Own code commit
So e.g. I never retain images after I finish something. I commit, wait for the build system to tell me everything is green, and I throw the image away. Images are transient things.
This in turn means nobody uses updating, and this means that it is not tested. and everything not tested brakes after a whileâ¦. (In turn, everything we want to be sure works needs to be tested after every commit, but testing âupdating every old version to the newestâ is not really testable, anaywayâ¦)
When we move to an image-bootstrap for the development of Pharo itself (I guess in Pharo4), we should really check what and how (and if) we support updating existing images, or if we declare the image to be something that *always* be the result of a deterministic build processâ¦
Marcus
On 04 Nov 2013, at 00:01, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
But marcus we are doing update all the time because this is the way we push new updates daily. So I do not understand why this would be different?
It happens due to strange things: updates that access the web and URLs change, for example. Or in the past one problem was that it could overload squeak-source to load for hours and hours packages⦠And it takes quite some care to keep it going: when *really* bad things happen, we now (once or twice in a year) upload a fixed image that is than taken as the base. If you want to support âtake pharo2 and update it to pharo3â, (or even, take Pharo3 half a year agoâ¦), then we need to put *a huge* (very huge) effort into making sure that we never ever upload a hand-fixed image. This is a lot of work. And in addition, even that does not guarantee anything: you would need to actually test itâ¦
no you dont do anything wrong, unfortunately from what I have been told the update process is broken. Right now the best choices is to download directly from pharo website
The problem is that how images are used is shifting: People used to use an image for a long time, updating the base from time to time while their code was in the image.
These days, what people do is to have an automatic (and well defined) process that build a fresh image on -> base system is updated -> Own code commit
So e.g. I never retain images after I finish something. I commit, wait for the build system to tell me everything is green, and I throw the image away. Images are transient things.
This in turn means nobody uses updating, and this means that it is not tested. and everything not tested brakes after a whileâ¦. (In turn, everything we want to be sure works needs to be tested after every commit, but testing âupdating every old version to the newestâ is not really testable, anaywayâ¦)
When we move to an image-bootstrap for the development of Pharo itself (I guess in Pharo4), we should really check what and how (and if) we support updating existing images, or if we declare the image to be something that *always* be the result of a deterministic build processâ¦
Marcus
On 04 Nov 2013, at 08:26, Marcus Denker <marcus.denker@inria.fr> wrote:
On 04 Nov 2013, at 00:01, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
But marcus we are doing update all the time because this is the way we push new updates daily. So I do not understand why this would be different?
It happens due to strange things: updates that access the web and URLs change, for example. Or in the past one problem was that it could overload squeak-source to load for hours and hours packagesâ¦
And it takes quite some care to keep it going: when *really* bad things happen, we now (once or twice in a year) upload a fixed image that is than taken as the base. If you want to support âtake pharo2 and update it to pharo3â, (or even, take Pharo3 half a year agoâ¦), then we need to put *a huge* (very huge) effort into making sure that we never ever upload a hand-fixed image. This is a lot of work.
And in addition, even that does not guarantee anything: you would need to actually test itâ¦
So in the end, when we get the the bootstrap into Pharo4, this would even mean that keeping an incremental updater would be completely additional work. Like they do with Chrome⦠I am sure one could generate the diff automatically and detect the cases when it does not work (and tell the user). Would be an interesting research project. Marcus
Ok so that I know it and this is probably 3 changes of 500. I was thinking about what is the problem with 2.0 update.
But marcus we are doing update all the time because this is the way we push new updates daily. So I do not understand why this would be different?
It happens due to strange things: updates that access the web and URLs change, for example. Or in the past one problem was that it could overload squeak-source to load for hours and hours packagesâ¦
And it takes quite some care to keep it going: when *really* bad things happen, we now (once or twice in a year) upload a fixed image that is than taken as the base. If you want to support âtake pharo2 and update it to pharo3â, (or even, take Pharo3 half a year agoâ¦), then we need to put *a huge* (very huge) effort into making sure that we never ever upload a hand-fixed image. This is a lot of work.
And in addition, even that does not guarantee anything: you would need to actually test itâ¦
no you dont do anything wrong, unfortunately from what I have been told the update process is broken. Right now the best choices is to download directly from pharo website
The problem is that how images are used is shifting: People used to use an image for a long time, updating the base from time to time while their code was in the image.
These days, what people do is to have an automatic (and well defined) process that build a fresh image on -> base system is updated -> Own code commit
So e.g. I never retain images after I finish something. I commit, wait for the build system to tell me everything is green, and I throw the image away. Images are transient things.
This in turn means nobody uses updating, and this means that it is not tested. and everything not tested brakes after a whileâ¦. (In turn, everything we want to be sure works needs to be tested after every commit, but testing âupdating every old version to the newestâ is not really testable, anaywayâ¦)
When we move to an image-bootstrap for the development of Pharo itself (I guess in Pharo4), we should really check what and how (and if) we support updating existing images, or if we declare the image to be something that *always* be the result of a deterministic build processâ¦
Marcus
Bahman, Hi, Fuel was moved some time ago from SS3 to SmalltalkHub. Could it be that it was searching ConfigurationOfFuel in SS3? On Sun, Nov 3, 2013 at 3:10 AM, Bahman Movaqar <Bahman@bahmanm.com> wrote:
Hi all,
I just downloaded Pharo 2.0 on a Windows machine, unpacked it, ran it and from the world menu selected System -> Software Update but bumped into an exception:
<stacktrace>
Error: Unable to resolve ConfigurationOfFuel
GoferConfigurationReference(Object)>>error: GoferConfigurationReference(GoferReference)>>resolveWith: Gofer>>resolved in Block: [:each | each resolveWith: self] Array(SequenceableCollection)>>collect: Gofer>>resolved GoferLoad>>initializeOn: GoferLoad class(GoferOperation class)>>on: Gofer>>execute:do: Gofer>>execute: Gofer>>load ScriptLoader>>update20608 UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: DoItDeclaration>>import CodeImporter>>evaluateDeclarations in Block: [:decl | value := decl import] OrderedCollection>>do: CodeImporter>>evaluateDeclarations CodeImporter class>>evaluateReadStream: ChangeSet class>>newChangesFromStream:named: in Block: [| newStream |... BlockClosure>>ensure: ChangeSet class>>newChangesFromStream:named: UpdateStreamer>>elementaryReadServerUpdates: in Block: [| docQueue docQueueSema |... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile: UpdateStreamer>>elementaryReadServerUpdates: UpdateStreamer>>elementaryReadServerUpdates UpdateStreamer>>updateFromServer in Block: [self elementaryReadServerUpdates]
</stacktrace>
This is an ablsolutely fresh Pharo instance. Am I doing anything wrong? How can I resolve this?
TIA,
-- Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
-- Mariano http://marianopeck.wordpress.com
participants (7)
-
Bahman Movaqar -
btc＠openinworld.com -
kilon alios -
Marcus Denker -
Mariano Martinez Peck -
Stéphane Ducasse -
Sven Van Caekenberghe