Standard Library

Ruby standard library imap.

Ruby standard library smtp.

Ruby standard library prime.

Ruby standard library matrix.

Ruby standard library tsort.

Ruby standard library getoptlong.

Ruby standard library strscan.

Ruby standard library complex.

Ruby standard library drb.

Ruby standard library xmlrpc.

Ruby standard library timeout.

Ruby standard library telnet.

Ruby standard library net-protocol.

Ruby standard library pstore.

Ruby standard library pop.

Ruby standard library wait.

Ruby standard library weakref.

Ruby standard library threads_wait.

Ruby standard library profile.

Ruby standard library rss.

Ruby standard library observer.

Ruby standard library scanf.

Ruby standard library sync.

Ruby standard library gserver.

Ruby standard library cmath.

Ruby standard library continuation.

Ruby standard library un.

Ruby standard library fiber.

Ruby standard library console.

Ruby standard library nonblock.

This library performs diffs of CSV data, or any table-like source. Unlike a standard diff that compares line by line, and is sensitive to the ordering of records, CSV-Diff identifies common lines by key field(s), and then compares the contents of the fields in each line. Data may be supplied in the form of CSV files, or as an array of arrays. The diff process provides a fine level of control over what to diff, and can optionally ignore certain types of changes (e.g. changes in position). CSV-Diff is particularly well suited to data in parent-child format. Parent- child data does not lend itself well to standard text diffs, as small changes in the organisation of the tree at an upper level can lead to big movements in the position of descendant records. By instead matching records by key, CSV-Diff avoids this issue, while still being able to detect changes in sibling order. This gem implements the core diff algorithm, and handles the loading and diffing of CSV files (or Arrays of Arrays). It also supports converting data in XML format into tabular form, so that it can then be processed like any other CSV or table-like source. It returns a CSVDiff object containing the details of differences in object form. This is useful for projects that need diff capability, but want to handle the reporting or actioning of differences themselves. For a pre-built diff reporting capability, see the csv-diff-report gem, which provides a command-line tool for generating diff reports in HTML, Excel, or text formats.

A simple set of module functions to normalize, validate, and convert common library standard numbers

The sys-admin library is a unified, cross platform replacement for the 'etc' library that ships as part of the Ruby standard library. It provides a common interface for all platforms, including MS Windows. In addition, it provides an interface for adding, deleting and configuring users on MS Windows.

OptionParser based CLI support for rapid CLI development in an object-oriented context. This library wraps Ruby's OptionParser for parsing your options under the hood, so you get all the goodness that the Ruby standard library provides. On top of that it adds a rich and powerful DSL for defining, validating, and normalizing options, as well as automatic and gorgeous help output (modeled after `gem --help`).

Colorist is a library built to handle the easy conversion and manipulation of colors with a special emphasis on W3C standards and CSS-style hex color notation.

Guilded is a framework for building web based components centered around current web standards and best practices. The current framework is written in ruby, but could be ported to other languages. Guilded intends to provide a toolset for creating and consuming reusable web components. Currently, this problem domain is filled with JavaScript frameworks. These frameworks are wonderful and work very well. However, they do not degrade gracefully and are not accessible. Guilded seeks to provide the same level of "componentization" and ease of use without sacrificing degradability and accessibility. Guilded will achieve these goals by applying each technology at our disposal to do what it was intended. XHTML will be employed for content. CSS used for layout and styling. Behavior will be added to a component with JavaScript through progressive enhancement. The user will have the best experience with a Guilded component when CSS and JavaScript are enabled in their browser, but will still be able to use the component when CSS and JavaScript are disabled. Guilded will use jQuery as it's base JavaScript framework. jQuery was chosen because it lends itself to progressive enhancement due to the way it was authored. In addition, the tight integration of jQuery's selectors with CSS selectors is also highly desirable. When authoring a Guilded component, it is encouraged to write the behavior code as a jQuery plugin. This will allow the jQuery plugin to be used outside of the Guilded project, if desired. Guilded also seeks to provide a standardized CSS framework for creating layouts that are reusable and predictable. Guilded will utilize the currently existing RubyGems system to package its components. A new Guilded component will be packaged in a Gem and have a dependency on the Guilded gem. The Guilded gem contains the framework to build Guilded components. Update: Due to the quality components, etc. being generated by the MooTools community and the general quality of the library, we have decided to include support for it in Guilded as of release 0.3.0.

Slogger is a Ruby library to help work with standard Ruby Syslog library. Yeah! Just it.

Rails I18n: de-facto standard library for ActiveRecord data translation

D3.js is a JavaScript library for manipulating documents based on data. D3 helps you bring data to life using HTML, SVG and CSS. D3’s emphasis on web standards gives you the full capabilities of modern browsers without tying yourself to a proprietary framework, combining powerful visualization components and a data-driven approach to DOM manipulation.

This module calculates the date upon which Easter falls, a date upon which many holidays in the Western world depend. It extends the Date class available in the Ruby standard library, adding the class method Date::easter(year) and the instance method easter().

Ruby standard library unicode_normalize.

The getopt library provides two different command line option parsers. They are meant as easier and more convenient replacements for the command line parsers that ship as part of the Ruby standard library. Please see the README for additional comments.

Inventory Inventory keeps track of the contents of your Ruby¹ projects. Such an inventory can be used to load the project, create gem specifications and gems, run unit tests, compile extensions, and verify that the project’s content is what you think it is. ¹ See http://ruby-lang.org/ § Usage Let’s begin by discussing the project structure that Inventory expects you to use. It’s pretty much exactly the same as the standard Ruby project structure¹: ├── README ├── Rakefile ├── lib │ ├── foo-1.0 │ │ ├── bar.rb │ │ └── version.rb │ └── foo-1.0.rb └── test └── unit ├── foo-1.0 │ ├── bar.rb │ └── version.rb └── foo-1.0.rb Here you see a simplified version of a project called “Foo”’s project structure. The only real difference from the standard is that the main entry point into the library is named “foo-1.0.rb” instead of “foo.rb” and that the root sub-directory of “lib” is similarly named “foo-1.0” instead of “foo”. The difference is the inclusion of the API version. This must be the major version of the project followed by a constant “.0”. The reason for this is that it allows concurrent installations of different major versions of the project and means that the wrong version will never accidentally be loaded with require. There’s a bigger difference in the content of the files. ‹Lib/foo-1.0/version.rb› will contain our inventory instead of a String: require 'inventory-1.0' class Foo Version = Foo.new(1, 4, 0){ authors{ author 'A. U. Thor', 'a.u.thor@example.org' } homepage 'http://example.org/' licenses{ license 'LGPLv3+', 'GNU Lesser General Public License, version 3 or later', 'http://www.gnu.org/licenses/' } def dependencies super + Dependencies.new{ development 'baz', 1, 3, 0 runtime 'goo', 2, 0, 0 optional 'roo-loo', 3, 0, 0, :feature => 'roo-loo' } end def package_libs %w[bar.rb] end } end We’re introducing quite a few concepts at once, and we’ll look into each in greater detail, but we begin by setting the ‹Version› constant to a new instance of an Inventory with major, minor, and patch version atoms 1, 4, and 0. Then we add a couple of dependencies and list the library files that are included in this project. The version numbers shouldn’t come as a surprise. These track the version of the API that we’re shipping using {semantic versioning}². They also allow the Inventory#to_s method to act as if you’d defined Version as ‹'1.4.0'›. Next follows information about the authors of the project, the project’s homepage, and the project’s licenses. Each author has a name and an email address. The homepage is simply a string URL. Licenses have an abbreviation, a name, and a URL where the license text can be found. We then extend the definition of ‹dependencies› by adding another set of dependencies to ‹super›. ‹Super› includes a dependency on the version of the inventory project that’s being used with this project, so you’ll never have to list that yourself. The other three dependencies are all of different kinds: development, runtime, and optional. A development dependency is one that’s required while developing the project, for example, a unit-testing framework, a documentation generator, and so on. Runtime dependencies are requirements of the project to be able to run, both during development and when installed. Finally, optional dependencies are runtime dependencies that may or may not be required during execution. The difference between runtime and optional is that the inventory won’t try to automatically load an optional dependency, instead leaving that up to you to do when and if it becomes necessary. By that logic, runtime dependencies will be automatically loaded, which is a good reason for having dependency information available at runtime. The version numbers of dependencies also use semantic versioning, but note that the patch atom is ignored unless the major atom is 0. You should always only depend on the major and minor atoms. As mentioned, runtime dependencies will be automatically loaded and the feature they try to load is based on the name of the dependency with a “-X.0” tacked on the end, where ‘X’ is the major version of the dependency. Sometimes, this isn’t correct, in which case the :feature option may be given to specify the name of the feature. You may also override other parts of a dependency by passing in a block to the dependency, much like we’re doing for inventories. The rest of an inventory will list the various files included in the project. This project only consists of one additional file to those that an inventory automatically include (Rakefile, README, the main entry point, and the version.rb file that defines the inventory itself), namely the library file ‹bar.rb›. Library files will be loaded automatically when the main entry point file loads the inventory. Library files that shouldn’t be loaded may be listed under a different heading, namely “additional_libs”. Both these sets of files will be used to generate a list of unit test files automatically, so each library file will have a corresponding unit test file in the inventory. We’ll discuss the different headings of an inventory in more detail later on. Now that we’ve written our inventory, let’s set it up so that it’s content gets loaded when our main entry point gets loaded. We add the following piece of code to ‹lib/foo-1.0.rb›: module Foo load File.expand_path('../foo-1.0/version.rb', __FILE__) Version.load end That’s all there’s to it. The inventory can also be used to great effect from a Rakefile using a separate project called Inventory-Rake³. Using it’ll give us tasks for cleaning up our project, compiling extensions, installing dependencies, installing and uninstalling the project itself, and creating and pushing distribution files to distribution points. require 'inventory-rake-1.0' load File.expand_path('../lib/foo-1.0/version.rb', __FILE__) Inventory::Rake::Tasks.define Foo::Version Inventory::Rake::Tasks.unless_installing_dependencies do require 'lookout-rake-3.0' Lookout::Rake::Tasks::Test.new end It’s ‹Inventory::Rake::Tasks.define› that does the heavy lifting. It takes our inventory and sets up the tasks mentioned above. As we want to be able to use our Rakefile to install our dependencies for us, the rest of the Rakefile is inside the conditional #unless_installing_dependencies, which, as the name certainly implies, executes its block unless the task being run is the one that installs our dependencies. This becomes relevant when we set up Travis⁴ integration next. The only conditional set-up we do in our Rakefile is creating our test task via Lookout-Rake⁵, which also uses our inventory to find the unit tests to run when executed. Travis integration is straightforward. Simply put before_script: - gem install inventory-rake -v '~> VERSION' --no-rdoc --no-ri - rake gem:deps:install in the project’s ‹.travis.yml› file, replacing ‹VERSION› with the version of Inventory-Rake that you require. This’ll make sure that Travis installs all development, runtime, and optional dependencies that you’ve listed in your inventory before running any tests. You might also need to put env: - RUBYOPT=rubygems in your ‹.travis.yml› file, depending on how things are set up. ¹ Ruby project structure: http://guides.rubygems.org/make-your-own-gem/ ² Semantic versioning: http://semver.org/ ³ Inventory-Rake: http://disu.se/software/inventory-rake-1.0/ ⁴ Travis: http://travis-ci.org/ ⁵ Lookout-Rake: http://disu.se/software/lookout-rake-3.0/ § API If the guide above doesn’t provide you with all the answers you seek, you may refer to the API¹ for more answers. ¹ See http://disu.se/software/inventory-1.0/api/Inventory/ § Financing Currently, most of my time is spent at my day job and in my rather busy private life. Please motivate me to spend time on this piece of software by donating some of your money to this project. Yeah, I realize that requesting money to develop software is a bit, well, capitalistic of me. But please realize that I live in a capitalistic society and I need money to have other people give me the things that I need to continue living under the rules of said society. So, if you feel that this piece of software has helped you out enough to warrant a reward, please PayPal a donation to now@disu.se¹. Thanks! Your support won’t go unnoticed! ¹ Send a donation: https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now@disu.se&item_name=Inventory § Reporting Bugs Please report any bugs that you encounter to the {issue tracker}¹. ¹ See https://github.com/now/inventory/issues § Authors Nikolai Weibull wrote the code, the tests, the documentation, and this README. § Licensing Inventory is free software: you may redistribute it and/or modify it under the terms of the {GNU Lesser General Public License, version 3}¹ or later², as published by the {Free Software Foundation}³. ¹ See http://disu.se/licenses/lgpl-3.0/ ² See http://gnu.org/licenses/ ³ See http://fsf.org/

SCORM is a Ruby library for reading and extracting Shareable Content Object Reference Model (SCORM) files. SCORM is a standardized package format used mainly by e-learning software to help with the exchange of course material between systems in an interoperable way. This gem supports SCORM 1.2 and SCORM 2004.

Library that provides more mathematical functions/algorithms than standard Ruby.

Classes for inter-process synchronization/communication like thread library in ruby standard library

An implementation of Javascript written in pure Ruby. Twostroke contains a parser, a bytecode compiler, a VM, and a minimal implementation of the Javascript standard library.

CoreEx is designed to provide a simple but quite useful extension of the standard library of Ruby. So some classes and modules like Pathname, Time, Enumerable, Exception, FileUtils, String, and YAML are extended. There is also some new features like attr_once, DTime, TempPath, Version, embedded_tests, filelist (almost from rake), a common Rakefile, and an extension of the require system.

The relative library enhances Ruby's core and standard libraries to support naming, opening, and reading files relative to the Ruby file currently being interpreted (the contents of the __ FILE __ identifier). This functionality is especially useful in embedded Ruby (eruby, erb, erubis, etc.) where absolute paths or paths relative to the interpreter's current working directory are problematic (due to file system structures and working directories varying across platforms and web servers).

A ruby library to generate Ethereum addresses from a hierarchical deterministic wallet according to the BIP44 standard.