Results for: "String#[]"

SyntaxSuggest::DisplayInvalidBlocks

Used for formatting invalid blocks

SyntaxSuggest::ExplainSyntax

Explains syntax errors based on their source

example:

source = "def foo; puts 'lol'" # Note missing end
explain ExplainSyntax.new(
  code_lines: CodeLine.from_source(source)
).call
explain.errors.first
# => "Unmatched keyword, missing `end' ?"

When the error cannot be determined by lexical counting then the parser is run against the input and the raw errors are returned.

Example:

source = "1 * " # Note missing a second number
explain ExplainSyntax.new(
  code_lines: CodeLine.from_source(source)
).call
explain.errors.first
# => "syntax error, unexpected end-of-input"

SyntaxSuggest::RipperErrors

Capture parse errors from Ripper

Prism returns the errors with their messages, but Ripper does not. To get them we must make a custom subclass.

Example:

puts RipperErrors.new(" def foo").call.errors
# => ["syntax error, unexpected end-of-input, expecting ';' or '\\n'"]

SyntaxSuggest::ScanHistory

Scans up/down from the given block

You can try out a change, stash it, or commit it to save for later

Example:

scanner = ScanHistory.new(code_lines: code_lines, block: block)
scanner.scan(
  up: ->(_, _, _) { true },
  down: ->(_, _, _) { true }
)
scanner.changed? # => true
expect(scanner.lines).to eq(code_lines)

scanner.stash_changes

expect(scanner.lines).to_not eq(code_lines)

SyntaxSuggest::UnvisitedLines

Tracks which lines various code blocks have expanded to and which are still unexplored

URI::Generic

Base class for all URI classes. Implements generic URI syntax as per RFC 2396.

YAML::Store

YAML::Store provides the same functionality as PStore, except it uses YAML to dump objects instead of Marshal.

Example

require 'yaml/store'

Person = Struct.new :first_name, :last_name

people = [Person.new("Bob", "Smith"), Person.new("Mary", "Johnson")]

store = YAML::Store.new "test.store"

store.transaction do
  store["people"] = people
  store["greeting"] = { "hello" => "world" }
end

After running the above code, the contents of “test.store” will be:

---
people:
- !ruby/struct:Person
  first_name: Bob
  last_name: Smith
- !ruby/struct:Person
  first_name: Mary
  last_name: Johnson
greeting:
  hello: world

Math::DomainError

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

A Process::Status contains information about a system process.

Thread-local variable $? is initially nil. Some methods assign to it a Process::Status object that represents a system process (either running or terminated):

`ruby -e "exit 99"`
stat = $?       # => #<Process::Status: pid 1262862 exit 99>
stat.class      # => Process::Status
stat.to_i       # => 25344
stat.stopped?   # => false
stat.exited?    # => true
stat.exitstatus # => 99

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}

Encoding::UndefinedConversionError

Raised by Encoding and String methods when a transcoding operation fails.

Encoding::InvalidByteSequenceError

Raised by Encoding and String methods when the string being transcoded contains a byte invalid for the either the source or target encoding.

Thread::Backtrace

An internal representation of the backtrace. The user will never interact with objects of this class directly, but class methods can be used to get backtrace settings of the current session.

File::Constants

Module File::Constants defines file-related constants.

There are two families of constants here:

Those having to do with file access.
Those having to do with filename globbing.

File constants defined for the local process may be retrieved with method File::Constants.constants:

File::Constants.constants.take(5)
# => [:RDONLY, :WRONLY, :RDWR, :APPEND, :CREAT]

File Access

File-access constants may be used with optional argument mode in calls to the following methods:

Read/Write Access

Read-write access for a stream may be specified by a file-access constant.

The constant may be specified as part of a bitwise OR of other such constants.

Any combination of the constants in this section may be specified.

File::RDONLY

Flag File::RDONLY specifies the stream should be opened for reading only:

filepath = '/tmp/t.tmp'
f = File.new(filepath, File::RDONLY)
f.write('Foo') # Raises IOError (not opened for writing).

File::WRONLY

Flag File::WRONLY specifies that the stream should be opened for writing only:

f = File.new(filepath, File::WRONLY)
f.read # Raises IOError (not opened for reading).

File::RDWR

Flag File::RDWR specifies that the stream should be opened for both reading and writing:

f = File.new(filepath, File::RDWR)
f.write('Foo') # => 3
f.rewind       # => 0
f.read         # => "Foo"

File Positioning

File::APPEND

Flag File::APPEND specifies that the stream should be opened in append mode.

Before each write operation, the position is set to end-of-stream. The modification of the position and the following write operation are performed as a single atomic step.

File::TRUNC

Flag File::TRUNC specifies that the stream should be truncated at its beginning. If the file exists and is successfully opened for writing, it is to be truncated to position zero; its ctime and mtime are updated.

There is no effect on a FIFO special file or a terminal device. The effect on other file types is implementation-defined. The result of using File::TRUNC with File::RDONLY is undefined.

Creating and Preserving

File::CREAT

Flag File::CREAT specifies that the stream should be created if it does not already exist.

If the file exists:

- Raise an exception if File::EXCL is also specified.
- Otherwise, do nothing.

If the file does not exist, then it is created. Upon successful completion, the atime, ctime, and mtime of the file are updated, and the ctime and mtime of the parent directory are updated.

File::EXCL

Flag File::EXCL specifies that the stream should not already exist; If flags File::CREAT and File::EXCL are both specified and the stream already exists, an exception is raised.

The check for the existence and creation of the file is performed as an atomic operation.

If both File::EXCL and File::CREAT are specified and the path names a symbolic link, an exception is raised regardless of the contents of the symbolic link.

If File::EXCL is specified and File::CREAT is not specified, the result is undefined.

POSIX File Constants

Some file-access constants are defined only on POSIX-compliant systems; those are:

File::SYNC.
File::DSYNC.
File::RSYNC.
File::DIRECT.
File::NOATIME.
File::NOCTTY.
File::NOFOLLOW.
File::TMPFILE.

File::SYNC, File::RSYNC, and File::DSYNC

Flag File::SYNC, File::RSYNC, or File::DSYNC specifies synchronization of I/O operations with the underlying file system.

These flags are valid only for POSIX-compliant systems.

File::SYNC specifies that all write operations (both data and metadata) are immediately to be flushed to the underlying storage device. This means that the data is written to the storage device, and the file’s metadata (e.g., file size, timestamps, permissions) are also synchronized. This guarantees that data is safely stored on the storage medium before returning control to the calling program. This flag can have a significant impact on performance since it requires synchronous writes, which can be slower compared to asynchronous writes.
File::RSYNC specifies that any read operations on the file will not return until all outstanding write operations (those that have been issued but not completed) are also synchronized. This is useful when you want to read the most up-to-date data, which may still be in the process of being written.
File::DSYNC specifies that all data write operations are immediately to be flushed to the underlying storage device; this differs from File::SYNC, which requires that metadata also be synchronized.

Note that the behavior of these flags may vary slightly depending on the operating system and filesystem being used. Additionally, using these flags can have an impact on performance due to the synchronous nature of the I/O operations, so they should be used judiciously, especially in performance-critical applications.

File::NOCTTY

Flag File::NOCTTY specifies that if the stream is a terminal device, that device does not become the controlling terminal for the process.