Google search got me here: http://www.sparkfun.com/commerce/product_info.php?products_id=7918

There is example C code on that page.  Maybe that could be a start?

What happens if you try a power adapter or a battery?  Center of the jack is positive.

Seems to me you are just hitting the end of SRAM.  Code does weird things when RAM starts thrashing.

I wouldn't call this a leak if you keep allocating memory and not releasing it.

Does append() return anything of interest?  I'm too lazy to look it up, but you might see it failing to allocate the space.

I suspect the intention was not to reproduce the avr-libc docs which are, as you point out, identical.  I recall that there is link back to avr-libc in the appropriate places for those library details that are unchanged with respect to the Arduino and avr-libc.

Yup, it is falling off the end of the world trying to make sense of that bad code.  The parsing stuff looks ok, but it might be the display code wanting to display things over and over.

I cannot reproduce this in 0016 by setting TEMP to a place on the T: drive in run.bat and launching the IDE.

If you get a chance, please specify exactly how you are invoking the IDE, and where this environment is changed.

(This is a hint that you don't have to change the system-wide TEMP probably if you hack the run.bat and invoke the IDE from that.)

Actually, the interaction with the OS and Java for input devices is very tricky.  Scroll-mice didn't really work at all in the earlier days of Java, and have been broken regularly as the hardware underlying the abstraction of the VM has changed over time.

I suspect neither Sun nor Microsoft have fully vetted the VM for use on Windows 7 for this reason.  The VM will be certified, with caveats, once Windows 7 has been released.

Check the Java BugParade to see if this has already been reported.  I also suspect that some releases of the VM will not be supported in this release of Windows.  If Arduino is bundled with a JRE on Windows it might actually not be supported.  There are ways to have Arduino use a different JRE, of course.

The boolean type definition for "boolean" is in wiring.h, as are the definitions for "true" and "false".

The example is correct.  For some reason your development system is not picking up or finding the right header files, so the compiler doesn't know what boolean means.

There is a "verbose" mode you can run in that might give you more information.  Of course, we are not sure what you are actually doing, as per the last comment regarding "Illuminato core" so you might need to start from the beginning and show what you are really doing.

The way that the IDE captures the output from external processes is a bit problematic.  I took a look at it briefly and did not see a trivial fix.  If I do look at it again I might refactor it.  A lot.

The problem with fixing these sorts of problems is that the easiest way to make the problem go away is to put the debugger on it, or add some logging!  This is what the verbose setting sometimes magically solves things.

So it requires someone who really want to bite into it, and who can reproduce it.  I'm not quite the former (yet) even if I'm the latter.  Another problem is that I mostly use make at the command line to make sketches now, so I have little personal incentive to improve the IDE.  Yes, a terrible excuse, but what can you do?

But, I will try to take a look at this one this week-end.  Like I said, I think there will be a fair amount of refactoring to do, so it may take awhile to get right.

Here it is:

Code:

Index: Sizer.java
===================================================================
--- Sizer.java      (revision 567)
+++ Sizer.java      (working copy)
@@ -57,17 +57,26 @@
    
     commandSize[1] = buildPath + File.separator + sketchName + ".hex";
 
+        int rc = 0;
     try {
       exception = null;
       size = -1;
       firstLine = null;
       Process process = Runtime.getRuntime().exec(commandSize);
-      new MessageSiphon(process.getInputStream(), this);
-      new MessageSiphon(process.getErrorStream(), this);
+      MessageSiphon in = new MessageSiphon(process.getInputStream(), this);
+      MessageSiphon err = new MessageSiphon(process.getErrorStream(), this);
+
       boolean running = true;
+
       while(running) {
         try {
-          process.waitFor();
+              // Wait for the MessageSiphon threads
+              if (in.thread != null)
+                    in.thread.join();
+              if (err.thread != null)
+                    err.thread.join();
+                  
+          rc = process.waitFor();
           running = false;
         } catch (InterruptedException intExc) { }
       }
@@ -76,7 +85,7 @@
       // some sub-class has overridden it to do so, thus we need to check for
       // it.  See: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1166589459
       exception = new RunnerException(
-        (e.toString() == null) ? e.getClass().getName() : e.toString());
+        (e.toString() == null) ? e.getClass().getName() + rc : e.toString() + rc);
     }
    
     if (exception != null)

Thread.join() to help co-ordinate threads, though I think I still have not convinced myself that I haven't just moved the race condition to this class.

Some exception and info tweaks.

[Later]

Wait, I changed my mind.  This is exactly how we can solve this problem in a highly parallelized environment.  We should still mark this as a place where we can improve things with Java 5 ProcessBuilder which sidesteps all this thread output cruft.

To be sure, this annoyance will never keep a sketch from being compiled and uploaded to any device.  It is merely coincidence that one is seeing the "Couldn't determine program size" message at the same time.  But it is unrelated.

I haven't posted the patch because I have not had time to really look at my changes and then cook up a proper patch.  I'm hoping to have some time this week to do that.

It may be that my patch is completely bogus, and I've just moved the race condition around, or made the hole smaller.

Hmm.  An initial naive pass at the messaging stuff in Compiler does not indicate that the same fix will address this.  The output is just not there.  This is not the same race condition.  More debugging will have to be done.  I'll try again later this week.

Correct.

Ah foo. I messed up the patch.  Grab another copy.

And then change Info.plist like:

Code:

              <array>
                       <string>$JAVAROOT/lib/patch</string>
                       <string>$JAVAROOT/antlr.jar</string>
                       <string>$JAVAROOT/Arduino.jar</string>
                       <string>$JAVAROOT/oro.jar</string>

Then, unzip the patch into Arduino 15.app/Contents/Resources/Java/lib/patch/

Er, I guess I should have replied, instead of just adding to my last comment.

So: bump!