| Age | Commit message (Collapse) | Author |
|---|
|
|
|
I've added a dependency so if lib.macros isn't working, we can skip
all the tests in lib.functions. Therefore we can use lib.macros in
the test code.
|
|
Setup cantedraw/tests with a test-system record, as well as linking it
back to cantedraw so we can run test-system on cantedraw and run the
tests.
Using parachute, we can setup a suite of unit tests for each package.
For each package in src/ or lib/ we'll write a separate unit test
suite with tests for all the public exposing functionality.
I've setup a main suite in cantedraw/tests/main which will depend on
each of the unit test suites so we can run the tests all at once.
Currently we have one test for the --> macro.
|
|
|
|
|
|
This package defines a player data structure, collections of players,
and different interactions you can have with them:
- Extracting attributes (destructors)
- Checking if they're bankrupt or can bet
- Modifying a collection to adjust the balance of any one
player (including errors in case that isn't possible)
|
|
Currently can deal some hands and redeal some cards.
|
|
|
|
Gives a hand from a shuffled deck to the user, asks them to provide
indices for cards they wish to re-deal then does so.
|
|
Time to do the fun non-yakshaving part. I'll start out by writing
some custom types for the objects of concern: ranks, suits, cards and
sets of cards.
|
|
This is mostly a sanity check in-case anyone else decides to load this
system for use in their own package - don't want to conflict with
their names.
|
|
|
|
|
|
Why name it something unique when this is what I'm going to be making
at the end of it all? Just makes it more confusing for the end user.
|
