Potentially raised when a specification is validated.
Signals that a file permission error is preventing the user from operating on the given directory.
Used to raise parsing and loading errors
Raised by Resolver when a dependency requests a gem for which there is no spec.
The SourceList represents the sources rubygems has been configured to use. A source may be created from an array of sources:
Gem::SourceList.from %w[https://rubygems.example https://internal.example]
Or by adding them:
sources = Gem::SourceList.new sources << 'https://rubygems.example'
The most common way to get a SourceList is Gem.sources.
The Specification class contains the information for a Gem. Typically defined in a .gemspec file or a Rakefile, and looks like this:
Gem::Specification.new do |s| s.name = 'example' s.version = '0.1.0' s.licenses = ['MIT'] s.summary = "This is an example!" s.description = "Much longer explanation of the example!" s.authors = ["Ruby Coder"] s.email = 'rubycoder@example.com' s.files = ["lib/example.rb"] s.homepage = 'https://rubygems.org/gems/example' end
Starting in RubyGems 2.0, a Specification can hold arbitrary metadata. See metadata for restrictions on the format and size of metadata items you may add to a specification.
RubyGemTestCase provides a variety of methods for testing rubygems and gem-related behavior in a sandbox. Through RubyGemTestCase you can install and uninstall gems, fetch remote gems through a stub fetcher and be assured your normal set of gems is not affected.
Tests are always run at a safe level of 1.
In order to execute a command on your OS, you need to define it as a Shell method.
Alternatively, you can execute any command via Shell::CommandProcessor#system even if it is not defined.
Processes HTTP cookies
Process::Status encapsulates the information on the status of a running or terminated system process. The built-in variable $? is either nil or a Process::Status object.
fork { exit 99 } #=> 26557 Process.wait #=> 26557 $?.class #=> Process::Status $?.to_i #=> 25344 $? >> 8 #=> 99 $?.stopped? #=> false $?.exited? #=> true $?.exitstatus #=> 99
Posix systems record information on processes using a 16-bit integer. The lower bits record the process status (stopped, exited, signaled) and the upper bits possibly contain additional information (for example the program’s return code in the case of exited processes). Pre Ruby 1.8, these bits were exposed directly to the Ruby program. Ruby now encapsulates these in a Process::Status object. To maximize compatibility, however, these objects retain a bit-oriented interface. In the descriptions that follow, when we talk about the integer value of stat, we’re referring to this 16 bit value.
Used to construct C classes (CUnion, CStruct, etc)
Fiddle::Importer#struct and Fiddle::Importer#union wrap this functionality in an easy-to-use manner.
Module managing the underlying network protocol(s) used by drb.
By default, drb uses the DRbTCPSocket protocol. Other protocols can be defined. A protocol must define the following class methods:
[open(uri, config)] Open a client connection to the server at +uri+,
using configuration +config+. Return a protocol
instance for this connection.
[open_server(uri, config)] Open a server listening at +uri+,
using configuration +config+. Return a
protocol instance for this listener.
[uri_option(uri, config)] Take a URI, possibly containing an option
component (e.g. a trailing '?param=val'),
and return a [uri, option] tuple.
All of these methods should raise a DRbBadScheme error if the URI does not identify the protocol they support (e.g. “druby:” for the standard Ruby protocol). This is how the DRbProtocol module, given a URI, determines which protocol implementation serves that protocol.
The protocol instance returned by open_server must have the following methods:
Accept a new connection to the server. Returns a protocol instance capable of communicating with the client.
Close the server connection.
Get the URI for this server.
The protocol instance returned by open must have the following methods:
Send a request to ref with the given message id and arguments. This is most easily implemented by calling DRbMessage.send_request, providing a stream that sits on top of the current protocol.
Receive a reply from the server and return it as a [success-boolean, reply-value] pair. This is most easily implemented by calling DRb.recv_reply, providing a stream that sits on top of the current protocol.
Is this connection still alive?
Close this connection.
The protocol instance returned by open_server().accept() must have the following methods:
Receive a request from the client and return a [object, message, args, block] tuple. This is most easily implemented by calling DRbMessage.recv_request, providing a stream that sits on top of the current protocol.
Send a reply to the client. This is most easily implemented by calling DRbMessage.send_reply, providing a stream that sits on top of the current protocol.
Close this connection.
A new protocol is registered with the DRbProtocol module using the add_protocol method.
For examples of other protocols, see DRbUNIXSocket in drb/unix.rb, and HTTP0 in sample/http0.rb and sample/http0serv.rb in the full drb distribution.
A template for stream parser listeners. Note that the declarations (attlistdecl, elementdecl, etc) are trivially processed; REXML doesn’t yet handle doctype entity declarations, so you have to parse them out yourself.
ignorable_whitespace
WARNING These methods are certainly going to change, until DTDs are fully supported. Be aware of this.
start_document end_document doctype elementdecl attlistdecl entitydecl notationdecl cdata xmldecl comment
Defines a number of tokens used for parsing XML. Not for general consumption.