I either remove it or add the 64-bit abi. Since it's only there to run
in the emulator let's just leave it in for DEBUG builds. If I need to
run a release build in the emulator I can add it back.
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.
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.
