Anyway, the washer was draining too fast, and thus overflowing the drain pipe. I found a good solution at FixItNow.com, which includes draining directly into one fork of a y-pipe, and extending the other fork much higher in the air as a “surge” pipe. Tried it out; works like a charm. I made the surge pipe higher than it needed to be (by about 1 foot), but it helps as the water being drained tends to come out at fairly high pressure, and since it’s now entering at an angle it tends to splash a bit.

I also ended up needing more parts than were necessary due to the hardware store not having everything. The y-pipe is 2ʺ at both vertical ends, and the fork is 1-1/2ʺ. The hardware store didn’t have a 1-1/2ʺ to 1ʺ threaded reducer (the washer drain hose is 1ʺ), only a 1-1/2ʺ to 1-1/4ʺ threaded, so I also had to buy a 1-1/4ʺ threaded to 1ʺ threaded to screw the hose adapter in.

Poor pictures taken with my cell phone below:

#!/bin/bash
# chkconfig: 2345 20 80
# description: gem server
# processname: gem_server
# pidfile: /var/lock/subsys/gem_server

source /etc/rc.d/init.d/functions
prog=”/usr/local/bin/gem server –daemon”

start() {
pid=$(ps ax -o pid,command | grep “gem server” | grep daemon | awk ‘{print $1}’)
if test -n “$pid”
then
echo “gem server already running : PID $pid”
else
$prog
fi
}

stop() {
pid=$(ps ax -o pid,command | grep “gem server” | grep daemon | awk ‘{print $1}’)
if test -n “$pid”
then
echo “stopping gem server”
kill $pid
else
echo “gem server not running”
fi
}

case “$1″ in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo $”Usage: $0 {start|stop|restart}”
exit 1
esac

private function doIt( ...args ):void

… then called the method:

doIt( 1 )
doIt( 1, 2 )
doIt( "some", "other", "stuff" )

The question is this: from within that method, how do you send those same arguments on to another method that accepts a dynamic argument array? You can’t just pass the “args” array, as the method called will only see 1 argument; the array you passed it. Instead, you need to “explode” the array into its’ original parts. Here’s the most simple way I’ve found to forward that array on to the next method:

public function doIt( ...args ):void
{
   var someObject:SomeType = new SomeType()
   someObject.someMethod.apply( someObject, args );
}

The “apply” method of Function does exactly what we need. Now “someMethod” will have it’s own argument array, and be able to access them the same way you were able to from within “doIt”.

This all came about when we began writing a wrapper of sorts for WebServices. We created our own RPC class, with a “call” method that accepts the parameters, and we needed to forward them on to Operation’s “send” method. Below is a much simplified example:

import mx.rpc.soap.Operation;
public class RPC
{
  public static function call( operation, ...params ):void
  {
    //...code to initialize WebService "svc"
    var op:Operation = Operation( svc.getOperation(operation) );
    //...more code (unimportant)
    var token:AsyncToken = op.send.apply( op, params  );
    //...code to hook up handlers
  }
}

Using Ruby, let’s suppose we have a simple math problem… and we want to check equality:

1.2 + 1.0 == 2.2 (returns true)

Yay, it’s correct! But that’s not really much to ask of a language is it now. Let’s switch it up just a little bit:

1.2 - 1.0 == 0.2 (returns false)

Uhh… Ruby? You OK? I really don’t understand how this is acceptable. I know the argument that we generally work and think in a base10 system, while computers generally store numbers in binary, and there’s no exact way to store many numbers. But shouldn’t that be fixed (and by fixed, I mean an easy way provided for us to perform exact base10 math), assuming once again, we generally work in base10? i.e. when I subtract 1 from 1.2, shouldn’t I get exactly 0.2?
Anyway, if you do a little research, you’ll find that BigDecimal is supposedly much more accurate when performing calculations, so let’s try that:

require 'bigdecimal'
BigDecimal.new('1.2') - BigDecimal.new('1') ==
   BigDecimal.new('0.2') (returns true)

Yay, it worked! …but who wants to type ‘BigDecimal.new’ a thousand times? Dig a little further and you’ll find a BigDecimal utility, which adds functionality to other Ruby Numeric classes to convert them to BigDecimals:

require 'bigdecimal'
require 'bigdecimal/util'
1.2.to_d - 1.0.to_d == 0.2.to_d (returns true)

Still works, and it’s definitely cleaner, but remembering to append ‘.to_d’ may be somewhat of a pain (and unnecessarily ugly.) The innaccuracy of Float can still bite you, however; check this out:

require 'bigdecimal'
require 'bigdecimal/util'
x = 1.2000000000000000001.to_d
puts x.to_s('F') (prints 1.2)

Yep, our 1 in the 1/1000000000000000000th place at the end is lost. This is probably because BigDecimal is aware of the innaccuracy of Float, and since that was of such small value, it assumed it was just a precision issue and is dropped. Frustrating!

Another issue for us might be that using BigDecimal in place of Float probably has more overhead; I don’t personally have any benchmarks to compare the two. But, then again, I don’t really need them. For me, being precise far outweighs it being fast (to a point of course). If I was performing some super-intensive process, that did crazy math, and as a result I only needed an answer that was pretty close but not exact, I’d probably give Float a chance. But until then, it’s BigDecimal for me, despite it not being the easist/cleanest/prettiest solution.

At any rate, I can live (for now) with implementing BigDecimal in this way (or ‘new’ing them up when appropriate.) But if you happen to use ActionWebService in Rails, you have another problem. Currently (as of version 1.2.3), when you define your API, and use the :float datatype, you’ll find this does in fact use Float to convey numbers. Dig a little, and you’ll find that in their SVN repository they may be working on changing this to use BigDecimal instead. One can only hope!

A coworker and I attempted to dig in and try to convert it ourselves for use in a current project, but that attempt was fairly short-lived, and we instead use the “.to_d” method above to convert them to BigDecimals once inside the service method. This works for us, since we’re generally dealing with dollar amounts that aren’t terribly huge, so we’re only concerned with accuracy to the penny.

I fully intend, at some point, to revisit this issue and perhaps instead of replacing :float to use BigDecimal, using :decimal or :bigdecimal, thus leaving the ability to use Float if so desired. Hopefully by the time I get to it, they’ll release a new version with it already implemented. I can dream can’t I?