Hub Levente,
I like the idea of SHA256 and friends to throw an exception when #new is called directly SHA256 new. With a message to call newSHA256.
What do you think?
Kindly, Robert
On Tue, Jul 21, 2020 at 14:02, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Chris,
On Mon, 20 Jul 2020, Chris Muller wrote:
Hi Levente,
HashFunction newSHA256
instead of
SHA256 new
in order to take advantage of Levente's plugin.
That is indeed some sort of a change but it only affects those who compiled the SHA256Plugin themselves since that plugin wasn't shipped with the VM.
Ah, you're speaking about legacy code. I really hope we can include your plugin in future VM's. Are Eliot, et al, on board?
The most recent VMs ship with the plugins.
I decided against the practice of making #new return an instance of another class than the receiver, as it was with the previous implementation, because that makes it a lot harder for others to understand the code.
Hm. I sort of agree, although I guess Factory is a recognized pattern. To me, the issue is that writing
"SHA256 new"
, is a perfectly intuitive and obvious way to use it, but sticking out like a sore thumb as a subversively-wrong-way to-use-it. It'd be better if it threw an error, and even better than that if it just worked.
I know you care about the quantity of methods in the image (as do I), how about quality? Can SHA256 #new be improved by doing essentially what HashFunction #newSHA256 does, and simply sending some alternative to new (i.e.,
It's not clear what do you mean by caring about the quantity of methods.
basicNew initialize) to avoid the recursion?
That would do exactly what I do not want to do: #new would return an object whose class is not SHA256.
Above, you mentioned you decided against the practice, does that mean you're writing:
SHA256 newSHA256
? If not, how did you do it?
Use HashFunction's class side #new* methods to create the instances. HashFunction is a facade and a factory at the same time. I originally wanted to create a separate class for this role named Hasher, but HashFunction seemed to work just as well.
Levente
Thanks again for this great work.
- Chris
On Sun, Jul 19, 2020 at 9:55 PM Levente Uzonyi leves@caesar.elte.hu wrote: Hi Chris,
On Sun, 19 Jul 2020, Chris Muller wrote:
Hi Robert and Levente,
Yes, I *think* so! I'm just now getting up to speed after reading that epic thread between you and Levente (subject line: "SHA512 squeak implementation"). Thanks a ton to both of you, BTW, for this work!
After loading
ProCrypto-1-1-1 and ProCryptoTests-1-1-1,
all 205 tests are passing, however, it took me a bit to realize I need to use
HashFunction newSHA256
instead of
SHA256 new
in order to take advantage of Levente's plugin. This is great, thanks again!
That is indeed some sort of a change but it only affects those who compiled the SHA256Plugin themselves since that plugin wasn't shipped with the VM. I decided against the practice of making #new return an instance of another class than the receiver, as it was with the previous implementation, because that makes it a lot harder for others to understand the code.
Quick side question: Is it okay to reuse a SHA256 instance, or should I just create a new one for each and every message to hash?
All subinstances of HashFunction are reusable. The tests (see HashFunctionTest) do exactly that.
Levente
Best, Chris
On Sat, Jul 18, 2020 at 6:02 AM Robert Withers robert.withers@pm.me wrote:
Hey Chris,
Did this approach fix your issues?
Kindly, rabbit
On 7/13/20 11:46 PM, Robert wrote:
Hi Chris,
You should only need to run #3, which will load Registers. Hasher was from before we integrated the code into ProCrypto-1-1-1.
Installer as project: ‘Cryptography’; install: ‘ProCrypto-1-1-1’.
Then to load tests run:
Installer as project: ‘Cryptography’; install: ‘ProCryptoTests-1-1-1’.
Let us know if any tests fail and we can look into it.
Kindly, Robert
On Mon, Jul 13, 2020 at 19:52, Chris Muller asqueaker@gmail.com wrote:
Hi Robert, hi Levente,
I would like to utilize the latest crypto in my next project, would you help me with the current proper way to configure my image, and my vm with plugins?
(image) In going back through some recent messages on the mailing lists and instructions on squeaksource.com, I came across these incantations as current ways to load the image code:
- Installer ss
project: 'Registers'; install: 'Registers'; project: 'Hasher'; install: 'HAHasher-Core'; install: 'HAHasher-Tests'.
- Installer ss
project: 'Registers'; install: 'Registers'; project: 'Hasher'; install: 'HAHasher'.
- Installer ss project: 'Cryptography'; install: 'ProCrypto-1-1-1'.
I like these one-click-for-everything scripts for crypto -- it satisfies the good use-case of development and education, and also knowing all what's available to Squeak in one glance. My app's build script can cherry pick what it needs, but any advice on which starting point above or otherwise is appreciated.
(vm) I put the SHA2Plugin.so from Roberts dropbox in the lib directory, and it shows up as a "Loaded VM Module" in About Squeak. But, three of the "WithPluginTest"'s are failing. My OS is linux_x64. I don't know how to build Squeak or plugins from sources, but including it in the standard precompiled vm would be so pertinent for Squeak today, IMO. SHA256 is one of the ones I'm going to need, so would be nice to have it work via plugin. I assume it's a lot faster?
Thanks, Chris
On Tue, Mar 10, 2020 at 3:52 PM Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Robert,
With yesterday's help from Eliot and Nicolas, the SHA2Plugin is ready: http://squeaksource.com/Cryptography/CryptographyPlugins-ul.19.mcz The updated version of the image-side code is available in the Hasher repository. You can install it with:
Installer ss project: 'Registers'; install: 'Registers'; project: 'Hasher'; install: 'HAHasher-Core'; install: 'HAHasher-Tests'.
Levente
On Tue, 10 Mar 2020, Levente Uzonyi wrote:
Hi Robert,
Please have a look at: http://lists.squeakfoundation.org/pipermail/squeak-dev/2020-March/207851.htm... It answers all your questions.
Levente
On Tue, 10 Mar 2020, Robert wrote:
> Hi Levente, > > I got the SHA2Plugin built and deployed to my Crypto plugins folder. Now I am trying to figure out how to call it from SHA512. > > https://www.dropbox.com/sh/yhv253rwrhq0q5p/AAB7PKP2KPiGpDnIyule2h_Ia?dl=0 > > [plugin] I looked at it and please understand I think the classes you wrote and the framework is really quite nice. I am thrilled we found SHA512! It's impressive that your one plugin can handle a number of hash functions! > Now all I need is to find the code that calls the SHA2Plugin. Levente, would you share that code, please? > > Kindly, > Robert > >
Erg, I meant "Hi Levente", of course. It there an exception to mark deprecated and suggest alternate code to use?
K, r
On 7/21/20 3:22 PM, Robert wrote:
Hub Levente,
I like the idea of SHA256 and friends to throw an exception when #new is called directly SHA256 new. With a message to call newSHA256.
What do you think?
Kindly, Robert
On Tue, Jul 21, 2020 at 14:02, Levente Uzonyi leves@caesar.elte.hu wrote:
Hi Chris,
On Mon, 20 Jul 2020, Chris Muller wrote:
Hi Levente,
HashFunction newSHA256
instead of
SHA256 new
in order to take advantage of Levente's plugin.
That is indeed some sort of a change but it only affects those who compiled the SHA256Plugin themselves since that plugin wasn't shipped with the VM.
Ah, you're speaking about legacy code. I really hope we can include your plugin in future VM's. Are Eliot, et al, on board?
The most recent VMs ship with the plugins.
I decided against the practice of making #new return an instance of another class than the receiver, as it was with the previous implementation, because that makes it a lot harder for others to understand the code.
Hm. I sort of agree, although I guess Factory is a recognized pattern. To me, the issue is that writing
"SHA256 new"
, is a perfectly intuitive and obvious way to use it, but sticking out like a sore thumb as a subversively-wrong-way to-use-it. It'd be better if it threw an error, and even better than that if it just worked.
I know you care about the quantity of methods in the image (as do I), how about quality? Can SHA256 #new be improved by doing essentially what HashFunction #newSHA256 does, and simply sending some alternative to new (i.e.,
It's not clear what do you mean by caring about the quantity of methods.
basicNew initialize) to avoid the recursion?
That would do exactly what I do not want to do: #new would return an object whose class is not SHA256.
Above, you mentioned you decided against the practice, does that mean you're writing:
SHA256 newSHA256
? If not, how did you do it?
Use HashFunction's class side #new* methods to create the instances. HashFunction is a facade and a factory at the same time. I originally wanted to create a separate class for this role named Hasher, but HashFunction seemed to work just as well.
cryptography@lists.squeakfoundation.org
-
Robert -
Robert Withers