The message "Your sketch has been modified externally..." appears erroneously #3222

Closed
Corrado972 opened this Issue Apr 27, 2015 · 18 comments

Comments

Projects
None yet
5 participants
@Corrado972

Hello,
while a sketch is running, if I modify and save the sketch the message "Your sketch han been modified externally. Would you like to reload the sketch?" appears and at the beginning of the file the comment " //<>// " is automatically inserted.

This same message also appers if I open and close the dialog "About processing".

Processing 3.0a7-windows64
Windows 7 Pro 64bit

@glasscanvas

This comment has been minimized.

Show comment
Hide comment
@glasscanvas

glasscanvas Apr 27, 2015

Same problem on Macintosh

Same problem on Macintosh

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Apr 27, 2015

Member

I can't reproduce this on any machines. Are you using the debugger? What's the exact sequence that causes the problem?

Member

benfry commented Apr 27, 2015

I can't reproduce this on any machines. Are you using the debugger? What's the exact sequence that causes the problem?

@Corrado972

This comment has been minimized.

Show comment
Hide comment
@Corrado972

Corrado972 Apr 27, 2015

I start Processing,
load the sketch,
modify at least one character
then save the sketch.

I switch to another application then switch to Processing again: the message appear and in the console window there are rows like (Gold5EsecInfo is the name of the sketch):
Gold5EsecInfo.pde 35
Gold5EsecInfo.pde 9
Gold5EsecInfo.pde 9

If I click "yes", the comment " //<>// " appear on the sketch.

Hope this help

I start Processing,
load the sketch,
modify at least one character
then save the sketch.

I switch to another application then switch to Processing again: the message appear and in the console window there are rows like (Gold5EsecInfo is the name of the sketch):
Gold5EsecInfo.pde 35
Gold5EsecInfo.pde 9
Gold5EsecInfo.pde 9

If I click "yes", the comment " //<>// " appear on the sketch.

Hope this help

@glasscanvas

This comment has been minimized.

Show comment
Hide comment
@glasscanvas

glasscanvas Apr 27, 2015

Ben,

This happened on the latest alpha 3.07a and Mac Yosemite. I did have the debugger ON. I had also recently added the GUI builder but the error happened after I had already saved.

Unrelated: I have sketch with a lot of tabs which I mostly work on my iMac 27. But when I work with it on a smaller screen (11" Mac book air) there is no way to reach all the tabs. It might be nice to have a down arrow appear or scroll arrows.

I saw this reported already, but it is really hard to see the breakpoints in the 3.07a IDE.

Thanks for developing Processing. I can get lots of results without so much development overhead. I mostly use it to process images and create a new image based on the content of the image source. I mostly create splines depending on image gradients, color, etc. and save the result as either bitmaps or SVGs.

Will processing have native GUI elements such as sliders, boxes to enter parameters? I am familiar with the GUI library though.

Thank you very much,
I hope you don't mind the other feedback

Carlos Caicedo

Sent from my iPhone

On Apr 27, 2015, at 8:35 AM, Ben Fry notifications@github.com wrote:

I can't reproduce this on any machines. Are you using the debugger? What's the exact sequence that causes the problem?


Reply to this email directly or view it on GitHub.

Ben,

This happened on the latest alpha 3.07a and Mac Yosemite. I did have the debugger ON. I had also recently added the GUI builder but the error happened after I had already saved.

Unrelated: I have sketch with a lot of tabs which I mostly work on my iMac 27. But when I work with it on a smaller screen (11" Mac book air) there is no way to reach all the tabs. It might be nice to have a down arrow appear or scroll arrows.

I saw this reported already, but it is really hard to see the breakpoints in the 3.07a IDE.

Thanks for developing Processing. I can get lots of results without so much development overhead. I mostly use it to process images and create a new image based on the content of the image source. I mostly create splines depending on image gradients, color, etc. and save the result as either bitmaps or SVGs.

Will processing have native GUI elements such as sliders, boxes to enter parameters? I am familiar with the GUI library though.

Thank you very much,
I hope you don't mind the other feedback

Carlos Caicedo

Sent from my iPhone

On Apr 27, 2015, at 8:35 AM, Ben Fry notifications@github.com wrote:

I can't reproduce this on any machines. Are you using the debugger? What's the exact sequence that causes the problem?


Reply to this email directly or view it on GitHub.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Apr 27, 2015

Member

@Corrado972 If you leave the debugger off (and perhaps restart Processing?), does it still cause trouble?

Member

benfry commented Apr 27, 2015

@Corrado972 If you leave the debugger off (and perhaps restart Processing?), does it still cause trouble?

@Corrado972

This comment has been minimized.

Show comment
Hide comment
@Corrado972

Corrado972 Apr 27, 2015

Ben,
the debugger is off because the menù "Debug" shows "Enable Debugger".

Am I right? Or there is a different debugger that I can disable? I'm not an expert of Processing.

Thank you

Ben,
the debugger is off because the menù "Debug" shows "Enable Debugger".

Am I right? Or there is a different debugger that I can disable? I'm not an expert of Processing.

Thank you

@pvrs12

This comment has been minimized.

Show comment
Hide comment
@pvrs12

pvrs12 Apr 27, 2015

Contributor

I looked into this since I wrote the original code and it seems pretty confusing to me. I can reproduce the erroneous reload message after saving the sketch in processing (normal Ctrl+S) but not all the time. The times that are echoed to the console on reload are always incredibly low (6ish ms).

It might make sense to change the logic to only prompt for a reload if the diff time is greater than some reasonably low (500ms?) buffer value as it is pretty unlikely for a file to be modified within half a second of being saved in processing. This would be a pretty simple change in the code to something like this

long diff = sketchFile.lastModified() - sc.lastModified();
//if it is less than 500, might as well be 0
if(Math.abs(diff) < 500){
    diff = 0;
} 
if (diff != 0) {
    //i have concerns about this
    if (Base.isMacOS() && diff == 1000L) {
      // Mac OS X has a one second difference. Not sure if it's a Java bug
      // or something else about how OS X is writing files.
      continue;
    }
  System.out.println(sketchFile.getName() + " " + diff);
  reloadSketch(sc);
  return;
}

This should work for anything but OS X. I'm not sure how to handle that one since it has reliance on being exactly 1000ms. Could just add a 500ms buffer on that too I guess

Contributor

pvrs12 commented Apr 27, 2015

I looked into this since I wrote the original code and it seems pretty confusing to me. I can reproduce the erroneous reload message after saving the sketch in processing (normal Ctrl+S) but not all the time. The times that are echoed to the console on reload are always incredibly low (6ish ms).

It might make sense to change the logic to only prompt for a reload if the diff time is greater than some reasonably low (500ms?) buffer value as it is pretty unlikely for a file to be modified within half a second of being saved in processing. This would be a pretty simple change in the code to something like this

long diff = sketchFile.lastModified() - sc.lastModified();
//if it is less than 500, might as well be 0
if(Math.abs(diff) < 500){
    diff = 0;
} 
if (diff != 0) {
    //i have concerns about this
    if (Base.isMacOS() && diff == 1000L) {
      // Mac OS X has a one second difference. Not sure if it's a Java bug
      // or something else about how OS X is writing files.
      continue;
    }
  System.out.println(sketchFile.getName() + " " + diff);
  reloadSketch(sc);
  return;
}

This should work for anything but OS X. I'm not sure how to handle that one since it has reliance on being exactly 1000ms. Could just add a 500ms buffer on that too I guess

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Apr 27, 2015

Member

@pvrs12 That actually sounds like a separate bug... that we need a window in which modifications can be made. Though it sounds like that'll be a necessary change as well.

I'm nervous that the issue being reported is that the debugger is modifying the file behind the scenes and therefore the sketch appears to have changed. I don't know @Manindra29's debugger code well enough yet to understand if that's the case or not, but we'll have to see.

Member

benfry commented Apr 27, 2015

@pvrs12 That actually sounds like a separate bug... that we need a window in which modifications can be made. Though it sounds like that'll be a necessary change as well.

I'm nervous that the issue being reported is that the debugger is modifying the file behind the scenes and therefore the sketch appears to have changed. I don't know @Manindra29's debugger code well enough yet to understand if that's the case or not, but we'll have to see.

@pvrs12

This comment has been minimized.

Show comment
Hide comment
@pvrs12

pvrs12 May 2, 2015

Contributor

I looked into this error a little further and the two are definitely separate like you thought @benfry.

I think the one I reported might have had to do with my using a Windows 10 preview build (really shouldn't have tested on that).

The issue that brought this up is, as you suspected related to the debugger. It looks like breakpoints are implemented (and saved) within the file by placing //<>// at the end of the line the breakpoint is located on. This comes from inside the java mode code, the symbol is set here. I haven't been able to reproduce getting the reload message yet, but I'm sure it is possible if this is getting added to the file via some different save method.

Edit: Just looked a little more, the file is being saved in a different manner than the normal save function here. I think if that is simply changed to sketch.save() it will fix this issue, but I don't know if this could save things that shouldn't be saved like other tabs.

Contributor

pvrs12 commented May 2, 2015

I looked into this error a little further and the two are definitely separate like you thought @benfry.

I think the one I reported might have had to do with my using a Windows 10 preview build (really shouldn't have tested on that).

The issue that brought this up is, as you suspected related to the debugger. It looks like breakpoints are implemented (and saved) within the file by placing //<>// at the end of the line the breakpoint is located on. This comes from inside the java mode code, the symbol is set here. I haven't been able to reproduce getting the reload message yet, but I'm sure it is possible if this is getting added to the file via some different save method.

Edit: Just looked a little more, the file is being saved in a different manner than the normal save function here. I think if that is simply changed to sketch.save() it will fix this issue, but I don't know if this could save things that shouldn't be saved like other tabs.

@pvrs12

This comment has been minimized.

Show comment
Hide comment
@pvrs12

pvrs12 May 10, 2015

Contributor

Bumping this too. I can submit a PR which should fix this if you would like

Contributor

pvrs12 commented May 10, 2015

Bumping this too. I can submit a PR which should fix this if you would like

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 10, 2015

Member

Yes, I think we should pass it through the regular save() method, because users have to save before running anyway (please verify that that's correct). A PR is always welcome.

And for the other issue, I think we need to say something like "if the time difference is <= 1000 ms" then we don't count it as modified.

Member

benfry commented May 10, 2015

Yes, I think we should pass it through the regular save() method, because users have to save before running anyway (please verify that that's correct). A PR is always welcome.

And for the other issue, I think we need to say something like "if the time difference is <= 1000 ms" then we don't count it as modified.

@pvrs12

This comment has been minimized.

Show comment
Hide comment
@pvrs12

pvrs12 May 11, 2015

Contributor

Sorry for the bumps, I won't do that again. Those two PRs should fix these issues.

Contributor

pvrs12 commented May 11, 2015

Sorry for the bumps, I won't do that again. Those two PRs should fix these issues.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 11, 2015

Member

Thanks; appreciate it!

Member

benfry commented May 11, 2015

Thanks; appreciate it!

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 12, 2015

Member

Should be fixed for 3.0a8. Fingers crossed...

Member

benfry commented May 12, 2015

Should be fixed for 3.0a8. Fingers crossed...

@benfry benfry closed this May 12, 2015

@rapatski

This comment has been minimized.

Show comment
Hide comment
@rapatski

rapatski Jun 14, 2015

Hey guys, I'm running into this issue running the newly released 3.0a10 upon load of a sketch. Choosing Yes recursively prompts another dialog, choosing No resumes normal behaviour until the IDE loses focus and gains focus again - prompting the dialog again. Tried deleting my (heavily customised) preferences file but to no avail; a fresh preferences file elicits the same behaviour. Debugger disabled.

Hey guys, I'm running into this issue running the newly released 3.0a10 upon load of a sketch. Choosing Yes recursively prompts another dialog, choosing No resumes normal behaviour until the IDE loses focus and gains focus again - prompting the dialog again. Tried deleting my (heavily customised) preferences file but to no avail; a fresh preferences file elicits the same behaviour. Debugger disabled.

@rapatski

This comment has been minimized.

Show comment
Hide comment
@rapatski

rapatski Jun 14, 2015

OK, narrowed down the issue only to occur on sketches stored on my secondary FAT32 formatted partition. The same sketch stored on the main HFS+ partition seems to work fine.

OK, narrowed down the issue only to occur on sketches stored on my secondary FAT32 formatted partition. The same sketch stored on the main HFS+ partition seems to work fine.

@pvrs12

This comment has been minimized.

Show comment
Hide comment
@pvrs12

pvrs12 Jun 14, 2015

Contributor

I'm sure this has to do with this code

if (Base.isMacOS() && diff == 1000L) {
      // Mac OS X has a one second difference. Not sure if it's a Java bug
      // or something else about how OS X is writing files.
      continue;
    }

I don't know if it is possible to detect the partition type that a file is stored on, but I'm sure that's the issue here

Contributor

pvrs12 commented Jun 14, 2015

I'm sure this has to do with this code

if (Base.isMacOS() && diff == 1000L) {
      // Mac OS X has a one second difference. Not sure if it's a Java bug
      // or something else about how OS X is writing files.
      continue;
    }

I don't know if it is possible to detect the partition type that a file is stored on, but I'm sure that's the issue here

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 15, 2015

Member

Please open a separate issue for this.

Member

benfry commented Jun 15, 2015

Please open a separate issue for this.

@processing processing locked and limited conversation to collaborators Jun 15, 2015

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