[Pharo-project] 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
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 <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
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 <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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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
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 <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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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
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 <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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 <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.
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
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 <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.
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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 <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.
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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
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
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
MC1.5 reinstates the in-memory "dictionary" repository to speed up such 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
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 < marianopeck@gmail.com> 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
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 <marianopeck@gmail.com
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, May 21, 2009 at 6:51 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
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. 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 < marianopeck@gmail.com
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 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
On May 21, 2009, at 3:10 PM, Mariano Martinez Peck wrote:
On Thu, May 21, 2009 at 6:51 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
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 <marianopeck@gmail.com
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 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
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 <stephane.ducasse@inria.fr
wrote:
On May 21, 2009, at 3:10 PM, Mariano Martinez Peck wrote:
On Thu, May 21, 2009 at 6:51 AM, Stéphane Ducasse <
stephane.ducasse@inria.fr
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 <
marianopeck@gmail.com
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 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Adrian Lienhard -
Alexandre Bergel -
Keith Hodges -
Lukas Renggli -
Mariano Martinez Peck -
Michael Roberts -
Nicolas Cellier -
Stéphane Ducasse