Re: [Pharo-users] 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 s...@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 bah...@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: Goferresolved in Block: [:each | each resolveWith: self] Array(SequenceableCollection)collect: Goferresolved GoferLoadinitializeOn: GoferLoad class(GoferOperation class)on: Goferexecute:do: Goferexecute: Goferload ScriptLoaderupdate20608 UndefinedObjectDoIt Compilerevaluate:in:to:notifying:ifFail:logged: Compiler classevaluate:for:notifying:logged: Compiler classevaluate:for:logged: Compiler classevaluate:logged: DoItDeclarationimport CodeImporterevaluateDeclarations in Block: [:decl | value := decl import] OrderedCollectiondo: CodeImporterevaluateDeclarations CodeImporter classevaluateReadStream: ChangeSet classnewChangesFromStream:named: in Block: [| newStream |... BlockClosureensure: ChangeSet classnewChangesFromStream:named: UpdateStreamerelementaryReadServerUpdates: in Block: [| docQueue docQueueSema |... BlockClosureensure: CursorWithMask(Cursor)showWhile: UpdateStreamerelementaryReadServerUpdates: UpdateStreamerelementaryReadServerUpdates UpdateStreamerupdateFromServer 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)
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
On 03 Nov 2013, at 10:54, kilon alios kilon.al...@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
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
On 03 Nov 2013, at 12:37, Marcus Denker marcus.den...@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 !
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
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 bah...@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: Goferresolved in Block: [:each | each resolveWith: self] Array(SequenceableCollection)collect: Goferresolved GoferLoadinitializeOn: GoferLoad class(GoferOperation class)on: Goferexecute:do: Goferexecute: Goferload ScriptLoaderupdate20608 UndefinedObjectDoIt Compilerevaluate:in:to:notifying:ifFail:logged: Compiler classevaluate:for:notifying:logged: Compiler classevaluate:for:logged: Compiler classevaluate:logged: DoItDeclarationimport CodeImporterevaluateDeclarations in Block: [:decl | value := decl import] OrderedCollectiondo: CodeImporterevaluateDeclarations CodeImporter classevaluateReadStream: ChangeSet classnewChangesFromStream:named: in Block: [| newStream |... BlockClosureensure: ChangeSet classnewChangesFromStream:named: UpdateStreamerelementaryReadServerUpdates: in Block: [| docQueue docQueueSema |... BlockClosureensure: CursorWithMask(Cursor)showWhile: UpdateStreamerelementaryReadServerUpdates: UpdateStreamerelementaryReadServerUpdates UpdateStreamerupdateFromServer 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
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
On 04 Nov 2013, at 00:01, Stéphane Ducasse stephane.duca...@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
Re: [Pharo-users] Updating Pharo 2 - Unable to resolve ConfigurationOfFuel
On 04 Nov 2013, at 08:26, Marcus Denker marcus.den...@inria.fr wrote: On 04 Nov 2013, at 00:01, Stéphane Ducasse stephane.duca...@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
