table exactly and I fear that it makes the ACIP->Tibetan converter code
a lot uglier. The TODO(DLC)[EWTS->Tibetan] comments littered throughout
are part of the ugliness; they point to the ugliness. If each were addressed,
cleanliness could perhaps be achieved.
I've largely forgotten exactly what this change does, but it attempts to
improve EWTS->Tibetan conversion. The lexer is probably really, really
primitive. I concentrate here on converting a single tsheg bar rather than
a whole document.
Eclipse was used during part of my journey here and some imports were
reorganized merely because I could. :)
(Eclipse was needed when the usual ant build failed to run a new test
EWTSTest. And I wanted its debugger.)
Next steps: end-to-end EWTS tests should bring many problems to light. Fix
those. Triage all the TODO comments.
I don't know that I'll ever really trust the implementation. The tests are
valuable, though. A clean implementation of EWTS->Tibetan in Jython
might hold enough interest for me; I'd like to learn Python.
conversion. The tag 'TODO(DLC)[EWTS->Tibetan]' exists all over the
place. EWTS->Tibetan isn't here yet; lexing isn't here yet; this is
mainly a refactoring so that the ACIP->Tibetan code can be reused to
do EWTS->Tibetan.
I'm committing this because tests pass (it shouldn't be breaking
anything), because I want a checkpoint, and because the laptop this
sandbox was on isn't my preferred development environment.
Fixed part of bug 998476 and part of an undocumented bug. Discovered a
new bug, "aM" should be generated but only "M" is.
The undocumented bug was that laMA was generated when lAM should have been.
The part of bug 998476 that was fixed: laM, laH, etc. are now generated.
This does nothing about paN etc.
Some refactoring here; this is not a minimal diff.
Added tests of TMW->EWTS that use ACIP to get the TMW in place
because EWTS->TMW is a faulty keyboard at present.
non-reference, publicly available ACIP files (hundreds of megabytes of
them) through the converter. The frequencies of these tsheg bars in
in the file, too.
(which I found on suigeneris.org, not apache.org) in order to bulletproof the
Tibetan Converter tests. They used to fail due to nondeterminism in the
Java RTF writer; they should no longer fail.
I've also changed it so that the Tibetan Converter tests run in headless
mode, which means that they'll run on the nightly builds server.
noticed that formatting is mostly OK but sometimes gets bungled slightly.
I tried everything I could think of, and now I'm passing the buck to Java's
RTF support.
TMW_RTF_TO_THDL_WYLIE (now misnamed) support TMW->TM
conversion (but not TM->TMW). There is an automated test case for a
TMW->TM conversion.
I have full confidence in this conversion. Even the smallest glitch in the core
functionality (not formatting) would surprise me.
clean check'. Right now there are tests to ensure that typing certain
sequences of keys in the Extended Wylie keyboard gives the expected
Extended Wylie back when "Tools/Convert Tibetan to Wylie" is invoked.
The syntactically illegal d.wa now converts to Tibetan and then back
to d.wa (not dwa, as it did); likewise with the illegal g.wa. wa
doesn't take any prefixes, but I prefer clean end-to-end
behavior. (jeskd doesn't go end-to-end, though.)
Note that you cannot successfully run the DuffPane tests on a Linux
box unless your DISPLAY variable is set correctly. Thus, my nightly
builds will fail with an Error (as opposed to a Failure).
Jskad/extensions. If you're lazy, you can move them to
extensions/drop-ins, but the correct thing to do is to move x*.jar to
$ANT_HOME/lib [next to vamp.jar, if you're already set up for Java Web
Start builds]. This is a side effect of improving the nightly builds.
Nightly builds now feature an HTML summary of the JUnit test results,
a datestamp, and full API docs in two flavors.
If you use a patched vamp.jar [e-mail me] that can run when an X11
display is not available (there is not an analogous problem for
Windows servers, I suspect), all you have to do to put up a nightly
builds site is to set up CVS access so that no password is requires
using SSH public-key crypto (sf.net documents how to do so well) and
then use the following daily cron job on your Unix box:
#! /bin/sh
renice +19 -p $$ >/dev/null 2>&1
su -l joe-user /bin/sh -c /var/www/thdl/nightly/doTheBuild.sh
where joe-user is an unprivileged user who has installed Ant properly
(see the updated BuildSystems.html on the developer's site off of
thdltools.sf.net) and set himself up a Jskad sandbox with a Fonts
sandbox underneath it in, e.g., /var/www/thdl/nightly/Jskad. Here's
doTheBuild.sh:
#! /bin/sh
JSKAD=/var/www/thdl/nightly/Jskad
DEST=/var/www/thdl/nightly/builds
HISTORY=/var/www/thdl/nightly/history
DATE=`date`
if test ! -d $DEST; then \
echo "$DEST does not exist ($DATE)." >> history; exit 1; fi
(cd $JSKAD && ant dc-nightly-build \
&& rm -fr ${DEST}/* \
&& cp dist/nightlyBuild.zip $DEST \
&& cd $DEST \
&& unzip nightlyBuild.zip)
if test $? != 0; then echo "NIGHTLY BUILDS FAILED on $DATE" >> $HISTORY; exit 2; fi
DDDATE=`date`
echo "Success on start=$DATE end=$DDDATE" >> $HISTORY
exit 0
that I like unit tests, my Unicode conversion work is going to have to
be thorougly tested for reasons I will outline in
http://thdltools.sf.net/BuildSystems.html later today.
Added the freely licensed JUnit 3.8.1 binary to the repository, along
with some README files. Added a new supporting buildfile,
junitbuild.xml. 'ant clean check' is now good to go (though it uses
the text UI for JUnit, and some developers may want the Swing GUI)
Also, I cleaned up build.xml a bit, including adding all buildfiles
(but not junit.jar and things like that) to the source distribution
('ant src-dist') rather than just build.xml.
