First large oversight uncovered by beta testers: SpellingTool claimed to handle languages that don't allow codas, but doesn't.

Fixing that right now.

Spelling Tool 1.1 is now being tested by a handful of projects. It has an easier interface and finds even better syllable rules.

Spelling Tool is now being tested by a limited number of consultants. Minor refinements continue to be made, but the features called for at our Fall meeting have been added.

The Paratext team plans to distribute Spelling Tool as an update file (.PUD) in the near future, along with updates to other checking scripts.

Paratext trailing diacritics seem to work now. Just had to use the same preprocess function as the check.

Just tried Yupik. ST seems to handle its Unicode combining diacritics just fine.

I'm close (I think) to wrapping the beta version up for testing, but there's this nagging problem with combining diacritics. I think I have it working with Unicode combining diacritics, and I should test it on Yupik.

But Paratext diacritics are another matter (where one can change language settings to allow any character to be a preceeding or following diacritic). Without a live project, I've had to try make my own, but it's taking a long time to do so, and I'm guessing at best.

I thought I could just copy a book of RVS95 over, then encode some sample diacritics. But when you change language settings for the project, it changes them for all Spanish projects. No good. I'll have to make a project with it's own language.

Babelpad made adding tests for Greek and Latin supplement characters a snap. Got both done. Now I'll focus on the analyze syllables check (Check #1).

Yesterday and today I tested and wrote a general character classifier. It will tell the syllable analysis check how to guess what are the consonants, vowels, and semivowels in the project.

Latin basic is complete.

Cyrillic tests need to be double checked against Expert data.

Greek and Latin extended tests not written yet. Shouldn't be hard.

Spent 2-3 hours today trying to speed up parsing with memoization. Got the syllable lexer memoized. It was actually slower.

The word parser/divider isn't done in a functional style, so I found it hard to memoize. It might stand to gain more, since it has more Python loops, etc., but it started looking like a time pit, so I quit. I left the code in there: Syllables.Word._FastSplitRest(), but I made sure compile() never calls it. Might come back to it later, but I doubt it, unless speed really becomes an issue.

It still bugs me, though: I know we are parsing some of the same tails over, and over, and over. But at this point, it's waste a few cycles, or waste a lot of hours.

If this becomes an issue, it'd be wise to profile first, I think. I was really sure the syllable lexer would be easy to memoize, and it was. I was really sure it would give me 10x the speed, but it did the opposite. Python can be that way, I've heard: your gut (your c and asm?) instinct about what's fast and what's not isn't always right.

I'm working this week on cleaning up old source code. I hope to have the new stuff fully functional by Monday, ready to make the requested feature changes over the next week or two.