Does anyone know if this is something systemic with the cloud compiler yet? I’m still getting this behavior. I’ve ensured my version of Particle Dev / Atom is updated, but I’m not sure what else to check to make sure everything is up-to-date. Any new insight would be much appreciated. Thanks in advance.
1 Like
What is the error that you are seeing?
“Compiler timed out or encountered an error”
just started working with the offline ide. getting the error (compiler timed out or encountered an error) all the time.
i was getting this error even on an empty project, did not make any sense, no errors, see rvess, till i discovered that all projects visible in particle-atom-dev are compiled, not only the one in focus. selecting an old target (0.5.2) showed the error and then i realised it was another project. closed the other project, switch the target back, and it would compile and give “success!”.
i do not think the offline ide is workable this way.
(which is really too bad since the online ide is also not a serious development platform without source control)
I’m also still getting this behavior randomly and it does make it nearly impossible to use Particle Dev effectively. And it’s definitely impossible for debugging.
I’m curious why this issue is not more prominent on the forum. Maybe it’s only happening to a small number of users. @boddeke what platform are you on? I’m on Mac OS X Sierra.
Good insight on having the other projects open and having it compile all of them. Did not know that.
I’m also having this problem, every time. I installed Particle Dev earlier today and have yet to see it compile successfully. It says there’s an error (timed out or encountered an error), but if you click on the error message it brings up a box that says “There were no compile errors”.
I’m also on Mac OS Sierra. Very frustrating.
I can only assume an awful lot of people are subjecting themselves to the WebIDE, using the CLI and an editor of their choice or perhapse VS Code.
The problem is the error parsing script. Take a very simple ino:
#include "iammissing.h"
setup(){};
loop(){};
if you compile for firmware 0.53 all is good: you get a warning about the missing header file.
however if you compile for 0.62 you get that error about timing out or error and if you want to see the error there is none.
I assume there are different compiler toolchains for different firmware versions and they have slightly different output formatting. But the script to parse the output does not handle it different and gets stuck. As a first solution it would be best to get the raw compiler output just as the binary is transmitted as a file to your local dir. So we could parse it with our human brain…
Michael
Please bring this about me, I still do not understand about this.
FOLLOWUP: I’m still getting timeout errors, but sometimes it works.
OK, I think I was misunderstanding how the libraries work in Atom. Or there’s a bug.
The key is to not have any local libraries. If I do an “Add to current project” for all the libraries in my code, it compiles cleanly under 0.5.3 AND 0.6.2 AS LONG AS THERE ARE NO LOCAL LIBRARIES.
Previously I did “Copy to current project”, which puts them under ~/Particle/projects/<projectName/lib/ while the compiler seems to be looking for them under ~/Particle/projects/<projectName/src instead. I didn’t try moving them to where the compiler thinks they are, but will in the future when I need to make changes to a library.
If you have any libraries under ~/Particle/projects/<projectName/lib/ then it seems it won’t compile. Once you remove them, it does.
When you create a new project this is what the IDE tells you:
Projects with external libraries
If your project includes a library that has not been registered in the Particle libraries system, you should create a new folder named
/lib/<libraryname>/srcunder/<project dir>and add the.hand.cppfiles for your library there. All contents of the/libfolder and subfolders will also be sent to the Cloud for compilation.
This implies that "copy to" is behaving as intended although why so many folders and so much nesting is required I do not know. There is without doubt a bug here, its been well documented for some time, not so long ago one of the several threads that mentions this issue included mention of an IDE update that fixes it, it was supposedly "due next week" but that next week is now about 2 weeks in the past....
When I tried to compile with 0.5.3 the first few times I got an error saying it couldn’t find the .h file for one of my libraries under projects/<projectName/src/, which implies it is looking in the wrong directory. Maybe the problem is that it’s not copying the lib directory at all.
I have found a temp solution to the problem. I open a separate shell window, then cd to the directory holding my source. There I type “particle compile photon” then i can see the error output… But You have to save the files first.
Why do I do this ? Because the Web IDE keeps overwriting my source files occasionally when changing between several source-files.
I found that I could successfully compile and run my code if I did the following after using the “Copy to current project” option:
-
Zip the Examples folder. (atom can open .zip files)
-
Delete the lib/library_name/src/library_name.h folder, including it’s contents.
The above folder contains a file that points to the libraries .h file that is located in the libraries src folder. The file contents are …/library_name.h
There may be more the one Example folder & lib/library_name/src/library_name.h folder. You will need do this for all of them.
This particular issue has become a real pain point, at least for me. It’s now down to the point if I misspell a variable name, I get this error instead of something a bit more helpful. I don’t recall this phenom in the past.
I tried compiling with the CLI while at the top level of the project folder, but got errors about my included libraries. I then moved to the src folder and attempted a compile, but again, got errors related to the libraries. I wish I were a bit more experienced with the whole development environment, but alas, I’m not. I added my libraries to my particle account months ago and haven’t had any issues related to them, but I’ve never tried a CLI compile. I trust the library files don’t need to be in each project when doing a CLI compile.
I guess you got the “included libraries” as copies in your lib folder rather than just using dependencies (which I prefere as long I don’t really need to tweak the lib).
With copied libs you need to remove the “examples” folder and get rid of the <libName> folder inside the src for that lib, which only contains header files with #include "../header.h" statements since these cause troubles too.
If you never worked with dependencies (which work for Dev and CLI alike) you just open a console in the place where your project.properties file lives and execute
particle library add <libraryName>
You can even just use parts of the name, but if you can’t remember the name you can also use
particle library search <someSearchTerm>
Hi @ScruffR, I do have the libraries listed as dependencies and do not have them in my project lib directory (copies). I’ve routinely developed for many months in this fashion using Particle Dev without issue. In an attempt to see explicitly what’s causing the compile error, I thought I’d try a CLI compile but got the surprising library errors.
What directory (project root or project src) should I be in when I do the compile or doesn’t it matter?
Can you post the error messages?
If Dev built the project CLI will do it just fine too, without alteration.
Are you executing
particle compile <platform> .
from the directory where the project.properties file lives.
@ScruffR well…it appears to be OK now. I had an error in my switch() statement that seems to have confounded the most recent compile. If I experience another error, I’ll ping you. BTW, I was attempting to reference the source .ino file and that may have been the issue. When I used your syntax (with “Electron” and simply a “.”), it seemed to be fine. Perhaps that was the root cause of my errors.
Yup, if you explicitly state the .ino file only this will be built. But if you reference the project folder (which the single dot does when you are sat in that directory) then the standard project hierarchy will be used to build.