Hello
The class MethodProperties which was in Squeak 5.1 and as well in Squeak 3.10.2 is no longer in Squeak 6.0a. [1] Thus a project from Squeak 3.10.2 (BabyIDE/SRE in this case) does not load. It seems that the issue might be resolved by adding a new class to SmartRefStream initKnownRenames http://wiki.squeak.org/squeak/1124 initKnownRenames renamed at: #FlasherMorph put: #Flasher; at: #AlansTextPlusMorph put: #TextPlusMorph; at: #Project put: #MorphicProject; at: #Presenter put: #EtoysPresenter; at: #InputSensor put: #EventSensor; yourself! "(May 2018 version)" Which new class name should be put there? ? Regards Hannes [1] Attached is a screen shot of a search on the swiki http://wiki.squeak.org/squeak/search?search=MethodProperties&casesensitive=false&and=true The search shows that the class MethodProperties was still in Squeak 5.1 Searching_for_class_MethodProperties_2018-05-23.png (98K) Download Attachment |
> On 23.05.2018, at 08:55, H. Hirzel <[hidden email]> wrote: > > [1] Attached is a screen shot of a search on the swiki > http://wiki.squeak.org/squeak/search?search=MethodProperties&casesensitive=false&and=true > The search shows that the class MethodProperties was still in Squeak 5.1 No, Squeak 5.1 and 5.0 have only • MethodPropertiesTest Which tests the behavior of things around CompiledMethod>>properties and AdditionalMethodState. also you probably do not want to change the init method but rather implement the following: SmartRefStream>>methodPropertiespps0 ^ AdditionalMethodState This special method name allows the RefStream to identify the replacement Class for MethodProperties. That being said, I do not thing that it is necessary to map incoming MethodProperties. They should rather be ignored and the corresponding _method_ should just be recompiled. That way it is assured that the correct AdditionalMethodState is created. I looked in Squeak 3.9, and all MethodProperties that exists are either effectively empty or just replicate the primitive information, if any (except for two methods in Parser, but that is not useful here I think). I'd say its safe to ignore them on load (returning nil or something) and rather trigger a recompile afterwards. Best regards -Tobias |
On 5/23/18, Tobias Pape <[hidden email]> wrote:
> >> On 23.05.2018, at 08:55, H. Hirzel <[hidden email]> wrote: >> >> [1] Attached is a screen shot of a search on the swiki >> http://wiki.squeak.org/squeak/search?search=MethodProperties&casesensitive=false&and=true >> The search shows that the class MethodProperties was still in Squeak 5.1 > > No, Squeak 5.1 and 5.0 have only > • MethodPropertiesTest > Which tests the behavior of things around CompiledMethod>>properties and > AdditionalMethodState. > Yes, thank for the correction. There is not class MethodProperties in Squeak 5.0 and 5.1 > also you probably do not want to change the init method but rather implement > the following: > > SmartRefStream>>methodPropertiespps0 > > ^ AdditionalMethodState > > This special method name allows the RefStream to identify the replacement > Class for MethodProperties. Yes, this is one options of dealing with classes which are no longer in the image. > That being said, I do not thing that it is necessary to map incoming > MethodProperties. They should rather be ignored and the corresponding > _method_ should just be recompiled. ok. > That way it is assured that the correct > AdditionalMethodState is created. > I looked in Squeak 3.9, and all MethodProperties that exists are either > effectively empty or just replicate the primitive information, if any > (except for two methods in Parser, but that is not useful here I think). I'd > say its safe to ignore them on load (returning nil or something) in which method? > and rather trigger a recompile afterwards. At which place should this happen? ProjectLoading steps http://wiki.squeak.org/squeak/883 Best Hannes |
> On 23.05.2018, at 12:09, H. Hirzel <[hidden email]> wrote: > > On 5/23/18, Tobias Pape <[hidden email]> wrote: >> >>> On 23.05.2018, at 08:55, H. Hirzel <[hidden email]> wrote: >>> >>> [1] Attached is a screen shot of a search on the swiki >>> http://wiki.squeak.org/squeak/search?search=MethodProperties&casesensitive=false&and=true >>> The search shows that the class MethodProperties was still in Squeak 5.1 >> >> No, Squeak 5.1 and 5.0 have only >> • MethodPropertiesTest >> Which tests the behavior of things around CompiledMethod>>properties and >> AdditionalMethodState. >> > > Yes, thank for the correction. > > There is not class MethodProperties in Squeak 5.0 and 5.1 > > >> also you probably do not want to change the init method but rather implement >> the following: >> >> SmartRefStream>>methodPropertiespps0 >> >> ^ AdditionalMethodState >> >> This special method name allows the RefStream to identify the replacement >> Class for MethodProperties. > > > Yes, this is one options of dealing with classes which are no longer > in the image. > > >> That being said, I do not thing that it is necessary to map incoming >> MethodProperties. They should rather be ignored and the corresponding >> _method_ should just be recompiled. > > ok. > > >> That way it is assured that the correct >> AdditionalMethodState is created. >> I looked in Squeak 3.9, and all MethodProperties that exists are either >> effectively empty or just replicate the primitive information, if any >> (except for two methods in Parser, but that is not useful here I think). I'd >> say its safe to ignore them on load (returning nil or something) > > in which method? > >> and rather trigger a recompile afterwards. > > At which place should this happen? > Good call on both. I have no idea, actually. I have used projects very little. Best regards -Tobias > ProjectLoading steps > http://wiki.squeak.org/squeak/883 > > > Best > Hannes > |
OK, thank you for the answer. I went for the first idea
I added a new method SmartRefStream >> methodPropertiespps0 in the conversion protocol methodPropertiespps0 ^ AdditionalMethodState Now an error occurs later ImageSegmentLoader>>readObject More see mail in a new thread. On 5/23/18, Tobias Pape <[hidden email]> wrote: > >> On 23.05.2018, at 12:09, H. Hirzel <[hidden email]> wrote: >> >> On 5/23/18, Tobias Pape <[hidden email]> wrote: >>> >>>> On 23.05.2018, at 08:55, H. Hirzel <[hidden email]> wrote: >>>> >>>> [1] Attached is a screen shot of a search on the swiki >>>> http://wiki.squeak.org/squeak/search?search=MethodProperties&casesensitive=false&and=true >>>> The search shows that the class MethodProperties was still in Squeak 5.1 >>> >>> No, Squeak 5.1 and 5.0 have only >>> • MethodPropertiesTest >>> Which tests the behavior of things around CompiledMethod>>properties and >>> AdditionalMethodState. >>> >> >> Yes, thank for the correction. >> >> There is not class MethodProperties in Squeak 5.0 and 5.1 >> >> >>> also you probably do not want to change the init method but rather >>> implement >>> the following: >>> >>> SmartRefStream>>methodPropertiespps0 >>> >>> ^ AdditionalMethodState >>> >>> This special method name allows the RefStream to identify the replacement >>> Class for MethodProperties. >> >> >> Yes, this is one options of dealing with classes which are no longer >> in the image. >> >> >>> That being said, I do not thing that it is necessary to map incoming >>> MethodProperties. They should rather be ignored and the corresponding >>> _method_ should just be recompiled. >> >> ok. >> >> >>> That way it is assured that the correct >>> AdditionalMethodState is created. >>> I looked in Squeak 3.9, and all MethodProperties that exists are either >>> effectively empty or just replicate the primitive information, if any >>> (except for two methods in Parser, but that is not useful here I think). >>> I'd >>> say its safe to ignore them on load (returning nil or something) >> >> in which method? >> >>> and rather trigger a recompile afterwards. >> >> At which place should this happen? >> > > Good call on both. I have no idea, actually. I have used projects very > little. > > Best regards > -Tobias > >> ProjectLoading steps >> http://wiki.squeak.org/squeak/883 >> >> >> Best >> Hannes >> > > > |
As you see here
How does ImageSegmentLoader>>readObject work? http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-May/198849.html I got stuck. So the other option might be more promising. Just to ignore the creation of MethodProperties objects and recompile the methods instead. But which methods, and where to do the recompiling, that is the question.... On 5/23/18, H. Hirzel <[hidden email]> wrote: > OK, thank you for the answer. I went for the first idea > > > > I added a new method > > SmartRefStream >> methodPropertiespps0 > > in the conversion protocol > > > > methodPropertiespps0 > > ^ AdditionalMethodState > > > > Now an error occurs later > > ImageSegmentLoader>>readObject > > More see mail in a new thread. > > > > On 5/23/18, Tobias Pape <[hidden email]> wrote: >> >>> On 23.05.2018, at 12:09, H. Hirzel <[hidden email]> wrote: >>> >>> On 5/23/18, Tobias Pape <[hidden email]> wrote: >>>> >>>>> On 23.05.2018, at 08:55, H. Hirzel <[hidden email]> wrote: >>>>> >>>>> [1] Attached is a screen shot of a search on the swiki >>>>> http://wiki.squeak.org/squeak/search?search=MethodProperties&casesensitive=false&and=true >>>>> The search shows that the class MethodProperties was still in Squeak >>>>> 5.1 >>>> >>>> No, Squeak 5.1 and 5.0 have only >>>> • MethodPropertiesTest >>>> Which tests the behavior of things around CompiledMethod>>properties >>>> and >>>> AdditionalMethodState. >>>> >>> >>> Yes, thank for the correction. >>> >>> There is not class MethodProperties in Squeak 5.0 and 5.1 >>> >>> >>>> also you probably do not want to change the init method but rather >>>> implement >>>> the following: >>>> >>>> SmartRefStream>>methodPropertiespps0 >>>> >>>> ^ AdditionalMethodState >>>> >>>> This special method name allows the RefStream to identify the >>>> replacement >>>> Class for MethodProperties. >>> >>> >>> Yes, this is one options of dealing with classes which are no longer >>> in the image. >>> >>> >>>> That being said, I do not thing that it is necessary to map incoming >>>> MethodProperties. They should rather be ignored and the corresponding >>>> _method_ should just be recompiled. >>> >>> ok. >>> >>> >>>> That way it is assured that the correct >>>> AdditionalMethodState is created. >>>> I looked in Squeak 3.9, and all MethodProperties that exists are either >>>> effectively empty or just replicate the primitive information, if any >>>> (except for two methods in Parser, but that is not useful here I >>>> think). >>>> I'd >>>> say its safe to ignore them on load (returning nil or something) >>> >>> in which method? >>> >>>> and rather trigger a recompile afterwards. >>> >>> At which place should this happen? >>> >> >> Good call on both. I have no idea, actually. I have used projects very >> little. >> >> Best regards >> -Tobias >> >>> ProjectLoading steps >>> http://wiki.squeak.org/squeak/883 >>> >>> >>> Best >>> Hannes >>> >> >> >> > |
Free forum by Nabble | Edit this page |