Kick off of playing with trees

As I have stated before, I enjoy the speed at which I can prototype an idea in Ruby. Even if ultimately that idea runs better on another language. For the sake of my academics, it provides a super learning playground.

Earlier, this past week, I began reading up on papers and documentation of trees. All in an effort to differentiate the various implementations of trees, including their benefits and drawbacks. Finding AVL trees, B trees, 2-3 node, 2-3-4 node and RB trees. I decided to kick off the events with a Red-Black tree. Some of the papers I found are the generally available by Google searching.

After a lot of learning, and a little massage, I have the first of a an “academic” implementation of an RB tree (http://hashbangbash.com/~vbatts/rbtree.rb). I gravitated towards this tree first because of the type searches I am needing. While the population of this slows as it grows, the searches are ridiculously fast. I’ll get around to generating some instrumentation to graph it. For now I have the run_loop() to return @results of the populating trees. The sets are [ , , , ]

The insertion graphed was an O(N) climb. For doubling the number of nodes to be inserted (of random unique numbers), the time increase was just a tad more than double. The @results for run_loop(1,000,000) was
=> [[1000000, 43.4912700653076, 24, 16], [500000, 20.5859882831573, 20, 15], [250000, 9.5372850894928, 20, 14], [125000, 4.50037479400635, 21, 13], [62500, 2.01573848724365, 16, 12], [31250, 0.941669225692749, 14, 11], [15625, 0.435366868972778, 14, 11], [7812, 0.252951860427856, 13, 10], [3906, 0.0940215587615967, 11, 9], [1953, 0.043536901473999, 13, 8], [976, 0.0200107097625732, 9, 8], [488, 0.00921034812927246, 9, 6], [244, 0.00417494773864746, 10, 5], [122, 0.00190210342407227, 6, 5], [61, 0.000821590423583984, 5, 4], [30, 0.000351667404174805, 4, 3], [15, 0.000170707702636719, 4, 2], [7, 6.03199005126953e-05, 2, 1], [3, 2.57492065429688e-05, 1, 1]]

which resulted in a time climb of




Another interesting observation was the logarithmic oscillations of the depth of the left most leg.


At any rate, enjoy and feel free to send your thoughts.

Take care,

vb

Share

a point-and-clicky (ruby) addition, dobbage!

Some time ago, the brainstorm of a simple GUI package viewer for my Slackware desktop would be handy. While completely unnecessary, I thought it would be neat.
So what did I do? Created a project on github.com for an application that did not exist yet, and commenced to reading the source of others with similarly simple application frameworks.

While having the project created out on github was a reminder, it was not much for encouragement, so the idea lay dormant for a while. With a free moment this past weekend, I solidified several ideas and actually sought to make headway on this task. But I will say, that having the project on github for so long, has increased the rank on Google’s search results for “dobbage” so that is a plus :)

While I am crafty with many tools/languages, my weapon of choice remains ruby. For my development time, I can get an idea prototyped very quick. At which point I can decided whether it is worth it to use another language (for performance, etc.). All that to say, dobbage is written in Ruby.

Initially, I had thought that ruby-gtk2 would be the windowing toolkit to use, but then Qt and QtRuby are included in the stock Slackware installation.
I must say, there is not an abundance of applications to find, that are written in QtRuby, the bindings to access the Qt libraries is very nice and extensive. This is my first “GUI” application, so it’s all new to me. The Qt API documentation is written for C++, but once you get the hang of translating their C++ explanation to a Ruby implementation, then it’s all gravy! :)

Dobbage only has one dependency, that is not included in a stock Slackware install, and that is my slack-utils ruby library, which can be built as an installable Slackware package, or available as a rubygem. slack-utils does provide several command line tools, but more importantly, it includes a library for a Slackware Linux harness.

Right now, dobbage only shows information for packages currently installed, and for “removed” packages. Removed packages include previous iterations of upgraded packages. There is a little fancy-ness in the status bar too. Other ideas include the ability:

  • sorting the Removed packages by date removed, instead of alphabetical
  • to open an installable Slackware package (a *.t?z archive), and get a tab with information about that package.
  • to have a tab for fetching information from a Slackware repository /mirror
  • good ideas from others :)

In any event, the code is available at github.com/vbatts/dobbage and here are a few screen shots.



Take care,
vb

Share

latest ruby packages for slackware current

Keeping on the track of various projects that have new releases out right now, Ruby has just released a couple of patch releases like 1.9.1-p429. Which has a list of bugfixes, and only a vulnerability that affects Windows users. Another release just a few days ago, is the 1.9.2 RC2 release. Which should be interesting for a couple of reasons. They are stating that it should be mostly compatible with previous versions.  This is the current problem with getting many ruby projects updated from 1.8.x to 1.9.1.  Now there may be potentially more updates and modifications needed.

Also, unlike the 1.8.x branch that stayed in /usr/lib/ruby/1.8/, once they got underway with 1.9.1 the path standard became /usr/lib/ruby/1.9.1/, so it’ll be changing with every sub-major release (so you would think). This is fine and good, and will join the ranks of the layout that other interpreters have taken. I just hope that the community cleanly grabs on to this, otherwise it’ll make for ugly clean-up. Another thing, is that despite these path changes due to version, there is no option (like there is when compiling perl) to -Dinc_version_list=''. So you can quickly and easy lose libraries that you had built for a previous version. We will have to continue pulling through this 1.9.2RC2 release, because initially there is not a lot of consistency in paths. There are some libraries built out as 1.9.1, and other paths as 1.9.2. Even the default headers have a mix of whether to be in a 1.9.1 or  1.9.2. Hmmm. I have taken steps to avoid these conflicts, but /usr/lib64/libruby.so.1.9.1 will still conflict.

The packages have landed on cardinal and are to be used at your own risk. I built the 1.9.2 version with a suffix of 192, in efforts to test having multiple versions coexist, but due to the spattering of 1.9.1 conflicts, you should `removepkg ruby` before installing the 1.9.2 package.

In other neat things about ruby-1.9.2, the Time class has been reimplemented so that the year 2038 is no longer a problem.

Available on http://cardinal.lizella.net/~vbatts/ you’ll find a ruby18 package. This package does coexist nicely with either ruby or ruby192. I had bundled this up while working with some rails projects (like radiant CMS!) that are not yet ready for ruby-1.9.x

Take care,

vb

Share

Various VIM builds for slackware -current

In the past couple of days I have been staying unusually aware of updates and patches from the VIM project. I have uploaded several packages that have the latest patches of the 7.2 branch. Then for kicks and giggles I pulled down the 7.3a unstable build, but it is nothing released or ready.

One thing in particular, the 7.2.446 build does have --enable-rubyinterp compiled in, for supporting the Ruby interpreter. Someone had sent a link for the lusty-explorer script for VIM. While the prospects of the script look great, I was unable to give it whirl, since the stock VIM in slackware currently does not have the ruby interpreter compiled in.

Enjoy, and feel free to drop me your feedback.

Take care,

vb

Share