Suggestion: Web IDE preprocsssor for Mesh.publish()


#1

Hi!

Just a suggestion based on a weird experience I had:

I was doing several things at once, and ended up getting compiler errors about Mesh not being defined in this scope.

After an embarsssingly long time trying to figure out how I broke that, turned out my not so clever re-use of some tabs had a Photon selected as destination (because I’d recently updated the photon) and it gave the error because the Photon has no concept of that.

All is well and solved, but it might save someone else a lot of confusion if in this instance there was a warning before the compiler’s unhelpful vomit that basically said “Hey? This has mesh code calls but you’re trying to flash a photon. You sure about that?” So that they could more quickly realize their mistake and not think they broke core firmware features :slight_smile: Like many things, it’s a 2-second duh fix once you’re aware of the problem.

Just an idea, from a less sophisticated user who still loves the web IDE (trying the Code plugin, I swear!)

.p


#2

Another possible UX solution here might be to “remember” the last device a sketch/app was flashed to and default back to that when you switch apps in the IDE. That would also save some time in other situations, but also has some possible undesired effects.


#3

I like that idea, but it is made more complicated because there are multiple environments from which you could be building software. For example, I sometimes switch between the Cloud IDE and the new Particle Workbench. And there are also tools like po.

I do wonder if there might be a way to toss a #pragma or something in the Mesh libraries that could throw a more meaningful error if the device you’re currently compiling for isn’t Mesh-capable, though?


#4

Hmm, I think that discussion is somewhat mute.

The error message is quite clear IMO.
We already know when we try to use WiFi on a non-WiFi-enabled device or Cellular on a non-Cellular-enabled device the compiler will complaint about the fact that this radio is not known to it with exactly the same message.
It would also complain with exactly the same message when you try to refer to a class or variable that is not known to your project.

It’s just like talking to a human. When you tell them a story about - lets say - Tom and your counterpart can’t make any sense of what you are saying, instead of expecting the other to know which Tom you mean you could try to create a common frame of reference by specifying what you mean or double-check with your opposite whether or not they know that specific Tom.


#5

Oh yeah, now that I think about it, my suggestion about a #pragma doesn’t make sense. Because the problem is that the build system already knows not to include the Mesh libraries when building for a Photon, so that pragma would never be seen (thus the “Mesh not defined” error in the first place).


#6

I’ve been there before, mostly in the Particle Dev, where after you change devices the fw version reverts to the default.

To be honest with you, my life got SO much better when I started exclusively compiling with the particle cli. You are being explicit with the device and version, so really nothing hidden. And it’s super simple: particle compile [electron | photon] --target [fw_version (eg "0.6.4")]

I’ve since gone a little farther and use the local compiler toolchain with VS-Code, but that also requires configuration of the project (I only use it because I like the extra detail it sometimes gives me when things go wrong).

Give the Particle CLI compilation method a try - I think you’ll find that you will adjust quickly and be less frustrated!


#7

BTW, in Web IDE you see in the bottom right corner which device you are currently targeting.


#8

I recognize that the flash target information is available in several places, and it’s now highly unlikely I’ll ever make this mistake again. The possibility of fixing it isn’t what I was focused on, just the ease of making the problem visible.

I disagree that the compiler messaging is adequate to understand that this is the problem, especially given that the Web IDE is primarily geared toward the quick start, less technical people. Given that I never include or instantiate Mesh, it’s confusing to know why it suddenly can’t find it.

I’m in progress in switching to CLI/workbench but I think one of the differentiators of the Particle platform, and one I have evangelized on, is the sheer accessibility to noobs, and this suggestion is geared toward that, in the hopes that the platform maintains its easy to learn, grows in complexity as you learn model.

I also enjoy the flexibility of a cloud IDE for periodic updates in whatever context I may be in, and being able to patch code and update a remote device from a hotel room via wireless flashing is one of the core value propositions for the product line.

Obviously this isn’t a critical issue, hence “suggestion” in the title, but I could probably accomplish a simple “Hey Dummy” warning with a browser extension that sniffs the content in the web IDE.

I think as you scale the product line to different boards with different internal firmware capabilities, and hopefully people like myself build out a larger fleet, building that simple goof check into the web IDE would benefit a lot of people. Maybe I am uniquely distracted.