Response class for Internal Server Error responses (status code 500).
An unexpected condition was encountered and no more specific message is suitable.
References:
This represents an error that was encountered during parsing.
This represents a warning that was encountered during parsing.
This is a result specific to the parse and parse_file methods.
Raised when trying to activate a gem, and the gem exists on the system, but not the requested version. Instead of rescuing from this class, make sure to rescue from the superclass Gem::LoadError to catch all types of load errors.
Raised when attempting to uninstall a gem that isn’t in GEM_HOME.
Raised by Gem::Validator when something is not right in a gem.
Raised by Gem::WebauthnListener when an error occurs during security device verification.
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}
Mixin methods for install and update options for Gem::Commands
Mixin methods for local and remote Gem::Command options.
Socket::ResolutionError is the error class for hostname resolution.
The InstructionSequence class represents a compiled sequence of instructions for the Virtual Machine used in MRI. Not all implementations of Ruby may implement this class, and for the implementations that implement it, the methods defined and behavior of the methods can change in any version.
With it, you can get a handle to the instructions that make up a method or a proc, compile strings of Ruby code down to VM instructions, and disassemble instruction sequences to strings for easy inspection. It is mostly useful if you want to learn how YARV works, but it also lets you control various settings for the Ruby iseq compiler.
You can find the source for the VM instructions in insns.def in the Ruby source.
The instruction sequence results will almost certainly change as Ruby changes, so example output in this documentation may be different from what you see.
Of course, this class is MRI specific.
Parent class for server error (5xx) HTTP response classes.
A server error response indicates that the server failed to fulfill a request.
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 Proxy Authentication Required responses (status code 407).
The client must first authenticate itself with the proxy.
References:
Response class for Precondition Failed responses (status code 412).
The server does not meet one of the preconditions specified in the request headers.
References:
Response class for Precondition Required responses (status code 428).
The origin server requires the request to be conditional.
References:
Response class for HTTP Version Not Supported responses (status code 505).
The server does not support the HTTP version used in the request.
References:
Response class for Network Authentication Required responses (status code 511).
The client needs to authenticate to gain network access.
References: