Results for: "match"

Raised by Gem::Validator when something is not right in a gem.

Raised by Resolver when a dependency requests a gem for which there is no spec.

Gem::PathSupport facilitates the GEM_HOME and GEM_PATH environment settings to the rest of RubyGems.

Available list of platforms for targeting Gem installations.

See ‘gem help platform` for information on platform matching.

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'
  s.metadata    = { "source_code_uri" => "https://github.com/example/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.

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.

Validator performs various gem file and gem database validation

Searches code for a syntax error

There are three main phases in the algorithm:

1. Sanitize/format input source

2. Search for invalid blocks

3. 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"]

Converts a SyntaxError message to a path

Handles the case where the filename has a colon in it such as on a windows file system: github.com/ruby/syntax_suggest/issues/111

Example:

message = "/tmp/scratch:2:in `require_relative': /private/tmp/bad.rb:1: syntax error, unexpected `end' (SyntaxError)"
puts PathnameFromMessage.new(message).call.name
# => "/tmp/scratch.rb"

RFC6068, the mailto URL scheme.

Raised when a mathematical function is evaluated outside of its domain of definition.

For example, since cos returns values in the range -1..1, its inverse function acos is only defined on that interval:

Math.acos(42)

produces:

Math::DomainError: Numerical argument is out of domain - "acos"

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.

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

• process_wait

• kernel_sleep

• timeout_after

• address_resolve

• block and unblock

• (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

Commands will be placed in this namespace

Provides 3 methods for declaring when something is going away.

+deprecate(name, repl, year, month)+:

Indicate something may be removed on/after a certain date.

+rubygems_deprecate(name, replacement=:none)+:

Indicate something will be removed in the next major RubyGems version,
and (optionally) a replacement for it.

rubygems_deprecate_command:

Indicate a RubyGems command (in +lib/rubygems/commands/*.rb+) will be
removed in the next RubyGems version.

Also provides skip_during for temporarily turning off deprecation warnings. This is intended to be used in the test suite, so deprecation warnings don’t cause test failures if you need to make sure stderr is otherwise empty.

Example usage of deprecate and rubygems_deprecate:

class Legacy
  def self.some_class_method
    # ...
  end

  def some_instance_method
    # ...
  end

  def some_old_method
    # ...
  end

  extend Gem::Deprecate
  deprecate :some_instance_method, "X.z", 2011, 4
  rubygems_deprecate :some_old_method, "Modern#some_new_method"

  class << self
    extend Gem::Deprecate
    deprecate :some_class_method, :none, 2011, 4
  end
end

Example usage of rubygems_deprecate_command:

class Gem::Commands::QueryCommand < Gem::Command
  extend Gem::Deprecate
  rubygems_deprecate_command

  # ...
end

Example usage of skip_during:

class TestSomething < Gem::Testcase
  def test_some_thing_with_deprecations
    Gem::Deprecate.skip_during do
      actual_stdout, actual_stderr = capture_output do
        Gem.something_deprecated
      end
      assert_empty actual_stdout
      assert_equal(expected, actual_stderr)
    end
  end
end

Mixin methods for install and update options for Gem::Commands