spell checker for a dictionary that has a tree structure, see doc/tree_spell_checker_api.md
Error raised by a dRuby protocol when it doesn’t support the scheme specified in a URI
. See DRb::DRbProtocol
.
Response class for Switching Protocol
responses (status code 101).
The <tt>Switching Protocol<tt> response indicates that the server has received a request to switch protocols, and has agreed to do so.
References:
Response class for Multiple Choices
responses (status code 300).
The Multiple Choices
response indicates that the server offers multiple options for the resource from which the client may choose.
References:
Response class for Multiple Choices
responses (status code 300).
The Multiple Choices
response indicates that the server offers multiple options for the resource from which the client may choose.
References:
Individual switch class. Not important to the user.
Defined within Switch
are several Switch-derived classes: NoArgument
, RequiredArgument
, etc.
Represents the use of a case statement for pattern matching.
case true in false end ^^^^^^^^^
Represents a regular expression literal that contains interpolation that is being used in the predicate of a conditional to implicitly match against the last line read by an IO
object.
if /foo #{bar} baz/ then end ^^^^^^^^^^^^^^^^
Represents a regular expression literal used in the predicate of a conditional to implicitly match against the last line read by an IO
object.
if /foo/i then end ^^^^^^
Represents writing local variables using a regular expression match with named capture groups.
/(?<foo>bar)/ =~ baz ^^^^^^^^^^^^^^^^^^^^
Generated when trying to lookup a gem to indicate that the gem was found, but that it isn’t usable on the current platform.
fetch and install read these and report them to the user to aid in figuring out why a gem couldn’t be installed.
An error that indicates we weren’t able to fetch some data from a source
Raised when a gem dependencies file specifies a ruby version that does not match the current version.
RemoteFetcher
handles the details of fetching gems and gem information from a remote source.
SpecFetcher
handles metadata updates from remote gem repositories.
Searches code for a syntax error
There are three main phases in the algorithm:
Sanitize/format input source
Search for invalid blocks
Format invalid blocks into something meaninful
This class handles the part.
The bulk of the heavy lifting is done in:
- CodeFrontier (Holds information for generating blocks and determining if we can stop searching) - ParseBlocksFromLine (Creates blocks into the frontier) - BlockExpand (Expands existing blocks to search more code)
## Syntax error detection
When the frontier holds the syntax error, we can stop searching
search = CodeSearch.new(<<~EOM) def dog def lol end EOM search.call search.invalid_blocks.map(&:to_s) # => # => ["def lol\n"]
This is not an existing class, but documentation of the interface that Scheduler
object should comply to in order to be used as argument to Fiber.scheduler
and handle non-blocking fibers. See also the “Non-blocking fibers” section in Fiber
class docs for explanations of some concepts.
Scheduler’s behavior and usage are expected to be as follows:
When the execution in the non-blocking Fiber
reaches some blocking operation (like sleep, wait for a process, or a non-ready I/O), it calls some of the scheduler’s hook methods, listed below.
Scheduler
somehow registers what the current fiber is waiting on, and yields control to other fibers with Fiber.yield
(so the fiber would be suspended while expecting its wait to end, and other fibers in the same thread can perform)
At the end of the current thread execution, the scheduler’s method scheduler_close is called
The scheduler runs into a wait loop, checking all the blocked fibers (which it has registered on hook calls) and resuming them when the awaited resource is ready (e.g. I/O ready or sleep time elapsed).
This way concurrent execution will be achieved transparently for every individual Fiber’s code.
Scheduler
implementations are provided by gems, like Async.
Hook methods are:
io_wait
, io_read
, io_write
, io_pread
, io_pwrite
, and io_select
, io_close
(the list is expanded as Ruby developers make more methods having non-blocking calls)
When not specified otherwise, the hook implementations are mandatory: if they are not implemented, the methods trying to call hook will fail. To provide backward compatibility, in the future hooks will be optional (if they are not implemented, due to the scheduler being created for the older Ruby version, the code which needs this hook will not fail, and will just behave in a blocking fashion).
It is also strongly recommended that the scheduler implements the fiber
method, which is delegated to by Fiber.schedule
.
Sample toy implementation of the scheduler can be found in Ruby’s code, in test/fiber/scheduler.rb