[sip-comm-dev] [gsoc-wideband codec]work log 2


#1

Hi,

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. 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
tested them.

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.

Maybe my next work log would be posted 2 weeks later, for I'll take my main
subjects' damn exams next week.

Question:
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?

Regards,
Jing


#2

Hi Jing,

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
tested them.

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.

Question:
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
here.

Regards,
Lubomir

···

2010/5/19 Dai Jing <daijing09@gmail.com>:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Is it because of gabbage collection of Java that people don't need to care about that?

--- 10年5月19日,周三, Dai Jing <daijing09@gmail.com> 写道:

···

发件人: Dai Jing <daijing09@gmail.com>
主题: [sip-comm-dev] [gsoc-wideband codec]work log 2
收件人: dev@sip-communicator.dev.java.net
日期: 2010年5月19日,周三,下午10:10

Hi,

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. 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 tested them.

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.

Maybe my next work log would be posted 2 weeks later, for I'll take my main subjects' damn exams next week.

Question:
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?

Regards,
Jing


#4

Hi Lubo,

Thanks again for patience.

I read your explanations for 3 times and go back to read your earlier reply
agian. I hope I don't make it wrong this time.

Hi Jing,

> 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
> tested them.

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

In fact, I am now doing the translation of CELT(version0.7.1) library
downloaded from this site, I'm sorry I didn't describe it clearly enough.
The coding work I've done is direct translation (only deleted some
#if...#endif code at the purpose of cross-platform in my opinion). In fact,
3 of 14 API functions of CELT is only related to struct CELTMode and has
nothing to do with CELTEncoder/CELTDecoder, so I translated it first.

(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.

I think I have understood what JavaEncoder/JavaDecoder is used for after
your explanation last time. I just want to do the translation work first.

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.

Probably I have made some mistakes about the *automatical* translation.

Since I am not very familar with shell script, I'll choose "(1) documenting
the approach in discreet steps". Maybe I should discuss with you and Jean
before translating the C files, global variables and functions into Java
classes and static fields and methods? I care about the readability of my
translation and of course hope it can be reproduced. So tell me more about
this. I'll really appreciate it.

···

2010/5/19 Lubomir Marinov <lubo@sip-communicator.org>

2010/5/19 Dai Jing <daijing09@gmail.com>:

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.

> Question:
> 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
here.

Regards,
Lubomir

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Jing,

In fact, I am now doing the translation of CELT(version0.7.1) library
downloaded from this site, I'm sorry I didn't describe it clearly enough.
The coding work I've done is direct translation (only deleted some
#if...#endif code at the purpose of cross-platform in my opinion). In fact,
3 of 14 API functions of CELT is only related to struct CELTMode and has
nothing to do with CELTEncoder/CELTDecoder, so I translated it first.

Cool, I'm glad we're on the same page.

I just want to do the translation work first.

Totally, I believe we also see the JMF integration at a later stage of
the development.

Maybe I should discuss with you and Jean before
translating the C files, global variables and functions into Java classes
and static fields and methods?

Absolutely, it was the theme of my previous e-mail - have the
discussion with us first so that we can weigh in and only code
afterwards. As Emil suggested, we should probably also get together
via chat for quick discussions - we could summarize them for the
mailing list afterwords if we feel there's a need.

I care about the readability of my
translation and of course hope it can be reproduced. So tell me more about
this. I'll really appreciate it.

Well, it's nothing fancy really. I don't expect you to be doing
radically different things for each and every file that you translate
- at the end of the day, a single library likely follows conventions
not only for code formatting but also in its design and implementation
- so after looking at it and maybe translating a couple of files, you
could try and create generic rules which you follow. For example and I
really mean it as a general example, you could say:

Whenever there are .h and .c files with the same name, I represent
them as a .java file by concatenating the code from the .h file with
the content of the .c file. The name of the resulting .java file is
derived by capitalizing the name of the respective .c/.h file by
making the first letter and the letter after a - or _ capital.
Respectively, the public class defined inside it uses the same name
and the concatenated content of the .h and .c files becomes static
members of that class.

I think that having such rules allows one to handle a good deal of the
translation in a "mechanical" (thanks to Emil for finding a better
term for what I had in mind!) and incremental way i.e. without opening
a single file and trying to translate it 100% in one go constantly
thinking about the various details that have to be taken care of.
Moreover, when we get to reproduce the translation, what one may feel
to be easily done manually, another may find it easier to do it with
the help of another program.

Regards,
Lubomir

···

2010/5/19 Dai Jing <daijing09@gmail.com>:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Modes.java. Here are some doubts I have during translation.
(1) In .c and .h, there are some constants, and a struct type CELTMode. What
I did is, put all the constants in class Modes_Constants as final fields,
and extend Modes_Constants to Modes. Class Modes is composed like:
fields: the members of struct CELTMode; methods: all the functions in
modes.c
Does this meet the general example you gave above?
(2) Data types. e.g. there is no unsigned int type in java. Besides, the
author of CELT defines a lot of types for different compilers of different
platforms. But as I see, the float precision is not likely to be higher than
IEEE754 standard which java uses, and the integer types of java is qualified
enough in most of the situations. So, maybe I can deal with these problems
when testing?
(3) Pointers. Most of the time, array as an substitution is OK. However,
some are tricky. e.g.
-1- A function call:
        mode->eBands = compute_ebands(Fs, frame_size, mode->nbShortMdcts, *
&mode->nbEBands*);
     which not only returns an int value to eBands, but also changes the
value of nbEBands.
     Without pointer, I have to write like:
        int[] trans = {mode[0].nbEBands}; // a temporary transition
        mode[0].eBands = compute_ebands(Fs, frame_size,
mode[0].nbShortMdcts, trans);
        mode[0].nbEBands = trans[0];
     I feel it is a little stupid...
-2- The memory release dirty work I mentioned before. There is a
function celt_mode_destroy(CELTMode
*mode) used to free the pointer *mode. What I did is just ignoring. I didn't
translate it.

···

2010/5/20 Lubomir Marinov <lubo@sip-communicator.org>

Whenever there are .h and .c files with the same name, I represent
them as a .java file by concatenating the code from the .h file with
the content of the .c file. The name of the resulting .java file is
derived by capitalizing the name of the respective .c/.h file by
making the first letter and the letter after a - or _ capital.
Respectively, the public class defined inside it uses the same name
and the concatenated content of the .h and .c files becomes static
members of that class.

I want to take modes.c and modes.h as an example, which I translated into

---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Jing,

Just a quick thoughts about the pointer problem you mentioned. In this
case, as you explained, it is caused by having to pass a variable by
reference instead of value, so that the C function can modify it.

I might be mistaken but, since you said that all the members of the C
structure you translated have landed in the java class itself, and
since this C function has become a java method, wouldn't it be
possible to access the field in the class and modify the value ?
saving one argument from the call at the same time ?

As far as I can see, this function is only used within modes.c so you
should be fine.

These were my thoughts, hope it helps
jean

PS: don't do it using the temporary transition, it looks horrible !

···

On Thu, May 20, 2010 at 1:25 PM, Dai Jing <daijing09@gmail.com> wrote:

2010/5/20 Lubomir Marinov <lubo@sip-communicator.org>

Whenever there are .h and .c files with the same name, I represent
them as a .java file by concatenating the code from the .h file with
the content of the .c file. The name of the resulting .java file is
derived by capitalizing the name of the respective .c/.h file by
making the first letter and the letter after a - or _ capital.
Respectively, the public class defined inside it uses the same name
and the concatenated content of the .h and .c files becomes static
members of that class.

I want to take modes.c and modes.h as an example, which I translated into
Modes.java. Here are some doubts I have during translation.
(1) In .c and .h, there are some constants, and a struct type CELTMode. What
I did is, put all the constants in class Modes_Constants as final fields,
and extend Modes_Constants to Modes. Class Modes is composed like:
fields: the members of struct CELTMode; methods: all the functions in
modes.c
Does this meet the general example you gave above?
(2) Data types. e.g. there is no unsigned int type in java. Besides, the
author of CELT defines a lot of types for different compilers of different
platforms. But as I see, the float precision is not likely to be higher than
IEEE754 standard which java uses, and the integer types of java is qualified
enough in most of the situations. So, maybe I can deal with these problems
when testing?
(3) Pointers. Most of the time, array as an substitution is OK. However,
some are tricky. e.g.
-1- A function call:
mode->eBands = compute_ebands(Fs, frame_size, mode->nbShortMdcts,
&mode->nbEBands);
which not only returns an int value to eBands, but also changes the
value of nbEBands.
Without pointer, I have to write like:
int[] trans = {mode[0].nbEBands}; // a temporary transition
mode[0].eBands = compute_ebands(Fs, frame_size,
mode[0].nbShortMdcts, trans);
mode[0].nbEBands = trans[0];
I feel it is a little stupid...
-2- The memory release dirty work I mentioned before. There is a function
celt_mode_destroy(CELTMode *mode) used to free the pointer *mode. What I did
is just ignoring. I didn't translate it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Thanks for reminding. I see, this.xx would work well.

···

2010/5/20 Jean Lorchat <jean.lorchat@gmail.com>

Hi Jing,

Just a quick thoughts about the pointer problem you mentioned. In this
case, as you explained, it is caused by having to pass a variable by
reference instead of value, so that the C function can modify it.

I might be mistaken but, since you said that all the members of the C
structure you translated have landed in the java class itself, and
since this C function has become a java method, wouldn't it be
possible to access the field in the class and modify the value ?
saving one argument from the call at the same time ?

As far as I can see, this function is only used within modes.c so you
should be fine.

These were my thoughts, hope it helps
jean

PS: don't do it using the temporary transition, it looks horrible !

On Thu, May 20, 2010 at 1:25 PM, Dai Jing <daijing09@gmail.com> wrote:
>
>
> 2010/5/20 Lubomir Marinov <lubo@sip-communicator.org>
>>
>>
>> Whenever there are .h and .c files with the same name, I represent
>> them as a .java file by concatenating the code from the .h file with
>> the content of the .c file. The name of the resulting .java file is
>> derived by capitalizing the name of the respective .c/.h file by
>> making the first letter and the letter after a - or _ capital.
>> Respectively, the public class defined inside it uses the same name
>> and the concatenated content of the .h and .c files becomes static
>> members of that class.
>>
> I want to take modes.c and modes.h as an example, which I translated into
> Modes.java. Here are some doubts I have during translation.
> (1) In .c and .h, there are some constants, and a struct type CELTMode.
What
> I did is, put all the constants in class Modes_Constants as final fields,
> and extend Modes_Constants to Modes. Class Modes is composed like:
> fields: the members of struct CELTMode; methods: all the functions in
> modes.c
> Does this meet the general example you gave above?
> (2) Data types. e.g. there is no unsigned int type in java. Besides, the
> author of CELT defines a lot of types for different compilers of
different
> platforms. But as I see, the float precision is not likely to be higher
than
> IEEE754 standard which java uses, and the integer types of java is
qualified
> enough in most of the situations. So, maybe I can deal with these
problems
> when testing?
> (3) Pointers. Most of the time, array as an substitution is OK. However,
> some are tricky. e.g.
> -1- A function call:
> mode->eBands = compute_ebands(Fs, frame_size, mode->nbShortMdcts,
> &mode->nbEBands);
> which not only returns an int value to eBands, but also changes the
> value of nbEBands.
> Without pointer, I have to write like:
> int[] trans = {mode[0].nbEBands}; // a temporary transition
> mode[0].eBands = compute_ebands(Fs, frame_size,
> mode[0].nbShortMdcts, trans);
> mode[0].nbEBands = trans[0];
> I feel it is a little stupid...
> -2- The memory release dirty work I mentioned before. There is a
function
> celt_mode_destroy(CELTMode *mode) used to free the pointer *mode. What I
did
> is just ignoring. I didn't translate it.
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net