<commit_before># Versioned API Browser
This Ember Application allows you to browse API docs.


# Setup

1. Install Dependencies

  ```shell
  npm install && bower install
  ```

1. Start the app with with the following command args
  
  * `lib-dir` (path) local path to the library documented with YUIDoc
  e.g. `/usr/yourname/code/ember.js`

  * `execution-dir` (path, default `lib-dir`) local path to the directory where `yuidoc` should 
  execute: e.g. `'/usr/yourname/code/ember.js/docs'`

  * `project-name` (string, default `''`) the name of the project you're documenting.
  this becomes the project's slug for urls: e.g. `ember.js` becomes `/ember.js/v1.9.0`

  * `default-index` (string) name of the class you'd like to redirect to
  when someone visits the root (`/`) of the documentation. e.g. `Ember`

  * `default-module` (string) name of the module where to look for module
  related data. YUIDoc stuffs all modules (even if you only have one) into
  `modules`: e.g. `ember`

  * `rev` (string, optional, defaults to 'master') name of the revision you are
  generating: e.g. `v1.1.0`

  * `sha` (String, optional, defaults to 'master') name of the SHA or tag. This is different
  than `rev` to allow you to publish new versions of a rev's docs that have been updated
  in future commits. So, if a spelling fixes occur in commits > v1.1.0 and < v1.1.1 you
  can publish the SHA to update: e.g. `decafbebad01` or `v1.0.0`<commit_msg>Fixing README typos<commit_after># Versioned API Browser
This Ember Application allows you to browse API docs.


# Setup

1. Install Dependencies

  ```shell
  npm install && bower install
  ```

1. Start the app with the following command args
  
  * `lib-dir` (path) local path to the library documented with YUIDoc
  e.g. `/usr/yourname/code/ember.js`

  * `execution-dir` (path, default `lib-dir`) local path to the directory where `yuidoc` should 
  execute: e.g. `'/usr/yourname/code/ember.js/docs'`

  * `project-name` (string, default `''`) the name of the project you're documenting.
  this becomes the project's slug for urls: e.g. `ember.js` becomes `/ember.js/v1.9.0`

  * `default-index` (string) name of the class you'd like to redirect to
  when someone visits the root (`/`) of the documentation. e.g. `Ember`

  * `default-module` (string) name of the module where to look for module
  related data. YUIDoc stuffs all modules (even if you only have one) into
  `modules`: e.g. `ember`

  * `rev` (string, optional, defaults to 'master') name of the revision you are
  generating: e.g. `v1.1.0`

  * `sha` (String, optional, defaults to 'master') name of the SHA or tag. This is different
  than `rev` to allow you to publish new versions of a rev's docs that have been updated
  in future commits. So, if spelling fixes occur in commits > v1.1.0 and < v1.1.1 you
  can publish the SHA to update: e.g. `decafbebad01` or `v1.0.0`
{'fraction_non_alphanumeric': 0.11214953271028037, 'fraction_numerical': 0.013153340256143994, 'mean_word_length': 3.4806201550387597, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, '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': '1232524', 'n_tokens_mistral': 984, 'n_tokens_neox': 925, 'n_words': 399}