1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
|
---
date: "2003-09-27T13:08:57Z"
title: FAM-Ruby, Other
---
<p>
Released version 0.1.3 of <a href='/software/fam-ruby'><acronym
title='File Alteration Monitor'>FAM</acronym>-Ruby</a>. This release
consists entirely of a small one line patch from <a
href='http://cs.roanoke.edu/~jbernard/'>Jon Bernard</a>, so I took the
opportunity to import <a href='/software/fam-ruby'><acronym title='File
Alteration Monitor'>FAM</acronym>-Ruby</a> into <acronym title='Concurrent Versioning System'>CVS</acronym> under the module <code><a href='http://cvs.pablotron.org/?m=fam-ruby'>fam-ruby</a></code>.
</p>
<p>
<a href='http://www.raggle.org/'>Raggle</a> now has a half-assed (but working!) implementation of parallel feed grabbing. Basically each feed grab is forked off in it's own thread, which means you can grab an arbitrary number of feeds in parallel (limited by <acronym title='Central Processing Unit'>CPU</acronym> speed and bandwidth, of course). This implementation is in <acronym title='Concurrent Versioning System'>CVS</acronym>, but don't rush to try it just yet; it seems to have dug up some intermittent concurrency issue in either <a href='http://www.germane-software.com/software/rexml/'>REXML</a>, <a href='http://www.ruby-lang.org/'>Ruby</a>, or <a href='http://www.raggle.org/'>Raggle</a>. I've marked all the "destructive" regions of feed grabbing threads as critical regions, but I haven't narrowed down the problem just yet. My <em>hunch</em> is that it's either a subtle error in the Ruby <acronym title='Garbage Collector'>GC</acronym>, or a concurrency issue in <a href='http://www.germane-software.com/software/rexml/'>REXML</a>. The latter seems strange to me, since REXML is written in pure Ruby and, as far as I know, doesn't use threads internally. I guess we'll see.
</p>
<p>
<a href='http://www.richlowe.net/'>Richard (richlowe)</a> and I were
talking about passing events between machines, and he suggested that I
use <a href='http://www.rubycentral.com/articles/drb.html'>DRb</a>.
I've played around with <a
href='http://www.rubycentral.com/articles/drb.html'>DRb</a> a bit before, but for some reason using <acronym title='Remote Method Invocation'>RMI</acronym> for mundane things — in this case, a <code>/whatsPlaying</code> alias in <a href='http://www.irssi.org/'>Irssi</a> which queries the <a href='http://www.xmms.org/'><acronym title='X MultiMedia System'>XMMS</acronym></a> process on my workstation — never occurred to me. What I really love about this solution is how absurdly simple it is. Here's the code for the "server":
</p>
<pre>
require 'drb'
require 'xmms'
DRb::start_service('druby://picard:2345', Xmms::Remote::new)
DRb::thread.join
</pre>
<p>
The "client" is ridiculously simple as well. Here it is:
</p>
<pre>
require 'drb'
DRb::start_service
if r = DRbObject.new(nil, 'druby://picard:2345')
puts "Playing \"#{r.title}\"."
end
</pre>
<p>
Finally, the one-liner in <a href='http://www.irssi.org/'>Irssi</a> to
tie the whole thing together:
</p>
<pre>
/alias whatsPlaying exec - -o bin/whatsPlaying.rb
</pre>
<p>
In case anyone is wondering, this is one of the things I really like
about <a href='http://www.ruby-lang.org/'>Ruby</a>; solutions tend to be
simple, short, and legible. Okay, <code></advocacy></code>. I'm
out for now.
</p>
|
