[squeak-dev] [Vm-dev] SHA512 squeak implementation?
pbpublist at gmail.com
Tue Mar 10 15:34:41 UTC 2020
I'm not the Phil you're looking for. I only wrote my previous comment, not
the plugin you're asking about...
Phil (a different one ;-)
On Tue, Mar 10, 2020 at 9:59 AM Robert <robert.withers at pm.me> wrote:
> 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:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev