Archive for the ‘ruby’ Category
OpenSolaris, Netbeans and rubygems.
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!
boo versus ruby
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.
Trapping signals in Ruby
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 = 0def quit_on_int
puts "Quitting on interrupt signal."
exit
enddef quit_on_quit
puts "U sure killed me guud!"
exit
enddef handle_hup
$hups=$hups+1
puts "HUP! (count: #{$hups})"
endwhile 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").
Ruby and Silverlight
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