rubyjobbuilderdsl 0.0.0 → 0.0.1

data/vendor/bundle/ruby/2.1.0/gems/nokogiri-1.6.3.1-x64-mingw32/Y_U_NO_GEMSPEC.md

@@ -0,0 +1,155 @@
+(note: this was originally a blog post published at http://blog.flavorjon.es/2012/03/y-u-no-gemspec.html)
+
+## tl;dr
+
+1. Team Nokogiri are not 10-foot-tall code-crunching robots, so `master` is usually unstable.
+2. Unstable code can corrupt your data and crash your application, which would make everybody look bad.
+3. Therefore, the _risk_ associated with using unstable code is severe; for you _and_ for Team Nokogiri.
+4. The absence of a gemspec is a risk mitigation tactic.
+5. You can always ask for an RC release.
+
+
+## Why Isn't There a Gemspec!?
+
+OHAI! Thank you for asking this question!
+
+Team Nokogiri gets asked this pretty frequently. Just a sample from
+the historical record:
+
+* [Issue #274](https://github.com/sparklemotion/nokogiri/issues/274)
+* [Issue #371](https://github.com/sparklemotion/nokogiri/issues/371)
+* [A commit removing nokogiri.gemspec](https://github.com/sparklemotion/nokogiri/commit/7f17a643a05ca381d65131515b54d4a3a61ca2e1#commitcomment-667477)
+* [A nokogiri-talk thread](http://groups.google.com/group/nokogiri-talk/browse_thread/thread/4706b002e492d23f)
+* [Another nokogiri-talk thread](http://groups.google.com/group/nokogiri-talk/browse_thread/thread/0b201bb80ea3eea0)
+
+Sometimes people imply that we've forgotten, or that we don't how to
+properly manage our codebase. Those people are super fun to respond
+to!
+
+We've gone back and forth a couple of times over the past few years,
+but the current policy of Team Nokogiri is to **not** provide a
+gemspec in the Github repo. This is a conscious choice, not an
+oversight.
+
+
+## But You Didn't Answer the Question!
+
+Ah, I was hoping you wouldn't notice. Well, OK, let's do this, if
+you're serious about it.
+
+I'd like to start by talking about _risk_. Specifically, the risk
+associated with using a known-unstable version of Nokogiri.
+
+
+### Risk
+
+One common way to evaluate the _risk_ of an incident is:
+
+    risk = probability x impact
+
+You can read more about this on [the internets](http://en.wikipedia.org/wiki/Risk_Matrix).
+
+The _risk_ associated with a Nokogiri bug could be loosely defined by
+answering the questions:
+
+* "How likely is it that a bug exists?" (probability)
+* "How severe will the consequences of a bug be?" (impact)
+
+
+### Probability
+
+The `master` branch should be considered unstable. Team Nokogiri are
+not 10-foot-tall code-crunching robots; we are humans. We make
+mistakes, and as a result, any arbitrary commit on `master` is likely
+to contain bugs.
+
+Just as an example, Nokogiri `master` was unstable for about five
+months between November 2011 and March 2012. It was unstable not
+because we were sloppy, or didn't care, but because the fixes were
+hard and unobvious.
+
+When we release Nokogiri, we test for memory leaks and invalid memory
+access on all kinds of platforms with many flavors of Ruby and lots of
+versions of libxml2. Because these tests are time-consuming, we don't
+run them on every commit. We run them often when preparing a release.
+
+If we're releasing Nokogiri, it means we think it's rock solid.
+
+And if we're not releasing it, it means there are probably bugs.
+
+
+### Impact
+
+Nokogiri is a gem with native extensions. This means it's not pure
+Ruby -- there's C or Java code being compiled and run, which means
+that there's always a chance that the gem will crash your application,
+or worse. Possible outcomes include:
+
+* leaking memory
+* corrupting data
+* making benign code crash (due to memory corruption)
+
+So, then, a bug in a native extension can have much worse downside
+than you might think. It's not just going to do something unexpected;
+it's possibly going to do terrible, awful things to your application
+and data.
+
+**Nobody** wants that to happen. Especially Team Nokogiri.
+
+
+### Risk, Redux
+
+So, if you accept the equation
+
+    risk = probability x impact
+
+and you believe me when I say that:
+
+* the probablility of a bug in unreleased code is high, and
+* the impact of a bug is likely to be severe,
+
+then you should easily see that the _risk_ associated with a bug in
+Nokogiri is quite high.
+
+Part of Team Nokogiri's job is to try to mitigate this risk. We have a
+number of tactics that we use to accomplish this:
+
+* we respond quickly to bug reports, particularly when they are possible memory issues
+* we review each others' commits
+* we have a thorough test suite, and we test-drive new features
+* we discuss code design and issues on a core developer mailing list
+* we use valgrind to test for memory issues (leaks and invalid
+  access) on multiple combinations of OS, libxml2 and Ruby
+* we package release candidates, and encourage devs to use them
+* **we do NOT commit a gemspec in our git repository**
+
+Yes, that's right, the absence of a gemspec is a risk mitigation
+tactic. Not only does Team Nokogiri not want to imply support for
+`master`, we want to **actively discourage** people from using
+it. Because it's not stable.
+
+
+## But I Want to Do It Anyway
+
+Another option, is to email the [nokogiri-talk
+list](http://groups.google.com/group/nokogiri-talk) and ask for a
+release candidate to be built. We're pretty accommodating if there's a
+bugfix that's a blocker for you. And if we can't release an RC, we'll
+tell you why.
+
+And in the end, nothing is stopping you from cloning the repo and
+generating a private gemspec. This is an extra step or two, but it has
+the benefit of making sure developers have thought through the costs
+and risks involved; and it tends to select for developers who know
+what they're doing.
+
+
+## In Conclusion
+
+Team Nokogiri takes stability very seriously. We want everybody who
+uses Nokogiri to have a pleasant experience. And so we want to make
+sure that you're using the best software we can make.
+
+Please keep in mind that we're trying very hard to do the right thing
+for all Nokogiri users out there in Rubyland. Nokogiri loves you very
+much, and we hope you love it back.

data/vendor/bundle/ruby/2.1.0/gems/nokogiri-1.6.3.1-x64-mingw32/bin/nokogiri

@@ -0,0 +1,78 @@
+#!/usr/bin/env ruby
+require 'optparse'
+require 'open-uri'
+require 'irb'
+require 'uri'
+require 'rubygems'
+require 'nokogiri'
+
+parse_class = Nokogiri
+encoding = nil
+
+opts = OptionParser.new do |opts|
+  opts.banner = "Nokogiri: an HTML, XML, SAX, and Reader parser"
+  opts.define_head "Usage: nokogiri <uri|path> [options]"
+  opts.separator ""
+  opts.separator "Examples:"
+  opts.separator "  nokogiri http://www.ruby-lang.org/"
+  opts.separator "  nokogiri ./public/index.html"
+  opts.separator "  curl -s http://nokogiri.org | nokogiri -e'p $_.css(\"h1\").length'"
+  opts.separator ""
+  opts.separator "Options:"
+
+  opts.on("--type [TYPE]", [:xml, :html]) do |v|
+    parse_class = {:xml => Nokogiri::XML, :html => Nokogiri::HTML}[v]
+  end
+
+  opts.on("-E", "--encoding encoding", "Read as encoding (default #{encoding})") do |v|
+    encoding = v
+  end
+
+  opts.on("-e command", "Specifies script from command-line.") do |v|
+    @script = v
+  end
+
+  opts.on("--rng <uri|path>", "Validate using this rng file.") do |v|
+    @rng = open(v) {|f| Nokogiri::XML::RelaxNG(f)}
+  end
+
+  opts.on_tail("-?", "--help", "Show this message") do
+    puts opts
+    exit
+  end
+
+  opts.on_tail("-v", "--version", "Show version") do
+    puts Nokogiri::VersionInfo.instance.to_markdown
+    exit
+  end
+end
+opts.parse!
+
+uri = ARGV.shift
+
+if uri.to_s.strip.empty? && $stdin.tty?
+  puts opts
+  exit 1
+end
+
+if $stdin.tty?
+  @doc = parse_class.parse(open(uri).read, nil, encoding)
+else
+  @doc = parse_class.parse($stdin, nil, encoding)
+end
+
+$_ = @doc
+
+if @rng
+  @rng.validate(@doc).each do |error|
+    puts error.message
+  end
+else
+  if @script
+    eval @script, binding, '<main>'
+  else
+    puts "Your document is stored in @doc..."
+    IRB.start
+  end
+end
+

data/vendor/bundle/ruby/2.1.0/gems/nokogiri-1.6.3.1-x64-mingw32/build_all

@@ -0,0 +1,129 @@
+#! /usr/bin/env bash
+#
+#  script to build gems for all relevant platforms:
+#  - MRI et al (standard gem)
+#  - windows (x86-mingw32 and x64-mingw32)
+#  - jruby
+#
+#  here's what I recommend for building all the gems:
+#
+#  set up a rake-compiler-dev-box as described here:
+#      https://github.com/tjschuck/rake-compiler-dev-box
+#  It is prepared with all the necessary build tools and environments.
+#
+#  or alternatively do:
+#   1. Setup a ubuntu 12.04+ machine
+#   2. install rvm, and install 1.9.3, 2.0.0 and jruby.
+#   3. `sudo apt-get install mingw32 gcc-mingw-w64-i686 gcc-mingw-w64-x86-64`
+#
+#  as you build, you may run into these problems:
+#
+#  - if you're using Virtualbox shared directories, you'll get a mingw
+#    "Protocol error" at linktime. Boo! Either use NFS or a
+#    locally-checked-out repository.
+#
+#  - on ubuntus 11 and later, you may have issues with building
+#    rake-compiler's rubies against openssl v2. Just comment the lines
+#    out from ossl_ssl.c and you'll be fine.
+#
+#  - you may have issues with Pathname conversion to String in
+#    bundler. Add this to the offending bundler file:
+#
+#      class Pathname
+#        def to_str
+#          to_s
+#        end
+#      end
+#
+#  - you may also have to hack rubygems.rb to eliminate a reference to
+#    RUBY_ENGINE (just comment it out)
+#
+
+DEFAULT_RUBY=2.0.0
+
+HOST=
+
+# Load RVM into a shell session *as a function*
+if [[ -s "$HOME/.rvm/scripts/rvm" ]] ; then
+    source "$HOME/.rvm/scripts/rvm"
+elif [[ -s "/usr/local/rvm/scripts/rvm" ]] ; then
+    source "/usr/local/rvm/scripts/rvm"
+else
+    echo "ERROR: An RVM installation was not found.\n"
+fi
+
+rvm_use () {
+    current_ruby=$1
+    rvm use "${1}@nokogiri" --create || rvm -v
+}
+
+rvm_do () {
+    local ver=$1
+    shift
+    rvm "${ver}@nokogiri" do "$@"
+}
+
+cross_rubies () {
+    grep -v '#' .cross_rubies
+}
+
+ruby_vers () {
+    cross_rubies | while read -r line; do
+        echo "${line%%[-:]*}"
+    done | uniq
+}
+
+set -o errexit
+
+for ver in `ruby_vers`; do
+    rvm_use $ver
+    gem install bundler --conservative
+    bundle install --quiet --local || bundle install
+done
+
+rvm_use $DEFAULT_RUBY
+
+rm -rf tmp pkg
+bundle exec rake clean
+
+# holding pen
+rm -rf gems
+mkdir -p gems
+
+# windows
+for verspec in `cross_rubies`; do
+    version="${verspec%%:*}"
+    ver="${version%%-*}"
+    host="${verspec#*:}"
+
+    case $ver in
+        1.9.3)
+            # Parallel make does not work in 1.9.3, as it has a
+            # missing dependency problem with main.o.
+            make="make"
+            ;;
+        *)
+            make="$MAKE"
+    esac
+
+    MAKE="$make" rvm_do $ver rake-compiler cross-ruby VERSION=$version HOST=$host debugflags="-g"
+done
+
+bundle exec rake gem:windows
+cp -v pkg/nokogiri*{x86,x64}-mingw32*.gem gems
+
+# MRI
+bundle exec rake clean
+bundle exec rake gem
+cp -v pkg/nokogiri*.gem gems
+
+# jruby
+rvm_use jruby
+gem install bundler --conservative
+bundle install --quiet --local || bundle install
+bundle exec rake clean clobber
+rvm_use $DEFAULT_RUBY
+bundle exec rake generate
+rvm_use jruby
+bundle exec rake gem
+cp -v pkg/nokogiri*java.gem gems

data/vendor/bundle/ruby/2.1.0/gems/nokogiri-1.6.3.1-x64-mingw32/dependencies.yml

@@ -0,0 +1,4 @@
+libxml2: "2.8.0"
+libxslt: "1.1.28"
+zlib: "1.2.8"
+libiconv: "1.14"