Even weirder: played with the debugger and sayed Over Over Over then Proceed and it worked. Strange....

What do you mean exactly ? You were not able to Proceed after clicking on

Over several times on Pharo 1.4 ? I've just made a fix in the debugger that was integrated today.Give me more details to know if I have to look at it. Clement Phil

2013/2/19 Esteban Lorenzano <estebanlm@gmail.com>:

...

Hi,

We are almost there for the release, but we still need a little effort more. Would be terrific if everyone of you took the latest 2.0 image and test it with your usual workflows (we cannot imagine all, they are infinite :)

And please report bugs, and JUST bugs :)

all the "nice to have" can be reported, but in 3.0 milestone (or not milestone at all).

cheers, Esteban

I start to believe that it might be your VM? Which version are you using? Smalltalk vm version does the trick. On 2013-02-19, at 21:45, "phil@highoctane.be" <phil@highoctane.be> wrote:

Pharo 2.0 not 1.4

The World Menu > System >Software Update started working and then threw me in teh debugger where I had the error. I inspected several variables and then did some Restart,, Over, Over, ..Proceed and things went fine.

There was a ZnClient in there but I can't figure out why there was a mention of SmallInteger.

Phil

2013/2/19 Clément Bera <bera.clement@gmail.com>:

...

...

Even weirder: played with the debugger and sayed Over Over Over then Proceed and it worked. Strange....

What do you mean exactly ? You were not able to Proceed after clicking on Over several times on Pharo 1.4 ? I've just made a fix in the debugger that was integrated today.Give me more details to know if I have to look at it.

Clement

...

Phil

2013/2/19 Esteban Lorenzano <estebanlm@gmail.com>:

...

Hi,

We are almost there for the release, but we still need a little effort more. Would be terrific if everyone of you took the latest 2.0 image and test it with your usual workflows (we cannot imagine all, they are infinite :)

And please report bugs, and JUST bugs :)

all the "nice to have" can be reported, but in 3.0 milestone (or not milestone at all).

cheers, Esteban

thanks, I will try it with that one and see what happens. On 2013-02-19, at 23:28, "phil@highoctane.be" <phil@highoctane.be> wrote:

Latest PharoVM from the CI

'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Feb 18 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Feb 18 2013 git://gitorious.org/cogvm/blessed.git Commit: 05ed728452dc92732f9f23ce24a3c32bfdc0f4b8 Date: 2013-02-15 17:04:09 +0100 By: Igor Stasenko <siguctua@gmail.com> Jenkins build #14519 '

2013/2/19 Camillo Bruni <camillobruni@gmail.com>:

...

I start to believe that it might be your VM? Which version are you using?

Smalltalk vm version

does the trick.

On 2013-02-19, at 21:45, "phil@highoctane.be" <phil@highoctane.be> wrote:

...

Pharo 2.0 not 1.4

The World Menu > System >Software Update started working and then threw me in teh debugger where I had the error. I inspected several variables and then did some Restart,, Over, Over, ..Proceed and things went fine.

There was a ZnClient in there but I can't figure out why there was a mention of SmallInteger.

Phil

2013/2/19 Clément Bera <bera.clement@gmail.com>:

...

...

Even weirder: played with the debugger and sayed Over Over Over then Proceed and it worked. Strange....

What do you mean exactly ? You were not able to Proceed after clicking on Over several times on Pharo 1.4 ? I've just made a fix in the debugger that was integrated today.Give me more details to know if I have to look at it.

Clement

...

Phil

2013/2/19 Esteban Lorenzano <estebanlm@gmail.com>:

...

Hi,

We are almost there for the release, but we still need a little effort more. Would be terrific if everyone of you took the latest 2.0 image and test it with your usual workflows (we cannot imagine all, they are infinite :)

And please report bugs, and JUST bugs :)

all the "nice to have" can be reported, but in 3.0 milestone (or not milestone at all).

cheers, Esteban

On 2013-02-19, at 23:30, Camillo Bruni <camillobruni@gmail.com> wrote:

thanks, I will try it with that one and see what happens.

I just took the latest Mac VM and updated from Pharo 20550 with! a crash! => problem with the latest VM!! I can easily update the image with an older VM, maybe I was just lucky it didn't crash with the old build: CoInterpreter VMMaker-oscog-IgorStasenko.162 uuid: e4554f9a-cc90-4826-a807-ac282b782fe4 Jul 26 2012 StackToRegisterMappingCogit VMMaker-oscog-IgorStasenko.162 uuid: e4554f9a-cc90-4826-a807-ac282b782fe4 Jul 26 2012 https://git.gitorious.org/cogvm/blessed.git Commit: aeb0705cde4b8fc57cb262dc051c5ee6dfa72a14 Date: 2012-07-26 16:38:48 +0200 By: Igor Stasenko <siguctua@gmail.com>

I guess I should start sleeping, tired beyond return (aka, my emails start to just be gibberish). ;) On 2013-02-19, at 23:50, "phil@highoctane.be" <phil@highoctane.be> wrote:

26/07/2012 ? Huh?

yes the update runs fine with a "rather" old VM which we built. However it fails with one of the new series built this week. I will forward that to our VM masters ;)

2013/2/19 Camillo Bruni <camillobruni@gmail.com>:

...

On 2013-02-19, at 23:30, Camillo Bruni <camillobruni@gmail.com> wrote:

...

thanks, I will try it with that one and see what happens.

I just took the latest Mac VM and updated from Pharo 20550 with! a crash!

=> problem with the latest VM!!

I can easily update the image with an older VM, maybe I was just lucky it didn't crash with the old build:

CoInterpreter VMMaker-oscog-IgorStasenko.162 uuid: e4554f9a-cc90-4826-a807-ac282b782fe4 Jul 26 2012 StackToRegisterMappingCogit VMMaker-oscog-IgorStasenko.162 uuid: e4554f9a-cc90-4826-a807-ac282b782fe4 Jul 26 2012 https://git.gitorious.org/cogvm/blessed.git Commit: aeb0705cde4b8fc57cb262dc051c5ee6dfa72a14 Date: 2012-07-26 16:38:48 +0200 By: Igor Stasenko <siguctua@gmail.com>

Hi Yanni, On 20 Feb 2013, at 22:23, Yanni Chiu <yanni@rogers.com> wrote:

On 19/02/13 12:22 PM, Esteban Lorenzano wrote:

...

We are almost there for the release, but we still need a little effort more. Would be terrific if everyone of you took the latest 2.0 image and test it with your usual workflows (we cannot imagine all, they are infinite :)

I usually keep a build tracking the upcoming Pharo release, but when I tried to do it during early Pharo-2.0 development, the code was not stable. Then I never got back to it. Here's what happened, when I tried to build with the newest version.

Thanks for testing, thanks for the feedback.

First try: "Notice: Your VM is too old for this image. Please download the latest VM."

Get latest coglinux, from http://www.mirandabanda.org/files/Cog/VM/

Second try: "Can't infer base LD_LIBRARY_PATH. Aborting. Try adding a line for /lib/i686/cmov/libc.so.6 ..."

Patch squeak shell script with a case for "/lib/i686/cmov/libc*"

Third try: No complaint about LD_LIBRARY_PATH, but still says "VM is too old ..."

Switch to a CogVM (early version of PharoVM) that was lying around.

This is a bit to be expected when you use older VMs, the one-click or designated Pharo (NBCog) VMs would have prevented these issues.

More tries:

Can't load Seaside. Update to newer seaside31.st script from https://github.com/renggli/builder/tree/master/scripts

Magritte3/Pier3 has deprecations and undefined class.

Revert to trying Seaside30. Get: *** Warning: Warning: This package depends on the following classes: BlockContext You must resolve these dependencies before you will be able to load these definitions: renderOn:

Go back to trying Magritte3/Pier3 on Seaside31 again. Ignore the deprecations, find: FileSystem-Legacy, at: http://smalltalkhub.com/mc/dh83/fisleg/main Can now load Pier3 into Pharo-20558.

Figure out where to get the latest Zinc-Seaside. (Found at http://www.squeaksource.com/ZincHTTPComponents). Start Seaside, go to Pier link, get deprecation warnings about #includesSubString:. Try to disable warnings in System Settings. Still get warnings in webpage. Change to #includesSubString: to not call #deprecated:on:. Now, can see default Pier page.

It will be a while before all third party packages are properly ported to Pharo 2.0. Many are, but that depends mostly on their authors. Now, Seaside 3.1 and friends will load and work proper on Pharo 2.0, it is just not an out-of-the-box it-just-works experience. The #includesSub[S|s]tring: issue is easy to solve, it just requires a decision on the part of the Seaside developers. See http://forum.world.st/Broken-build-because-of-use-of-includesSubstring-tt466... There also seem to be some technical reasons why a Metacello Configuration is not yet there. I guess that user pressure, once 2.0 is out, is the only thing that will make a difference. These things sometimes go slowly. This is all open source.

Next step, try to load my custom code…

Let us know how it goes ! Regards, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Hi Yanni,

I just had to change my build script to stop loading an older version of Fuel on top of the version already present in Pharo-2.0. After some quick manual testing, things look good.

What version was you loading?

But, the newer Fuel version means I have to migrate Fuel versions again, which is not something I expected to have to do. Hmmm, will have to back away from moving to 2.0, for now.

The code of Fuel that was integrated today is the same as installing with: Gofer it squeaksource3: 'Fuel'; package: 'ConfigurationOfFuel'; load. (ConfigurationOfFuel project version: '1.9') load. (actually, the code that has been integrated should be the definitive one for Fuel 1.9, but the configuration still needs a revision for old Pharos) Tell me if I can help with the migration. Martin

On Mon, Feb 25, 2013 at 10:55 PM, Yanni Chiu <yanni@rogers.com> wrote:

On 25/02/13 4:25 PM, Martin Dias wrote:

...

What version was you loading?

Fuel-MartinDias.685 which corresponds to version 1.8

...

(actually, the code that has been integrated should be the definitive one for Fuel 1.9, but the configuration still needs a revision for old Pharos)

Would it be easy to unload Fuel 1.9 from Pharo-2.0, and load Fuel 1.8 instead?

I tried to load Fuel 1.8 in Pharo 2.0 but it seems that there is an incompatibility with Date and DateAndTime...

On 01/03/13 10:10 AM, Max Leske wrote:

On 01.03.2013, at 15:36, Martin Dias <tinchodias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

...

On Mon, Feb 25, 2013 at 10:55 PM, Yanni Chiu <yanni-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org> wrote:

...

Would it be easy to unload Fuel 1.9 from Pharo-2.0, and load Fuel 1.8 instead?

I tried to load Fuel 1.8 in Pharo 2.0 but it seems that there is an incompatibility with Date and DateAndTime…

Should work from 1.8.1 on upwards though...

The description for 1.8.1 says: - same as 1.8 - fix: serialization / materialization of Date objects. The description for 1.8.2 says: - Date / DateAndTime are now serialized consistently across different images (Squeak and Pharo) So, the question is: will something serialized by 1.8, load into 1.8.1, 1.8.2? I guess I'll find out shortly. My other option is to do the migration to 1.9 in Pharo-1.4, before moving to Pharo-2.0. BTW, the slowest part of a migration is upgrading the Fuel version for each set of Fuel files being migrated. Do you think it would work to have a Fuel Tanker file for Fuel version 1.9, that can be quickly loaded? Hold on - that would mean you'd need some version of Fuel loaded.

Or... really i'm not sure what is the Right Solution, but at least I read of a couple of prototypes that achieved to load multiple versions of classes and methods, so it is technically feasible. The magic of Smalltalk! On Fri, Mar 1, 2013 at 7:54 PM, Martin Dias <tinchodias@gmail.com> wrote:

I'm sorry but AFAIK you won't be able to materialize in 1.8.x the files you serialized with 1.8. Maybe Max has some trick to do it?

And you are true: tanker needs fuel so it won't work :)

Some time ago we thought in a nasty way of have two versions of fuel at the same time: take a fuel version, then rename all extension methods adding a prefix. But it's ugly and it should be done with care.

This year I realised that it is possible to hack the image to enable several versions of the same package at the same time. I should ask Marcus again about this, I think it should be a good solution. Others in this mailing-list can correct me, but IMO to do it well, we first need a good modules system... but before maybe we can do some hacky solution to easy migration of files. It could be fun.

Martin

On Fri, Mar 1, 2013 at 5:53 PM, Yanni Chiu <yanni@rogers.com> wrote:

...

On 01/03/13 10:10 AM, Max Leske wrote:

...

On 01.03.2013, at 15:36, Martin Dias <tinchodias-** Re5JQEeQqe8AvxtiuMwx3w@public.**gmane.org<tinchodias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote:

On Mon, Feb 25, 2013 at 10:55 PM, Yanni Chiu <

...

yanni-bJEeYj9oJeDQT0dZR+AlfA@**public.gmane.org<yanni-bJEeYj9oJeDQT0dZR%2BAlfA@public.gmane.org>> wrote:

...

Would it be easy to unload Fuel 1.9 from Pharo-2.0, and load Fuel 1.8 instead?

I tried to load Fuel 1.8 in Pharo 2.0 but it seems that there is an incompatibility with Date and DateAndTime…

Should work from 1.8.1 on upwards though...

The description for 1.8.1 says:

- same as 1.8 - fix: serialization / materialization of Date objects.

The description for 1.8.2 says:

- Date / DateAndTime are now serialized consistently across different images (Squeak and Pharo)

So, the question is: will something serialized by 1.8, load into 1.8.1, 1.8.2? I guess I'll find out shortly.

My other option is to do the migration to 1.9 in Pharo-1.4, before moving to Pharo-2.0. BTW, the slowest part of a migration is upgrading the Fuel version for each set of Fuel files being migrated. Do you think it would work to have a Fuel Tanker file for Fuel version 1.9, that can be quickly loaded? Hold on - that would mean you'd need some version of Fuel loaded.