Well, I'd imagine you'd use the ConfigurationOf. Perhaps this is what you want?

I have no idea what ConfigurationOf is.

Installer ss3 project: 'Fuel'; install: 'ConfigurationOfFuel-MaxLeske.178'. (Smalltalk at: #ConfigurationOfFuel) loadStable.

That last line might be wrong. Is that how you trigger/load the configuration, Max?

It worked with

Installer ss3 project: 'Fuel'; install: 'ConfigurationOfFuel-MaxLeske.178'.

((Smalltalk at: #ConfigurationOfFuel) project version: #stable) load.

... maybe this could appear in http://rmod.lille.inria.fr/web/pier/software/Fuel/Installation ?

Stef

If noone beats me to it, I'll try add one tonight. (I'm playing Lego with my children at the moment!)

No hurry, and happy new year !

Stef

On 2 January 2013 16:03, Max Leske maxleske@gmail.com wrote:

On 02.01.2013, at 16:13, Stéphane Rollandin lecteur@zogotounga.net wrote:

...

...

Well, I'd imagine you'd use the ConfigurationOf. Perhaps this is what you want?

I have no idea what ConfigurationOf is.

...

Installer ss3 project: 'Fuel'; install: 'ConfigurationOfFuel-MaxLeske.178'. (Smalltalk at: #ConfigurationOfFuel) loadStable.

That last line might be wrong. Is that how you trigger/load the configuration, Max?

It worked with

Installer ss3 project: 'Fuel'; install: 'ConfigurationOfFuel-MaxLeske.178'.

((Smalltalk at: #ConfigurationOfFuel) project version: #stable) load.

Perfect. You could also use the provided load shortcut:

(Smalltalk at: #ConfigurationOfFuel) load.

If Installer doesn't work, this is the MC repo config:

MCHttpRepository location: 'http://ss3.gemstone.com/ss/Fuel' user: '' password: ''

...

... maybe this could appear in http://rmod.lille.inria.fr/web/pier/software/Fuel/Installation ?

Stef

The fuel website, including documentation, is here: http://rmod.lille.inria.fr/web/pier/software/Fuel. Issues can be reported on the Google Code page: http://code.google.com/p/fuel/.

I will ask Mariano to update the installation section of the docs.

I've added a package to SqueakMap, together with a release for 4.4. This means my name's attached to the package, but I've tried to make it clear it's not my work :)

It seems to work!

frank

Cheers, Max

Thanks guys!

On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote:

...

I've added a package to SqueakMap, together with a release for 4.4. This means my name's attached to the package, but I've tried to make it clear it's not my work :)

No problemo, I just made it a Community Supported package. Now anyone will be able to add or update the release entry's.

Thanks Hannes, I'll look at that.

On 03.01.2013, at 13:47, H. Hirzel hannes.hirzel@gmail.com wrote:

Hello

[Test]

Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. All 252 tests are green.

Thank you, Max, for your porting work. This is a very useful asset to have in Squeak.

A thing which does not work: The example in the class comment of FLSerializer gives a walkback

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript with: [ Transcript show: 'a string' ].

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'.

Without having to serialize the block [ Transcript show: 'a string' ] it runs fine.

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript.

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'.

--Hannes

On 1/2/13, Max Leske maxleske@gmail.com wrote:

...

Thanks guys!

On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote:

...

...

I've added a package to SqueakMap, together with a release for 4.4. This means my name's attached to the package, but I've tried to make it clear it's not my work :)

No problemo, I just made it a Community Supported package. Now anyone will be able to add or update the release entry's.

On Thu, Jan 3, 2013 at 4:29 PM, Martin Dias tinchodias@gmail.com wrote:

Hello Hannes,

We didn't note this buggy comment. I'm sorry. I guess it is wrong since we moved the ability to serialize CompiledMethods from the core Fuel package to an optional one, named FuelMetalevel. Probably we will revert this in 1.9, so the example will be valid again... I loaded FuelMetalevel in Squeak 4.3 but the tests are red, but probably

Ouch, I didn't finish the sentence: I loaded FuelMetalevel in Squeak 4.3 but the tests are red, but probably it's easy to make it work.

On the other side, I'm updating the documentation on our webpage, it is almost exactly the same than in 1.8.

Thank you; any feedback is more than welcome!

Regards, Martin

On Thu, Jan 3, 2013 at 1:47 PM, H. Hirzel hannes.hirzel@gmail.com wrote:

...

Hello

[Test]

Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. All 252 tests are green.

Thank you, Max, for your porting work. This is a very useful asset to have in Squeak.

A thing which does not work: The example in the class comment of FLSerializer gives a walkback

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript with: [ Transcript show: 'a string' ].

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'.

Without having to serialize the block [ Transcript show: 'a string' ] it runs fine.

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript.

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'.

--Hannes

On 1/2/13, Max Leske maxleske@gmail.com wrote:

...

Thanks guys!

On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote:

...

...

I've added a package to SqueakMap, together with a release for 4.4. This means my name's attached to the package, but I've tried to make it clear it's not my work :)

No problemo, I just made it a Community Supported package. Now anyone will be able to add or update the release entry's.

On Thu, Jan 3, 2013 at 4:33 PM, Martin Dias tinchodias@gmail.com wrote:

On Thu, Jan 3, 2013 at 4:29 PM, Martin Dias tinchodias@gmail.com wrote:

...

Hello Hannes,

We didn't note this buggy comment. I'm sorry. I guess it is wrong since we moved the ability to serialize CompiledMethods from the core Fuel package to an optional one, named FuelMetalevel. Probably we will revert this in 1.9, so the example will be valid again... I loaded FuelMetalevel in Squeak 4.3 but the tests are red, but probably

Ouch, I didn't finish the sentence: I loaded FuelMetalevel in Squeak 4.3 but the tests are red, but probably it's easy to make it work.

I didn't explain the problem you had:

When you evaluated the snippet of code, it was compiled to a temporary #DoIt method (not installed into the method dictionary). Then, the example serialized a blockclosure, that was defined into the not-installed #DoIt. By default, Fuel serializes the CompiledMethods just as a class name and a selector. So, when you try to materialize the blockclosure, Fuel asks the method dictionary for the #DoIt, which is not there. So signals an error. Using FuelMetalevel, you can tell Fuel to fully serialize the CompiledMethods, so DoIt can be serialized and materialized, no matter if it is installed or not.

Best regards.

...

On the other side, I'm updating the documentation on our webpage, it is almost exactly the same than in 1.8.

Thank you; any feedback is more than welcome!

Regards, Martin

On Thu, Jan 3, 2013 at 1:47 PM, H. Hirzel hannes.hirzel@gmail.com wrote:

...

Hello

[Test]

Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. All 252 tests are green.

Thank you, Max, for your porting work. This is a very useful asset to have in Squeak.

A thing which does not work: The example in the class comment of FLSerializer gives a walkback

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript with: [ Transcript show: 'a string' ].

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'.

Without having to serialize the block [ Transcript show: 'a string' ] it runs fine.

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript.

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'.

--Hannes

On 1/2/13, Max Leske maxleske@gmail.com wrote:

...

Thanks guys!

On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote:

...

...

I've added a package to SqueakMap, together with a release for 4.4. This means my name's attached to the package, but I've tried to make it clear it's not my work :)

No problemo, I just made it a Community Supported package. Now anyone will be able to add or update the release entry's.

Hello Martín

I wanted to try out a simpler example first, just a few Morphs and had problems with it.

The test case ---------------------

A) Create a RectangleMorph with 4 submorphs and serialize it.

I a Morphic project I evaluate the following code. It serializes a morph into a file called

4ColoredDots.FL.

"Example taken from: http://wiki.squeak.org/squeak/52"

m := RectangleMorph new. m layoutPolicy: TableLayout new. m listDirection: #leftToRight. "If you omit this expression you get the default " "m listDirection: #topToBottom." m hResizing: #shrinkWrap. m vResizing: #shrinkWrap.

m addMorph: (EllipseMorph new extent: 40@40; color: Color red). m addMorph: (EllipseMorph new extent: 50@50; color: Color yellow). m addMorph: (EllipseMorph new extent: 60@60; color: Color green). m addMorph: (EllipseMorph new extent: 70@70; color: Color blue). m openInWorld.

"Store to the file" FLSerializer serialize: r toFileNamed: '4coloredDots.FL'.

B) Loading file '4coloredDots.FL' into another Morphic project

I open another Morphic project and evaluate.

"Load from the file" | r | r := FLMaterializer materializeFromFileNamed: '4coloredDots.FL'. r inspect. World addMorph: r.

PROBLEM ----------------

r is nil.

QUESTION ----------------

What am I missing here? Maybe this example is not actually simpler but more complicated than the one you gave in the previous mail.... :-(

In any case illustrative comments are appreciated.

Kind regards

Hannes Hirzel

On 1/3/13, Martin Dias tinchodias@gmail.com wrote:

...

I didn't explain the problem you had:

When you evaluated the snippet of code, it was compiled to a temporary #DoIt method (not installed into the method dictionary). Then, the example serialized a blockclosure, that was defined into the not-installed #DoIt. By default, Fuel serializes the CompiledMethods just as a class name and a selector. So, when you try to materialize the blockclosure, Fuel asks the method dictionary for the #DoIt, which is not there. So signals an error. Using FuelMetalevel, you can tell Fuel to fully serialize the CompiledMethods, so DoIt can be serialized and materialized, no matter if it is installed or not.

Just to complete the idea... if the block closure were installed in a class, then there will be no error. If you file-in the attached file and evaluate:

FLSerializer example.

I works, so you can see a string printed in the Transcript.

Martín

Thank you Martín for reviewing the test.

Indeed it works after correcting the typo.

A slightly different example works also fine.

In one Morphic Project I do

FLSerializer serialize: World submorphs toFileNamed: 'myExample2.FL'.

In another I get it back with

| r | r := FLMaterializer materializeFromFileNamed: 'myExample2.FL'. r do: [ :m | (m isKindOf: DockingBarMorph) ifFalse: [World addMorph: m.]]

In fact this recreates as well the Workspace used for serializing but this does not matter as it can easily be closed.

Very simple to use. Nice.

--Hannes

On 1/4/13, Martin Dias tinchodias@gmail.com wrote:

Hi Hannes,

I tried it and then discovered the tiny typing error: actually you are serializing nil, because r is not initialized. For sure you wanted to serialize the contents of m, instead.

So replacing r by m, it worked fine.

:)

thanks, feedback is welcome! best regards Martín

On Fri, Jan 4, 2013 at 1:44 PM, H. Hirzel hannes.hirzel@gmail.com wrote:

...

"Load from the file" | r | r := FLMaterializer materializeFromFileNamed: '4coloredDots.FL'. r inspect. World addMorph: r.

I can't find the version 12371 in trunk. Can you give me the url?

Max

On 07.01.2013, at 03:06, Ken G. Brown kbrown@mac.com wrote:

I tried loading Fuel 1.8.1 into Squeak4.4-12327 via SqueakMap, and also get all green tests, 252 run. COG 2640 vm on Mac OS X 10.7.5. After switching to trunk and updating to 12371, the Fuel tests no longer run green, getting 242 errors.

When loading Fuel from SqueakMap, it complains that there is no version for my version of Squeak, and then says there is no published version at all, but seems to load if you click to try the latest unpublished version.

Ken G. Brown

On 2013-01-03, at 5:47 AM, H. Hirzel wrote:

...

Hello

[Test]

Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. All 252 tests are green.

Thank you, Max, for your porting work. This is a very useful asset to have in Squeak.

A thing which does not work: The example in the class comment of FLSerializer gives a walkback

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript with: [ Transcript show: 'a string' ].

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'.

Without having to serialize the block [ Transcript show: 'a string' ] it runs fine.

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript.

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'.

--Hannes

On 1/2/13, Max Leske maxleske@gmail.com wrote:

...

Thanks guys!

On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote:

...

...

I've added a package to SqueakMap, together with a release for 4.4. This means my name's attached to the package, but I've tried to make it clear it's not my work :)

No problemo, I just made it a Community Supported package. Now anyone will be able to add or update the release entry's.

Thanks, got it. The culprit is a change that apparently makes "Smalltalks globals" en Environment object now. So alot of the former messages to that object (originally an IdentityDictionary) now fail. I'm fixing it and will post back when I'm done.

Max

On 07.01.2013, at 06:25, "Ken G. Brown" kbrown@mac.com wrote:

When you set Squeak4.4-12327 to point to trunk for updates by doIt:

MCMcmUpdater defaultUpdateURL: 'http://source.squeak.org/trunk'.

then do Update Squeak from the Squeak menu, it updates to 12371 currently.

Ken

On 2013-01-06, at 10:18 PM, Max Leske wrote:

...

I can't find the version 12371 in trunk. Can you give me the url?

Max

On 07.01.2013, at 03:06, Ken G. Brown kbrown@mac.com wrote:

...

I tried loading Fuel 1.8.1 into Squeak4.4-12327 via SqueakMap, and also get all green tests, 252 run. COG 2640 vm on Mac OS X 10.7.5. After switching to trunk and updating to 12371, the Fuel tests no longer run green, getting 242 errors.

When loading Fuel from SqueakMap, it complains that there is no version for my version of Squeak, and then says there is no published version at all, but seems to load if you click to try the latest unpublished version.

Ken G. Brown

On 2013-01-03, at 5:47 AM, H. Hirzel wrote:

...

Hello

[Test]

Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. All 252 tests are green.

Thank you, Max, for your porting work. This is a very useful asset to have in Squeak.

A thing which does not work: The example in the class comment of FLSerializer gives a walkback

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript with: [ Transcript show: 'a string' ].

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'.

Without having to serialize the block [ Transcript show: 'a string' ] it runs fine.

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript.

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'.

--Hannes

On 1/2/13, Max Leske maxleske@gmail.com wrote:

...

Thanks guys!

On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote:

...

> I've added a package to SqueakMap, together with a release for 4.4. > This means my name's attached to the package, but I've tried to make > it clear it's not my work :)

No problemo, I just made it a Community Supported package. Now anyone will be able to add or update the release entry's.

On 7 January 2013 07:18, Max Leske maxleske@gmail.com wrote:

Because 4.4 is (apparently) still under development I will not update the configuration (SqueakMap release) at the moment. I did attach a fix for the globals problem though. There's another issue with IdentityDictionaries that I wasn't able to fix quickly, which shouldnt be a problem in most cases.

4.4 is only under development in the sense of "if you find a bug we'll fix it", but its active development is finished.

You know by now, but I'll repeat it here: Ken reported a failure in Squeak 4.5 (trunk). You can get the latest release from CI here: http://squeakci.org/job/ReleaseSqueakTrunk/lastSuccessfulBuild/artifact/targ...

frank

Cheers, Max

On 07.01.2013, at 07:28, Max Leske maxleske@gmail.com wrote:

...

Thanks, got it. The culprit is a change that apparently makes "Smalltalks globals" en Environment object now. So alot of the former messages to that object (originally an IdentityDictionary) now fail. I'm fixing it and will post back when I'm done.

Max

On 07.01.2013, at 06:25, "Ken G. Brown" kbrown@mac.com wrote:

...

When you set Squeak4.4-12327 to point to trunk for updates by doIt:

MCMcmUpdater defaultUpdateURL: 'http://source.squeak.org/trunk'.

then do Update Squeak from the Squeak menu, it updates to 12371 currently.

Ken

On 2013-01-06, at 10:18 PM, Max Leske wrote:

...

I can't find the version 12371 in trunk. Can you give me the url?

Max

On 07.01.2013, at 03:06, Ken G. Brown kbrown@mac.com wrote:

...

I tried loading Fuel 1.8.1 into Squeak4.4-12327 via SqueakMap, and also get all green tests, 252 run. COG 2640 vm on Mac OS X 10.7.5. After switching to trunk and updating to 12371, the Fuel tests no longer run green, getting 242 errors.

When loading Fuel from SqueakMap, it complains that there is no version for my version of Squeak, and then says there is no published version at all, but seems to load if you click to try the latest unpublished version.

Ken G. Brown

On 2013-01-03, at 5:47 AM, H. Hirzel wrote:

...

Hello

[Test]

Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. All 252 tests are green.

Thank you, Max, for your porting work. This is a very useful asset to have in Squeak.

A thing which does not work: The example in the class comment of FLSerializer gives a walkback

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript with: [ Transcript show: 'a string' ].

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'.

Without having to serialize the block [ Transcript show: 'a string' ] it runs fine.

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript.

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'.

--Hannes

On 1/2/13, Max Leske maxleske@gmail.com wrote: > Thanks guys! > > > On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote: > >>> I've added a package to SqueakMap, together with a release for 4.4. >>> This means my name's attached to the package, but I've tried to make >>> it clear it's not my work :) >> >> No problemo, I just made it a Community Supported package. Now anyone >> will be able to add or update the release entry's. >> > > >

On 7 January 2013 09:49, Max Leske maxleske@gmail.com wrote:

On 07.01.2013, at 10:37, Frank Shearar frank.shearar@gmail.com wrote:

...

On 7 January 2013 07:18, Max Leske maxleske@gmail.com wrote:

...

Because 4.4 is (apparently) still under development I will not update the configuration (SqueakMap release) at the moment. I did attach a fix for the globals problem though. There's another issue with IdentityDictionaries that I wasn't able to fix quickly, which shouldnt be a problem in most cases.

4.4 is only under development in the sense of "if you find a bug we'll fix it", but its active development is finished.

You know by now, but I'll repeat it here: Ken reported a failure in Squeak 4.5 (trunk). You can get the latest release from CI here: http://squeakci.org/job/ReleaseSqueakTrunk/lastSuccessfulBuild/artifact/targ...

Ah, ok. Didn't realize that "trunk" meant 4.5. Thanks for the clarification.

So: Fuel for 4.4 runs with all tests green, 4.5 not yet supported (will wait until it stabilizes).

Yes, that's an excellent idea. Thanks, Max!

frank

Max

...

frank

...

Cheers, Max

On 07.01.2013, at 07:28, Max Leske maxleske@gmail.com wrote:

...

Thanks, got it. The culprit is a change that apparently makes "Smalltalks globals" en Environment object now. So alot of the former messages to that object (originally an IdentityDictionary) now fail. I'm fixing it and will post back when I'm done.

Max

On 07.01.2013, at 06:25, "Ken G. Brown" kbrown@mac.com wrote:

...

When you set Squeak4.4-12327 to point to trunk for updates by doIt:

MCMcmUpdater defaultUpdateURL: 'http://source.squeak.org/trunk'.

then do Update Squeak from the Squeak menu, it updates to 12371 currently.

Ken

On 2013-01-06, at 10:18 PM, Max Leske wrote:

...

I can't find the version 12371 in trunk. Can you give me the url?

Max

On 07.01.2013, at 03:06, Ken G. Brown kbrown@mac.com wrote:

> I tried loading Fuel 1.8.1 into Squeak4.4-12327 via SqueakMap, and also get all green tests, 252 run. COG 2640 vm on Mac OS X 10.7.5. > After switching to trunk and updating to 12371, the Fuel tests no longer run green, getting 242 errors. > > When loading Fuel from SqueakMap, it complains that there is no version for my version of Squeak, and then says there is no published version at all, but seems to load if you click to try the latest unpublished version. > > Ken G. Brown > > > On 2013-01-03, at 5:47 AM, H. Hirzel wrote: > >> Hello >> >> [Test] >> >> Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. >> All 252 tests are green. >> >> Thank you, Max, for your porting work. This is a very useful asset to >> have in Squeak. >> >> >> >> A thing which does not work: >> The example in the class comment of FLSerializer gives a walkback >> >> >> | sourceArray loadedArray | >> sourceArray := >> Array >> with: 'a string' >> with: Transcript >> with: [ Transcript show: 'a string' ]. >> >> "Store to the file" >> FLSerializer serialize: sourceArray toFileNamed: 'example.FL'. >> >> "Load from the file" >> loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'. >> >> >> >> >> Without having to serialize the block [ Transcript show: 'a string' ] >> it runs fine. >> >> | sourceArray loadedArray | >> sourceArray := >> Array >> with: 'a string' >> with: Transcript. >> >> "Store to the file" >> FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'. >> >> "Load from the file" >> loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'. >> >> >> >> --Hannes >> >> >> >> >> >> On 1/2/13, Max Leske maxleske@gmail.com wrote: >>> Thanks guys! >>> >>> >>> On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote: >>> >>>>> I've added a package to SqueakMap, together with a release for 4.4. >>>>> This means my name's attached to the package, but I've tried to make >>>>> it clear it's not my work :) >>>> >>>> No problemo, I just made it a Community Supported package. Now anyone >>>> will be able to add or update the release entry's. >>>> >>> >>> >>> >> > >

On 7 January 2013 10:42, Max Leske maxleske@gmail.com wrote:

Could somone please update the SqueakMap release with the following:

Installer ss3 project: 'Fuel'; install: 'ConfigurationOfFuel-MarianoMartinezPeck.179'. (Smalltalk at: #ConfigurationOfFuel) load.

I tried to do it myself but I get a connection timeout (i did create a SqueakMap account for that a few minutes ago).

Done. The 1.8.1 version now uses the above installation.

(It might be useful to borrow an idea from the Java work. A maven version can be of the form 1.8.1-SNAPSHOT, which says "this is the thing that will become 1.8.1, once we're done." That lets one make a release that's mutable and, when one's happy, lock down the version by removing the "-SNAPSHOT" suffix. A released version ought never to change. (SM, I think, calls this a published release?)

frank

Thanks, Max

On 07.01.2013, at 11:07, Frank Shearar frank.shearar@gmail.com wrote:

...

On 7 January 2013 09:49, Max Leske maxleske@gmail.com wrote:

...

On 07.01.2013, at 10:37, Frank Shearar frank.shearar@gmail.com wrote:

...

On 7 January 2013 07:18, Max Leske maxleske@gmail.com wrote:

...

Because 4.4 is (apparently) still under development I will not update the configuration (SqueakMap release) at the moment. I did attach a fix for the globals problem though. There's another issue with IdentityDictionaries that I wasn't able to fix quickly, which shouldnt be a problem in most cases.

4.4 is only under development in the sense of "if you find a bug we'll fix it", but its active development is finished.

You know by now, but I'll repeat it here: Ken reported a failure in Squeak 4.5 (trunk). You can get the latest release from CI here: http://squeakci.org/job/ReleaseSqueakTrunk/lastSuccessfulBuild/artifact/targ...

Ah, ok. Didn't realize that "trunk" meant 4.5. Thanks for the clarification.

So: Fuel for 4.4 runs with all tests green, 4.5 not yet supported (will wait until it stabilizes).

Yes, that's an excellent idea. Thanks, Max!

frank

...

Max

...

frank

...

Cheers, Max

On 07.01.2013, at 07:28, Max Leske maxleske@gmail.com wrote:

...

Thanks, got it. The culprit is a change that apparently makes "Smalltalks globals" en Environment object now. So alot of the former messages to that object (originally an IdentityDictionary) now fail. I'm fixing it and will post back when I'm done.

Max

On 07.01.2013, at 06:25, "Ken G. Brown" kbrown@mac.com wrote:

> When you set Squeak4.4-12327 to point to trunk for updates by doIt: > > MCMcmUpdater defaultUpdateURL: 'http://source.squeak.org/trunk'. > > then do Update Squeak from the Squeak menu, it updates to 12371 currently. > > Ken > > On 2013-01-06, at 10:18 PM, Max Leske wrote: > >> I can't find the version 12371 in trunk. Can you give me the url? >> >> Max >> >> >> On 07.01.2013, at 03:06, Ken G. Brown kbrown@mac.com wrote: >> >>> I tried loading Fuel 1.8.1 into Squeak4.4-12327 via SqueakMap, and also get all green tests, 252 run. COG 2640 vm on Mac OS X 10.7.5. >>> After switching to trunk and updating to 12371, the Fuel tests no longer run green, getting 242 errors. >>> >>> When loading Fuel from SqueakMap, it complains that there is no version for my version of Squeak, and then says there is no published version at all, but seems to load if you click to try the latest unpublished version. >>> >>> Ken G. Brown >>> >>> >>> On 2013-01-03, at 5:47 AM, H. Hirzel wrote: >>> >>>> Hello >>>> >>>> [Test] >>>> >>>> Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. >>>> All 252 tests are green. >>>> >>>> Thank you, Max, for your porting work. This is a very useful asset to >>>> have in Squeak. >>>> >>>> >>>> >>>> A thing which does not work: >>>> The example in the class comment of FLSerializer gives a walkback >>>> >>>> >>>> | sourceArray loadedArray | >>>> sourceArray := >>>> Array >>>> with: 'a string' >>>> with: Transcript >>>> with: [ Transcript show: 'a string' ]. >>>> >>>> "Store to the file" >>>> FLSerializer serialize: sourceArray toFileNamed: 'example.FL'. >>>> >>>> "Load from the file" >>>> loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'. >>>> >>>> >>>> >>>> >>>> Without having to serialize the block [ Transcript show: 'a string' ] >>>> it runs fine. >>>> >>>> | sourceArray loadedArray | >>>> sourceArray := >>>> Array >>>> with: 'a string' >>>> with: Transcript. >>>> >>>> "Store to the file" >>>> FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'. >>>> >>>> "Load from the file" >>>> loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'. >>>> >>>> >>>> >>>> --Hannes >>>> >>>> >>>> >>>> >>>> >>>> On 1/2/13, Max Leske maxleske@gmail.com wrote: >>>>> Thanks guys! >>>>> >>>>> >>>>> On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote: >>>>> >>>>>>> I've added a package to SqueakMap, together with a release for 4.4. >>>>>>> This means my name's attached to the package, but I've tried to make >>>>>>> it clear it's not my work :) >>>>>> >>>>>> No problemo, I just made it a Community Supported package. Now anyone >>>>>> will be able to add or update the release entry's. >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> > >

On 8 January 2013 07:21, Max Leske maxleske@gmail.com wrote:

On 07.01.2013, at 12:09, Frank Shearar frank.shearar@gmail.com wrote:

...

On 7 January 2013 10:42, Max Leske maxleske@gmail.com wrote:

...

Could somone please update the SqueakMap release with the following:

Installer ss3 project: 'Fuel'; install: 'ConfigurationOfFuel-MarianoMartinezPeck.179'. (Smalltalk at: #ConfigurationOfFuel) load.

I tried to do it myself but I get a connection timeout (i did create a SqueakMap account for that a few minutes ago).

Done. The 1.8.1 version now uses the above installation.

Thanks Frank.

I added a CI job that loads Fuel into a Trunk image and, in a post Environments-fbs.13 world, we have Fuel almost perfectly working in 4.5. "Almost" means two test failures: http://build.squeak.org/job/ExternalPackage-Fuel/6/#showFailuresLink

Judging by the error message, they're failing for the same reason.

Any ideas?

#1: Error Message

Materialization error. Method UndefinedObject>>#DoIt not found. Stacktrace

[] in FLGlobalCompiledMethodCluster>>materializeInstanceWith: MethodDictionary>>at:ifAbsent: UndefinedObject class(Behavior)>>compiledMethodAt:ifAbsent: FLGlobalCompiledMethodCluster>>materializeInstanceWith: FLGlobalCompiledMethodCluster(FLIteratingCluster)>>materializeInstancesStepWith: FLMaterialization>>clusterInstancesStep [] in FLMaterialization>>instancesStep SmallInteger(Integer)>>timesRepeat: FLMaterialization>>instancesStep FLMaterialization>>run [] in FLMaterializer>>setDefaultMaterialization FLMaterializer>>materializeFrom: [] in FLBasicSerializationTest(FLSerializationTest)>>materialization FLMultiByteStreamStrategy>>readStreamDo: FLBasicSerializationTest(FLSerializationTest)>>materialization FLBasicSerializationTest(FLSerializationTest)>>materialized FLBasicSerializationTest(FLSerializationTest)>>resultOfSerializeAndMaterialize: FLBasicSerializationTest(FLSerializationTest)>>assertSerializationIdentityOf: FLBasicSerializationTest>>testSmalltalkGlobals FLBasicSerializationTest(TestCase)>>performTest

#2: Error Message

Materialization error. Method UndefinedObject>>#DoIt not found. Stacktrace

[] in FLGlobalCompiledMethodCluster>>materializeInstanceWith: MethodDictionary>>at:ifAbsent: UndefinedObject class(Behavior)>>compiledMethodAt:ifAbsent: FLGlobalCompiledMethodCluster>>materializeInstanceWith: FLGlobalCompiledMethodCluster(FLIteratingCluster)>>materializeInstancesStepWith: FLMaterialization>>clusterInstancesStep [] in FLMaterialization>>instancesStep SmallInteger(Integer)>>timesRepeat: FLMaterialization>>instancesStep FLMaterialization>>run [] in FLMaterializer>>setDefaultMaterialization FLMaterializer>>materializeFrom: FLMaterializer class>>materializeFromByteArray: FLInMemoryBasicSerializationTest>>materialized FLInMemoryBasicSerializationTest(FLSerializationTest)>>resultOfSerializeAndMaterialize: FLInMemoryBasicSerializationTest(FLSerializationTest)>>assertSerializationIdentityOf: FLInMemoryBasicSerializationTest(FLBasicSerializationTest)>>testSmalltalkGlobals FLInMemoryBasicSerializationTest(TestCase)>>performTest

frank

(I'm reposting this without the screen shots because the message was bounced for being to big…)

Frank,

I took a 4.4 image, pointed it to trunk and updated. Running the tests (CogVM) I do get the same two failures but with slightly different entries on the top of the stack. These entries vary depenging on which other tests are run simultaneously. However, they all seem to have in common, that they fail during #rehash. The point of failure is probably more or less random. I attached screen shots of the stack traces.

Stepping through the debugger, it looks like the problem might acutally occurr during serialization. If you look at the third screen shot you'll see that the instance variable "array" of the IdentityDictionary does not contain any associations and the array you see is actually the value of the association (see StandardScriptingSystem>>addCustomEventFor:name:help:targetMorphClass:).

I'll try to find out more.

Cheers, Max

On 12.02.2013, at 17:09, Frank Shearar frank.shearar@gmail.com wrote:

On 8 January 2013 07:21, Max Leske maxleske@gmail.com wrote:

...

On 07.01.2013, at 12:09, Frank Shearar frank.shearar@gmail.com wrote:

...

On 7 January 2013 10:42, Max Leske maxleske@gmail.com wrote:

...

Could somone please update the SqueakMap release with the following:

Installer ss3 project: 'Fuel'; install: 'ConfigurationOfFuel-MarianoMartinezPeck.179'. (Smalltalk at: #ConfigurationOfFuel) load.

I tried to do it myself but I get a connection timeout (i did create a SqueakMap account for that a few minutes ago).

Done. The 1.8.1 version now uses the above installation.

Thanks Frank.

I added a CI job that loads Fuel into a Trunk image and, in a post Environments-fbs.13 world, we have Fuel almost perfectly working in 4.5. "Almost" means two test failures: http://build.squeak.org/job/ExternalPackage-Fuel/6/#showFailuresLink

Judging by the error message, they're failing for the same reason.

Any ideas?

#1: Error Message

Materialization error. Method UndefinedObject>>#DoIt not found. Stacktrace

[] in FLGlobalCompiledMethodCluster>>materializeInstanceWith: MethodDictionary>>at:ifAbsent: UndefinedObject class(Behavior)>>compiledMethodAt:ifAbsent: FLGlobalCompiledMethodCluster>>materializeInstanceWith: FLGlobalCompiledMethodCluster(FLIteratingCluster)>>materializeInstancesStepWith: FLMaterialization>>clusterInstancesStep [] in FLMaterialization>>instancesStep SmallInteger(Integer)>>timesRepeat: FLMaterialization>>instancesStep FLMaterialization>>run [] in FLMaterializer>>setDefaultMaterialization FLMaterializer>>materializeFrom: [] in FLBasicSerializationTest(FLSerializationTest)>>materialization FLMultiByteStreamStrategy>>readStreamDo: FLBasicSerializationTest(FLSerializationTest)>>materialization FLBasicSerializationTest(FLSerializationTest)>>materialized FLBasicSerializationTest(FLSerializationTest)>>resultOfSerializeAndMaterialize: FLBasicSerializationTest(FLSerializationTest)>>assertSerializationIdentityOf: FLBasicSerializationTest>>testSmalltalkGlobals FLBasicSerializationTest(TestCase)>>performTest

#2: Error Message

Materialization error. Method UndefinedObject>>#DoIt not found. Stacktrace

[] in FLGlobalCompiledMethodCluster>>materializeInstanceWith: MethodDictionary>>at:ifAbsent: UndefinedObject class(Behavior)>>compiledMethodAt:ifAbsent: FLGlobalCompiledMethodCluster>>materializeInstanceWith: FLGlobalCompiledMethodCluster(FLIteratingCluster)>>materializeInstancesStepWith: FLMaterialization>>clusterInstancesStep [] in FLMaterialization>>instancesStep SmallInteger(Integer)>>timesRepeat: FLMaterialization>>instancesStep FLMaterialization>>run [] in FLMaterializer>>setDefaultMaterialization FLMaterializer>>materializeFrom: FLMaterializer class>>materializeFromByteArray: FLInMemoryBasicSerializationTest>>materialized FLInMemoryBasicSerializationTest(FLSerializationTest)>>resultOfSerializeAndMaterialize: FLInMemoryBasicSerializationTest(FLSerializationTest)>>assertSerializationIdentityOf: FLInMemoryBasicSerializationTest(FLBasicSerializationTest)>>testSmalltalkGlobals FLInMemoryBasicSerializationTest(TestCase)>>performTest

frank

Hi Just looking at the test that is failing (#testSmalltalkGlobals) and the error (a DoIt method can't be materialized), it makes me wonder why a method is being serialized in this method. There is the problem, I guess.

To reproduce what the test is serializing you can inspect:

| anObject aStream | anObject := Smalltalk globals. aStream := (MultiByteBinaryOrTextStream on: '') binary.

(FLSerializer newDefault serialize: anObject on: aStream) objects.

I get this in Pharo:

an Array(a SystemDictionary(lots of globals) true false nil)

What do you get?

Maybe it has to be with the environment? I have no idea of that.

Best regards, Martin

On Wed, Feb 13, 2013 at 10:56 AM, Frank Shearar frank.shearar@gmail.com wrote:

On 13 February 2013 08:45, Max Leske maxleske@gmail.com wrote:

...

(I'm reposting this without the screen shots because the message was bounced for being to big…)

Frank,

I took a 4.4 image, pointed it to trunk and updated. Running the tests (CogVM) I do get the same two failures but with slightly different entries on the top of the stack. These entries vary depenging on which other tests are run simultaneously. However, they all seem to have in common, that they fail during #rehash. The point of failure is probably more or less random. I attached screen shots of the stack traces.

Stepping through the debugger, it looks like the problem might acutally occurr during serialization. If you look at the third screen shot you'll see that the instance variable "array" of the IdentityDictionary does not contain any associations and the array you see is actually the value of the association (see StandardScriptingSystem>>addCustomEventFor:name:help:targetMorphClass:).

I'll try to find out more.

Thanks for looking into this, Max. If you want to precisely (modulo operating system) reproduce the setup causing the issue you can run "./run-test.sh Fuel" once you've checked out https://github.com/frankshearar/squeak-ci/. You might need to comment out the `WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: false andQuit: true ].` line.

frank

...

Cheers, Max

On 12.02.2013, at 17:09, Frank Shearar frank.shearar@gmail.com wrote:

On 8 January 2013 07:21, Max Leske maxleske@gmail.com wrote:

On 07.01.2013, at 12:09, Frank Shearar frank.shearar@gmail.com wrote:

On 7 January 2013 10:42, Max Leske maxleske@gmail.com wrote:

Could somone please update the SqueakMap release with the following:

Installer ss3 project: 'Fuel'; install: 'ConfigurationOfFuel-MarianoMartinezPeck.179'. (Smalltalk at: #ConfigurationOfFuel) load.

I tried to do it myself but I get a connection timeout (i did create a SqueakMap account for that a few minutes ago).

Done. The 1.8.1 version now uses the above installation.

Thanks Frank.

I added a CI job that loads Fuel into a Trunk image and, in a post Environments-fbs.13 world, we have Fuel almost perfectly working in 4.5. "Almost" means two test failures: http://build.squeak.org/job/ExternalPackage-Fuel/6/#showFailuresLink

Judging by the error message, they're failing for the same reason.

Any ideas?

#1: Error Message

Materialization error. Method UndefinedObject>>#DoIt not found. Stacktrace

[] in FLGlobalCompiledMethodCluster>>materializeInstanceWith: MethodDictionary>>at:ifAbsent: UndefinedObject class(Behavior)>>compiledMethodAt:ifAbsent: FLGlobalCompiledMethodCluster>>materializeInstanceWith: FLGlobalCompiledMethodCluster(FLIteratingCluster)>>materializeInstancesStepWith: FLMaterialization>>clusterInstancesStep [] in FLMaterialization>>instancesStep SmallInteger(Integer)>>timesRepeat: FLMaterialization>>instancesStep FLMaterialization>>run [] in FLMaterializer>>setDefaultMaterialization FLMaterializer>>materializeFrom: [] in FLBasicSerializationTest(FLSerializationTest)>>materialization FLMultiByteStreamStrategy>>readStreamDo: FLBasicSerializationTest(FLSerializationTest)>>materialization FLBasicSerializationTest(FLSerializationTest)>>materialized FLBasicSerializationTest(FLSerializationTest)>>resultOfSerializeAndMaterialize: FLBasicSerializationTest(FLSerializationTest)>>assertSerializationIdentityOf: FLBasicSerializationTest>>testSmalltalkGlobals FLBasicSerializationTest(TestCase)>>performTest

#2: Error Message

Materialization error. Method UndefinedObject>>#DoIt not found. Stacktrace

[] in FLGlobalCompiledMethodCluster>>materializeInstanceWith: MethodDictionary>>at:ifAbsent: UndefinedObject class(Behavior)>>compiledMethodAt:ifAbsent: FLGlobalCompiledMethodCluster>>materializeInstanceWith: FLGlobalCompiledMethodCluster(FLIteratingCluster)>>materializeInstancesStepWith: FLMaterialization>>clusterInstancesStep [] in FLMaterialization>>instancesStep SmallInteger(Integer)>>timesRepeat: FLMaterialization>>instancesStep FLMaterialization>>run [] in FLMaterializer>>setDefaultMaterialization FLMaterializer>>materializeFrom: FLMaterializer class>>materializeFromByteArray: FLInMemoryBasicSerializationTest>>materialized FLInMemoryBasicSerializationTest(FLSerializationTest)>>resultOfSerializeAndMaterialize: FLInMemoryBasicSerializationTest(FLSerializationTest)>>assertSerializationIdentityOf: FLInMemoryBasicSerializationTest(FLBasicSerializationTest)>>testSmalltalkGlobals FLInMemoryBasicSerializationTest(TestCase)>>performTest

frank

On 14.02.2013, at 16:15, Frank Shearar frank.shearar@gmail.com wrote:

On 14 February 2013 10:30, Martin Dias tinchodias@gmail.com wrote:

...

Hi Just looking at the test that is failing (#testSmalltalkGlobals) and the error (a DoIt method can't be materialized), it makes me wonder why a method is being serialized in this method. There is the problem, I guess.

To reproduce what the test is serializing you can inspect:

| anObject aStream | anObject := Smalltalk globals. aStream := (MultiByteBinaryOrTextStream on: '') binary.

(FLSerializer newDefault serialize: anObject on: aStream) objects.

I get this in Pharo:

an Array(a SystemDictionary(lots of globals) true false nil)

What does `Smalltalk globals` return in Pharo? Does it directly match what #objects returns?

A SystemDictionary (IdentityDictionary) that matches symbols to classes or globals. (That's in 1.4)

...

What do you get?

Maybe it has to be with the environment? I have no idea of that.

It might. I get an Array with a whole pile of stuff. I _don't_ have a SystemDirectory with a bunch of stuff; I see symbols, associations, classes, ...

So it might be that these two tests no longer make sense in Squeak 4.5? `Smalltalk globals` is an Environment in Squeak 4.5. Do things need custom serialisers/deserialisers?

I think they still make sense. The Smalltalk global still does contain classes and globals but grouped better (correct?). Usually, there's no need for custom serialization if an object inherits from Object (and that seems to be the case with Environment AFAICT). In any case, it should be possible without problems to serialize Enviroments, so the best thing would be to first write a test that asserts serializability / materializability of Environemnt and then go from there. I'll write one later this afternoon.

Max

frank

...

Best regards, Martin

On Wed, Feb 13, 2013 at 10:56 AM, Frank Shearar frank.shearar@gmail.com wrote:

...

On 13 February 2013 08:45, Max Leske maxleske@gmail.com wrote:

...

(I'm reposting this without the screen shots because the message was bounced for being to big…)

Frank,

I took a 4.4 image, pointed it to trunk and updated. Running the tests (CogVM) I do get the same two failures but with slightly different entries on the top of the stack. These entries vary depenging on which other tests are run simultaneously. However, they all seem to have in common, that they fail during #rehash. The point of failure is probably more or less random. I attached screen shots of the stack traces.

Stepping through the debugger, it looks like the problem might acutally occurr during serialization. If you look at the third screen shot you'll see that the instance variable "array" of the IdentityDictionary does not contain any associations and the array you see is actually the value of the association (see StandardScriptingSystem>>addCustomEventFor:name:help:targetMorphClass:).

I'll try to find out more.

Thanks for looking into this, Max. If you want to precisely (modulo operating system) reproduce the setup causing the issue you can run "./run-test.sh Fuel" once you've checked out https://github.com/frankshearar/squeak-ci/. You might need to comment out the `WorldState addDeferredUIMessage: [ SmalltalkImage current snapshot: false andQuit: true ].` line.

frank

...

Cheers, Max

On 12.02.2013, at 17:09, Frank Shearar frank.shearar@gmail.com wrote:

On 8 January 2013 07:21, Max Leske maxleske@gmail.com wrote:

On 07.01.2013, at 12:09, Frank Shearar frank.shearar@gmail.com wrote:

On 7 January 2013 10:42, Max Leske maxleske@gmail.com wrote:

Could somone please update the SqueakMap release with the following:

Installer ss3 project: 'Fuel'; install: 'ConfigurationOfFuel-MarianoMartinezPeck.179'. (Smalltalk at: #ConfigurationOfFuel) load.

I tried to do it myself but I get a connection timeout (i did create a SqueakMap account for that a few minutes ago).

Done. The 1.8.1 version now uses the above installation.

Thanks Frank.

I added a CI job that loads Fuel into a Trunk image and, in a post Environments-fbs.13 world, we have Fuel almost perfectly working in 4.5. "Almost" means two test failures: http://build.squeak.org/job/ExternalPackage-Fuel/6/#showFailuresLink

Judging by the error message, they're failing for the same reason.

Any ideas?

#1: Error Message

Materialization error. Method UndefinedObject>>#DoIt not found. Stacktrace

[] in FLGlobalCompiledMethodCluster>>materializeInstanceWith: MethodDictionary>>at:ifAbsent: UndefinedObject class(Behavior)>>compiledMethodAt:ifAbsent: FLGlobalCompiledMethodCluster>>materializeInstanceWith: FLGlobalCompiledMethodCluster(FLIteratingCluster)>>materializeInstancesStepWith: FLMaterialization>>clusterInstancesStep [] in FLMaterialization>>instancesStep SmallInteger(Integer)>>timesRepeat: FLMaterialization>>instancesStep FLMaterialization>>run [] in FLMaterializer>>setDefaultMaterialization FLMaterializer>>materializeFrom: [] in FLBasicSerializationTest(FLSerializationTest)>>materialization FLMultiByteStreamStrategy>>readStreamDo: FLBasicSerializationTest(FLSerializationTest)>>materialization FLBasicSerializationTest(FLSerializationTest)>>materialized FLBasicSerializationTest(FLSerializationTest)>>resultOfSerializeAndMaterialize: FLBasicSerializationTest(FLSerializationTest)>>assertSerializationIdentityOf: FLBasicSerializationTest>>testSmalltalkGlobals FLBasicSerializationTest(TestCase)>>performTest

#2: Error Message

Materialization error. Method UndefinedObject>>#DoIt not found. Stacktrace

[] in FLGlobalCompiledMethodCluster>>materializeInstanceWith: MethodDictionary>>at:ifAbsent: UndefinedObject class(Behavior)>>compiledMethodAt:ifAbsent: FLGlobalCompiledMethodCluster>>materializeInstanceWith: FLGlobalCompiledMethodCluster(FLIteratingCluster)>>materializeInstancesStepWith: FLMaterialization>>clusterInstancesStep [] in FLMaterialization>>instancesStep SmallInteger(Integer)>>timesRepeat: FLMaterialization>>instancesStep FLMaterialization>>run [] in FLMaterializer>>setDefaultMaterialization FLMaterializer>>materializeFrom: FLMaterializer class>>materializeFromByteArray: FLInMemoryBasicSerializationTest>>materialized FLInMemoryBasicSerializationTest(FLSerializationTest)>>resultOfSerializeAndMaterialize: FLInMemoryBasicSerializationTest(FLSerializationTest)>>assertSerializationIdentityOf: FLInMemoryBasicSerializationTest(FLBasicSerializationTest)>>testSmalltalkGlobals FLInMemoryBasicSerializationTest(TestCase)>>performTest

frank

On Thu, Feb 14, 2013 at 10:18 PM, Max Leske maxleske@gmail.com wrote:

I've written some tests and have the following to report: serializing / materializing Environments is not a problem at all. Even serializing / materializing a shallow copy of "Smalltalk globals" works. The only thing that doesn't work is the materialization of that specific instance of Environment that is returned by "Smalltalk globals". The only difference between that instance and a shallow copy of it is the set of references TO each instance, right? But that shouldn't make any difference to Fuel (AFAIK).

Mariano, Martin? Any ideas?

You could put a halt in FLAnalysis>>trace: and watch there why other objects than the environment is traced. Or you could try FLGraphViewBuilder explained in the debug doc, to visually explore the graph.

I attached the tests.

Ah great! Next time I'll try reading the full thread before replying!

frank

On 07 Jan 2013, at 6:28, Max Leske maxleske@gmail.com wrote:

Thanks, got it. The culprit is a change that apparently makes "Smalltalks globals" en Environment object now. So alot of the former messages to that object (originally an IdentityDictionary) now fail. I'm fixing it and will post back when I'm done.

Max

On 07.01.2013, at 06:25, "Ken G. Brown" kbrown@mac.com wrote:

...

When you set Squeak4.4-12327 to point to trunk for updates by doIt:

MCMcmUpdater defaultUpdateURL: 'http://source.squeak.org/trunk'.

then do Update Squeak from the Squeak menu, it updates to 12371 currently.

Ken

On 2013-01-06, at 10:18 PM, Max Leske wrote:

...

I can't find the version 12371 in trunk. Can you give me the url?

Max

On 07.01.2013, at 03:06, Ken G. Brown kbrown@mac.com wrote:

...

I tried loading Fuel 1.8.1 into Squeak4.4-12327 via SqueakMap, and also get all green tests, 252 run. COG 2640 vm on Mac OS X 10.7.5. After switching to trunk and updating to 12371, the Fuel tests no longer run green, getting 242 errors.

When loading Fuel from SqueakMap, it complains that there is no version for my version of Squeak, and then says there is no published version at all, but seems to load if you click to try the latest unpublished version.

Ken G. Brown

On 2013-01-03, at 5:47 AM, H. Hirzel wrote:

...

Hello

[Test]

Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. All 252 tests are green.

Thank you, Max, for your porting work. This is a very useful asset to have in Squeak.

A thing which does not work: The example in the class comment of FLSerializer gives a walkback

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript with: [ Transcript show: 'a string' ].

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'.

Without having to serialize the block [ Transcript show: 'a string' ] it runs fine.

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript.

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'.

--Hannes

On 1/2/13, Max Leske maxleske@gmail.com wrote:

...

Thanks guys!

On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote:

>> I've added a package to SqueakMap, together with a release for 4.4. >> This means my name's attached to the package, but I've tried to make >> it clear it's not my work :) > > No problemo, I just made it a Community Supported package. Now anyone > will be able to add or update the release entry's. >

On 07 Jan 2013, at 2:06, "Ken G. Brown" kbrown@mac.com wrote:

I tried loading Fuel 1.8.1 into Squeak4.4-12327 via SqueakMap, and also get all green tests, 252 run. COG 2640 vm on Mac OS X 10.7.5. After switching to trunk and updating to 12371, the Fuel tests no longer run green, getting 242 errors.

When loading Fuel from SqueakMap, it complains that there is no version for my version of Squeak, and then says there is no published version at all, but seems to load if you click to try the latest unpublished version.

Thanks for the report, Ken. There are as yet no 4.5 releases at all. Not surprising, given it's only just started.

I would _guess_ the regression's because of the Environments changes, which are pretty fundamental changes. Would you mind detailing the failures? Which tests, walkbacks and so on would be greatly appreciated!

frank

Ken G. Brown

On 2013-01-03, at 5:47 AM, H. Hirzel wrote:

...

Hello

[Test]

Loading Fuel 1.8.1 into http://ftp.squeak.org/4.4/Squeak4.4-12327.zip runs fine. All 252 tests are green.

Thank you, Max, for your porting work. This is a very useful asset to have in Squeak.

A thing which does not work: The example in the class comment of FLSerializer gives a walkback

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript with: [ Transcript show: 'a string' ].

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example.FL'.

Without having to serialize the block [ Transcript show: 'a string' ] it runs fine.

| sourceArray loadedArray | sourceArray := Array with: 'a string' with: Transcript.

"Store to the file" FLSerializer serialize: sourceArray toFileNamed: 'example0.FL'.

"Load from the file" loadedArray := FLMaterializer materializeFromFileNamed: 'example0.FL'.

--Hannes

On 1/2/13, Max Leske maxleske@gmail.com wrote:

...

Thanks guys!

On 02.01.2013, at 20:13, Chris Muller asqueaker@gmail.com wrote:

...

...

I've added a package to SqueakMap, together with a release for 4.4. This means my name's attached to the package, but I've tried to make it clear it's not my work :)

No problemo, I just made it a Community Supported package. Now anyone will be able to add or update the release entry's.

On 7 January 2013 15:43, Chris Muller asqueaker@gmail.com wrote:

Mornin'.

...

...

When loading Fuel from SqueakMap, it complains that there is no version for my version of Squeak, and then says there is no published version at all, but seems to load if you click to try the latest unpublished version.

Thanks for the report, Ken. There are as yet no 4.5 releases at all. Not surprising, given it's only just started.

This is what the (head) release is (supposed to be) for -- it's a separate Release which always just loads the latest versions and therefore almost never needs updating.

Yes, but (head) also needs to be marked as compatible with a Squeak version. It doesn't make sense for (head) to be compatible with _all_ versions either, just ones more recent than, say, the latest non-(head) release. So FFI has a (head) that's marked as compatible with 4.3, for instance. Either we need an automatic mechanism for (head) versions to gain compatibility with the latest Squeak release, or people have to fix things themselves.

(Having the ability to multiselect Squeak versions in the SMReleaseBrowser would aid the manual approach.)

frank

This is before I directed my image to point to trunk. I start with a fresh Squeak4.4-12327, open SqueakMap, select Squeak 4.4, then select Fuel. When I click Install, I get: The package has no published release for your Squeak version, try releases for any Squeak version? Yes, No.

Then if I click 'Yes', I get: The package has no published release at all, take the latest of the unpublished releases? Yes, No.

Clicking 'Yes', allows the Install to proceed.

Apparently this has something to do with selecting Fuel in the list without clicking the dropdown arrow to allow selecting version 1.8.1. If I do the Install when 1.8.1 is selected, it proceeds without the notifiers.

Ken G. Brown

On 2013-01-07, at 8:43 AM, Chris Muller wrote:

Mornin'.

...

...

When loading Fuel from SqueakMap, it complains that there is no version for my version of Squeak, and then says there is no published version at all, but seems to load if you click to try the latest unpublished version.

Thanks for the report, Ken. There are as yet no 4.5 releases at all. Not surprising, given it's only just started.

This is what the (head) release is (supposed to be) for -- it's a separate Release which always just loads the latest versions and therefore almost never needs updating.

On 7 January 2013 16:46, Chris Muller ma.chris.m@gmail.com wrote:

On Mon, Jan 7, 2013 at 10:14 AM, Ken G. Brown kbrown@mac.com wrote:

...

This is before I directed my image to point to trunk. I start with a fresh Squeak4.4-12327, open SqueakMap, select Squeak 4.4, then select Fuel. When I click Install, I get: The package has no published release for your Squeak version, try releases for any Squeak version? Yes, No.

Then if I click 'Yes', I get: The package has no published release at all, take the latest of the unpublished releases? Yes, No.

Clicking 'Yes', allows the Install to proceed.

IMO, the whole "Published" attribute should be ripped out of SqueakMap because it does not seem useful at all.

Well, its utility is only in "this version is considered immutable". The Ruby guys use a convention of 1.2.dev and the Java/Scala/Clojure guys (because they all share most of the same toolchain) use a convention of 1.2-SNAPSHOT.

We could just do that. Users would expect a version of 1.2-SNAPSHOT to possibly change, while expecting that eventually an immutable 1.2 would be released.

frank

You're relying then on the good/competent intentions of every flawed human with commit rights. The ability to just fix a typo is the inability for anyone to know what code you're actually running. Is that Foo 1.1 with that ostensibly inconsequential fix that broke an edge case, or the other one?

frank

On 09 Jan 2013, at 16:52, Chris Muller asqueaker@gmail.com wrote:

...

Well, its utility is only in "this version is considered immutable". The Ruby guys use a convention of 1.2.dev and the Java/Scala/Clojure guys (because they all share most of the same toolchain) use a convention of 1.2-SNAPSHOT.

We could just do that. Users would expect a version of 1.2-SNAPSHOT to possibly change, while expecting that eventually an immutable 1.2 would be released.

I guess I never understood self-imposed, artificial restrictions. If we want something not to change, then don't change it. OTOH, if a silly typo bug that went undiscovered appears in something that wasn't intended to change, wouldn't it be ok to just fix that typo?

What's the use-case for needing absolute immutability, including inability to fix a typo? Security -- verifying a digitally signed package is the only one I can come up with.. Is that it?

But I understand your point -- but then I guess a digital sig really is the proper solution then, since a "published" attribute could be easily gotten around (which is why I see it as an artificial barrier).

Not a digital sig, just a hash. Which SM already has!!!

On 09-01-2013, at 9:46 AM, Chris Muller asqueaker@gmail.com wrote:

...

You're relying then on the good/competent intentions of every flawed human with commit rights. The ability to just fix a typo is the inability for anyone to know what code you're actually running. Is that Foo 1.1 with that ostensibly inconsequential fix that broke an edge case, or the other one?

Well, one would only fix an _obvious_ typo that could not possibly break any edge cases.

My experience suggests that there is no such thing, sadly. Part of the problem is (or at least, was, in the past) that the simple process of building an install package isn't simple enough to trust fully. I'm thinking of distant past here, the days of VisualWorks 1.0 and Windows 3.1 and InstallShield and ritual self-abuse to get it all to hang together.

The process at ParcPlace back then was relatively simple and sensible; when you start making release candidates, you start packaging them and the testing has to include installing them from those packages every release candidate is run through the test suite of choice after testing you gather together and discuss found problems and decide if any are worth the work of 'cracking the release' to fix, re-package and re-test. eventually you get too tired to do any more and release it

I guess it was slightly complicated by the practise of condensing the sources for every release, so any cracking that required a change to the image that could add anything to the changelog then required re-doing the condense.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Lightbulb over his head is burned out.

SqueakSource is deprecated.

"ATTENTION! The creation of new projects has been disabled. If you would like to create a new project please consider moving to: http://ss3.gemstone.com/. It is still possible to access, commit, and edit existing projects."

Try: http://ss3.gemstone.com/ss/Fuel.html and: http://rmod.lille.inria.fr/web/pier/software/Fuel.

-- View this message in context: http://forum.world.st/ANN-Fuel-1-8-1-tp4661609p4661745.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

Stéphane Rollandin wrote

...

SqueakSource is deprecated.

"ATTENTION! The creation of new projects has been disabled.

This does not apply to me: I do not want to create a new project, I only want to download existing code. Thanks for the pointer though.

Stef

You want to download an existing project with /new/ code. ;)

-- View this message in context: http://forum.world.st/ANN-Fuel-1-8-1-tp4661609p4661752.html Sent from the Squeak - Dev mailing list archive at Nabble.com.