Get rid of the DL deprecated message from Pry and IRB in Ruby 2.0 on Windows

It's a commonly known fact that in Ruby 2.0 on Windows, Pry and IRB display the infamous message DL is deprecated, please use Fiddle. This can get annoying after some time. If you really want to remove this message, I found a method to do it and it's actually very simple.

Start off by installing the rb-readline gem, by Luis Lavena, of RubyInstaller fame:

gem install rb-readline

This is a pure ruby implementation of Readline that doesn't require DL.

Let's start with Pry. First, open or create your .pryrc file. I'm not going to explain what the file is. You can find that information here. The file should be in %HOMEDRIVE%%HOMEPATH%. If it isn't, then you need to create one through the command prompt, since Windows Explorer doesn't like creating files that start with a dot. This command will create an empty .pryrc file from the command prompt for you:

echo. 2> %HOMEDRIVE%%HOMEPATH%\.pryrc

Editing the file, include the following:

gem 'rb-readline'

Now, if you open Pry the message is gone. Victory!

Unfortunately, .irbrc doesn't work the same way that .pryrc does. IRB actually loads .irbrc only after requiring readline, but if you don't mind editing code that came with Ruby, then follow on.

Go to the bin directory of your Ruby installation, and open the irb file (not the irb.bat file), and add the same gem line from above, before require "irb":

gem 'rb-readline'

If you open IRB the message is gone.

ObjectSpace::define_finalizer says no

In Ruby, one has to be extremely careful when using ObjectSpace::define_finalizer. I fell for this trap:


See the problem here? Well, I didn't at first, until I noticed that my program only freed memory at shutdown. The problem here is that the proc is created with the obj instance as part of it's scope... or self, even if it isn't used inside the proc, which is the infamous ObjectSpace::define_finalizer bug.

To correct, I removed the obj parameter and called define_finalizer directly like so:


This time around my computer started to say yes:

I hope this post may help someone, since I didn't find anything on the interwebs that exposed this specific issue.

DB2 SQL - Some secrets

I don't know how many people know about this, but I found a neat trick when using DB2 SQL.
Usually you have to query something like this:

Now in DB2 SQL (at least it works in iSeries/AS400), you can simplify it like this:

Maybe it doesn't seem very useful, but most of the tables that I work with have a double or triple key (one being product and the other a serial number per product).
The real advantage comes when using a group of rows. Instead of using a temporary table and joining in the query, or making something horrible like:

It's much more simple to write it like this:

Matlab Vector Graphics

Matlab v7.5 still has trouble with vector graphics. When trying to create a vector image it, instead, generates a bitmap image if you use rgb colors (for example in scatter) instead of colormap indices.

Here's an example:

But there is a workaround. Instead of doing this:

Do it like this to be able to export in vector format (like eps):

Now each point, instead of being colored by the rgb data, it is indexed to the custom colormap, which is exactly made up of the rgb data we want. Now it is possible to export to vector.

(Sorry, blogger doesn't like svg.)

Firebird Embedded in SQuirreL SQL (in Windows)

After 5 days I have finally been able to setup Firebird Embedded in SQuirreL SQL.

And I call myself a programmer... Shame on me!

Since I haven't found any concise tutorial on how this can be achieved (for newbies in Firebird, at least), I'll write here on how to do it.

You will need three things:

• SQuirreL SQL
• Jaybird (a.k.a., Firebird JDBC)
• Firebird Embedded "edition" (Follow the current release link, then select an "embed" installation)

Unpack both zips into the same folder. You will only need the following:

Jaybird archive:

• jaybird-full-*.jar
• jaybird21.dll

Firebird embedded archive:

• fbembed.dll
• ib_util.dll
• icudt30.dll
• icuin30.dll
• icuuc30.dll
• firebird.conf (if you wish to provide custom configuration)
• firebird.msg
• intl\* (folder)

After the libraries and SQuirreL SQL are installed, you have to setup a connection and some paths for the libraries.

Before opening SQuirreL, go to the directory where it is installed. In there you will find the main runnable batch file: squirrel-sql.bat. Edit the file and insert the red colored text in the last line:

start "SQuirreL SQL Client" /B "%LOCAL_JAVA%w" -Djava.library.path=/path/to/jaybird_dll -Xmx256m -cp %TMP_CP% net.sourceforge.squirrel_sql.client.Main %TMP_PARMS%

Replace with the path where the file jaybird21.dll is installed. It will typically be in the same folder as jaybird-full-*.jar.

Open SQuirreL and choose "Firebird JayBird" from drivers. On "Extra Class Path", point to the jaybird-full.jar that was unpacked from the archive you downloaded.

Since it is the embedded version, make sure your database string is:

jdbc:firebirdsql:embedded:<database_path>

Simplifying conditionals

My job requires me to work in RPG, an old, old language. Worse yet I cannot use the free keyword because of our pre-processor, and I don't see that changing for some time.

With that in mind, I show you what I have learned when working with conditionals (specifically if).

Let's first assume that lowercase are boolean expressions and that uppercase are sets of statements and expressions (i.e., code instructions). Next I present some snippets, following a demonstration on how to simplify them.

Note: Ignore the brackets. I only use then to make clear where code breaks.

Case 1

Simplification:

Case 2

Yes, I do find many of these:

Simplification:

Case 3

Intermediate step:

Simplification:

To some people this can seem quite obvious, but I find that most people don't bother to apply these rules, which gives readability a punch in the face.

Distributed Tree Construction

During this semester, at college, I had a project on Epidemic Algorithms (a.k.a. Gossip or Rumor Algorithms) on a dynamic system, where new nodes enter and existing nodes leave (or crash) from the system. One challenge was to find the average of the system, and I thought that a distributed tree could solve that problem.
One additional restriction was that each node could not know more than 1% of the total system. This rule is what sets this protocol apart from the other existing (and more common) ones.
According to the protocol I implemented, the parents are responsible for accumulating the information of their children, and by the previous restriction, there is a need for the parent to limit the number of children it has.
The protocol consists on three types of messages:

• Parent Query Message
• Child Accept Message
• Parent Refuse Message

For the protocol to work some requirements come to order:

• Each node needs a unique identifier. A GUID, an IP, or a MAC address should suffice. This will serve as a tie breaker in root choosing. The concept of “better root” is relative and any concept of uniqueness can be used. In the project I chose minimum id.
• Communications don't fail, i.e., the child didn't exit, but was unable to communicate with the parent or vice versa.

Initially all nodes consider themselves as a root. From time to time, a node sends a Parent Query Message, initiating the protocol. This message indicates that the node is searching for a parent (the construction of the tree is bottom-up). If the receiver node is full (no more space for new children) or already contains the sending node as child, then the node discards the message. If it isn't full then, the receiver node will check which root is best, the one it currently has or the one received in the message. In case the root it has is the best it adds the sender as a child and sends back a Child Accept Message. On the other hand, if the root sent in the message is better (and not the same), then it sends back a Parent Query Message, reversing the roles of parent/child.
A Child Accept Message, indicates the node was accepted as a child of a node. It also implies that it already sent a Parent Query Message.
Since some events might have occurred between sending the Parent Query and the Child Accept messages, the node has to confirm if it will link with the new parent. If the receiver (new child) node had already found a better parent (with better root), it will send a Parent Reject Message, else it will register the new parent and new root, if it isn't already (a node initiates the protocol randomly, so it might have sent a Parent Query more than once to the same node).
The Parent Reject Message serves to inform a parent to discard any information about a child that it might have.
Any other protocol (like the average finding one), working over the tree protocol, needs to communicate in both directions, up and down.
When going down, in case the child fails to report to the parent, the parent can assume a Parent Reject Message and remove any stats it has of that child. When going up the node resets itself has a root, resetting any stats it needs, and resumes protocol in Parent Query to link itself to another tree.

Here's some pseudo-code:

Fields:
    UID root
    Node parent
    List children // Size <= 1% of system size
    List knownNodes // Size <= 1% of system size

Initialize()
{
    root = getMyID()
    parent = this
    populate(knownNodes)
    children = createList()

    resetStats()
}

Periodically call:
LinkTree()
{
    Node n = random(knownNodes)
    send(n, ParentQuery(root))
}

OnReceive(Node sender, ParentQuery msg)
{
    if(not isFull(children) and not contains(children, sender))
    {
        if(isBetter(msg.Root, root))
        {
            add(children, sender)
            send(sender, ChildAccept(root))
        }
        else if(not equal(msg.Root, root))
        {
            send(sender, ParentQuery(root))
        }
    }
}

OnReceive(Node sender, ChildAccept msg)
{
    if(isBetter(msg.Root, root))
    {
        if(not equal(parent, this))
        {
            send(parent, ParentRefuse())
        }

        parent = sender
        root = msg.Root
    }
    else // I already have a better parent
    {
        send(sender, ParentRefuse())
    }
}

OnReceive(Node sender, ParentRefuse msg)
{
    remove(children, sender)
    removeStats(sender)
}

OnFailure(Node receiver)
{
    remove(knownNodes, receiver)

    if(equal(parent, receiver))
    {
        root = getMyID()
        parent = this
        resetStats()
    }
    else
    {
        remove(children, receiver)
        removeStats(receiver)
    }
}