Hi guys, sorry for late reply.
You don’t need to change anything or switch to Atom. Update check failed error was due to server hiccup. Current installation of Particle Dev App should update automatically on OS X.
If you’re more advanced users, using Atom will allow you to hack with our packages and write your own too 
Suggested feature/FIX.
Particle Dev (Atom) just trashed two of my files after making minor changes. The IDE had been open overnight, and I simply edited the files and tried to save them. The dots remaine Blue. Then after a restart of Dev - my files were GONE = ZERO byte length :-O.
Please consider integrating Visual SVN as a requirement ???.
Being new to Particle - I had not yet put my files under my SVN source control system :-((, so now face the daunting task of re-creating by hand :-((.
Question - are the files cached on the build compiler under my login ???. If so how to I get them please :-)).
BR
Graham
Hi @GrahamS. Seems that files you mentioned haven’t beed saved (blue dot next to filename). It’s possible you tried to save it to unreachable network location, write protected media or didn’t confirm by mistake. Unfortunately we don’t store local files on our servers so we’re unable to restore them.
Atom/Particle Dev are well integrated with git version control system, so we encourage using it instead of SVN.
Hi,
Thanks for the reply - I sort of guessed that ;-).
Now recovered by re-writing the code from scratch. It was a cpp file (now 195 lines) and an h (now 77 lines).
So luckily these were not too big and I could actually remember most of it anyway as I only created them yesterday.
As for saving to an unknown location - sorry but NO - its a local folder. Not protected, and NO confirm dialog popped up - unless it was hidden !!!. It must also have ‘tried’ to save them as outside Dev they were still in the folder but BOTH had zero bytes !!! - thus a VERY BAD save operation. Last night they were fully operational files - built and running…
As for GIT - I really do not like it - never have done :-O. Its a nightmare to the ‘uninitiated’ 
- to me its just not ‘intuitive’ :-(. Plus - I really don’t want my private code at risk on a public server :-O.
NB I am not a dev noob - and been developing software for 40 years or so :-O. So yup - I am an ‘oldie’ and can’t abide some of the ‘newer’ ways of working ;-)) - we’ve forgotten way too much!!
This is almost definitely an issue with the Particle Dev (or Atom ??) environment (on my PC at least - Windows 8.1). Basically if you leave it open for too long it seems to get VERY confused, and just stops doing things (like compiling !!), and like the uncaught errors (trapped in your code - not mine :-O) which randomly pop up during compiling :-O.
Close Atom, re-open and its fine (for quite a while).
I really MUST stop leaving it running I guess - AND start using Visual SVN again ;-)).
Don’t get me wrong…
Particle Dev is a GREAT tool to use - I MUCH prefer it to the web build stuff !!. BUT its a tad ‘raw around the edges’ - mind you I AM more used to a tool like Visual Studio Pro (2013 and all the way back to the 90’s 
- not really used 2015 yet).
Not a complaint as the MS tool has had a hell of a lot more paid resource thrown at it ;-)).
NB I LOVE these ‘Photon’ modules :-)) - any thoughts about a 5G wifi module ??? 2.4G is a pretty crowded space nowadays - and has limited channels ;-).
These are HIGHLY productive modules - ready to GO ‘out of the box’ ;-)).
BR
Graham
When compiling with Particle Dev or CLI, why do our files have to be flat? It would be awfully convenient if we could put libraries in subdirectories. That way, we could use the exact same files locally as in the web IDE, without having to muck around with changing library references.
We share your pain and are working on a next version of a compile server which will allow nested dirs (and more). It’s a huge change (involves a lot of moving parts) so it may take some time before it goes live.
Are there any best practices or tricks that anyone is using for conditional compilation, depending on the compiler environment? Something like…
/* is there a define for this? if so, what is it? */
#ifdef PARTICLE_CLOUD
#include "neopixel/neopixel.h"
#else
#include "neopixel.h"
#endif
Unfortunately no. What you can do is define PARTICLE_CLOUD in a separate header file and keep one that equals true in Build IDE and one that equals false on disk.
Can you explain more please? I’ve been bitten by this too and didn’t see an obvious solution.
Of course, ideally we’d have the local build functioning the same as the cloud build so these differences aren’t necessary.
Yeah sure! 
Here’s my local project (w/o neopixel lib copied):
And my cloud project:
I can copy/paste any files (except constants.h) between local/cloud and project will compile properly.
Ah yes. Thanks. I was thinking for the case of library code on github where there isn’t such an easy opportunity to tweak files like that since the code has to be the same locally or in the cloud.
This is a nice work-around. Maybe having a more descriptive name would be good before this gets too ingrained?
I would suggest something like “WEB_IDE” instead of “PARTICLE_CLOUD” for the macro.
Yeah, I was thinking CLOUD_IDE. But I think it could be useful to have constants for the particle CLI and Atom-based Particle Dev. But then with Particle Dev, you have cloud compile, and in the future there will be local compile. And then there’s also an option for a stand-alone toolchain, too, right? Are there differences enough between these different possible build chains to be worth defining some common constants for them all?
/* web IDE build.particle.io */
PARTICLE_CLOUD_WEB
/* Atom IDE, compiling in the cloud */
PARTICLE_CLOUD_DEV
/* particle cli, compiling in the cloud */
PARTICLE_CLOUD_CLI
/* Atom IDE, compiling with local tools */
PARTICLE_LOCAL_DEV
/* particle cli, compiling with local tools */
PARTICLE_LOCAL_CLI
/* manual build with local tools */
PARTICLE_LOCAL_STANDALONE
Too much to worry about?
Dev and CLI use the same API endpoint so only cases you would want to cover are: Build IDE (web), Dev/CLI and using local build tools.
Similarly, if you create your own header called “Arduino.h”, you can define many of the missing Arduino-defined macros (BitWrite(), abs(), PI…, ) as well as include Particle’s “application.h”, making it a bit easier to share code between both envs.
If you are using the Web UI and .ino files, you can also key off of
#if defined(SPARK_CORE)
In addition, you may find the following useful
#if defined(SPARK)
#if defined(PLATFORM_ID)
#if (PLATFORM_ID == 0)
//Core
#elif (PLATFORM_ID == 6)
//Photon
#endif
#endif //PLATFORM_ID
#endif //SPARK
Here’s an example of what’s in my Arduino.h:
#ifndef _ARDUINO_H_
#define _ARDUINO_H_
/*
* Arduino compatability shim for Particle applications and libraries
*
* 2015, John Plocher
* Released to the public domain
*
* Leverage the normal include <Arduino.h> mechanism to do the right thing.
*
* The "right thing" means
* assume the caller wants an Arduino/wiring-like environment,
* define the things that are defined for 'duino users in the official IDE env
* don't require libs and apps to sprinkle ifdef PARTICLE or SPARK directives
*/
#include <application.h>
#define PI 3.1415926535897932384626433832795
#define HALF_PI 1.5707963267948966192313216916398
#define TWO_PI 6.283185307179586476925286766559
#define DEG_TO_RAD 0.017453292519943295769236907684886
#define RAD_TO_DEG 57.295779513082320876798154814105
#define EULER 2.718281828459045235360287471352
#define abs(x) ((x)>0?(x):-(x))
#define round(x) ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
#define radians(deg) ((deg)*DEG_TO_RAD)
#define degrees(rad) ((rad)*RAD_TO_DEG)
#define sq(x) ((x)*(x))
#define lowByte(w) ((uint8_t) ((w) & 0xff))
#define highByte(w) ((uint8_t) ((w) >> 8))
#define bitRead(value, bit) (((value) >> (bit)) & 0x01)
#define bitSet(value, bit) ((value) |= (1UL << (bit)))
#define bitClear(value, bit) ((value) &= ~(1UL << (bit)))
#define bitWrite(value, bit, bitvalue) (bitvalue ? bitSet(value, bit) : bitClear(value, bit))
#endifI just wanted to point out that using #define to define abs, min, max, round etc. has been problematic with C++ libraries that already define these names as methods, so this is not the best long-term approach to adding compatibility. The std::max and std::min redefines have caused the most confusion and problems for users but all the others are possible too.
In the general case, I agree.
But, in the specific case of making it easy for people to migrate from the Arduino world, these ARE implemented as #defines in the Arduino IDE, and already could cause these problems, so there is no effective downside.
What’s worse?
My money is on the former.
Fix that and you have happy Photon users that might (low probability…) run into the second problem. Ignore the first because of the second, and (high probability) you won’t have happy users…
There’s always
#ifdef min
#undef min
#endif
-John
In terms of using libraries, I’ve noticed there is no standard format. Some put their classes and headers in a firmware directory, some don’t. Some put it in a directory with the same name as the library, some don’t. This gets really confusing on anything but the Cloud IDE, because there it seems standardized and it adds the header locations for you.
We’re working on implementing a new version of libraries which would be compatible with Arduino 1.5 Library specification. We’ll also provide tools for library creators to easily migrate to the new version. The work in firmware you’ve seen is a part of it 
This is eating at me lately, draining it be.