Thanks Mariano. I can confirm that it works out of the box in Squeak 4.3. I have a 3.9 image though… :) I'll let you know if I get it running on there (might be simpler to use a newer image though). On 01.10.2012, at 22:51, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Mon, Oct 1, 2012 at 10:44 PM, Max Leske <maxleske@gmail.com> wrote: I wanted some info on Fuel but the rmod page is down…

Anyways, I read that Mariano got Fuel running on Squeak. Is there an official version for Squeak?

Hi Max. It should just work. The ConfigurationOfFuel should automatically load the needed compatibility packages. I tried in 4.3 and 4.1 (if I remember correctly).

-- Mariano http://marianopeck.wordpress.com

No, this time it's not for seaside hosting. It's another application that we cannot port to Pharo at the moment. Max On 01.10.2012, at 23:07, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Mon, Oct 1, 2012 at 11:04 PM, Max Leske <maxleske@gmail.com> wrote: Thanks Mariano.

I can confirm that it works out of the box in Squeak 4.3.

:)

I have a 3.9 image though… :)

I'll let you know if I get it running on there

Let me know if I can help. If you make it work, we can do a compatibility package and put it in ConfigurationOfFUel so that it loads automatically in Squeak 3.9.

(might be simpler to use a newer image though).

Well, it looks this is for seasidehosting? in either case, why not updating to Pharo? because of the custom network primitives you have?

On 01.10.2012, at 22:51, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

On Mon, Oct 1, 2012 at 10:44 PM, Max Leske <maxleske@gmail.com> wrote: I wanted some info on Fuel but the rmod page is down…

Anyways, I read that Mariano got Fuel running on Squeak. Is there an official version for Squeak?

Hi Max. It should just work. The ConfigurationOfFuel should automatically load the needed compatibility packages. I tried in 4.3 and 4.1 (if I remember correctly).

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

Doesn't work because of syntax errors. We're trying to port to 4.3 now, at least we can load Fuel there :) Thanks! On 02.10.2012, at 10:58, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Tue, Oct 2, 2012 at 6:48 AM, Max Leske <maxleske@gmail.com> wrote: No, this time it's not for seaside hosting. It's another application that we cannot port to Pharo at the moment.

Ok. What you should try to do (since I guess Metacello does not work there) is to manually load this (the order is important):

ConfigurationOfFuel project stableVersion record

a MetacelloNullRecordingMCSpecLoader(linear load : linear load : 1.8 [ConfigurationOfFuel] load : Fuel-MartinDias.685 load : FuelTests-MartinDias.267 load : FuelCompatibilityBeforePharo20-MartinDias.4 load : FuelCompatibilityBeforePharo14-MartinDias.3 load : FuelCompatibilityBeforePharo13-MarianoMartinezPeck.3 load : FuelCompatibilityBeforePharo12-MartinDias.8 load : FuelCompatibilityForSqueak-MMP.4 load : FuelTestsCompatibilityForSqueak)

and try to see what happens :)

Max

On 01.10.2012, at 23:07, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

On Mon, Oct 1, 2012 at 11:04 PM, Max Leske <maxleske@gmail.com> wrote: Thanks Mariano.

I can confirm that it works out of the box in Squeak 4.3.

:)

I have a 3.9 image though… :)

I'll let you know if I get it running on there

Let me know if I can help. If you make it work, we can do a compatibility package and put it in ConfigurationOfFUel so that it loads automatically in Squeak 3.9.

(might be simpler to use a newer image though).

Well, it looks this is for seasidehosting? in either case, why not updating to Pharo? because of the custom network primitives you have?

On 01.10.2012, at 22:51, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

On Mon, Oct 1, 2012 at 10:44 PM, Max Leske <maxleske@gmail.com> wrote: I wanted some info on Fuel but the rmod page is down…

Anyways, I read that Mariano got Fuel running on Squeak. Is there an official version for Squeak?

Hi Max. It should just work. The ConfigurationOfFuel should automatically load the needed compatibility packages. I tried in 4.3 and 4.1 (if I remember correctly).

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

On Tue, Oct 2, 2012 at 12:02 PM, Edgar J. De Cleene <edgardec2005@gmail.com>wrote:

On 10/2/12 6:36 AM, "Max Leske" <maxleske@gmail.com> wrote:

Ok. What you should try to do (since I guess Metacello does not work there) is to manually load this (the order is important):

ConfigurationOfFuel project stableVersion record

a MetacelloNullRecordingMCSpecLoader(linear load : linear load : 1.8 [ConfigurationOfFuel] load : Fuel-MartinDias.685 load : FuelTests-MartinDias.267 load : FuelCompatibilityBeforePharo20-MartinDias.4 load : FuelCompatibilityBeforePharo14-MartinDias.3 load : FuelCompatibilityBeforePharo13-MarianoMartinezPeck.3 load : FuelCompatibilityBeforePharo12-MartinDias.8 load : FuelCompatibilityForSqueak-MMP.4 load : FuelTestsCompatibilityForSqueak)

Hi Mariano: Repository which you are using ?

Hi Edgar, 'http://ss3.gemstone.com/ss/Fuel'

I reading http://marianopeck.wordpress.com/ , waiting Tanker could be adapted to Squeak some day.

Hopefully, I don't have time to do it myself but as always, I am happy to help is someone wants to do it. It should be very easy actually.

Edgar

-- Mariano http://marianopeck.wordpress.com

On Tue, Oct 2, 2012 at 12:10 PM, Frank Shearar <frank.shearar@gmail.com>wrote:

On 2 October 2012 11:07, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

...

On Tue, Oct 2, 2012 at 12:02 PM, Edgar J. De Cleene <

edgardec2005@gmail.com>

...

wrote:

...

On 10/2/12 6:36 AM, "Max Leske" <maxleske@gmail.com> wrote:

Ok. What you should try to do (since I guess Metacello does not work there) is to manually load this (the order is important):

ConfigurationOfFuel project stableVersion record

a MetacelloNullRecordingMCSpecLoader(linear load : linear load : 1.8 [ConfigurationOfFuel] load : Fuel-MartinDias.685 load : FuelTests-MartinDias.267 load : FuelCompatibilityBeforePharo20-MartinDias.4 load : FuelCompatibilityBeforePharo14-MartinDias.3 load : FuelCompatibilityBeforePharo13-MarianoMartinezPeck.3 load : FuelCompatibilityBeforePharo12-MartinDias.8 load : FuelCompatibilityForSqueak-MMP.4 load : FuelTestsCompatibilityForSqueak)

Hi Mariano: Repository which you are using ?

Hi Edgar,

'http://ss3.gemstone.com/ss/Fuel'

...

I reading http://marianopeck.wordpress.com/ , waiting Tanker could be adapted to Squeak some day.

Hopefully, I don't have time to do it myself but as always, I am happy to help is someone wants to do it. It should be very easy actually.

Unless someone beats me to it, I'll port it. (I have other things on my plate right now so if you (the reader, not necessarily Edgar) have need of Tanker in Squeak, by all means start without me and I'll pitch in when I have a chance.)

Good. Before starting let me know that I can send you what I thought about how we could do it.

frank

...

...

Edgar

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com

Here's a possibly related question: after having analysed a large object graph, I get exceptions in FLEncoder>>encodeReferenceTo:. When I look at the values #largeIdentityHash generates for that object, then the one looked up in the dictionary (that is used by the debugger) is different than the one I get when asking the object manually. Incidentally, the manually retrieved value would lead to a match in the lookup. Could there be something weird going on with the hashes? BTW, the VM is a SqueakVM 4.2.5beta1U. I'll also try with a CogVM later and let you know if it worked. Cheers, Max On 07.10.2012, at 14:38, Edgar J. De Cleene <edgardec2005@gmail.com> wrote:

Hi Mariano:

Just have Fuel loaded into Squeak. Trying to understand , first I run Sunit The test says 240 run, 231 passes, 2 expected failures, 6 failures, 0 errors, 1 unexpected passes

failures

FLBasicSerializationTest>>#testDate FLBasicSerializationTest>>#testGradientFillStyle FLInMemoryBasicSerializationTest>>#testDate FLInMemoryBasicSerializationTest>>#testGradientFillStyle FLMigrationTest>>#testFormatFixedToVariable FLMigrationTest>>#testFormatVariableToFixed FLWeakObjectsTest>>#testAssociationWithWeakFinalizationList

In testDate, clicking in debugger for materialized and for anObject both shows as Date objects with 14 May 2002 as value. Could tell why anObject = materialized evaluates to false ?

Edgar

One cool thing: Cog is roughly 10 times (!!) faster than the SqueakVM I used :D On the down side, I still have the problem described before. Here's some more detail: Screenshot 1 shows the debugger, opened on the method that signalled the error. It also shows the inspector I used to get the #largeIdentityHash of the object (the value is 2062). Screenshot 2 shows a second debugger, that I opened on the expression "objectsIndexes at: anObject". The value of the expression "key largeIdentityHash" is 182 (when it should be 2062). Cheers, Max On 07.10.2012, at 15:34, "Edgar J. De Cleene" <edgardec2005@gmail.com> wrote:

On 10/7/12 10:16 AM, "Max Leske" <maxleske@gmail.com> wrote:

...

Here's a possibly related question: after having analysed a large object graph, I get exceptions in FLEncoder>>encodeReferenceTo:. When I look at the values #largeIdentityHash generates for that object, then the one looked up in the dictionary (that is used by the debugger) is different than the one I get when asking the object manually. Incidentally, the manually retrieved value would lead to a match in the lookup. Could there be something weird going on with the hashes?

BTW, the VM is a SqueakVM 4.2.5beta1U. I'll also try with a CogVM later and let you know if it worked.

Cheers, Max

Thanks, is a good pointer. In my case I try with last CogVM http://www.mirandabanda.org/files/Cog/VM/VM.r2585/

Edgar

The two objects I looked at where a string and an OrderedCollection. I wouldn't conclude that the problem is class specific... On 07.10.2012, at 16:12, "Edgar J. De Cleene" <edgardec2005@gmail.com> wrote:

On 10/7/12 10:51 AM, "Max Leske" <maxleske@gmail.com> wrote:

Following you example, in Squeak FLBasicSerializationTest>>#testDate

materialized largeIdentityHash = 2571

anObject. largeIdentityHash = 1094

So why Date serializaded object gives this and the rest of objects no ?

Edgar

On Mon, Oct 8, 2012 at 8:30 AM, Max Leske <maxleske@gmail.com> wrote:

Looking at the failing tests I see that the objects really are supposed to be different (comparison with #~~). What fails is the equality check (#=) and for Date that is the method Timespan>>=. The problem that occurs there is a really old (and annoying one), namely that the timezone offset is handled inconsistently: the materialized object has the correct offset while the original object doesn't.

I think it could work if you just remove Date>>fuelAccept: . Can you try?

So: - FLBasicSerializationTest>>testDate fails because of timezone offset - FLBasicSerializationTest>>testGradientFillStyle fails because Object>>= isn't overridden in any subclass and therefore identity is checked, which fails - (same as above for FLBasicInMemorySerializationTest)

The other failures seem to be due to implementation differences between Pharo and Squeak (I didn't really look into them) but I couldn't find one test that seemed to fail because of hashing problems.

Yes, I didn't really understand the thing with the hashes. I don't think there should be a problem there. Something obvious is that a normal object that is serialized will probabyt have a different identityHash than the materialized object. Thanks!

I'll see if I can come up with a test case.

Cheers, Max

On 07.10.2012, at 16:38, Max Leske <maxleske@gmail.com> wrote:

The two objects I looked at where a string and an OrderedCollection. I wouldn't conclude that the problem is class specific...

On 07.10.2012, at 16:12, "Edgar J. De Cleene" <edgardec2005@gmail.com> wrote:

On 10/7/12 10:51 AM, "Max Leske" <maxleske@gmail.com> wrote:

Following you example, in Squeak FLBasicSerializationTest>>#testDate

materialized largeIdentityHash = 2571

anObject. largeIdentityHash = *1094 *

So why Date serializaded object gives this and the rest of objects no ?

Edgar

-- Mariano http://marianopeck.wordpress.com

On 10/9/12 4:00 AM, "Max Leske" <maxleske@gmail.com> wrote:

I guess, your idea was to not use optimized encoding, right? But that would have meant to serialize an extra DateAndTime object. So I hacked together this quick fix (see attachment) that simply encodes another int32 on the stream with the offset. The materialization method took care of creating a new DateAndTime object anyway.

With the fix, the Date tests pass.

Cheers, Max

Max: With your changes the test still fails in Squeak. Very thanks for for show where the problem could be, I try see Date and Timespan implementations Edgar

That works (at least for me). On 09.10.2012, at 21:59, Mariano Martinez Peck <marianopeck@gmail.com> wrote:

On Tue, Oct 9, 2012 at 2:22 PM, Edgar J. De Cleene <edgardec2005@gmail.com> wrote:

On 10/9/12 4:00 AM, "Max Leske" <maxleske@gmail.com> wrote:

I guess, your idea was to not use optimized encoding, right? But that would have meant to serialize an extra DateAndTime object. So I hacked together this quick fix (see attachment) that simply encodes another int32 on the stream with the offset. The materialization method took care of creating a new DateAndTime object anyway.

With the fix, the Date tests pass.

Cheers, Max

Max:

With your changes the test still fails in Squeak. Very thanks for for show where the problem could be, I try see Date and Timespan implementations

In the meanwhile, can you test the workaround I proposed? (that is, remove Date>>#fuelAccept:)

Thanks

-- Mariano http://marianopeck.wordpress.com

Edgar, which version of Squeak are you using? Max On 10.10.2012, at 12:52, Edgar J. De Cleene <edgardec2005@gmail.com> wrote:

On 10/9/12 4:59 PM, "Mariano Martinez Peck" <marianopeck@gmail.com> wrote:

...

...

In the meanwhile, can you test the workaround I proposed? (that is, remove Date>>#fuelAccept:)

Thanks

Sorry I miss your previous mail.

With Date>>#fuelAccept: removed we have:

...

'240 run, 233 passes, 2 expected failures, 4 failures, 0 errors, 1 unexpected passes' FLBasicSerializationTest>>#testGradientFillStyle FLInMemoryBasicSerializationTest>>#testGradientFillStyle FLMigrationTest>>#testFormatFixedToVariable FLMigrationTest>>#testFormatVariableToFixed FLWeakObjectsTest>>#testAssociationWithWeakFinalizationList

Edgar

Ah! Could you try the Date fix I proposed in a 4.3 image? BTW I'm working on fixing the other failing tests (for 4.3) aswell. Cheers, Max On 11.10.2012, at 11:48, Edgar J. De Cleene <edgardec2005@gmail.com> wrote:

On 10/10/12 11:04 AM, "Max Leske" <maxleske@gmail.com> wrote:

...

Edgar, which version of Squeak are you using?

Max

Current Squeak 4.4 updated with some code I add.

Edgar

On 10/11/12 12:53 PM, "Max Leske" <maxleske@gmail.com> wrote:

Ah!

Could you try the Date fix I proposed in a 4.3 image?

BTW I'm working on fixing the other failing tests (for 4.3) aswell.

Cheers, Max

You was right, some changed recently in Squeak as 4.3 11860 (fresh unzipped) do not fail the two test of Date, the rest is same as 4.4 You only need fileIn TClassAndTraitDescription from Pharo when Monticello complains Edgar

Hey Edgar I checked the Fuel tests in a 4.4 image and there are no differences to the 4.3 image. If you still have that problem with the failing Date test then you probably have an issue with the code you loaded in addition. One package that would break that test is PostgresV2 because that packages overrides #year:month:day: in Date and DateAndTime. Cheers, Max On 12.10.2012, at 08:33, Max Leske <maxleske@gmail.com> wrote:

Thanks Edgar. Much appreciated.

On 11.10.2012, at 21:14, Edgar J. De Cleene <edgardec2005@gmail.com> wrote:

...

On 10/11/12 12:53 PM, "Max Leske" <maxleske@gmail.com> wrote:

...

Ah!

Could you try the Date fix I proposed in a 4.3 image?

BTW I'm working on fixing the other failing tests (for 4.3) aswell.

Cheers, Max

You was right, some changed recently in Squeak as 4.3 11860 (fresh unzipped) do not fail the two test of Date, the rest is same as 4.4

You only need fileIn TClassAndTraitDescription from Pharo when Monticello complains

Edgar

I checked against build 11925 (found here: http://ftp.squeak.org/trunk/). Did you get your image from somewhere else? I can take a look at the image if you like. You'd just have to put it somewhere for me to download (together with the changes of course). Max On 15.10.2012, at 22:19, "Edgar J. De Cleene" <edgardec2005@gmail.com> wrote:

On 10/15/12 5:10 PM, "Max Leske" <maxleske@gmail.com> wrote:

...

Hey Edgar

I checked the Fuel tests in a 4.4 image and there are no differences to the 4.3 image. If you still have that problem with the failing Date test then you probably have an issue with the code you loaded in addition. One package that would break that test is PostgresV2 because that packages overrides #year:month:day: in Date and DateAndTime.

Cheers, Max

I re check, do not remember any I made change Date.

Thanks

Edgar

On 10/7/12 10:23 AM, "Mariano Martinez Peck" <marianopeck@gmail.com> wrote:

Hi Edgar. Which version are you using exactly of the package Fuel? Thanks,

From http://ss3.gemstone.com/ss/Fuel repository/ Open and load ConfigurationOfFuel-MarianoMartinezPeck.153

Then ConfigurationOfFuel load And this is the list of loaded from Monticello Browser * ConfigurationOfFuel (MarianoMartinezPeck.153) ³marked dirty as I write ConfigurationOfFuel load in the comment ³ Fuel (MartinDias.685) FuelCompatibilityBeforePharo12 (MartinDias.8) FuelCompatibilityBeforePharo13 (MarianoMartinezPeck.3) FuelCompatibilityBeforePharo14 (MartinDias.3) FuelCompatibilityBeforePharo20 (MartinDias.4) FuelCompatibilityForSqueak (MMP.4) * FuelTests (MartinDias.267) ³marked dirty as I put a self halt for seeing what¹s going on² FuelTestsCompatibilityForSqueak (MMP.1) The same on Pharo-1.4-14557 gives all green test Cheers Edgar