Add section Profiling your K semantics section in the user manual.

[ChristianoBraga]

The new section, right after Debugging, gives a general description of the process necessary for profiling and illustrates it with a couple of Makefile target examples from the KPlutus project.

[radumereuta]

Just some minor aesthetic changes.
Suggestions from the makefile blocks removes trailing whitespace so it doesn't introduce a horizontal scroll bar in the rendered version.

I would still like it this gets one more review from @dwightguth or @ehildenb

[dwightguth]

let's add -DNDEBUG but remove -g here.

[ehildenb]

@dwightguth is this suggested change supposed to be for both CFLAGS and CXXFLAGS? Currently, we are saying -DNDEBUG for CXXFLAGS, but -g for CFLAGS.

[dwightguth]

Both

[ehildenb]

The rest of the file is wrapped at 80 characters I believe @ChristianoBraga . Please follow the same convention.

[dwightguth]

As a matter of fact, because of how terminals that are exactly 80 characters wide tend to work, the entire file is word wrapped such that each line (with the exception of some code fragments and urls that aren't easy to effectively wrap) is less than 80 characters, as in, the 79th character is the last one that is allowed to exist.

[ChristianoBraga]

I dont’t understand why this was assigned to me in the first place. Please reassign it to someone who is responsible for formatting the documentation of K.

…

On Sat, 3 Sep 2022 at 17:26 Everett Hildenbrandt ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In USER_MANUAL.md <#2809 (comment)> : > +optimization_. For example, for EVM, this means rebuilding GMP, MPFR, +JEMalloc, Crypto++, SECP256K1, etc with the following `exports`. +```shell + export CFLAGS="-g -O2 -fno-omit-frame-pointer" ; + export CXXFLAGS="-DNDEBUG -O2 -fno-omit-frame-pointer" +``` + +You can skip this step, but if you do, any samples within these +libraries will not have correct stack trace information, which means Look at the rest of this flie, and format this the same way as the rest. A space before the backticks codeblock, a space after it, no spaces before each line in the code block, etc... You should *always* inspect the formatting of th erest of the file or project or whatever you're contributing to, it's up to you, the PR author, to make sure this is correct. Burden should not be shifted onto the reviewers. — Reply to this email directly, view it on GitHub <#2809 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFNNCEPDYX4A2DZERAEKWL3V4OYANANCNFSM56V6L4XQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>