A few quick comments Oasis-wise...

----- Original Message ----- From: Lex Spoon lex@cc.gatech.edu To: squeak-dev@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

on 1/2/02 8:22 PM, Lex Spoon at lex@cc.gatech.edu wrote:

...

So I would like to know what is the status of the type inferencers? 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
2. a senders-of table, to avoid searching through the system
3. an implementors-of table, again to avoid searching

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....

Roel in is Prolog in Smalltalk (SOUL) added a notification mechanism to the changeset so that everytimes a method gets added its engine would get notifyed. I do not know if this is what you want (or even enough) but contact him: wuyts@iam.unibe.ch

-Lex

Lex why don't you try the following:

put a button that will recompute everything even if this takes long time and cache it. -> this way we (the other users) will be able to play with it (and we will know that this is like that) -> I think that in the beginning of a PhD you should know fast if the things you are doing are worth. that's why incremental changes are interesting but if you would have a solution for type inference that we could use for documentation this would be already great.

I would really like from you if you could write in a wiki page all the information you would like to have in an AST for code analysis (and state if this is in Lucid).

Stef