I agree on the section definitions. It's very hard to remember which underline I need to use because every project (or even document) can just define their own order implicitly. The sphinx project recommends a specific order somewhere in their documentation that I look up every time I need to write rst, but markdowns just-count-the-hashes is much easier.
To be honest, I don't find this to be true. To email a patch, you usually have to
* figure out if you can use git-request-pull or git-send-email
* sign up for a mailing list (which, depending on the mailing list software the project uses, can take anywhere between a few seconds and annoyingly large amounts of minutes)
* optionally figure out how to not receive the whole traffic of the ML or set up custom email filters
* figure out if you have to CC the people responsible for the area of the code you're going to send a patch for (which might be written down in a wiki, some CONTRIBUTING file or somewhere else)
* figure out if the project wants an extra cover letter for the patch series or not (and optionally search the man pages for how to write one).
With GitHub, I just use [hub](https://hub.github.com/) or an Emacs package or plugins for other editors to
* fork the repository
* (without additional tools, I now have to add my newly created remote)
* push to my own remote
* create the pull request after reading CONTRIBUTING<tab>
which so far has been the exact same workflow for every project I've seen (ymmv of course).
Note that not all of those use Phabricator as a bug tracker (KDE, lighttpd, LLVM, Haskell, I imagine a lot of bugs for Wikimedia are reported through project chat pages on the wikis themselves).
This might sound a bit stupid, but I was looking into F# a while ago (26 days ago, if the timestamps of the few files I wrote don't lie :-) ) and now I'm wondering I could have found those things (especially RWFP because I usually don't like learning from videos) if I start on fhsarp.org?
It's possible to "lock" [0] conversations on GitHub. This means that only
collaborators of the repository are able to add comments to the issue/pull
request.
That's because gcc is trying to compile it as C, not C++. You need to call the file "test.cpp" or explicitly use g++ instead of gcc to compile it. (You'll also need to "#include <assert.h>" or it won't compile.)
That should be "foldl f z (x:xs) = foldl f (f z x) xs" because the function f takes two arguments (the whole thing boils down to "(((z `f` x_1) `f` x_2) ... `f` x_n)").