Helper methods for both Gem::Installer and Gem::Uninstaller
FIXME: This isn’t documented in Nutshell.
Since MonitorMixin.new_cond returns a ConditionVariable, and the example above calls while_wait and signal, this class should be documented.
Subclass of StreamUI that instantiates the user interaction using $stdin, $stdout, and $stderr.
ConditionVariable objects augment class Mutex. Using condition variables, it is possible to suspend while in the middle of a critical section until a condition is met, such as a resource becomes available.
Due to non-deterministic scheduling and spurious wake-ups, users of condition variables should always use a separate boolean predicate (such as reading from a boolean variable) to check if the condition is actually met before starting to wait, and should wait in a loop, re-checking the condition every time the ConditionVariable is waken up. The idiomatic way of using condition variables is calling the wait method in an until loop with the predicate as the loop condition.
condvar.wait(mutex) until condition_is_met
In the example below, we use the boolean variable resource_available (which is protected by mutex) to indicate the availability of the resource, and use condvar to wait for that variable to become true. Note that:
Thread b may be scheduled before thread a1 and a2, and may run so fast that it have already made the resource available before either a1 or a2 starts. Therefore, a1 and a2 should check if resource_available is already true before starting to wait.
The wait method may spuriously wake up without signalling. Therefore, thread a1 and a2 should recheck resource_available after the wait method returns, and go back to wait if the condition is not actually met.
It is possible that thread a2 starts right after thread a1 is waken up by b. Thread a2 may have acquired the mutex and consumed the resource before thread a1 acquires the mutex. This necessitates rechecking after wait, too.
Example:
mutex = Thread::Mutex.new resource_available = false condvar = Thread::ConditionVariable.new a1 = Thread.new { # Thread 'a1' waits for the resource to become available and consumes # the resource. mutex.synchronize { condvar.wait(mutex) until resource_available # After the loop, 'resource_available' is guaranteed to be true. resource_available = false puts "a1 consumed the resource" } } a2 = Thread.new { # Thread 'a2' behaves like 'a1'. mutex.synchronize { condvar.wait(mutex) until resource_available resource_available = false puts "a2 consumed the resource" } } b = Thread.new { # Thread 'b' periodically makes the resource available. loop { mutex.synchronize { resource_available = true # Notify one waiting thread if any. It is possible that neither # 'a1' nor 'a2 is waiting on 'condvar' at this moment. That's OK. condvar.signal } sleep 1 } } # Eventually both 'a1' and 'a2' will have their resources, albeit in an # unspecified order. [a1, a2].each {|th| th.join}
Raised when memory allocation fails.
Configuration for the openssl library.
Many system’s installation of openssl library will depend on your system configuration. See the value of OpenSSL::Config::DEFAULT_CONFIG_FILE for the location of the file for your host.
General error for openssl library configuration files. Including formatting, parsing errors, etc.
Response class for Continue responses (status code 100).
A Continue response indicates that the server has received the request headers.
References:
Response class for No Content responses (status code 204).
The No Content response indicates that the server successfully processed the request, and is not returning any content.
References:
Response class for Partial Content responses (status code 206).
The Partial Content response indicates that the server is delivering only part of the resource (byte serving) due to a Range header in the request.
References:
Response class for Conflict responses (status code 409).
The request could not be processed because of conflict in the current state of the resource.
References:
Response class for Insufficient Storage (WebDAV) responses (status code 507).
The server is unable to store the representation needed to complete the request.
References:
Gem::ConfigFile RubyGems options and gem command options from gemrc.
gemrc is a YAML file that uses strings to match gem command arguments and symbols to match RubyGems options.
Gem command arguments use a String key that matches the command name and allow you to specify default arguments:
install: --no-rdoc --no-ri update: --no-rdoc --no-ri
You can use gem: to set default arguments for all commands.
RubyGems options use symbol keys. Valid options are:
:backtraceSee backtrace
:sourcesSets Gem::sources
:verboseSee verbose
:concurrent_downloadsgemrc files may exist in various locations and are read and merged in the following order:
system wide (/etc/gemrc)
per user (~/.gemrc)
per environment (gemrc files listed in the GEMRC environment variable)
Installs a gem along with all its dependencies from local and remote gems.
Raised when there are conflicting gem specs loaded
Raised when removing a gem with the uninstall command fails
Potentially raised when a specification is validated.
The installer installs the files contained in the .gem into the Gem.home.
Gem::Installer does the work of putting files in all the right places on the filesystem including unpacking the gem into its gem dir, installing the gemspec in the specifications dir, storing the cached gem in the cache dir, and installing either wrappers or symlinks for executables.
The installer invokes pre and post install hooks. Hooks can be added either through a rubygems_plugin.rb file in an installed gem or via a rubygems/defaults/#{RUBY_ENGINE}.rb or rubygems/defaults/operating_system.rb file. See Gem.pre_install and Gem.post_install for details.
Gem::StubSpecification reads the stub: line from the gemspec. This prevents us having to eval the entire gemspec in order to find out certain information.