art's abode

If you are stuck trying to get rubygems installed in your OpenSolaris environment, the following may help. I ran into these issues while installing bcrypt-ruby and sqlite3-ruby gems.

• First off, get the SUNWruby18 package, not the netbeans or jruby one. You can setup netbeans to use the  SUNWruby18 binary rather than jruby.
• Install GCC, for example package name gcc-432.
• Using “pfexec ln -s” for example, make symbolic links to GCC from /usr/bin/gcc-4.3.2 to /usr/bin/gcc and /usr/sfw/bin/gcc. Take note of which gcc version you have and construct your ln -s command appropriately.
• Update your rubygems installation: “pfexec gem update –system”.
• If you are compiling gems, you will need rake: “pfexec gem install rake”.
• If you need sqlite3-ruby gem, you will need to download and compile a newer version of sqlite3 from the website as the OpenSolaris package is currently too old to build the gem.

That should be enough to get you going. Try installing gems now either from shell or netbeans with superuser privileges. If you run into errors, take close note of the error messages while compiling the gem, and the output logs. You can generally work out what is required from the fairly verbose errors.

You may see this type of error:

art@sol:~$ irb
irb(main):001:0> require “bcrypt”
LoadError: no such file to load — bcrypt
from (irb):1:in `require’
from (irb):1

One way to resolve this is to run ruby or irb with the -rubygems option:

art@sol:~$ irb -rubygems
irb(main):001:0> require “bcrypt”
=> true
irb(main):002:0>

Hope this helps!

Here’s a document I ran across today which details some of the specific differences in the two languages. Just one of the many glorious tidbits:

Boo uses CLR threads, which generally map one-to-one to kernel threads and therefore exploit multiple processors and are fully preemptive.

In contrast, Ruby uses lightweight threads – threads implemented within the interpreter. Because of their extremely low switching latency, they can be used in situations where kernel threads impose too much overhead…[b]ut Ruby’s threads are limited to one CPU, and block on OS calls.

Microthreads can be implemented in user libraries, but only cooperative threads (as far as I know). I don’t know how important preemptive (within the hosted language) microthreads are. But the CLI (and therefore, Boo) seem to have no standard library implementation of lightweight threads.

All this is specific to the main Ruby implementation. JRuby, like Boo, relies on the underlying VM’s threading model – the JVM’s, in this case – and so its threads are generally fully preemptive and exploit multiple CPUs.

At the end of the day, I suppose comparing boo with ruby is a bit like comparing dicks to pussies, as ruby is an interpreted language through-and-through, whilst boo can be run, for instance using booi in interpreter mode, or using booc compile CLI bytecode binaries (which are absolutely tiny compared with, for instance, ruby2exe’ing a ruby project) to be run with mono/.NET or other CLR.

Also gotta love the mention of the JRuby: now we’re talking optimized best-of-breed solution. Lulz.

It’s pretty easy to handle signals in Ruby, which is sometimes necessary when you want your code to interact with the system running it.

Signalz Ahoy!

If you want to know which kill signals you have:

bash-3.2$ kill -l
1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
5) SIGTRAP      6) SIGABRT      7) SIGEMT       8) SIGFPE
9) SIGKILL     10) SIGBUS      11) SIGSEGV     12) SIGSYS
13) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGURG
17) SIGSTOP     18) SIGTSTP     19) SIGCONT     20) SIGCHLD
21) SIGTTIN     22) SIGTTOU     23) SIGIO       24) SIGXCPU
25) SIGXFSZ     26) SIGVTALRM   27) SIGPROF     28) SIGWINCH
29) SIGINFO     30) SIGUSR1     31) SIGUSR2

If you want to know which kill signals Ruby recognises:

irb(main):002:0> Signal.list.keys.join ", "
=> "USR1, BUS, USR2, TERM, SEGV, KILL, EMT, EXIT, STOP, SYS, TRAP, INFO, IOT, HUP, INT, WINCH, XCPU, TTIN, CLD, TSTP, FPE, IO, TTOU, PROF, CHLD, CONT, PIPE, ABRT, VTALRM, QUIT, ILL, XFSZ, URG, ALRM"
irb(main):003:0>

Some quick-n-dirty source code:

There’s probably better ways of doing this, but here’s a stupid little example demonstrating how it could work:

bash-3.2$ cat signal.rb

$hups = 0

def quit_on_int
  puts "Quitting on interrupt signal."
  exit
end

def quit_on_quit
  puts "U sure killed me guud!"
  exit
end

def handle_hup
  $hups=$hups+1
  puts "HUP! (count: #{$hups})"
end

while true
  trap("INT") {quit_on_int}
  trap("HUP") {handle_hup}
  trap("QUIT") {quit_on_quit}
end

Example in use:

bash-3.2$ ruby signal.rb
HUP! (count: 1)
HUP! (count: 2)
HUP! (count: 3)
^CQuitting on interrupt signal.
bash-3.2$

We run the program as above, then send it three SIGHUPs (i.e., using "kill -HUP pid"). We break out the program using ^C (ctrl-c), sending an Interrupt. Note this may not work in windows.

bash-3.2$ ruby signal.rb
U sure killed me guud!
bash-3.2$

Here we run the program again, and send it a SIGQUIT ("kill -QUIT pid").

• RubyCLR, a ruby bridge to .NET:

A high-performance Ruby to .NET bridge that allows seamless integration of CLR and Ruby objects in the same Win32 process. Use it to create rich client applications using the Windows Forms or Windows Presentation Foundation libraries.

• John Lam (the RubyCLR developer) discusses DLR, ruby and Silverlight.

• An insightful video on mashing up Silverlight (using the Dynamic Language Runtime) and ruby, together with Python, VB and JavaScript:

Presented by Jim Hugunin, John Lam
Duration: 72 minutes, 26 seconds