Tagruby

ruby 1.9.3 is released, and slackware packages are here

Ruby 1.9.3 is *finally* released. Their NEWS and ChangeLog are available.

And I have packages built for slackware-current and slackware64-current here:

ruby-1.9.3_p0-i486-1_vb.txz [MD5] [ASC]

ruby-1.9.3_p0-x86_64-1_vb.txz [MD5] [ASC]

Again, these are built on the -current development branch, so use at your own risk. :)

Take care,
vb

Tastes in Languages: an internal dialogue

This has been a point of contention for me, ever since I have had a desire to learn a “language” other than shell scripting. Which language would be most practical, valuable, powerful, reach the most receptive audience, designed with the ideals you share, what pays the bills, etc. Some, or all, of these aspects can conflict at any given point.

As for being practical or powerful, these measurements are based on your use of the language, which vary more than there are languages, so it is a continually refining target. As I continue to learn more languages, and deepen my knowledge of others, it is evident that no one language can be the end-all. Learning their benefits and drawbacks is a large part of efficient implementation.

As for valuable, this can be in a business sense, or marketability since. For me, this is the first real point of indecision. Fortunately AND unfortunately, this measurement has a callback to another measurement, “What are the ideals and motives of the language’s design?”. Business sense can be a fuzzy option sometimes. If you are a business unit that is exclusively a Java shop, it does not mean that all glue and helpers must also be java. Inversely, just because Perl is flexible and powerful, does not mean it needs to be built into a megalithic solution. The marketability of a language though, can relate more to the individual developer.

The evolution of all the available languages comes due to varying factors and motivation, and that motivation assists greatly in the type of community and reputation that a language accrues. These are the ideals that a language is evolved with. This is the perception that can be reflected back on a developer. Like how PHP was formed by a loose group of code hackers, perl was an overly flexible parsing and report language, ruby was started by a single humble person seeking to please others. Thus is the seed that grows the community. As soon as you state what language you write in, the other person immediately conjures stereotypes to cast over you. Regardless of good or bad, it is another expression of the eight mundane concerns. If it is blame or disapproval that you seek to avoid, then you find yourself not associating with a broader audience. And seeking praise and approval, you turn in towards like minded folks to reaffirm your expressed position. This may work out just fine for many, but it does put you at a great chance of clinging to an us-and-them mentality, which can be poisonous for you and the community at large. I’m not going to expand on that greatly, you can find more insight on that, starting by reading on ingroups and outgroups

And for many, they may not be an advocate of the language they know best, but it is what has been taught abd/or what they are paid to write in. That is okay, because you can learn other languages, despite the stereotypes others cast on you from what you’ve written in. There are soon likely to be a multitude of .Net folks, regardless whether loyalist or indifferent, that need to branch out to new languages. Thankfully for the open source communities at large, these folks have fodder to learn from, and become involved with to broaden their own experience.

While I have languages that I am more comfortable with, than others, ultimately I am an advocate for being a language generalist. Determining the best tool for the job requires having a broad idea of the pros/cons of many options. Forcing a project into the box you are most familiar with, is not always the most efficient or effective approach.

Good Times

This year has been a nice for socializing with nerds. Attending conferences is something that can get tiresome, if the content is something you do not find interesting or stimulating. Thankfully, I have no required conferences, so I can be choosy (schedules permitting). Naturally open source and languages would top the list of places to attend.

First off, was hanging out with the KDE folks in San Francisco, CA for CampKDE – April 4,5 2011. There were a number of good talks, and a great opportunity to shake the hands of names that I have seen around, as well as meeting many new folks. The kde-promo team has a YouTube channel, that they have published all the talks and interviews to. http://www.youtube.com/user/kdepromo
The talk I gave there is titled “Slackware: Quickly and Easily Manage Your KDE SC Hacking.” You can get the slides in [PDF] or [ODP], plus the videos posted on the kde-promo channel have the full talk (youtube.com/watch?v=Qs7vR3POHeo), as well as an interview afterwards by Wade Olson (youtube.com/watch?v=YIpUmPul1i4).

Next, was down to Spartanburg, SC for the SouthEast Linux Fest (SELF) – June 10-12, 2011.
This is the third year that I have attended SELF, and second time to speak, but what differentiated this year from any other speaking engagement (in the past, or distant future), was that it was a talk title “Slackware Demystified”, and none other than the founder of Slackware Linux, Patrick Volkerding was not only in attendance, but sitting on the front row! The slides from this presentation are available in [HTML] or [PDF]. Unfortunately, the videos have not been published yet. Hopefully they will actually get them published, unlike the previous two years…

Lastly … so far, was a local conference, that I did not speak at, only attended. JrubyConf – August 3-5, 2011. While I use MRI Ruby much more than JRuby, this conference was a great way to be around and hear from many brilliant folks (Like Wayne Seguin, Charles Nutter (headius), Nick Sieger, and Jim Weirich, to name a few), plus I felt that I needed to make up for missing out on RubyConf taking place in Baltimore, MD.

The KDE folks strongly encouraged making it to the DesktopSummit, which was hosted in Berling, Germany this year. While it was surely appetising to think of attending, it did not work out this time. It would have been nice to shake hands with some fellow contributors, like Eric Hameleers (alienBob). Better luck next year.

All good times, I look forward to next year, or event the rest of 2011.

Feel free to leave feedback on the talks.

Take care,
vb

More Red-Black Tree, but a little Ruby Benchmarking

After hearing a bit about the improvements in the Rubinius ruby interpreter, I decided to test a handful of the interpreters against the Red-Black tree insertion script I last posted about.

As a forward, this is completely out of idle curiosity, and with no deep intentions. The results had distinct winners and losers, and for more rich benchmark, this would need to include multiple iterations and some other aspects as well. All that to say, this is not an all encompassing benchmark.
The results are the length (in seconds) of time for the execution.

So using the rbtree.rb, that I last blogged about, using rvm, I have just run it through the following ruby interpreters:

  • ruby 1.9.1p430 (2010-08-16 revision 28998) [x86_64-linux]
  • rubinius 1.3.0dev (1.8.7 5bd938b5 xxxx-xx-xx JI) [x86_64-unknown-linux-gnu]
  • rubinius 1.2.0 (1.8.7 release 2010-12-21 JI) [x86_64-unknown-linux-gnu]
  • jruby 1.5.3 (ruby 1.8.7 patchlevel 249) (2010-09-28 7ca06d7) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_23) [amd64-java]
  • ruby 1.8.7 (2010-12-23 patchlevel 330) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2011.01
  • ruby 1.9.3dev (2011-02-14 trunk 30873) [x86_64-linux]

From an early look at it, the Rubinius interpreter is on to something good. For this example at least, their current release branch (1.2) is smoking, compared to anything else.
To look at the values, that make up the graph above, here is the spreadsheet

Take care,
vb

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

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

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