antelope 0.2.0 → 0.2.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 516fa3871c9dac6ede9010e5dce27e6427e54c0a
-  data.tar.gz: 05950417e688f1e91bd72533a6fba22e5b4f0c39
+  metadata.gz: b92cf3cc4e8746993ec89f21f9eb97646787cbf1
+  data.tar.gz: 2739de2a0326fa116232b6f6be22e1b771d87225
 SHA512:
-  metadata.gz: 5f798c4757105920b7b552891c481587654bbbf3df69fb0ab5eff2e0c6a927ddf6b5f746fa548bdf71970aebda029c249e0d1ea82d418dc88d22d6c4b378f7a1
-  data.tar.gz: 1a800f78ea7ba51e36a3d4e24bd905dd49b7f7b37bc4eccebbc6872230d44653252b4b288b6988e6c3470e37face35e89ffb427e7d6e73553b221c1e4cc419be
+  metadata.gz: 1bca5d306f74efc0f25f4823e288221e3b5c708a2f6a15e870254df602c617bfac7482c5871b6241a17c2fd81cad4bb83a132c7c04a44c2c035e14604faf85cd
+  data.tar.gz: 22b68475fe03066f181006e21763707dd01102143998634b8938597d771a9bca7a776f5980702a55db87db6ad923b63434c14dd12be925a2d1c0cf40ccdf9653

data/.gitignore

@@ -1,23 +1,25 @@
-*.gem
-*.rbc
-.bundle
-.config
-.yardoc
-Gemfile.lock
-InstalledFiles
-_yardoc
-coverage
-doc/
-lib/bundler/man
-pkg
-rdoc
-spec/reports
-test/tmp
-test/version_tmp
-examples/*.rb
-tmp
-*.bundle
-*.so
-*.o
-*.a
-mkmf.log
+*.gem
+*.rbc
+.bundle
+.config
+.yardoc
+Gemfile.lock
+InstalledFiles
+_yardoc
+coverage
+doc/
+lib/bundler/man
+pkg
+rdoc
+spec/reports
+test/tmp
+test/version_tmp
+examples/*.rb
+tmp
+*.bundle
+*.so
+*.o
+*.a
+mkmf.log
+*.ant.rb
+*.output

data/.rspec

@@ -1,3 +1,3 @@
---color
--f d
---require spec_helper.rb
+--color
+-f d
+--require spec_helper.rb

data/.travis.yml

@@ -1,9 +1,10 @@
-language: ruby
-rvm:
-  - 2.1.2
-  - 2.1.0
-  - 2.0.0
-  - 1.9.3
-  - jruby-19mode
-script: bundle exec rspec -f d spec
-sudo: false
+language: ruby
+rvm:
+  - 2.1.2
+  - 2.1.0
+  - 2.0.0
+  - 1.9.3
+  - jruby-19mode
+script: bundle exec rspec -f d spec
+sudo: false
+cache: bundler

data/.yardopts

@@ -1,7 +1,7 @@
---protected
---private
--m markdown
--
-LICENSE.txt
-CONTRIBUTING.md
-GENERATORS.md
+--protected
+--private
+-m markdown
+-
+LICENSE.txt
+CONTRIBUTING.md
+GENERATORS.md

data/CONTRIBUTING.md

@@ -1,38 +1,38 @@
-# Contributing to _Antelope_
-
-First and foremost, **thank you**! Contributing to _Antelope_ is great!  There are a few guidelines, however...
-
-## Contribution Process
-
-1. Fork the repository ([medcat/antelope])
-2. Create a new branch for your feature (something like `my-feature`)
-3. Make your changes
-4. Commit your changes
-5. if(notDone) goto 3;
-6. Push your changes
-7. Make a pull request
-
-Creating a new branch is a _really, really_ good idea; it keeps things neat in the world of git.  When you make the pull request, any commits you make to the merging branch are added to the pull request.  Also, _please_ make sure you describe the pull request, and what it does, and why it's needed.
-
-## Commit Message Style
-
-I have to admit, I'm absolutely terrible at commits.  But, in case of a commit, commit messages should be imperative - it's what the commit _does_, not what it _will do_ or what it _has done_; for example, "Create Generator for C Output".  Messages should have a subject, and optionally a body; the subject should have no more than 50 characters, and should be concise, as well as in Title Case.  If you can't fit information in the subject, put it in the body.
-
-## Issues
-
-When opening issues, there are a few requirements:
-
-- Describe the problem
-- Show how to reproduce it, if applicable
-- Explain what you think is causing it, if applicable
-- Give a plausible solution, if applicable
-
-Give (us|me) as much information as needed so (we|I) can decide how to handle the issue.
-
-## Closing Words
-
-And, most of all, the last requirement: have fun!
-
-
-
-[medcat/antelope]: https://github.com/medcat/antelope
+# Contributing to _Antelope_
+
+First and foremost, **thank you**! Contributing to _Antelope_ is great!  There are a few guidelines, however...
+
+## Contribution Process
+
+1. Fork the repository ([medcat/antelope])
+2. Create a new branch for your feature (something like `my-feature`)
+3. Make your changes
+4. Commit your changes
+5. if(notDone) goto 3;
+6. Push your changes
+7. Make a pull request
+
+Creating a new branch is a _really, really_ good idea; it keeps things neat in the world of git.  When you make the pull request, any commits you make to the merging branch are added to the pull request.  Also, _please_ make sure you describe the pull request, and what it does, and why it's needed.
+
+## Commit Message Style
+
+I have to admit, I'm absolutely terrible at commits.  But, in case of a commit, commit messages should be imperative - it's what the commit _does_, not what it _will do_ or what it _has done_; for example, "Create Generator for C Output".  Messages should have a subject, and optionally a body; the subject should have no more than 50 characters, and should be concise, as well as in Title Case.  If you can't fit information in the subject, put it in the body.
+
+## Issues
+
+When opening issues, there are a few requirements:
+
+- Describe the problem
+- Show how to reproduce it, if applicable
+- Explain what you think is causing it, if applicable
+- Give a plausible solution, if applicable
+
+Give (us|me) as much information as needed so (we|I) can decide how to handle the issue.
+
+## Closing Words
+
+And, most of all, the last requirement: have fun!
+
+
+
+[medcat/antelope]: https://github.com/medcat/antelope

data/GENERATORS.md

@@ -1,124 +1,124 @@
-# Generators
-
-_Antelope_ comes with an assortment of generators; however, if you wish to create a custom generator, here's how.
-
-First, you'll want to make your generator a subclass of `Antelope::Generator::Base`.  This sets up a basic framework for you to build upon.
-
-```Ruby
-class MyGenerator < Antelope::Generator::Base
-
-end
-```
-
-Next, you'll want to define a `generate` method on your generator that takes no arguments.  This is used internally by _Antelope_ to actually have your generator perform its generation.  In the case of this generator, we'll have it copy over a template (after running the templating generator over it over it).
-
-```Ruby
-class MyGenerator < Antelope::Generator::Base
-
-  def generate
-    template "my_template", "#{file}.my_file"
-  end
-end
-```
-
-`Base` provides a few convienince methods for you, one of them being [`template`](http://rubydoc.info/github/medcat/antelope/master/Antelope/Generator/Base#template-instance_method); `file` is also provided, and it contains the base part of the file name of the parser ace file that this is being generated for.  The template, by default, should rest in `<lib path>/lib/antelope/generator/templates` (with `<lib path>` being the place that _Antelope_ was installed); however, if it should be changed, you can overwrite the `source_root` method on the class:
-
-```Ruby
-class MyGenerator < Antelope::Generator::Base
-
-  def self.source_root
-    Pathname.new("/path/to/source")
-  end
-
-  def generate
-    template "my_template", "#{file}.my_file"
-  end
-end
-```
-
-In the template, the code is run in the context of the instance of the class, so you have access to instance variables and methods as if you were defining a method on the class:
-
-```
-{{ table.each_with_index do |hash, i| }}
-  state {{= i }}:
-{{   hash.each do |token, action| }}
-    for {{= token }}, I'll {{= action[0] }} {{= action[1] }}
-{{   end }}
-{{ end }}
-```
-
-_Note: in templates, blocks that start at the beginning of a line and end at the end of a line do not produce any whitespace._
-
-`table` here is defined on the base class, and we're iterating over all of the values of it.
-
-The last thing to do is to register the generator with _Antelope_.  This is as simple as adding a line `register_as "my_generator"` to the class definition.  Then, if any grammar file has the type `"my_generator"`, your generator will be run (assuming it's been required by _Antelope_).
-
-The finialized product:
-
-```Ruby
-# my_generator.rb
-class MyGenerator < Antelope::Generator::Base
-
-  register_as "my_generator"
-
-  def self.source_root
-    Pathname.new("/path/to/source")
-  end
-
-  def generate
-    template "my_template.erb", "#{file}.my_file"
-  end
-end
-```
-
-```
-# my_template.ant
-{{ table.each_with_index do |hash, i| }}
-  state {{= i }}:
-{{   hash.each do |token, action| }}
-    for {{= token }}, I'll {{= action[0] }} {{= action[1] }}
-{{   end }}
-{{ end }}
-```
-
-## Bundling
-
-If you want to bundle a few generators together such that the bundle is generated together, you can use an `Antelope::Generator::Group`.  This would be useful for something like a C language generator, which may need to generate both a header and a source file:
-
-```Ruby
-class CHeader < Antelope::Generator::Base
-  # ...
-end
-
-class CSource < Antelope::Generator::Base
-  # ...
-end
-
-
-class C < Antelope::Generator::Group
-  register_generator CHeader, "c-header"
-  register_generator CSource, "c-source"
-end
-```
-
-The `register_generator` takes a generator class and a name for the generator, and adds the generator to the list of generators on the receiver (in this case, the `C` class).  Now, when `C#generate` is run, it will run both `CHeader#generate` and `CSource#generate`.
-
-## Using Compiler Directives
-
-Directives are statements that are used in Ace files in order to pass information to _Antelope_.  They normally follow the syntax `%<directive name> [directive arguments]*`.  See [the Ace file format](http://rubydoc.info/github/medcat/antelope/Antelope/Ace) for more information about directives.
-
-In some cases, like in the [Ruby generator][Ruby], options from the Ace file are needed for generation.  In the case of the Ruby generator, we need the error class that the developer wants the generator to use; and we reference it through the `ruby.error-class` directive.  In order to define directives that can be used in custom generators, you just need to add a few lines:
-
-```Ruby
-class MyGenerator < Antelope::Generator::Base
-
-  has_directive "my-generator.some-value", Boolean
-
-end
-```
-
-In this example, we define a directive named `my-generator.some-value`; this directive is eventually coerced into a `true`/`false` value.  In order to actually use the value of the directive, in either the template or a method on the generator, you can reference `directives["my-generator.some-value"]`, which will be `nil` (it wasn't defined), `true` (it was defined, with any arguments), or `false` (it was explicitly defined with one argument, `"false"`).  Some other values you can pass in place of `Boolean` would be `:single` (or `:one`), which only gives the first argument passed to the directive; an `Array` of types, which would coerce each argument into its corresponding element of the array; `Array`, which will give an array of the given arguments; `String`, which gives a string representation of the first argument; any `Numeric` subclass, which would coerce the first argument into an integer; `Float`, which would coerce the first argument into a float; any class, which would be instantized with the arguments to the directive.  Any other values would yield an error.
-
-It is recommended that you namespace directives that only your generator would use, using dashed syntax, like in our example above.  However, some directives are not namespaced, or are not namespaced under a generator; these may be used by any generator.  It is also recommended that you declare every directive that you use.
-
-[Ruby]: http://rubydoc.info/github/medcat/antelope/Antelope/Generator/Ruby
+# Generators
+
+_Antelope_ comes with an assortment of generators; however, if you wish to create a custom generator, here's how.
+
+First, you'll want to make your generator a subclass of `Antelope::Generator::Base`.  This sets up a basic framework for you to build upon.
+
+```Ruby
+class MyGenerator < Antelope::Generator::Base
+
+end
+```
+
+Next, you'll want to define a `generate` method on your generator that takes no arguments.  This is used internally by _Antelope_ to actually have your generator perform its generation.  In the case of this generator, we'll have it copy over a template (after running the templating generator over it over it).
+
+```Ruby
+class MyGenerator < Antelope::Generator::Base
+
+  def generate
+    template "my_template", "#{file}.my_file"
+  end
+end
+```
+
+`Base` provides a few convienince methods for you, one of them being [`template`](http://rubydoc.info/github/medcat/antelope/master/Antelope/Generator/Base#template-instance_method); `file` is also provided, and it contains the base part of the file name of the parser ace file that this is being generated for.  The template, by default, should rest in `<lib path>/lib/antelope/generator/templates` (with `<lib path>` being the place that _Antelope_ was installed); however, if it should be changed, you can overwrite the `source_root` method on the class:
+
+```Ruby
+class MyGenerator < Antelope::Generator::Base
+
+  def self.source_root
+    Pathname.new("/path/to/source")
+  end
+
+  def generate
+    template "my_template", "#{file}.my_file"
+  end
+end
+```
+
+In the template, the code is run in the context of the instance of the class, so you have access to instance variables and methods as if you were defining a method on the class:
+
+```
+{{ table.each_with_index do |hash, i| }}
+  state {{= i }}:
+{{   hash.each do |token, action| }}
+    for {{= token }}, I'll {{= action[0] }} {{= action[1] }}
+{{   end }}
+{{ end }}
+```
+
+_Note: in templates, blocks that start at the beginning of a line and end at the end of a line do not produce any whitespace._
+
+`table` here is defined on the base class, and we're iterating over all of the values of it.
+
+The last thing to do is to register the generator with _Antelope_.  This is as simple as adding a line `register_as "my_generator"` to the class definition.  Then, if any grammar file has the type `"my_generator"`, your generator will be run (assuming it's been required by _Antelope_).
+
+The finialized product:
+
+```Ruby
+# my_generator.rb
+class MyGenerator < Antelope::Generator::Base
+
+  register_as "my_generator"
+
+  def self.source_root
+    Pathname.new("/path/to/source")
+  end
+
+  def generate
+    template "my_template.erb", "#{file}.my_file"
+  end
+end
+```
+
+```
+# my_template.ant
+{{ table.each_with_index do |hash, i| }}
+  state {{= i }}:
+{{   hash.each do |token, action| }}
+    for {{= token }}, I'll {{= action[0] }} {{= action[1] }}
+{{   end }}
+{{ end }}
+```
+
+## Bundling
+
+If you want to bundle a few generators together such that the bundle is generated together, you can use an `Antelope::Generator::Group`.  This would be useful for something like a C language generator, which may need to generate both a header and a source file:
+
+```Ruby
+class CHeader < Antelope::Generator::Base
+  # ...
+end
+
+class CSource < Antelope::Generator::Base
+  # ...
+end
+
+
+class C < Antelope::Generator::Group
+  register_generator CHeader, "c-header"
+  register_generator CSource, "c-source"
+end
+```
+
+The `register_generator` takes a generator class and a name for the generator, and adds the generator to the list of generators on the receiver (in this case, the `C` class).  Now, when `C#generate` is run, it will run both `CHeader#generate` and `CSource#generate`.
+
+## Using Compiler Directives
+
+Directives are statements that are used in Ace files in order to pass information to _Antelope_.  They normally follow the syntax `%<directive name> [directive arguments]*`.  See [the Ace file format](http://rubydoc.info/github/medcat/antelope/Antelope/Ace) for more information about directives.
+
+In some cases, like in the [Ruby generator][Ruby], options from the Ace file are needed for generation.  In the case of the Ruby generator, we need the error class that the developer wants the generator to use; and we reference it through the `ruby.error-class` directive.  In order to define directives that can be used in custom generators, you just need to add a few lines:
+
+```Ruby
+class MyGenerator < Antelope::Generator::Base
+
+  has_directive "my-generator.some-value", Boolean
+
+end
+```
+
+In this example, we define a directive named `my-generator.some-value`; this directive is eventually coerced into a `true`/`false` value.  In order to actually use the value of the directive, in either the template or a method on the generator, you can reference `directives["my-generator.some-value"]`, which will be `nil` (it wasn't defined), `true` (it was defined, with any arguments), or `false` (it was explicitly defined with one argument, `"false"`).  Some other values you can pass in place of `Boolean` would be `:single` (or `:one`), which only gives the first argument passed to the directive; an `Array` of types, which would coerce each argument into its corresponding element of the array; `Array`, which will give an array of the given arguments; `String`, which gives a string representation of the first argument; any `Numeric` subclass, which would coerce the first argument into an integer; `Float`, which would coerce the first argument into a float; any class, which would be instantized with the arguments to the directive.  Any other values would yield an error.
+
+It is recommended that you namespace directives that only your generator would use, using dashed syntax, like in our example above.  However, some directives are not namespaced, or are not namespaced under a generator; these may be used by any generator.  It is also recommended that you declare every directive that you use.
+
+[Ruby]: http://rubydoc.info/github/medcat/antelope/Antelope/Generator/Ruby

data/Gemfile

@@ -1,7 +1,7 @@
-source 'https://rubygems.org'
-
-# Specify your gem's dependencies in antelope.gemspec
-gemspec
-
-gem 'coveralls'
-gem 'simplecov'
+source 'https://rubygems.org'
+
+# Specify your gem's dependencies in antelope.gemspec
+gemspec
+
+gem 'coveralls'
+gem 'simplecov'

data/LICENSE.txt

@@ -1,22 +1,22 @@
-Copyright (c) 2014 Jeremy Rodi
-
-MIT License
-
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-"Software"), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-
-The above copyright notice and this permission notice shall be
-included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
-LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
-OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
-WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+Copyright (c) 2014 Jeremy Rodi
+
+MIT License
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.