When a stream reader and writer are out of sync it often shows up as
trying to read off the end of the stream (firing an assert.) It's useful
to know where that's coming from on android where there's usually no
stack trace in the jin world. So pass __func__ in using macros, and log
before asserting. Crude but quick and already useful.
When I started opening a lot of games at the same time hit a race
condition that synchronized fixes. Duh. Since two similiarly used
variables with the same name confused me, changed that too.
Add a third processor type to the .so, and fix first compile-time
warnings and then a few dumb bugs based on assumptions about ptr sizes.
Works to play networked games and browse wordlists, but is not
extensively tested and needs to be before release.
Looking for a common but not-yet-reproducible situation where the
gamelock gets stuck preventing a game from being opened, usually related
to a move arriving. One thing that looked wrong is it seemed possible to
have the refcount drop to 0 then get increased again, causing somebody
to thing he has a lock when it's actually unlocked. So assert to try to
catch that case (and synchronize to make it much harder.)
command: find . -name '*.jp*g' -o -name '*.png' | xargs exiftool -all=
Did this because fdroid is complaining about metadata and I can't see
any obvious changes in the appearance of the app, but it's not
well-considered. Back this out if there are problems.
I think there's a rare race condition here. Assuming it results from a
bad network state rather than two sends coming too quickly, respond to
not having a connection by killing the thread so the next send will
retry.
Failure to immediately get a lock for a rowID in an intent meant that
other intent processing kicked in, and might have done the wrong
thing. So now if there's a rowid in it we try nothing else. And we use
the GameLock callback mechanism to deal with the case where it's
temporarily unavailable, as it will be when an incoming move is being
dispatched to it.
(DEBUG only) I'm seeing deadlocks in a non-reproducible way and need to
get at the source. This should log the stacks of long-held locks, and
notify via Toast (when possible) when it occurs.
No point in worrying about whether a thread exists without emptying its
queue. Instead have a thread start when something's added to the queue
and exit when it's been empty for a while. Only trick is the need to
remember the phone number[s] on behalf of which a retry's necessary
because jni code is waiting to see if combining can be done.
Should not show the new you-can-lookup-uncommitted-words hint for
already-played words, so needed to be able to tell difference between
the two. Now you can -- and on the gtk side I draw them differently
because I can.
It's crashing all the time and involves a system that only exists in
debug builds. So I should understand the root cause, but other stuff
needs to get done first.
When a word's been formed as part of the current turn, but not yet
committed, allow long-tap to trigger an offer to look it up online same
as for already-committed words. Allows checking the legality of
potential plays AND figuring WTF the hint feature just suggested.
Scrolling's needed in some cases, and you can't easily put a ListView
inside a ScrollView. So replace the ListView with a LinearLayout whose
contents I manage manually, and wrap the whole layout in a ScrollView.
