Processing - C mode

dekevin

Hello everyone, what do you think about a C mode for Processing or a C wrapper for some functions of Processing?

I just recently discovered Python mode for Processing and found it to be a huge motivator for finally learning Python. There is an R-mode and the P5.js mode as well. All these try to support Processing with their native languages (instead of trying to transpile it, like Processingjs does, which is useful in a different way).

Instead of re-implementing Processing for say D, Mathematica, Haskell, Haxe or Rust, a lot of this work could be simplified by writing a C-mode first. Then one would only need to create a thin wrapper for these C functions. Edit: This idea might come closest to the Coffescript mode for Processing, where Processingjs made it very easy to add a new Coffeescript mode to Processing.

Since C is quite low-level it might not support some features from Java, which would break the C-mode. For example classes behave a lot differently, than C structs. However I don't really see any big flaws, since most functions don't require very Java specific features such as polymorphism or interfaces (am I mistaken?) One might need to cut some corners and define enums as integers or structs to make bindings easy to include into other languages though.

The higher level constructs could then be used by each language in their respective ways. D handles arrays a lot differently than Haskell for example.

The one downside I see with this approach beside the limitations of C: Processing itself is basically a Java wrapper around OpenGL and some other libraries for sound, etc., which would basically make a C-mode a wrapper around OpenGL. This might seem to make the C-wrapper a bit redundant. On the other hand I would love to use Processing syntax when programming C, instead of using OpenGL or Vulkan. It would be especially nice if one could switch the modes with a single command.

What are your thoughts on this? Do you think it would be feasible and useful? Are there any major points I missed, which would make writing a C-mode impossible or redundant?

dekevin

Perhaps I should add that this could not be done by simply using Openframeworks or Cider, since almost no language supports wrapping C++ functions, but a lot of languages support wrapping C.

dekevin

Also the Python mode used http://www.jython.org (which basically allowed directly wrapping to Processing, which is my goal in the first place, but not that many languages support binding from Java. Perhaps one should first focus on porting Processing to languages which support binding Java). P5.js (and the R-mode) on the other hand implemented the Processing core again, if I'm not mistaken.

A language which allows direct wrapping to say Java would be a lot more ideal in my opinion, since then you wouldn't need to update the core for all different modes.

This leads to me asking another question: Would it be better to write the Processing core in C or to use JNI to access the Processing code (would this even be possible?)

jeremydouglass

Hi dekevin --

Very interesting! Thank you for sharing these thoughts.

1. Who would your user audience be for something like that?
2. Are you already familiar with C++ systems like OpenFrameworks?

Processing.R actually uses renjin -- just like Processing.py uses Jython. In both cases you are writing a subset of the language (R, Python) that is running in emulation on JVM -- this makes access to a full and up-to-date Processing(Java) and its API relatively easy.

I'm not sure if Renjin's gcc-bridge project is stalled

• https://github.com/bedatadriven/gcc-bridge-example

...but it might be one example of C-on-JVM.... -- although there may be structural reasons why this is hard, and thus not already widely available

nabr

http://malinsky.eu/blog/how-to-call-a-c-function-from-java/

dekevin

Audience: The idea was, that after such a C mode has been made, everybody can then integrate these C bindings into their own language (with the danger of making Processing the monopoly of creative coding libraries :-) ) Having a C-mode would also automatically allow a C, C++ & Objective-C mode (but then again, there already is Cider & OpenFrameworks for this purpose. This would also not allow an iOS mode, since this is still based on the JVM).

I have coded a lot with OpenFrameworks, but don't know much about Cider. Anyways implementing C++ functions into another language is really hard (beside maybe Objective-C++, even D doesn't support this), so they can't really contribute in the same way.

Rewriting Processing (the way P5.js did) is probably out of question (yet another branch to maintain), but would be a faster solution.

On the other hand binding to Java (what nabr linked) seems more feasible (much less work, since you only need to call the Processing core functions).

The only thing I worry about is whether this glue (Java -> C -> other language) would have too much of an overhead. Does anyone know? This should probably be the first thing to test out.

jeremydouglass

I don't know about the overhead -- but it does seem like a good thing to check out! This sounds like an exciting project!

nabr

Yes if you bypass JOGL to C to OpenGL bindings https://wiki.jogamp.org/ it should reduce the overhead. :)

CalxDesign

I would LOVE to see this happen. C, (not C++) or Rust would be ideal.

prince_polka

I am working on it but haven't gotten very far
https://github.com/Prince-Polka/processing.c/

kfrajer

@prince_polka Good for you! :-bd Do you mind commenting in your approach a bit? I am interested to hear about it.

Kf

nabr

★·.·´¯·.·★ ᴛᴇʀʀɪғɪᴄ ★·.·´¯·.·★

i need some music to celebrate.
https://soundcloud.com/robertskmiles/bitshift-variations-in-c-minor

prince_polka

@krafjer
My goal is not to make a c mode for the pde.
Actually I don't even intend to make a straight up port of processing,
just a lightweight c framework for drawing fragment shaders inspired by processing.
Although the code on my github uses a glfw bouilerplate I'm considering using just windows.h as I don't wan't any dependecies.
I don't hate mac or linux, but I do hate installing libraries.

jeremydouglass

That sounds really interesting, but a Windows-only framework for fragment shaders would definitely not be "Processing.c" -- it might be better to avoid confusion by renaming your project so that people will understand what it actually is....

prince_polka

@jeremydouglass I think I'll call it "Hello Fragment Shader" for now

Bundled with the TCC compiler https://github.com/Prince-Polka/Hello-Fragment-Shader/blob/master/HFS.zip

It's not useable for any projects yet, only implemented window creation with shader, draw() loop, setting pixels

gaocegege

Hi @dekevin

I love this idea although I am not sure the overhead and compatibility problem of JNI. And we need to make sure that people will use Processing.C, instead of OF or other C-based creative coding tools.