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