The Big One: Proposal in GSoC 2017 #28
Comments
|
I have updated the progress of the tasks in #28 (comment), maybe we could schedule a date to discuss about the milestone :) |
|
There are some issues with potential risks: #9 and #17 , since easy issues have been solved during community bonding period. I think I should spend more time on those two issues. And before I start to code, maybe we should discuss about the implementation :) Then other issues are under control 🤔 If we have more time, more built-in functions support, setting up test environment and documentation are the potential work to do. I definitely like the idea in #71 . But I am afraid that we could not implement the feature in this GSoC, IMO. It is a little complex. |
|
Great -- I'll email you now about meeting times. My initial thoughts:
I agree that #9 "Add pre-processer into Processing.R" deserves extra time and expert feedback. Making the Processing API accessible in R mode through pre-processing may be critical to whether Processing.R mode is popular / successful. I agree that #71 should not be a high priority -- it would be really interesting to incorporate at the end of the project only if there is time -- see my response there.
|
|
My main feedback right now looking over this plan is that #58 "Support Processing Libraries" should be at least as high priority as #17 "Support packages (libraries) in R". The potential audience for Processing.R is both:
In many modes the demand for loading Processing libraries is as high or higher than demand for native libraries. Many R libraries and Processing libraries won't work without changes -- often because they are not pure native R / Java -- but some do. In my opinion it is more important to the future of Processing.R to have a simple working example of each type of library (ones that can already work unmodified). It would be less important to have a number of popular BioConductor packages all working but no mechanism for loading a Processing library. |
Development Process(Draft 1)Coding Phase 1 (May 30 - June 26)Week 1 (May 30 - June 5)Minimal Documentation about the latest version of Processing.R should be ready. Processing.R is under active development now, but the documentation should be keep update. Week 2 (June 6 - June 12)Fix code styles according to coala and codacy. coala is a command code linting tool, and codacy is a automated code reviewing tool. There are many errors about coding style reported from codacy and coala. It is better to fix them before development since style-fixing would affect the code base, and it will be conflicts if we don't do it. Week 3 (June 13 - June 19)Do the research #61 , if it is feasible, refactor the code to language solution, else support more functions based on Built-in Applet. Week 4 (June 20 - June 26)Similar to Week 3. Coding Phase 2 (June 27 - July 24)Week 5 (June 27 - July 3)The aim in week 5 is to support R libraries in Processing.R. There are some differences between the way Renjin manages packages compared to the way that GNU R manages packages, This can be done in multiple ways, where the clearest way would be to install packages in runtime. If that is not possible, the other way is to install packages ahead of time. Status: TODO #17 Week 6 (July 4 - July 10)In week 6, there are test to be done. The main logic in PApplet, Sketch and other main components should have corresponding unit test cases. Status: TODO with potential risk #10 Status: partially done #29 Week 7 (July 11 - July 17)Week 8 (July 17 - July 24)In week 8, again, a pause for testing and review of code and updating documentation will be a good idea. Besides this, CI for Windows and macOS could be added into the project. AppVeyor is a helpful tool to implement this task. Status: TODO Coding Phase 3 (July 25 - Aug 29)Week 9 (July 25 - July 31)Week 10 (Aug 1 - Aug 7)In week 10, The work about active/mix/static modes is in the plan. The mode is a syntactic sugar, it is designed to make code easier to read or to express. Processing.R has some problems in static mode now, because there is no check in AST level. Finding and evaluating the function calls such as size and others that should be used in initialization of the PApplet before running is a possible solution. Status: TODO Week 11 (Aug 8 - Aug 14)The aim in week 11 is to remove Status: TODO #9 Week 12 (Aug 14 - Aug 20)It is the final week, code reviewing and bug fixing are the main tasks in this week. There are some preparations and cleanups to transfer the ownership to Processing Foundation. Status: TODO Buffer Time (9 days)There are 9 buffer days in case something didn’t go as planned in the weeks before. |
|
We have reached the conclusion of the GSOC 2017 timeline -- the Big Plan (which evolved and grew more ambitious as it went) was a success! Of course, there is still some cleanup left to do -- including closing old issues like this one.... |
Processing.R
Project Abstract
The goal of this project is to offer a new mode in Processing for R Language, which allows users to write Processing sketches in R.
Project Description
Motivation
Now Processing has two language modes: Java and Python. And p5.js ports core concept of Processing on native Javascript. Java, Python and Javascript are among the most popular and widely used programming languages in the world, but these languages have similar audiences.
R is an open source programming language and software environment for statistical computing and graphics. It ranks 15th in TIOBE Index for February 2017. Compared to Java or Python, R is concentrated on statistical computing although it is designed to be general purpose. There's a demand for data visualization and visual art in R. Processing.R is to offer a new mode in Processing for R. It is a good way to expand the user base for Processing and reduce learning curve of Processing for people using R.
Prototype
I have built a prototype for this proposal: Processing.R. It has basic abilities to write R scripts using the functionality of Processing, but it is incomplete. There are some key features to implement. In GSoC 2017, I propose to fix critical bugs and add some important features to make the production ready.
Implementation
Now Processing.R has two ways to use:
The UML class diagram shows main classes in Processing.R.
Runner.jar has two main components: Standalone Sketch and Runner. Standalone Sketch represents the sketchbook. Runner inserts some built-in functions and variables into R global scope; interpret code by renjin, which is a JVM-based interpreter for the R language; and create PApplet to run sketch code.
Processing.R Mode extends Editor and Mode classes to support Processing app. RLangMode has a Sketch Service Manager, it creates a new Sketch Service and Sketch Service runs a Sketch Runner to run specific logic.
Development Process
Community Bonding (May 5 - May 30)
The aim in Community Bonding is to learn about Processing community, dive into the architecture of language modes in Processing, set up a development environment for coding and debugging, and optimize the process of CI for Processing.R.
Now Processing.R builds a jar in CI process. In Community Bonding it is better to build all targets in build.xml.
Coding Phase 1 (May 30 - June 26)
There are 4 weeks in Coding Phase 1 and an evaluation after the phase.
The aim in Coding Phase 1 is to fix critical known bugs and support more built-in functions. There are some bugs in the prototype, one of them is critical.
Besides this, Processing.R only supports a subset of all Processing built-in functions. There are more than 250 functions in Processing and 5 of these functions are supported in Processing.R. In this phase functions about shape, 2D Primitives, environment, curves and vertex should be ready.
Week 1 (May 30 - June 5)
The users could not input new lines in R mode now. The aim in week 1 is to fix the critical bug in Processing.R. Formatter is the possible cause to this bug but it needs to be confirmed with further analyses.
Status: done #8
Week 2 (June 6 - June 12)
The aim in week 2 is to support functions about shape, 2D Primitives and curves. There may be some tricks in the implementation because of the different type systems between Java and R. Processing.R is usable to some use cases after this week.
Status: partially done #16
Week 3 (June 13 - June 19)
The aim in week 3 is to support functions about environment and vertex, similar to week 2.
Status: partially done #16
Week 4 (June 20 - June 26)
In week 4, The goal of this phase has been attained and it’s better to review the code and fix some known bugs in the previous code. And the code should have corresponding documentation. Examples can be added about newly supported built-in functions.
Status: partially done #45 #46 #57 #48
Coding Phase 2 (June 27 - July 24)
There are 4 weeks in Coding Phase 2 and an evaluation after the phase.
The aim in phase 2 is to support some CRAN and BioConductor R libraries, improve code quality according to automated code reviewing tool(codacy), and add unit test cases for Processing.R.
Week 5 (June 27 - July 3)
The aim in week 5 is to support R libraries in Processing.R.
There are some differences between the way Renjin manages packages compared to the way that GNU R manages packages, This can be done in multiple ways, where the clearest way would be to install packages in runtime. If that is not possible, the other way is to install packages ahead of time.
Status: TODO #17
Week 6 (July 4 - July 10)
The aim in week 6 is to improve code quality according to codacy. Maintainability is important to open source projects. Now Processing.R has some problems in code complexity and error-prone, these problems should be solved in this week.
Status: partially done #29
Week 7 (July 11 - July 17)
In week 7, there are test to be done. The main logic in PApplet, Sketch and other main components should have corresponding unit test cases.
Status: TODO with potential risk #10
Week 8 (July 17 - July 24)
In week 8, again, a pause for testing and review of code and updating documentation will be a good idea. Besides this, CI for Windows could be added into the project. AppVeyor is a helpful tool to implement this task.
Status: TODO
Coding Phase 3 (July 25 - Aug 29)
There are 4 weeks in Coding Phase 2 and the final evaluation after the phase.
The aim in this phase is to solve the problem about RLangPApplet, add Mix mode, and remove
processingprefix in built-in function calls.Week 9 (July 25 - July 31)
The aim in week 9 is to solve the problem about RLangPApplet singleton. RLangPApplet is created every time the user clicks
run.Status: done #6
Week 10 (Aug 1 - Aug 7)
In week 10, The work about active/mix/static modes is in the plan. The mode is a syntactic sugar, it is designed to make code easier to read or to express. Processing.R has some problems in static mode now, because there is no check in AST level. Finding and evaluating the function calls such as size and others that should be used in initialization of the PApplet before running is a possible solution.
Status: TODO
Week 11 (Aug 8 - Aug 14)
The aim in week 11 is to remove
processingprefix in built-in function calls. It also is a feature to make Processing.R “sweeter” for human use. The built-in functions now have a prefix “processing”, because there are some functions in R with the same name as in Processing. @GoToLoop gives me a idea to implement a pre-processor, so Processing.R scripts may not be valid R scripts. We have a discussion about the issue.Status: TODO #9
Week 12 (Aug 14 - Aug 20)
It is the final week, code reviewing and bug fixing are the main tasks in this week. There are some preparations and cleanups to transfer the ownership to Processing Foundation.
Status: TODO
Buffer Time (9 days)
There are 9 buffer days in case something didn’t go as planned in the weeks before.
The text was updated successfully, but these errors were encountered: