Oct 29, 2007

「灯台下暗し」の読み方

「灯台下暗し」という慣用句の世間一般の発音が、昔から気になっている。なぜ皆「もと」にアクセントを置くのだろうか?まるで「東大モトクロス」のようだ。関東のイントネーションによるそれは「大正デモクラシー」をも連想させる。

中1の頃、一般的な発音を知らずに、「灯台下」(関西弁で、尻上がり)「暗し」(同じく「ら」にアクセント)と級友に言ったら、なんやその変な言い方、と笑われてしまい、「灯台」(尻上がり)「下暗し」(「もと」にアクセント)やろ、と訂正された。その訂正された読み方を聞いた時に違和感を覚えてから20年以上、TVでもその違和感のある読み方しか耳にせず、ずっと疑問に思っている。

「ほの暗い」のように「下暗し(もとくらし)」という形容詞がある訳では無く、「下」は灯台(燭台)の真下のことを指し「灯台」にかかるのだから、「下」と「暗し」の間は切れるはずだ。従って「灯台」「下暗し」と切れて聞こえる読み方をするのは間違ってると思うのだが、どうなのだろうか。

See more ...

Posted at 21:42 in 雑記 | WriteBacks (2)
WriteBacks

「ほの暗い」のように「下暗し(もとくらし)」という形容詞がある訳では無く… (^o^)(^o^)(^o^) 私もずっと違和感感じてたんですよ~っ! 友人曰く、「灯台下暗し」があの発音なのは大正デモクラシーの影響に間違いないそうです。 何を根拠に!?と思いつつ、確かに大正デモクラシーの発音は揺るぎがないし、 日本人は義務教育でほぼ確実に習っているのであながち嘘とは言い切れないかも?

Posted by yukineco at 06/25/2010 09:48:38 PM

ほほうそんな民主主義的な発音の混用または抑揚のユニフィケーションが原因または理由でございましたか。 関西では灯台モトクラシーと大正デモクラシーでは自然に発音するとイントネーションのパターンにそれなりの隔たりがあるためまさかそんな統合一体化リファクタリングはあったはずがないと思って居りましたが、やはり我々関西人も関東人による無機質な日本語の簡素化、日本文化の否定、外国文化への移行の弊害を被っているとは知りませんでした。 「モトクラシー」が国語辞典に載る日は遠くないでしょうか。

Posted by ynomura at 06/26/2010 01:24:58 AM

jvim+cannaでローマ字かな入力できない時

このサーバーには、FreeBSDのportsを使って、jvim-canna+freewnnをインストールしていた。
先日、ふとこのサーバー上で日本語の文章を書きたくなって、jvimで書き始めた。ヘルプを見ていると、日本語入力中にかな漢変換エンジンを切り替えることができるとあったので、FreeWnnからCannaに切り替えると、ローマ字入力がひらがなやカタカナに変換されないことに気づいた。aiueoと打つと、日本語入力モードにも関わらず、画面にaiueoと表示され、スペースキーを押しても漢字変換がされなかった。

jvimは日本語入力fepとしてONEWというものを使っているらしい。ONEWのREADMEを読むと、どうやらONEWに対してCannaのローマ字かな変換表(ONEW_CANNA_RKTAB)、またはその探索パス(ONEW_CANNA_RKPATH)を指定する必要があるらしかった。

さらに調べていると、Cannaのデフォルトのローマ字かな変換表はdefault.cbpという名前らしく、このサーバーには/usr/local/share/canna/dic/default.cbpが存在したので、cshで

setenv ONEW_CANNA_RKPATH /usr/local/share/canna/dic/

としてみると、jvim上のCanna選択状態でローマ字入力による日本語入力ができるようになった。

See more ...

Posted at 19:25 in UNIX | WriteBacks (0)
WriteBacks

Oct 28, 2007

Module::Starter::PBP v0.0.3のエラー

ITProのページ「Webプログラミング実力アップ Part1 正しいPerl/CGIの書き方」を参考に、Module::Starter::PBPをインストールして、

perl -MModule::Starter::PBP=setup

を実行して、module-starterを実行すると、
Unknown placeholder <MAIN PM FILE> in Makefile.PL

というエラーが出た。

何かCPANのモジュールが足りないのか、1つ目のコマンドで生成された、~/.module-starter/configの内容が悪いのか、などと思って色々試したが、全く改善しなかった。
仕方なく、インストールされたModule::Starter::PBPの本体であるPBP.pmを解析した所、同じディレクトリのSimple.pmと整合していないことが判った。どうやら、CPANにてModule::Starter::Simpleがバージョンアップされて(今回インストールされたのはv0.0.3のPBP.pmとv1.44のSimple.pm)不整合が発生したようだ。

結局、PBP.pmのsub Makefile_PL_gutsとsub Build_PL_gutsの最初の方を以下のように修正した。
(#の後が元々の記述、#の後が無い行は新しく追加した行)

sub Makefile_PL_guts {
my $self = shift;
my $main_module = shift; #
my $main_pm_file = $self->_module_to_pm_file($main_module); #
my %context = (
'MAIN MODULE' => $main_module, #shift,
'MAIN PM FILE' => $main_pm_file, #shift,

sub Build_PL_guts {
my $self = shift;
my $main_module = shift; #
my $main_pm_file = $self->_module_to_pm_file($main_module); #
my %context = (
'MAIN MODULE' => $main_module, #shift,
'MAIN PM FILE' => $main_pm_file, #shift,

これにより、module-starterがエラー無く動くようになった。

それから、上記ITProのページに書かれている通りに、module-starterを実行した直後の状態の.pmに対して"perl Build test"までを実行すると、

Global symbol "$VERSION" requires explicit package name ...

というエラーが出る。どうせ雛形の中の書き換える部分のエラーなので放っておいても良いのだが、これを回避するには、同じくPBP.pmの中に書かれているModule.pmのテンプレートの
use version; $VERSION = qv('0.0.3');

use version; our $VERSION = qv('0.0.3');
に書き換えておけばよい。(書き換えた後は~/.module-starterを作り直す必要があるので注意)

See more ...

Posted at 22:37 in PC一般 | WriteBacks (1)
WriteBacks

[Perl]Module::Starter::PBPで最初のテストが通らなかった場合の対処メモ

TAKESAKOさんの「Part1 正しいPerl/CGIの書き方:ITpro」を参考にモジュールを書いてみようとしたら、perl Build test...[link]

Posted by at 11/26/2007 02:52:18 PM

Oct 20, 2007

mod_proxyでmod_perlを分離

先週のエントリーで、mod_perlはポート待ち受けする全てのhttpdの内部にperlを常駐させるのでメモリを使いまくって困る、と書いたが、当然その課題については色々考えられてきたようで、mod_perlの様々な文書に対策が書かれていることがわかった。

最初に見つけたのは、単純にもman mod_perlの中だった。"MEMORY CONSUMPTION"という章があり、メモリ消費量が増える理由や、Perlスクリプトを書く時のノウハウが書かれている。さらにman mod_perl_tuningにずばり"REDUCING MEMORY USE"という章があり、次のような方法が紹介されている。
(1) httpdのプロセス数を減らす
(2) httpdが子プロセスをforkする前にPerlモジュールをできるだけ事前にロードして子プロセス間のRAMの共有化を図る(OSによってはあるメモリ領域に書き込みが発生するまではそのメモリ領域のコピーを子プロセスに作らないため)
(3) 通常のコンテンツ用のhttpd(多数の接続を許す)とmod_perlするhttpd(少数の接続のみ)とを分ける

mod_perlのサイトのDocumentationの"Choosing the Right Strategy""Performance Tuning"の所にも色々な情報があるが、大まかには上記の3通りの方法にまとめられると思う。

このWeblogを動かしているサーバーに関しては、(1)はhttpd.confのMaxSpareServersもMaxClientsも最少限にしてあるので無理、(2)は前回の設定で半分程度はなされており、これ以上はMovableTypeに手を加えることを意味し大変なので、(3)のように2種類のhttpdを動かす選択が妥当だ。
そして、複数のhttpdをシームレスに動かすと言えば、Apacheのmod_proxyだ。httpdに届いたHTTPリクエストを他のHTTPサーバーに転送できる機能だ。Apacheを使っていてHTTPサーバーの連携にmod_proxyを使わない手は無い。

ところで、このサーバーにはApacheとTomcatとが動いていて、それぞれ待ち受けポート番号が異なり、2つのポートをインターネットに公開しないといけないことと、一方のコンテンツのURLにポート番号が含まれるのが気になっていた。先々週、Apacheのmod_proxyのことを知り、それを使えば解決することがわかったので、mod_perlを組み込むのと同時に、mod_proxyを使えるようにApache 1.3を再コンパイルしていた。
そのmod_proxyを使って、mod_perlを外したApacheのhttpdとmod_perlを組み込んだApacheのhttpdを繋げれば良いのだ。実に幸便、渡りに船だ。

今回mod_proxyを使って作成した環境を大まかに説明する。
HTTPサーバーは上述のように3つの構成(同一PCで動く)とした。
(A) mod_proxyを組み込んだApacheのhttpd
(B) mod_perlを組み込んだApacheのhttpd
(C) Tomcat
インターネットからのHTTPリクエストは全て(A)が受け取り、リクエストのURLを見て、Perlを起動するべきコンテンツであればリクエストを(B)に転送し、Tomcatの管轄のコンテンツであればリクエストを(C)に転送する。

●mod_proxyの設定
特に細かいことをしなければ、mod_proxyの設定は至って簡単だ。
今回は、上記(A)のhttpd.confに以下を追加した。ここでは(B)はポート81、(C)はポート8080で待ち受けているとする。


ProxyPass /mt/ http://localhost:81/mt/
ProxyPassReverse /mt/ http://localhost:81/mt/
ProxyPass /cgi-bin/mt/ http://localhost:81/cgi-bin/mt/
ProxyPassReverse /cgi-bin/mt/ http://localhost:81/cgi-bin/mt/
ProxyPass /cgi-bin/mt/mt/app http://localhost:81/mt/app
ProxyPass /cgi-bin/mt/mt-search.cgi http://localhost:81/mt/search
ProxyPass /servlet/ http://localhost:8080/servlet/
ProxyPassReverse /servlet/ http://localhost:8080/servlet/
(10/29訂正:取り消し線部分2行削除、その下に2行追加)

言うまでも無く上4行が(B)への転送、下2行が(C)への転送の設定だ。

●httpd二重化の設定
2種類のhttpdを動作させるために、通常、最低
・httpd.conf
・ロックファイル、PIDファイル
・起動スクリプト(/etc/rcまたはそこから呼ばれるもの)
を別々にする必要があると思われる。

httpd.confは、異なるファイル名で2つ用意し、httpdの起動時に"-f"オプションを指定して区別させれば良い。
ロックファイルやPIDファイルの指定は、httpd.confの中で行う。それぞれ"LockFile"、"PidFile"の行で別々のものを設定する。

今回、最終的に(A)と(B)のhttpd.confの差分は次のものとなった。
・LockFile/PidFileの設定
・ErrorLogの設定
・ポート番号
・httpdプロセスの数に関係する値(MaxSpareServers, MinSpareServers, StartServers, MaxClients)
・mod_proxyの設定
・mod_perlの設定(LoadModuleやAddModuleも含めて)

起動スクリプトについては、本サーバーはFreeBSD 4.xなので、それに特化した話になるが、/usr/local/etc/rc.d/にapache-backend.shというファイルを追加した。apache.shとの差分は次の通り。
・apache_flagsの行("-f (config)"によるhttpd.confの指定)
・apache_pidfileの行(httpd.confのPidFileと同じものにする。httpdを通さない処理に必要になる)

See more ...

WriteBacks

上記のmod_proxyの設定で、MovableTypeの全てのCGIへの要求をmod_perlサーバーに転送するようにしていたが、それだとMovableType的にまずいことがわかった。コメントのCGI(mt-comments.cgi)への要求がproxyされると、コメントの送信元IPアドレスが全てlocalhostになってしまい、IPアドレスによる迷惑コメントのフィルタリングが効かなくなり、さらにMovableTypeによってlocalhostが勝手に「禁止IP」に追加されてしまい、一切のコメントが投稿できなくなってしまうのだ。従って、mod_perlで処理されるCGI要求だけをmod_perlサーバーにproxyするように設定を変更した。同様の理由で、このサーバーではコメントのCGIをmod_perl化できないことが確定した。

Posted by ynomura at 10/29/2007 06:01:24 PM

Oct 14, 2007

MovableType3.35をmod_perlで動かす(2/2)

前のエントリーに書いたように、mod_perlのApache::Registryを使ってMovableTypeを動かすのに失敗した後、改めてMovableType3.2のマニュアルを基点に調べていると、MovableType DocumentationのページMovableType3.3のインストールガイド(PDF)にもmod_perl化の方法が書かれていることに気付いた。こちらにはApache::Registryを使う方法は書かれていない。

そこでMovableType3.3のインストールガイドに従ってやってみた所、いくつかのトラブルがあったが、何とかMovableTypeをmod_perlで動かすことができた。

●mod_perlの設定(MovableType自体をPerlHandlerにする)
最終的にhttp.confの末尾に書いた設定は以下の通り。/path/to/…となっている部分は、実際のものから書き換えている。


#(a) library path descriptions passed as-is to the Perl interpreter
<Perl>
use lib '/path/to/mt/lib';
use lib '/path/to/mt/extlib';
use lib '/path/to/mt/plugins/WidgetManager/lib';
use lib '/path/to/mt/plugins/StyleCatcher/lib';
use lib '/path/to/mt/plugins/GoogleSearch/lib';
use lib '/path/to/mt/plugins/spamlookup/lib';
</Perl>

#(b) just as the installation guide says
Alias /mt/mt-static/ /path/to/mt-static/

#(c) definition of the Perl handler, set to MovableType
PerlModule MT::App::CMS
<Location /mt/app>
SetHandler perl-script
PerlHandler MT::App::CMS
PerlSetVar MTConfig /path/to/mt/mt-config.cgi
Allow from 192.168
</Location>

#(d) corresponding to "$CGIPath/$AdminScript" in mt-config.cgi
<Location /cgi-bin/mt/mt/app>
SetHandler perl-script
PerlHandler MT::App::CMS
PerlSetVar MTConfig /path/to/mt/mt-config.cgi
Allow from 192.168
</Location>

(a)のPerlのライブラリパス設定の部分は、インストールガイドには最初の2行しか書かれていないが、実際にはインストールしてるプラグイン全ての分が必要だ。プラグインの分の設定が無いと、MovableTypeの管理画面で時々、例えば下のようなエラーが出る。

Can't locate object method "get_handle" via package "StyleCatcher::L10N" at /usr/local/www/cgi-bin/mt/lib/MT/Plugin.pm line 459.

(b)の部分はインストールガイドのままの記述だ。おそらくhttpd.conf内のaliasが誤って適用されないようにするための処置だと思われ、必須ではないような気がするが、念の為加えている。

(d)の部分は後述の"$CGIPath/$AdminScript"の対策だ。

●mt-config.cgiの設定
インストールガイドに書かれている通り、下の設定を加える。

StaticWebPath http://hostname/mt/mt-static
AdminScript mt/app

StaticWebPathのhostnameより右の部分は、httpd.confの(b)で定義したエイリアスにする。実際には、StaticWebPathは既存の設定のままでも、少し使った感じでは問題なく動いたように見えた。

●起動確認
さて、インストールガイドに従ってhttpd.confとmt-config.cgiを書き換えてhttpdを再起動し、いざmod_perl経由のMovableTypeの管理画面にアクセスしようとすると、URLがわからない。もちろん既存のURLにアクセスすると、別プロセスのPerlのCGIが起動してしまう。上記の設定の場合、正解は、

http://hostname/mt/app
だ。なぜインストールガイドに書かれてないのだろう。httpd.confをいじるなら、それくらい判れということだろうか。

当初、上記(d)の設定をしていない状態で、ブラウザでhttp://hostname/mt/appにアクセスするとログイン画面が表示され、パスワードを入力すると、mt-config.cgiのCGIPATHとAdminScriptとを繋げたURL(http://hostname/…/mt/mt/appのような感じ)にジャンプしてしまい、ページが見つからないというエラーになってしまった。
それで思わずCGIPATHをhttp://hostname/に書き換えてしまった。それから出てくるエラー(プラグインが見つからないというエラーもここで出た)に対処すると、そこそこ動作するようになった。エントリーの追加、サイトの再構築もできたので、これでバッチリかと思い始めた頃、コメントの投稿ができないことに気付いた。CGIPATHを書き換えてしまったため、MovableTypeが生成したページから呼ばれる他のCGIが起動できないのだ。

正直な所、この管理画面のURLが"$CGIPATH/$AdminScript"になる問題への適切な対処はわからない。
インストールガイドに書かれてる方法で、必要な全てのCGIをmod_perl化すれば良いかも知れないが、そうするとテンプレートに書いている全てのCGIへのリンクをmod_perlのものに書き換えないといけなくなるので大変だ。
という訳で、上記(d)の設定を加えて、$CGIPATHと$AdminScriptとを繋げたURLについても/mt/appと同じ動作をするようにした。もしかして、インストールガイドの<Location /mt/app>は、CGIPATHのホスト名より下の部分を付け加えたものとして読めということだろうか。

●検索機能(mt-search.cgi)のmod_perl化
インストールガイドには、同様の方法でMovableTypeのどのCGIもmod_perl化できると書かれており、このサーバーではmt-search.cgiが非常に遅く、サイト内の検索に1分くらいかかっていたので、これをmod_perl化することにした。

httpd.confに追加する必要があるのは、PerlModuleの行と、それに続く<Location>のブロックだ。インストールガイドでMT::App::CMSとなっている部分(アプリ起動メソッド)を何にすべきかは、mt-search.cgiの中身を見ればわかる。

use MT::Bootstrap App => 'MT::App::Search';

とあるので、MT::App::Searchだ。従って、

PerlModule MT::App::Search
<Location /mt/search>
SetHandler perl-script
PerlHandler MT::App::Search
PerlSetVar MTConfig /path/to/mt/mt-config.cgi
</Location>

というのをhttpd.confの末尾に追加し、httpdを再起動した。
それから、MovableTypeの検索機能のURLがhttp://hostname/mt/searchに変わったので、テンプレート内のmt-search.cgiの部分を書き換えて、ページを再構築した。
以上の手順で、検索機能をmod_perlで起動することができるようになった。

ただ、httpd起動直後は、なぜか検索を実行するとノータイムでエラーとなってしまい、何回か検索を実行しないと初回の検索がなされない。httpdのログに何も出ないし、ブラウザの画面には「エラーが発生しました」とだけ出るので、何が悪いのかさっぱり分からない。

ついでに、テンプレートを全て書き換えるのが大変なので、httpd.confの上記の<Location>ブロックの直後に


<Location /cgi-bin/mt/mt-search.cgi>
SetHandler perl-script
PerlHandler MT::App::Search
PerlSetVar MTConfig /path/to/mt/mt-config.cgi
</Location>

を加えてみた所、自信は無いが、とりあえず以前のCGI起動のURLでもmod_perl起動するようになった。

●その他の設定
mod_perlでPerlを常駐化すると、httpdの子プロセスのそれぞれにPerlが常駐することがわかった。
MovableType常駐後は子httpd1つ当たり約30Mものメモリを占有してしまう。swapと合わせてもメモリが192Mしかないこのサーバーでは空きメモリがあっという間に無くなってしまったので、子httpdの数、すなわちhttpd.confのMaxClientの数を減らした。

See more ...

WriteBacks

Oct 13, 2007

MovableType3.35をmod_perlで動かす(1/2)

今週、某サイトのApacheの記事を読んでいて、mod_proxyというモジュールに興味を惹かれてApacheのマニュアルやhttpd.confを眺めてると、mod_perlという単語が目に止まった。この単語は私にはかなり昔から見覚えがあって、何だろうこれは、とずっと気になっていたので、少し調べてみると、どうやらApacheのモジュールで、Perlのプロセスを常駐させてCGIを速く動かせるもののようだった。(あくまでmod_perlの利点の1つで、mod_perlの役割はそれだけではない)

ということは、CGIとJavaのServletを比べた場合にServletの利点とされる、HTTPサーバーの一部として動くことによる効率の良さが、Perlでも実現できるということだ。(PHPを使ってる人は何を今更と言うかも知れないが)

このサーバー(CPU: Pentium 150MHz, OS: FreeBSD 4.11)では、これまでMovableTypeが遅く、管理画面でサーバーにアクセスする度に14秒以上かかっており、何かいい方法が無いものかと思っていたので、MovableTypeをmod_perlで動かせないかと思い、Webで調べてみると、Six ApartのMovableType3.2のマニュアルにやり方が書いてあった。

今日、早速それに従って試してみた。
上記のマニュアルには、MovableTypeをmod_perlで動かす方法として、Apache::Registryを使う方法と、MovableType自体をPerlHandlerとする方法の2つが書いてあり、前者の方が手軽にできそうだったので、まずApache::Registryを使う方法を試そうとした。
結論としては、この方法はうまくいかなかった。

●mod_perlのインストール
MovableType3.2のマニュアルによると、MovableTypeを動かすにはmod_perlのバージョンが1.xでないといけないので、今回はFreeBSDのportsを使ってバージョン1.3をインストールした。mod_perl 1.xを使うにはApacheは1.xである必要があるが、元々1.3を使っていたので問題なかった。
mod_perlの動作確認は、mod_perlのページに従って、以下のような設定をhttpd.confの末尾に追加して試した。
(インデントは省略)

Alias /perl/ /…/cgi-bin/

PerlModule Apache::Registry
<Location /perl/>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
PerlSendHeader On
Allow from all
</Location>


httpd.confを書き換えて、httpdを再起動して、ローカルで既存の簡単なPerlのCGIにhttp://localhost/perl/….cgiというURLでアクセスすると、CGIとして動作させた場合と同じ出力が得られた。なお、あらゆるPerl CGIがそのまま動くわけではないので注意が必要だ。

●Apache::Request, Apache::Cookieのインストール
MovableType3.2のマニュアルによると、mod_proxy(Apache::Registry)を使ってMovableTypeを動かすには、PerlモジュールのApache::RequestとApache::Cookieが必要だ。
Perlモジュールのインストールは、CPANのシェルを使って、下記の要領でできる。

> perl -MCPAN -e shell
cpan[1]> install Apache::Request Apache::Cookie

cpanコマンドが存在する場合は、下記のようにしてもできる。
cpan -i Apache::Request Apache::Cookie

CPANによるインストールには、このサーバーではRAMの空きが60M~70M程度必要だった。メモリ不足になると、メモリ不足だとわかるメッセージを出さずに、"Killed."とだけ出て終了してしまう。

なお、root権限で、作業ディレクトリをroot権限でしかアクセスできない場所(/rootとか)にして、CPANを使ってApache::Requestをインストールしようとすると、途中のmake testの時に

[ error] You are running the test suite under user 'root'.

The problem is that the path (including all parent directories):
/root/.cpan/build/libapreq-1.33/t
must be 'rwx' by user 'nobody', so Apache can read and write under that path.

というエラーが出る。しかし、
Skip the test suite? [No]

と尋ねられた時に"Yes"と答えれば、インストールは続行できる。今回は、インストールした後に、作業ディレクトリを/usrに移して、make testだけ手動で起動して全てOKとなることを確認した。
やはりコンパイルまではユーザー権限で行って、インストールだけをrootで行うべきだった。一般論としても、その方がインストール準備まででトラブルが発生してもシステムに影響が無いようにできるので、rootでのコンパイルは避けるべきである。

●mod_perlの設定(Apache::Registry)
MovableType3.2のマニュアルに従い、httpd.confの末尾に

PerlModule Apache::Registry
<Location /cgi-bin/mt/>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Location>

を追加して、httpdを再起動してブラウザからhttp://…/cgi-bin/mt/mt.cgiにアクセスすると、MovableTypeのログイン画面は表示されたが、ログインすると、ページが見つからないというエラーになり、その後はログイン画面も表示されなくなった。
Perlのプロセスは新規に立ち上がることは無く、httpdのプロセスにPerlが常駐しているらしいことが確認でき、他のPerlスクリプトはmod_perl経由で正常に実行できたので、常駐してるMovableTypeがおかしな状態になったようだった。
CGIの設定と不整合を起こしてるのかと思い、httpd.confの設定を

Alias /perl/ /…/perl/ # out of cgi-bin directory

PerlModule Apache::Registry
<Location /perl/mt/>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Location>


という風にして、MovableTypeをApacheのcgi-binディレクトリ以外の所に移して試したが、動作は変わらなかった。

See more ...

WriteBacks

Oct 08, 2007

MovableType3.35インストール

何ヶ月か前から、このweblogのトップページに表示される最近のエントリーの末尾の「コメント (*)」「トラックバック (*)」というリンクがおかしくなっており、辿っても何も表示されなくなっていたが、原因がわからなかった。おそらくコメントデータの不整合だろう、Berkeley DBからMySQLに移行すれば直るかも知れないと思って、少し前にSix Apartのサイトのマニュアルを参考にしてMySQLデータベースへの変換を試みたが、日本語が文字化けしてしまった。これも原因がわからなかった。

同じバージョンであるMovableType3.33と全く同じBerkeley DBのデータを用いて、予備の環境でMySQLデータベースへの変換を行うと、文字化けしなかったので、問題は本環境のMySQLにあると思い、MySQLのcharset周りを調べて色々試したが、解決しなかった。本環境と予備環境の違いは、FreeBSDのバージョンの違い(4.11/5.5)とMySQLのバージョンの違い(5.0/5.1)と、いくつかのPerlモジュールのバージョンの違いしか無い。

今日、これまでの調査結果を踏まえて再度調べていると、MySQLに移行して文字化けしたデータでもサイトの再構築はでき、「コメント」「トラックバック」のリンクの問題は全く解決しないことに気付いた。これはMovableTypeを4.xにバージョンアップするしかないか、と思ったが、4.xにバージョンアップして直らなかったら立ち直れないと思い、3.xのままでまともに解析することにした。

どうせ4.xにするとテンプレート総入れ替えになるだろうから、と思って、試しにテンプレートを3.xのデフォルトのものに戻すと、エントリー毎のコメントやトラックバックへのリンクが正常に動作した。そのことから突き詰めると、結局、この環境では、テンプレート内の<$MTCommentScript$>(mt-comments.cgiに置換される)、<$MTTrackbackScript$>(mt-tb.cgiに置換される)は無効であるらしいことがわかった。MovableType3.17の頃は問題なく使えていたのだが。
代わりに"<$MTEntryPermalink$>#comments" "<$MTEntryPermalink$>#trackback"を使うことで、リンクの問題は解決した。

文字化けの問題はもっと単純で、Six Apartのニュースによると、MovableType3.34から3.35の変更点として

convert-dbおよびmt-db2sql.cgiで別のデータベースに移行すると移行先のデータが文字化けする可能性がありました。この不具合を修正しました。

と書かれており、それで解決することを信じてMovableTypeを3.33から3.35へバージョンアップすると、文字化けせずにSQLデータベースへの移行ができてしまった。

ついでに、以前のエントリーのコメントに書いた、エントリー投稿時にエラーが発生することについても修正されていることを確認した。

See more ...

WriteBacks

Sep 30, 2007

MySQL Connector/J導入記

JDBCを使ってMySQLにアクセスするためのJava側のドライバとして、MySQL Connector/Jというものがある。
今回、JDK 1.3、Tomcat 4.1が動いている環境にMySQL Connector/J 5.0をインストールし、動かしてみて気付いたことや、遭遇したトラブルと実際に行った対処を書き留める。

(1) JDK 1.3でMySQL Connector/Jを使う時の注意点
MySQL Connector/Jのマニュアルの§1.1.1にあるが、JDK 1.4未満では、class verifierをOFFにする必要がある。コマンドラインからJava VMを起動する場合は、-Xverify:noneを指定すれば良い。

(2) JDK 1.3+TomcatでMySQL Connector/Jを使う時の注意点
上記(1)の制限により、TomcatのJava VM起動時オプションに"-Xverify:none"を指定する必要がある。FreeBSD 4.11でTomcat 4.1を動かしているこのサーバーでは、/etc/rc.confに

tomcat41_java_opts="-Xverify:none"

を加えている。

なお、シェルのコマンドラインからjavaコマンドを使用する場合は、mysql-connector-java.jarをJDKのディレクトリの下のjre/lib/ext/に置いておくとCLASSPATHの指定が不要になるが、Tomcatの場合はこれは無効である。インストールマニュアルの通り、mysql-connector-java.jarをTomcatのディレクトリの下のcommon/lib/に置く必要がある。

(3) MySQL Connector/JのExample 10がSQLエラーになる
あるMySQLのサーバーに対して、MySQL Connector/JのマニュアルのExample 10のコードを動かすと、

You have an error in your SQL syntax near 'DEFAULT, 'AUTO INCREMENT here?')' at line 1

というメッセージと共にSQLExceptionが発生した。
そのサーバーに対してMySQLのコマンドライン(クライアント)からサンプルコードと同等の処理である
INSERT INTO ... VALUES (DEFAULT, "...");

を実行すると、同様のエラーとなった。

MySQLのinfoによると、MySQLをconfigureする時にDONT_USE_DEFAULT_FIELDSを指定すると、そういう動作になるらしい。このコンパイルオプションはバージョン5.0.2で削除されているが、システム変数sql_modeをSTRICT_TRANS_TABLESにすると同じことが起こる。

このエラーを回避するには、rs.insertRow();の前に

rs.updateInt("priKey", 0);

を足すと良い。
第2引数は、0以外だと、auto incrementの初期値を与えることになるので正しくない。

See more ...

Posted at 22:32 in UNIX | WriteBacks (0)
WriteBacks

Sep 23, 2007

(FreeBSD)TomcatでServletする(2/2)

インストールし立てのTomcatを起動してHTMLブラウザでアクセスすると、予め用意されているコンテンツ(TomcatではWebアプリと言うらしい)が表示され、ブラウザがJavaに対応していれば、サンプルのServletやJSPがすぐに動く。サンプルのServletのソースを見ることもでき、開発意欲をかき立てられる。

なお、Tomcatのマニュアル(RUNNING.txt)には、デフォルトの設定ではポート8080で待ち受けると書いてあるが、FreeBSDのportsはそれを8180に書き換えるので、注意が必要だ。

そのサンプルソースを改造して、自前のServletを作成して、いざTomcatで動かそうとすると、作成したServletをどこに置いてどういう設定をすれば良いかがわからない。
とりあえず、最初のテストとしては、クラスファイルをサンプルServletのある所(webapp/examples/WEB-INF/classes/)に置いて、サンプルServletの設定があるwebapps/examples/WEB-INF/web.xmlに同じような設定(<servlet>と<servlet-mapping>)を加えればよい。そうして新たなServletが動けば、JDKの動作には問題なしだ。

Servletのきちんとした配置と設定は、大変見つけにかったが、TomcatのマニュアルのDeploymentのページ(TomcatのデフォルトのWebアプリのページから"Tomcat Documentation"→"App Developer Guide"→"Deployment"と順に辿る)に書いてあった。Servletを動かすための最低限の準備は、
(1) Tomcatのwebappsディレクトリに新たなディレクトリ(ここでは"sample"とする)を作成し、
(2) webapps/sample/WEB-INF/classes/ にクラスファイルを置き、
(3) webapps/sample/WEB-INF/ に設定ファイルであるweb.xmlを置く
だ。web.xmlは、conf/web.xml.sampleをコピーして編集するが、筆者が試した所、Tomcat 4.1では<web-app>の中に<servlet>と<servlet-mapping>だけでうまくいったが、Tomcat 5.5では<session-config>も必要だった。

今回、試験的なアプリとして、ランダムな表を出力するServletを作ってみた。
RandomTable Servletへのリンク
 ※アクセス後、ブラウザでページの更新(再読み込み)をすると違う表が出てくると思います。
 ※JRE 1.3.1 + Tomcat 4.1で動かしています。
RandomTable Servletのソースコードへのリンク
web.xmlへのリンク
 ※Tomcat 4.1で不要だった部分はコメントアウトしています。

See more ...

Posted at 18:53 in UNIX | WriteBacks (2)
WriteBacks

ServletとCGIの違いであるが、プログラムを作る側にとっては、その起動形態の違いが結構大きいということがわかってきた。 CGIのプログラムは毎回ゼロから起動される(新しいプロセスで動く)ため、メモリ上のデータは毎回失われるのに対し、ServletはHTTPサーバーが動いている間ずっと動き続ける(プロセスに残る)ため、メモリ上にデータを残すことができるのだ。 具体的には、例えばServletの静的クラス変数は、そのServletが呼び出された時に前回の値が残っている。従って、そのServletが何回起動されたかは、静的クラス変数で簡単に記録できるわけだ。 同様に、HTTPセッションの保持も比較的簡単にできる。JDBCのDBとの接続をServletで一定数保持して使い回すという使い方も定番のようだ。 HTTPサーバーの一部として動くという形態のServletは、CGIよりサーバーの負荷を低く抑えられることが多いので、アクセス頻度の高いシステムでは有効であろう。

Posted by ynomura at 09/29/2007 07:20:23 PM

Servletのデメリットとして、全てのServletでJava VMを共用するので、全てのServletが動く設定でJava VMを動かさないといけない。そのため、1つのServletがJava VMの設定を制限すると、全てのServletに影響してしまう。例えば、MySQL Connector/Jモジュールを使うにはclass verifierをOFFにする必要があるので、そのモジュールを使うServletがあると、全てのServletでclass verifierが使用不能になってしまう。JavaのCGIだとプログラム毎にJava VMの起動オプションを変えることができるので、この点もServletとCGIの違いと言えるだろう。

Posted by ynomura at 09/30/2007 09:24:19 PM

Sep 22, 2007

(FreeBSD)TomcatでServletする(1/2)

HTTPのクライアント側で動作する小さなJavaアプリを指すアプレット(applet)と呼ぶが、それに対してサーバー側で動作する小さなJavaアプリを指すサーブレット(servlet)という言葉がある。昔かすかに聞いた覚えはあるが、その後servletなんて言葉はすっかり忘れていた。
先月から興味があってJDBCを勉強し始めているが、その関連の本を読むと、よくServletの話が出てくる。JavaはWebで使われることが多く、データベースをクライアント側で使うことは稀であるから、JDBCはServletで使われることが多い、ということになるのだろうか。

という訳で、このFreeBSDのWebサーバーにServletを動かす環境を作ってみたので、その過程を報告する。

まず必要なソフトであるが、Java開発環境であるJDK、Java動作環境であるJRE(Java VM)は当然として、クライアントの要求を受けてJavaアプリを起動するHTTPサーバーが必要だ。当初はCGIと似たような動作なのでApacheの設定かプラグインでできると思っていたが、過去にはJServというプログラムを使ってそのようなことをしていたようだが、今はTomcatという異なるHTTPサーバーを使うのがオープンソースでは主流のようだ。他にJRunやResinなどがあるが、これらは基本的には商用である。
蛇足だが、現在TomcatはApacheのプロジェクトで開発されているらしい。Jakarta TomcatとApache Tomcatは同じものである。

次に具体的なインストールの方法を記す。

●FreeBSDへのJDKのインストール
JDKにはJREが含まれているので、Java環境としてはJDKだけをインストールすれば良い。
しかし、最初につまづくのが、Sunが配布するJDKには、Linux用のバイナリはあるが、FreeBSD用のバイナリが無いことだ。従って、インストールするバイナリは次の3通りから選択する必要がある。
 (1) JDKのソースコードをコンパイルしてFreeBSD nativeなバイナリを作る
 (2) FreeBSDのLinux emulationによって、Linux用のバイナリを使う
 (3) Sun以外が配布するFreeBSD nativeなバイナリを使う

勿論(3)が一番楽である。FreeBSDのバージョンが5.5以降でJavaのバージョンが(1.4以前でなく)1.5で良いなら、FreeBSD Foundationが配布するDiablo JDKをインストールすれば良い。これはportsを使用してインストールすることもできる。

しかしながら、このサーバーのように、4.x以前のFreeBSDしか動かず(未だ原因不明)、HDDの空き容量が2G以上必要なJDK1.5のコンパイルができない場合は、別の選択をせざるを得ない。

JDK1.4については、(3)のようなバイナリは存在しない。CPUがPentium 150MHzであるこのサーバーでは、(2)のようにしてLinux emulationでLinuxのJREを動かすのでは、動作速度に難があり使い物にならない。
従ってJDK1.4をソースからコンパイルしたいのだが、少なくとも現時点のportsでは、なんとJDK1.4をコンパイルするのに(2)のLinux emulationによるLinuxのJDK1.4が必要になる。そして、portsのMakefileに書かれていたが、LinuxのJDK1.4を動かすには、FreeBSDが5.4以降である必要がある。
ついでに、JDK1.4のMakefileを動かし始めると、コンパイルには1.7GのHDDの作業領域が必要だという注意書きが表示された。このサーバーには0.4Mも空きが無いので、どの道無理であった。

Tomcat 5.5を動かすにはJDK1.4以上が必要なのだが、Tomcat 4.1なら、JDK1.2以上があれば良いので、このサーバーにはJDK1.3を入れることにした。
JDK1.3についても現在は(3)のようなバイナリが存在しない(過去にはDiablo JDKの1.3があったようだ)が、portsを使えば、JDK1.3のソースコードからのコンパイルは、Linuxのバイナリが必要になることも無く、実に簡単にできた。JDK本体のコンパイルはPentium 150MHzでも2~3時間でできたし、HDDの作業領域も300Mで足りた。

●Tomcatのインストール
packages/portsを使えば、特に難しいことは無かった。このサーバーにTomcat 4.1を、別のPCにTomcat 5.5をインストールしたが、どちらもバイナリのインストール自体は容易だった。
敢えて注意すべきことを挙げると、上に書いたことと重複するが、JDKが1.3以前だとTomcat 5.0以降は動かせないことと、packages/portsのパッケージ名ではtomcat??とapache-tomcat??は同じものだということがある。

Tomcatの起動スクリプトは/usr/local/etc/rc.d/に作られるので、それを参考に、/etc/rc.confにtomcat_enable等の行を追加すれば、Tomcatが起動できるようになる。(OS起動時にも自動的に起動されるようになる)
ちなみに、このサーバーの/etc/rc.confの設定は、

tomcat41_enable="YES"
tomcat41_java_home="/usr/local/jdk1.3.1"
tomcat41_java_vendor="sun"
tomcat41_java_version="1.3"
tomcat41_java_os="native"
tomcat41_java_opts="-Xverify:none"

である。最後の行は、JDBCのI/Fの都合で追加したものであり、Tomcat単体としては必要ない。

ただ1点問題なのは、Tomcat 4.1は、起動スクリプトを使ってTomcatの起動はできるが、状態表示や終了ができないことだ。通常運用だと特に問題無いのだが、Servletのクラスファイルを更新するとTomcatを再起動する必要がある(Tomcat自体がJava VM上で動いておりServletを1回起動したらその名前のクラスはロード済になってしまうため)ので、Servlet開発中は不便である。
原因はロックファイル(/var/run/tomcat41.pid)がうまく作られない(中身が空になる)ことなのだが、/usr/local/etc/rc.subrとにらめっこしているが、今の所修正方法を発見していない。
FreeBSD 5.5のTomcatだとそういう問題は起こらないので、Tomcat 4.1のportsがFreeBSD 4.x以前のことを考えていない可能性がある。
また、samba等他のサーバープログラムの起動スクリプトを一通り見たが、サーバープログラムが自前でdaemon起動しロックファイルを管理しているものばかりで、Tomcatのようにdaemonコマンドを使用してJavaのようなインタプリタをdaemon起動するものは無く、参考にならなかった。起動スクリプトにてJava起動後のpidを取得してロックファイルに格納するというのは、OSの助けが無い限り、並の手段では不可能のように思える。

See more ...

Posted at 20:18 in UNIX | WriteBacks (0)
WriteBacks

Aug 14, 2007

忘れやすいC++の仕様(3/3)

1つ前のエントリーの続きである。

(5) 純粋仮想関数の定義方法
クラス定義内で、"virtual void foo() = 0;"のように、メソッドのプロトタイプにて、関数=0;とする。
関数の宣言と同時に、関数のポインタの値を0に決めてしまうという感じだろうか。独特の風味だ。

この"=0"を外すと、派生クラスに関数の実体があっても、基底クラスの仮想関数の実体が無いということでコンパイルエラーになるし、"=0"じゃなく"{}"とすると、その基底クラス(仮想クラス)のインスタンスを作ることが可能になってしまう。

(6) デストラクタはvirtualにすると派生クラスのデストラクタも呼ばれる

class CLS{
    …
public:
    virtual ~CLS() {…}  /* (g) */
};

class DRV : public CLS{
    …
public:
    ~DRV() {…}
};

int main()
{
    CLS* p = new DRV;
    delete p;  /* (h) */
}
このコードにおいて、(h)の基底クラスのポインタを使ったdeleteを実行すると、派生クラスのデストラクタDRV::~DRV()と基底クラスのデストラクタCLS::=~CLS()が順に呼び出される。もし(g)のvirtualが無いと、CLS::=~CLS()しか呼び出されない。
従って、基底クラスのデストラクタはvirtualにすべしと言えるだろう。

蛇足だが、派生クラスのポインタを使ってdeleteすると、基底クラスのデストラクタをvirtualにしていなくても、派生クラスのデストラクタの後に基底クラスのデストラクタが呼び出される。

(7) フレンド関数の1つ目の引数は型変換される
フレンド関数の1つ目の引数については、フレンド関数の他に適用できるクラスメソッドや関数やが無く、型変換により適用可能であれば、自動的に型変換されて適用される。
クラス外で定義されるクラスメソッドは、1つ目の引数が型変換されて適用されることは無い。従って、フレンド関数はクラスメソッドよりも適用範囲が広いと言える。

次のコードは、1つの演算に適用できるクラスメソッドとフレンド関数との両方がある例である。

class CLS1{
    friend class CLS2;
    int i;
public:
    CLS1(int i=0){this->i = i;}
    CLS1& operator+(double d){i += (int)d; return *this;}  /* (k) */
};

class CLS2{
    double d;
public:
    CLS2(){d = 0.0;}
    CLS2(CLS1 &i){d = (double)i.i;}  /* (l) */
    friend CLS2& operator+(CLS2, double);  /* (m) */
    double get() const {return d;}
};

CLS2& operator+(CLS2 c2, double e)  /* (m) */
{
    c2.d += e;
    return c2;
}

int main()
{
    CLS1 c1(3);
    CLS2 c2 = c1 + 2.5;  /* (n) */
}
このコードにおいては、(n)の演算において(k)のクラスメソッドがc1.operator+(2.5)という形で呼び出され、演算結果は5.0になるが、もし(k)の行が存在しないと、(n)の演算において、(l)による型変換が自動的に適用されて、(m)のフレンド関数がoperator+(CLS2(c1), 2.5)という形で呼ばれ、演算結果は5.5になる。

Posted at 11:05 in PC一般 | WriteBacks (0)
WriteBacks

Aug 13, 2007

忘れやすいC++の仕様(2/3)

続いて、C++のクラスの仕様に関する、忘れていたことを書き留める。

(1) 定数オブジェクトは定数メソッドしか使えない
例:

class CLS{
    int i;
public:
    CLS(int i = 1){this->i = i;}
    int get() const {return i;}  /* (a) */
    void set(int i) {this->i = i;}
};

int main()
{
    CLS c1;
    const CLS c2(2);
    int i;

    c1.set(3);
    c2.set(4);    /* (b) */
    i = c1.get();
    i = c2.get();    /* (c) */
}
このソースをコンパイルすると、(b)でエラーになる。
もし(a)の行のconstを外すと、(c)もコンパイルエラーになる。コンパイル時にreadonlyとwritableの区別はメソッド呼び出し毎に厳密になされる言語仕様らしい。
定数オブジェクトが出現する可能性を考えると、クラス定義においてメソッドの定数定義は重要だ。

(2)デフォルトコンストラクタが無いと配列を定義できない

class CLS{
    int i;
public:
    CLS(int i){this->i = i;}    /* (d) */
};

int main()
{
    CLS c[2];    /* (e) */
}
このコードは、(e)がコンパイルエラーになる。
C++では、配列の定義時に引数のあるコンストラクタが呼べないので、引数なしで呼べるコンストラクタ(デフォルトコンストラクタ)が存在しないと、そのクラスの配列は定義できない。
従って、CLS::CLS()やCLS::CLS(int i=0)のようなメソッドが必要になる。

なお、このコードの(d)を削除すると、コンパイルが通る。明示的なコンストラクタ定義が1つも無ければ、自動的にデフォルトコンストラクタが作成されるからだ。

(3)単項演算子の定義方法
単項演算子には前置(++obj等)と後置(obj++等)があり、それぞれ定義方法が異なる。
クラス名をCLS、演算子を@とすると、前置はCLS::operator@() / operator@(CLS&)、後置はCLS::operator@(int) / operator@(CLS&, int)で定義する。呼び出し時には、int引数には0が入る。

また、単項演算子関数が返す型は、CLSでもCLS&でも良い。だから、通常は異なる値を生成する(一時的なインスタンスを作って返す)マイナス演算子が何もしないなら、

CLS& CLS::operator-() {return *this;}
と参照を返すこともできる。

(4) コピーコンストラクタと代入演算子の共通化
コピーコンストラクタを定義する必要がある場合、代入演算子もそっくりな内容で定義する必要がある場合が多い。
そんな代入演算子を定義しようとして、

class CLS{
private:
    …
public:
    CLS(const CLS& c){…}
    const CLS& operator=(const CLS& c){CLS(c); return *this;}  /* (f) */
};
のようにコピーコンストラクタを普通のメソッドと同じ感覚で呼び出そうとすると、コンパイルエラーになる。なぜなら、上記の"CLS(c);"は"CLS c;"と同じ意味(!)、つまり新たなインスタンスの定義になるからだ。
コピーコンストラクタと代入演算子の処理を共通化するには、次のように別な関数を用意する必要がある。
class CLS{
private:
    …
    inline void copy(const CLS& c){…}
public:
    CLS(const CLS& c){copy(c);}
    const CLS& operator=(const CLS& c){copy(c); return *this;}
};

(参考文献:JIS X 3014)

Posted at 22:13 in PC一般 | WriteBacks (0)
WriteBacks

Aug 10, 2007

忘れやすいC++の仕様(1/3)

私は10年ほど前にC++の仕様を隅から隅まで覚えたことがあるが、それから10年、全く触っていない。Cは時々接するのでANSI Cの仕様はまだ結構覚えているが、C++の仕様は全般的にうろ覚えだ。

そんな状態で、久々にC++の仕様を眺めていると、すっかり忘れていることがいくつもあったので、ここに記す。

(1) 構造体内の構造体定義の参照


struct Outer{
struct Inner{
int i;
} j;
}

というコードのInnerを参照する場合、Cだと

struct Inner i;

とできるが、C++だと

struct Outer::Inner i;

としないといけない。

(2)int値のenum型への変換

Cでは


enum Color {RED=1, GREEN, BLUE};
enum Color c;
c = 1;

ができるが、C++ではできない。

c = Color(1);
c = (Color)1;

のようにする必要がある。

蛇足だが、Cで"c = Color(1);"とすると、コンパイルエラーとはならず、Color()という関数が無いというリンクエラーになる。

(3)template文はクラス定義以外にも使える


template<class T> T square(T x)
{
T y;
y = x * x;
return y;
}

のような関数定義もできる。

ひょっとしてtemplateをクラス定義にしか使えないと思い込んでいる人は少数だろうか。

(4)通常型引数と参照型引数の多重定義

C++では引数の型を変えて同じ名前の関数を多重定義できるが、


void foo(int i) {}
void foo(int &i) {}

の2つを同時に定義することはできない。

よく考えると、これらの関数を呼び分けられないので当然とも思える。

同様に

void foo(int i) {}
void foo(const int &i) {}

の組み合わせも不可だが、

void foo(int &i) {}
void foo(const int &i) {}

の2つは同時に定義できる。

なお、g++では重複定義自体はエラーにならず、呼び出し文にてコンパイルエラーとなった。


See more ...

Posted at 21:23 in PC一般 | WriteBacks (5)
WriteBacks

C++の複雑な仕様の中をよく覚えてますね! まねできないっす。。。 最近はCさえ忘れてきました。。。 もっぱらjavaで、ぬるま湯につかってます。

Posted by KaBA at 08/12/2007 11:42:34 AM

いえいえ、すっかり忘れてたってことでして… どうでもいいですが、MovableTypeでソースコードを貼り付けるの難しいですね。preタグを使うとやたら行間が空くし、preタグを使わずにインデントを表示しようとしたら全角スペース使うくらいしかないし、そうするとcopy&pasteでコンパイルエラーになるソースになるし… preタグ中でも"<"や">"が消えてしまうのは盲点でした。

Posted by ynomura at 08/13/2007 10:04:03 PM

C++ってホント難しいですね。 私は多重継承+friend関数で脱落しました。 でも、いろいろと応用が効きそうですね。 ynomuraさんの記事をみると。 あとは、interfaceが使えるといいのですけれど。今はどうなんですか? 演算子オーバーロードは初心者の頃、惹かれました。 私もHTMLはとっくの昔に忘れてしまいました。 pタグか、quote(?)タグはどうですか? あ、インデントか。。。 ネストもできなかったでしたっけ? <>は要注意っすね。

Posted by KaBA at 08/14/2007 08:36:47 PM

今回実は大学時代に取ったC++の入門書のコピーを捨てる前に読み返してたんですが、読む前は、friendって何で要るんだったっけ?という状態でした。特に演算子のオーバーライドをする時は重要のようです。C++はJavaと違って多重継承ができるので、インターフェースは昔から抽象クラス(仮想クラス)として記述することになってます。

class XXX_Interface{public:    virtual void xxx() = 0;};class YYY_Interface{(略)};class The_Implementer :  The_Superclass, XXX_Interface, YYY_Interface{(略)};
みたいに。HTMLでのインデントについては、結局HTML 4.01の仕様を調べたんですが、下記URLの9.1節に、preタグ以外では連続した空白は単語の区切りと解釈する、と明記されています。しかもTabは強く非推奨(9.3.4節)だそうで。http://www.w3.org/TR/html401/struct/text.htmlネストは可能なんですが、<pre>を使った途端に行間が空いてしまいます。使ってるstylesheetのせいかも知れませんが。というか、codeタグ(9.2節)を使ってもインデントが無視されてしまう仕様なのが、実に不思議です。

Posted by ynomura at 08/16/2007 08:49:18 AM

preタグを使うとやたら行間が空くのは、stylesheetのせいではなく、エントリーに「改行を変換する」(Convert Line Breaks)設定をした場合のMovableTypeの仕様だったようで、<pre>~</pre>の間の改行にも<br />が追加されて改行が2重になってたのが原因でした。<pre>~</pre>等の間の改行は変換しないプラグインもあるようですが、<pre>や<table>を使うエントリーは「改行を変換する」設定にしない方が良さそうです。

Posted by ynomura at 02/12/2008 11:28:33 PM

Jun 30, 2007

日本のソフトウェア産業を考える

日本のソフトウェア開発の生産性が低い理由を考察した記事を見つけた。
全く同感だったので、コメントと共に書き留める。
http://itpro.nikkeibp.co.jp/article/COLUMN/20070306/264055/

 中小のソフトウエア会社は、市場からの要請に応えて、新卒者をろくな教育もせずに開発プロジェクトに放り込んだ。大企業が採用した新卒者も、大量の採用で教育に手が回らず、事情は大して変わらなかった。

日本はプログラマーが不足していると昔から言われているが、ソフトウェア会社自体は結構多くあるように思う。それに、私自身が見てきた経験として、趣味でプログラミングをする若くて優秀なアマチュアのプログラマーは決して少なくない。しかし、優秀なプログラマーが職業プログラマーにはならない傾向があると思う。
その理由はいくつか思い当たる。例えば、趣味のプログラマーはモチベーションが無いと力を発揮できないことを感覚的に知っているため、やらされるプログラミングを嫌う。また、優秀なプログラマーは大抵プログラミング以外にも発揮できる能力があり、職業を選択できるため、プログラマーにはならない。それに、徹夜続きであるとか、実際にプログラミングができる時間は10%も無いとか、プログラマーという職業について希望を持てない噂が流れている。
その結果、ソフトハウスに入る新人はプログラミングの素人が多いのだろう。

 その一方で、目的と手段とを取り違えて、モデルに書かれたプロセスを表面的にこなし、小さな範囲で要領よく認証を取得し、あたかも会社全体がレベル達成したように宣伝する企業も増えた。認証獲得やアセスメント自体を目的とすると、達成した途端に経営トップが投資意欲を失い、地道な改善活動を妨げる。後には死んだ規格や形式的に書類に記録をするといった無駄な作業が残り、本来の目的と逆の結果をもたらす。

能力の無いソフトウェア開発者は、開発プロセスに従うことしか考えなくなる。そして、業務を効率的に進めるためにケースバイケースで開発プロセスを少し外れようとする優秀な技術者にケチをつけるようになる。開発効率を上げるために開発プロセスを手段として採用するのでなく、本来の目的を忘れて開発プロセスに従うことが目的になるのだ。

 発注する側がプログラミングなど、ソフト開発の最下流部分を発注しているつもりでも、受ける側に力量があれば、技術やノウハウを吸収して自らの力で設計や開発ができるようになる。逆に、発注者は技術とノウハウを維持しているつもりでも、実際にソフトウエアを開発していないと、高い品質で効率よく作る能力は急速に衰え、見積もりを正当に評価する力もなくなる。

発注者が受注者の納品物を検査するのは容易ではない。仕様通りに動くかどうかは、テストすれば分かるかも知れない。しかし、受注者も大きな工数をかけてテストをして出す訳で、それで見つからなかった不具合を発注者が見つけるのは大変だ。従って、基本的には受注者が提出したテスト結果報告を信用することになる。
受注者がかけた作業量が妥当であるかどうかを、実際に作業をしていない発注者が見極めるのも難しいし、納品物の仕様通りである以外の品質(保守性や効率性など)を、実際に作ってない発注者が見極めるのも難しい。
結局発注者側がそういう作業を嫌がるために、受注者側の言いなりになっていく。

システムからサブシステムを切り出し、自ら責任範囲を決め、それが果たせるようになると、親会社に執拗しつようにお願いして順次、請負契約に切り替えた。

 ところが派遣指向の会社はその逆をやっている。顧客が請負を要請しても、派遣を続けて欲しいと懇願しているのを知って驚いた。経営の自立は、個人の自立を促す。自らの意思で、必要な技術を身につけようとする。それが企業風土になれば、自立した企業と言える。

実際にソフトウェア開発の仕事をしていると、工数に対して費用を取る方式を希望する外注がある。やった仕事でなく、仕事した時間に対する報酬を求めている訳だから、できる仕事に自信が無いということにしか思えない。
逆に、請負契約(一括の業務委託)にすると、非常に融通が利かなくなる会社がある。最初に決めたこと以外は絶対にやらないとか、ちょっとした仕様変更に対して莫大な追加費用を請求するとかいうことが起こる。そういう会社に遭遇すると、工数精算という方式も重要だと思う。
2つの方式の適正運用に、多くの人が考えさせられ悩まされているのも納得だ。

See more ...

Posted at 09:58 in 雑記 | WriteBacks (2)
WriteBacks

引用文、コメントともに一字一句深く感動しながら読みました。 感動して目が潤みさえしてきましたよ。(/-T) ちょうど3年前の今日の記事だというのに、内容的にはなんと色褪せないことでしょう。 法改正の影響で、周囲では徐々に派遣が減りつつはありますが。 年齢的に好きなプログラミングだけやってはいられないこともわかってはいるのですが、 「書かなくなる→書けなくなる→読めなくなる→判断できなくなる」 の最終状態に行きついてはならないという、半分本音、半分建前のもと まだ筆を置くわけには行かない気がしています。 #筆はキーボードのアナログ表現です。(^m^) #筆を置く…プログラミングを止める #筆が進まない…コード作成の進捗状況が悪い

Posted by yukineco at 06/30/2010 10:30:09 PM

さすが、お目がhighでござられます。 ソフトウェアの技術は日進月歩であります。 年々覚える事が増えております。 私はソフトウェア技術の半分以上は新しいものを使いこなす能力、すなわち理解して覚える能力に依存していると考えております。 そして少なくとも今の所、新しいものを使いこなすには最低限のプログラミングができる必要があると思います。 ついていけなければ現場から遠ざかるしかありません。 たとえ監督業でも、現場の近くに居るには、プログラミングの腕(指?)を維持し、理解し、覚え続けるしかありません。 ソフトウェアの分野で、理解すること、覚えることを放棄し、過去の経験に頼って仕事することに、現実味があるとは思えません。一体この世界で何を覚えれば一生食っていけると言うのでしょう。 それなのに、技術から卒業し、または卒業させられ、または技術を極めようとする人が冷遇されて、日本にソフトウェア技術者が増えないことは、残念の極みであります。 むむむ、無念なり。

Posted by ynomura at 07/02/2010 12:25:35 AM

Apr 20, 2007

(VMWare)HDDに空きが無くてもshrink成功

中身が少ないのに肥大化してしまったVMWareの仮想ディスクをスリムにする(shrink)するためには、その肥大化した仮想ディスクと同じサイズの空きがHDDに必要だということが、VMWareサイトのページに書いてある。

Shrinking requires free disk space on the host equal to the size of the virtual disk you are shrinking.

しかしながら、先日、割合的にほとんどHDDに空きが無い状態にもかかわらずshrinkに成功したので、諦めずに試してみる価値ありということで報告する。

環境とshrink前の状態は以下の通り。
VMWare: 5.5.3 build-34685 (日本語版)
Host OS: Windows XP Home Edition
Guest OS: Windows 2000 SP4
Virtual disk: 190GB (NTFS, splitted by 2GB, 200GB at max, 115GB used)
  (ホストOSで見ると「現在のサイズ190GB」、ゲストOSで見ると115GB使用中)
Host HDD: 232GB, NTFS, <8GB Free

手順はVMWareのページの通り。
1. ゲストOSでデフラグ
2, ゲストOS終了
3. ホストOSで「仮想マシン設定」画面を開き、「デバイス」のハードディスクを選択して「ディスクの最適化」実行
4, ゲストOS起動
5. コントロールパネルから「VMWare Tools」→「仮想ディスク圧縮」を開き、shrinkするパーティションにチェックを入れて「圧縮の準備」実行
6. 「圧縮しますか?」という感じのダイアログが出るので、OKする

See more ...

Posted at 22:52 in PC一般 | WriteBacks (1)
WriteBacks

> Virtual diskが2GB毎に分割される設定だった うまくいったのは、これが理由だと思いますよ。

Posted by とおりすがり at 10/09/2007 01:01:00 PM

Mar 07, 2007

Mebius MN-340へのFreeBSD再インストール記(3)

MovableTypeが動いたことで、Webサーバとしてすぐに必要な環境はとりあえず揃った。次に、X無しの日本語入力環境を構築したので、その手順を記録する。他に、sambaとPython Infoのインストール、カーネルのオープンファイル数超過対策についても記録する。

●konインストール
デフォルトのコンソールでは日本語(マルチバイト文字、日本語フォント)が使えないので、konを使うことにした。
portsにkon2-14dotとkon2-16dotというのがあったので、両方試したが、kon2-14dotの方が見栄えが良かったので、こちらを採用した。

●jvimインストール
かな漢fepとしてcannaとFreeWnnを使うことに決め、portsのjvim-canna+freewnnをインストールした。

●cannaインストール
上記の手順でjvimをインストールすると、cannaは自動的にインストールされた。
システム起動時にcannaを起動するよう、rc.confに次の行を足した。

canna_enable="YES"

●FreeWnnインストール
FreeWnnは自動的にインストールされなかったので、portsのFreeWnn-serverをインストールした。
システム起動時にjserverを起動するよう、rc.confに次の行を足した。

wnn_enable="YES"

●Emacs(without X)インストール
個人的に欠かせないPython Info(info pythonで見るマニュアル)をmakeしようとしたら、Emacsが必要であることが判明したので、Emacsの日本語環境も作ることにした。
ports/japaneseを見ると、muleにはmule-canna+freewnnがあるのに、emacsにはそれらしい物が無かった。代わりにemacs-emcwsというのがあり、何だろうと思って見てみたら、これがEmacs+Canna+Wnn+Sj3だった。

emacs-emcws/Makefileを見ると、"NO_X11"が定義されているとX無しになりそうだったので、setenv NO_X11してmakeすると、emacs21がXありでmakeされてしまった。こちらはWITHOUT_X11が必要のようだ。

(1) portsのemacs-emcwsディレクトリに移動し、Makefileを編集
  WITH_FREEWNNをYESに変更、WITH_SJ3をNOに変更
(2) 環境変数NO_X11, WITHOUT_X11設定
  setenv NO_X11; setenv WITHOUT_X11
(3) make install

なお、上記手順でインストールした後、日本語入力可能なEmacsを起動するには、シェルから"emacs"でなく"emcws"で起動する必要があるのでご注意。

●python infoインストール
portsのlang/python25を普通にmakeすると、Python Infoがmakeされなかった。
仕方なく、手動でwork/Python-2.5/Doc/infoでmakeすると、エラーが出た。Makefileの依存関係を追っ掛けて編集しながら試していると、gmakeでないと通らないということに気付いた。
それでもなおpython-lib.infoのmakeには失敗した(Python-2.5.tgzのDoc/lib/*.texがおかしいようだ)ので、python-lib.infoだけはlang/python24の下でmakeした。

Infoのインストールは、手動で行った。手順はDoc/info/READMEに記されているが、*.info*を/usr/local/info/にコピーし、python.dirの内容を/usr/local/info/dirにマージすればOKだ。
なお、infoのトップページが/usr/share/infoにあるので、ついここにinfoを加えてしまいそうになるが、/usr/local/infoに加えるのが好ましいので、注意が必要だ。

●sambaインストール
(1) ports/japanese/sambaをインストール
(2) cd /usr/local/etc; cp smb.conf.default smb.conf
(3) smb.confを編集
(4) /etc/rc.confに'samba_enable="YES"'を追加

●kern.maxfilesの変更
"/kernel: kern.maxfiles limit exceeded by uid ..."というエラーメッセージがコンソールに出るようになった。カーネル再構築時にmaxusersを5にしたので、kern.maxfilesが200になっており(tuning(7)によると数千が普通らしい)、長時間サーバーとして動かして色々やってると、簡単に限界に達するようだ。

kern.maxfilesの値は、次のコマンドで見れる。(sysctl(8)参照)

sysctl kern.maxfiles

現在開いてるファイル数は、kern.openfilesという変数名で参照できる。
sysctl kern.openfiles

見た感じ、kern.maxfilesを300にすれば大丈夫のようだったので、/etc/sysctl.confに次の行を追加した。

kern.maxfiles=300

See more ...

Posted at 00:45 in UNIX | WriteBacks (0)
WriteBacks

Feb 09, 2007

(Linux)GRUBのブートフロッピーの作り方

LinuxでGRUBのブートフロッピー(実際はVMWareの仮想フロッピー)を作成したので、その方法を記録しておく。

まず、フロッピーにGRUBをインストールする。
info grubの"Installing GRUB using grub-install"の節を参考に、以下のようにした。
#mke2fs /dev/fd0
#mount -t ext2 /dev/fd0 /mnt/floppy
#grub-install --root-directory=/mnt/floppy '(fd0)'

続けて、grub.confをフロッピーにインストールする。
#cp .../grub/grub.conf /mnt/floppy/boot/grub/

必要に応じて、grub.confを編集する。
以上でumount /mnt/floppyして完了。

See more ...

Posted at 14:29 in UNIX | WriteBacks (0)
WriteBacks

LinuxがVMWareのNICを認識しなければ

VMWareでLinuxを動かすと、ディストリビューションによっては、ドライバが仮想ネットワークアダプタを認識しないことがある。
そういう時は、/etc/sysconfig/network-scripts/ifcfg-eth*に
----------------------
check_link_down() {
return 1;
}
----------------------
を加えると、うまくいくかも知れない。

See more ...

Posted at 13:03 in UNIX | WriteBacks (0)
WriteBacks

Jan 21, 2007

Mebius MN-340へのFreeBSD再インストール記(2)

カーネルをスリム化し、Portsを更新できたので、Webサーバーとして必要なソフトのインストールを始めた。まずはこのWeblogを実現するMovableTypeに必要な環境だ。

●Apacheインストール
新しいバージョンの方が良かろうと思ってapache2.2をインストールしたが、httpd.confがあまりにも複雑だったのと、同時接続クライアント数(旧MaxClients)の設定がわからなかったので、apache1.3に入れ替えた。
(1) ports/www/apache13をインストール
(2) /usr/local/etc/apache/httpd.confをコメントに従って編集
(3) /etc/rc.confに'apache_enable="YES"'を追加してOS再起動
(4) 別PCから'http://(IPアドレス)/'にアクセスして/usr/local/www/data-distが見えることを確認
(5) 'http://(IPアドレス)/cgi-bin/test-cgi'にアクセスしてCGIが正常実行されることを確認

●MySQLインストール
MySQLは(少なくとも現時点でportsがサポートする最新の5.1までは)バージョンが上がる度に結構基本的なDBの機能が追加されているので、新しい方が良いと思われる。
そう思っていたのだが、5.1の新機能に魅力を感じなかったので5.0をインストールしてしまった。
(1) ports/databases/mysql50-serverをインストール
(2) /etc/rcに'mysql_enable="YES"'他必要な設定を加えてOS再起動
(3) 'mysql -e "select version()"'を実行、適切な結果が得られることを確認(今回は5.0.27と出た)

●MovableTypeリストア
MovableType自体は一式をtarで固めてバックアップしたものを展開すれば即動いた。
これまではBerkeleyDBを使っていたので、DBも一緒にリストアされた。

mt-check.cgiを実行すると、Perlが5.005であるということで、Perl 5.6.1以上を強く推奨された。
他に、このWeblogのエントリー作成で必要なHTML::Entities, Image::Magickが無かった。

●Perl 5.6.2インストール
portsにlang/perl5(Perl5.6.2)とlang/perl5.8があり、Perl 5.8のことはよく知らないし、Perl5.6.2で十分だろうと思ったのとで、perl/lang/perl5をインストールした。
その後、下記の要領でPerlの追加モジュールをインストールしていると、最新のportsではImage::Magick、XML::Atom等がPerl5.8を必要とすることが判明したので、5.8に入れ替えた。

●Perl 5.8インストール
ports/lang/perl5.8をインストールした後、ports/graphics/ImageMagickをmakeすると、configureスクリプトでPerlのバージョンが5.005だと診断されてしまい、Image::Magickがインストールされなかった。
/usr/bin/perlが5.005のままで、5.8は/usr/local/bin/perlとしてインストールされており、autoconfでは/usr/bin/perlが優先的に使用されてしまうらしい。
・/usr/bin/perlを/usr/local/bin/perl へのシンボリックリンクにしても駄目だった。
・/usr/bin/perlを/usr/local/bin/perl へのハードリンクにしても駄目だった。
・configureを実行する時のパス順序を/usr/local/bin優先に変更しても駄目だった。
ということでmanやdoc等かなり調べまくって悩んだのだが、たまたま/usr/ports/lang/perl5.8/pkg-messageというファイルが存在することに気付き、開いたらあっさり答えが書いてあった。

use.perl port

とすると、5.8がデフォルトになるらしい。use.perl systemで5.005がデフォルトに戻る。/usr/local/bin/use.perlの中身が何なのかは、疲労により追究する気力が無かった。

●HTML::Entitiesのインストール
Portsにそれらしいのが無かったので、CPANでインストールした。
(1) 'man CPAN'の記述に従い、'perl -MCPAN -e shell'を実行
(2)設定を色々尋ねられるが全てデフォルト設定、FTPサイトは日本国内のを選択
(3)'install HTML::Entities'実行

●Image::Magickのインストール
上記の通りPerlのバージョン認識エラーにより失敗を繰り返したが、それがクリアされたら、ports/graphics/ImageMagickをインストールするだけで完了した。
なお、ports/graphics/ImageMagickのオプションメニュー(初回のmakeまたはmake configで出る)にて"IMAGEMAGICK_PERL"にチェックが入っているのを確認しておくべし。

See more ...

Posted at 23:08 in UNIX | WriteBacks (0)
WriteBacks

Jan 13, 2007

Mebius MN-340へのFreeBSD再インストール記(1)

このサーバーはMebius MN-340(CPU: Pentium 150MHz) + FreeBSD 4.10で構成されていた。たまにCPUのパワー不足を感じる以外は問題なく動いていたが、長年色々なアプリをインストールしては消したりしていたためか、HDDにゴミが溜まり、不自然に空き容量が無くなってしまった。
しかも、おそらくセクタ不良によるHDDの"hardware error"がこれまでに何回か発生して、使用不能な領域が増えている。
そのため、HDDをフォーマットしてFreeBSDを再インストールすることにした。

●最新バージョンを試す
せっかくなので、最新バージョンである6.1をインストールしようと思った。CD-Rが勿体無いので、インストーラーをFD起動してネットワークインストールしようと思って、6.1-RELEASE/floppies/の
boot.flp
kern1.flp
kern2.flp
をダウンロードしてFDにコピーしてPCをFD起動したら、右側にポップな"FreeBSD"のアスキーアートが出るブートメニューでデフォルトのものを選択し、カーネルが起動開始した直後に"page fault"が出て固まってしまった。
FDが悪いのかと思って、6.1-RELEASE-i386-bootonly.iso をCD-Rに焼いてCD起動したが、結果は同じだった。PCIドライバ起動中に出てる感じだ。

以前にもこのPCのFreeBSDを5.xにバージョンアップしようとして、同じことが起こって断念した経緯がある。6.xになって解決してるかもと期待したが、残念だった。
仕方なく、4.xの最終バージョンである4.11をインストールすることにした。

●FreeBSD 4.11インストール
4.11のインストールCDのISOイメージをFreeBSDのミラーサイトからダウンロードしようとしたら、古過ぎるためか、ミラーサイトの無いftp-archiveサーバーに移されていた(なぜか2.2.9だけはftpサーバーに残されていた。2.2.9は現役なのだろうか?)。そのftp-archiveサーバーからのダウンロードが非常に遅いため、通常の2枚分のCD-ROMイメージの取得を諦めて、233Mの4.11-RELEASE-i386-miniinst.isoを2時間かけてダウンロードし、8分でCD-Rに焼いた。

そのCD-ROMにはX11が入っていなかったので、この際、X Window無しのWebサーバーとして構築することにした。
CD-ROMを起動して、Kern-Developerのセットを選択して、特に工夫せずインストールしてFreeBSDを起動したら、PCMCIAのネットワークカードが認識されなかった。dmesgで起動ログを見ると、pcic0(PCMCIAドライバ)は正常に起動していたのに、カードを抜き差ししても反応しなかった。認識失敗の下り調子のBEEP音も出ない。原因がわからなくて、再度インストーラーを起動してKernel configurationにてシリアルポート(IRQ=3-4)とパラレルポート(IRQ=7)のドライバを無効にして、ネットワークインストールする振りしてIRQ=3,7指定でPCMCIAのNICを認識させてみたら、あっさり認識されたので、そのままFreeBSD全体を再インストールした。そうすると、シリアルポート(IRQ=3)を有効にして起動しても、PCMCIAのNICが正常に認識された。

おそらく、rc.confのpccard_*の行がおかしかったのだろう。最終的には

pccard_enable="YES"
pccard_mem="DEFAULT"
pccard_flags="-i 3"

の設定で正常に動いている。

●カーネル再構築
なにぶん低スペックのマシンなので、まずカーネルをスリムにすることにした。

cd /usr/src/sys/i386/conf/
cp GENERIC MINE

として、MINEを編集した。結果はこちら。SCSI関連、PCI NICドライバ、USB関連を全て無効にした。Webサーバーとしての動作を考えると、もっとスリムにできるだろうだが、追求するのは後日にすることにした。
MN-340に浮動少数点演算のコプロもあるようなので、MATH_EMULATIONも無効にしてみた。これを消すのは初挑戦だ。

MINE編集後、

config MINE
cd ../../compile/MINE
make depend
make
make install

として再構築(約2時間)したカーネルをインストールして再起動すると、起動しなかった。この時、MINEのcpuの行を誤って"I386_CPU"としていたため、"Unknown processor type"というエラーが出たのだ。

そこで、/usr/share/doc/の教え通り、カーネル起動前の10カウント中に停止し、

unload
boot kernel.old

としてカーネルを起動し(10カウントより前にkernel.oldと打っても起動するが、正しく起動しないようだ)、
cd /
mv kernel.old kernel.good
mv modules.old modules.good

として、正しく動くカーネルを退避した。

その後、MINEのcpuの行を"I586_CPU"に修正して同じ手順で再構築すると、今度は無事に起動した。
再構築前のカーネルが4.2Mだったのに対し新しいのは1.9M、起動直後のRAM使用量は24Mから21Mに減少した。(カーネル単体のRAM使用量は調べ方がわからなかった)

●Portsのアップデート
4.11のpackagesは当然もはやネット上に存在しないので、各種アプリケーションはportsでインストールするのだが、4.11のportsのままだと、必要とする各ソースコードパッケージのバージョンが古すぎて、やはりネット上に存在しないものが多数ある。従って、まずはportsを最新のものにしなければならない。
portsの更新は、現在はPortsnapとかいう手段が主流のようだが、今回は昔ながらのCVSupで行うことにした。

1. cvsupインストール

cd /usr/ports/net/cvsup-without-gui
make install

 なんと、依存関係により、これだけで12のパッケージがインストールされてしまった。
2. 環境変数の設定
 環境変数SUP_UPDATE, PORTSSUPFILEを設定する。
setenv SUP_UPDATE
setenv PORTSSUPFILE /usr/share/examples/cvsup/ports-supfile

 (本当はports-supfileを別の場所にコピーした方が良い)
3. ports-supfileの編集
 $PORTSSUPFILEで示されるファイルを編集する。特に"*default host="の右側に近所のサーバー名を指定する。
 今回は/usr/share/docs/を参考に(今回はよくお世話になった)
*default host=cvsup4.jp.FreeBSD.org

 とした。
4. CVSup実行
cd /usr/ports
make update

とすると、約3時間で更新が完了した。
5. portupgrade
 cvsupの道連れに大量の古いバージョンのツールがインストールされたので、portupgradeを使用して全てバージョンアップすることにした。
 portupgradeをインストールし(これでまたrubyを含むいくつかのツールが芋づる式にインストールされてしまった)、
portupgrade cvsup-without-gui
を実行すると、無事に全てバージョンアップされた。

portsを更新するだけで20近いパッケージがインストールされてしまうとは、えらいものだ。最初は最新のports.tar.gzをダウンロードした方が良かったのかも知れない。

See more ...

Posted at 13:39 in UNIX | WriteBacks (1)
WriteBacks

FreeBSD 6.x/5.xのインストーラー起動時に--------------------- on pcib0trap12: page fault while in kernel mode...current process = 0 (swapper)---------------------と出て固まる件について色々調べたが、同様のトラブルは結構発生しているようだが、解決したらしい情報は1件も発見できなかった。原因の憶測も多岐に渡り、結構根が深い問題のようだ。大体共通しているのは、おそらくハードウェアが古くてサポート対象外となったのだろう、ということだった。古いIDE HDDはDMAができないのが原因だろう、という意見が散見されたが、ブートメニューの"Safe mode"だとIDEのDMAが無効にされる(カーネル変数hw.ata.ata_dmaが0に設定されるされる)ことが判明し、Safe modeでも同様の現象だったので、外れだ。他に"second disk"で起動するとより多くのカーネルが選択できるので試してみるべし、という怪情報があったが、*-disk2.isoでは起動できなかった。こういうことではなく"second disk"なるものが存在するのだろうか?

Posted by ynomura at 01/15/2007 01:26:51 AM