Hi Simon, Thanks for the interest! I just finished my Ph.D., so I must say my mind is a bit elsewhere at the moment ;-). Here is the extension to eCompletion I made. Keep in mind that the code will probably not load cleanly as parts of it depend on the code in my prototype which is larger. There are two packages: - ChangeCompletion contains the code I used to measure the accuracy of the benchmark, and the variants of the completion algorithm itself. It also contains some overrides I needed to introduce more flexibility in ECompletion - OCompletion contains the code of a small UI experiment, where completion is "always activated", i.e. you don't need to press tab or control-space to get the menu, it is always there, but with only two or three propositions at each time. As for some general comments about how ecompletion is implemented, here is what I can tell you (you can ask me more of course). ECompletion has an ECEntry object that represents a completion proposal (one of the items in the menu). They are sorted alphabetically. I introduced a version containing a date to sort them according to usage. ECContext is the class that is the actual engine and returns a model of the system when asked for completion. The model in turn gives a list of entries for a given prefix. There are several kinds of models returned, depending if the type of the receiver is known (eg a model for a class, or the general untyped model of the system). The models use tables of symbols that they convert to entries when asked for a completion. Based on this, I introduced variants of completion algorithms by introducing subclasses of ECContext and ECTypedModel and ECUntypedModel, that build tables of symbols according to recent changes in the system. I introduced a processChange: method in ECContext for that. It uses the change representation of my prototype to do so, so you would probably need to change that (e.g. use the SystemChangeNotifier and the normal smalltalk parser). It selects the interesting entries according to the algorithm, and includes the date so that they are ordered as they should. I think the one with the "recent method bodies" algorithm is the one named ECECContext3 (I am aware the name is horrible ;-)). Finally, to activate the whole thing, I recommend you to have a subclass of the ECController (like the OController I implemented). You then need to switch from one to the other in a method in StringHolder such as: createCompletionController ^ (bool ifTrue: [OController] ifFalse: [ECController]) model: self It's important to have a way to toggle the completion off without typing in case it breaks ;-). Cheers, Romain On Dec 3, 2008, at 1:07 PM, Simon Denier wrote:
Hi guys
This is something really interesting to me so if you dont have time, I can take a look at it, either to the paper or the code if Romain can put it somewhere.
David, do you have some pointers about the recent modification list in OB?
As a newcomer, I dont know who is the developper/maintainer for eCompletion.
On 2 déc. 08, at 18:52, David Röthlisberger wrote:
Hi Romain,
But I believe the algorithms are described clearly enough in the paper. The one which provides the more "Bang for the Buck" would be "Recently Modiï¬ed Method Bodies" which proposes as completion entries the methods calls in the bodies of methods which were recently changed (ordered by time, ie most recent first). A further (but small) improvement would be to merge it with type inference when the information is available. Such as algorithm would be quite small to implement.
But you implemented those algorithms already in your prototype I think? Would it be possible to extract them from this large prototype and put them in a separate package that we can easily load? That would be really great.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Simon
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://www.inf.unisi.ch/phd/robbes