[Glass] Tode problematic
Dale Henrichs via Glass
glass at lists.gemtalksystems.com
Tue Jul 11 12:40:24 PDT 2017
On 7/11/17 12:31 PM, Trussardi Dario Romano via Glass wrote:
>
>> On 7/11/17 10:28 AM, Trussardi Dario Romano via Glass wrote:
>>> Ciao,
>>>
>>>>> Ciao,
>>>>>>
>>>>>> This looks like a different problem now ... you shouldn't have
>>>>>> gotten a reference to the method isNotNil if it is not present in
>>>>>> the method dictionaries for Object ...
>>>>>>
>>>>>> Have you refreshed the method list (by clicking on the Object
>>>>>> class in the class pane)? tODE does not automatically update the
>>>>>> lists when methods are removed, so this is one possibility for
>>>>>> the error ..
>>>>>>
>>>>> Yes the method list is update.
>>>>>>
>>>>>> You are missing a stack for B), so I cannot comment on that error
>>>>>> --- it would be useful to see the stack when you are trying to
>>>>>> define the method again ...
>>>>>>
>>>>> I add the stack to B)
>>>>>
>>>>> I confirm stack for:A)and C)
>>>>>>
>>>>>> At this point in time it does not appear that the method is
>>>>>> present and that it is possible that the method list is just out
>>>>>> of date ...
>>>>>>
>>>>>> Try refreshing the method list ... and reporting stacks at each
>>>>>> point where you hit an error ...
>>>>>>
>>>>> D)When on the method isNotNili do themove to protocol menu options,
>>>>>
>>>>> the system answer :
>>>>>
>>>>> a LookupError occurred (error 2021), reason:rtErrKeyNotFound,
>>>>> A reference using the non-existent key #'isNotNil' was made
>>>>> into the dictionary Object
>>>>> --------------------
>>>>> 1. LookupError(AbstractException)>>_signalWith: @5 line 25
>>>>> 2. LookupError(AbstractException)>>signal @2 line 47
>>>>> 3. Object class(Object)>>_error:args: @15 line 11
>>>>> 4. Object class(Behavior)>>compiledMethodAt:environmentId: @5
>>>>> line 9
>>>>> 5. Object class(Behavior)>>compiledMethodAt: @2 line 2
>>>>> 6. Object class(Behavior)>>moveMethod:toCategory: @13 line 10
>>>>> 7. Object class(Behavior)>>classify:under: @9 line 7
>>>>> 8. TDMethodDefinition>>moveToProtocolNamed: @4 line 2
>>>>> 9.
>>>>> TDClassicClassSelectorListElementBuilder(TDClientListElementBuilder)>>moveMethodToProtocolMenuAction:selectionIndex:
>>>>> @16 line 11
>>>>> 10.
>>>>> TDClassicClassSelectorListElementBuilder(TDWindowBuilder)>>handleMenuActions:listElement:actionArg:
>>>>> @12 line 10
>>>>> 11. [] in
>>>>> TDClassicClassSelectorListElementBuilder(TDClientListElementBuilder)>>menuActionBlock
>>>>> @2 line 7
>>>>> 12.
>>>>> TDClassicClassSelectorListElementBuilder(ExecBlock)>>value:value:value:
>>>>> @2 line 11
>>>>> 13. GsNMethod class>>_gsReturnToC @1 line 1
>>>>>
>>>>>
>>>>> After refreshed the method list the method is right moved to new
>>>>> protocol but A B C point don't work.
>>>> Okay, the method
>>>> Behavior>>compiledMethodAt:environmentId:otherwise: appears to be
>>>> the culprit in all of these errors ... there are quite a few of the
>>>> higher level methods that pass through
>>>> Behavior>>compiledMethodAt:environmentId:otherwise: and
>>>> Behavior>>compiledMethodAt:environmentId:otherwise: ignores methods
>>>> that are installed in the session method dictionary and that is
>>>> leading to the rash of lookup errors as the code is looking in the
>>>> wrong place ...
>>>>
>>>> This problem has been around for a while, but in tODE I
>>>> rarely/never add methods to system classes without creating a
>>>> protocol starting with * first and then crate the method in that
>>>> protocol (new method menu item) --- and that combo works ... My
>>>> suggested patch solved one problem but there appear to be quite a
>>>> few potential problems. I am quite busy with 3.4 work at the moment
>>>> and do not have the time to properly fix all of the problems ...
>>>
>>> No problem.....
>>>
>>> I do this work only for document the question ...
>>>
>>>>
>>>> Sooo, I think that if you can create a protocol starting with a *
>>>> and add create your method in that protocol, then you should be
>>>> good to go ... I was able to take my experimental method from
>>>> yesterday that was n a non-* protocol and re-create it in a *
>>>> protocol, so this should get you out of the woods ...
>>>
>>> The isNotNil method is in a protocol begin with *
>>>
>>> and i can move it into another protocol begin with * as i report at
>>> point D
>> but point D is an error, so you are not able to move it to another
>> protocol, correct? You have not been able to do anything without
>> error correct?
>
> Yes point D erase the error but the method after it is moved to new
> *... protocol. ( really strange )
>>>
>>> But the A B C problematic don't change.
>>>
>>> In any case when compile the isNotNil method i a new *... protocol
>>> the system behaves like B
>> This is not my experience so there is something that you are doing
>> that I'm not doing ... I don't "move" the method. I compile the
>> method in the new * protocol and after that I can look at source,
>> move the method to other * protocols, etc.
>
> The method is defined in the *... protocol and i can't do anything...
> No remove .... | No new method compile | No *... protocol remove....
>
> I don't remember when and as i compile the method in *.. protocol
>
>>
>> Have you tried creating a new * protocol and creating the method in
>> that protocol?
>
> Yes, it's same of the B case.
>
>>
>> If that doesn't work, provide me with a fresh stack that produces an
>> error (please provide method source
>
> What do you mean with method source ?
>
>> ) and I will see if I can work out a repair script.
>
> In the case C) If i select theisNotNil remove menu option the system
> answer:
>
> a MessageNotUnderstood occurred (error 2010), a UndefinedObject does
> not understand #'inClass'
> --------------------
> 1. MessageNotUnderstood>>defaultAction @2 line 3
> 2. MessageNotUnderstood(AbstractException)>>_signalWith: @5 line 25
> 3. MessageNotUnderstood(AbstractException)>>signal @2 line 47
> 4. UndefinedObject(Object)>>doesNotUnderstand: @9 line 10
> 5. UndefinedObject(Object)>>_doesNotUnderstand:args:envId:reason: @7
> line 12
> 6. TDMethodDefinition>>methodCategory @5 line 6
> 7. TDMethodDefinition>>removeFromSystem: @4 line 4
> 8.
> TDClassicClassSelectorListElementBuilder>>cutObjectMenuAction:selectionIndex:
> @9 line 6
> 9.
> TDClassicClassSelectorListElementBuilder(TDWindowBuilder)>>handleMenuActions:listElement:actionArg:
> @12 line 10
> 10. [] in
> TDClassicClassSelectorListElementBuilder(TDClientListElementBuilder)>>menuActionBlock
> @2 line 7
> 11.
> TDClassicClassSelectorListElementBuilder(ExecBlock)>>value:value:value:
> @2 line 11
> 12. GsNMethod class>>_gsReturnToC @1 line 1
>
>
> The source of methodCategory is:
>
> methodCategory
> methodCategory
> ifNil: [
> | method category |
> method := self method.
> methodCategory := method inClass categoryOfSelector: self
> selector.
> methodCategory ifNil: [ category := ClassOrganizer default ] ].
> ^ methodCategory
>
>
> At line 6 the method variable is nil.
I guess is thinking of one of your many Lookup errors ... obviously it
is not finding the method (returning nil), but I'm looking for a method
on behavior where an error occurs ... iI think I mentioned that it is
possible that the category structure is messed up and I'm looking for
evidence ... the evidence here is that the method is not found, but
there are too many explanations for that ... especially without a more
specific error from Behavior
Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170711/9de8d78a/attachment-0001.html>
More information about the Glass
mailing list