Functional Programming

A package (also known as a library) contains a set of functionality that can be invoked by a Ruby program, such as reading and parsing an XML file. We call these packages 'gems' and RubyGems is a tool to install, create, manage and load these packages in your Ruby environment. RubyGems is also a client for RubyGems.org, a public repository of Gems that allows you to publish a Gem that can be shared and used by other developers. See our guide on publishing a Gem at guides.rubygems.org

This is the MySQL API module for Ruby. It provides the same functions for Ruby programs that the MySQL C API provides for C programs. This package is offered as gem for easy installation using RubyGems. It wraps unmodified tmtm's mysql-ruby extension into a proper gem. Please note that tmtm (Tomita Mashahiro) has deprecated development of this extension and only update it for bug fixes.

This gem is intended to accomplish the same purpose as jStat js library: to provide ruby with statistical capabilities without the need of a statistical programming language like R or Octave. Some functions and capabilities are an implementation from other authors and are referenced properly in the class/method.

# Excel to Code [](https://travis-ci.org/tamc/excel_to_code) excel_to_c - roughly translate some Excel files into C. excel_to_ruby - roughly translate some Excel files into Ruby. This allows spreadsheets to be: 1. Embedded in other programs, such as web servers, or optimisers 2. Without depending on any Microsoft code For example, running [these commands](examples/simple/compile.sh) turns [this spreadsheet](examples/simple/simple.xlsx) into [this Ruby code](examples/simple/ruby/simple.rb) or [this C code](examples/simple/c/simple.c). # Install Requires Ruby. Install by: gem install excel_to_code # Run To just have a go: excel_to_c <excel_file_name> This will produce a file called excelspreadsheet.c For a more complex spreadsheet: excel_to_c --compile --run-tests --settable <name of input worksheet> --prune-except <name of output worksheet> <excel file name> See the full list of options: excel_to_c --help # Gotchas, limitations and bugs 0. No custom functions, no macros for generating results 1. Results are cached. So you must call reset(), then set values, then read values. 2. It must be possible to replace INDIRECT and OFFSET formula with standard references at compile time (e.g., INDIRECT("A"&"1") is fine, INDIRECT(userInput&"3") is not. 3. Doesn't implement all functions. [See which functions are implemented](docs/Which_functions_are_implemented.md). 4. Doesn't implement references that involve range unions and lists (but does implement standard ranges) 5. Sometimes gives cells as being empty, when excel would give the cell as having a numeric value of zero 6. The generated C version does not multithread and will give bad results if you try. 7. The generated code uses floating point, rather than fully precise arithmetic, so results can differ slightly. 8. The generated code uses the sprintf approach to rounding (even-odd) rather than excel's 0.5 rounds away from zero. 9. Ranges like this: Sheet1!A10:Sheet1!B20 and 3D ranges don't work. Report bugs: <https://github.com/tamc/excel_to_code/issues> # Changelog See [Changes](CHANGES.md). # License See [License](LICENSE.md) # Hacking Source code: <https://github.com/tamc/excel_to_code> Documentation: * [Installing from source](docs/installing_from_source.md) * [Structure of this project](docs/structure_of_this_project.md) * [How does the calculation work](docs/how_does_the_calculation_work.md) * [How to fix parsing errors](docs/How_to_fix_parsing_errors.md) * [How to implement a new Excel function](docs/How_to_add_a_missing_function.md) Some notes on how Excel works under the hood: * [The Excel file structure](docs/implementation/excel_file_structure.md) * [Relationships](docs/implementation/relationships.md) * [Workbooks](docs/implementation/workbook.md) * [Worksheets](docs/implementation/worksheets.md) * [Cells](docs/implementation/cell.md) * [Tables](docs/implementation/tables.md) * [Shared Strings](docs/implementation/shared_strings.md) * [Array formulae](docs/implementation/array_formulae.md)

A slice of functional programming to chain ruby services and blocks. Make them flow!

A gem for adding functional programming tools to Ruby. Inspired by Erlang, Clojure, Haskell, and Functional Java.

Allows Ruby programs to access sendfile(2) functionality on any IO object. Works on Linux, Solaris, FreeBSD and Darwin with blocking and non-blocking sockets.

CompTree is a parallel computation tree structure based upon concepts from pure functional programming.

PluginFactory is a mixin module that turns an including class into a factory for its derivatives, capable of searching for and loading them by name. This is useful when you have an abstract base class which defines an interface and basic functionality for a part of a larger system, and a collection of subclasses which implement the interface for different underlying functionality. An example of where this might be useful is in a program which talks to a database. To avoid coupling it to a specific database, you use a Driver class which encapsulates your program's interaction with the database behind a useful interface. Now you can create a concrete implementation of the Driver class for each kind of database you wish to talk to. If you make the base Driver class a PluginFactory, too, you can add new drivers simply by dropping them in a directory and using the Driver's `create` method to instantiate them:

Lookout Lookout is a unit testing framework for Ruby¹ that puts your results in focus. Tests (expectations) are written as follows expect 2 do 1 + 1 end expect ArgumentError do Integer('1 + 1') end expect Array do [1, 2, 3].select{ |i| i % 2 == 0 } end expect [2, 4, 6] do [1, 2, 3].map{ |i| i * 2 } end Lookout is designed to encourage – force, even – unit testing best practices such as • Setting up only one expectation per test • Not setting expectations on non-public APIs • Test isolation This is done by • Only allowing one expectation to be set per test • Providing no (additional) way of accessing private state • Providing no setup and tear-down methods, nor a method of providing test helpers Other important points are • Putting the expected outcome of a test in focus with the steps of the calculation of the actual result only as a secondary concern • A focus on code readability by providing no mechanism for describing an expectation other than the code in the expectation itself • A unified syntax for setting up both state-based and behavior-based expectations The way Lookout works has been heavily influenced by expectations², by {Jay Fields}³. The code base was once also heavily based on expectations, based at Subversion {revision 76}⁴. A lot has happened since then and all of the work past that revision are due to {Nikolai Weibull}⁵. ¹ Ruby: http://ruby-lang.org/ ² Expectations: http://expectations.rubyforge.org/ ³ Jay Fields’s blog: http://blog.jayfields.com/ ⁴ Lookout revision 76: https://github.com/now/lookout/commit/537bedf3e5b3eb4b31c066b3266f42964ac35ebe ⁵ Nikolai Weibull’s home page: http://disu.se/ § Installation Install Lookout with % gem install lookout § Usage Lookout allows you to set expectations on an object’s state or behavior. We’ll begin by looking at state expectations and then take a look at expectations on behavior. § Expectations on State: Literals An expectation can be made on the result of a computation: expect 2 do 1 + 1 end Most objects, in fact, have their state expectations checked by invoking ‹#==› on the expected value with the result as its argument. Checking that a result is within a given range is also simple: expect 0.099..0.101 do 0.4 - 0.3 end Here, the more general ‹#===› is being used on the ‹Range›. § Regexps ‹Strings› of course match against ‹Strings›: expect 'ab' do 'abc'[0..1] end but we can also match a ‹String› against a ‹Regexp›: expect %r{a substring} do 'a string with a substring' end (Note the use of ‹%r{…}› to avoid warnings that will be generated when Ruby parses ‹expect /…/›.) § Modules Checking that the result includes a certain module is done by expecting the ‹Module›. expect Enumerable do [] end This, due to the nature of Ruby, of course also works for classes (as they are also modules): expect String do 'a string' end This doesn’t hinder us from expecting the actual ‹Module› itself: expect Enumerable do Enumerable end or the ‹Class›: expect String do String end for obvious reasons. As you may have figured out yourself, this is accomplished by first trying ‹#==› and, if it returns ‹false›, then trying ‹#===› on the expected ‹Module›. This is also true of ‹Ranges› and ‹Regexps›. § Booleans Truthfulness is expected with ‹true› and ‹false›: expect true do 1 end expect false do nil end Results equaling ‹true› or ‹false› are slightly different: expect TrueClass do true end expect FalseClass do false end The rationale for this is that you should only care if the result of a computation evaluates to a value that Ruby considers to be either true or false, not the exact literals ‹true› or ‹false›. § IO Expecting output on an IO object is also common: expect output("abc\ndef\n") do |io| io.puts 'abc', 'def' end This can be used to capture the output of a formatter that takes an output object as a parameter. § Warnings Expecting warnings from code isn’t very common, but should be done: expect warning('this is your final one!') do warn 'this is your final one!' end expect warning('this is your final one!') do warn '%s:%d: warning: this is your final one!' % [__FILE__, __LINE__] end ‹$VERBOSE› is set to ‹true› during the execution of the block, so you don’t need to do so yourself. If you have other code that depends on the value of $VERBOSE, that can be done with ‹#with_verbose› expect nil do with_verbose nil do $VERBOSE end end § Errors You should always be expecting errors from – and in, but that’s a different story – your code: expect ArgumentError do Integer('1 + 1') end Often, not only the type of the error, but its description, is important to check: expect StandardError.new('message') do raise StandardError.new('message') end As with ‹Strings›, ‹Regexps› can be used to check the error description: expect StandardError.new(/mess/) do raise StandardError.new('message') end § Queries Through Symbols Symbols are generally matched against symbols, but as a special case, symbols ending with ‹?› are seen as expectations on the result of query methods on the result of the block, given that the method is of zero arity and that the result isn’t a Symbol itself. Simply expect a symbol ending with ‹?›: expect :empty? do [] end To expect it’s negation, expect the same symbol beginning with ‹not_›: expect :not_nil? do [1, 2, 3] end This is the same as expect true do [].empty? end and expect false do [1, 2, 3].empty? end but provides much clearer failure messages. It also makes the expectation’s intent a lot clearer. § Queries By Proxy There’s also a way to make the expectations of query methods explicit by invoking methods on the result of the block. For example, to check that the even elements of the Array ‹[1, 2, 3]› include ‹1› you could write expect result.to.include? 1 do [1, 2, 3].reject{ |e| e.even? } end You could likewise check that the result doesn’t include 2: expect result.not.to.include? 2 do [1, 2, 3].reject{ |e| e.even? } end This is the same as (and executes a little bit slower than) writing expect false do [1, 2, 3].reject{ |e| e.even? }.include? 2 end but provides much clearer failure messages. Given that these two last examples would fail, you’d get a message saying “[1, 2, 3]#include?(2)” instead of the terser “true≠false”. It also clearly separates the actual expectation from the set-up. The keyword for this kind of expectations is ‹result›. This may be followed by any of the methods • ‹#not› • ‹#to› • ‹#be› • ‹#have› or any other method you will want to call on the result. The methods ‹#to›, ‹#be›, and ‹#have› do nothing except improve readability. The ‹#not› method inverts the expectation. § Literal Literals If you need to literally check against any of the types of objects otherwise treated specially, that is, any instances of • ‹Module› • ‹Range› • ‹Regexp› • ‹Exception› • ‹Symbol›, given that it ends with ‹?› you can do so by wrapping it in ‹literal(…)›: expect literal(:empty?) do :empty? end You almost never need to do this, as, for all but symbols, instances will match accordingly as well. § Expectations on Behavior We expect our objects to be on their best behavior. Lookout allows you to make sure that they are. Reception expectations let us verify that a method is called in the way that we expect it to be: expect mock.to.receive.to_str(without_arguments){ '123' } do |o| o.to_str end Here, ‹#mock› creates a mock object, an object that doesn’t respond to anything unless you tell it to. We tell it to expect to receive a call to ‹#to_str› without arguments and have ‹#to_str› return ‹'123'› when called. The mock object is then passed in to the block so that the expectations placed upon it can be fulfilled. Sometimes we only want to make sure that a method is called in the way that we expect it to be, but we don’t care if any other methods are called on the object. A stub object, created with ‹#stub›, expects any method and returns a stub object that, again, expects any method, and thus fits the bill. expect stub.to.receive.to_str(without_arguments){ '123' } do |o| o.to_str if o.convertable? end You don’t have to use a mock object to verify that a method is called: expect Object.to.receive.name do Object.name end As you have figured out by now, the expected method call is set up by calling ‹#receive› after ‹#to›. ‹#Receive› is followed by a call to the method to expect with any expected arguments. The body of the expected method can be given as the block to the method. Finally, an expected invocation count may follow the method. Let’s look at this formal specification in more detail. The expected method arguments may be given in a variety of ways. Let’s introduce them by giving some examples: expect mock.to.receive.a do |m| m.a end Here, the method ‹#a› must be called with any number of arguments. It may be called any number of times, but it must be called at least once. If a method must receive exactly one argument, you can use ‹Object›, as the same matching rules apply for arguments as they do for state expectations: expect mock.to.receive.a(Object) do |m| m.a 0 end If a method must receive a specific argument, you can use that argument: expect mock.to.receive.a(1..2) do |m| m.a 1 end Again, the same matching rules apply for arguments as they do for state expectations, so the previous example expects a call to ‹#a› with 1, 2, or the Range 1..2 as an argument on ‹m›. If a method must be invoked without any arguments you can use ‹without_arguments›: expect mock.to.receive.a(without_arguments) do |m| m.a end You can of course use both ‹Object› and actual arguments: expect mock.to.receive.a(Object, 2, Object) do |m| m.a nil, 2, '3' end The body of the expected method may be given as the block. Here, calling ‹#a› on ‹m› will give the result ‹1›: expect mock.to.receive.a{ 1 } do |m| raise 'not 1' unless m.a == 1 end If no body has been given, the result will be a stub object. To take a block, grab a block parameter and ‹#call› it: expect mock.to.receive.a{ |&b| b.call(1) } do |m| j = 0 m.a{ |i| j = i } raise 'not 1' unless j == 1 end To simulate an ‹#each›-like method, ‹#call› the block several times. Invocation count expectations can be set if the default expectation of “at least once” isn’t good enough. The following expectations are possible • ‹#at_most_once› • ‹#once› • ‹#at_least_once› • ‹#twice› And, for a given ‹N›, • ‹#at_most(N)› • ‹#exactly(N)› • ‹#at_least(N)› § Utilities: Stubs Method stubs are another useful thing to have in a unit testing framework. Sometimes you need to override a method that does something a test shouldn’t do, like access and alter bank accounts. We can override – stub out – a method by using the ‹#stub› method. Let’s assume that we have an ‹Account› class that has two methods, ‹#slips› and ‹#total›. ‹#Slips› retrieves the bank slips that keep track of your deposits to the ‹Account› from a database. ‹#Total› sums the ‹#slips›. In the following test we want to make sure that ‹#total› does what it should do without accessing the database. We therefore stub out ‹#slips› and make it return something that we can easily control. expect 6 do |m| stub(Class.new{ def slips raise 'database not available' end def total slips.reduce(0){ |m, n| m.to_i + n.to_i } end }.new, :slips => [1, 2, 3]){ |account| account.total } end To make it easy to create objects with a set of stubbed methods there’s also a convenience method: expect 3 do s = stub(:a => 1, :b => 2) s.a + s.b end This short-hand notation can also be used for the expected value: expect stub(:a => 1, :b => 2).to.receive.a do |o| o.a + o.b end and also works for mock objects: expect mock(:a => 2, :b => 2).to.receive.a do |o| o.a + o.b end Blocks are also allowed when defining stub methods: expect 3 do s = stub(:a => proc{ |a, b| a + b }) s.a(1, 2) end If need be, we can stub out a specific method on an object: expect 'def' do stub('abc', :to_str => 'def'){ |a| a.to_str } end The stub is active during the execution of the block. § Overriding Constants Sometimes you need to override the value of a constant during the execution of some code. Use ‹#with_const› to do just that: expect 'hello' do with_const 'A::B::C', 'hello' do A::B::C end end Here, the constant ‹A::B::C› is set to ‹'hello'› during the execution of the block. None of the constants ‹A›, ‹B›, and ‹C› need to exist for this to work. If a constant doesn’t exist it’s created and set to a new, empty, ‹Module›. The value of ‹A::B::C›, if any, is restored after the block returns and any constants that didn’t previously exist are removed. § Overriding Environment Variables Another thing you often need to control in your tests is the value of environment variables. Depending on such global values is, of course, not a good practice, but is often unavoidable when working with external libraries. ‹#With_env› allows you to override the value of environment variables during the execution of a block by giving it a ‹Hash› of key/value pairs where the key is the name of the environment variable and the value is the value that it should have during the execution of that block: expect 'hello' do with_env 'INTRO' => 'hello' do ENV['INTRO'] end end Any overridden values are restored and any keys that weren’t previously a part of the environment are removed when the block returns. § Overriding Globals You may also want to override the value of a global temporarily: expect 'hello' do with_global :$stdout, StringIO.new do print 'hello' $stdout.string end end You thus provide the name of the global and a value that it should take during the execution of a block of code. The block gets passed the overridden value, should you need it: expect true do with_global :$stdout, StringIO.new do |overridden| $stdout != overridden end end § Integration Lookout can be used from Rake¹. Simply install Lookout-Rake²: % gem install lookout-rake and add the following code to your Rakefile require 'lookout-rake-3.0' Lookout::Rake::Tasks::Test.new Make sure to read up on using Lookout-Rake for further benefits and customization. ¹ Read more about Rake at http://rake.rubyforge.org/ ² Get information on Lookout-Rake at http://disu.se/software/lookout-rake/ § API Lookout comes with an API¹ that let’s you create things such as new expected values, difference reports for your types, and so on. ¹ See http://disu.se/software/lookout/api/ § Interface Design The default output of Lookout can Spartanly be described as Spartan. If no errors or failures occur, no output is generated. This is unconventional, as unit testing frameworks tend to dump a lot of information on the user, concerning things such as progress, test count summaries, and flamboyantly colored text telling you that your tests passed. None of this output is needed. Your tests should run fast enough to not require progress reports. The lack of output provides you with the same amount of information as reporting success. Test count summaries are only useful if you’re worried that your tests aren’t being run, but if you worry about that, then providing such output doesn’t really help. Testing your tests requires something beyond reporting some arbitrary count that you would have to verify by hand anyway. When errors or failures do occur, however, the relevant information is output in a format that can easily be parsed by an ‹'errorformat'› for Vim or with {Compilation Mode}¹ for Emacs². Diffs are generated for Strings, Arrays, Hashes, and I/O. ¹ Read up on Compilation mode for Emacs at http://www.emacswiki.org/emacs/CompilationMode ² Visit The GNU Foundation’s Emacs’ software page at http://www.gnu.org/software/emacs/ § External Design Let’s now look at some of the points made in the introduction in greater detail. Lookout only allows you to set one expectation per test. If you’re testing behavior with a reception expectation, then only one method-invocation expectation can be set. If you’re testing state, then only one result can be verified. It may seem like this would cause unnecessary duplication between tests. While this is certainly a possibility, when you actually begin to try to avoid such duplication you find that you often do so by improving your interfaces. This kind of restriction tends to encourage the use of value objects, which are easy to test, and more focused objects, which require simpler tests, as they have less behavior to test, per method. By keeping your interfaces focused you’re also keeping your tests focused. Keeping your tests focused improves, in itself, test isolation, but let’s look at something that hinders it: setup and tear-down methods. Most unit testing frameworks encourage test fragmentation by providing setup and tear-down methods. Setup methods create objects and, perhaps, just their behavior for a set of tests. This means that you have to look in two places to figure out what’s being done in a test. This may work fine for few methods with simple set-ups, but makes things complicated when the number of tests increases and the set-up is complex. Often, each test further adjusts the previously set-up object before performing any verifications, further complicating the process of figuring out what state an object has in a given test. Tear-down methods clean up after tests, perhaps by removing records from a database or deleting files from the file-system. The duplication that setup methods and tear-down methods hope to remove is better avoided by improving your interfaces. This can be done by providing better set-up methods for your objects and using idioms such as {Resource Acquisition Is Initialization}¹ for guaranteed clean-up, test or no test. By not using setup and tear-down methods we keep everything pertinent to a test in the test itself, thus improving test isolation. (You also won’t {slow down your tests}² by keeping unnecessary state.) Most unit test frameworks also allow you to create arbitrary test helper methods. Lookout doesn’t. The same rationale as that that has been crystallized in the preceding paragraphs applies. If you need helpers you’re interface isn’t good enough. It really is as simple as that. To clarify: there’s nothing inherently wrong with test helper methods, but they should be general enough that they reside in their own library. The support for mocks in Lookout is provided through a set of test helper methods that make it easier to create mocks than it would have been without them. Lookout-rack³ is another example of a library providing test helper methods (well, one method, actually) that are very useful in testing web applications that use Rack⁴. A final point at which some unit test frameworks try to fragment tests further is documentation. These frameworks provide ways of describing the whats and hows of what’s being tested, the rationale being that this will provide documentation of both the test and the code being tested. Describing how a stack data structure is meant to work is a common example. A stack is, however, a rather simple data structure, so such a description provides little, if any, additional information that can’t be extracted from the implementation and its tests themselves. The implementation and its tests is, in fact, its own best documentation. Taking the points made in the previous paragraphs into account, we should already have simple, self-describing, interfaces that have easily understood tests associated with them. Rationales for the use of a given data structure or system-design design documentation is better suited in separate documentation focused at describing exactly those issues. ¹ Read the Wikipedia entry for Resource Acquisition Is Initialization at http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization ² Read how 37signals had problems with slow Test::Unit tests at http://37signals.com/svn/posts/2742-the-road-to-faster-tests/ ³ Visit the Lookout-rack home page at http://disu.se/software/lookout-rack/ ⁴ Visit the Rack Rubyforge project page at http://rack.rubyforge.org/ § Internal Design The internal design of Lookout has had a couple of goals. • As few external dependencies as possible • As few internal dependencies as possible • Internal extensibility provides external extensibility • As fast load times as possible • As high a ratio of value objects to mutable objects as possible • Each object must have a simple, obvious name • Use mix-ins, not inheritance for shared behavior • As few responsibilities per object as possible • Optimizing for speed can only be done when you have all the facts § External Dependencies Lookout used to depend on Mocha for mocks and stubs. While benchmarking I noticed that a method in Mocha was taking up more than 300 percent of the runtime. It turned out that Mocha’s method for cleaning up back-traces generated when a mock failed was doing something incredibly stupid: backtrace.reject{ |l| Regexp.new(@lib).match(File.expand_path(l)) } Here ‹@lib› is a ‹String› containing the path to the lib sub-directory in the Mocha installation directory. I reported it, provided a patch five days later, then waited. Nothing happened. {254 days later}¹, according to {Wolfram Alpha}², half of my patch was, apparently – I say “apparently”, as I received no notification – applied. By that time I had replaced the whole mocking-and-stubbing subsystem and dropped the dependency. Many Ruby developers claim that Ruby and its gems are too fast-moving for normal package-managing systems to keep up. This is testament to the fact that this isn’t the case and that the real problem is instead related to sloppy practices. Please note that I don’t want to single out the Mocha library nor its developers. I only want to provide an example where relying on external dependencies can be “considered harmful”. ¹ See the Wolfram Alpha calculation at http://www.wolframalpha.com/input/?i=days+between+march+17%2C+2010+and+november+26%2C+2010 ² Check out the Wolfram Alpha computational knowledge engine at http://www.wolframalpha.com/ § Internal Dependencies Lookout has been designed so as to keep each subsystem independent of any other. The diff subsystem is, for example, completely decoupled from any other part of the system as a whole and could be moved into its own library at a time where that would be of interest to anyone. What’s perhaps more interesting is that the diff subsystem is itself very modular. The data passes through a set of filters that depends on what kind of diff has been requested, each filter yielding modified data as it receives it. If you want to read some rather functional Ruby I can highly recommend looking at the code in the ‹lib/lookout/diff› directory. This lookout on the design of the library also makes it easy to extend Lookout. Lookout-rack was, for example, written in about four hours and about 5 of those 240 minutes were spent on setting up the interface between the two. § Optimizing For Speed The following paragraph is perhaps a bit personal, but might be interesting nonetheless. I’ve always worried about speed. The original Expectations library used ‹extend› a lot to add new behavior to objects. Expectations, for example, used to hold the result of their execution (what we now term “evaluation”) by being extended by a module representing success, failure, or error. For the longest time I used this same method, worrying about the increased performance cost that creating new objects for results would incur. I finally came to a point where I felt that the code was so simple and clean that rewriting this part of the code for a benchmark wouldn’t take more than perhaps ten minutes. Well, ten minutes later I had my results and they confirmed that creating new objects wasn’t harming performance. I was very pleased. § Naming I hate low lines (underscores). I try to avoid them in method names and I always avoid them in file names. Since the current “best practice” in the Ruby community is to put ‹BeginEndStorage› in a file called ‹begin_end_storage.rb›, I only name constants using a single noun. This has had the added benefit that classes seem to have acquired less behavior, as using a single noun doesn’t allow you to tack on additional behavior without questioning if it’s really appropriate to do so, given the rather limited range of interpretation for that noun. It also seems to encourage the creation of value objects, as something named ‹Range› feels a lot more like a value than ‹BeginEndStorage›. (To reach object-oriented-programming Nirvana you must achieve complete value.) § News § 3.0.0 The ‹xml› expectation has been dropped. It wasn’t documented, didn’t suit very many use cases, and can be better implemented by an external library. The ‹arg› argument matcher for mock method arguments has been removed, as it didn’t provide any benefit over using Object. The ‹#yield› and ‹#each› methods on stub and mock methods have been removed. They were slightly weird and their use case can be implemented using block parameters instead. The ‹stub› method inside ‹expect› blocks now stubs out the methods during the execution of a provided block instead of during the execution of the whole except block. When a mock method is called too many times, this is reported immediately, with a full backtrace. This makes it easier to pin down what’s wrong with the code. Query expectations were added. Explicit query expectations were added. Fluent boolean expectations, for example, ‹expect nil.to.be.nil?› have been replaced by query expectations (‹expect :nil? do nil end›) and explicit query expectations (‹expect result.to.be.nil? do nil end›). This was done to discourage creating objects as the expected value and creating objects that change during the course of the test. The ‹literal› expectation was added. Equality (‹#==›) is now checked before “caseity” (‹#===›) for modules, ranges, and regular expressions to match the documentation. § 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%40disu%2ese&item_name=Lookout § Reporting Bugs Please report any bugs that you encounter to the {issue tracker}¹. ¹ See https://github.com/now/lookout/issues § Contributors Contributors to the original expectations codebase are mentioned there. We hope no one on that list feels left out of this list. Please {let us know}¹ if you do. • Nikolai Weibull ¹ Add an issue to the Lookout issue tracker at https://github.com/now/lookout/issues § Licensing Lookout 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/

ruby-spacy is a wrapper module for using spaCy from the Ruby programming language via PyCall. This module aims to make it easy and natural for Ruby programmers to use spaCy. This module covers the areas of spaCy functionality for using many varieties of its language models, not for building ones.

RubyNEAT -- Neural Evolution of Augmenting Topologies for Ruby. By way of an enhanced form of Genetic Algorithms -- the NEAT algorithm, populations of neural nets are evolved to handle pre-defined goals. RubyNEAT is the first implementation of the NEAT algorithm for Ruby, and it leverages Ruby's power to implement the NEAT algorithm in a way that would be difficult to do in other languages. The 'activation function' is largely standalone. Basically, activation is achieved by functional programming. Meaning, once your network is evolved, you can extract it as source code you can then utilize without the RubyNEAT engine. RubyNEAT can be used for nearly any Machine Learning task you can dream of, because it's also extensible and modular. See http://rubyneat.com for the details.

Tools to assist in programming in a more functional style

RedisRPC is the easiest to use RPC library in the world. (No small claim!) It has implementations in Ruby, PHP, and Python. Redis is a powerful in-memory data structure server that is useful for building fast distributed systems. Redis implements message queue functionality with its use of list data structures and the `LPOP`, `BLPOP`, and `RPUSH` commands. RedisRPC implements a lightweight RPC mechanism using Redis message queues to temporarily hold RPC request and response messages. These messages are encoded as JSON strings for portability. Many other RPC mechanisms are either programming language specific (e.g. Java RMI) or require boiler-plate code for explicit typing (e.g. Thrift). RedisRPC was designed to be extremely easy to use by eliminating boiler-plate code while also being programming language neutral. High performance was not an initial goal of RedisRPC and other RPC libraries are likely to have better performance. Instead, RedisRPC has better programmer performance; it lets you get something working immediately.

Aims to extend Ruby standard library, providing some useful tools that's not existed in the standard library, especially for functional programming.

A prelude library that belongs to the book "functional programming in ruby".

Graphics provides a simple framework to implement games and/or simulations and is designed to follow mathematical conventions, NOT game programming conventions. Particularly it: * Uses degrees. * Draws in quadrant 1 (0-90 degrees). * Right hand rule: 0 degrees is east, 90 is north, etc. These allow simple things like Trigonometry functions to work as expected. It means that all that stuff you were taught in grade school still work as intended. This makes one less thing you have to adjust when implementing your simulation.

Ruber is a Ruby editor for KDE 4 written in pure ruby, making use of the excellent ruby bindings for KDE 4 (korundum). Ruber is plugin-based, meaning that almost all its functionality is provided by plugins. This has two important consequences: 1) A user can write plugins having availlable all the features availlable to the Ruber developers. In other words, there's not a plugin-specifi API 2) Users can write plugins which replace some of the core functionality of \ Ruber. For example, a user can create a plugin which replaces the default plugin to run ruby programs

LiveScript is a language which compiles to JavaScript. It has a straightforward mapping to JavaScript and allows you to write expressive code devoid of repetitive boilerplate. While LiveScript adds many features to assist in functional style programming, it also has many improvements for object oriented and imperative programming.

A library to do Functional Reactive Programming in Ruby.

== DESCRIPTION: Charlie is a library for genetic algorithms (GA) and genetic programming (GP). == FEATURES: - Quickly develop GAs by combining several parts (genotype, selection, crossover, mutation) provided by the library. - Sensible defaults are provided with any genotype, so often you only need to define a fitness function. - Easily replace any of the parts by your own code. - Test different strategies in GA, and generate reports comparing them. Example report: http://charlie.rubyforge.org/example_report.html == INSTALL: * sudo gem install charlie == EXAMPLES: This example solves a TSP problem (also quiz #142): N=5 CITIES = (0...N).map{|i| (0...N).map{|j| [i,j] } }.inject{|a,b|a+b} class TSP &lt; PermutationGenotype(CITIES.size) def fitness d=0 (genes + [genes[0]]).each_cons(2){|a,b| a,b=CITIES[a],CITIES[b] d += Math.sqrt( (a[0]-b[0])**2 + (a[1]-b[1])**2 ) } -d # lower distance -&gt; higher fitness. end use EdgeRecombinationCrossover, InversionMutator end Population.new(TSP,20).evolve_on_console(50) This example finds a polynomial which approximates cos(x) class Cos &lt; TreeGenotype([proc{3*rand-1.5},:x], [:-@], [:+,:*,:-]) def fitness -[0,0.33,0.66,1].map{|x| (eval_genes(:x=&gt;x) - Math.cos(x)).abs }.max end use TournamentSelection(4) end Population.new(Cos).evolve_on_console(500)

Church provides top-level constant Procs to do various and sundry kinds of functional programming.

include login, send subscribe message, get phone number function of mini program

Miscellaneous functions and classes to help Ruby programming. To be used in other NumRu libraries.

AnySpec is a framework for writing executable language specifications and automated black-box functional tests for programming languages.

Support code for functional programming

P is a small ('pequena' in portuguese) functional programming language.

This gem implements the functionality to take a signature of the current Ruby program (i.e. the current process) and respawn it whenever the source code or libraries change

Watcher provides advanced integrated exception handling and logging functionality to your Ruby programs.

Functional programming with collections (Higher Order Methods)

"I wanted to make a fun programming language so I did. It's mine. My own. My Precious... Precious is a LOTR esoteric programming language translator. Precious uses lore keywords and english to create simple programming functionality."

rns is a namespace management library designed to ease functional programming in Ruby.

Music Coder is a music programming library. It generates music entirely through code in the chosen programming language (Ruby). There are three main reasons a technically minded person would use Music Coder: Producing music: Write scripts that mimic human creativity, and put some randomness in it, giving you a program that can generate aesthetically pleasing music that is completely unique in each file generated. Scientific exploration: Use the functions in Music Coder to concisely apply algorithms or math to the structure and properties of sound. Making samples: create samples or sections of music that are too complex to be done by hand in graphical audio programs such as Ableton.

This is the MySQL API module for Ruby. It provides the same functions for Ruby programs that the MySQL C API provides for C programs. Some small mods by http://github.com/lsegal/mysql-ruby for ruby 1.9.1 support for utf-8

A Ruby implementation of the Lox programming language. Lox is a dynamically typed, object-oriented programming language that features first-class functions, closures, classes, and inheritance.

RedisRpc is the easiest to use RPC library in the world. (No small claim!). This version is a repackage that only has Ruby implementation. Redis is a powerful in-memory data structure server that is useful for building fast distributed systems. Redis implements message queue functionality with its use of list data structures and the `LPOP`, `BLPOP`, and `RPUSH` commands. RedisRpc implements a lightweight RPC mechanism using Redis message queues to temporarily hold RPC request and response messages. These messages are encoded as JSON strings for portability. Many other RPC mechanisms are either programming language specific (e.g. Java RMI) or require boiler-plate code for explicit typing (e.g. Thrift). RedisRpc was designed to be extremely easy to use by eliminating boiler-plate code while also being programming language neutral. High performance was not an initial goal of RedisRpc and other RPC libraries are likely to have better performance. Instead, RedisRpc has better programmer performance; it lets you get something working immediately.

Terraform's HCL lacks quite many programming features like iterators, true variables, advanced string manipulation, functions etc. This Ruby tool provides an easy-to-use DSL to define Terraform compatible .json files which can then be used with Terraform side-by-side with HCL files.

Easy_html_creator is a gem that makes developing static HTML websites easy and joyful. Once you learned the joy of haml or sass, it get boring to program in 'plain old' html and css. Using our Gem you could generate and maintain multiple static websites and program them in your preferred languages. Currently supported by our fast and lightweight re-generation server: HAML, Sass (with bootstarp) and CoffeeScript. We also included the 'actionview' gem, to enable the use of rails standard functions like 'text_field_tag'.

Sanzang is a compact and simple cross-platform machine translation system. It was designed especially for translating from the CJK languages (Chinese, Japanese, and Korean), and it is suitable even for translating from ancient texts. Sanzang is implemented as a Unix style command suite program, with each subcommand carrying out a major function of the system.

functional programming library for ruby

Provide a similar way to config HCL (HashiCorp Configuration Language) in ruby. And featuring all programming features (variables, iterators, functions, regexp, etc) in ruby.

This is the MySQL API module for Ruby. It provides the same functions for Ruby programs that the MySQL C API provides for C programs.

RDocF95 is an improved RDoc for generation of documents of Fortran 90/95 programs. Differences to the original one are given below. &lt;b&gt;Enhancement of &quot;parser/f95.rb&quot;&lt;/b&gt; :: The Fortran 90/95 parse script &quot;parser/f95.rb&quot; (In rdoc-f95, old name &quot;parsers/parse_f95.rb&quot; is used yet) is modified in order to parse almost all entities of the Fortran 90/95 Standard. &lt;b&gt;Addition of &lt;tt&gt;--ignore-case&lt;/tt&gt; option &lt;/b&gt; :: In the Fortran 90/95 Standard, upper case letters are not distinguished from lower case letters, although original RDoc produces case-dependently cross-references of Class and Methods. When this options is specified, upper cases are not distinguished from lower cases. &lt;b&gt;Cross-reference of file names&lt;/b&gt; :: Cross-reference of file names is available as well as modules, subroutines, and so on. &lt;b&gt;Modification of &lt;tt&gt;--style&lt;/tt&gt; option&lt;/b&gt; :: Original RDoc can not treat relative path stylesheet. Application of this patch modifies this function. &lt;b&gt;Conversion of TeX formula into MathML&lt;/b&gt;:: TeX formula can be converted into MathML format with --mathml option, if &lt;b&gt;MathML library for Ruby version 0.6b -- 0.8&lt;/b&gt; is installed. This library is available from {Bottega of Hiraku (only JAPANESE)}[http://www.hinet.mydns.jp/~hiraku/]. See {RDocF95::Markup::ToXHtmlTexParser}[link:classes/RDocF95/Markup/ToXHtmlTexParser.html] about format. &lt;b&gt;*** Caution ***&lt;/b&gt; Documents generated with &quot;--mathml&quot; option are not displayed correctly according to browser and/or its setting. We have been confirmed that documents generated with &quot;--mathml&quot; option are displayed correctly with {Mozilla Firefox}[http://www.mozilla.org/products/firefox/] and Internet Explorer (+ {MathPlayer}[http://www.dessci.com/en/products/mathplayer/]). See {MathML Software - Browsers}[http://www.w3.org/Math/Software/mathml_software_cat_browsers.html] for other browsers. Some formats of comments in HTML document are changed to improve the analysis features. See {parse_f95.rb}[link:files/lib/rdoc-f95/parsers/parse_f95_rb.html]

Functional programming is gaining more and more mindshare in software lately. One of the main benefits of programming in the functional style is function composition. Function composition allows you to break your program into small manageable chunks that can be put together in new and interesting ways. Object Oriented Programming is supposed to be composable, but the composition is lacking compared to FP. Perhaps Ruby's flexibility can get us part of the way there?

Examples of immutable data structures and functional programming in Ruby

Schaefer is a small programming language deigned to show how to build a programming language. Running the command 'schaefer' begins console based execution of code and passing a file name will execute the file. SchaeferScript is a scheme-style language where the core functions are written in ruby and other functions written in the language itself. You can access the source for SchaeferScript at https://github.com/tommyschaefer/SchaeferScript.

A service skeleton with an emphasis on simplicity with a pinch a functional programming

Generators to build random data, which compose (in the functional-programming sense) so that you can build larger ones from many smaller ones.

Pure Functional Programming with your microcomputer.

== README.md: #ScheduledResource This gem is for displaying how things are used over time -- a schedule for a set of "resources". You can configure the elements of the schedule and there are utilities and protocols to connect them: - Configuration (specification and management), - Query interfaces (a REST-like API and internal protocols to query the models), and - A basic Rails controller implementation. We have a way to configure the schedule, internal methods to generate the data, and a way to retrieve data from the client. However this gem is largely view-framework agnostic. We could use a variety of client-side packages or even more traditional Rails view templates to generate HTML. In any case, to get a good feel in a display like this we need some client-side code. The gem includes client-side modules to: - Manage &lt;b&gt;time and display geometries&lt;/b&gt; with "infinite" scroll along the time axis. - &lt;b&gt;Format display cells&lt;/b&gt; in ways specific to the resource models. - &lt;b&gt;Update text justification&lt;/b&gt; as the display is scrolled horizontally. ## Configuration A **scheduled resource** is something that can be used for one thing at a time. So if "Rocky &amp; Bullwinkle" is on channel 3 from 10am to 11am on Saturday, then 'channel 3' is the &lt;u&gt;resource&lt;/u&gt; and that showing of the episode is a &lt;u&gt;resource-use&lt;/u&gt; block. Resources and use-blocks are typically Rails models. Each resource and its use-blocks get one row in the display. That row has a label to the left with some timespan visible on the rest of the row. Something else you would expect see in a schedule would be headers and labels -- perhaps one row with the date and another row with the hour. Headers and labels also fit the model of resources and use-blocks. Basic timezone-aware classes (ZTime*) for those are included in this gem. ### Config File The schedule configuration comes from &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; which has three top-level sections: - ResourceKinds: A hash where the key is a Resource and the value is a UseBlock. (Both are class names), - Resources: A list where each item is a Resource Class followed by one or more resource ids, and - visibleTime: The visible timespan of the schedule in seconds. The example file &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; (installed when you run &lt;tt&gt;schedulize&lt;/tt&gt;) should be enough to display a two-row schedule with just the date above and the hour below. Of course you can monkey-patch or subclass these classes for your own needs. ### The schedule API The 'schedule' endpoint uses parameters &lt;tt&gt;t1&lt;/tt&gt; and &lt;tt&gt;t2&lt;/tt&gt; to specify a time interval for the request. A third parameter &lt;tt&gt;inc&lt;/tt&gt; allows an initial time window to be expanded without repeating blocks that span those boundaries. The time parameters _plus the configured resources_ define the data to be returned. ### More About Configuration Management The &lt;b&gt;ScheduledResource&lt;/b&gt; class manages resource and use-block class names, id's and labels for a schedule according to the configuration file. A ScheduledResource instance ties together: 1. A resource class (eg TvStation), 2. An id (a channel number in this example), and 3. Strings and other assets that will go into the DOM. The id is used to - select a resource _instance_ and - select instances of the _resource use block_ class (eg Program instances). The id _could_ be a database id but more often is something a little more suited to human use in the configuration. In any case it is used by model class method &lt;tt&gt;(resource_use_block_class).get_all_blocks()&lt;/tt&gt; to select the right use-blocks for the resource. A resource class name and id are are joined with a '_' to form a tag that also serves as an id for the DOM. Once the configuration yaml is loaded that data is maintained in the session structure. Of course having a single configuration file limits the application's usefulness. A more general approach would be to have a user model with login and configuration would be associated with the user. ## Installation Add this line to your application's Gemfile: ```ruby gem 'scheduled_resource' ``` And then execute: $ bundle Or install it yourself as: $ gem install scheduled_resource Then from your application's root execute: $ schedulize . This will install a few image placeholders, client-side modules and a stylesheet under &lt;tt&gt;vendor/assets&lt;/tt&gt;, an example configuration in &lt;tt&gt;config/resource_schedule.yml&lt;/tt&gt; and an example controller in &lt;tt&gt;app/controllers/schedule_controller.rb&lt;/tt&gt;. Also, if you use $ bundle show scheduled_resource to locate the installed source you can browse example classes &lt;tt&gt;lib/z_time_*.rb&lt;/tt&gt; and the controller helper methods in &lt;tt&gt;lib/scheduled_resource/helper.rb&lt;/tt&gt; ## Testing This gem also provides for a basic test application using angularjs to display a minimal but functional schedule showing just the day and hour headers in two different timezones (US Pacific and Eastern). Proceed as follows, starting with a fresh Rails app: $ rails new test_sr As above, add the gem to the Gemfile, then $ cd test_sr $ bundle $ schedulize . Add lines such as these to &lt;tt&gt;config/routes.rb&lt;/tt&gt; get "/schedule/index" =&gt; "schedule#index" get "/schedule" =&gt; "schedule#schedule" Copy / merge these files from the gem source into the test app: $SR_SRC/app/views/layouts/application.html.erb $SR_SRC/app/views/schedule/index.html.erb $SR_SRC/app/assets/javascripts/{angular.js,script.js,controllers.js} and add &lt;tt&gt;//= require angular&lt;/tt&gt; to application.js just below the entries for &lt;tt&gt;jquery&lt;/tt&gt;. After you run the server and browse to http://0.0.0.0:3000/schedule/index you should see the four time-header rows specified by the sample config file. ## More Examples A better place to see the use of this gem is at [tv4](https://github.com/emeyekayee/tv4). Specifically, models &lt;tt&gt;app/models/event.rb&lt;/tt&gt; and &lt;tt&gt;app/models/station.rb&lt;/tt&gt; give better examples of implementing the ScheduledResource protocol and adapting to a db schema organized along somewhat different lines. ## Contributing 1. Fork it ( https://github.com/emeyekayee/scheduled_resource/fork ) 2. Create your feature branch (`git checkout -b my-new-feature`) 3. Commit your changes (`git commit -am 'Add some feature'`) 4. Push to the branch (`git push origin my-new-feature`) 5. Create a new Pull Request