Add a basic regular expression engine to the dictiter, and to the UI add
the ability to filter for "starts with", "contains" and "ends with",
which translate into ANDed RE_*, _*RE_* and _*RE, respectively (with
_ standing for blank/wildcard). The engine's tightly integrated with the
next/prevWord() functions for greatest possible speed, but unless
there's no pattern does slow things down a bit (especially when "ENDS
WITH" is used.) The full engine is not exposed (users can't provide raw
REs), and while the parser will accept nesting (e.g. ([AB]_*[CD]){2,5}
to mean words from 2-5 tiles long starting with A or B and ending with C
or D) the engine can't handle it. Which is why filtering for word length
is handled separately from REs (but also tightly integrated.)
Users can enter strings that don't map to tiles. They now get an
error. It made sense for the error alert to have a "Show tiles"
button, so there's now a dialog listing all the tiles in a wordlist,
something the browser has needed all along.
The Maven repo that includes the (FOSS) client library for MQTT isn't
approved by the f-droid build system, so for now rip MQTT out of that
variant. Long-term I'll have to fix this, either by persuading the
f-droid folk to permit the library or by building the C client from
source in my jni library -- or when the relay goes away the f-droid
build will cease to offer internet play.
I was really after the situation where a game could never be
opened. There are lots of reasons a single failure can occur, not least
of which is installing via adb while game's open. :-)
It looks bad, especially to a new user we suspect. Also add retries,
hoping that whatever caused the thumbnail to fail to load once will not
happen again.
Get rid of subclasses, since there's not the clear inheritance structure
I imagined. Any dialog type might want a not-again checkbox, or to have a
third button offer an unexpected option. This is a big change that needs
some bake time.
The Maven repo that includes the (FOSS) client library for MQTT isn't
approved by the f-droid build system, so for now rip MQTT out of that
variant. Long-term I'll have to fix this, either by persuading the
f-droid folk to permit the library or by building the C client from
source in my jni library -- or when the relay goes away the f-droid
build will cease to offer internet play.
I was really after the situation where a game could never be
opened. There are lots of reasons a single failure can occur, not least
of which is installing via adb while game's open. :-)
It looks bad, especially to a new user we suspect. Also add retries,
hoping that whatever caused the thumbnail to fail to load once will not
happen again.
Get rid of subclasses, since there's not the clear inheritance structure
I imagined. Any dialog type might want a not-again checkbox, or to have a
third button offer an unexpected option. This is a big change that needs
some bake time.
Change copy-strings.py to insist that no language provide a format
string not also found in English (since parameters to match all English
format string are sure to exist, but other languages are free NOT to
match them.) It's ok for other languages to provide "few", for example,
when English doesn't.
For some reason I wasn't unless it was the current instance, meaning
that some would leak and forever be connecting and disconnecting as
failures were in effect ignored.
Moving logic into the timer itself. There's always meant to be one
running, set from between 10 seconds and 23 hours from now. Code
receiving messages (mqtt or relay) resets the backoff when a message is
received, so when there's activity the timer should stay short. Somebody
with no games at all will have attempts made to connect to the relay and
mosquitto once/day, which is when invitations via that method would be
received. Devices with FCM should see lower latency of course.
There were ways of leaving multiple instances running, I think fighting
for resources and keeping each other from connecting. Now I think there
can only be one. And lots of logging will help find future problems.
This is meant to replace the relay eventually, but for now it's a new
option, like BT or SMS, to be chosen. Protocol is handled in common/
code for the first time, meaning that linux and android interact without
the need to keep two platforms in sync. Linux uses lib-mosquitto, and
Android uses eclipse's Paho client (the generic java version, not the
one that uses four-year-old Service patterns and so crashes for SDK >=
26.)
Hungarian is unique (so far) in having two-letter tiles that can be
spelled with one-letter tiles AND in allowing words to be spelled both
ways. This crashed search based on strings because there were
duplicates. So now search is done by tile arrays. Strings are first
converted, and then IFF there is more than one tile array result AND the
wordlist has the new flag indicating that duplicates are possible, THEN
the user is asked to choose among the possible tile spellings of the
search string.
Strictly speaking I think a subset is ok. I need to fix my build scripts
OR figure out how to enable the checking Weblate claims to have. The
string I modified is isn't used AFAIK so it's not urgent.
Linux and Android duplicated all the code to parse a wordlist file --
and shared a bug that needed fixing. So now most of that is in a common/
function both call, and the bug -- failing to mask out flag bits I don't
care about -- is fixed.
I'm getting crashes and don't want to think about it. It may be time to
remove this, though it's needed for logging-storage to work from jni.
To be revisited....
Separated the refcounting and ptr-as-long wrapping aspects of GamePtr
into a superclass that others might later inherit from. Cleaned up
dict_iter entrypoints, and added sanity checks to both structs so I'll
quickly notice if I get the ptr management wrong.
Fixing a problem with languages (like Hungarian) where it's legal to use
a two-letter tile or two single-letter tiles to play the same word. When
words are seen, or searched for, as char-arrays, there are
duplicates. Current code crashes, but there's also risk the user gets
unexpected behavior. Crash is fixed, and foundation laid for better UX,
by doing all searches for tile arrays. If a search string translates to
more than one tile array the user must choose. For that choice to make
sense it's now possible to translate tile[] to char[] with a delimiter
between the tile strings.
I'm keeping it AND asserting at every possible location that the env
passed all the way in is the same as what the mapping produces. If in
months I haven't seen a single crash then I can evaluate which way of
passing the env around is better. (It'd be code size vs. performance,
as the passing of env is noticably faster. Code size could be fixed by
turning 'XWEnv xwe,' into a macro that goes away on some builds.)
I was getting an occasional crash using a stale env to delete a dict's
resources because the dict was cacheing the env that created it. Dumb!
Using the thread->env mapping stuff worked, but that felt risky and so I
tried just passing it in. It's safe, and involves an amount of change I
can tolerate. So likely going that way.
With reject-phonies set this will trigger the reject path.
Also init CommonPrefs in jni land since its makePhonyPct, left unitialized,
causes the robot to deliberately reverse every turn, firing an assertion that the
robot's moves are legal.
Currently detects the same as tiles not in a line and calls out to a new
util method that's currently parameter-less. On Android the option only
appears in d variants.
On each open, increment a counter. And if we're able to close without a
crash intervening, decrement. Once we're trying to open with a non-0
counter we have a bad game. Open only after warning the user.
The lock was leaking when sometimes the OS would call onStop() without
isFinishing() being true, then never use the fragment again. And never
call onDestroy(). Releasing the lock in onStop and regetting it in
onResume seems to fix, but this needs some testing and time.
The problem appears to be that the new <vector/> .xml drawable has a
greater height for purposes of layout. Specifying dimensions seems to be
the way to go, though devices may vary.
The problem appears to be that the new <vector/> .xml drawable has a
greater height for purposes of layout. Specifying dimensions seems to be
the way to go, though devices may vary.
reverse change in 19fa3fce05 (April 4
2019) making MainActivity singleTask, which caused starting the app to
launch the gamesList screen rather than the game that had been open when
it was moved to background. Now it's "standard," and I have to hope that
doesn't produce new problems. As I wrote back then, we'll see. More
quickly I hope.
Required redoing how I invoke the NDK. The limititations I had to hack
around before seem fixed, so this is probably better. But there will be
glitches. :-)
The common code truncates to 255 *bytes*, not chars, so this isn't even
right, but at least for ascii users it'll make it less likely that
what's typed doesn't all get sent. The right fix is to change the format
to not limit sent str len to 255 bytes. See commit 512a8e1af.
Len byte was limited to 255, but would get clipped (masked with 0xFF)
then all the string data would get written. So on receipt, the clipped
length was taken to be that of the string data, with the rest of the
string to be interpreted as something else. An array index, in this
case.
The common code truncates to 255 *bytes*, not chars, so this isn't even
right, but at least for ascii users it'll make it less likely that
what's typed doesn't all get sent. The right fix is to change the format
to not limit sent str len to 255 bytes. See commit 512a8e1af.
Len byte was limited to 255, but would get clipped (masked with 0xFF)
then all the string data would get written. So on receipt, the clipped
length was taken to be that of the string data, with the rest of the
string to be interpreted as something else. An array index, in this
case.
To move away from generating .png files, I need to be able to specify
which of the .svg files is used as a source at build time. (The rest
will be converted manually into .xml files that are checked in.)
