From: Behdad Esfahbod <[EMAIL PROTECTED]>
On Sat, 3 Apr 2004, ahmad khalifa wrote:
> so u both think that what i did was wrong ? > enlighten me...
Depends on how do you define "wrong". What you did is quite good as a _prototype_, to be replaced by something better later.
i was talking about "personal preference"... because i thought that i couldnt use FriBidi Inside putty's code. so the only options i thought were available were 1. FriBidi as a dynamic lib. 2. own implementation. Simon wouldnt accept number1, so the only thing left was number 2. so there was no "personal preference"...
Unfortunately I cannot access your code right now, as there is no link from the arabeyes PuTTY page, nor from the sf.net page! But lemme give an example: your code has no optimizations and it looks like an O(N^2) implementation. You may say that the lines are short in PuTTY, but IIRC you are keeping the minibidi separate from PuTTY.
its in cvs beside putty http://cvs.arabeyes.org/viewcvs/projects/external/putty
well, you're right about that O(N^2). but as i checked, the reference code and Fribidi are also O(N^2). and besides, in apps other than putty, Bidi should be performed when the buffer changes, which shouldnt take much processing...
i have some optimizations in mind, but first i'll get the issue of the explicit marks...
As another example, I'm not sure you fixed it or not, but you used to only keep bidi types for Arabic block.
i have mentioned before that i wrote 2 very small C programs to make a C header file for (almost) all unicode types in UnicodeData.txt and mirroring.txt (or whatever its name is). so minibidi handles all characters from 0000 to FFFF and applies mirroring to all. the version in cvs only has the RLE table.
and beside that, i have implemented an RLE scheme, so instead of having FFFF+1 type values in memory which is ~65KB, its compressed to ~1KB. this ofcourse needs some optimization that i'll get to later if minibidi becomes significant, i.e if putty accepts it, or its used elsewhere...
Or one really hard to find out technical one: A PDF should pop the *matching* LRE/RLE/LRO/RLO code, not the one on top of the stack. Now go find what does it mean ;). [Hint: the reference impl. does this too, as well as FriBidi]
hard one... i still dont get it. but debugging the refrence code should be helpful.
And you say your implementation is quite compliant to the spec, but I see you can only say it because you have done absolutely no systematic tests. Lemme tell you how we tested FriBidi for compliance: compiled both FriBidi and the reference impl. Then wrote a few small scripts (they are in FriBidi CVS too) to generate absolutely random strings of length 64kb, and feed to both implementations, and compare the output.
wow, do i need to do that ? i'll probably have to establish some GOOD testing mechanism and some scripts. although i'd have to learn some scripting language first... but only if minibidi is to be used by something.
This way could find any of my implementation errors in a matter of seconds, giving a huge counter example, that I used to trim down and find the bug. Then I let the test process to run for 24 hours on my celeron machine, and only when it couldn't find any offending string, I claimed that.
i claimed 100% compliance after i tested minibidi on putty against the refrence code on putty, now i take it back and say 100% compliance with the Implicit algorithm, i.e no explicit handling yet..
Ofcourse we have some static tests too, that you have seen.
> ak.
--behdad
ak.
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
_______________________________________________ Developer mailing list [EMAIL PROTECTED] http://lists.arabeyes.org/mailman/listinfo/developer
