我写故我在

I write, therefore I am

Archive for 2011年8月

SVN 使用笔记

Posted by ieipi 于 八月 31, 2011

1.设置svn:ignore 属性

svn会默认监测目录下的所有文件,这样当使用svn status时会遇到很多冗余信息。实际上,有很多文件,比如二进制文件,日志文件等是不需要加入svn 版本控制的。我们可以利用每个目录均有的svn:ignore属性来实现这一目的。
1)  设置.svnignore文件
在当前目录上新建.svnignore文件(文件名可行任意),并在其中编辑需要忽略的文件类型。例如

build/
dist/
*.class

2)  设置svn:ignore属性

svn propset svn:ignore –F .svnignore .

3)  其他
这种方法是局部设置,只对当前目录生效。还可以进行全局设置,对所有的svn workcopy均有效。

sudo vim /etc/subversion/config

找到global-ignores条目,在其后加上需要忽略的文件类型。

2.版本代码回滚

svn 本版库包含所有的历史信息,所以你可以回滚到任意历史版本。所有的修改可以看作是由一系列的修改及集组成。可以利用svn merge命令将一个或一组修改集应用当前工作拷贝。基本工作流程为:
1)    更新工作拷贝

svn update

2)    定位可疑目标

svn log test_rollback
svn diff –r 100:101 test_rollback

3)    撤销错误修改集

svn merge –r 101:100 test_rollback

4)    检查修改结果

svn diff test_rollback

5)    提交

svn commit –m"revert the wrong change from r101"

6)    其他
当提交更改后,r101的更改集已经从HEAD中删除。但是,r101版本仍然在版本库中。当直接从r101版本checkout时仍会得到错误更改。但是通常我们只对HEAD版本感兴趣,所以从HEAD删除已经足够好了。如果想从版本库中毁掉所有证据,并不容易。

Advertisements

Posted in 工具, 技术 | Tagged: | Leave a Comment »

GSoC 2011 is over

Posted by ieipi 于 八月 31, 2011

Google has announced the final evaluation result and the integration work is underway—my GSoC2011 journey with Jitsi has approached to its final period. Now it’s the right time to reminisce about this unique experience.

I can’t forget the moment when I received the email from Google saying that I had been accepted by Jitsi as a GSoC2011 student. The official announcement time is 19:00 UTC April 25, which is 03:00 here in Beijing. I spent all night waiting for the final moment with butterflies in my stomach. When the announcement came, I was even too excited to fall asleep.

After immersed in the excitement for a week, coding period started.

The project is to implement support for wideband codecs, to be specific, SILK, in Jitsi. So why wideband codecs? Thanks to the advancement of Internet access technology, the available bandwidth has increased a lot, and the major concern of VoIP developers has shifted from using less bandwidth to supporting better quality. Imagine the quality of music rather than speech, that’s cool. And then why SILK? Well, to be honest, Skype has done pretty well in the VoIP industry, and they share their main audio codec, SILK, to the open source community. And we are eager to have it in Jitsi.

The main work is to import SILK from C to Java. Sounds very straightforward, right? It may be easy to start, but you may suffer to make it work well. We’ve decided to translate the C code from scratch rather than using JNI technique. There are some important notes to be taken care of in the translation process.1). Pointers. The C programs use pointers intensively. However, there is no pointer in Java. So you should be careful when encounter pointers. Generally speaking, when the pointer is of complex type, e.g. struct, you can use an object reference in Java to translate it. However, when the pointer points an array, you should use an array reference and a data offset in addition. 2). Callbacks. C supports function pointers, which make callbacks flexible and powerful. Again, no pointers in Java, so you should design carefully based on the interface technique to support callbacks.3). Unsigned data types. There is no unsigned data type in Java, so you should be careful when unsigned data is involved in the operation.4). Shift operations. Java has separated operators for logic shift and arithmetic shift operation. 5). Endianness. Java is big endian, and usually the input data is in the format of little-endian. 6).Float point arithmetic. Subtle problems will arise when float point operation is involved.

The coding work was finished nearly in the mid-term, and then came the test. I should say that test really takes time. The test and debugging can easily take more time than you expect. So I think you should always remember to assign more time than you predict for debugging and test. In the first phase, it was not difficult to clear the bugs and made the program run. Though it gave no error messages, the result was not correct. For example, when I played the music which was encoded/decoded by the codec, the last part of the audio was not clear at all. At first, I tried to find the bugs from top down—debug step by step, and compare the intermediate result with that of the C version. But I found it was really difficult to determine whether they match or not when float point arithmetic operation was involved. Since the float point operation result is not exactly the same in Java as in C, when the intermediate result doesn’t match, it’s difficult to judge whether it’s because of a bug or just because of the float point operation itself. After discussion with my mentor Lyubomir, I decided to use another approach—a down-top approach. Get the intermediate result from C, and hard-coded it into Java to test whether there are bugs in the following parts. By this approach, I finally located the bug. It resides in the re-sampler part, and this explains why only part of encoded/decoded audio is incorrect.

Finally, how to test a codec? I think there are basically two methods. The first is to write a script to compare the result with a reference signal to see whether they match with each other. And the second is by hearing. Let the user test it. You play the audio result which is processed by the encoder and decoder and compare with the original sample audio. If it’s clear enough, I think you can say the codec works correctly.

The 3 months passed quickly, but the memory will last. Thank Google, thank Jitsi, and especially thank my mentor Lyubomir. I hope I can continue to work with the community in the future.

Posted in 随笔 | Tagged: | Leave a Comment »