Skip to content

Debugger does not work if Sketch name and folder are not equal #1190

Closed

Description

@Stefterv

Most appropriate sub-area of Processing 4?

PDE

Processing version

4.4.4

Operating system

Linux/macOS

Bug description

https://discourse.processing.org/t/impossible-to-activate-debug-in-processing/46781/8

The reason … the folder and PDE file was not sharing the same name. When I renamed my PDE script with the same content folder it makes it works …

Steps to reproduce this

  1. Create and save a new example sketch
  2. Close the sketch
  3. Rename the folder
  4. Open sketch in Processing
  5. Say keep so that sketch name and folder name are no longer in sync
  6. Enable Debugger
  7. Create a breakpoint
  8. Observe breakpoint not working

snippet

// Paste your code below :)

void setup() {

}

void draw() {

}

Additional context

No response

Would you like to work on the issue?

No, I’m just reporting the issue

Activity

  1. added
    bugSomething isn't working
    help wantedExtra attention is needed
    pdeProcessing Development Environment
    on Jul 24, 2025
  2. Stefterv commented on Jul 24, 2025

    @Stefterv
    MemberAuthor

    Related to #486

  3. kaybcodes commented on Jul 29, 2025

    @kaybcodes
    Contributor

    Hi! @Stefterv, I am looking into this issue with @SilasVM, @npNSU, and @awood0727. We were able to successfully replicate this issue using the steps provided. The debugger indeed fails to activate breakpoints when the sketch filename and folder name are not the same. We're currently investigating the underlying cause and exploring potential solutions. We'll follow up here with updates as we make progress.

  4. npNSU commented on Jul 31, 2025

    @npNSU

    Hey @Stefterv, Our team has been diligently working on finding the source and solution of this bug, and we think it could be along the line 912 of file path: app/src/processing/app/Sketch.java

    Line 912: if (!newMainName.equals(newSketchName) && newFolder.exists())

    We believe that this line of code is too restrictive for the user and it should be modified to allow the user to be able to change these variables without errors.

    Another thing we found was within lines 2170-2175 of the processing4/app/src/processing/app/ui/Editor.java file path, where it highlights the toggleBreakpoint() and the isDebuggerEnabled() functions.

    public boolean isDebuggerEnabled() {
        return false;
      }
    
    
      public void toggleBreakpoint(int lineIndex) { }
    

    We think this may be vital for us to note, as it directly points out the workflow within the UI.

    We’d appreciate your feedback on our current investigation!

  5. Stefterv commented on Aug 1, 2025

    @Stefterv
    MemberAuthor

    Hi @npNSU Thank you for your research so far! I took a look at the points you showed, these are related to the debugger functionality but not the actual implementation. Please take a look at /java/src/processing/mode/java/debug/ folder for the implementation of the debugger within Java mode. Good luck and thank you!

  6. awood0727 commented on Aug 4, 2025

    @awood0727
    Contributor

    Hey @Stefterv,
    Thank you for pointing us to the /java/src/processing/mode/java/debug/ folder! We've now focused our investigation specifically on the debugger implementation and found critical issues causing the breakpoint failures:

    Issue 1 in filepath: java/src/processing/mode/java/debug/LineBreakpoint.java

    While examining this file, we noticed that there was a line of code specifically for Java that returns the filename, while for PDE files, it gets the name from the editor.

    if (line.fileName().endsWith(".pde")) {   //Line of code mentioned (209)
      // standard tab
      return dbg.getEditor().getSketch().getName();
    }
    
    if (line.fileName().endsWith(".java")) {
      // pure java tab
      return line.fileName().substring(0, line.fileName().lastIndexOf(".java"));
    }
    return null;  
    

    }

    Issue 2 in filepath: java/src/processing/mode/java/debug/Debugger.java

    While examining this file, we noticed the same pattern. On line 1413, there is a function specifically to check on Java files that have mismatching names; however, there is no check for Java files.

    Possible Solution

    After multiple tests, we came across a potential solution. For issue 1, we edited line 211 so that the program will return the filename for PDE files, similarly to how it does for Java files. Additionally, for issue 2, we created a similar function for PDE files that will translate the filename over to the debugger. This has resulted in the debugger working as expected, even though the file and folder names are not the same. We have attached screenshots of the debugger before and after our implementation as well.

    Please let us know your feedback, and if you believe this is a good solution, I ask that you assign the issue to me, and I can get a pull request started. We greatly appreciate your guidance!

    Before Implementation

    Image

    After Implementation

    Image
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

bugSomething isn't workinggood first issueGood for newcomershelp wantedExtra attention is neededpdeProcessing Development Environment

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions