Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 15 commits
- 12 files changed
- 2 contributors
Commits on Mar 4, 2024
-
-
Fix additional typo: ressource -> resource
These weren't caught in #28 and I missed them during review, so let's fix them now.
-
Add docs of
Possibilityto Userfacing APIThis can easily be exposed as well, since the various `Possibility` that are already constructible are already supported too.
-
Remove superfluous grave character
This caused misrendering in documentation and wasn't supposed to be there.
Commits on Mar 5, 2024
-
This lays out the basic "how/where do I contribute?" flow.
Commits on Mar 8, 2024
Commits on Mar 10, 2024
-
Add feature comparison table to FAQ
This was asked about on discourse, to make it easier for people to migrate.
-
Abbreviate comparison in documentation
The previous version caused bad visuals in the rendered documentation.
Commits on Mar 11, 2024
-
Change error shrinking to only compare the type
This is an improvement in the short term, since this allows errors with different messages to shrink better. A followup to this commit will allow users to hook into this a bit better, by providing a custom comparison function for their errors.
-
This function is intended to be used as a more fine grained comparison of thrown errors. This may be beneficial in case an error carries rich metadata that's a bit distinct from what Supposition.jl generates and that should shrink too.
-
When encountering more than one error during shrinking, Supposition.jl currently prints a message every time such an error is encountered, even if the error was already previously rejected as being distinct. This commit changes that, by caching the type & frame/source location where the error was thrown.
Commits on Mar 12, 2024
-
This was previously untested; adding error caching is a good opportunity to increase coverage too. When shrinking an error, if another error is encountered, we need to remember its location so that the user is only notified of each distinct error once. "Distinct" here means either 1) A different error type - if the types are different, the path to `throw`ing that error must have been different. This used to look at `==` of the thrown objects themselves, not their types, but that didn't play nice with custom errors with rich metadata. 2) A different source location. If the error originates from a different location, the paths to getting that error must have been different too. This is likely a bit more conservative than necessary (it can happen that two errors from different locations "mean" the same thing to the program), but since we care about inputs exploring error paths, they should be treated as distinct errors too. There is also a hook for figuring out which stackframe to report for caching when handling an error, `find_user_error_frame`. This currently only specializes for `ErrorException`, since that is commonly thrown from the `error` function. Reporting the location of that function instead of where it's called from as the "source" of the error is more likely to be helpful in distinguishing different classes of errors.
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v0.1.0...v0.2.0