Hello all,
For the past few weeks I have been hinting at a proposal for an updated
NimBLE host API. It has taken a bit longer than I expected, but I think
the proposal is finally ready to unleash on the dev list. I have not
pushed any changes to master or develop; I wanted to give the community
Hi all,
I checked in the first take of the socket interface.
I did change it a bit from my original email. Notably; the user of the socket
will not allocate the memory for socket. This would be done by the system.
The API uses callbacks instead of struct os_event automatically.
As discussed
All great comments, and good to have a discussion of this.
Here’s why I brought it up.
In going through the bletiny sample app, there are almost no comments that
describe what is going on, and why. In slinky there are a few more, but they
are still fairly sparse. For someone coming into this
Hey,
On 11 Jul 2016, at 12:45, Christopher Collins wrote:
On Mon, Jul 11, 2016 at 11:01:45AM -0700, Sterling Hughes wrote:
As Will points out, I’m OK if APIs are documented outside of the
code
itself. For the OS, I went through and added a bunch of Doxygen
comments, but the function calls
On Mon, Jul 11, 2016 at 11:01:45AM -0700, Sterling Hughes wrote:
> As Will points out, I’m OK if APIs are documented outside of the code
> itself. For the OS, I went through and added a bunch of Doxygen
> comments, but the function calls and their variants were fairly
> simple. Function calls
As Will points out, I’m OK if APIs are documented outside of the code
itself. For the OS, I went through and added a bunch of Doxygen
comments, but the function calls and their variants were fairly simple.
Function calls that take big enums as a parameter can be very lengthy to
document with
On Mon, Jul 11, 2016 at 08:51:10AM -0700, will sanfilippo wrote:
> I have mixed feelings about comments. In my view, it is OK to not
> comment the code heavily if there is a document that explains the
> code. Either is sufficient in my opinion. Of course, keeping to
> Doxygen style comments for
I have mixed feelings about comments. In my view, it is OK to not comment the
code heavily if there is a document that explains the code. Either is
sufficient in my opinion. Of course, keeping to Doxygen style comments for
public API is a good idea. Do we run doxygen automatically and can we
And just in case you think commenting your code is boring and pointless, here’s
a fun reason to do it … you just never know. The code that took the USA to the
moon was just posted on GitHub, and some of the code comments are pure gold!
