Please remember to wait with this, until #7925 is merged.

disable develhelp for all examples

Why? This would disable all assertions, ps, extra checks, ...

@kaspar030 IMHO the examples are more like productive applications, hence DEVELHELP would be off by default, but can still be enabled (e.g. in CI) when needed. On the other hand, for tests as in #8080 DEVELHELP is on by default, because those are tests and assertions etc should be checked.

IMHO the examples are more like productive applications, hence DEVELHELP would be off by default

Why? What's there to gain?

Why? What's there to gain?

Could ask the same the other way around 😉 Or: what exactly is lost by disabling DEVELHELP for examples, it can be enabled (as said) easily e.g. for CI builds and any prevalent issues should be discovered/pop up compiling/running the tests not examples.

If the examples (should) target RIOT beginners and users (not only developers), I don't see the point of having DEVELHELP enabled by default. It increased binary sizes and may through rather pedantic compiler errors (not necessarily causing any runtime issues) which only irritate inexperienced users and frustrate them right at the start.

First thing that comes to mind is the shorted output of the ps command. I think that the expanded output including the process names gives some valuable insight in the threading of RIOT for newcomers. I dont know if it can be enabled by a separate flag, but I think that is one of the valuable "features" of enabling DEVELHELP.

First thing that comes to mind is the shorted output of the ps command.

Agreed, but then IMHO it would be better to change/enhance the default output of the ps command, for instance by having thread names - while something like stack size and so on is still only available with DEVELHELP.

I prefer DEVELHELP to be activated for most examples as well. Yes, examples can be seen as production code, but on the other hand they can also be seen as examples which help newcomers understand RIOT. As they should be as helpful as possible and that would be lost by deactivating DEVELHELP

First thing that comes to mind is the shorted output of the ps command.

Agreed, but then IMHO it would be better to change/enhance the default output of the ps command, for instance by having thread names - while something like stack size and so on is still only available with DEVELHELP.

Uhmm... Thread names are the epitome of a development helper. They serve no other purpose other than giving the developer a hint which thread is which. So activating them for anything else but DEVELHELP seems like a waste of memory to me, when it comes to production systems.

Okay, to ease things (for now) I let DEVELHELP state unchanged for examples, i.e., leave as is: on for some off for other examples. We may change this later on.

Regarding ps output: what good is this command without thread names to anyone (user or developer)? Or what's its purpose for non-developers and its limited output (without DEVELHELP) anyway? But that is another discussion, unrelated here.

TL;DR: I revert my changes, and leave state of DEVELHELP (on/off) for examples as is now.

Regarding ps output: what good is this command without thread names to anyone (user or developer)? Or what's its purpose for non-developers and its limited output (without DEVELHELP) anyway? But that is another discussion, unrelated here.

Seeing what state a thread is in. Very helpful if you run into a deadlock ;-).

Also not having no names doesn't mean you can't identify which thread is which (there is still the PID). It's just easier with names.

I agree with Martine and Kaspar, for newcomers the DEVELHELP switch should be on by default.

Regarding ps without DEVELHELP:
I sometimes call the ps function directly from GDB when I run into a hardfault or other bad situation, it's better to get some output without thread names than nothing, though it was more useful before the RIOT support was updated for openocd (http://openocd.zylin.com/#/c/4256/, please try it and add your code reviews to their tracker so it can be merged into master!), now the info threads command provides some of the same information.

GNRC embargo is lifted. When this is ACK'd it may be merged

rebased and squashed

@cladmi adapted comment

Fixing and amending commit in the same one, its harder to read… (just kidding :D)