When did that happen?! Has it been there since the v0.2.0 release? Can we use that to get a sense of how much memory/RAM our code is using? Is there a spark-cli equivalent?
1 Like
Very interesting. I tried to click it, but I am getting 404s. Also getting 404s when trying to build or flash. Must be a big update in the works!
It’s already in the API for a long time and Spark-cli has it as spark cloud compile dir I use it all the time
So I guess it’s gonna be rolled out for the web ide 
1 Like
I tried using the compile command, but I just received a “compile failed” error, even though the code compiles fine in the web IDE. I opted to go to bed than down that rabbit hole late at night!
You can paste the error and I’ll take a look. Shouldn’t be too tough! I compiled all the SD library using Spark-cli
1 Like
When I click the “cloud” on a freshly verified program in the web IDE, nothing happens. No download, no error.
Hey @peekay123,
The firmware binary download link isn’t working for you? What’s your browser / OS combination again?
Thanks,
David
apparently it doesn’t work for almost everyone?
Good to know! I’ll pass that along.
Thanks,
David
The code is being verified but not sure what caused it not to be downloaded
Hmm… I wonder if it isn’t the result of the SSL certificate weirdness we’re seeing right now. Can you try opening “https://api.spark.io” in your browser and see if you get a certificate error?
Thanks,
David
I’m on Windows 7 Chrome. No issues i guess. Since i get:
{
"code": 400,
"error": "invalid_request",
"error_description": "The access token was not found"
}
1 Like
Hey guys, I just confirmed that this is not working correctly in Firefox.
The JS plugin we're using to serve up the downloads does some fanciness with iframes in the background so you don't get redirected to a different page out of the IDE when downloading--clearly there are cross-browser issues with this tooling. Will investigate and fix.
Just happened a couple days ago; Friday with the v0.2.1 release.
No. I think you need the .elf file for that. We'll be reviving that task of showing the output of arm-none-eabi-size --format=berkeley core-firmware.elf to the IDE given all of the recent frustrations of viewing available RAM though.
Yes. Given a file called t.cpp like this:
#include "application.h"
void setup() {}
void loop() {}
The CLI command spark cloud compile t.cpp, should return something like this:
Including:
t.cpp
attempting to compile firmware
pushing file: t.cpp
grabbing binary from: https://api.spark.io/v1/binaries/53557a4f359294de24444706
saved firmware to .../firmware_1398110796553.bin
Compiled firmware downloaded.
3 Likes
This appears to be working again. The issue seems to have been resolved via the SSL changes made yesterday and summarized here. The impact of these SSL (and heartbleed) issues were broader than expected. Sorry for the convenience folks!
Tested working but we might want to work on the .bin file name when downloading 
1 Like
@jgoggins Have you taken a look at this, or is it somewhere on a backlog? It'd be really neat if the file name of the .bin file could resemble the complementary name of the sketch.
Stretch goal:
Would it perhaps be possible to create some sort of automatic version system? I'd image something like a counter that increases with every change you make to your code (after having flashed/downloaded it). This way, the file name would give you an idea of how many versions back it goes. If possible, make the version user editable.
I know it's a long shot, but I figured that if an occasion might arise in which you find yourself having nothing better to to, you might give it a shot. (Like that'll ever happen any time soon :p). Either way, thanks in advance!
2 Likes
Hi @Moors7,
Definitely a good idea! I threw that task in the log for Joe / the web team.
Thanks,
David
1 Like
@Moors7 thanks for the suggestion, great idea, one dirt simple way to tackle [most of] what your thinking would be to simply tack on a time-stamp. So, for a sketch called “my-killer-app”, a listing of the user’s download directory after downloading 3 binaries for the same app would look like:
my-killer-app-2014-08-04-12-03-11.bin
my-killer-app-2014-08-05-22-55-18.bin
my-killer-app-2014-08-06-15-10-28.bin
...
aka the-app-name-year-month-day-hour-minute-second.bin
I’d rather not add a version number at the moment because the change would be more involved/complex/take-longer.
I’ve got this spec above added to our backlog, let me know if you have any ideas for tweaks to this.
Thanks!
-joe
That’d be a great start! Versions might be something for the far future.
If you absolutely want a suggestion: make the timestamps optional (toggle button next to the download button perhaps?)
The reason I wanted the versions was because my download folder would get stacked with firmware (x).bin copies. Having to rename them every time I flashed over CLI would get rather irritating (only because I’m lazy…) That’s why I thought I’d be nice if it could just increment with each new download. In that case I’d only have to edit a single number in my CLI, which is bearable ;p
The timestamps would be really neat for all those organised people out there, which love to have different versions of everything. I, however, am looking for the least type intensive way to flash my Spark, meaning that the timestamps would only add to the troubles. (Yeah, first world problems indeed…)
Either way, thanks in advance!
Ah, I appreciate that extra context behind this suggestion. Can’t you get around the typing by hitting tab? Most shells will do file completion for you if you get the first part right. Is there a way to enable this for your shell?
In any case, maybe it’d be easier and and preferred to just keep a counter like you suggested aka my-killer-app-1.bin, ...-2.bin, etc, I’m leaning toward this direction now if folks want to know the time something was downloaded, they can get it with the last mod time of the file I suppose, it doesn’t need to be in the filename…
1 Like