next topic »

[on:]

I've had a bit of a search, and I can't find this, but I can't believe it's unique.

When I hit the Verify/Compile button in the development environment and there's something wrong with my program one of three things happens:

I get an error message telling me in which function the error is and what I've done wrong.  

I get an error message telling me in which function some unspecified error is.  

I get no error message, but the error bar in the window goes red to tell me there's an error somewhere or other that could be anything.  >

In the last two cases, how do I find out what's wrong?

I get the same problems with a number of different devices in the Arduino family.  I'm running Arduino-0015 under Ubuntu.

[Reply #1 on:]

I've seen this kind of thing before -- it must be on the forums somewhere!  There is a way to make a "verbose" setting, in the main preferences file I think, that helps in some cases.

[Reply #2 on:]

Thanks - I had actually found build.verbose and upload.verbose in the preferences file and set them true.  It made no difference.  But in response to your post I discovered that, if you edit the file while the development environment is running, it overwrites it with the old values when you quit (which is actually understandable).  Lesson: quit, then edit.

Now I get a list of what it's doing, which is better:

avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -mmcu=atmega644p -DF_CPU=16000000L -I/usr/local/arduino-0015/hardware/cores/sanguino /usr/local/arduino-0015/hardware/cores/sanguino/wiring_serial.c -o/tmp/build23199.tmp/wiring_serial.c.o
.
.
.
avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega644p -DF_CPU=16000000L -I/usr/local/arduino-0015/hardware/cores/sanguino /tmp/build23199.tmp/Temporary_6723_3259.cpp -o/tmp/build23199.tmp/Temporary_6723_3259.cpp.o

But the bar still goes red at the end indicating that something's wrong, but no indication of what.

So I ran the last command in a terminal window, which - inter alia - gave me

In file included from /tmp/build23199.tmp/Temporary_6723_3259.cpp:18:
/tmp/build23199.tmp/cartesian_dda.h:163:2: error: #endif without #if

which allowed me to fix the problem.  But - despite setting all verbose values true - I still didn't get that rather important message in the development environment.

[Reply #3 on:]

This is a thread with a similar problem:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1233044085/14#14

There's another, better one but I can't find it yet.

[Reply #4 on:]

There are already several threads about this problem (eg http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1235432803 or http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1233044085) but no response from the developers. There is also some discussion after I brought it up in this thread: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1225145000 but no progress.

This seems to me to be a really serious bug, and I don't understand how the developers can simply ignore it.

Barney.

[Reply #5 on:]

Thanks all.  

Hacky fix: copy and paste the last command in the list you get from build.verbose into a terminal window and actually see the error messages.

Having raised the issue, the least I can do is to link all these threads together, which I'll do now.

[Reply #6 on:]

Does anyone know why this happens?  Is it because the error occurs in a library (and the library build process is separate from the sketch build process)?  Or is there a race condition similar to the problems with showing the size of a compiled sketch?

[Reply #7 on:]

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.

[Reply #8 on:]

Any help would be appreciated.  I already committed your patch for Sizer.java.  Even if you don't have time to find a correct fix, any diagnostics would be useful.