Compiler errors link to blank file

[jtzemp]

Here's some context in the community: https://community.particle.io/t/multiple-folders-in-the-dev-ide-compile-errors-go-to-blank-file/18876

When in a project with subfolders. If there is a compiler error, the message box links to the correct line number but to a file that doesn't exist. It opens up an empty file.

This is how I and Joe4455 in the forum experienced it. It might not actually be a subfolder issue, but might be something else related to how the compiler handles files.

[ScruffR]

Since the directory structure gets flattend for upload, the compiler has no way of telling where the original file would be to find in the "unflattened" structure - as a 2D creature could not comprehend or really talk about a 3D world ;-)

[jtzemp]

True dat, but I'm betting there are some workarounds. A simple, yet naive approach would just be to try and match the names. Obviously there would be collisions if there are files with the same name. Another could be for each compile request to build an internal (in memory) representation of the tree and prefix duplicated filenames in the API calls. When the files are sent to the API, use the internal, prefixed name (HTTP posting a file doesn't actually care what the file name is on the local computer, you can tell it any name you want) and do a reverse lookup on the actual file if errors do come back. It's a bit of a kludge, but possible.

There might be other options as well. Those two are kinda kludgey, but @suda is one smart fellow. I'm sure he can figure something out. :smile:

I suppose a workaround from a user's perspective could be to create subdirs and spark.ignore their contents and symlink a file at the top level to all the files in the subdir(s). That is like using a chainsaw for a bandage, though. :smile:

[suda]

Yeah the root of the problem is compile service flattening the dir. We could do some file searching but it may still fail if you have more than one file with the same name. I think it would be best to fix it in CS as we want to support nested dirs anyway.

[dmiddlecamp]

I think the cli preserves directory structure for builds on the farm, no?

Sent from my iPhone

On Jan 8, 2016, at 6:39 AM, Wojtek Siudzinski notifications@github.com wrote:

Yeah the root of the problem is compile service flattening the dir. We could do some file searching but it may still fail if you have more than one file with the same name. I think it would be best to fix it in CS as we want to support nested dirs anyway.

— Reply to this email directly or view it on GitHub.

[suda]

CLI and Dev send files with their dir names but compile server squishes them into single dir. So neither CLI nor Dev support nested dirs:

If I would use #include "neopixel.h" this would succeed but any errors in this file would be pointing to a file in a root dir instead of neopixel subdirectory.

[dmiddlecamp]

hm, weird! looks like something we should fix cloud side, totally

[N6UDP]

Is there a issue tracking the cloud side of this as particle dev isn't the place the fix is going to be made? This is only driving me slightly crazy :)

[suda]

This one is on our short list :) CLI already supports nested dirs and Dev will be next!

As for tracking cloud issues, we have and internal JIRA where such tickets are always added if they were raised on the client side.

[N6UDP]

Makes sense -- I've seen some projects track service-side closed-source bits on github issues/similar (under docs or empty repos) before so I figured I'd quickly poke the thread.

[jenschr]

Any progress on getting Particle Dev to support nested dirs? I's a little annoying to use CLI all the time :)

[suda]

@jenschr you should be able to compile nested dirs since v0.1.18. Are you still having issues with this?

[jenschr]

I just downloaded a fresh build of Particle Dev some weeks ago and it says that it is based on Atom 1.8.0 when I select Atom > About Particle Dev. How can I view the Particle Dev version number?

[suda]

Standalone Particle Dev App 1.8.0 is bundled with Particle Dev v0.1.20 (currently latest version). You can always check the package version in Settings -> Packages by searching for particle-dev. Can you share the code that causes the issues?

[jenschr]

Sure: https://dl.dropboxusercontent.com/u/20621/ScreenTest.zip Based on this thread in the forums https://community.particle.io/t/ra8875-library-working-on-photon/30464/3 I've tried setting this up as a "Project" also. It works perfectly via CLI using "particle flash 23My-device-id3233"

[jaza-tom]

Here is a video I uploaded showing the problem.... note it is not a problem with Particle-CLI from my testing... Particle-CLI still reports the correct file names (sans parent folder) and correct line numbers where the error is in the code. Particle Dev totally craps the bed, however.

https://youtu.be/UdJqlLfv-rQ

[ScruffR]

@suda, maybe this should be reopened or referenced by a new issue

[suda]

@jaza-tom / @jenschr can you try the latest Particle Dev package in Atom? This issue should be fixed there.

[jaza-tom]

Same problem