The aim is to package as close to as the same functionality as possible across a range of languages, both as a way to be authoritative about "collatz packages" and as a learning opportunity in several languages I have not worked in before, and to serve as a future example for packaging in multiple languages.
I've always appreciated the "Rosetta Stone"-esque compilations of similar tasks across multiple languages, including but not limited to;
- Rosetta Code
- The OG "Hello World" Collection
- Wikipedia's "Hello World" collection
- leachim6's "Hello World" compilation
And would like to compile a similarly motivated collection of implementations of functions utilised to compute iterations of the function that comprises the Collatz conjecture, a number theory conjecture that is incredibly easy to state, but remains unsolved. I've chosen this as the theme as I originally became interested in the problem a few years ago, as a "novel" problem the infamy of which made alluring, and ended up reacquiring some of the key results from a few decades ago.
I would also however, like to focus on languages that can be easily, or consequentially, distributed, and implement not just the algorithm similar to what the linked compilations above do, but also implement the distribution.
I've chosen python to start with as it's very easy to script calculations with, and was the language I wrote some scripts in years ago when playing around with the concept of attacking the Collatz conjecture via repeatedly splitting modulo conjugacy classes and comparing the resulting sub-classes with the set of conjugacy classes that where split. I've also added R and Julia as intended languages to implement next, with their relevance to math/data making them obvious candidates. Go, Java, and JavaScript via NodeJS, all seem like good candidates for the purposes of highly distributable/packageable languages.
Also worth targetting are the "GitHub packages" which supports Docker/OCI containers, Java Maven, C#/++ nuget, ruby gems, and npm.
Recently, I've been made aware of deps.dev, and it seems the implementations done so far for python, Java, and Go are scoring low! The go package appears to have no score at all, because the go package site does not appear to allow tags to be provided to it in any way other than through tags on the repository that follow semver strict enough to not accept prefixes, as well as any suffix being considered a candidate, and not an actual release, so until I change how I'm tagging orthogonal releases, what's interesting is that the python and java score cards are the same, because it appears to not be scanning them on a per language basis but rather the "meta" health of the repository itself, which is, obviously for both of them, this one, that they and all the others will eventually share. For the health of the repository to get only 3.7/10 is a bit shocking, so it'll be worthwhile reading through the sorts of checks it does, and how to improve on whatever is seems must not be as good as it could be!
These are the checks it's doing. Which come from the Open Source Security Foundation's Scorecard. This is what the score is at the moment.
Vulnerabilities,License,Binary Artifacts,Dangerous Workflow: are all10/10.Pinned-Dependenciesis7/10for "dependency not pinned by hash detected".- There's too many errors to fit on the screen, but it wants every dependency pinned to a hash, semver versions mustn't be good enough for it.
Branch-Protectionis3/10for "branch protection is not maximal on development and all release branches".- Warn: no status checks found to merge onto branch 'main'
- Warn: number of required reviewers is only 0 on branch 'main'
Code-Reviewis0/10for having only 2 of the last 30 commits against main come in via PR.Maintainedis0/10for 1 commit out of 30 and 0 issue activity out of 0 found in the last 90 days.CII-Best-Practicesis0/10for not having this badge?- Add the badge and work on its goals.
- Add the badge and work on its goals.
Dependency-Update-Toolis0/10for "no update tool detected".- Add a dependabot and renovatebot config.
Token-Permissionsis0/10for "non read-only tokens detected in GitHub workflows".- Define a "topLevel permission" in every workflow.
Signed-Releasesis0/10for "0 out of 5 artifacts are signed". It's counting all the python release files.Security-Policyis0/10for "security policy file not detected".- Add a
SECURITY.md
- Add a
Fuzzingis0/10for "project is not fuzzed".- Use either OSS-Fuzz or ClusterFuzzLite.
This might be a very silly thing to mention, but in my quest to assign 3 emojis to each implementation to make them visually easier to distinguish in the side panel, the ones I have chosen for C#, 🟢©#️⃣, and for R, ®🔵®, include the registered trademark and copyright symbols. Although, these don't seem to display as emoji in the browser which chunks the alignement horizontally, so I'm going to replace C# with the emojis that appear for "see" and "sharp" (there aren't any obvious "sea" ones, and the only "beach" one, 🏖, doesn't appear as an emoji in the text editor). I'm going to also make a dumb joke with "R" and replace borth "®" with pirate themed emoji.
Decided it would be a good idea to add the recommended vs code extensions to this, to record what I've used when developing it, initially for external reasons that prompted me to want to come back and sort out the 50 or 60 odd extensions I had. I had to split them, the result of code --list-extensions, between what was used for this, and what has been used for everything else. Regretfully the marketplace doesn't make it abundantly clear what the dependency graph between installed extensions looks like, so it's hard to know what the dependency graph should look like, but I've attempted to guess it as much as possible. Because json comments aren't a thing, but I want to separate the extensions into logical units, the top paragraph will be "generic" extensions applicable to the repo as a whole, and each subsequent paragraph will be the set of extensions per each implementation, in alphabetical order (ignoring case, unlike the github interface) (multi-root-workspaces is an interesting idea but probably overkill for us). Indeed, I just learnt while looking around some more after already writing the previous sentences, that VS Code supports a "JSON with Comments" mode for its own config, which is crazy. I guess I've spent long enough on it now though that I may as well end up just making a multi-root-workspace. Re-enabling the R extenions "REditorSupport.r" ran into an issue with the command it was trying to use to install its language server, which can instead be installed on windows with an admin cmd window running:
Rterm --silent --slave --no-save --no-restore -e "install.packages('languageserver', repos='https://cran.r-project.org/')"