<commit_before>### FAQ:

**Q: Why is "--enable-more-deterministic" recommended?**

**A:** Fuzzing with this mode on allows us to run compareJIT, which runs testcases generated by jsfunfuzz using different flags and compares the output. In order to compare successfully, the shell should generate consistent output everytime with a fixed input. Since we do not ship deterministic shells by default, if testing deterministic shells, we do not run with compareJIT.

**Q: Is "--enable-nspr-build" needed?**

**A:** Moving forward, NSPR is compiled along with SpiderMonkey in the js build system. However, prior to sometime in Spring 2014, it was not, and it had to be compiled separately from SpiderMonkey in order to compile a threadsafe shell.

This flag is usually recommended for bisection and compatibility purposes, where the earliest possible revision that could be compiled is still prior to this change.

**Q: What are average build times for SpiderMonkey?**

**A:** On a decent Linux machine or a powerful Mac, both with 4 or more cores, 3-4 minutes on average. On Windows, probably 5-10 minutes. On an ARM ODROID board, up to an hour.

**Q: Do these build configure flags get passed into the js configure scripts?**

No, they are independent. We only implemented the flags that are most useful for fuzzing in the harness.

**Q: Will the gecko-dev Git mirror of mozilla-central be supported?**

**A:** The "-R" flag assumes a Mercurial clone of mozilla-central is passed in as an argument. Git repositories are not yet supported fully, and especially not for autoBisect. See issue #2.

**Q: Can I run multiple instances of compileShell?**

This is not recommended as it will slow down your computer. Running one instance of compileShell will use the maximum number of cores as found by cpu_count() from the Python multiprocessing module, with the exception of ARM boards that tend to have slower cores.

**Q: What kind of build does compileShell do, and what files do it store on my machine?**

**A:** It creates a clobber build, compiling in the ~/shell-cache directory by default. There may also be a bunch of tempfiles created in the system temporary directory.

**Q: How do I check if the SpiderMonkey build created is the one I specified?**

**A:** Post-compilation, the harness does a bunch of verification tests to ensure that the desired build is created. To double check, run `getBuildConfiguration();` within the SpiderMonkey shell. If compileShell isn't compiling as desired, file an issue!

**Q: What happens if the build I want to compile causes a compilation error?**

**A:** A .busted file is created in the shell-cache directory. This will notify the harness not to retry in the future since it is busted. However, if there is an error in the harness, file an issue detailing the build configurations and steps to reproduce, and once it is fixed, remove the corresponding file/directory in ~/shell-cache and retry again.

**Q: After compiling many shells, I'm now running out of disk space! What should I do?**

**A:** Oops! You can remove the ~/shell-cache directory to reclaim space, and reboot to clear system temporary directories.<commit_msg>Remove redundant boilerplate.<commit_after>### FAQ:

**Q: Why is "--enable-more-deterministic" recommended?**

Fuzzing with this mode on allows us to run compareJIT, which runs testcases generated by jsfunfuzz using different flags and compares the output. In order to compare successfully, the shell should generate consistent output everytime with a fixed input. Since we do not ship deterministic shells by default, if testing deterministic shells, we do not run with compareJIT.

**Q: Is "--enable-nspr-build" needed?**

Moving forward, NSPR is compiled along with SpiderMonkey in the js build system. However, prior to sometime in Spring 2014, it was not, and it had to be compiled separately from SpiderMonkey in order to compile a threadsafe shell.

This flag is usually recommended for bisection and compatibility purposes, where the earliest possible revision that could be compiled is still prior to this change.

**Q: What are average build times for SpiderMonkey?**

On a decent Linux machine or a powerful Mac, both with 4 or more cores, 3-4 minutes on average. On Windows, probably 5-10 minutes. On an ARM ODROID board, up to an hour.

**Q: Do these build configure flags get passed into the js configure scripts?**

No, they are independent. We only implemented the flags that are most useful for fuzzing in the harness.

**Q: Will the gecko-dev Git mirror of mozilla-central be supported?**

The "-R" flag assumes a Mercurial clone of mozilla-central is passed in as an argument. Git repositories are not yet supported fully, and especially not for autoBisect. See issue #2.

**Q: Can I run multiple instances of compileShell?**

This is not recommended as it will slow down your computer. Running one instance of compileShell will use the maximum number of cores as found by cpu_count() from the Python multiprocessing module, with the exception of ARM boards that tend to have slower cores.

**Q: What kind of build does compileShell do, and what files do it store on my machine?**

It creates a clobber build, compiling in the ~/shell-cache directory by default. There may also be a bunch of tempfiles created in the system temporary directory.

**Q: How do I check if the SpiderMonkey build created is the one I specified?**

Post-compilation, the harness does a bunch of verification tests to ensure that the desired build is created. To double check, run `getBuildConfiguration();` within the SpiderMonkey shell. If compileShell isn't compiling as desired, file an issue!

**Q: What happens if the build I want to compile causes a compilation error?**

A .busted file is created in the shell-cache directory. This will notify the harness not to retry in the future since it is busted. However, if there is an error in the harness, file an issue detailing the build configurations and steps to reproduce, and once it is fixed, remove the corresponding file/directory in ~/shell-cache and retry again.

**Q: After compiling many shells, I'm now running out of disk space! What should I do?**

Oops! You can remove the ~/shell-cache directory to reclaim space, and reboot to clear system temporary directories.
{'fraction_non_alphanumeric': 0.058590028580501746, 'fraction_numerical': 0.003493172435693871, 'mean_word_length': 4.535149384885765, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5794174', 'n_tokens_mistral': 1621, 'n_tokens_neox': 1504, 'n_words': 999}