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