Skip to content

Processing 4 reaches "auto naming limit", suggests going for a walk #582

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
processing-bot opened this issue Oct 24, 2022 · 4 comments
Closed
Labels
has attachment Attachment was not transfered from GitLab

Comments

@processing-bot
Copy link
Collaborator

In GitLab by @rric on Oct 24, 2022, 20:50

A student of mine struggeled with Processing 4 today, and ran into the following behaviour. I was able to reproduce it:

Steps to Reproduce

  • start Processing, close it, re-start it again; repeat several times

or,

  • start Processing, and create a number1 of new sketches

Then, at some point, the following dialog pops up:

Time for a Break: You've reached the limit for auto naming of new sketches for the day. How about going for a walk instead?

When trying to start Processing again, one gets this:

Sunshine: No really, time for some fresh air for you.

That's it. One can no longer start Processing for an unknown period of time.

What is that, some kind of an Easter egg?! I find this rather inappropriate. Today, it only led to even more frustration for my students who are just starting to learn Python and Processing.

Expected Behavior

Please don't tell me Processing cannot "auto name" more than 26 sketches per day. Keep the funny messages, if you like, but allow Processing to start again. Thanks.

Environment

  • Processing version: 4.0.1
  • Operating System and OS version: Windows 10

Footnotes

  1. this number might be 26, as the last sketch I was able to create ended with z.

@processing-bot
Copy link
Collaborator Author

Created by: SableRaf

Hello @rric

Here's how you may fix this on Windows 10:

  1. Go to C:\Users\[User name]\AppData\Local\Temp\processing
  2. Move the anonymous sketches (named like sketch_000000a to sketch_000000z) to another folder.
  3. Start Processing again. It should open normally.

You may also manually create an empty .pde file outside of the Processing IDE and double click it.

The best way to avoid reaching the maximum auto-naming limit is to save your sketches.

I hope this will help your students and hopefully anyone else who may run into this issue in the future.


For anyone interested the check happens from line 70 in SketchName.Java

    if (index == 26) {
      // In 0159, avoid running past z by sending people outdoors.
      if (!breakTime) {
        Messages.showWarning("Time for a Break",
                "You've reached the limit for auto naming of new sketches\n" +
                        "for the day. How about going for a walk instead?", null);
        breakTime = true;
      } else {
        Messages.showWarning("Sunshine",
                "No really, time for some fresh air for you.", null);
      }
      return null;
    }

@processing-bot
Copy link
Collaborator Author

In GitLab by @rric on Oct 25, 2022, 17:16

I was able to reproduce a similar behaviour in Processing 3.5.4, i.e. this issue seems to be older ... Surprising, then, that I was not able to find any reference beforehand.

@SableRaf, thanks for explaining and pointing out the workaround.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Fixed for 4.0.2; this was just a regression introduced by the changes to temp folder handling to resolve #529.

@processing-bot
Copy link
Collaborator Author

Created by: github-actions[bot]

This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
has attachment Attachment was not transfered from GitLab
Projects
None yet
Development

No branches or pull requests

1 participant