[ANN] Fuel 1.8.1
Locked
1234
1234
 
|
On 7 January 2013 10:42, Max Leske <[hidden email]> 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 <[hidden email]> wrote: > >> On 7 January 2013 09:49, Max Leske <[hidden email]> wrote: >>> >>> On 07.01.2013, at 10:37, Frank Shearar <[hidden email]> wrote: >>> >>>> On 7 January 2013 07:18, Max Leske <[hidden email]> 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/target/Squeak4.5-12371.zip >>> >>> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>>>>>>>>> Thanks guys! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 02.01.2013, at 20:13, Chris Muller <[hidden email]> 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. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > > |
|
|
In reply to this post by Frank Shearar-3
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 15:43, Chris Muller <[hidden email]> 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 |
|
|
In reply to this post by Chris Muller-3
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. > |
|
|
In reply to this post by Frank Shearar-3
>> 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. I think the retag-for-new-version-of-Squeak should be done manually. It's very easy to do it, but by requiring a human to do it, it truly informs when the last time someone put a little energy into a package and the most likely version that code was last known to work. I agree it would be odd for a (head) release to be tagged for an earlier release than a fixed release -- it probably just means the owner forgot to retag the (head) release. > (Having the ability to multiselect Squeak versions in the > SMReleaseBrowser would aid the manual approach.) Yea, I agree about that. |
|
|
In reply to this post by Ken G. Brown
On Mon, Jan 7, 2013 at 10:14 AM, Ken G. Brown <[hidden email]> 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. |
|
|
On 7 January 2013 16:46, Chris Muller <[hidden email]> wrote:
> On Mon, Jan 7, 2013 at 10:14 AM, Ken G. Brown <[hidden email]> 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 |
|
|
In reply to this post by Frank Shearar-3
On 07.01.2013, at 12:09, Frank Shearar <[hidden email]> wrote: > On 7 January 2013 10:42, Max Leske <[hidden email]> 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. > > (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 <[hidden email]> wrote: >> >>> On 7 January 2013 09:49, Max Leske <[hidden email]> wrote: >>>> >>>> On 07.01.2013, at 10:37, Frank Shearar <[hidden email]> wrote: >>>> >>>>> On 7 January 2013 07:18, Max Leske <[hidden email]> 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/target/Squeak4.5-12371.zip >>>> >>>> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>>>>>>>>>> Thanks guys! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 02.01.2013, at 20:13, Chris Muller <[hidden email]> 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. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > |
|
|
In reply to this post by Frank Shearar-3
> 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? |
|
|
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 <[hidden email]> 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? > |
|
|
> 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. 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). |
|
|
> 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 9 January 2013 17:49, Chris Muller <[hidden email]> wrote:
>> 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!!! Hashing would do just fine. Excellent! frank |
release processes (was Re: [squeak-dev] [ANN] Fuel 1.8.1)
|
|
In reply to this post by Chris Muller-3
On 09-01-2013, at 9:46 AM, Chris Muller <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Lightbulb over his head is burned out. |
|
|
In reply to this post by Max Leske
On 8 January 2013 07:21, Max Leske <[hidden email]> wrote:
> > On 07.01.2013, at 12:09, Frank Shearar <[hidden email]> wrote: > >> On 7 January 2013 10:42, Max Leske <[hidden email]> 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 12.02.2013, at 17:09, Frank Shearar <[hidden email]> wrote: > On 8 January 2013 07:21, Max Leske <[hidden email]> wrote: >> >> On 07.01.2013, at 12:09, Frank Shearar <[hidden email]> wrote: >> >>> On 7 January 2013 10:42, Max Leske <[hidden email]> 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? > I'm looking into it. > #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 > |
|
|
In reply to this post by Frank Shearar-3
(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 <[hidden email]> wrote: On 8 January 2013 07:21, Max Leske <[hidden email]> wrote: |
|
|
On 13 February 2013 08:45, Max Leske <[hidden email]> 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 <[hidden email]> wrote: > > On 8 January 2013 07:21, Max Leske <[hidden email]> wrote: > > > On 07.01.2013, at 12:09, Frank Shearar <[hidden email]> wrote: > > On 7 January 2013 10:42, Max Leske <[hidden email]> 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 <[hidden email]> wrote: > On 13 February 2013 08:45, Max Leske <[hidden email]> 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 <[hidden email]> wrote: >> >> On 8 January 2013 07:21, Max Leske <[hidden email]> wrote: >> >> >> On 07.01.2013, at 12:09, Frank Shearar <[hidden email]> wrote: >> >> On 7 January 2013 10:42, Max Leske <[hidden email]> 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 February 2013 10:30, Martin Dias <[hidden email]> 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? > 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? frank > Best regards, > Martin > > > On Wed, Feb 13, 2013 at 10:56 AM, Frank Shearar <[hidden email]> wrote: >> On 13 February 2013 08:45, Max Leske <[hidden email]> 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 <[hidden email]> wrote: >>> >>> On 8 January 2013 07:21, Max Leske <[hidden email]> wrote: >>> >>> >>> On 07.01.2013, at 12:09, Frank Shearar <[hidden email]> wrote: >>> >>> On 7 January 2013 10:42, Max Leske <[hidden email]> 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 >>> >>> >>> >>> >>> >> > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |