Paul: Might this relate to what you saw as changed in the IDE on Serial?
No, or at least not directly related.
The serial monitor problem on Windows that delayed 1.24-beta3 for nearly a whole day turned out to be entirely a mistake on my part.
Back in the simpler times of Arduino 1.0.x, all of Arduino's Java source was contained in only 17 directories, with only 3 levels of hierarchy under app/src/processing/app. Oh how I long for those simpler days....
Now with Arduino 1.6.5, there are 4 locations. app/src/processing/app still is used, with 10 directories in 3 levels. But the pde.jar file is now also build with code from app/src/cc/arduino, which contains 16 more directories in another 3 levels of hierarchy. They're also now building a arduino-core.jar for the non-GUI stuff, with it's source in arduino-core/src/processing/app with many subdirs, though the java code is contained in only a dozen of them mostly contained in only 2 levels. There's also quite a lot of code now in arduino-core/src/cc/arduino, contained in 17 more directories on 3 levels of hierarchy.
Until 1.6.5, I've only needed to make edits to java source in app/src/processing/app and arduino-core/src/processing/app and a few of their subdirs. I manage my patching and JDK version checking with a number of small scripts. My patching process uses recursive "diff" and "patch" on those 2 directories.
With 1.6.5, Arduino's addition of a conceptually similar but very differently implemented feature to keep the serial monitor open caused massive merge conflicts. Most of the blame rests squarely on me, since I had gradually added lots of little and not-so-little patches into SerialMonitor.java over the years. On 1.0.x, that was really the only viable option. With 1.6.x, they added an AbstractMonitor.java file (thankfully containing a good amount of serial monitor speedups I'd previously contributed), meant to be inherited by different serial monitor implementations. I had meant to create a TeensyMonitor class to cleanly inherit from AbstractMonitor... but the path of least resistance was to bring in the work from 1.0.x as-is, and then as I kept working on it, more and more patches when into both SerialMonitor.java and AbstractMonitor.java. Earlier this week, I finally took the time to consolidate all of Teensy's very different stuff into
TeensyMonitor.java.
However, the switch to a dedicated TeensyMonitor object required
this tiny edit in MonitorFactory.java. Long term, I believe this is the right approach. It's working within the framework Arduino has created, at least to the best of my understanding of how they probably intended it to be used (of course, there's absolutely no documentation for any of this stuff... you have to learn & infer everything by reading the source code).
The 1.6.5 to 1.6.5r2 trouble came into play because I hadn't updated my scripts to deal with the fact I now had patches in 3 of the 4 locations, rather than just the 2 I've always patched before. I should probably adapt my scripts to treat the source as just 2 locations with much more heirarchy... but that's a bridge to cross when I need to patch 1.6.6.
This problem tripped me up for the better part of a day, mostly because there were no obvious errors. The unpatched MonitorFactory happily created instances of SerialMonitor, rather than TeensyMonitor. Fiddling with Windows always slows me down. I probably would have found and fixed this within minutes if it'd been on Linux... but 1.6.5r2 was only for Windows, so I didn't do any of my usual testing first on Linux and Mac.
So, ultimately, the problem turned out to be only a simple mistake on my part, failing to bring over one tiny but critically important part of my patch set from 1.6.5 to 1.6.5r2.
But along the way, I did enounter another rare corner case. Actually, maybe 2 or 3. They're so very hard to reproduce. But all were due to a couple threads continuing to run after closing the serial monitor, so the same
simple fix applied to all.
