Type Inferencer to the Rescue
tyrrell at canis.uiuc.edu
Wed Jan 2 21:18:54 UTC 2002
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 ).
More information about the Squeak-dev