>> I have just a suggestion : could this AutoChuck feature be turned
>> on only on certain packages, such as Kernel and not Morphic for example 
>> ?
>> This could spare some time and quit a bit of space ... 
>> 
> 
> I'm working on the space requirements, but wanted to go ahead and post
> the system as is for the diehards.  Memory usage is not the only area
> that is lacking I'm afraid! 
> 

Right, it's always best to get early feedback. 

> The major memory requirement, it turns out, is that AutoChuck is keeping
> around parse trees for every method.  So I'm trying to eithre get rid of
> that requirement or make the parse trees take less memory. 
> 
> The particular idea of caching part of the system seems difficult to
> implement.  If you ask what the type of Morph>>width is, it will end up
> tracing into methods in Rectangle, which will in turn trace into methods
> in the numeric hierarchy.  So what parts do you *really* need if you
> just want to analyze morphic stuff?  It's hard to tell. 
> 

Maybe just being lazy could work ...
But I was rather thinking of splitting the images into chunks, using 
PAckageInfo for example, and maybe include package dependency information
(I don't know how far TFNR went on this), so that you could use dependencies
to analyse packages one at a time (assuming Kernel doesn't depend on 
someting else ...) 

> 
> Romain Robbes <rrobbes at info.unicaen.fr> wrote:
>> A while ago I started (I mean, played 3 hours ;-)) a little program to 
>> store type
>> information which could then be used by several tools, such as a type 
>> inferencer,
>> an the toy I was doing, which was collecting run-time types, so they
>> could "collaborate". This could then be used by a code completion 
>> system,
>> or various navigation systems (how about clicking on a variable and 
>> being
>> automagically teleported to it's class ?).
> 
> Oh yes, this is a great tool too, and it complements what Chuck does. 
> 
> Chuck examines the program and gives you an upper bound on what the
> types might ever be; your tool examines executions and thus finds a
> *lower* bound on the types.  Your tool is, I'm sure, consistently fast;
> on the other hand, Chuck will find a good many answers even in code that
> has yet to be executed.  This is nice if you have not yet figured out
> how to run the code you are studying!   
> 

Does that mean you don't program test-first ;-) ?
Seriously, do you think, several tools could collaborate using a
common knowledge base (I guess I should check Chuck ASAP) ? 

> Also, upper bounds on the types have different applications in
> downstream tools such as compilers and dead code removers; a lower bound
> can inform the compiler that a case is worth optimizing (e.g. this
> method really does get run with FloatArray's), and an upper bound can
> let the compiler *avoid* dealing with certain cases (e.g., this message
> send can only ever invoke one particular method, so inline it). 
> 

This kind of optimizations seems great, but also harder to do in Squeak,
where a method could be added anywhere at any time ... but there is sure
a lot of work to do in this field ... 

Romain 


> 
> Lex 
>