第23回 Module::Build：MakeMakerの後継者を目指して | gihyo.jp
今年もよしなにお願いいたします 連載第18回ではlocal::libの話題を取り上げましたが、今回はそのときにもちらと紹介した、モジュールをインストールするときに利用するいくつかのモジュールについて簡単にまとめてみます。 ExtUtils::MakeMakerが生まれるまで Perlがバージョン3でコンパイル時にユーザ独自のライブラリを組み込んで本体機能を拡張できるようになったとき（1990年）、おそらくもっとも喜んだのがデータベースを使っていたユーザでした。彼らはいそいそと自分の使っていたデータベースのライブラリをPerlに組み込み、それとわかる名前をつけて公開しました。当時の記録によれば、Oracleに対応したOraperlやPostgreSQLに対応したPgperlなど、データベース関連だけで8つないし9つの専用Perlがあったようです[1]。 でも、このアプローチには問題もあ
第31回 encoding：いつまでもjperlから抜け出せない方に | gihyo.jp
いまさら使う人はいないと思っていますが かつて、jperlと呼ばれるものがありました。これは当時まだシングルバイト文字にしか対応していなかったPerl本体にパッチをあてて日本語（など）の2バイト文字をより直感的に扱えるようにしたもので、いまとなっては史料的価値しかありませんが、1990年代にはそれなりに重宝されていましたから、筆者を含めて、お世話になったことのある方も少なからずいることでしょう。 jperlはその後、ライブラリレベルで日本語対応できるようにしたjcode.pl（1992年）や、その流れをくむJcode.pm（1999年）を経て、2000年にリリースされたPerl 5.6からは本家のほうでUnicode対応が始まったことで、その歴史的役割を終え、開発も事実上終了したのですが、困ったことに、それから10年がたったいまなお、jperlを求めたり、勧めたりする動きはやまないようです
第32回 Encode：日本語だけ扱えればよいのではなく | gihyo.jp
一般的には推奨されないencodingプラグマ 前回取り上げたencodingプラグマは、簡単なjperl用のスクリプトを移植したい場合には便利ですが、perlunifaqというPerl付属のマニュアルにははっきり「Don't use it.」と書いてあるくらい、一般的には使えないプラグマと認識されています。 前回も見たように、encodingプラグマが対応しているのは、ソースコードに埋め込まれている文字列やそれに類する正規表現、そして標準入力からのデータを指定された文字コードからPerlの内部表現に変換し、標準出力へ出力する際には内部表現を指定された文字コードに変換することだけです。ほかのファイル入出力部分や、コマンドラインから受け取った引数、標準エラー出力などの変換は行わないので、ちょっと凝ったことをしようと思うと、結局「外から入ってきたものはデコード、外に出すものはエンコード」という
2011年のPerl | gihyo.jp
あけましておめでとうございます。今回は新春特別企画ということで、2010年のPerl界を振り返りつつ、2011年のPerl界がどうなっていくかを、予定と期待を織りまぜながら見ていきましょう。 Perl 5.14 2010年のYAPC::Asiaでジェシー・ヴィンセント（Jesse Vincent）氏が紹介されていたように、Perl 5は現在、2011年4月に予定されているPerl 5.14のリリースに向けて最後の仕上げをしているところです。Perl 5.14は2010年の開発成果をまとめた定期リリースなのでPerlの根幹をゆるがす大きな仕様変更はありませんが、Perl本体、コアモジュールともに細かなバグがいくつも修正されているほか、内部的にはさまざまな最適化が行われています。 一例を紹介しますと、Perl 5.14ではkeysやeach、あるいはpushやshiftのような、配列やハッシュ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
