- made it so that Hand.__init__ calls the hhc readX methods in the right
order for that kind of Hand (Stud or Holdem/Omaha)
- hhc.readX methods then callback Hand.addX methods
Why? WHY! I hear you ask. Actually I can see there's very little gain,
sorry about that; but it sort of makes sense. Now you just make the
right kind of Hand, give it the text and the right kind of HHC filter,
and it makes itself.
- apart from that, biggest actual thing done is probably in adding
player cards for stud hands -- revamped and made it really clear (I
think) whats happening (see FullTilt.readStudPlayerCards)
When I run FullTiltToFpdf.py it goes through all the hands.
- Still have some print statements, have been changing them to
logging.debug or logging.info as I come across them.
You may find "tail -f logging.out" useful
Actually I'm not at all convinced about the use of logging except that
you can redirect it to stderr quite easily and then set the threshold
for what gets logged quite easily, so that might be a plus.
- Oh and the subclassing of Hand is getting clearer.
Everleaf converts hands
Moved process hand logic into the hand subclass that knows what it
wants, it calls back to the hhc (which knows about the format) to populate itself
Conflicts:
pyfpdb/EverleafToFpdb.py
pyfpdb/Hand.py
pyfpdb/HandHistoryConverter.py
Also fixes popups not closing correctly.
General cleanup in the HUD closing code. Closing a HUD
is now managed by the HUD_Main object--this should ensure
that no objects are left dangling.
- command line options
Try the following
./Everleaf --help
cat everleaf.txt | ./Everleaf -i - -o -
Try using -i -, and pasting in a hand. Be aware it needs an EOF
<ctrl>-d (unless you specify --follow, which isn't done yet)
- HHC is a thread
- hand gametypes per hand
- lots of stupid little things just to cause trouble
- added logging
Not yet done:
- tail -f mode
- integration into fpdb_import. Two options for grand plan here:
1) recently modified files get a HHC filter attached
when the HHC runs out of pipe it waits
runUpdated finds modified files and notifies the thread
2) the thread follows independently, when it runs out of input it
sleeps and then tries again at intervals
I like both, 1) involves bigger changes to fpdb_import whilst with 2) we
just point the existing fpdb_import code at the filter output (the way
we currently do filtering has to be altered though)
Comments welcome of course.
