What a great idea for a project. Will try out. Any thoughts on supporting a CLI (or TUI) interface for browsing through the problem sets locally (titles, descriptions, difficulty, etc.)? On that note, open to contributions? And much respect for choosing Haskell.
I love open source and open systems in general. Popular competitive programming platforms aren't like that: not only is their source code closed, but they also don't publish the test cases used to evaluate submissions.
There are already projects that can submit your solutions through the LeetCode API and return the results. But I don't really like that approach, so I decided to build an open set of tests that aims to match the quality of LeetCode's tests as closely as possible. This way, you can run everything locally, without needing for example, an internet connection.
I see the project being useful for its most straightforward purpose: testing your solutions locally on your own hardware, without any submission delays and even completely offline. Since the tests are open, people can also build different tools around them. For example vim extensions and other integrations. Ofc it's not that simple, we currently support about 1400 problems (out of 4000~, including premium), and not all topics are covered.
LeetCode problems are usually added after each contest, and as far as I know their statements generally don't change afterward at least the actual problem itself doesn't.
As for test cases, there are occasionally solutions that are technically incorrect but still pass because a particular edge case isn't covered. We maintain our own test cases, including a DSL for writing large stress tests, and try to cover all possible cases.
In the worst case, a solution might pass our local tests but fail on LeetCode. I expect such cases to be rare and one of the benefits of having the tests open is that when someone finds a missing case, it can be added so nobody else runs into the same issue.
I just prompt my ai coding assistant directly to scaffold out problems and test cases.
One nice thing is the LLM can “reason” about my weak areas and tailor the drills it generates next to keep me on a productive path.
I personally don’t get much value from pulling in 1,400 arbitrary problems but this is cool for people who want to hit the ground running.
What a great idea for a project. Will try out. Any thoughts on supporting a CLI (or TUI) interface for browsing through the problem sets locally (titles, descriptions, difficulty, etc.)? On that note, open to contributions? And much respect for choosing Haskell.
Very cool. What motivated you to build this and what use case do you see for this project ?
I love open source and open systems in general. Popular competitive programming platforms aren't like that: not only is their source code closed, but they also don't publish the test cases used to evaluate submissions.
There are already projects that can submit your solutions through the LeetCode API and return the results. But I don't really like that approach, so I decided to build an open set of tests that aims to match the quality of LeetCode's tests as closely as possible. This way, you can run everything locally, without needing for example, an internet connection.
I see the project being useful for its most straightforward purpose: testing your solutions locally on your own hardware, without any submission delays and even completely offline. Since the tests are open, people can also build different tools around them. For example vim extensions and other integrations. Ofc it's not that simple, we currently support about 1400 problems (out of 4000~, including premium), and not all topics are covered.
how do you keep the local test cases in sync when the original problems or test cases change?
LeetCode problems are usually added after each contest, and as far as I know their statements generally don't change afterward at least the actual problem itself doesn't.
As for test cases, there are occasionally solutions that are technically incorrect but still pass because a particular edge case isn't covered. We maintain our own test cases, including a DSL for writing large stress tests, and try to cover all possible cases.
In the worst case, a solution might pass our local tests but fail on LeetCode. I expect such cases to be rare and one of the benefits of having the tests open is that when someone finds a missing case, it can be added so nobody else runs into the same issue.
The fact that this is written in Haskell is amazing in it of itself. Will try it out
so the final challenge is to try to print a string ? ;)
This is awesome!