on 1/2/02 10:18 PM, Les Tyrrell at tyrrell at canis.uiuc.edu wrote:

> A few quick comments Oasis-wise...
> 
> ----- Original Message -----
> From: Lex Spoon <lex at cc.gatech.edu>
> To: <squeak-dev at lists.squeakfoundation.org>
> Sent: Wednesday, January 02, 2002 11:22 AM
> Subject: Re: Type Inferencer to the Rescue
> 
>>> So I would like to know what is the status of the type inferencers?
> 
> Oasis is developed in fits and starts.  Also in fits and starts, I get the
> occasional urge to publish it.  Unfortunately, I often find that in fits and
> starts other things come up that take me out of the action.  I really, really
> want to get it published, but there are the usual non-niceties ( or sheer
> ugliness ) that tend to hold me back.  At this rate, it will never be
> published.  I've had a few inquiries lately, reminders that I'm *way* overdue
> on this... so it is in my mind, at least.  The latest detraction is that my
> laptop is currently dead, probably a dead CMOS battery.  It goes on like this
> all the time it seems...
> 
>>> Is Lucid still developed?
>> 
>> I'm still chugging along on Lucid.  It does find types for a good many
>> expressions, but I'm trying to improve on it.  I haven't reposted a
>> newer version in a while -- first, the next version will be better, and
>> second, it's probably not real fun to play with right now, because of
>> the way it deals (or doesn't deal) with code changes.
>> 
>> Specifically, on that last note, I've started assuming that the
>> following things are available to the analysis:
>> 
>> 1. parse trees for all methods
> 
> In Oasis I've only needed these once per method- after having done some model
> building, I can discard these.  My experience was that these took up a HUGE
> amount of memory, so dropping them was nice.  The model I build that contains
> such information ( see below )  is much much smaller than the parse trees.
> 
>> 2. a senders-of table, to avoid searching through the system
>> 3. an implementors-of table, again to avoid searching
> 
> I don't use tables, but this sort of functionality is an explicit part of what
> could be called a message trace model.  That model should be useable by lots
> of different analysis tools, not just the ones in Oasis.
> 
>> What I haven't done, is arranged for these tables to get updated
>> whenever someone changes code in a browser.  It's more work than it
>> seems at first, because there are several different ways someone can
>> change code (add a method; rename a class; reparent a class; etc.).  And
>> there's a temptation to generalize, so that other tools could react to
>> changes in the system code....
> 
> Ditto... The analysis models are large, and in the past I've been focused on
> some making some other things work rather than going back to make the static
> models become dynamically synchronized with the actual state of the image.
> But I think this can be done easily with a well-chosen place to watch.. for
> instance, in VW I can simply become a dependent of ChangeSet and catch all of
> these things happening. ( the Refactory stuff had already added the
> notifications to ChangeSet class ).
> 
> - les
> 
> 
> 
> 

les 

you should write a paper that describe what you have so that we can learn
from you!!!!!
Even if you do not solve the world. Let some work for the others ;)
But write down what you have made....That's important the errors, dead-ends
and solutions are extremely  valuable information