On Wed, 26 Jul 2006 08:48:21 +0200, Marcus Denker wrote:
> On 26.07.2006, at 07:36, Klaus D. Witzel wrote:
>> ... May I stress that my concern is the *current*
>> *integrity* of
>>
>> (nil systemNavigation
>> 	allMethodsSelect: [:method |
>> 		method hasNewPropertyFormat == false]) size
>> => 0
>
> All methods have been recompiled to use the new format (with class
> binding in last literal)
>
>> 	
>> |x y | x := y := 0.
>> nil systemNavigation
>> 	allMethodsSelect: [:method |
>> 		method literals last isVariableBinding
>> 		ifTrue: [x := 1 + x]
>> 		ifFalse: [y := 1 + y]. false].
>> x @ y => 49487 at 0
>> 	
>> |x y | x := y := 0.
>> CompiledMethod allInstancesDo: [:z |
>> 	z literals last isVariableBinding
>> 		ifTrue: [x := 1 + x]
>> 		ifFalse: [y := 1 + y]].
>> x at y => 49035 at 5
>>
>> (note the discrepancy, 49487 versus 49035,
>
> non-locally intalled traits methods.

Aha, I already assumed this was related to traits. Thank you for the  
confirmation.

>> 0 versus 5, relative to 3.9#7048)
>>
>
> There are some methods on the stack that have not yet finished
> executing... should be fixed.
>   It's on the never-ending list of stuff on the todo.

O.K. will have a look at what can be stolen from Pavel's kernel w.r.t.  
re-instantiating the as yet not terminated processes.

In adition, would you please review this line of thought: if we already  
had the new ObsoleteMethods feature, we'd know exactly which ones (of the  
still executing methods) that are. Thank you for you time.

>> But aCompiledMethod methodClass ... This must be as
>> reliable as possible, otherwise we can forget about
>> aCompiledMethod>>#= for use in any other (sub)system. No, it's not
>> my intention to invent something which is ersatz (<= WordNet/2.1)
>> for aCompiledMethod>>#=.
>>
>
> #= does not take the Class of the method into account, as any client
> for equality would not want that.

I repeat my argument ( >= 3 postings ago): any two classes must have (by  
definition) ~= type, so their methods. Please confirm or refute, if an  
answer is possible, thank you in advance.

> You want to ask "which methods are
> the same in the system".

Do I? Do I want to know that two methods which are defined for two ~=  
types (classes) both access the i-th instance variable in their local  
(hidden, encapsulated) state?

> If we
> take the Class into account, you will never find any equeal methods...

Hhm. Do you suggest that we can get rid of aCompiledMethod>>#= because  
there is not much sensible use of it anyways (see my point on the i-th  
instVar of two ~= types)?

So what do we need for finding out whether or not the compiler has made  
two methods from exactly the same or from guaranteed different entries in  
the new source code subsystem (a question which cannot be answered by  
querying the [most likely remote] source code subsystem)? Do we need  
"just" meta data and never ask aCompiledMethod>>#= ?

When does a method become a new (a different) version? Because the [most  
likely remote] new source code subsystem dictates so <joke> http push:  
sourceCode newVersion: true </joke>. Or because any two  
aCompiledMethod>>#= tell so?

[take my apologies for the many ?'s]

>> A nice and bad (perhaps no *that* close but nevertheless
>> frightening) example is ChangeRecord>>#methodClass, it asks
>> Smalltalk (regardless of obsolence)...
>> words and in a single statement: clean up the #methodClass mess in
>> the image.
>
> The whole fileOut / Changes stuff os a huge huge mess. But
> #methodClass in ChangeRecord has not much to do with #methodClass on
> CompiledMethod...

OhhKay, lame example ;-) But frightening, isn't it.

> Seriously, the only way to improve the situation is to improve it...
> we had many people telling that only perfect solutions are
> acceptable.

I never had the time ( == my customers never had the time) for waiting for  
/ or doing a perfect solution. We're in sync (I know you knew that).

> Or worthy of Squeak
> or something. This is wrong: We need *better* solutions, not perfect
> ones.

Yes, better quality than quantity.

> If we would have just made everything continously a little bit
> better over the last
> 10 years, we would have quite a cool system now.
>
> The idea of searching for the "perfect" solution only (while letting
> everything rot) is the reason for a lot of what we see now.

...while letting everything *else* rot... yes, agreed.

/Klaus

>         Marcus