RubyGems - logstash-input-salesforce - Versions diffs - 3.0.0 → 3.0.1 - Mend

logstash-input-salesforce 3.0.0 → 3.0.1

Files changed (3717) hide show

data/vendor/jruby/1.9/gems/treetop-1.4.15/doc/semantic_interpretation.markdown DELETED Viewed

@@ -1,218 +0,0 @@
-#Semantic Interpretation
-Lets use the below grammar as an example. It describes parentheses wrapping a single character to an arbitrary depth.
-    grammar ParenLanguage
-      rule parenthesized_letter
-        '(' parenthesized_letter ')'
-        /
-        [a-z]
-      end
-    end
-Matches:
-* `'a'`
-* `'(a)'`
-* `'((a))'`
-* etc.
-Output from a parser for this grammar looks like this:
-![Tree Returned By ParenLanguageParser](./images/paren_language_output.png)
-This is a parse tree whose nodes are instances of `Treetop::Runtime::SyntaxNode`. What if we could define methods on these node objects? We would then have an object-oriented program whose structure corresponded to the structure of our language. Treetop provides two techniques for doing just this.
-##Associating Methods with Node-Instantiating Expressions
-Sequences and all types of terminals are node-instantiating expressions. When they match, they create instances of `Treetop::Runtime::SyntaxNode`. Methods can be added to these nodes in the following ways:
-###Inline Method Definition
-Methods can be added to the nodes instantiated by the successful match of an expression
-    grammar ParenLanguage
-      rule parenthesized_letter
-        '(' parenthesized_letter ')' {
-          def depth
-            parenthesized_letter.depth + 1
-          end
-        }
-        /
-        [a-z] {
-          def depth
-            0
-          end
-        }
-      end
-    end
-Note that each alternative expression is followed by a block containing a method definition. A `depth` method is defined on both expressions. The recursive `depth` method defined in the block following the first expression determines the depth of the nested parentheses and adds one to it. The base case is implemented in the block following the second expression; a single character has a depth of 0.
-###Custom `SyntaxNode` Subclass Declarations
-You can instruct the parser to instantiate a custom subclass of Treetop::Runtime::SyntaxNode for an expression by following it by the name of that class enclosed in angle brackets (`<>`). The above inline method definitions could have been moved out into a single class like so.
-    # in .treetop file
-    grammar ParenLanguage
-      rule parenthesized_letter
-        '(' parenthesized_letter ')' <ParenNode>
-        /
-        [a-z] <ParenNode>
-      end
-    end
-    # in separate .rb file
-    class ParenNode < Treetop::Runtime::SyntaxNode
-      def depth
-        if nonterminal?
-          parenthesized_letter.depth + 1
-        else
-          0
-        end
-      end
-    end
-##Automatic Extension of Results
-Nonterminal and ordered choice expressions do not instantiate new nodes, but rather pass through nodes that are instantiated by other expressions. They can extend nodes they propagate with anonymous or declared modules, using similar constructs used with expressions that instantiate their own syntax nodes.
-###Extending a Propagated Node with an Anonymous Module
-    rule parenthesized_letter
-      ('(' parenthesized_letter ')' / [a-z]) {
-        def depth
-          if nonterminal?
-            parenthesized_letter.depth + 1
-          else
-            0
-          end
-        end
-      }
-    end
-The parenthesized choice above can result in a node matching either of the two choices. The node will be extended with methods defined in the subsequent block. Note that a choice must always be parenthesized to be associated with a following block, otherwise the block will apply to just the last alternative.
-###Extending A Propagated Node with a Declared Module
-    # in .treetop file
-    rule parenthesized_letter
-      ('(' parenthesized_letter ')' / [a-z]) <ParenNode>
-    end
-    # in separate .rb file
-    module ParenNode
-      def depth
-        if nonterminal?
-          parenthesized_letter.depth + 1
-        else
-          0
-        end
-      end
-    end
-Here the result is extended with the `ParenNode` module. Note the previous example for node-instantiating expressions, the constant in the declaration must be a module because the result is extended with it.
-##Automatically-Defined Element Accessor Methods
-###Default Accessors
-Nodes instantiated upon the matching of sequences have methods automatically defined for any nonterminals in the sequence.
-    rule abc
-      a b c {
-        def to_s
-          a.to_s + b.to_s + c.to_s
-        end
-      }
-    end
-In the above code, the `to_s` method calls automatically-defined element accessors for the nodes returned by parsing nonterminals `a`, `b`, and `c`.
-###Labels
-Subexpressions can be given an explicit label to have an element accessor method defined for them. This is useful in cases of ambiguity between two references to the same nonterminal or when you need to access an unnamed subexpression.
-    rule labels
-      first_letter:[a-z] rest_letters:(', ' letter:[a-z])* {
-        def letters
-          [first_letter] + rest_letters.elements.map do |comma_and_letter|
-            comma_and_letter.letter
-          end
-        end
-      }
-    end
-The above grammar uses label-derived accessors to determine the letters in a comma-delimited list of letters. The labeled expressions _could_ have been extracted to their own rules, but if they aren't used elsewhere, labels still enable them to be referenced by a name within the expression's methods.
-###Overriding Element Accessors
-The module containing automatically defined element accessor methods is an ancestor of the module in which you define your own methods, meaning you can override them with access to the `super` keyword. Here's an example of how this fact can improve the readability of the example above.
-    rule labels
-      first_letter:[a-z] rest_letters:(', ' letter:[a-z])* {
-        def letters
-          [first_letter] + rest_letters
-        end
-        def rest_letters
-          super.elements.map { |comma_and_letter| comma_and_letter.letter }
-        end
-      }
-    end
-##Methods Available on `Treetop::Runtime::SyntaxNode`
-<table>
-  <tr>
-    <td>
-      <code>terminal?</code>
-    </td>
-    <td>
-      Was this node produced by the matching of a terminal symbol?
-    </td>
-  </tr>
-  <tr>
-    <td>
-      <code>nonterminal?</code>
-    </td>
-    <td>
-      Was this node produced by the matching of a nonterminal symbol?
-    </td>
-  <tr>
-    <td>
-      <code>text_value</code>
-    </td>
-    <td>
-      The substring of the input represented by this node.
-    </td>
-  <tr>
-    <td>
-      <code>elements</code>
-    </td>
-    <td>
-      Available only on nonterminal nodes, returns the nodes parsed by the elements of the matched sequence.
-    </td>
-  <tr>
-    <td>
-      <code>input</code>
-    </td>
-    <td>
-       The entire input string, which is useful mainly in conjunction with <code>interval</code>
-    </td>
-  <tr>
-    <td>
-      <code>interval</code>
-    </td>
-    <td>
-       The Range of characters in <code>input</code> matched by this rule
-    </td>
-  <tr>
-    <td>
-      <code>empty?</code>
-    </td>
-    <td>
-       returns true if this rule matched no characters of input
-    </td>
-  <tr>
-    <td>
-      <code>inspect</code>
-    </td>
-    <td>
-       Handy-dandy method that returns an indented subtree dump of the syntax tree starting here.
-       This dump includes, for each node, the offset and a snippet of the text this rule matched, and the names of mixin modules and the accessor and extension methods.
-    </td>
-  </tr>
-</table>

data/vendor/jruby/1.9/gems/treetop-1.4.15/doc/site.rb DELETED Viewed

@@ -1,112 +0,0 @@
-require 'rubygems'
-require 'erector'
-require "#{File.dirname(__FILE__)}/sitegen"
-require 'fileutils'
-require 'bluecloth'
-class Layout < Erector::Widget
-  def content
-    html do
-      head do
-        link :rel => "stylesheet",
-        :type => "text/css",
-        :href => "./screen.css"
-        rawtext %(
-          <script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
-          </script>
-          <script type="text/javascript">
-          _uacct = "UA-3418876-1";
-          urchinTracker();
-          </script>
-        )
-      end
-      body do
-        div :id => 'top' do
-          div :id => 'main_navigation' do
-            main_navigation
-          end
-        end
-        div :id => 'middle' do
-          div :id => 'main_content' do
-            main_content
-          end
-        end
-        div :id => 'bottom' do
-        end
-      end
-    end
-  end
-  def main_navigation
-    ul do
-      li { link_to "Documentation", SyntacticRecognition, Documentation }
-      li { link_to "Contribute", Contribute }
-      li { link_to "Home", Index }
-    end
-  end
-  def main_content
-  end
-end
-class Index < Layout
-  def main_content
-    bluecloth "index.markdown"
-  end
-end
-class Documentation < Layout
-  abstract
-  def main_content
-    div :id => 'secondary_navigation' do
-      ul do
-        li { link_to 'Syntax', SyntacticRecognition }
-        li { link_to 'Semantics', SemanticInterpretation }
-        li { link_to 'Using In Ruby', UsingInRuby }
-        li { link_to 'Advanced Techniques', PitfallsAndAdvancedTechniques }
-      end
-    end
-    div :id => 'documentation_content' do
-      documentation_content
-    end
-  end
-end
-class SyntacticRecognition < Documentation
-  def documentation_content
-    bluecloth "syntactic_recognition.markdown"
-  end
-end
-class SemanticInterpretation < Documentation
-  def documentation_content
-    bluecloth "semantic_interpretation.markdown"
-  end
-end
-class UsingInRuby < Documentation
-  def documentation_content
-    bluecloth "using_in_ruby.markdown"
-  end
-end
-class PitfallsAndAdvancedTechniques < Documentation
-  def documentation_content
-    bluecloth "pitfalls_and_advanced_techniques.markdown"
-  end
-end
-class Contribute < Layout
-  def main_content
-    bluecloth "contributing_and_planned_features.markdown"
-  end
-end
-Layout.generate_site

data/vendor/jruby/1.9/gems/treetop-1.4.15/doc/sitegen.rb DELETED Viewed

@@ -1,65 +0,0 @@
-class Layout < Erector::Widget
-  class << self
-    def inherited(page_class)
-      puts page_class
-      (@@page_classes ||= []) << page_class
-    end
-    def generate_site
-      FileUtils.mkdir_p(site_dir)
-      @@page_classes.each do |page_class|
-        page_class.generate_html unless page_class.abstract?
-        puts page_class
-      end
-    end
-    def generate_html
-      File.open(absolute_path, 'w') do |file|
-        file.write(new.to_html)
-      end
-    end
-    def absolute_path
-      absolutize(relative_path)
-    end
-    def relative_path
-      "#{name.gsub('::', '_').underscore}.html"
-    end
-    def absolutize(relative_path)
-      File.join(site_dir, relative_path)
-    end
-    def abstract
-      @abstract = true
-    end
-    def abstract?
-      @abstract
-    end
-    def site_dir
-      File.join(File.dirname(__FILE__), "site")
-    end
-  end
-  def bluecloth(relative_path)
-    File.open(File.join(File.dirname(__FILE__), relative_path)) do |file|
-      rawtext BlueCloth.new(file.read).to_html
-    end
-  end
-  def absolutize(relative_path)
-    self.class.absolutize(relative_path)
-  end
-  def link_to(link_text, page_class, section_class=nil)
-    if instance_of?(page_class) || section_class && is_a?(section_class)
-      text link_text
-    else
-      a link_text, :href => page_class.relative_path
-    end
-  end
-end

data/vendor/jruby/1.9/gems/treetop-1.4.15/doc/syntactic_recognition.markdown DELETED Viewed

@@ -1,215 +0,0 @@
-#Syntactic Recognition
-Treetop grammars are written in a custom language based on parsing expression grammars. Literature on the subject of <a href="http://en.wikipedia.org/wiki/Parsing_expression_grammar">parsing expression grammars</a> (PEGs) is useful in writing Treetop grammars.
-PEGs have no separate lexical analyser (since the algorithm has the same time-complexity guarantees as the best lexical analysers) so all whitespace and other lexical niceties (like comments) must be explicitly handled in the grammar. A further benefit is that multiple PEG grammars may be seamlessly composed into a single parser.
-#Grammar Structure
-Treetop grammars look like this:
-    require "my_stuff"
-    grammar GrammarName
-      include Module::Submodule
-      rule rule_name
-        ...
-      end
-      rule rule_name
-        ...
-      end
-      ...
-    end
-The main keywords are:
-* `grammar` : This introduces a new grammar. It is followed by a constant name to which the grammar will be bound when it is loaded.
-* `include`: This causes the generated parser to include the referenced Ruby module (which may be another parser)
-* `require`: This must be at the start of the file, and is passed through to the emitted Ruby grammar
-* `rule` : This defines a parsing rule within the grammar. It is followed by a name by which this rule can be referenced within other rules. It is then followed by a parsing expression defining the rule.
-A grammar may be surrounded by one or more nested `module` statements, which provides a namespace for the generated Ruby parser.
-Treetop will emit a module called `GrammarName` and a parser class called `GrammarNameParser` (in the module namespace, if specified).
-#Parsing Expressions
-Each rule associates a name with a _parsing expression_. Parsing expressions are a generalization of vanilla regular expressions. Their key feature is the ability to reference other expressions in the grammar by name.
-##Terminal Symbols
-###Strings
-Strings are surrounded in double or single quotes and must be matched exactly.
-* `"foo"`
-* `'foo'`
-###Character Classes
-Character classes are surrounded by brackets. Their semantics are identical to those used in Ruby's regular expressions.
-* `[a-zA-Z]`
-* `[0-9]`
-###The Anything Symbol
-The anything symbol is represented by a dot (`.`) and matches any single character.
-###Ellipsis
-An empty string matches at any position and consumes no input. It's useful when you wish to treat a single symbol as part of a sequence, for example when an alternate rule will be processed using shared code.
-<pre>
-    rule alts
-      ( foo bar / baz '' )
-      {
-        def value
-          elements.map{|e| e.text_value }
-        end
-      }
-    end
-</pre>
-##Nonterminal Symbols
-Nonterminal symbols are unquoted references to other named rules. They are equivalent to an inline substitution of the named expression.
-    rule foo
-      "the dog " bar
-    end
-    rule bar
-      "jumped"
-    end
-The above grammar is equivalent to:
-    rule foo
-      "the dog jumped"
-    end
-##Ordered Choice
-Parsers attempt to match ordered choices in left-to-right order, and stop after the first successful match.
-    "foobar" / "foo" / "bar"
-Note that if `"foo"` in the above expression came first, `"foobar"` would never be matched.
-Note also that the above rule will match `"bar"` as a prefix of `"barbie"`.
-Care is required when it's desired to match language keywords exactly.
-##Sequences
-Sequences are a space-separated list of parsing expressions. They have higher precedence than choices, so choices must be parenthesized to be used as the elements of a sequence.
-    "foo" "bar" ("baz" / "bop")
-##Zero or More
-Parsers will greedily match an expression zero or more times if it is followed by the star (`*`) symbol.
-* `'foo'*` matches the empty string, `"foo"`, `"foofoo"`, etc.
-##One or More
-Parsers will greedily match an expression one or more times if it is followed by the plus (`+`) symbol.
-* `'foo'+` does not match the empty string, but matches `"foo"`, `"foofoo"`, etc.
-##Optional Expressions
-An expression can be declared optional by following it with a question mark (`?`).
-* `'foo'?` matches `"foo"` or the empty string.
-##Repetition count
-A generalised repetition count (minimum, maximum) is also available.
-* `'foo' 2..` matches `'foo'` two or more times
-* `'foo' 3..5` matches `'foo'` from three to five times
-* `'foo' ..4` matches `'foo'` from zero to four times
-##Lookahead Assertions
-Lookahead assertions can be used to make parsing expressions context-sensitive.
-The parser will look ahead into the buffer and attempt to match an expression without consuming input.
-###Positive Lookahead Assertion
-Preceding an expression with an ampersand `(&)` indicates that it must match, but no input will be consumed in the process of determining whether this is true.
-* `"foo" &"bar"` matches `"foobar"` but only consumes up to the end `"foo"`. It will not match `"foobaz"`.
-###Negative Lookahead Assertion
-Preceding an expression with a bang `(!)` indicates that the expression must not match, but no input will be consumed in the process of determining whether this is true.
-* `"foo" !"bar"` matches `"foobaz"` but only consumes up to the end `"foo"`. It will not match `"foobar"`.
-Note that a lookahead assertion may be used on any rule, not just a string terminal.
-    rule things
-      thing (!(disallowed / ',') following)*
-    end
-Here's a common use case:
-    rule word
-      [a-zA-Z]+
-    end
-    rule conjunction
-      primitive ('and' ' '+ primitive)*
-    end
-    rule primitive
-      (!'and' word ' '+)*
-    end
-Here's the easiest way to handle C-style comments:
-    rule c_comment
-      '/*'
-      (
-        !'*/'
-        (. / "\n")
-      )*
-      '*/'
-    end
-##Semantic predicates (positive and negative)
-Sometimes you must execute Ruby code during parsing in order to decide how to proceed.
-This is an advanced feature, and must be used with great care, because it can change the
-way a Treetop parser backtracks in a way that breaks the parsing algorithm. See the
-notes below on how to use this feature safely.
-The code block is the body of a Ruby lambda block, and should return true or false, to cause this
-parse rule to continue or fail (for positive sempreds), fail or continue (for negative sempreds).
-* `&{ ... }` Evaluate the block and fail this rule if the result is false or nil
-* `!{ ... }` Evaluate the block and fail this rule if the result is not false or nil
-The lambda is passed a single argument which is the array of syntax nodes matched so far in the
-current sequence. Note that because the current rule has not yet succeeded, no syntax node has
-yet been constructed, and so the lambda block is being run in a context where the `names` of the
-preceding rules (or as assigned by labels) are not available to access the sub-rules.
-    rule id
-      [a-zA-Z][a-zA-Z0-9]*
-      {
-        def is_reserved
-          ReservedSymbols.include? text_value
-        end
-      }
-    end
-    rule foo_rule
-      foo id &{|seq| seq[1].is_reserved } baz
-    end
-Match "foo id baz" only if `id.is_reserved`. Note that `id` cannot be referenced by name from `foo_rule`,
-since that rule has not yet succeeded, but `id` has completed and so its added methods are available.
-    rule test_it
-      foo bar &{|s| debugger; true } baz
-    end
-Match `foo` then `bar`, stop to enter the debugger (make sure you have said `require "ruby-debug"` somewhere),
-then continue by trying to match `baz`.
-Treetop, like other PEG parsers, achieves its performance guarantee by remembering which rules it has
-tried at which locations in the input, and what the result was. This process, called memoization,
-requires that the rule would produce the same result (if run again) as it produced the first time when
-the result was remembered. If you violate this principle in your semantic predicates, be prepared to
-fight Cerberus before you're allowed out of Hades again.