Have you ever created or used libraries?
Than you should know WProgram.h library, that is missing in new version, so many projects now couldn't be compiled.
There is very simple decision
just add this file to \arduino-1.0\hardware\arduino\cores\arduino
WProgram.h (73 Bytes)
You're wrong kaor. Why don't you RTFM?
· Renamed WProgram.h to Arduino.h.
- The WProgram.h file, which provides declarations for the Arduino API,
has been renamed to Arduino.h. To create a library that will work in
both Arduino 0022 and Arduino 1.0, you can use an #ifdef that checks
for the ARDUINO constant, which was 22 and is now 100. For example:#if defined(ARDUINO) && ARDUINO >= 100
#include "Arduino.h"
#else
#include "WProgram.h"
#endif
The Arduino Team considered including a WProgram.h, but ultimately they decided against it:
http://code.google.com/p/arduino/issues/detail?id=609
Personally, I would not have made that choice. In Teensyduino, I kept WProgram.h and also added Arduino.h, so either new or old libs can work.
"RTFM" seems a bit harsh.
I don't like seeing people suffering compatibility issues (which is why I kept WProgram.h and went to a lot of effort for backwards compatibility in Teensyduino). But what ships in the official Arduino isn't up to me.
Razorblade,
I'm not seeing how kaor is wrong.
All he stated was:
Both of these assertions are correct.
While the official solution is to correct each library code module with a conditional,
an interim "quick fix" that is much easier that fixes many library modules all at once is
to simply create a WProgram.h as kaor has stated.
The bottom line is to get things back to working again.
Creating a WProgram.h file one time is a much simpler and easier solution for less technical users
than having them wade through compiler error messages and then locate each source file that needs
correcting and then edit each file to correct the includes.
The needed backward compatibility isn't for the library writers, it is for the less technical users of the library
that are stuck in the middle.
I'm with Paul, I simply don't understand the decision not to include a little bit of additional backward compatibility,
particularly given the 1.0 IDE has added additional code to deal with supporting both the .pde vs .ino extensions.
A novice user can easily handle renaming his sketch to get going again. But even the simple changes to correct
the header filenames in the library code can be beyond many less technical users.
--- bill
Doesn't just seem, it indeed is. Shouting and the 'F' word. 
bperrybap:
Razorblade,
I'm not seeing how kaor is wrong.
All he stated was:
- WProgram.h is missing (renamed to Arduino.h)
- Many projects/libraries will no longer compile because of this.
Both of these assertions are correct.
No, they are not. Arduino 1.0 has changed more than a filename, and old projects/libraries will mostly not compile because of ALL OF THAT CHANGES (Serial.flush(), Serial.print(byte), write(str), "client == NULL", String class, ...........). Copy-rename Arduino.h (or worse, copying from 022) is a solution for nothing but few sketches.
Doing a 1.0 IDE clean 'install', using .INO file extension, updating Uno bootloader if you want to use it as ICSP programmer, spending 5 minutes learning the changes and modifying code, or asking developers to update their libraries is. Indeed it will stop "Arduino 1.0 is bad" topics from growing.
Anyway, you are right: Arduino team is forgetting that information availability is one of the most important Open-source Hardware premises.
So libraries form 022 are obsolete in 1.0 and we must wait for new versions or try to modify them ?
Max89:
So libraries form 022 are obsolete in 1.0 and we must wait for new versions or try to modify them ?
Yes, exactly.
But the libraries that come with Arduino, and many of the major libraries, have already been updated. I updated OneWire a couple weeks ago, and PS2Keyboard many months ago. I've sent patches to a several library authors. I'm planning to work on IRremote next week.
Razorblade:
bperrybap:
Razorblade,
I'm not seeing how kaor is wrong.
All he stated was:
- WProgram.h is missing (renamed to Arduino.h)
- Many projects/libraries will no longer compile because of this.
Both of these assertions are correct.
No, they are not. Arduino 1.0 has changed more than a filename, and old projects/libraries will mostly not compile because of ALL OF THAT CHANGES (Serial.flush(), Serial.print(byte), write(str), "client == NULL", String class, ...........). Copy-rename Arduino.h (or worse, copying from 022) is a solution for nothing but few sketches.
Stepping way off topic here. But I feel it is time for a lesson in
"The absence of a positive does not prove a negative."
i.e. just because other statements may be true it doesn't necessarily cause previous statements to be false.
Ok so lets do the breakdown:
Is the statement: "WProgram.h is missing" in 1.0 true or false? Hmm.... Well that is true there is no WProgram.h in 1.0
Is the statement: "Many projects/libraries will no longer compile because of this." in 1.0 true or false? Hmmm. Again this is true.
The fact that there are other issues that can keep still keep some things from compiling was never mentioned.
Likewise these statements never claimed that this single patch would solve all the incompatibilities in 1.0
There are several additional issues such as the changes in the Print class and the changing
of the send() function name in the wire library that can also keep things from compiling.
But just because there are other issues that can keep things from working does not change validity of
the above two statements. They are still both true.
IMHO what kaor is demonstrating and what Paul has actually done with his Teensyduino
(which is more extensive than adding a WProgram.h file)
is show that it is not difficult to provide some level of pre 1.0 backward compatibility
through some very simple means.
Will it work for everything? of course not but there is a level of pre 1.0 backward compatibility
that can easily be provided that does work for a great number of existing pre 1.0 libraries and sketches.
The Arduino team intentionally decided not do those things and push all work for dealing
with these incompatibilities out to the end users with no period of overlap.
And like I said in this thread:
While the changes to adapt code to 1.0 are usually quite minimal and easily done for a library
developer, they are often beyond the capabilities of many of the Arduino users.
Try compiling a pre 1.0 library and take a look at the lengthy error output. For a novice it
is quite scary looking and will not be obvious that the error is due to the library simply not including the proper header file.
Arduino has positioned itself as an easy to use system and it has often gone to great lengths
to try to make it easy to use for non programmer types.
Here is the mission statement directly from their main web page:
Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It's intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments.
Intentionally deciding to break 100% of the many years of pre 1.0 libraries floating around in cyberspace by
not providing any backward compatibility for pre 1.0 library code, IMHO,
sure feels like it goes against that core philosophy, especially when there are some very simple things that could be done to allow
many of the existing libraries and sketches to continue to work while not disabling or breaking anything
for the newer 1.0 libraries and sketches.
And if backward compatibility was not a high priority,
why continue to support the .pde extension in the 1.0 IDE?
Supporting both sketch extensions was quite a bit more work than the few other things
that would let many of the pre 1.0 libraries continue to work as well.
While there will always be the "proper" solution that purists may offer (or SHOUT) of "RTFM and then go fix the code yourself",
my prediction is that very soon, there will start to be some writeups available on the WEB
that will show less technical folks how to "patch" their Arduino 1.0 release to continue to use pre 1.0 libraries
so that they don't have continually fix pre 1.0 libraries that they discover out there in cyberspace.
It will be interesting to see how the mpide guys handle the 1.0 transition.
--- bill
All
Again Bill points out very well what I think. 
Much of the fuss here and elsewhere could have been avoided by some simple measures. Now Arduino is hit by negative reactions of many members of its own community. This is a strong message which could easily be predicted and avoided.
Incompatibilities at many levels are not fixed easily. I spend quite some time to update my eclipse plugin and I wondered what I was doing? Will Arduino 1.1 break it all again? If the plugin had been older I probably would not have updated it.
I still don't get why the Arduino IDE guys don't see this.
Best regards
Jantje
bperrybap:
Will it work for everything? of course not but there is a level of pre 1.0 backward compatibility
that can easily be provided that does work for a great number of existing pre 1.0 libraries and sketches.
I have personally worked with a large number of the commonly used libraries and their example sketches. WProgram.h, print(n, BYTE), and Wire.send represent the lion's share of all compatibility issues. All the others are relatively rare.
The Arduino team intentionally decided not do those things and push all work for dealing
with these incompatibilities out to the end users with no period of overlap.
"No period of overlap" doesn't take into account the many months where 4 beta tests and 2 release candidates were published. Unfortunately, they were published on an obscure wiki page, not the main download page, so relatively few users saw them. The first release candidate was announced on the Arduino blog on Oct 4th, and the upcoming candidates at Maker Faire on Sept 17. Some news sites carried those stories, though the 1.0 software issues were drowned out by hype about the upcoming new hardware, especially Due.
Certainly 1.0's release candidates could have been promoted much better. But to say the Arduino Team didn't give any period for libraries to adapt just isn't true. I personally updated several libraries during that time, and in the process developed and tested Teenyduino's backwards compatibility on 1.0, and forwards compatibility on 0022 and 0023.
I guess I'll clarify what I really meant by "No Period of overlap" since it can be
interpreted in different ways.
What I really meant was that there was not a release that tried to allow pre 1.0 code
to coexist along side of 1.x code in the same release.
By a "period of overlap" I meant a release that attempted to allow
both old and new source code to coexist in the same release.
The way 1.0 was handled, yes there was a not very well advertised period of time where
the new 1.0 release candidates and their testing overlapped the 0022 release
and a 0023 release actually happened after the 1.0 release candidates were published,
but there was ZERO overlap in terms of
a release in which pre 1.0 code could coexist along side of 1.0 code in the same release.
So while the Arduino team offered a period of time, essentially a warning period, to allow
developers time to update their code in preparation for the 1.0 release.
The decision for not providing additional backward compatibility meant that the end users would
not see any overlap period where they could continue to use their pre 1.0 code or libraries
in the official 1.0 release.
From and end user perspective, they have 0022 or 0023 which are working just fine
and then download the official 1.0 release, and things no longer compile.
IMHO, this is not a good first impression of the first official Arduino release.
If this were a 0024 release, I would have no issues with any of it.
But to break everything as you move into the 1.0 release seems really bad,
especially given that another release (0023) happened during the 1.0 release
candidate testing, which was made widely available that was not using the 1.0
RC code.
Whether people agree with backward compatibility or not, from purely a PR perspective, breaking
everything right as you deliver your first official 1.0 release doesn't make good press.
It is possible that there will be some amount some negative press on the impact
of the decision to not provide additional backward compatibility.
So, IMHO, it was simply a mistake to jump directly to 1.0 from the 0022/0023 release
and not provide additional backward compatibility, especially given how simple it is to toss in.
--- bill
Jantje:
Will Arduino 1.1 break it all again?
No. The intention is that all other releases in the 1.x series will be backward compatible with the 1.0 release.
--Philip;
Whether people agree with backward compatibility or not, from purely a PR perspective, breaking
everything right as you deliver your first official 1.0 release doesn't make good press.
It is possible that there will be some amount of negative press on the impact
of the decision to not provide additional backward compatibility.
I fully agree with this one. It is not a technical issue. It is a customer relationship issue which makes many people stand up and say it was a bad idea.
Best regards
Jantje
1.0 breaking everythnig in an open source model is not very smart from the core team. This is worse than the Vista stuff. Probably similar to IBM PS/2. The only thing of it that succeeded was the mini DIN keyboard/mouse connector 
instead of big DIN5 and serial DB9, BTW a similar strange mapping as FTDI USB-serial, but I digress :-).
Look at the presentation they did in september: many many download, but majority running 0022. Very likely 0022 will stay alive for a long time. I for one will definitely NOT (maybe never) migrate to 1.0. No advantage at all, lack of documentation/libraries, and no sign of community support. Only one thing can be worse : a 2.0 that would break it again and be for a fee
IF I need to "restart", then it would be much better to go 32-bit, i.e. Maple or PIC. At least this gives you some positive return on effort.
Conclusion : the only good reason for the Arduino core team to sell 1.0 would be full support of 32-bit platforms. This is the idea behind Pinguino, but it looks to me that they (the Pinguino team) lack momentum to succeed.
I do not consider myself an advanced user however, I like 1.0 IDE for some of it's features and I think with time it be 100% better than IDE 22. I have already ran into some incompatibility issues so, I just copy, paste, and move my sketch to IDE 22 to continue the work. I think they did well considering that they are trying to make such a vast array of things work with one IDE.
I don't mind using both IDE22 and IDE1.0 to get the best of both worlds. Once 1.0 is sorted out, then I can ditch the old.
It is a small pain but, not comparable to Windoze version changes.
I only started Arduino 1 week ago, and what a nightmare!
I was about to go back to Labview and direct programming of microcontrollers, until I found this thread.
Nothing with libaries would compile, the help files where no help at all, because they refered to a Wprogram.h that I couldn't find anywhere.
I have downloaded 023, and I am willing to try Arduino again, because for small tasks/ prototyping, it makes programming so easy (now that it will compile).
I've been developing software / hardware for 20+ years now, and I must say, this 1.0 is a real flop guys, sorry 
Razorblade:
You're wrong kaor. Why don't you RTFM?· Renamed WProgram.h to Arduino.h.
- The WProgram.h file, which provides declarations for the Arduino API,
has been renamed to Arduino.h. To create a library that will work in
both Arduino 0022 and Arduino 1.0, you can use an #ifdef that checks
for the ARDUINO constant, which was 22 and is now 100. For example:#if defined(ARDUINO) && ARDUINO >= 100
#include "Arduino.h"
#else
#include "WProgram.h"
#endif
I doubt you don't understand my goal, just quoted the code :))
this code is supposed to be inserted in project not in library, therefore old projects should be modified and that isn't the best way imho 
There are many libraries that hasn't been updated (most of them!)
I've been reading this highly interesting thread because I've been experiencing the same problems as everybody since I switched to IDE 1.0.
Does seem a shame to excessivly bad programmers like myself to have to dig into library fixing tasks when we just want to get our projects up and running. Even worse - from what I read, it sounds like the future versions of the IDE might be paying versions? What a nightmare!
I've been using Arduino for 3 years and really enjoy the whole "easy to use" philosophy - I'd given up on microcontrollers after some heroic efforts on the 87C752/752 family in assembler a few years ago...
I like the look and feel of the 1.0 IDE but I think I'll stick to 0023 untill things settle down a bit.
Keep up the good work!
And thaks for all your valuable input for people like myself
I always linger a few versions behind, but I really struggle with "movin on up" to 1.0, just recently I had linux mint 10 installed on my bench machine, which lost support as of this month. It is a older release and thus even older packages, I was running arduino v.18.
I was working on a project using TV out library, which makes things pretty tight in the ram department, with the old .18 which I actually like the best I had 333 bytes of ram free. Then I upgraded linux to xbuntu, apt-get arduino got the .22 version ... ok whatever theres some handy things there, bam 220 bytes free.
I have 1.0 installed on my main / windows desktop for when I need to test some code when trolling the forums so I plopped my project into that, uploaded and bam 186 bytes free.
So while I am stressing to pinch bytes to ensure I have enough for my project + a little wiggle room, the newer software packages are eating more room for zero gain (not to mention the hex files increased significantly each time as well), which really puts me into a rush to get the bleeding edge ...
Hell I am seriously contemplating rolling back to .17 or .18, though I might have to fix a couple things here and there, why not? Sounds like I am going to have to anyway, might as well save ram and program space while I am at it.
jomo:
I've been reading this highly interesting thread because I've been experiencing the same problems as everybody since I switched to IDE 1.0.
Does seem a shame to excessivly bad programmers like myself to have to dig into library fixing tasks when we just want to get our projects up and running. Even worse - from what I read, it sounds like the future versions of the IDE might be paying versions? What a nightmare!
I've been using Arduino for 3 years and really enjoy the whole "easy to use" philosophy - I'd given up on microcontrollers after some heroic efforts on the 87C752/752 family in assembler a few years ago...
I like the look and feel of the 1.0 IDE but I think I'll stick to 0023 untill things settle down a bit.
Keep up the good work!
And thaks for all your valuable input for people like myself
It's not just a one or the other version choice, as actually the best solution is have both v23 and v1.0 installed on your PC.
Lefty