Error
raised upon an unknown response from the server.
Represents a specification retrieved via the rubygems.org API.
This is used to avoid loading the full Specification object when all we need is the name, version, and dependencies.
A GitSpecification
represents a gem that is sourced from a git repository and is being loaded through a gem dependencies file through the git:
option.
Represents a possible Specification object returned from IndexSet. Used to delay needed to download full Specification objects when only the name
and version
are needed.
An InstalledSpecification
represents a gem that is already installed locally.
A set of gems for installation sourced from remote sources and local .gem files
A LocalSpecification
comes from a .gem file on the local filesystem.
The LockSpecification
comes from a lockfile (Gem::RequestSet::Lockfile
).
A LockSpecification’s dependency information is pre-filled from the lockfile.
The Resolver::SpecSpecification contains common functionality for Resolver specifications that are backed by a Gem::Specification
.
A Resolver::Specification contains a subset of the information contained in a Gem::Specification
. Only the information necessary for dependency resolution in the resolver is included.
The SpecFetcherSetup
allows easy setup of a remote source in RubyGems tests:
spec_fetcher do |f| f.gem 'a', 1 f.spec 'a', 2 f.gem 'b', 1' 'a' => '~> 1.0' end
The above declaration creates two gems, a-1 and b-1, with a dependency from b to a. The declaration creates an additional spec a-2, but no gem for it (so it cannot be installed).
After the gems are created they are removed from Gem.dir
.
A progress reporter that prints out messages about the current progress.
An object representation of a stack frame, initialized by Kernel#caller_locations
.
For example:
# caller_locations.rb def a(skip) caller_locations(skip) end def b(skip) a(skip) end def c(skip) b(skip) end c(0..2).map do |call| puts call.to_s end
Running ruby caller_locations.rb
will produce:
caller_locations.rb:2:in `a' caller_locations.rb:5:in `b' caller_locations.rb:8:in `c'
Here’s another example with a slightly different result:
# foo.rb class Foo attr_accessor :locations def initialize(skip) @locations = caller_locations(skip) end end Foo.new(0..2).locations.map do |call| puts call.to_s end
Now run ruby foo.rb
and you should see:
init.rb:4:in `initialize' init.rb:8:in `new' init.rb:8:in `<main>'
This abstract class provides a common interface to message digest implementation classes written in C.
Digest
subclass in C Digest::Base
provides a common interface to message digest classes written in C. These classes must provide a struct of type rb_digest_metadata_t:
typedef int (*rb_digest_hash_init_func_t)(void *); typedef void (*rb_digest_hash_update_func_t)(void *, unsigned char *, size_t); typedef int (*rb_digest_hash_finish_func_t)(void *, unsigned char *); typedef struct { int api_version; size_t digest_len; size_t block_len; size_t ctx_size; rb_digest_hash_init_func_t init_func; rb_digest_hash_update_func_t update_func; rb_digest_hash_finish_func_t finish_func; } rb_digest_metadata_t;
This structure must be set as an instance variable named metadata
(without the +@+ in front of the name). By example:
static const rb_digest_metadata_t sha1 = { RUBY_DIGEST_API_VERSION, SHA1_DIGEST_LENGTH, SHA1_BLOCK_LENGTH, sizeof(SHA1_CTX), (rb_digest_hash_init_func_t)SHA1_Init, (rb_digest_hash_update_func_t)SHA1_Update, (rb_digest_hash_finish_func_t)SHA1_Finish, }; rb_ivar_set(cDigest_SHA1, rb_intern("metadata"), Data_Wrap_Struct(0, 0, 0, (void *)&sha1));