New package: DioidsGEMM v0.1.0

[JuliaRegistrator]

• Registering package: DioidsGEMM
• Repository: https://github.com/sonosole/DioidsGEMM.jl
• Created by: @sonosole
• Version: v0.1.0
• Commit: cc3f7e74576eb7d1ad8e322a4b46b6507253485c
• Git reference: HEAD
• Description: GEMM of matrix-in-semiring
• Release notes:

Fast Semiring matrix multiplication library. It's an extendtion package for Dioids.jl

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines are all met! ✅

Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

3. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[goerz]

Thank you for submitting your package! The repository has no continuous integration set up at all (there is no .github folder). Please set up continuous integration to run the test suite automatically on GitHub Actions, and to collect coverage information. See https://modernjuliaworkflows.org/sharing/ for a tutorial on best practices. You can copy the CI scripts (and README badges) from most other popular Julia packages. Your test suite runs and passes locally, so this is mainly a matter of adding the workflow file.

Relatedly, there is already a v0.1.0 tag in the repository. For Julia packages, tags must be created after a version has been registered, not before. This is exactly because you cannot generally predict that a commit you submit for a particular version will pass registration, or whether it has to be amended. The recommended way to automate this is via TagBot. So, you should delete the existing tag, and install TagBot, which fits naturally with setting up the CI workflows.

Also, the Project.toml sets julia = "1". It does not make sense for any new package to set julia = "1". At this point, a new package should probably not support anything before Julia 1.10.

Note that you can always update a pending registration: just keep the version number the same, and retrigger the registration based on a new commit (by commenting @JuliaRegistrator register on that commit). This will update the existing registration PR. Changing the version number (or the name / repo URL) would create a new PR, which then has to be manually closed in favor of the new one.

Lastly, a design question. DioidsGEMM consists entirely of three Base.:* methods and a Base.show method for the Dioid type, which is defined in your own Dioids.jl. That is precisely the situation package extensions were introduced for: you could move this code into Dioids/ext/DioidsLoopVectorizationExt.jl with LoopVectorization as a weak dependency, and your users would get the accelerated semiring GEMM automatically as soon as they load LoopVectorization, without a second package in the registry and without defining methods on a type from another package. Is there a specific reason you would prefer to keep it separate?

Independently of all this, I noticed a bug while reading the code: the Base.show method in src/DioidsGEMM.jl calls display(x.data) instead of writing to io, so the matrix contents go to stdout rather than into the stream. For a matrix-valued Dioid, string(w) returns just "Dioid{max,+} contains " and prints the matrix to the terminal as a side effect. That method also seems like it belongs in Dioids.jl rather than here.