Michael also answered that some features were integrated in the browser in envy, and that can be far more convenient. Until now, only the versions in change log are accessible from there. I have not much though of it, but I foresee several problems: 1) FROM WHAT PACKAGE COME REMOVED METHOD/CLASS ? Mariano did knew about the implementor, but that's not the case if you don't have a witness image handy. I have a debugger and a receiver that does not understand, but who tells me in which superclass/package lie the class/method in question? 2) RENAMING SHOULD ALSO BE TRACEABLE I also note that most tools haven't reified refactorings like renaming a method, adding/removing a parameter, and will handle these as an addition/deletion (very good way to break trace of authors for example). 3) RE-ORGANIZING SHOULD ALSO BE TRACEABLE What about moving a method in hierarchy? Or a class/method moved from one package to another... 4) RETRIEVING HISTORY SHOULD NOT TAKE HOURS Anyone working with Monticello can legitimely have questions about efficiency... Uploading and scanning Monticello packages is not free... SO WHAT? 1) could cost a large package scan GASP! 2 & 3) I note with interest the use of UUID for classes in frameworks like Spoon... How can this apply to methods? That's not obvious because of polymorphism. I can not only send a method from a package, but also implement my own version... The only easy way is to store an indication in Monticello... 4) That last point could be redhibitory... I would much better like a light weight list of changes travelling on the net, or a discovery service with its own protocol. I would like an access to a database syndicating several forks of Squeak along with full method history... Of course this database should be kept in sync with updated code from each fork... Nicolas 2009/5/19 Mariano Martinez Peck <marianopeck@gmail.com>:
On Tue, May 19, 2009 at 4:56 PM, Alexandre Bergel <alexandre@bergel.eu> wrote:
the topic of the discussion is not in sync with the thread topic.
My answer to Nicolas' was: Here is an idea: - Adding a button 'search' in a Monticello repository inspector (the one you get when opening a repository) - with a 'search' button, you can then enter a method location such as TextMorphEditor>>keystroke: - the list of versions that either added the method or removed it according to the ancestors.
How does that sound? I can work on it.
It's good to see you are trying to resolve this problem.
However, there are few things to add:
- the same situation can happen with removed classes, not only methods - suppose I found in which version a method was removed. What can I do ? just see commit comments. So, apart from that, we have to put a description in the comment that explains what was removed for example an even why.
What do you think ?
Cheers, Alexandre
Begin forwarded message:
From: Michael Roberts <mike@mjr104.co.uk> Date: 19 May 2009 19:06:13 CEDT To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed Reply-To: Pharo-project@lists.gforge.inria.fr
In general I would like to see a bit more envy tool like support in mc. I have not checked out OT or newer mc versions to see what is implemented. I would like the method vesions tool to map into a mc version and to quickly go from the class to mc view. Can we do this already? If not this would be really useful but I appreciate it has to be built. Otherwise I too scratch my head trying to work out where all the changes come in. I am not for a second proposing the envy model but the tool was integrated nicely. thanks mike
On Tuesday, May 19, 2009, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com
wrote:
To me, this raises a more general question. How can we trace a particular change in Pharo? Why when and where this change did occur? I know all is in the Monticello repository, but is there a quick and convenient way to answer such a question? I mean avoiding a manual scan of each and every Monticello version...
Or is it logged in the ChangeSet? In this case, what hidden menu or code snippet will help tracking the change?
Or should we use the issue tracker? Ideally, the reason for every change should be logged here. And every Monticello uploaded should refer to an issue. Even if this were strictly applied, not sure that is the way to retrieve information at such a detailed level.
If none of these tools can provide an easy answer, then yes, requests on mailing lists, IRC, or internet search can provide a much efficient answer. But that's the signature a tool is lacking.
I am agree. Actually, I thought to add in my email a generic question of that because I faced this problem several times and I didn't know what to do.
I wish Mariano gets an answer, but an answer on the method would be more profitable to every one. No problem. Perhaps someone knows haha.
Cheers
Nicolas
2009/5/19 Mariano Martinez Peck <marianopeck@gmail.com>:
Hi folks. I noticed that this two methods were removed from ThirtyTwoBitRegister:
asByteArray ^ ByteArray with: (low bitAnd: 16rFF) with: (low bitShift: -8) with: (hi bitAnd: 16rFF) with: (hi bitShift: -8)
reverseLoadFrom: aByteArray at: index "Load my 32-bit value from the four bytes of the given ByteArraystarting at the given index. Consider the first byte to contain the mostsignificant bits of the word (i.e., use big-endian byte ordering)."
hi := ((aByteArray at: index + 3) bitShift: 8) + ( aByteArray at: index + 2). low := ((aByteArray at: index + 1) bitShift: 8) + ( aByteArray at: index).
I need them for Glorp. I looked but I didn't found a similar message for them. I don't think adding them as an extension is a good solution here since this seems to be very "internal". is there a reason of the removing? If not, could them be added again? If there are reason, which should be the best approach to fix this in mi case?
I have no problem in commit them if you want.
Thanks!
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project