[Vm-dev] [squeak-dev] SHA512 squeak implementation?

[Robert]

Hi Phil,

I would first note that I released a new CryptographyHashing package with some cleanups, especially using the common protocol for #processFinalBuffer:bitLength:. Added a couple of SHA512 tests. #CryptoGreen! I decided to not remove the Registers, nor alter any tests, there are only a few. I am however, interested in the plugin you wrote.

[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?

On 3/9/20 6:56 PM, Phil B wrote:

> Robert,
>
> On Mon, Mar 9, 2020 at 6:41 PM Robert via Squeak-dev <squeak-dev at lists.squeakfoundation.org> wrote:
>
>> I see, alright, that's fair dinkum. I also feel strongly that a minimum
>> of tests be carried within the primary package for some code. If you
>> look at the Crypto packages, you'll see Hashing tests in hashing, Random
>> tests in Random, Cipher tests in Cipher. This way it is easy to run
>> them, off a CI server or what have you. The tests come with the code, is
>> a principle I try to follow.
>
> Just my .02: I don't like the approach of putting tests with the code.  I'm absolutely in favor of having as many tests as make sense, just please put them in a separate package.  While your approach seems reasonable for people who are working interactively on code and want to make sure things stay working as they are making changes, it doesn't make sense when what you are going for is a minimal or server image where the existing code is just being used, not actively developed.

My feeling, at this time, is that the tests size is a minimal increase to the size of unused code in an extremely large image, even if stripped. The issue is package management. I just split Crypto into 9 packages, a large number of dependent packages. I linked up dependencies. 8 of those packages have tests, so 8 more packages increases complexity, on the top of current complexity. Until package management can support test dependency, I would really rather leave it alone for now. I do see your perspective, I hope you see mine. So let's figure out how to do it best.

> Thanks,
> Phil
>
> Kindly,
> Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200310/14c29d37/attachment.html>