Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md #2399

Closed
wants to merge 1 commit into from
Closed

Update README.md #2399

wants to merge 1 commit into from

Conversation

nailujx86
Copy link

@nailujx86 nailujx86 commented Jun 14, 2018

Fixes no issue.

Make sure all boxes are checked (add x inside the brackets) when you submit your contribution, remove this sentence before doing so.

  • This PR is for the dev branch rather than for master.
  • This PR is compliant with the other contributing guidelines as well (if not, please describe why).
  • I have thoroughly tested my contribution.
  • The code changes are reflected in the documentation at docs/en/*.

<Description of and rationale behind this PR>
Updated the percentage of C-Code used in the firmware.

Updated the percentage of C-Code used in the firmware.
@TerryE
Copy link
Collaborator

TerryE commented Jun 14, 2018

@nailujx86 Julian, why make this change? I am not sure why the original overview left out 1.9% as non-C what is this? the Makefiles? The loader files?

I've never really bothered reading the lede to the README before, but it is a misleading summary.

  • All of the source in the firmware is C, and the small amount of assembler is embedded in C sources using the asm() directive. We don't use any other high level language in the firmware (though we do have some host-side python). Therefore a simpler and better summary would be to say that the firmware is written in C and leave out any 98.x% qualification.

  • We mention eLua and the original fork came from eLua but we've ended up ripping out most of the eLua stuff over time, with the exception of ROTables and the ECG which is a small % of the Lua source. In terms of run-time efficiencies and RAM saving, my LCD and LTR patch have a higher impact and have more lines of code than the eLua residues.

  • In terms of lines of code, the NodeMCU code-base is as large as the SDK, so calling it a thin veneer is stretching this a bit (forgive the pun).

Notwithstanding this, and even if we end up not choosing this PR, I would still support your taking a critical look at the source and documentation. For example, my developer FAQ could really do with a critical review from the PoV of a new developer coming to Lua development on ESP8266s -- what makes sense; what is confusing; what is missing and I would welcome this sort of constructive discussion. So thanks.

@marcelstoer
Copy link
Member

I am not sure why the original overview left out 1.9% as non-C what is this? the Makefiles? The loader files?

It's just what GitHub reports if you click that color bar (which in our case isn't that colored at all).
screen shot 2018-06-15 at 13 58 27

@TerryE
Copy link
Collaborator

TerryE commented Jun 15, 2018

Thanks @marcelstoer, but this is also misleading as the Lua is the Lua examples which are not part of the firmware, and the Python is the host-end esptool.py. Not sure where the C++ is as we don't have any .cpp files in the app, though some of the headers are "bilingual" in that they are designed to be included in C++ source as sell as C and may have been therefore classified as C++; so the real % is 100% C.

@marcelstoer
Copy link
Member

Well, that whole sentence isn't particularly helpful

The code repository consists of 98.6% C-code that glues the thin Lua veneer to the SDK.

@TerryE
Copy link
Collaborator

TerryE commented Jul 4, 2018

Closing this; see #2418. Thanks @nailujx86 Julian. 😄

@TerryE TerryE closed this Jul 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants