Eli Zaretskii wrote:
...
Turns out that function "bidi_dump_cached_states" in bidi.c prints to
stderr, but stdio is only included #ifdef TEST_STANDALONE. Since the
function doesn't seem to be used, I just #if 0'ed it out and "make
bootstrap" succeeded.
I'd prefer a cleaner solution, one that doesn't disable the standalone
configuration. How about if stdio was included unconditionally? it
cannot hurt, I think.
Probably wouldn't hurt, I guess. Link-wise, it would presumable not
lead to code bloat, right? (I'm a little rusty on this kind of stuff -
it's been 5+ years since I did serious systems-level programming.) If
it would use the same object code used elsewhere in emacs, why not do it?
Also, if you can, please post context diffs of the changes you
suggest, as that makes fixing the problems in the CVS much easier.
Will do, if and when I have something useful. The #if 0 was really just
to see if it would compile. Long-term something cleaner would
definitely be better. (I suppose I also have to sign some kind of
papers. Probably not a problem with my employer, but the timing is a
bit delicate at the moment. I'm not sure that "Hey, I want to work on
free software!" is the right thing to say at the moment. ;)
Regarding TEST_STANDALONE, I don't see any make targets or anything
obvious for doing that. Do you have any tools/test stuff remaining for
this?
Yes, I do: that's how I tested and debugged the code outside Emacs.
But I don't see any need to make it part of Emacs, since that testing
is already done, and the code passes it with flying colors. Now it
needs to be tested inside Emacs, which is a different environment,
since, e.g., the display engine not always renders complete paragraphs
or even complete lines, and the UAX#9 algorithm depends heavily on
notions such as ``paragraph direction'' and ``first strong
character''.
Hmm. I wonder if we couldn't come up with stand-alone test stuff that
would establish the capability of the code w/r/t emacs processing first,
and then do in-context emacs testing. Speculative question.
What would you think about moving your TEST_STANDALONE code out of
bidi.c and in to a separate driver program?
What for? It doesn't hurt anything to have the test code there, and
keeping them together makes sure the testing code will not be lost.
Just for the sake of clarity and hygiene. In general, if I'm reading a
chunk of code, I'd rather not be distracted by code that really should
be in a distinct test harness. Plus, would your bidi code not be of use
to anybody outside of emacs? Looks to me like it might be a useful
alternative model to other bidi implemenations. If so, would it make
sense to make it available as a stand-alone library?
Also, would it make sense to use a logging framework like Log4c
(http://log4c.sourceforge.net/) instead of simulate_display?
It's just a simple test driver, I don't see any justification for
sophisticated logging. All I needed to see is whether reordering does
what UAX#9 mandates, that's all.
Well, the nice thing about frameworks like log4c (or xUnit frameworks
like CUnit or Check, for that matter) is that they pretty much hide all
the complexity.
I've never tried to test an implementation against UAX9, myself. But
Unicode bidi stuff is pretty complicated - after all, here we are 10+
years into it, and *still* it has not stabilized (revisions are now
pending). After all, we're talking about 61 levels of embedding,
multiple directionality classes, etc. etc. I don't have the slightest
idea how one could verify all that crapola.
You mentioned that the implementation "passes with flying colors". Let
me play the devil's advocate: prove it. How can I be certain that your
test cases had sufficient coverage? You have to publish the test stuff
with the implementation, IMHO. For that I think one needs sth like log4c
or CUnit. Plus, if you use the embedded TEST_STANDALONE framework, how
do we know we can trust the framework itself to be bug-free?
As for testing the implementation in emacs, that's gonna be pretty
tough. There's a lot of complexity in there, there. E.g., how will it
work with elisp programs? What if somebody mucks about with the various
tables that touch on characers? Wants to use an obscure encoding?
Etc., etc. I would think that test/log frameworks would be of immense
help in that sort of testing.
I'm also looking at unit test framework that I think might be useful:
CUnit (http://cunit.sourceforge.net/index.html), which is a GPL'ed
JUnit-like framework for C.
Emacs doesn't currently have any test suite (mainly because the main
purpose of an editor is to display the buffers, and detecting display
bugs automatically is not easy). So something as elaborate as CUnit
would be a waste of time if we do that for bidi code alone.
Hmmm. Seems to me we should be able to automate even display logic
testing. As I hinted above, it looks to me like test/log frameworks
should actually reduce complexity. I'm not so sure of that, but I'll
leave off until I've had a chance to mess around with it myself.
thx,
gregg
_______________________________________________
emacs-bidi mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-bidi
