lennyにGPIBをいれてみた
lennyのリリースがもうそろそろということで、lennyをインストールした。Xを入れるつもりはなかったので、標準システムしか入れなかったので、特にetchとの違いは感じなかった。etchではなぜかgpibのパッケージが無かったが、lennyは今のところgpibに対応してみるようなので、GPIBもインストールしてみた。

aptitude install gpib-modules-source
module-assistant auto-install gpib
aptitude install libgpib0-dev

としたら、すべてのパッケージがそろった。あとは、/etc/gpib.confでnameを適宜変更して、/etc/groupでユーザーのグループを設定する。今回のボードでは

name="ni_pci_accel"

とした。gpib-rubyのインストールはetchとかとほとんど同じだった。 設定をいろいろといじっていたら、起動したときにうまく組み込まれなかったり、gpib_configが実行されなかったりしたが、結局ボードの設定のみをいじれば良いらしい。 以前に比べると、インストールのときに打つコマンドが非常に少なくなったように感じる。gpib-modules-sourceをいれたらkernelのソースも自動的に入ったし、modprobeの設定も自動にされるようだ。しかし、くせをつかむまでにはやはり多少苦労した。

telnetとssh
最近はsshのみでtelnetはほとんど使わないのだが、windowsとlinuxからなる外につながっていないネットワークで使用しようと思って、linuxにtelnetをインストールした。windowsではsshも使えないので、cygwinを入れるのも面倒だし、telnetでいこうということになったのだ。 sshはコマンドラインで一発でインストールできるのだが、telnetは意外に面倒だった。まずは、aptでtelnetdを入れて、/etc/inetd.confに

telnet stream tcp nowait telnetd /usr/sbin/tcpd /usr/sbin/in.telnetd

という行を追加する。さらに/etc/hosts.allowのホストですべてを許可するように、

ALL: ALL

とする。そして、inetdを再起動するために、

/etc/init.d/openbsd-inetd restart

とする。ついでにftpdもインストールしたが、こちらは特に設定する必要はなかった。 windowsがsshに対応していれば、こんなこともしなくても良いのだが。少しは他のOSとの共存を考えてほしいものである。

127.0.0.1 or 127.0.1.1
socketのプログラムを書いていて、サーバーが動いているマシンと同じマシンからのアクセスなのか、異なるマシンからのアクセスなのかを判断しようとして、少し迷った。サーバー側でクライアントの情報を見ると、自分のマシンが127.0.1.1になっている。localhostは127.0.0.1なのに変だなと思って調べると、/etc/hostsには’localhost’だと127.0.0.1で、ホスト名だと127.0.1.1となるらしい。とりあえず、127.0.1.1の時は、同じマシンからのアクセスだということにした。

CGIのformのデータ
CGIをrubyを使って書くことがあるが、formのデータを取り込むときには、

data=cgi.params["data"].collect{|l| l.read}

というようにしている。しかし、一度readしてしまうと、もう読めなくなってしまう。これをなんとかしたかったのだが、これまでどうしたら良いかが分からなかった。調べてみたら、上のlのclassはStringIOというもので、文字列なんだけどIOとして扱えるものらしい。読み込んだデータをもとに、もう一度StringIOを作ってやれば良いのだろうということで、

cgi.params["data"]=data.collect{|l| StringIO.new(l)}

としてみたら、うまく行った。読み込むたびにこれをやるのも面倒だが。もっと良い方法があるのかも知れないが、これで動いているからまあ良いかな。

いくつかのwindow managerを試してみた。
現在、icewmを使っているが、調べてみると、このところあまり開発は盛んではないようだ。個人的には、軽いし最低限の機能はあるので、不満は無いのだが、開発が止まってしまうと徐々に廃れていく。 fluxboxをインストールして、試してみた。icewmのメニューのsystemのwindow managerのところには無かったので、.xsessionを書き換えて起動したが、後でみたら、プログラムの下のウィンドウマネージャにはあった。少し使った感じでは、まあまあ良い感じだが、メニューの一部が文字化けしていた。tabとslitが特徴らしいが、なぜか動かなかったので、icewmと比べて特に惹かれる点はあまり無いように感じた。 折角なので、Xfce4も使ってみた。こちらは統合環境の割には、起動が速くて関心した。あまりうるさい感じはしないし。キーボードショートカットの設定も比較的簡単なようだし。icewmの次の候補にしておこう。

lennyのreleaseも間近か
久しぶりにDebianのサイトを覗いてみたら、次期メジャーリリースが近付いているようだ。リリースに関与するバグの数が100ぐらいになっている。過去の例を見ると、あと二ヶ月ほどでリーリスされる可能性が高い。 思い返してみると、メインマシンのOSをWindowsからLinux替えたのが約三年半前で、Sargeがリリースした後だった。それから二年ほどたってEtchに代えて、次はLennyか。 そういえば、研究室にはまだSargeのマシンがあるので、そろそろ入れ替えないといけないかな。EtchはなぜかGPIBがパッケージの形ではサポートされていないようだったので、なんとなくそのままにしてある。Lennyではパッケージが提供されるかな。Etchには、SSLの重大なバグがあったし。 まあ、新しいOSにしてもほとんど自分流のカスタマイズをしてしまうので、ほとんど変わらないのだけども、リリースが待ち遠しいな。そろそろGNOMEとかKDEとかにも慣れないといけないのかな。

Queueを使ったアクセス数の制限 いろいろと試してたら、Socketのプログラムがだいたい動くようになってきた。今度のはこれ。 require 'socket' require 'thread' q=SizedQueue::new(3) s=TCPServer.new(12344) Thread.start(s.accept){|cl| begin q.push(0) cn=cl.peeraddr.join(":") print "%s is accepted as %d/%d connection.\n"%[cn,q.size,q.max] cl.each{|cmd| cmd=cmd.strip str=case cmd when "status" (rand(2)>0)?"good":"bad" when "color" ["red","green","blue"][rand(3)] else "unknown command" end cl.puts "BEGIN" cl.puts str cl.puts "END" } #rescue Errno::ECONNABORTED ensure cl.close q.pop print "%s is closed remaining %d/%d connections.\n"%[cn,q.size,q.max] end } while true エラーの処理とQueueを使ってアクセス数の管理を加えた。それから、BEGINとENDで囲むことによって、複数の行のやりとりをするようにした。この部分の処理をクライアント側でもする必要があって、 require "socket" END{ print "connection is closed.\n" } s=TCPSocket.open("localhost",12344) loop{ s.write(["status","color","unknown"][rand(3)]+"\n") begin p s.

裸のハードディスクを動かしてみた。
ハードディスクの中を見たいという人がいたので、中身を空けて動作中の様子を見せるために、蓋を開けたまま使用してみた。先日、家を片付けていたら出てきた外付けのHDDを使って、蓋をあけて、パソコンに接続して、さて動作をみようとしたら、Linuxでのフォーマットの仕方とかを忘れてしまっていて手間取ってしまった。 ディスクが回転すると、引き起こされる風によってほこりは吹きとぶので、それほどほこりは気にならないということは聞いたことはあったのですが、思ったよりも大丈夫なようだ。いまのところ全く問題なく読み書きできている。もっとも、長期的にはダメだろうが。 最近では1Tとかも出てきて、容量はどんどん大きくなってきている。もうそろそろ限界に近い気もするのだが。

socketで装置制御
研究室にsocketを用いて制御されている装置があるのだが、既成のソフトだといろいろと拡張することが困難である。socketの使い方がなんとなく分かって来たので、この装置の制御を試してみた。コマンドに関する情報が不完全なので、そのコマンドを調べながらだったので、それなりに苦労はしたが、とりあえず動くようにはなった。 少し問題だと感じるのは、socketからの入力で、バッファの中にあるものを読み取る方法が分からないということだ。readとかだとEOFまで読もうとしてブロックしてしまうし。getsでも、何行あるかが分からなければ、同じことだし。サーバーも自分で設計する場合には、データのやりとりの際に、データの量などをあらかじめ通信しておけば良いので問題はないでしょうが。

socketを使ったプログラムを書いてみた。
測定用の自動化には、いろいろな仕組みがある。全部、ひとつのプログラムがやっているのが多い気がするが、制御の部分にサーバーを立ててGUI部分がクライアントとしてそれにアクセスしに行っているようなシステムも見受けられる。装置の制御部分は、一つのタスクからのみにした方がconflictが無くて良いと思うので、それをサーバーに任せるというのは理にかなっているように感じる。 そこで、そのようなシステムを組む練習がてら、遅ればせながらsocketというものを使ってみた。rubyでは、socketを簡単に使えるらしい。試しに書いてみたサーバー部がこれ。

require 'socket'
s=TCPServer.new(12344)
Thread.start(s.accept){|cl|
print "%s is accepted\n"%cl.peeraddr
  cl.each{|cmd|
    str=""
    case cmd.strip
    when "status"
      str=(rand(2)>0)?"good":"bad"
    when "color"
      str=["red","green","blue"][rand(3)]
    end
    cl.puts str
  }
  cl.close
print "%s is terminated\n"%cl.peeraddr
} while true

cygwin上で書いていたのだが、ポートは12345はトロイの木馬と勘違いされてだめだった。そして、クライアントはこれ。

s=TCPSocket.open("localhost",12344)
5.times{
  s.write(["status\n","color\n"][rand(2)])
  p s.gets
  sleep 2
}
s.close

とりあえずは動くのだが、いろいろと気に入らない点がある。まず、クライアントからの入力に対して、出力を二行以上にしようとしたら、なぜかうまくいかなかった。print文が働かないように見える。それから、クライアントの接続が切れたことを認識してくれない。これだと、接続がつながって切れる度に、スレッドが増えていくことになってしまう。windows上で動かしているからなのかもしれない。時間ができたらlinux上でいろいろと試してみよう。 他の人が書いたプログラムとかを参考にいろいろと勉強しないといけないようだ。HTMLとかPOPなんかも勉強すると参考になるかな。

2008/12/25追記 接続を切ったときには、Errno::ECONNABORTEDというエラーが起こっているようだ。スレッドはこのエラーで終了してしまうので、どんどんスレッドが増えることはないようだ。気持ちわるいので、rescueとかensureとかでこのエラーが起こったときの対処をすれば、それなりに動いた。

2008/12/25追記 いろいろいじっているうちに、二行以上も受け取れるようになった。おそらく主な原因は、

p s.gets until $_=~/^END/

としていたが、

begin
  p s.gets
end until $_=~/END/

と書き換えることによって、getsが条件判定よりも前に行うようになったからだと思う。untilが後にあるから、後に実行しているような気になっていた。でも、なんか変な気がする。