Perl
アクセス記録[推移 / PV内訳(過去1日 / 過去1週間) / 外部アクセス元 (昨日 / 過去1週間) / ログイン論客足跡]
| 私書() / / | 評価( /) 投票 /共: / | ファン登録 // | DB構築() | ブログ [書く] |
|---|
1. 2013/01/01 「Perl > Image > Magickのインストール」 [この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]拍手:1個 VERSION=6.8.4-6; wget http://www.imagemagick.org/download/ImageMagick-$VERSION.tar.gz; tar xvfz ImageMagick-$VERSION.tar.gz; cd ImageMagick-$VERSION; # for mod_perl and apache with worker mode make clean;; # マルチスレッド環境で安定稼働させる為disable指定 ./configure --disable-openmp --disable-opencl --enable-shared --with-perl; make; make install; cd ..;
2. 2012/05/13 「Perl > Perlのソースからのインストール手順」 [この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)] 1. バイナリーの用意まで 2. モジュール群の為に事前に必要なライブラリ 3. モジュールの事前用意 4. システムへの反映 1. バイナリーの用意まで
これしか使わないのなら
yumで更新されないように vi /etc/yum.conf して exclude=*perl* を追加 2. モジュール群の為に事前に必要なライブラリ
3. モジュールの事前用意 installで反映すると、版が上がってモジュールがなくてエラーとなってしまうので、installする前にモジュールを入れる。 perl -e shell -MCPAN を打ってから
後はサイト特有のperlモジュールをインストール 自分の場合は /tmp/perl$VER/perl install.pl で基本は全部入るしくみにしてある。 その他 Image::Magickのインストール http://sakuhindb.com/pj/6_B4C9CDFDBFCDA4B5A4F3/20130101.html 4. システムへの反映 cd /tmp/perl$VER; make install cd .. strip /usr/local/bin/perl 後は /usr/local/bin/perl に来てからではないと正常に入れられないモジュールをインストールする。 自分の場合には ・BerkeleyDB + (BDB::Wrapper) ・皆声関連
3. 2010/02/02 「Perl > 文字コード > Encode.pmが対応してない文字コード変換への対応」 [この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)] 1. 機種依存文字対応モジュールEncode::EUCJPMSを使っても発生する文字化け 2. 対応方法(自分で改変) 3. その他別の道対応もあるわけだけど 1. 機種依存文字対応モジュールEncode::EUCJPMSを使っても発生する文字化け 『﨑』『鄧』『髙』といった文字は、「EUC-JPから」の他文字コードへの変換は、Encode.pmを使ってもEncode::EUCJPMSを使っても、本日現在の最新版では文字化けして壊れてしまう。 Encode::EUCJPMS(ダウンロード元)はMS WindowsのEUC-JPの機種依存文字対応用のモジュールだが、そっちでもEUC-JPからその文字の変換は上手くいかない。 2. 対応方法(自分で改変) これはEncode::EUCJPMSを使って対応する場合には Encode-EUCJPMS-0.07/ucm/eucJP-ms.ucm を自分で修正してインストールする事で対応出来る。 以下差分。 行頭の「<」が追加、「>」が削除。 平たく言えば UCS2の文字コード EUC-JPの文字コード という並びで並んでいるが、その対応がマズい行を書き換えている。
注意: 書き換えはEUCの文字コードの方で合致させて行う。 PC版がEUC-JPで携帯版がShift_JISといったように文字コード変換をしていて、perl + Encode.pm系を使っても文字コード変換をしている方は、こういう対応をしてみると良いと思います。 Hey! Say! JUMPのメンバーの一人の髙木雄也君でこの問題にはまったので、今更ながらソースと文字コードの対応を眺めてみて対応してみました。 3. その他別の道対応もあるわけだけど 勿論文字コードの変換自体がトラブルの元、ということで、一番文字対応種が多いUTF-8で統一してしまい文字コード変換とおさらば、というのもありな選択肢だと思います。 こちらのサイトは ・携帯版でShift_JISしかサポートしていない携帯&パケット代節約の為にどうせShift_JISにするのだから、そのスーパーセットとなるUTF8は回避する ・日本語1文字に3バイト使うより2バイトにしておきたい(ネットワーク帯域とディスク容量節約&速度の為) ので、EUC-JPをPC版では使い、携帯版はShift_JISにしていますが、世の中の多くのところはそこらへんはもう気にしないでUTF-8、というところも多くなってきています。 文字コードがUTF8のHPの比率は年々高まってきていて、今だと約50%に達しているそうです。 http://googleblog.blogspot.com/2010/01/unicode-nearing-50-of-web.html  勿論UTF8でしか文字コード表せられない言語や、他文字コードを使うメリットが有る/無しによって状況は違うので、日本語だとどうかは分かりませんが、ブログがMTとかの系譜であるところが多いことも有り多くはUTF8なので、日本でもUTF8のHPの比率はかなり高まっているでしょうね。
4. 2009/12/03 「Perl > 正規表現 > gesxオプション v.s. while文」 [この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]
e=正規表現の置換部分をプログラムとして実行 s=改行で切らずに処理 x=コメント可能に といった正規表現の処理は
とりわけ条件によってループの途中で抜けたい場合には、抜ける処理が使えるwhile文を使いたくなるでしょう。 geオプションを使った正規表現では、元々ループ文ではないというのがあるからでしょうが、lastで抜けることは出来ませんし、それを関数の中に入れてreturnしてもgotoで抜けてもそうした途中抜け記述をすると処理がされていないことになってしまうので。 但し、 $a=~ s{...}{...}gesx; に比べ while($a=~ s!...!!s){...} は凄く処理時間が増します。 場合によっては途中でlastしてループを抜ける事で短縮出来る時間よりもより遙かに多くの時間をその処理の仕方で消費してしまうことになります。 ...という罠に近頃はまりました。 正規表現の実行し直しのコストがwhile文だともろに大きく掛かってきて、またそのコストがかなり大きいということでしょう（gesxでやるとそのやり直しコストが省かれる）。 なので、可能な限りwhile文で処理するより、gesxオプションで1つの正規表現内で処理をする事を優先するという基準を、正規表現の当てはめでは持つようにした方が良いでしょう。 結果的に同じことをしていても処理コストは随分変わります。 eオプションは余り使ったことが無い方が多いかも知れませんが、単なる置換だけでなくプログラミングも内部出来るようになり、正規表現の枠を超えた処理が可能になるので、使ったことが無い方はトライされてみる事をお勧め致します。 勿論、上記のようにwhile文で代替して結果的に同じ事＋αをすることが可能ですが、処理コストがwhile文より遙かに安いので、そうした処理をする時のFirst Choiceになります。
5. 2009/11/11 「Perl > 文字コード > jocode.pl, Jcode.pm, Encode.pmのパフォーマンス比較/一番速いのはどれ?」 [この書込みのみ表示(記事URL紹介用) / 編集 / 削除 / トラバ送信 / 共有分類に追加(タグ付け)]拍手:1個 1. Perlの文字コード変換モジュールのパフォーマンス比較をしてみようと思ったきっかけ 2. 比較テスト結果 3. パフォーマンス比較テスト結果からの結論 4. 各モジュールのパフォーマンス比較プログラム 1. Perlの文字コード変換モジュールのパフォーマンス比較をしてみようと思ったきっかけ ちょっと貧弱な環境でやってみたら、Jcodeの呼び出しの処理のところでOut of memoryでプログラムが落ちてしまうということがあった。 そこで、この際Encode.pmへの乗り換えを検討したのですが、結局Out of memoryになることには変わりなかった。 しかし、ちょっとでもパフォーマンス等が改善するのならば、Encode.pmに切替えておこうと思った。 とりあえず検索してみたところ 「jcode.plが最速でした」 というかんじのレポートが検索結果の上の方に見つかり拝見させて頂いたのですが、その結論と理由に納得感が得られなかったので（書いている方も他の人ももっと処理がかかると思っている処理が速い/しかしその理由がない）、自分でパフォーマンス比較するプログラムを作ってみて検証してみることにしました。 結論から言うと、こちらでのベンチマーク結果だと、そっちの結論の「jcode.pl最強伝説」とは違い「Encodeモジュールが最強」となっています。 何故かなと思ってそっちのサイトのベンチマークプログラムを見てみましたが、そちらのプログラムではjcode.plの呼び出し方が変換しているつもりが実は変換していない為、実際には正常処理しないまま次から次の処理へと計測されていただけのようでした。 処理が異常に速いと書かれているjcode.plの型グロブの処理のところを
これは、型グロブでの変換には
もしかして本当にjcode.plが最速なのか...と期待したのでちょっと残念でもありますが、一般的に想定されるであろう妥当な結論にはなりました。 jcode系列で最新版のEncodeが最速というのはソフトの進化の仕方として正しいということで、この結果はEncode.pmを使っていく上で安心出来る結果なのではないかと思います。 2. 比較テスト結果 条件
EUC-JP→Shift_JISの文字コード変換(携帯版への対応でよく使う変換)
全角文字を半角文字に変換(携帯版への対応でよく使う変換)
UTF8→EUC-JPへの変換（外部サイトのAPI対応でよく使う変換）
3. パフォーマンス比較テスト結果からの結論 EUC→Shift_JISに変換する処理でEncodeはJcodeの1.31倍速、jcode.plに比べると1.07倍速 UTF8→EUC-JPに変換する処理でEncodeはJcodeの1.33倍速 全角→半角に変換する処理でEncode::JP::H2ZはJcode.pmの8.4倍速、jcode.plに比べると11.2倍速 全パターンでEncode.pmが最善のパフォーマンスなので、迷わずEncode(Encode::EUCJPMS), Encode::JP::H2Zを選んで良いようです。 とりわけ全角文字を半角文字に変換する処理のパフォーマンス向上が著しいので、そこの処理に旧来のモジュールが文字コード変換なみの時間がかかっていることを考えると、携帯用に全角文字を半角にしたり、検索の為に文字コードを全角に統一したりする時に、大きなパフォーマンス向上が得られそうです。 なお、プログラムだけで処理出来るEUC-JP→Shift_JISより対応表が必要なUTF8→EUC-JPの方が7倍近く速いというのはちょっと予想外だったので、暇があったら後でどうしてそうなっちゃっているのか理由を調べてみようかなと思いました。 4. 各モジュールのパフォーマンス比較プログラム ご自分の環境でも試してみて下さい。 使ったことがない方には文字コード操作の実例として参考になるかもしれません。 jcode.plのダウンロードはこちらから 他は su - でrootになってから perl -MCPAN -e shell と打って、そこで install $MODULE_NAME でインストール出来ます。
実行結果例
=>古記事 |
|