2014/11/28

practical-scheme.net OS移行

実はこれまでUbuntu 10.04LTSで持たせてきたんだけどサポート切れが近づいてきたし以下の事情にも迫られて、14.04LTSに切り替え。記録のためにメモ。

最初にサーバをLinodeに移行したのは(2010年の始め)で、当時まだVPSのメモリが高かったから節約のために32bit Ubuntu9で構築した。

その後色々使う用途が増えてきたのと価格が下がったので、メモリ4GBのノードに移行したんだが、ユーザランドに色々インストールしてたのを入れ直すのが面倒だったので、 10.04への切り替えは「カーネル64bit、ユーザランド32bit」という変則的な対応で済ませた。確かLinodeのボタン一発で変更出来たような気がする。

それが、最近になって32bitアドレス空間ではいろいろ不便が生じて来ていた。 Kahuaプロセスが2GB超くらい食うことがあるんだけど、Conservative GCだとアドレス空間がつまってくるとfalse pointerの発生確率が上がってメモリ効率がどんどん落ちてくるのだ。そこで休日を一日潰して完全64bit化することにした。10.04サポート切れ直前に慌てるのもいやだし。

OS部分は別パーティション切って分離してて、そこに対する変更はgitで管理してるからいいんだけど、ユーザランドの方で思いつきでいろいろ機能足したりサービスをホストしたりしてるので、 64bit依存部分だけ綺麗に分けられるようになってない。バイナリは再インストールが必要だし、データのうち機種依存のもの (gdbmファイルが筆頭) はコンバートが必要だ。

そこで以下の手順で移行。

Linodeで新たなノードを作り、OSパーティションに14.04LTSインストール。
必要なシステムソフトをapt-get install。
システム設定のカスタム部分をgitから復帰
- Apacheが2.2から2.4になってて、confファイルの作法がちょっと変わってた (参考)
Gaucheなど必要なコードをコンパイル、インストール
- いくつか細かい修正。Kahuaにsvnへの参照が残ってたりとか。
データ部分はひとつのディレクトリの下にまとまっているので、
1. 変換が必要なものについてはスクリプトを流してダンプを作っとく
  - dbmファイルについてはrefj:DBMデータベースのダンプとリストア参照
2. ディレクトリまるごとコピー
3. スクリプトを流してダンプからバイナリデータ復元
元のノードとIPをswap。
- swap自体はノードを立ち上げたまま出来るんだけど、その後うまくssh接続できなかったのでノードを再起動した。sshdだけの再起動でも良いかもしれない。 (もちろん手元のknown_hostsのエントリはssh-keygen -Rで消しとく。known_hosts のホスト名がいつの間にかハッシュ化されててちょっと戸惑った。)
サービスを一個づつ立ち上げて確認
- ディレクトリのオーナーやパーミッションで何ヶ所かひっかかった。一度直せば動くんでつい忘れちゃうんだが、スクリプトで復元できるようにしとかないとな。

LinodeはWeb管理画面もそこそこストレス無く動くしなかなか良いですな。あとIP swapが出来るのでDNSいじらないで良いのは有難い。

Tag: Hosting

Comments (0)

2014/10/13

#permalink

お題:pingコマンド

本の虫: Pingプログラムの話を読んで、ずっと前に『どう書く.org』というプログラミングのサイトに出そうと思ってたんだけど忙しさに紛れて出しそびれたお題を思い出した。興味があればどうぞ。

簡単なping(1)コマンドを実装してください。スタンドアロンプログラム、単なる関数どちらでもOKです。仕様は次のとおりとします。
与えられたアドレスに対し、ICMP Echo Requestパケットをひとつ送出。 ident, seq, 及びペイロードに載せるデータは任意とする。
ident, seq, データが一致するICMP Echo Replyが返って来たら、送出から受け取りにかかった時間と返事したホストのアドレス (送ったアドレスと異なるアドレスから返事が来ることがあるので) を表示する、もしくは戻り値にする。
5秒以内に応答が無ければその旨表示する、もしくは戻り値にする。
リトライはしなくて良いです。IPv6/ICMPv6への対応はお好みで。また、アドレスの与え方は言語の都合の良い方法で構いません。LLならホスト名やドット記法からでも楽でしょうが、Cならin_addr_tを受けとってもOKです。
低レベル(raw)ソケット、バイナリパケット、タイムアウトの処理が色んな言語でどう書けるのかが興味の中心です。(ライブラリでさくっと解決っていう回答もありだと思います。pingを別プロセスで起動っていうのはちょっとつまらないと思うけれど。)

Tag: Programming

Comments (0)

2014/10/13

#permalink

翻訳のセルフチェック

善意のひどい訳について

言ってることはよくわかる。これはちょっとなあ、と思う訳を目にすることは、個人、商業どちらでもしばしばある。

だからと言って個人の場合、「下手な訳は公開するな」とも言いたくはない。誰だって経験によって上手くなるし、他者の目に晒されてこそ改善されてゆくから。

で、まあ叩き台を晒して揉んでゆけばいいんじゃない、っていうのが大人の結論なんだろうけど、それじゃつまらないので、もうちょい突っ込んでみる。

「誤訳は程度問題」としてこの話題を相対化する議論があるんだけど、個人的な感覚からすると、程度問題で片付けられない質の差ってものがあるように思う。

オープンソースのコードにも質は色々あるけれど、コンパイルがそもそも通らないとか、実行したらいきなりSEGVするコードを出してきて「叩き台です」という人はいないと思うんだ。やりたいことの一部機能がまがりなりにも動いて、何をしたいか客観的にわかるコードがあってはじめて、改善案も出せるというもの。

でも、翻訳だと「コンパイルを通らない/実行できない」レベルがたまに出てくる。単に訳文が日本語としておかしいという構文エラーじゃなくて、もっと大きな構造として意味が通らない、というものなんだけど。そういう段階だと、なかなかコメントしづらいので、フィードバックによる改善サイクルがうまく回らない。

コードなら実際に実行してみることで、出す前に自分でチェックできるけれど、翻訳だとそういうツールが無いから自分でわからない、というのが問題なんだと思う。 (実行環境が無い状態で曲がりなりにも動作するプログラムを書くことの難しさを考えれば、翻訳でそのハードルをクリアするのは簡単とは言えないだろう。)

けれど、ちょっと気をつけるだけで公開して有益なフィードバックをもらえる確率が格段にあがる、というポイントはいくつかあると思う。

★ ★ ★

構造

技術的文章については、原文が全体として主張したいことは何か、そのために各パラグラフでどういう主張をして、それがどのように論理的に組み立てられているか、という点はかなり明確なことが多い。

訳語の選択や日本語としての言い回しには訳者の個人差が出るとしても、背後にある論の骨組みについては、これは明確に「正解」が存在するものだ。 SEGVレベルの訳文の代表的なものは、この骨組みをとらえ損ねているものだと思う。

翻訳のスタイルは色々で、私は原文を読んで一旦骨組みを頭の中に収めてから訳し始めるけれど、とりあえず下訳を作ってから組み立てを考えるという人がいてもいいだろう。でも最終的に、自分が原文の構造を理解したかどうか、ということは、自分でかなりの程度までチェックできるはず。

文の一部や単語の意味がわからなくても、全体の論旨と文の構造を見れば、これとこれは並置されているとか、この要素はこの要素につながっている、とか、この代名詞はこれを受けている、といったグラフが描けるはず。そういう抽象化はむしろプログラマの得意分野だろう。

この構造がわかってない場合、出てきた訳文がどんなにもっともらしくても、外している可能性は高い。よくあるのは、ちょっとした誤読である一文の意味を逆に取ってしまい、でもその辻褄を合わせるために訳文をいじって無理やりつなげようとして傷口が広がるというもの。

自信が無かったら、その部分は全体の中でどういう役割になってるか考えてみるといいだろう。その上で分からなければ、部分的に原文を残して、「構造的にここは「XはYの一種だ」と言う主張が来るのが自然だと思うんだけど、この英語表現をそう解釈できるのか自信がない」みたいな注釈をつけておいてもいいと思う。

翻訳の改善では訳語の選択や表現について議論になることが多いけれど、どういう表現にすべきかというのは元の論理構造に照らして判断されることなので、構造が見えない段階で議論しても全く実りがない。

主語

日本語は文脈から明らかな時は主語を省略するのが普通だけれど、この性質はともすると「主語がわからないから書かないで誤魔化す」というふうにも使えてしまう。でもそうやって誤魔化した文は、文法的に合ってても意味的にわからない文になる。

訳出するかどうかは別として、訳している本人は、その文の動作の主体が自分でわかっているかどうか自覚できるはず。従属節や動詞句についても常に意味的な主語は何なのかチェックしよう。

照応

代名詞は何を指しているか。これも、最終的な訳文では明示しなくて良いことが多いんだけれど、「わからないので書かない」という誤魔化しも出来ちゃう。訳出するしないにかかわらず、自分でわかってるかどうかチェックしよう。

原文における数(単数/複数)や冠詞、時制は、訳文に直接現れないことが多いけれど、照応を判断するのにとても役に立つことが多い。というか英文に慣れてくると無意識のうちにそのへんを手がかりにして判断できるようになる。

とはいえ、実は原文の著者も感覚で書いてて照応があやふやになってる場合があったりする。なのでテストに解答するみたいに何が何でも全部答えをみつけなきゃならんってことはないんだけど、自信が無ければ(ここは原文の著者も混乱してるな、と判断できなければ) 「ここのitが何を指してるか不明、構造的にはこれだと思うんだけど英文としてそう解釈できるのか自信なし」とか注を入れとけばいい。肝心なのは「ここがわからない、という点がピンポイントでわかっていること」だ。

質問

技術文書は、著者がまだ生きていてemail等でコンタクトが取れることが多い。だから、わからなかったら何となく訳すんじゃなく、作者に尋ねることを考えよう。 (作者がCCライセンス等を明記してない場合、どうせ公開前に許可を求めることになるわけだしね。)

著者も広く読んでもらいたくて公開しているわけだから、大抵は快く教えてくれるはず。

実際に作者への質問を考え始めてみれば、「なんとなく意味がわからない」というのでは質問できないことがわかる。「自分は原文がこういう流れだと解釈して、だからここはこういうことを言いたいんだと思うのだけれど、このフレーズをそういう意味に取って良いのかわからない」というふうに、わからない箇所を具体的に絞り込まないとならない。

そういう質問を考えてるだけで答えがわかる場合もあるし、作者に質問するのに気後れする、あるいは作者とコンタクトが取れない場合でも、その質問を訳注として入れておけば、有益なフィードバックが得られるだろう。

★ ★ ★

他にもあると思うけれど、とりあえず思いつくのをあげてみた。

このいずれも、実際に一文一文日本語を考えてタイプする手間に比べれば、そんなに負担の多いものではないと思う。私の感覚では、頭の中に収めた原文の論理グラフを日本語で表現するという作業が翻訳作業の9割を占めるんだけど、これらチェック項目はそれ以前に済ませられる話だ (その意味で、「とりあえずコンパイルを通してみる」という感覚に近い。シンタックスではなくセマンティクスのチェックではあるけれど。)

自分も感覚的に訳してて厳密に考えてないことは多いけれど、このへんについてはバックグラウンドでセルフチェッカーが走っている感覚はある。

Tags: 翻訳, 英語

Comments (0)

2014/10/09

#permalink

算盤のAA

こんなのを見かけたので別解を

(Gauche) 2chお題「そろばんAA」

お題: 
整数n(0<=n<1000000)をソロバンのAAに変換するプログラムを書け 

n=9563なら 
######## 
#oo|||o# 
#||ooo|# 
######## 
#||o|oo# 
#oooo|o# 
#oooooo# 
#ooooo|# 
#oo|ooo# 
########

最初、見かたがわからなかったのだけど、縦一列が一桁なのね。

https://gist.github.com/c9b26f0ffaab9f123bab

最後の式はリストの転置の定番 (apply map list xs) の応用。

お題の通りでなくて良ければ、むしろ最後の式をこうした方が:

(for-each print (apply map list (num->columns num width)))

結果が見やすいかもしれないと思った:

gosh> (soroban 1234567890)
(# # # # # # # # # #)
(o o o o | | | | | o)
(| | | | o o o o o |)
(# # # # # # # # # #)
(o o o o | o o o o |)
(| o o o o | o o o o)
(o | o o o o | o o o)
(o o | o o o o | o o)
(o o o | o o o o | o)
(# # # # # # # # # #)

Tags: Programming, Gauche

Comments (0)