Enhancement request: Import of "Processing" code

[codemanyak]

I obtained an enhancement request via e-mail:

Meine Anregung zielt dahin, auch den Import von Code der Programmiersprache Processing zu ermöglichen. Processing ist eine auf Java basierende Sprache (bzw.C, C++ ähnlich), die auch gerne für Ausbildungszwecke benutzt wird. Sie ist nicht so sperrig wie das reine Java mit komplexen IDEs wieEclipse oder ähnlich. (Es sei denn man nimmt BlueJ : https://www.bluej.org ) Processing ist beliebt bei Künstlern und Designern und insbesondere auch (in der Lehre) weil Processing interpretativ ist. Und: Processing hat auch einen PYTHON-Modus ! Structorizer ist ja meiner Meinung nach ein tolles Tool, weil es nicht nur TEX erzeugen kann, sondern auch als Konversionstool von Code nach anderem Code benutzt werden kann. .-) Ich benutze zur Zeit Structorizer, um Code-Teile von Processing in Struktogramme und in TEX umzuwandeln. Mit einem Trick kann man Teile von Processing importieren. Ist aber noch etwas mühselig. Ich glaube aber, dass der Import von Processing Code (relativ einfach ?) zu bewerkstelligen wäre…

I obtained some code examples. Several constructs like Java array initializations had to be converted to C syntax, then an import worked surprisingly well, it seems. The advantage of Processing for a code import (in comparison to Java) seems to be that it is not strictly OOP, but rather used in a more "procedural" style.

[codemanyak]

We received an enthusiastic reaction from the instigator of this enhancement:

Da bin ich ja platt: Das ist ja eine tolle Überraschung !!! TOLL! Funktioniert fantastisch ….

[hkiel]

Importing Processing code works fine for single-file projects. However, users usually put classes in their own .pde files, so that you have severals .pde files in one directory. The main *.pde file is the one that has the same name as the directory that it is in.

Can you modify your importer to also load all other *.pde files in the directory? Maybe only if you open the PDE with the same name as the containing directory? I can imagine some use that you only want to open one specific file, so maybe you should ask before opening the other files...

[codemanyak]

@hkiel Thanks for your suggestion. To follow it, however, would mean to put something Processing-specific to a rather general interface. Also think of the batch import from the command line. Technically, it would certainly be feasible, but may I ask first what the specific aim of importing an entire project as a whole is? Usually import is about clarifying, presenting, and documenting the algorithmic structure of certain routines. Do you really need all these diagrams at once within Structorizer? Wouldn't it be sufficient to import the files of a project one by one? It is rather unlikely that the imported code "runs" in Structorizer's Executor, anyway (as all the Processing infrastructure is missing, and the imported diagrams are only a flattened pragmatic approximation of the OOP nature of the classes).

[hkiel]

I was thinking of translating code from one language to another, or even developing the whole program in structorizer (for educational purposes only!) Also, if you import a new pde file, it includes all the constants from Processing (PI, FX2D, ...) which I would need remove again. Most of them are not required by most sketches (add only the necessary ones?)

[codemanyak]

@hkiel

I was thinking of translating code from one language to another, or even developing the whole program in structorizer (for educational purposes only!)

Great. But Structorizer would not actually draw anything by means of Processing-typical instructions. The creation of objects via new may work in some cases but causes warnings, too. You might simply ignore the warning or temporarily define a constant null (which will have to be removed on/after export, of course). But well, it should not be utterly complex to add some extra checks in Structorizer to let null pass - if you insist. I will just have to ponder possible side effects.

Also, if you import a new pde file, it includes all the constants from Processing (PI, FX2D, ...) which I would need remove again. Most of them are not required by most sketches (add only the necessary ones?)

Why would you have to remove them? They are placed in a separate Includable diagram and don't cause harm. That was my consideration when I decided against the questionable efforts of scanning the entire file / diagrams for references to some of them. In Processing, they are always all defined as well, whether needed or not. If you want to develop a whole Processing program in Structorizer you might even benefit from such a rather complete definition diagram emerged from an arbitrary import.

[hkiel]

But well, it should not be utterly complex to add some extra checks in Structorizer to let null pass - if you insist.

That was just a suggestion.

Why would you have to remove them? They are placed in a separate Includable diagram and don't cause harm. That was my consideration when I decided against the questionable efforts of scanning the entire file / diagrams for references to some of them. In Processing, they are always all defined as well, whether needed or not. If you want to develop a whole Processing program in Structorizer you might even benefit from such a rather complete definition diagram emerged from an arbitrary import.

Good point. Of course the list of elements is far from being complete. The only thing I find inelegant is that these extra definitions are mixed with all global variables from the PDE. Maybe you can create two diagrams (one for implicit variables from Processing, one for global variables from program)?

[codemanyak]

The only thing I find inelegant is that these extra definitions are mixed with all global variables from the PDE. Maybe you can create two diagrams (one for implicit variables from Processing, one for global variables from program)?

Will be fixed with version 3.31-03.