cocRb 0.1.0

data/.bundle/ruby/3.0.0/gems/ast-2.4.2/lib/ast/processor.rb

@@ -0,0 +1,12 @@
+module AST
+  # This class includes {AST::Processor::Mixin}; however, it is
+  # deprecated, since the module defines all of the behaviors that
+  # the processor includes.  Any new libraries should use
+  # {AST::Processor::Mixin} instead of subclassing this.
+  #
+  # @deprecated Use {AST::Processor::Mixin} instead.
+  class Processor
+    require 'ast/processor/mixin'
+    include Mixin
+  end
+end

data/.bundle/ruby/3.0.0/gems/ast-2.4.2/lib/ast/processor/mixin.rb

@@ -0,0 +1,288 @@
+module AST
+  class Processor
+    # The processor module is a module which helps transforming one
+    # AST into another.  In a nutshell, the {#process} method accepts
+    # a {Node} and dispatches it to a handler corresponding to its
+    # type, and returns a (possibly) updated variant of the node.
+    #
+    # The processor module has a set of associated design patterns.
+    # They are best explained with a concrete example. Let's define a
+    # simple arithmetic language and an AST format for it:
+    #
+    # Terminals (AST nodes which do not have other AST nodes inside):
+    #
+    #   * `(integer <int-literal>)`,
+    #
+    # Nonterminals (AST nodes with other nodes as children):
+    #
+    #   * `(add <node> <node>)`,
+    #   * `(multiply <node> <node>)`,
+    #   * `(divide <node> <node>)`,
+    #   * `(negate <node>)`,
+    #   * `(store <node> <string-literal>)`: stores value of `<node>`
+    #     into a variable named `<string-literal>`,
+    #   * `(load <string-literal>)`: loads value of a variable named
+    #     `<string-literal>`,
+    #   * `(each <node> ...)`: computes each of the `<node>`s and
+    #     prints the result.
+    #
+    # All AST nodes have the same Ruby class, and therefore they don't
+    # know how to traverse themselves. (A solution which dynamically
+    # checks the type of children is possible, but is slow and
+    # error-prone.) So, a class including the module which knows how
+    # to traverse the entire tree should be defined.  Such classes
+    # have a handler for each nonterminal node which recursively
+    # processes children nodes:
+    #
+    #     require 'ast'
+    #
+    #     class ArithmeticsProcessor
+    #       include AST::Processor::Mixin
+    #       # This method traverses any binary operators such as (add)
+    #       # or (multiply).
+    #       def process_binary_op(node)
+    #         # Children aren't decomposed automatically; it is
+    #         # suggested to use Ruby multiple assignment expansion,
+    #         # as it is very convenient here.
+    #         left_expr, right_expr = *node
+    #
+    #         # AST::Node#updated won't change node type if nil is
+    #         # passed as a first argument, which allows to reuse the
+    #         # same handler for multiple node types using `alias'
+    #         # (below).
+    #         node.updated(nil, [
+    #           process(left_expr),
+    #           process(right_expr)
+    #         ])
+    #       end
+    #       alias_method :on_add,      :process_binary_op
+    #       alias_method :on_multiply, :process_binary_op
+    #       alias_method :on_divide,   :process_binary_op
+    #
+    #       def on_negate(node)
+    #         # It is also possible to use #process_all for more
+    #         # compact code if every child is a Node.
+    #         node.updated(nil, process_all(node))
+    #       end
+    #
+    #       def on_store(node)
+    #         expr, variable_name = *node
+    #
+    #         # Note that variable_name is not a Node and thus isn't
+    #         # passed to #process.
+    #         node.updated(nil, [
+    #           process(expr),
+    #           variable_name
+    #         ])
+    #       end
+    #
+    #       # (load) is effectively a terminal node, and so it does
+    #       # not need an explicit handler, as the following is the
+    #       # default behavior.  Essentially, for any nodes that don't
+    #       # have a defined handler, the node remains unchanged.
+    #       def on_load(node)
+    #         nil
+    #       end
+    #
+    #       def on_each(node)
+    #         node.updated(nil, process_all(node))
+    #       end
+    #     end
+    #
+    # Let's test our ArithmeticsProcessor:
+    #
+    #     include AST::Sexp
+    #     expr = s(:add, s(:integer, 2), s(:integer, 2))
+    #
+    #     p ArithmeticsProcessor.new.process(expr) == expr # => true
+    #
+    # As expected, it does not change anything at all. This isn't
+    # actually very useful, so let's now define a Calculator, which
+    # will compute the expression values:
+    #
+    #     # This Processor folds nonterminal nodes and returns an
+    #     # (integer) terminal node.
+    #     class ArithmeticsCalculator < ArithmeticsProcessor
+    #       def compute_op(node)
+    #         # First, node children are processed and then unpacked
+    #         # to local variables.
+    #         nodes = process_all(node)
+    #
+    #         if nodes.all? { |node| node.type == :integer }
+    #           # If each of those nodes represents a literal, we can
+    #           # fold this node!
+    #           values = nodes.map { |node| node.children.first }
+    #           AST::Node.new(:integer, [
+    #             yield(values)
+    #           ])
+    #         else
+    #           # Otherwise, we can just leave the current node in the
+    #           # tree and only update it with processed children
+    #           # nodes, which can be partially folded.
+    #           node.updated(nil, nodes)
+    #         end
+    #       end
+    #
+    #       def on_add(node)
+    #         compute_op(node) { |left, right| left + right }
+    #       end
+    #
+    #       def on_multiply(node)
+    #         compute_op(node) { |left, right| left * right }
+    #       end
+    #     end
+    #
+    # Let's check:
+    #
+    #     p ArithmeticsCalculator.new.process(expr) # => (integer 4)
+    #
+    # Excellent, the calculator works! Now, a careful reader could
+    # notice that the ArithmeticsCalculator does not know how to
+    # divide numbers. What if we pass an expression with division to
+    # it?
+    #
+    #     expr_with_division = \
+    #       s(:add,
+    #         s(:integer, 1),
+    #         s(:divide,
+    #           s(:add, s(:integer, 8), s(:integer, 4)),
+    #           s(:integer, 3))) # 1 + (8 + 4) / 3
+    #
+    #     folded_expr_with_division = ArithmeticsCalculator.new.process(expr_with_division)
+    #     p folded_expr_with_division
+    #     # => (add
+    #     #      (integer 1)
+    #     #      (divide
+    #     #        (integer 12)
+    #     #        (integer 3)))
+    #
+    # As you can see, the expression was folded _partially_: the inner
+    # `(add)` node which could be computed was folded to
+    # `(integer 12)`, the `(divide)` node is left as-is because there
+    # is no computing handler for it, and the root `(add)` node was
+    # also left as it is because some of its children were not
+    # literals.
+    #
+    # Note that this partial folding is only possible because the
+    # _data_ format, i.e. the format in which the computed values of
+    # the nodes are represented, is the same as the AST itself.
+    #
+    # Let's extend our ArithmeticsCalculator class further.
+    #
+    #     class ArithmeticsCalculator
+    #       def on_divide(node)
+    #         compute_op(node) { |left, right| left / right }
+    #       end
+    #
+    #       def on_negate(node)
+    #         # Note how #compute_op works regardless of the operator
+    #         # arity.
+    #         compute_op(node) { |value| -value }
+    #       end
+    #     end
+    #
+    # Now, let's apply our renewed ArithmeticsCalculator to a partial
+    # result of previous evaluation:
+    #
+    #     p ArithmeticsCalculator.new.process(expr_with_division) # => (integer 5)
+    #
+    # Five! Excellent. This is also pretty much how CRuby 1.8 executed
+    # its programs.
+    #
+    # Now, let's do some automated bug searching. Division by zero is
+    # an error, right? So if we could detect that someone has divided
+    # by zero before the program is even run, that could save some
+    # debugging time.
+    #
+    #     class DivisionByZeroVerifier < ArithmeticsProcessor
+    #       class VerificationFailure < Exception; end
+    #
+    #       def on_divide(node)
+    #         # You need to process the children to handle nested divisions
+    #         # such as:
+    #         # (divide
+    #         #   (integer 1)
+    #         #   (divide (integer 1) (integer 0))
+    #         left, right = process_all(node)
+    #
+    #         if right.type == :integer &&
+    #            right.children.first == 0
+    #           raise VerificationFailure, "Ouch! This code divides by zero."
+    #         end
+    #       end
+    #
+    #       def divides_by_zero?(ast)
+    #         process(ast)
+    #         false
+    #       rescue VerificationFailure
+    #         true
+    #       end
+    #     end
+    #
+    #     nice_expr = \
+    #       s(:divide,
+    #         s(:add, s(:integer, 10), s(:integer, 2)),
+    #         s(:integer, 4))
+    #
+    #     p DivisionByZeroVerifier.new.divides_by_zero?(nice_expr)
+    #     # => false. Good.
+    #
+    #     bad_expr = \
+    #       s(:add, s(:integer, 10),
+    #         s(:divide, s(:integer, 1), s(:integer, 0)))
+    #
+    #     p DivisionByZeroVerifier.new.divides_by_zero?(bad_expr)
+    #     # => true. WHOOPS. DO NOT RUN THIS.
+    #
+    # Of course, this won't detect more complex cases... unless you
+    # use some partial evaluation before! The possibilites are
+    # endless. Have fun.
+    module Mixin
+      # Dispatches `node`. If a node has type `:foo`, then a handler
+      # named `on_foo` is invoked with one argument, the `node`; if
+      # there isn't such a handler, {#handler_missing} is invoked
+      # with the same argument.
+      #
+      # If the handler returns `nil`, `node` is returned; otherwise,
+      # the return value of the handler is passed along.
+      #
+      # @param  [AST::Node, nil] node
+      # @return [AST::Node, nil]
+      def process(node)
+        return if node.nil?
+
+        node = node.to_ast
+
+        # Invoke a specific handler
+        on_handler = :"on_#{node.type}"
+        if respond_to? on_handler
+          new_node = send on_handler, node
+        else
+          new_node = handler_missing(node)
+        end
+
+        node = new_node if new_node
+
+        node
+      end
+
+      # {#process}es each node from `nodes` and returns an array of
+      # results.
+      #
+      # @param  [Array<AST::Node>] nodes
+      # @return [Array<AST::Node>]
+      def process_all(nodes)
+        nodes.to_a.map do |node|
+          process node
+        end
+      end
+
+      # Default handler. Does nothing.
+      #
+      # @param  [AST::Node] node
+      # @return [AST::Node, nil]
+      def handler_missing(node)
+      end
+    end
+  end
+end

data/.bundle/ruby/3.0.0/gems/ast-2.4.2/lib/ast/sexp.rb

@@ -0,0 +1,30 @@
+module AST
+  # This simple module is very useful in the cases where one needs
+  # to define deeply nested ASTs from Ruby code, for example, in
+  # tests. It should be used like this:
+  #
+  #     describe YourLanguage::AST do
+  #       include Sexp
+  #
+  #       it "should correctly parse expressions" do
+  #         YourLanguage.parse("1 + 2 * 3").should ==
+  #             s(:add,
+  #               s(:integer, 1),
+  #               s(:multiply,
+  #                 s(:integer, 2),
+  #                 s(:integer, 3)))
+  #       end
+  #     end
+  #
+  # This way the amount of boilerplate code is greatly reduced.
+  module Sexp
+    # Creates a {Node} with type `type` and children `children`.
+    # Note that the resulting node is of the type AST::Node and not a
+    # subclass.
+    # This would not pose a problem with comparisons, as {Node#==}
+    # ignores metadata.
+    def s(type, *children)
+      Node.new(type, children)
+    end
+  end
+end

data/.bundle/ruby/3.0.0/gems/diff-lcs-1.4.4/.rspec

@@ -0,0 +1 @@
+--colour

data/.bundle/ruby/3.0.0/gems/diff-lcs-1.4.4/Code-of-Conduct.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at [INSERT EMAIL ADDRESS]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

data/.bundle/ruby/3.0.0/gems/diff-lcs-1.4.4/Contributing.md

@@ -0,0 +1,118 @@
+## Contributing
+
+I value any contribution to Diff::LCS you can provide: a bug report, a
+feature request, or code contributions. Code contributions to Diff::LCS are
+especially <del>welcome</del>encouraged. Because Diff::LCS is a complex
+codebase, there are a few guidelines:
+
+- Code changes _will not_ be accepted without tests. The test suite is
+  written with [RSpec][].
+- Match my coding style.
+- Use a thoughtfully-named topic branch that contains your change. Rebase
+  your commits into logical chunks as necessary.
+- Use [quality commit messages][].
+- Do not change the version number; when your patch is accepted and a release
+  is made, the version will be updated at that point.
+- Submit a GitHub pull request with your changes.
+- New or changed behaviours require appropriate documentation.
+
+### Test Dependencies
+
+Diff::LCS uses Ryan Davis’s [Hoe][] to manage the release process, and it
+adds a number of rake tasks. You will mostly be interested in:
+
+```sh
+$ rake
+```
+
+which runs the tests the same way that:
+
+```sh
+$ rake spec
+```
+
+will do.
+
+To assist with the installation of the development dependencies, I have
+provided a Gemfile pointing to the (generated) `diff-lcs.gemspec` file. This
+will permit you to do:
+
+```sh
+$ bundle install
+```
+
+to get the development dependencies. If you aleady have `hoe` installed, you
+can accomplish the same thing with:
+
+```sh
+$ rake newb
+```
+
+This task will install any missing dependencies, run the tests/specs, and
+generate the RDoc.
+
+You can run tests with code coverage analysis by running:
+
+```sh
+$ rake spec:coverage
+```
+
+### Workflow
+
+Here's the most direct way to get your work merged into the project:
+
+- Fork the project.
+- Clone down your fork (`git clone git://github.com/<username>/diff-lcs.git`).
+- Create a topic branch to contain your change (`git checkout -b my_awesome_feature`).
+- Hack away, add tests. Not necessarily in that order.
+- Make sure everything still passes by running `rake`.
+- If necessary, rebase your commits into logical chunks, without errors.
+- Push the branch up (`git push origin my_awesome_feature`).
+- Create a pull request against halostatue/diff-lcs and describe what your
+  change does and the why you think it should be merged.
+
+### Contributors
+
+- Austin Ziegler created Diff::LCS.
+
+Thanks to everyone else who has contributed code or bug reports to Diff::LCS:
+
+- @ginriki
+- @joshbronson
+- @kevinmook
+- @mckaz
+- Akinori Musha
+- Artem Ignatyev
+- Brandon Fish
+- Camille Drapier
+- Cédric Boutillier
+- Gregg Kellogg
+- Jagdeep Singh
+- Jason Gladish
+- Jon Rowe
+- Josef Strzibny
+- Josep (@apuratepp)
+- Josh Bronson
+- Jun Aruga
+- Kenichi Kamiya
+- Kensuke Nagae
+- Kevin Ansfield
+- Koichi Ito
+- Mark Friedgan
+- Michael Granger
+- Myron Marston
+- Nicolas Leger
+- Oleg Orlov
+- Paul Kunysch
+- Pete Higgins
+- Peter Wagenet
+- Philippe Lafoucrière
+- Ryan Lovelett
+- Scott Steele
+- Simon Courtois
+- Tomas Jura
+- Vít Ondruch
+
+[rspec]: http://rspec.info/documentation/
+[quality commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
+[hoe]: https://github.com/seattlerb/hoe