I have finished the java
coding work of class CELTMode (one of the three interface classes to
JavaEncoder and JavaDecoder, the other two are CELTEncoder and CELTDecoder
in my plan), as well as some of the MDCT related functions. But I haven't
I believe I and Jean agreed in our last conversation with you here on
the dev mailing list on an approach to integrating a native codec
library into SIP Communicator without the use of JNI. What we at SIP
Communicator want is (1) a direct translation of the CELT codec
library at http://www.celt-codec.org to Java and (2) JavaEncoder and
JavaDecoder implementations which directly use the CELT codec library
API. I and Jean gave you an overview of the way to achieve (1). (2)
means that JavaEncoder and JavaDecoder should be implemented in such a
way that they should look nearly identical regardless of whether
you're implementing them using the CELT codec library through a JNI
wrapper or you're doing it using our Java translation.
The first step of the translation approach is coming up with a
procedure to automatically translate as much of the CELT codec library
C source code into Java. We have to know the specifics of the approach
because, as I said in my e-mail, we'll want to reproduce it. That
leaves you the choice between (1) documenting the approach in discreet
steps so that we can go through it and repeat it and (2) implementing
it in a program (e.g. a shell script). Whatever you choose, you have
to keep in mind that the approach will be iteratively discussed here
on the dev mailing list so that we can together shape it up.
This week, after solving some environment problems (thanks a lot to my
patient mentors, Lubo and Jean), I have begun my coding work. I tested
CELT's c code using CDT of eclipse (work well)，and did some single-step
debugging to be more clear with the algorithm.
While I don't personally mind you taking the time to delve into as
many CELT specifics as you like, we have to be clear that our goal is
integrating the CELT codec library into SIP Communicator, not
developing and maintaining a new CELT codec implementation. Which
means that unless you've already come up and realized an approach to
automatically translate as much of the CELT codec library as possible,
I don't expect you to be writing code and debugging it.
In my next work log, I'll draw a class architecture figure. I can't do it
now because some details still not clear enough.
I don't do figures. Unless it's for you own consumption (e.g. to make
you more productive) or it depicts a question that I have to answer, I
don't require it and I'm unlikely to use or comment on it.
Maybe my next work log would be posted 2 weeks later, for I'll take my main
subjects' damn exams next week.
We at SIP Communicator wish you success!
Once you're ready to focus on us again, I expect to hear from you here
on the dev mailing list so that we know how you're moving according to
the translation approach that I described in my previous e-mail and
that Jean agreed with.
In c, a struct type variable is frequently defined as a pointer, and we have
to write a memory-release function (i.e. DestroyCELTMode); In c++,
destructors usually also need to be written. In java we don't have to do
this dirty work?
The short answer is that you don't have to be as explicit as in C/C++.
Which doesn't mean that you cannot have memory leaks in Java so if
you're in doubt in a specific case, please show the code and ask us
2010/5/19 Dai Jing <email@example.com>:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com