Re: state of BIDI within stable GNU emacs (UTF8) nikud

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