Smalltalk › Pharo › Pharo Smalltalk Users

Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

bahman

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)

signature.asc (565 bytes) Download Attachment

Sven Van Caekenberghe-2

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

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 <[hidden email]> 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)
>
>

kilon.alios

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

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 <[hidden email]> 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 <[hidden email]> 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)
>
>

Marcus Denker-4

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

On 03 Nov 2013, at 10:54, kilon alios <[hidden email]> 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

Sven Van Caekenberghe-2

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

On 03 Nov 2013, at 12:37, Marcus Denker <[hidden email]> 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 !

Stéphane Ducasse

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

In reply to this post by Marcus Denker-4

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
>
>

Mariano Martinez Peck

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

In reply to this post by bahman

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 <[hidden email]> 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

Marcus Denker-4

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

In reply to this post by Stéphane Ducasse

On 04 Nov 2013, at 00:01, Stéphane Ducasse <[hidden email]> 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
>>
>>
>
>

Marcus Denker-4

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

On 04 Nov 2013, at 08:26, Marcus Denker <[hidden email]> wrote:

>
> On 04 Nov 2013, at 00:01, Stéphane Ducasse <[hidden email]> 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

Stéphane Ducasse

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

In reply to this post by Marcus Denker-4

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
>>>
>>>
>>
>>
>
>

Ben Coman

Re: Updating Pharo 2 - Unable to resolve ConfigurationOfFuel

In reply to this post by Marcus Denker-4

Marcus Denker wrote:

On 04 Nov 2013, at 08:26, Marcus Denker [hidden email] wrote:

On 04 Nov 2013, at 00:01, Stéphane Ducasse [hidden email] 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

Generally speaking, there is a use case (at least on Windows systems) is the common practice for end-user deployed applications to check for 'Updates available' - either automatically or manually from a Help menu, and downloading and installing these. However maybe that form of update is better done by other means.

cheers -ben