Skip to content
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

[v4.0.2 and above] “Cannot find a class or type named ‘PApplet’” error #626

Closed
12people opened this issue Dec 21, 2022 · 6 comments · Fixed by #635
Closed

[v4.0.2 and above] “Cannot find a class or type named ‘PApplet’” error #626

12people opened this issue Dec 21, 2022 · 6 comments · Fixed by #635

Comments

@12people
Copy link

Description

I’m maintaining an open-source Processing app called FOSStriangulator . It used to compile just fine with every Processing version I’ve tried up until Processing 4.0.2. Now, with Processing 4.0.2 and newer versions, it won’t compile, whereas with 4.0.1, it still does. With the newer versions, it’s giving me this error:

Cannot find a class or type named “PApplet”

It’s also giving me a range of errors, all seemingly random, such as not being able to find classes like PImage, PrintWriter, IntList, etc.

b7ef6f81331173d25768f9451edd4f4254bd2d7b

I looked at the 4.0.2 release notes 1 and I can’t see any change that might be causing the issues.

I originally posted about this on the forum and I was directed to file a bug report here.

Expected Behavior

I was expecting the app to run without a problem, just like it does on all the Processing versions I tried before 4.0.2.

Current Behavior

As described above, running the app on versions 4.0.2 and above gives the Cannot find a class or type named “PApplet” error and fails to run.

Steps to Reproduce

  1. Clone the FOSStriangulator repository.
  2. Open the project up in Processing 4.0.2 or above.
  3. Run the project.

Your Environment

  • Processing version: 4.0.2 and above (I tried every major version)
  • Operating System and OS version: macOS 13.1 on ARM; also independently verified on Linux
@benfry
Copy link
Owner

benfry commented Jan 9, 2023

@sampottinger Possible preproc changes in 4.0.2 causing this?

@sampottinger
Copy link
Collaborator

I'll take a look @benfry!

@sampottinger
Copy link
Collaborator

Hey all! Sorry for the issue here @12people.

@benfry I was trying to beautify the output Java file and part of that was trying to detect if the user was importing processing.core on their own, preventing duplicate imports from being written by the preproc. So, users who manually import processing.core.* wont see preproc generated import statements for processing.core objects.

This code imports part of processing core explicitly (https://github.com/FOSStriangulator/FOSStriangulator/blob/37fb816cc70dc4315c8a26b0b0db1411b20ffb20/FOSStriangulator/DTEdge.pde#L30) but not all of it. My change (#597) was problematic if the developer uses a package from default imports under processing.core without explicitly importing it but explicitly importing something else from processing.core as the preproc wont try to write the default imports for them to prevent duplication. Thinking more on this, unless you are opposed, I would recommend just allowing the duplicated imports to be written by the preproc in this instance. Though it may lead to duplicitous code, it is most consistent with historic behavior.

This fix is implemented with #635. My apologies to both of you for the bug. @12people I have tested FOSStriangulator with my code fix and it builds successfully.

@benfry
Copy link
Owner

benfry commented Jan 10, 2023

Great, thanks for taking a look Sam. It happens!

Merging in the fix for 4.1.2.

@12people
Copy link
Author

Amazing, thanks a ton!

@github-actions
Copy link

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 Feb 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants