assert(), faulting traps etc

[marko kiiskila <ma...@runtime.io>]

Hi,

what I want to have is better debugging when things go wrong.

And for this, I want assert() that prints out on console (if present)
and also default trap handler printing out salient system state
(we can also make this output part of corefile and/or system log).

Also I want the system to have 2 different types of assert() calls.
One that is only checked when doing debug builds, and another
one which is always checked. I was thinking
ASSERT_DEBUG() and ASSERT(), respectively.

What I’m wondering is where to put header files like this?
hw/hal egg is present always, but I’m not sure that is the right spot
to place this in.
What do you guys think about sys/include?

And 2nd (related) topic:
At the moment there is libs/console/full and libs/console/stub.
What kind of mechanism should we have for picking between
these two implementation? What I’d need is a way for a builder
of project to pick between these, and all eggs in the project
to have include the header file for the right implementation.

But I also want to be able to specify within egg definition that
the egg will make calls to console_printf(). Egg itself does not
care which one of the implementations gets used.

Is there a way to do this kind of thing yet?

—
M

Re: assert(), faulting traps etc

[Greg Stein <gs...@gmail.com>]

On Tue, Oct 27, 2015 at 1:14 PM, marko kiiskila <ma...@runtime.io> wrote:

>
> > On Oct 27, 2015, at 8:18 AM, Greg Stein <gs...@gmail.com> wrote:
> >
> > IMO, if new functions are going to be introduced, then put them into a
> > namespace. ... "ASSERT" is who-knows-what. "MYNEWT_ASSERT" is clearly
> part
> > of the mynewt OS.
> >
> > That said, it is ugly, so how about finding a PREFIX that can be set all
> > our custom symbols aside, and point people into the right direction to
> look
> > them up?
> >
> > "MN_" is an obvious candidate.
> >
> > Are there others, that might play on the "minute" or "mynewt" words?
>
> All true, naming is very important. However, assert() is so close to libc
> version of it,
> so I thought I’d make an exception ;) But I don’t feel strongly about it.
>

True, along with your note about NDEBUG

Re: assert(), faulting traps etc

[marko kiiskila <ma...@runtime.io>]

> On Oct 27, 2015, at 8:18 AM, Greg Stein <gs...@gmail.com> wrote:
> 
> IMO, if new functions are going to be introduced, then put them into a
> namespace. ... "ASSERT" is who-knows-what. "MYNEWT_ASSERT" is clearly part
> of the mynewt OS.
> 
> That said, it is ugly, so how about finding a PREFIX that can be set all
> our custom symbols aside, and point people into the right direction to look
> them up?
> 
> "MN_" is an obvious candidate.
> 
> Are there others, that might play on the "minute" or "mynewt" words?

All true, naming is very important. However, assert() is so close to libc version of it,
so I thought I’d make an exception ;) But I don’t feel strongly about it.

Re: assert(), faulting traps etc

[Greg Stein <gs...@gmail.com>]

IMO, if new functions are going to be introduced, then put them into a
namespace. ... "ASSERT" is who-knows-what. "MYNEWT_ASSERT" is clearly part
of the mynewt OS.

That said, it is ugly, so how about finding a PREFIX that can be set all
our custom symbols aside, and point people into the right direction to look
them up?

"MN_" is an obvious candidate.

Are there others, that might play on the "minute" or "mynewt" words?

Cheers,
-g


On Tue, Oct 27, 2015 at 9:38 AM, will sanfilippo <wi...@runtime.io> wrote:

> Regarding assert() and assert_debug(). Where would you put the dir “sys”?
> Why not put the definitions in an os include dir? Is that due to
> dependencies you would not want (i.e. os would need console, or something
> like that)? Or that you dont feel like assert belongs in the os?
>
> About the names: I think someone was mentioning that assert normally gets
> defined out if you define NDEBUG. Is that true? If that is the case,
> shouldnt we keep that paradigm? I know we discussed this a bit but I cant
> recall what we decided :-)
>
> Will
>
>
> > On Oct 26, 2015, at 5:36 PM, marko kiiskila <ma...@runtime.io> wrote:
> >
> >>
> >> On Oct 26, 2015, at 5:08 PM, Christopher Collins <ch...@runtime.io>
> wrote:
> >>
> >> On Mon, Oct 26, 2015 at 03:35:12PM -0700, marko kiiskila wrote:
> >>> Hi,
> >>
> >> [...]
> >>
> >>> And 2nd (related) topic:
> >>> At the moment there is libs/console/full and libs/console/stub.
> >>> What kind of mechanism should we have for picking between
> >>> these two implementation? What I’d need is a way for a builder
> >>> of project to pick between these, and all eggs in the project
> >>> to have include the header file for the right implementation.
> >>>
> >>> But I also want to be able to specify within egg definition that
> >>> the egg will make calls to console_printf(). Egg itself does not
> >>> care which one of the implementations gets used.
> >>>
> >>> Is there a way to do this kind of thing yet?
> >>
> >> The newt tool supports the concept of "capabilities" which can address
> >> this requirement.
> > ...
> >> All that said, the capabilities feature isn't actually fully implemented
> >> yet; the above is just how I might expect it to work once it is done :).
> >>
> >> Here are a few more questions that I think need to be answered:
> >>
> >>   * How does the "peripheral" egg include the appropriate console
> >>     header files?  Even if both console eggs have identically named
> >>     header files, newt needs to arrange for the appropriate include
> >>     directory to be passed to the compiler.
> >>
> >>   * What is an easy way to switch between the debug and full
> >>     implementations.  The user should not need to modify the
> >>     myproject.yml file to do this.  Perhaps the "identities" feature
> >>     can be used here.
> >>
> >
> > Thanks, this sounds like a thing that matches my requirement.
> > I’ll have to start filling in these blanks in newt tool then.
> >
> > I think I’ll treat a dependency that comes in a form of capability
> > requirement the same way as I’d treat normal dependency:
> > once an egg is found which implements the capability, it’s include
> > path is passed to compiler.
> >
> > I won’t address the identity thing with this work, but that sounds
> > useful. Depending on whether you’re building a debug version of your
> > project or not, you could pick whether you get console output.
>
>

Re: assert(), faulting traps etc

[marko kiiskila <ma...@runtime.io>]

> On Oct 27, 2015, at 7:38 AM, will sanfilippo <wi...@runtime.io> wrote:
> 
> Regarding assert() and assert_debug(). Where would you put the dir “sys”? Why not put the definitions in an os include dir? Is that due to dependencies you would not want (i.e. os would need console, or something like that)? Or that you dont feel like assert belongs in the os?
> 

I still would prefer to have the ability to build without OS, should the
user so desire. E.g. bootloaders and such. These guys will most likely
want to use HAL for accessing flash and GPIOs. And I could imagine
that HAL will end up having calls to assert().

Having it visible via header file only is ok, but then the implementation
will have to be in a form of an inline function. Therefore I would not
put ASSERT() in os.

> About the names: I think someone was mentioning that assert normally gets defined out if you define NDEBUG. Is that true? If that is the case, shouldnt we keep that paradigm? I know we discussed this a bit but I cant recall what we decided :-)

That knob would be fine. NDEBUG is used widely for this.

Re: assert(), faulting traps etc

[will sanfilippo <wi...@runtime.io>]

Regarding assert() and assert_debug(). Where would you put the dir “sys”? Why not put the definitions in an os include dir? Is that due to dependencies you would not want (i.e. os would need console, or something like that)? Or that you dont feel like assert belongs in the os?

About the names: I think someone was mentioning that assert normally gets defined out if you define NDEBUG. Is that true? If that is the case, shouldnt we keep that paradigm? I know we discussed this a bit but I cant recall what we decided :-)

Will


> On Oct 26, 2015, at 5:36 PM, marko kiiskila <ma...@runtime.io> wrote:
> 
>> 
>> On Oct 26, 2015, at 5:08 PM, Christopher Collins <ch...@runtime.io> wrote:
>> 
>> On Mon, Oct 26, 2015 at 03:35:12PM -0700, marko kiiskila wrote:
>>> Hi,
>> 
>> [...]
>> 
>>> And 2nd (related) topic:
>>> At the moment there is libs/console/full and libs/console/stub.
>>> What kind of mechanism should we have for picking between
>>> these two implementation? What I’d need is a way for a builder
>>> of project to pick between these, and all eggs in the project
>>> to have include the header file for the right implementation.
>>> 
>>> But I also want to be able to specify within egg definition that
>>> the egg will make calls to console_printf(). Egg itself does not
>>> care which one of the implementations gets used.
>>> 
>>> Is there a way to do this kind of thing yet?
>> 
>> The newt tool supports the concept of "capabilities" which can address
>> this requirement.  
> ...
>> All that said, the capabilities feature isn't actually fully implemented
>> yet; the above is just how I might expect it to work once it is done :).
>> 
>> Here are a few more questions that I think need to be answered:
>> 
>>   * How does the "peripheral" egg include the appropriate console
>>     header files?  Even if both console eggs have identically named
>>     header files, newt needs to arrange for the appropriate include
>>     directory to be passed to the compiler.
>> 
>>   * What is an easy way to switch between the debug and full
>>     implementations.  The user should not need to modify the
>>     myproject.yml file to do this.  Perhaps the "identities" feature
>>     can be used here.
>> 
> 
> Thanks, this sounds like a thing that matches my requirement.
> I’ll have to start filling in these blanks in newt tool then.
> 
> I think I’ll treat a dependency that comes in a form of capability
> requirement the same way as I’d treat normal dependency:
> once an egg is found which implements the capability, it’s include
> path is passed to compiler.
> 
> I won’t address the identity thing with this work, but that sounds
> useful. Depending on whether you’re building a debug version of your
> project or not, you could pick whether you get console output.

Re: assert(), faulting traps etc

[marko kiiskila <ma...@runtime.io>]

> On Oct 26, 2015, at 5:08 PM, Christopher Collins <ch...@runtime.io> wrote:
> 
> On Mon, Oct 26, 2015 at 03:35:12PM -0700, marko kiiskila wrote:
>> Hi,
> 
> [...]
> 
>> And 2nd (related) topic:
>> At the moment there is libs/console/full and libs/console/stub.
>> What kind of mechanism should we have for picking between
>> these two implementation? What I’d need is a way for a builder
>> of project to pick between these, and all eggs in the project
>> to have include the header file for the right implementation.
>> 
>> But I also want to be able to specify within egg definition that
>> the egg will make calls to console_printf(). Egg itself does not
>> care which one of the implementations gets used.
>> 
>> Is there a way to do this kind of thing yet?
> 
> The newt tool supports the concept of "capabilities" which can address
> this requirement.  
...
> All that said, the capabilities feature isn't actually fully implemented
> yet; the above is just how I might expect it to work once it is done :).
> 
> Here are a few more questions that I think need to be answered:
> 
>    * How does the "peripheral" egg include the appropriate console
>      header files?  Even if both console eggs have identically named
>      header files, newt needs to arrange for the appropriate include
>      directory to be passed to the compiler.
> 
>    * What is an easy way to switch between the debug and full
>      implementations.  The user should not need to modify the
>      myproject.yml file to do this.  Perhaps the "identities" feature
>      can be used here.
> 

Thanks, this sounds like a thing that matches my requirement.
I’ll have to start filling in these blanks in newt tool then.

I think I’ll treat a dependency that comes in a form of capability
requirement the same way as I’d treat normal dependency:
once an egg is found which implements the capability, it’s include
path is passed to compiler.

I won’t address the identity thing with this work, but that sounds
useful. Depending on whether you’re building a debug version of your
project or not, you could pick whether you get console output.

Re: assert(), faulting traps etc

[Christopher Collins <ch...@runtime.io>]

On Mon, Oct 26, 2015 at 03:35:12PM -0700, marko kiiskila wrote:
> Hi,

[...]

> And 2nd (related) topic:
> At the moment there is libs/console/full and libs/console/stub.
> What kind of mechanism should we have for picking between
> these two implementation? What I’d need is a way for a builder
> of project to pick between these, and all eggs in the project
> to have include the header file for the right implementation.
> 
> But I also want to be able to specify within egg definition that
> the egg will make calls to console_printf(). Egg itself does not
> care which one of the implementations gets used.
> 
> Is there a way to do this kind of thing yet?

The newt tool supports the concept of "capabilities" which can address
this requirement.  There are two ways to express a dependency in an
egg's yml file:
    * Simple dependencies (egg.deps)
    * Required capabilities (egg.req_caps)

If egg X has a simple dependency on egg Y, the newt tool gives X access
to Y's include directories, and it ensures that Y gets compiled and linked
into the final product when the target is built.

Capabilities work a bit differently.  Whereas a simple dependency
expresses a relationship to a specific egg, a required capability
expresses a relationship to an *interface*.  Many different eggs can
expose the same capability (interface), while having different
implementations.  Furthermore, the egg which requires the capability
doesn't actually have to "know" which implementation it is being linked
with.  All that is required is that: a) the egg indicates that it
requires a particular capability, and b) some other egg pulled in by the
build process indicates that it supports that capability.

Below is an example of how the console feature might be handled.  In
this example:
    * There are two console eggs (stub and full)
    * The "peripheral" egg requires the console capability
    * The "myproject" project depends on a concrete console implementation.

    <libs/console/full/egg.yml>
        egg.name: "libs/console/full"
        egg.caps: console

    <libs/console/stub/egg.yml>
        egg.name: "libs/console/stub"
        egg.caps: console

    <libs/peripheral/egg.yml>
        egg.req_caps: console

    <project/myproject/myproject.yml>
        project.eggs:
            - libs/peripheral
            - libs/console/full

All that said, the capabilities feature isn't actually fully implemented
yet; the above is just how I might expect it to work once it is done :).

Here are a few more questions that I think need to be answered:

    * How does the "peripheral" egg include the appropriate console
      header files?  Even if both console eggs have identically named
      header files, newt needs to arrange for the appropriate include
      directory to be passed to the compiler.

    * What is an easy way to switch between the debug and full
      implementations.  The user should not need to modify the
      myproject.yml file to do this.  Perhaps the "identities" feature
      can be used here.

Chris