ThirtyTwoBitRegister methods removed
Locked
ThirtyTwoBitRegister methods removed
 
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ThirtyTwoBitRegister methods removed
|
|
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 wish Mariano gets an answer, but an answer on the method would be more profitable to every one. Cheers Nicolas 2009/5/19 Mariano Martinez Peck <[hidden email]>: > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ThirtyTwoBitRegister methods removed
|
|
> 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... This is an interestion question that I asked myself many times. 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. Cheers, Alexandre > > > 2009/5/19 Mariano Martinez Peck <[hidden email]>: >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ThirtyTwoBitRegister methods removed
|
|
In reply to this post by Nicolas Cellier
On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <[hidden email]> wrote: To me, this raises a more general question. 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.
No problem. Perhaps someone knows haha.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ThirtyTwoBitRegister methods removed
|
|
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 <[hidden email]> wrote: > > > On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <[hidden email]> 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 <[hidden email]>: >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)
|
|
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. Cheers, Alexandre Begin forwarded message: > From: Michael Roberts <[hidden email]> > Date: 19 May 2009 19:06:13 CEDT > To: [hidden email] > Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed > Reply-To: [hidden email] > > 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 > <[hidden email]> wrote: >> >> >> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <[hidden email] >> > 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 <[hidden email]>: >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)
|
|
On Tue, May 19, 2009 at 4:56 PM, Alexandre Bergel <[hidden email]> wrote: the topic of the discussion is not in sync with the thread topic. 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 ?
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)
|
|
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 <[hidden email]>: > > > On Tue, May 19, 2009 at 4:56 PM, Alexandre Bergel <[hidden email]> > 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 <[hidden email]> >> > Date: 19 May 2009 19:06:13 CEDT >> > To: [hidden email] >> > Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed >> > Reply-To: [hidden email] >> > >> > 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 >> > <[hidden email]> wrote: >> >> >> >> >> >> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier >> >> <[hidden email] >> >> > 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 <[hidden email]>: >> >>> 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 >> >>> [hidden email] >> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >>> >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> [hidden email] >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)
|
|
In reply to this post by Alexandre Bergel
To be honest I think that is the wrong way around. I never need to
search for a method. I am normally in a debugger so have the method. Just want to work out when it changed. However if the only way to solve that is to write a top down search rather than a bottom up sort of approach then go for it. It should be possible to spawn the search from all the browsers. Thanks mike On Tuesday, May 19, 2009, Alexandre Bergel <[hidden email]> 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. > > Cheers, > Alexandre > > > Begin forwarded message: > >> From: Michael Roberts <[hidden email]> >> Date: 19 May 2009 19:06:13 CEDT >> To: [hidden email] >> Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed >> Reply-To: [hidden email] >> >> 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 >> <[hidden email]> wrote: >>> >>> >>> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <[hidden email] >>> > 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 <[hidden email]>: >>>> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)
|
|
In reply to this post by Mariano Martinez Peck
> 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 ? It makes sense. The method or the class could even be reintroduced. I will give a try in the next few days. Alexandre > > > Begin forwarded message: > > > From: Michael Roberts <[hidden email]> > > Date: 19 May 2009 19:06:13 CEDT > > To: [hidden email] > > Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed > > Reply-To: [hidden email] > > > > 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 > > <[hidden email]> wrote: > >> > >> > >> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <[hidden email] > >> > 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 <[hidden email]>: > >>> 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 > >>> [hidden email] > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > >>> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [hidden email] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)
|
|
In reply to this post by Michael Roberts-2
I meant in Monticello.
What I often need is the following: - the name of the committer who removed/added a class/method - the comment of the version in which this change occurs. Am I the only one who experience this? Alexandre On 19 May 2009, at 23:33, Michael Roberts wrote: > To be honest I think that is the wrong way around. I never need to > search for a method. I am normally in a debugger so have the method. > Just want to work out when it changed. However if the only way to > solve that is to write a top down search rather than a bottom up sort > of approach then go for it. It should be possible to spawn the search > from all the browsers. > > Thanks mike > > On Tuesday, May 19, 2009, Alexandre Bergel <[hidden email]> > 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. >> >> Cheers, >> Alexandre >> >> >> Begin forwarded message: >> >>> From: Michael Roberts <[hidden email]> >>> Date: 19 May 2009 19:06:13 CEDT >>> To: [hidden email] >>> Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed >>> Reply-To: [hidden email] >>> >>> 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 >>> <[hidden email]> wrote: >>>> >>>> >>>> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <[hidden email] >>>>> 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 <[hidden email]>: >>>>> 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 >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)
|
|
I don't think you are the only one!
- the previous version(s) of a method A problem of implementing this is that you have to download each version of a repository and analyze it, which can take a considerable amount of time. Adrian On May 20, 2009, at 10:00 , Alexandre Bergel wrote: > I meant in Monticello. > What I often need is the following: > - the name of the committer who removed/added a class/method > - the comment of the version in which this change occurs. > > Am I the only one who experience this? > > Alexandre > > On 19 May 2009, at 23:33, Michael Roberts wrote: > >> To be honest I think that is the wrong way around. I never need to >> search for a method. I am normally in a debugger so have the method. >> Just want to work out when it changed. However if the only way to >> solve that is to write a top down search rather than a bottom up sort >> of approach then go for it. It should be possible to spawn the search >> from all the browsers. >> >> Thanks mike >> >> On Tuesday, May 19, 2009, Alexandre Bergel <[hidden email]> >> 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. >>> >>> Cheers, >>> Alexandre >>> >>> >>> Begin forwarded message: >>> >>>> From: Michael Roberts <[hidden email]> >>>> Date: 19 May 2009 19:06:13 CEDT >>>> To: [hidden email] >>>> Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed >>>> Reply-To: [hidden email] >>>> >>>> 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 >>>> <[hidden email]> wrote: >>>>> >>>>> >>>>> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <[hidden email] >>>>>> 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 <[hidden email]>: >>>>>> 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 >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>> project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)
|
|
> A problem of implementing this is that you have to download each
> version of a repository and analyze it, which can take a considerable > amount of time. Such a search is not really practicable. Even if you have the versions stored locally you need to load and calculate the difference between the snapshots. Furthermore you might have versions missing that are required to accurately answer the question. Different branches make the search even more complicated. Monticello 2 can answer such questions efficiently. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Lukas Renggli wrote:
>> A problem of implementing this is that you have to download each >> version of a repository and analyze it, which can take a considerable >> amount of time. >> > > Such a search is not really practicable. Even if you have the versions > stored locally you need to load and calculate the difference between > the snapshots. Furthermore you might have versions missing that are > required to accurately answer the question. Different branches make > the search even more complicated. > > Monticello 2 can answer such questions efficiently. > > Lukas > > analyses. The "dual changes" sorter puts two repositories, (or the same repository) on both sides, and the delta's in the middle. There is supposed to be a "report" function which generates a step by step description of thechanges between two repos. This report is supposed to be displayed in the middle. Keith _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ThirtyTwoBitRegister methods removed
|
|
In reply to this post by Mariano Martinez Peck
I searched in Monticello for the package System-Digital Signatures and in the Pharo repository I only see two commits and even in the first one, these two methods are not there. But, they are in Squeak. So, know I guess where this commit should be? where I can search ?
Thanks! Mariano On Mon, May 18, 2009 at 9:27 PM, Mariano Martinez Peck <[hidden email]> wrote: Hi folks. I noticed that this two methods were removed from ThirtyTwoBitRegister: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ThirtyTwoBitRegister methods removed
|
|
If you need them for glorp copy them from Squeak and publish a new
package version working for Glorp in PharoInbox I will push it in pharo On May 21, 2009, at 3:07 AM, Mariano Martinez Peck wrote: > I searched in Monticello for the package System-Digital Signatures > and in the Pharo repository I only see two commits and even in the > first one, these two methods are not there. But, they are in Squeak. > So, know I guess where this commit should be? where I can search ? > > Thanks! > > Mariano > > On Mon, May 18, 2009 at 9:27 PM, Mariano Martinez Peck <[hidden email] > > wrote: > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ThirtyTwoBitRegister methods removed
|
|
On Thu, May 21, 2009 at 6:51 AM, Stéphane Ducasse <[hidden email]> wrote: If you need them for glorp copy them from Squeak and publish a new Ok, I will do that. I am trying to see how the fax the license signed. However, it is not that I NEED it for Glorp. I mean, I can put it in Glorp as an method extension with *Glorp and will work. But for me, these two methods are ok to be in Pharo. Cheers, Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ThirtyTwoBitRegister methods removed
|
|
On May 21, 2009, at 3:10 PM, Mariano Martinez Peck wrote: > > > On Thu, May 21, 2009 at 6:51 AM, Stéphane Ducasse <[hidden email] > > wrote: > If you need them for glorp copy them from Squeak and publish a new > package version working for Glorp in PharoInbox > I will push it in pharo > > Ok, I will do that. I am trying to see how the fax the license signed. > > However, it is not that I NEED it for Glorp. I mean, I can put it in > Glorp as an method extension with *Glorp and will work. But for me, > these two methods are ok to be in Pharo. sounds like so push them > > > Cheers, > > Mariano > > > On May 21, 2009, at 3:07 AM, Mariano Martinez Peck wrote: > > > I searched in Monticello for the package System-Digital Signatures > > and in the Pharo repository I only see two commits and even in the > > first one, these two methods are not there. But, they are in Squeak. > > So, know I guess where this commit should be? where I can search ? > > > > Thanks! > > > > Mariano > > > > On Mon, May 18, 2009 at 9:27 PM, Mariano Martinez Peck <[hidden email] > > > wrote: > > 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 > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: ThirtyTwoBitRegister methods removed
|
|
Just forget this topic. These methods actually are needed by the Cryptography package. Glorp port to Squeak only can be used with Postgres. So, I was doing the test with the native postgres driver. But, if you have configured your postgres database with MD5 (as I have), the package Cryptography is needed. I will configure my postgres without md5. When someone has time and do a port of Cryptography I can go on with this.
Sorry for the noise. Mariano On Thu, May 21, 2009 at 2:19 PM, Stéphane Ducasse <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |