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

[Robert]

Hi Chris,

On 3/9/20 7:37 PM, Chris Muller 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.
>
> +1   Everyone has different configuration needs.  As you know from your recent investigations on dependencies, it doesn't mean the ability to load (Core+Tests) has to require two clicks, it can still be just one.  Including tests is not useful for the use-case of "verifying you're running the correct software" either, only an externally applied signature scheme can do that, since you have to verify the tests packages, too.

1) I totally see the benefits of separate tests, but how to manage them best?

The shortcoming is in conditional dependencies. I stil lhave a weak understanding of .mcm files, for Monticello Configurations. Is it possible to specify a conditional dependency, so when #tests are loaded, all the #core components have a #tests dependency, that is installed when requested? I do not know. It needs to be so.

I'll point to a page in Java, which has definitely solved this class of needs. They use a small language, like Maven, or a full blown language, like Gradle, in Groovy. Maven relies on a .POM file, a json encoded specifications. Maven works in terms of archives. They build artifacts and their dependencies are artifacts. A dependent artifact specifies the repository, the archive name/id in that repository and you can specify conditions, like a load specification for #tests. When you run the maven POM you specify #build or #tests or whatever target tag you use (#archive).  I am unsure if we have this capability, we should. Can we extend Monticello forwards to language oriented package & dependency management, yet still be backwards compatible? Can we attach a "POM" file to the Monticello artifact? How does a Monticello Configuration work?

2) How can loading #core + #test be one-click? I would like to know.

3) I think validating vm components is a different conversation, entirely.

K, r

>  - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/cryptography/attachments/20200310/87802c09/attachment.html>