ref https://forum.processing.org/two/discussion/comment/97845/#Comment_97845

And, before implementing new features in Processing, the mode should look (someday, in the future) at how renjin imports Java libraries -- no need to reinvent the wheel of plotting.

The experience of the Processing.py mode with Java-libraries-in-Jython seems to have been this: Some Processing(Java) libraries worked without needing changes. Others required minor changes. Others needed a full separate version of the library or would not work at all.

Now Processing.R packages jacoco into modes, which is used in unit test.

The Processing.py mode has a great tutorial for command line support. In the documentation phase it might be worth adapting that tutorial to show how to work with Processing.R's Runner.jar

• http://py.processing.org/tutorials/command-line/

Processing(Java) has fairly minimal documentation in the wiki about command line mode -- it is mostly available via -help.

• https://github.com/processing/processing/wiki/Command-Line

Still, it uses a menu to install command line integration, which also might be worth looking into someday.

Someday:

Processing.R may wish to integrate its reference (right-click to look up) into the Processing IDE directly through the mode distribution. This is how the PDE supports right-click-to-look-up in Processing(Java).

Processing modes automatically do URL lookups in a mode-specific references folder, e.g.:

~/Documents/Processing/modes/PythonMode/reference
~/Documents/Processing/modes/RLangMode/reference

However, this isn't supported in the current Processing.py -- and I'm not sure if p5.js is using it either. It might be worth asking why before using it:

• https://github.com/jdf/processing.py/issues/235
• https://github.com/jdf/processing.py/issues/228

If Processing.R supports only a subset of Processing and has some exceptions and special rules, then documentation will be important to making it useable. Ideally, this documentation could be added to the mode directly, automatically available via right-click lookup in the PDE, and also used to generate online documentation.

https://www.codacy.com/app/gaocegege/Processing-R/issues

Fix code issues to keep maintainable

Now Travis CI process will clone the processing core and build it.

Actually there is no need to build from source code, just download it as docker image does.

The Processing size() command takes keywords for each renderer. In addition to the default renderer, other renderers are: (from https://processing.org/reference/size_.html )

• P2D (Processing 2D): 2D graphics renderer that makes use of OpenGL-compatible graphics hardware.
• P3D (Processing 3D): 3D graphics renderer that makes use of OpenGL-compatible graphics hardware.
• FX2D (JavaFX 2D): A 2D renderer that uses JavaFX, which may be faster for some applications, but has some compatibility quirks.
• PDF: The PDF renderer draws 2D graphics directly to an Acrobat PDF file.

So, currently the Processing.R example sketch 3d-cube.R:

settings <- function()
{
  processing$size(500, 500, "processing.opengl.PGraphics3D")
}

Would become:

settings <- function()
{
  processing$size(500, 500, P3D)
}

While this issue is unresolved, I would recommend that current and future example sketches have render keywords defined in the header so that settings() more closely mirrors normal Processing code -- using this style:

P3D <- "processing.opengl.PGraphics3D"
settings <- function()
{
  processing$size(500, 500, P3D)
}

Supporting render keywords in Processing.R will make it much easier to translate sketches back and for between Processing(Java) and Processing.R -- especially for new learners.

Renjin supports some of CRAN and BioConductor R libraries, Processing.R could benefit from it.

ref the post in forum

As for libraries, I did a feasibility study. Renjin is used in Processing.R as the backend to interpret R code in JVM. Documentation in renjin.org shows differences about packages between GNU R and renjin.

It supports some of CRAN and BioConductor R libraries and I want to integrate those libraries into Processing.R in GSoC. But I'm not sure whether those packages could be installed in runtime or ahead of time.

BTW I think Jython supports those libraries which do not require C compilation, although I do not have the experience on it.

@jeremydouglass

Now I will file a PR if there is a new feature, and do you think the code should be reviewed from now? 🤔

IMO, I think there is no need to review the easy PRs such as built-in function implementation. But I am not sure how we separate easy and difficult PRs.

Currently Processing.R has three methods of distribution as per https://github.com/gaocegege/Processing.R/blob/master/raw-docs/howto.md

• download a docker container and interact via NoVNC web browser
• download modified PDE as the package at http://gaocegege.com/Processing.R/
• build modified PDE from source

In Processing the normal way to use a new mode is:

1. install the standard Processing IDE (PDE)
2. add the mode using Tools > Add Tool > Modes.

If a mode is not available from Processing, manual mode installation generally works like this:

1. install the standard PDE
2. check out the mode source for its repository
3. type make at the repository root directory.
4. copy dist/MyMode/ directory into the Processing modes directory:
   • MacOSX: ~/Documents/Processing/modes/
   • Windows: %homepath%\Documents\modes\
   • Linux: ~/sketchbook/modes/
5. Reboot PDE

For an example of this, see Ruby mode: https://github.com/tyfkda/processing-ruby-mode

Is there a reason that the manual method of PDE mode distribution would not work for Processing.R?

In Processing the normal way to use a new mode is:

• install the standard Processing IDE (PDE)
• add the mode using Tools > Add Tool > Modes.

In practice, this requires:

• mode.properties
• a public release RLangMode.zip
• RLangMode.txt, containing the URL of RLangMode.zip
• a URL for RLangMode.txt submitted to Processing's http://download.processing.org/contribs

Here it is in more detail:

1. The mode has a mode.properties file -- R.Processing currently builds this with ant, but many modes also keep the file checked in to github, e.g.

   • https://github.com/jdf/processing.py/blob/master/mode/mode.properties
   • https://github.com/processing/processing-android-archive/blob/master/mode.properties

2. The mode also has a release -- a public zipped up copy of the built mode

3. The mode maintainer also has posted publicly a contributions manager configuration .txt file, often called e.g. RLangMode.txt. It contains a listing that includes the URL of the zipped release. The .txt file doesn't have to be part of the mode, but it must be available online. Some modes publish this .txt file via a website, others via github under Releases, for example:

   • http://py.processing.org/PythonMode.txt
   • https://github.com/joelmoniz/REPLmode/releases/download/latest/REPLMode.txt

4. When the mode is ready to include in the PDE Contributions Manager, the mode maintainer (@gaocegege) sends the URL of this .txt file to a Processing core team member (@prisonerjohn).

5. The URL is added to the contrib_generate tool -- the Modes section of sources.conf according to the editing rules in the README.md.

6. This is used to periodically generate an online "[contribution listing]" -- a live listing of all libraries, modes, example sets etc. that are available for download, checked by all PDE installs. See it here: http://download.processing.org/contribs

7. When the PDE application runs, the Contributions Manager checks the latest contribution listing online and downloads it to e.g. ~/Library/Processing/contribs.txt -- see: ContributionListing.java#L44

   static final String LISTING_URL = "http://download.processing.org/contribs";
   static final String LOCAL_FILENAME = "contribs.txt";
   

8. When a user selects a listing in the Contribution Manager, the latest zipped build of the mode is downloaded, unpacked, and installed in the modes directory, where it becomes available via the mode.properties file.

9. When the developer wants to make a new stable release they:

   • increment mode.properties
   • publish a new zipped release
   • update their contribution manager config txt file, RLangMode.txt, with the new zipped release URL
   • next time contrib_generate is run the new mode listing becomes available at http://download.processing.org/contribs and can be automatically downloaded into any PDE installation.

https://www.appveyor.com/

This came up in a discussion on the Renjin listserv: an example of using renjin inside a Processing(Java) sketch, rather than the other way around (using Renjin to power a Processing mode).

• https://gist.github.com/mjkallen/8299891

It isn't directly relevant to Processing.R as a mode -- but someday it might actually be interesting to include an example of that in the Processing.R example set. Install the R mode in PDE, switch to a Java sketch, then import renjin from the R mode. Not the core goal of this project, but potentially of interest -- and it expands the options for community engagement!

Now Processing.R doesn't support output.

related issue #24

Now have 3:

• .ci/init.sh
• .docker/generate-ant-file-in-docker.sh
• scripts/generate-ant-file.sh

ref coala/coala-bears#1750

ref #67 (comment)

coala is a perfect tool to lint and format the code in command line. But it seems that there is something wrong. I will comment the checkstyle bear now and uncomment it until the bug is fixed.

Once there is something to ask them that is a good idea for getting feedback . We may want to request feedback on aspects of the work plan -- and later recruit testers if we can.

ref #16

R does not have float type, but Processing heavily uses float as the built-in functions' parameters. To solve the problem, Processing.R defines a abstract layer called BuiltinApplet, which cast float to double explicitly by function overloading.

Function overloading requires a lot of manual work, so it is better to find a way to finish the job in language level, via renjin.

Maybe we could ask renjin community for help.

Processing.R does not have the concept about sketch, now.

Edit:

1. Tab contents are currently ignored by the R mode compiler -- tabs are NOT concatenated into the sketch. before compiling / running, and treated like one big text file.

2. Creating a new Tab2 in a PDE sketch gives the error: ".r is not a valid extension"
   New tabs are possible if manually named with the extension ".rpde", and new tab contents are saved-loaded correctly when PDE saves and loads. However they are ignored as above.

I tried to run Processing.R in PDE. It is generally feasible but fails to run 3d sketchs:

It causes an error: https://forum.processing.org/two/discussion/1755/java-lang-runtimeexcetion-framebuffer-objects-are-not-supported-by-this-hardware-or-driver

Maybe we should give up docker now.

It may be caused by formatter.

@gaocegege -- There is community of people who have recently developed either:

1. the code that enables modes in PDE
2. a mode for Processing, such as:
   • Processing.py https://github.com/jdf/processing.py @jdf
   • p5.js https://github.com/processing/p5.js @lmccart
   • Android Mode https://github.com/processing/processing-android @codeanticode
   • REPL mode https://github.com/joelmoniz/REPLmode @joelmoniz
   • CoffeeScript mode https://github.com/fjenett/coffeescript-mode-processing @fjenett
   • ...Processing.js / JavaScript mode, JRubyArt, etc.

As part of your GSOC "community bonding" period I would suggest first taking a look at these other mode repos, then reaching out to Processing mode experts, briefly introducing yourself and your project, and perhaps asking if they have any general words of wisdom for developing a new mode. As with #34 with the R community, if anyone from the "modes" community is interested they might also be kind enough to give more detailed feedback on the work plan.

size() does not appear to work with Processing.R static sketches.

Currently the "hello-processing.R" is an example is what Processing calls a static sketch:

A program written as a list of statements (like the previous examples) is called a static sketch. In a static sketch, a series of functions are used to perform tasks or create a single image without any animation or interaction. Interactive programs are drawn as a series of frames, which you can create by adding functions titled setup() and draw() as shown in the code below. -
https://processing.org/tutorials/overview/

Because size() does not work with static sketches, they cannot use 3D (using the P3D OpenGL renderer). For example, here is a static sketch in Processing(Java) showing how box() works:

size(100, 100, P3D);
translate(58, 48, 0); 
rotateY(0.5);
noFill();
box(40, 20, 50);

Here is the equivalent sketch in the current Processing.R without static size():

P3D <- "processing.opengl.PGraphics3D"
settings <- function() {
 processing$size(100, 100, P3D)
}
setup <- function() {
  processing$noLoop()
}
draw <- function() {
  processing$translate(58, 48, 0)
  processing$rotateY(0.5)
  processing$noFill()
  processing$box(40, 20, 50)
}
# based on https://processing.org/reference/box_.html

Supporting size() in Processing.R static sketches will make example code and documentation much more concise -- which will make it easier to read for learners.

There has been a lot of progress on Processing.R since v1.01! It would be nice to wrap up the latest progress in a new release, updating Github Releases and http://gaocegege.com/Processing.R/ .

This release would be a baseline before the official GSOC coding period begins at the end of the month.

Having a recent working release available will also mean that if we resolve #59 then we can invite early alpha testers to install the latest release of "Processing.R alpha" through the PDE Contributions Manager.

Now Processing.R uses print statements to debug, it is naive.

Processing comes with a collection of defined constants. The ones featured in the reference:

• HALF_PI - https://processing.org/reference/HALF_PI.html
• PI https://processing.org/reference/PI.html
• QUARTER_PI https://processing.org/reference/QUARTER_PI.html
• TAU https://processing.org/reference/TAU.html
• TWO_PI https://processing.org/reference/TWO_PI.html

So, for example, the Processing.R example 3d-cube.R sketch begins:

PI <- 3.1415

And this line could be removed with the sketch still running correctly.

Supporting more of these constants in Processing.R will make it much easier to translate sketches back and for between Processing(Java) and Processing.R -- especially for new learners.

• Short-term: Add a fat docker image
• Long-term:Use https://github.com/rancher/dapper or something to reduce the size of image

Now Processing.R supports draw, setting and some other functions but not enough.

ref https://processing.org/reference/

2D Primitives

• arc()
• ellipse()
• line()
• point()
• quad()
• rect()
• triangle()

Curves

• bezier()
• bezierDetail()
• bezierPoint()
• bezierTangent()
• curve()
• curveDetail()
• curvePoint()
• curveTangent()
• curveTightness()

Environments

• delay()
• displayDensity()
• focused
• frameCount
• frameRate()
• frameRate
• fullScreen()
• height
• noSmooth()
• pixelDensity()
• pixelHeight
• pixelWidth
• settings()
• size()
• smooth()
• width

3D Primitives

• box()
• sphere()
• sphereDetail()

Color

Setting

• background()
• clear()
• colorMode()
• fill()
• noFill()
• noStroke()
• stroke()

Creating & Reading

Blocked until #9

• alpha()
• blue()
• brightness()
• color()
• green()
• hue()
• lerpColor()
• red()
• saturation()

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:

1. A jar “Runner.jar” is offered, which allows users to have a try without the installation of Processing app.
2. A mode in Processing app, which is used to write and run code in the IDE.
   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 processing prefix 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 processing prefix 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.

Now the scripts uses time in Shanghai, China.

Now Processing.R has a complete version, it is cool to package processing app with Processing.R as the default mode.

I have the idea to transfer the ownership from me to The Processing Foundation, and this issue will be blocked until Evaluation 2 ends. When it ends, we will talk about it.

Now Processing.R imports the basic test framework (jacoco and junit), and the test coverage output will redirect to codacy.

Could't find renjin in classpath.

<zip destfile="${dist}/mode/${mode.name}.jar" excludes="**/*.MF">
            <zipgroupfileset dir="lib" includes="*.jar" />
        </zip>

The code above works but I need to make sure it doesn't affect linux build.

Now it is full of bugs, some logs in Processing.R will redirect to Processing console, it is confusing to users.

ref https://forum.processing.org/two/discussion/comment/90750/#Comment_90750

As for those conflict function names such as line, we could pre-pass all line calls in R mode to processing.line in Java and r$line to standard line function call in R, because I think R mode users call processing built-in functions more often. And if they need to use same name functions in R standard library, r$something works.

Then processing.r has the same behavior as in Java mode, follow the Law of Least Astonishment to more user-friendly, IMO :)

implement the pre-processor to solve the problem

Now multiple runs will create multiple instances.

Currently, other modes (like p5.js, Processing.py, etc.) package their examples with the mode in an examples subdirectory:

/Users/username/Documents/Processing/modes/p5jsMode/examples
/Users/username/Documents/Processing/modes/PythonMode/examples
etc.

This method of distributing mode examples fits with the general library guidelines:

Examples. Users tend to learn best from examples, therefore examples are important for a library release. It is highly recommended to support your library with various sample programs to demonstrate the use and potential of the library.
https://github.com/processing/processing/wiki/Library-Guidelines

At present, building and installing the Processing.R mode doesn't install the examples -- and creating an examples folder with the files is not enough for them to appear in the PDE "Processing.R Examples" menu of PDE after opening a new Processing.R Sketch. I haven't yet looked into whether this is:

1. a file-type filter problem (.R vs .pde vs. .pyde etc.)
2. a configuration that should be compiled into RLangMode.jar
3. something else

I'm currently able to test all of the example sketches manually -- very nice 3d-cube.R demo, by the way -- but if installing examples with the mode is fixed then it will be extremely easy for testers and community members to grab the latest Processing.R mode/examples from github and try them out in PDE. That should create more and higher quality feedback, help, and documentation.

If this is at all difficult -- e.g. it would require changes to Processing core beyond the scope of the mode -- another potential mechanism for distributing the Processing.R examples is to install them into a separate Example package using a properties file:

• https://github.com/processing/processing/wiki/Examples-Overview

Static mode has a lot of bugs.

All R example code and documentation should largely conform to some consistent R code style guide -- ideally one that already exists, rather than the project developing its own.

Here is one example:

• Google's R Style Guide https://google.github.io/styleguide/Rguide.xml

Future documentation efforts would:

• choose an R style guide
• reference the chosen style guide in the wiki / documentation
• correct issues of style in example code to conform

Example style consistency will be especially useful because some Processing.R users are more likely to be confused by readability issues, and may also be learning R syntax for the first time by way of Processing.