Max, Why was the contract of SHA1>>hashStream: changed ? It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption. MD5 hashMessage: 'foo'. #[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216] SHA1 hashMessage: 'foo'. 68123873083688143418383284816464454849230703155 It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions. Can you please explain ? Sven
On Thu, Aug 29, 2013 at 3:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions.
I have no idea about SHA1, and it may well be wrong. But you still probably don't need an ugly hack :-). You can always have your configuration load different versions of your code for different Pharo versions. (but it is time consuming). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill
I'm not aware of such a change... this is probably an error/side effect of something else. Esteban On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Max,
Why was the contract of SHA1>>hashStream: changed ?
It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption.
MD5 hashMessage: 'foo'.
#[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216]
SHA1 hashMessage: 'foo'.
68123873083688143418383284816464454849230703155
It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions.
Can you please explain ?
Sven
On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I'm not aware of such a change... this is probably an error/side effect of something else.
This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the image⦠https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations
Esteban
On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Max,
Why was the contract of SHA1>>hashStream: changed ?
It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption.
MD5 hashMessage: 'foo'.
#[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216]
SHA1 hashMessage: 'foo'.
68123873083688143418383284816464454849230703155
It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions.
Can you please explain ?
Sven
On 30 Aug 2013, at 13:39, Marcus Denker <marcus.denker@inria.fr> wrote:
On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I'm not aware of such a change... this is probably an error/side effect of something else.
This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦
https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations
I want to wait for Max to respond/explain. But according to http://en.wikipedia.org/wiki/Sha1 "SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long." The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash.
Esteban
On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Max,
Why was the contract of SHA1>>hashStream: changed ?
It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption.
MD5 hashMessage: 'foo'.
#[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216]
SHA1 hashMessage: 'foo'.
68123873083688143418383284816464454849230703155
It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions.
Can you please explain ?
Sven
Bump. Max ? On 30 Aug 2013, at 13:52, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Aug 2013, at 13:39, Marcus Denker <marcus.denker@inria.fr> wrote:
On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I'm not aware of such a change... this is probably an error/side effect of something else.
This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦
https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations
I want to wait for Max to respond/explain.
But according to http://en.wikipedia.org/wiki/Sha1
"SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long."
The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash.
Esteban
On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Max,
Why was the contract of SHA1>>hashStream: changed ?
It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption.
MD5 hashMessage: 'foo'.
#[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216]
SHA1 hashMessage: 'foo'.
68123873083688143418383284816464454849230703155
It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions.
Can you please explain ?
Sven
https://pharo.fogbugz.com/f/cases/11664/SHA1-hashStream-should-return-a-Byte... with slice On 13 Sep 2013, at 15:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Bump.
Max ?
On 30 Aug 2013, at 13:52, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Aug 2013, at 13:39, Marcus Denker <marcus.denker@inria.fr> wrote:
On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I'm not aware of such a change... this is probably an error/side effect of something else.
This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦
https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations
I want to wait for Max to respond/explain.
But according to http://en.wikipedia.org/wiki/Sha1
"SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long."
The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash.
Esteban
On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Max,
Why was the contract of SHA1>>hashStream: changed ?
It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption.
MD5 hashMessage: 'foo'.
#[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216]
SHA1 hashMessage: 'foo'.
68123873083688143418383284816464454849230703155
It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions.
Can you please explain ?
Sven
Hi Sorry, I was on holidays and didn't see this. On 23.09.2013, at 20:45, Sven Van Caekenberghe <sven@stfx.eu> wrote:
https://pharo.fogbugz.com/f/cases/11664/SHA1-hashStream-should-return-a-Byte...
with slice
On 13 Sep 2013, at 15:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Bump.
Max ?
On 30 Aug 2013, at 13:52, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Aug 2013, at 13:39, Marcus Denker <marcus.denker@inria.fr> wrote:
On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I'm not aware of such a change... this is probably an error/side effect of something else.
This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦
Yes that's true. Those two classes were nearly identical. I resolved differences by using the latest method versions of differing methods. Therefore it might well be that I changed that method to the way it is today because the current version is the one with the younger timestamp (I think the changes all came from Stef). Cheers, Max
https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations
I want to wait for Max to respond/explain.
But according to http://en.wikipedia.org/wiki/Sha1
"SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long."
The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash.
Esteban
On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Max,
Why was the contract of SHA1>>hashStream: changed ?
It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption.
MD5 hashMessage: 'foo'.
#[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216]
SHA1 hashMessage: 'foo'.
68123873083688143418383284816464454849230703155
It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions.
Can you please explain ?
Sven
cool :) this was annoying me too :P On Sep 23, 2013, at 8:45 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
https://pharo.fogbugz.com/f/cases/11664/SHA1-hashStream-should-return-a-Byte...
with slice
On 13 Sep 2013, at 15:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Bump.
Max ?
On 30 Aug 2013, at 13:52, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Aug 2013, at 13:39, Marcus Denker <marcus.denker@inria.fr> wrote:
On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
I'm not aware of such a change... this is probably an error/side effect of something else.
This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦
https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations
I want to wait for Max to respond/explain.
But according to http://en.wikipedia.org/wiki/Sha1
"SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long."
The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash.
Esteban
On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Max,
Why was the contract of SHA1>>hashStream: changed ?
It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption.
MD5 hashMessage: 'foo'.
#[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216]
SHA1 hashMessage: 'foo'.
68123873083688143418383284816464454849230703155
It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions.
Can you please explain ?
Sven
participants (5)
-
Damien Cassou -
Esteban Lorenzano -
Marcus Denker -
Max Leske -
Sven Van Caekenberghe