[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BSD license problem of BiCon was non-issue



From: Behdad Esfahbod <behdad at cs dot toronto dot edu>

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