Results for: "partition"

Gem::ConsoleUI

Subclass of StreamUI that instantiates the user interaction using $stdin, $stdout, and $stderr.

SyntaxSuggest::AroundBlockScan

This class is useful for exploring contents before and after a block

It searches above and below the passed in block to match for whatever criteria you give it:

Example:

def dog         # 1
  puts "bark"   # 2
  puts "bark"   # 3
end             # 4

scan = AroundBlockScan.new(
  code_lines: code_lines
  block: CodeBlock.new(lines: code_lines[1])
)

scan.scan_while { true }

puts scan.before_index # => 0
puts scan.after_index  # => 3

SyntaxSuggest::BlockExpand

This class is responsible for taking a code block that exists at a far indentaion and then iteratively increasing the block so that it captures everything within the same indentation block.

def dog
  puts "bow"
  puts "wow"
end

block = BlockExpand.new(code_lines: code_lines)

.call(CodeBlock.new(lines: code_lines[1]))

puts block.to_s # => puts “bow”

puts "wow"

Once a code block has captured everything at a given indentation level then it will expand to capture surrounding indentation.

block = BlockExpand.new(code_lines: code_lines)

.call(block)

block.to_s # => def dog

  puts "bow"
  puts "wow"
end

SyntaxSuggest::CaptureCodeContext

Turns a “invalid block(s)” into useful context

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 third part.

The algorithm is very good at capturing all of a syntax error in a single block in number 2, however the results can contain ambiguities. Humans are good at pattern matching and filtering and can mentally remove extraneous data, but they can’t add extra data that’s not present.

In the case of known ambiguious cases, this class adds context back to the ambiguitiy so the programmer has full information.

Beyond handling these ambiguities, it also captures surrounding code context information:

puts block.to_s # => "def bark"

context = CaptureCodeContext.new(
  blocks: block,
  code_lines: code_lines
)

lines = context.call.map(&:original)
puts lines.join
# =>
  class Dog
    def bark
  end

SyntaxSuggest::CodeSearch

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

SyntaxSuggest::MiniStringIO

Mini String IO [Private]

Acts like a StringIO with reduced API, but without having to require that class.

SyntaxSuggest::DisplayCodeWithLineNumbers

Outputs code with highlighted lines

Whatever is passed to this class will be rendered even if it is “marked invisible” any filtering of output should be done before calling this class.

DisplayCodeWithLineNumbers.new(
  lines: lines,
  highlight_lines: [lines[2], lines[3]]
).call
# =>
    1
    2  def cat
  > 3    Dir.chdir
  > 4    end
    5  end
    6

SyntaxSuggest::PathnameFromMessage

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"

SyntaxSuggest::UnvisitedLines

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

URI::InvalidComponentError

Not a URI component.

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 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.