Hi all, I'm a student at Xidian University, of Xi'an, China. This is my first time to apply for GSoC. Since I haven't applied before and don't know how to write a good enough application, I decide to follow the Inkscape SOC application template on the website. I'll try to cover all the points in brief. Also, English is not my mother tongue. Please excuse any errors on my part. I use Inkscape mainly for technical drawings (e.g. flow charts, neural networks structures) and app icons. The most complex two I created are a convolutional neural network and an anime character[1]. I love it for being powerful, easy-to-use and off course, open source. Being a contributor to it would definitely be exciting. I'm browsing the source code recently and have submitted two patches[2,3]. I code in C++ and Python. My favourite programming tools are Vim and Git. Projects I completed include a COOL compiler [4] which is the course project of Stanford compiler course and an Android client [5] for the NHK easy news website. My contributions to other open source projects are: 1. I fixed a bug in the implementation of the Felzenszwalb segmentation algorithm in scikit-image[6]. Old implementation does not update the sizes of merged regions which causes small regions to be merged into only a few large regions. [7] 2. I extended the Python binding of the Dlib library [8] to support discontiguous Numpy arrays. [9] Q: Why should you pick me? A: I use Inkscape and I would like to help it become better. I'm particularly interested in improving the performance of Inkscape which has been complained by many users [10,11] and hope to learn from it as well as sharpen my programming skills. The statements and adjudgements below are according to my current knowledge of Inkscape. If there's any mistake, please let me know. Any advice for improving this proposal will be greatly appreciated. The Proposal ============ Project: Robust Extension System Abstract The extension system is a way to extend Inkscape's functionality. My project aims to improve the performance of the subsystem and make extension development reliable through creating a specific unit test framework. Goals: 1. Check extensions' availabilities in a top-down strategy to avoid unnecessary rechecking in the case of cascading failure. This also makes the dependency check faster. (May 30 - June 20) 2. Implement a universal expiration time manager for all the extensions which uses less memory and is easier to maintain. (June 21 - July 20) 3. Create a test suite for extensions. Build infrastructures like document builder, extension loading, node and attribute lookup, etc.(July 21 - August 20) 4. Other miscellaneous tasks. (If time allows) - Implement an INX builder for internal extensions, making the code more readable and maintainable. - Release an extension if it gets deactivated to save memory. This follows the observation that deactiveated extensions are never activated again. - ... Details: 1. To check extensions' availabilities in a top-down strategy, we should use a data structure like disjoint sets to represent the relationships between extensions. We then assign ranks to extensions in the following way: If an extension has no dependency, we call it a root extension and assign a rank of 0 to it. Otherwise, we set its rank to the maximum rank of all its dependencies plus one. With the help of ranks, we're able to check extensions' availabilities in the order of their ranks. This ensures that an extension's dependencies have been checked before it is checked. 2. Inkscape trunk uses a circular linked list to manage extensions' expiration times. It is not well designed and do bad things (calling 'delete this' in the member). We can improve this by introduce a universal expiration time manager. The expiration time of each extension is inserted into a min heap (or priority queue) on load. When the manager timeouts, it removes all the time that have expired and unloads those extensions. This is similar to how Nginx manages its event timers. Unlike Nginx, we set the timeout of the timer according to the minimal expiration time instead of a constant interval and update it once the queue is updated. 3. Testing an extension is straightforward. We read or elaborate some documents, load the extension and test it against those documents. For most of the input/output extensions, we can do nothing but check if they finish without error and assume that third-party libraries do what they are supposed to do. For effect extensions, we apply them to the documents and examine if the objects are corretly modified in the returned document. Some helper functions should make writing test cases easier. I noticed that there're some bare-bone tests located in the test subdirectory of the extensions folder. Testing Python extensions separately using unittest is a good idea, but what about extensions written in other languages? This needs further consideration. [1] https://drive.google.com/open?id=0B1hNZ1rY1_c4RUJ5b3N5Z0gtODA [2] https://code.launchpad.net/~mljli/inkscape/fix-1670688 [3] https://code.launchpad.net/~mljli/inkscape/cmake_arch [4] https://github.com/mljli/compilers-004 [5] http://nekotachi.github.io/easynews [6] https://github.com/scikit-image/scikit-image [7] https://github.com/scikit-image/scikit-image/pull/2164 [8] http://dlib.net/ [9] https://github.com/davisking/dlib/pull/155 [10] https://bugs.launchpad.net/inkscape/+bug/1198317 [11] https://bugs.launchpad.net/inkscape/+bug/367779 Regard, Minglangjun Li