GSoC 2017 proposal - Robust Extension System
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
I manually wrapped the text. So in case the format is corrupted, I upload a plain text version.
On Tue, Mar 21, 2017 at 4:35 PM, Minglangjun Li <liminglangjun@...400...> wrote:
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:
- 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:
- 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)
- Implement a universal expiration time manager for all the extensions
which uses less memory and is easier to maintain. (June 21 - July 20)
Create a test suite for extensions. Build infrastructures like document builder, extension loading, node and attribute lookup, etc.(July 21 - August 20)
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:
- 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.
- 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.
- 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
Hi,
(I am not a inkscape developer, just an extension developer, the following is just my own opinions.)
Probably a lot or all of those ideas would be great additions (some real dev would have to judge) even if I have not had many issues with unstable extensions.
Including some more details in the XML for extensions to work with would be a good thing as well. Like how the current selection is included, it would be nice to get information about the filename of the current drawing (if it has been saved/loaded) and... there was some more things I have thought of would be nice to have for my extensions but I can't remember right now.
What I also would really like to see though (in addition) would be a new way to make extensions that gives them a (python) api to hook directly into Inkscape and modify the drawing. The current system is good for a few things (and for allowing extensions in other languages), but almost everything non-trivial requires using python modules to duplicate functionality that already exists in Inkscape, and it is very easy to miss some detail. For instance something simple as moving an object, that Inkscape can already do in different ways (with or without translating patterns or gradients for instance) becomes rather complex to get right the way extensions are currently made. Essentially the burden of parsing SVG and creating a valid SVG document (including Inkscape specific additions) is all on the extension developer.
Looking at the design of FreeCAD or Blender, both those open source applications have nice friendly python APIs, and built in script consoles. It would be fantastic to see something like that in Inkscape. An extension could have both access to low-level modification of SVG/XML attributes, as well as a higher level API to do things like moving or resizing objects without worrying about transforms etc.
Starting simple with just a few basic functions might be possible to do in a summer, even if it would not be by far a complete API.
https://docs.blender.org/api/blender_python_api_2_77_0/info_overview.html
https://www.freecadweb.org/wiki/Python_scripting_tutorial
I'm sure there has been some serious discussions about that in the past, but I am not sure about if there are any plans or even for some odd reason a decision to not wanting something like that.
On Tue, Mar 21, 2017 at 9:47 AM, Minglangjun Li <liminglangjun@...400...> wrote:
I manually wrapped the text. So in case the format is corrupted, I upload a plain text version.
On Tue, Mar 21, 2017 at 4:35 PM, Minglangjun Li <liminglangjun@...400...> wrote:
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:
- 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:
- 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)
- Implement a universal expiration time manager for all the extensions
which uses less memory and is easier to maintain. (June 21 - July 20)
Create a test suite for extensions. Build infrastructures like document builder, extension loading, node and attribute lookup, etc.(July 21 - August 20)
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:
- 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.
- 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.
- 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
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thanks for your advices, Pelle. I saw something similar with your idea on the Inkscape roadmap but is far ahead. However, I'm OK if the developers think we should start to work on it now. Regards, Minglangjun Li
2017年3月21日 17:57,"Pelle Nilsson" <pellenilsson@...400...>写道:
Hi,
(I am not a inkscape developer, just an extension developer, the following is just my own opinions.)
Probably a lot or all of those ideas would be great additions (some real dev would have to judge) even if I have not had many issues with unstable extensions.
Including some more details in the XML for extensions to work with would be a good thing as well. Like how the current selection is included, it would be nice to get information about the filename of the current drawing (if it has been saved/loaded) and... there was some more things I have thought of would be nice to have for my extensions but I can't remember right now.
What I also would really like to see though (in addition) would be a new way to make extensions that gives them a (python) api to hook directly into Inkscape and modify the drawing. The current system is good for a few things (and for allowing extensions in other languages), but almost everything non-trivial requires using python modules to duplicate functionality that already exists in Inkscape, and it is very easy to miss some detail. For instance something simple as moving an object, that Inkscape can already do in different ways (with or without translating patterns or gradients for instance) becomes rather complex to get right the way extensions are currently made. Essentially the burden of parsing SVG and creating a valid SVG document (including Inkscape specific additions) is all on the extension developer.
Looking at the design of FreeCAD or Blender, both those open source applications have nice friendly python APIs, and built in script consoles. It would be fantastic to see something like that in Inkscape. An extension could have both access to low-level modification of SVG/XML attributes, as well as a higher level API to do things like moving or resizing objects without worrying about transforms etc.
Starting simple with just a few basic functions might be possible to do in a summer, even if it would not be by far a complete API.
https://docs.blender.org/api/blender_python_api_2_77_0/info_overview.html
https://www.freecadweb.org/wiki/Python_scripting_tutorial
I'm sure there has been some serious discussions about that in the past, but I am not sure about if there are any plans or even for some odd reason a decision to not wanting something like that.
On Tue, Mar 21, 2017 at 9:47 AM, Minglangjun Li <liminglangjun@...400...> wrote:
I manually wrapped the text. So in case the format is corrupted, I
upload a
plain text version.
On Tue, Mar 21, 2017 at 4:35 PM, Minglangjun Li <liminglangjun@...400...
wrote:
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:
- 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:
- 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)
- Implement a universal expiration time manager for all the extensions
which uses less memory and is easier to maintain. (June 21 - July 20)
- Create a test suite for extensions. Build infrastructures like
document
builder, extension loading, node and attribute lookup, etc.(July 21 - August 20)
- 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:
- 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.
- 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.
- 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
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-- /Pelle
participants (2)
-
Minglangjun Li
-
Pelle Nilsson