DISCLAIMER: This is a continuing series detailing the painful story of a DIY render farm build. It is terribly technics and
somewhat frustrating. Those who are unprepared for such “entertainment” are advised to ignore these posts.
Apparently, the Dr. Queue Ruby-on-Rails front end, which is NOT the same as “Dr. Keewee,”which is a Python front-end, also has massive dependencies. And I had to figure out how to install those. And because Ruby is it’s own weird world, this was not going to be easy. I really only needed one thing done, here, I did not need to start at the beginning learning an entirely new language.
So let us recap.
- X-11 front-end, drqman, failed to build because dependencies (GTK2, reliant on db48) would not build
- Dr. Keewee, a Python front-end, required dependencies as well, only Python dependencies
- Dr. Queue on Rails front-end required dependencies as well, only this time Ruby dependencies
If you have not heard of Ruby (I had only barely), suffice to say that it is another programming language and requires hours of time to master. And Ruby-on-Rails is an open-source framework for web pages that is built with Ruby. So I would have to install Ruby in order to build Ruby-on-Rails. And I would use Ruby-on-Rails in order to build Dr. Queue for Rails, a web front-end for Dr. Queue.
This is because though I technically had Dr. Queue running, I could not see anything. It was a command-line program only. I could certainly have used a wide battery of comand-line tools to query the master and check to see if my job script was running. But I had no idea how to write a job script. I was hoping the GUI would do that for me. I’m an artist type – I don’t write code.
I also had no way of knowing if any other computers were connected to the PDC. I’m sure the command-line tools would tell me, but this seemed daunting. And so Dr. Queue was pretty much useless to me without some way to submit and manage jobs! And since drqman was really perplexing me, I needed to investigate this Ruby thing. Because maybe it would be easy and would compile immediately and I’d have luck of the kind not seen on this project before.
HAW HAW HAW!
Fortunately Dr. Queue on Rails does include a setup.rb file that would help describe what needed to be done. First I installed Ruby.
sudo ruby setup.rb
I was getting the hang of some of this. The “set up.rb” file, when run, revealed Ruby packages that were not installed, like “rmagick” which is the Ruby version of the usual imagemagick. It also checked some prerequisites. Ruby itself was at version 1.8.6, which was OK. Rails was at version 1.2.6 but Dr. Queue on Rails needed 2.3.5. The Ruby bindings were okay. I have no idea what a “binding” is, but it said they were fine, so I was willing to go with it.
Ruby is a somewhat new language, though, and I was concerned about how well it would perform on a PPC machine. It was invented in the 90s, but it seemed to me that no one really talked about Ruby until the mid-2000s, when it started to be the choice for some web designers. A bit of reading showed that the “Rails” portion really did come into being around 2005, and gained huge popularity by around 2007. This is roughly the time frame in which Apple switched from PPC chips to Intel chips. I could probably expect a lumpy Ruby distribution for PPC.
sudo port install imagemagick
This, of course, was important to have in order that the Ruby version could reference it.
sudo port install scons
OK, already! I’m not sure why I did that again. Maybe some kind of voodoo. But I ran out of time again, and locked the door. The next day would have to tell how easy Ruby and Ruby Gems were.