dmorrill10 / acpc_poker_types Goto Github PK

Some companies will only use gems with a certain license.
The canonical and easy way to check is via the gemspec,

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Even for projects that already specify a license, including a license in your gemspec is a good practice, since it is easily
discoverable there without having to check the readme or for a license file.

For example, there is a License Finder gem to help companies ensure all gems they use
meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough
issue that even Bundler now generates gems with a default 'MIT' license.

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file),
github has created a license picker tool.

In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally
looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :).

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue and let me know. In either case, I'll follow up. Thanks!

p.s. I've written a blog post about this project

Easy fix, should just return first_state_of_first_round? || what's being returned now.

Doesn't happen that often because typically the first state of the first round is being checked for explicitly with first_state_of_first_round?.

For instance, when printing or retrieving an action, if a game def is provided, the match state should be smart enough to figure out the turn ordering and convert the requested action, or list of actions into a more context-ful representation (bets and checks instead of raises and calls when appropriate). The match state only needs to look within the context of the current round to do this anyway, so it won't even take much more computation.

Where PlayerAgent will contain state that persists across hands (stack, balance, seat, name) and HandPlayer will contain state that only lasts per hand. Each PlayerAgent will have a HandPlayer that it uses to track the state of the hand as it's being played.

While it's not an urgent problem, it is counterintuitive and makes community_cards more difficult to deal with.

Having worked more with the files in the project_acpc_server, I've noticed there's a lot of duplication in the ruby code in this gem. The implementation could be simplified and sped up considerably if this C code were better leveraged. Making the change should be safe and not difficult because of this gem's extensive test suite.

For instance, there's no need to break down the betting sequence down from its string form to a nested list of actions until this list is first requested. In fact, such a list is unnecessary. Instead, do a little extra computation to parse the string on demand. Often only the last action is requested anyway, and this can be done easily with a regex.