PropCheck.jl
DMARCParser.jl
PropCheck.jl | DMARCParser.jl | |
---|---|---|
1 | 1 | |
79 | 3 | |
- | - | |
8.0 | 5.1 | |
about 2 months ago | 7 months ago | |
Julia | Julia | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
PropCheck.jl
-
Julia as a unifying end-to-end workflow language on the Frontier exascale system
There is no rebuttal because nothing much has really changed culture wise. Sure, the various @inbounds issues and concrete bugs that are mentioned in Yuris post have mostly been addressed, but the larger point (that is, "what can I actually expect/get guaranteed when calling a given function?") definitely hasn't been, at least not culturally. Documentation of pre- and postconditions are still lackluster, PRs trying to establish that for functions in Base stall for unclear reasons/don't get followups and when you try to talk about that on Slack retorts boil down to "we're tired of hearing you complain about this" instead of trying to find a systemic solution to that problem. Until that changes, I have large doubts about Yuris post losing relevance.
My own efforts (shameless plug, https://github.com/Seelengrab/PropCheck.jl for property based testing inspired by Hedgehog and https://github.com/Seelengrab/RequiredInterfaces.jl for somewhat formalizing "what methods are needed to subtype an abstract type") are unused in the wider community as far as I can tell, in spite of people speaking highly of them when coming across them. I also don't think Kenos InterfaceSpecs.jl is the way forward either - I think there's quite a lot of design space left in the typesystem the language could do without reaching for z3 and other SAT/SMT solvers. I personally attribute the lack of progress on that front to the lack of coherent direction of the project at large (and specifically not to the failings of individuals - folks are always very busy with their lives outside of Julia development/other priorities). In spite of the fact that making this single area better could be a big boon with more traditional software engineers, which are very underrepresented in the community.
DMARCParser.jl
-
parsedmarc VS DMARCParser.jl - a user suggested alternative
2 projects | 1 Oct 2023
DMARC Parser written in Julia
What are some alternatives?
Mousetrap.jl - Finally, a GUI Engine made for Julia
CoherentNoise.jl - A comprehensive suite of coherent noise algorithms and composable tools for manipulating them.
Chain.jl - A Julia package for piping a value through a series of transformation expressions using a more convenient syntax than Julia's native piping functionality.
dmarc-srg - A php parser, viewer and summary report generator for incoming DMARC reports.
RequiredInterfaces.jl - A small package for providing the minimal required method surface of a Julia API
KernelAbstractions.jl - Heterogeneous programming in Julia
julia - The Julia Programming Language
parsedmarc - A Python package and CLI for parsing aggregate and forensic DMARC reports
InterfaceSpecs.jl - Playground for formal specifications of interfaces in Julia