Any documentation for creating custom modes?

Processing Development
1

I want to write a custom mode for Processing and don’t know where to begin.

I couldn’t find anything on the wiki for Processing that describes how to create a custom mode.

I also tried looking at the source for Debug Mode, because it’s somewhat similar to the project I want to create, but it seems to be out of date with Processing 3.

Can anyone point me to any resources for getting started with writing custom modes?

2 Likes
2

Unfortunately…

A good first strategy is to look at the open source code of the existing modes – for example, Python mode – or R mode (written last year).

Good sources of advice for specific questions might be @fjenett and @gaocegege – and, to a much lesser extent, me.

What will the mode be?

Old info:

4 Likes
3

Hey, thanks for the response. I will look into those repositories to get started.

I’m sure I’ll have specific questions down the road, but probably not for a little while, as I try to get familiar with the basics.

As far as what the mode will be, I’d like to make a sort of debugging tool that allows users to see how their programs execute over time. Where a typical debugger allows you to step forward through your program, one line at a time, this mode would also allow you to scrub backwards in time. And where a typical debugger allows you to see your program at a given instant in time, this mode would allow you to see the flow of time, from one instant to the next, all at once.

I’m not exactly sure to what extent this is achievable with a Processing mode, but I have the sense that with modes you can create some that is more deeply integrated with the PDE than with tools.

4

Processing has a REPL mode which allows you to see live code (sketch changes as code is changed). Maybe that will be a good mode for you to explore. related to debugging, are you aware of the debugging capabilities of P3? It has the features that you mentioned except “to scrub backwards in time”. With respect to the latter, I haven’t seen any debugger doing that. As a matter of fact, one small issue with that approach is that after you leave a scope, your data is marked for gc and I don’t think you are able to step back in your code to restore those references. Mayb you have a novel approach. All ideas are good ideas, or at least, good to discuss. If you want more feedback, you can discuss them further here and different P3 goers will provide feedback if that is what you seek.

Lastly, I believe the Android mode is still looking for tools to perform debugging in the PDE, in case you are interested in exploring different concepts or tools.

Kf

2 Likes
5

W/r/t the question of scrubbing backwards in time, I suppose I was thinking that the state of the program would be recorded manually by the mode itself. So restoring a previous state would mean looking up that information in a data structure maintained by the mode rather than the JRE. Of course, there would be some memory limitations to how much history you could store.

I may have confused the issue by calling it a debugger, because what I had in mind wasn’t to reimplement what Processing’s debug mode already does well.

Anyway, thanks for the feedback — this is good food for thought

1 Like
6

In addition to REPL Mode, you might want to check out Tweak Mode for inspiration.

http://galsasson.com/tweakmode/

What you are describing is an interesting set of problems – there are a lot of limitations to consider even for fairly simple sketches.

One thing that comes to mind – to rewind the behavior of random() and noise(), they would need to be seeded, then returned to the seed and walked all the way forward to a specific step count. Alternately, you would need to copy the underlying random generator at snapshot steps. Maybe there are other ways?

Re: memory – one general approach to memory-limited histories is sparse snapshotting, in which snapshots get more and more sparse as you go further back in time (and / or are culled to stay under a limit once you reach a certain number of snapshots, with older timeframes culled more often).

2 Likes
7

@jeremydouglass Hi Jeremy. Thanks for your mention!

Hi I am the author of Processing.R. When I get started with the development of the mode, I learnt a lot from processing.py. I think if you want to create a new mode, there are some things you should do:

  /** True if heavy debugging error/log messages are enabled */
  // static public boolean DEBUG = false;
  static public boolean DEBUG = true;

  void buildCoreModes() {
    /* Mode javaMode =
      ModeContribution.load(this, Platform.getContentFile("modes/JavaMode"),
                            getDefaultModeIdentifier()).getMode();
    */

    Mode javaMode =
      ModeContribution.load(this, Platform.getContentFile("modes/PythonMode"),
                            getDefaultModeIdentifier()).getMode();

    // PDE X calls getModeList() while it's loading, so coreModes must be set
    coreModes = new Mode[] { javaMode };
  }

  String getDefaultModeIdentifier() {
    // return "processing.mode.java.JavaMode";
    return "jycessing.mode.PythonMode";
  }

You need to update the modeidentifier and javaMode to let the Processing IDE set your mode as default. Then you could build and run it. You will see there is a Processing IDE instance which default mode is your custom mode.

This is just for devops purpose. If you want to release the mode, there are lots of things you need to care about. I do not think you need to worry about it before you finish the first version of your mode.

4 Likes
8

Great! This helps me get started. Thank you very much

9

Do not be so polite. I am glad to help you.

If you have any question about mode development, feel free to @ me.