All slide content and descriptions are owned by their creators.
All slide content and descriptions are owned by their creators.
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build:MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
NAME Smart::Options - smart command line options processor SYNOPSIS use Smart::Options; my $argv = Smart::Options->new->argv; if ($argv->{rif} - 5 * $argv->{xup} > 7.138) { say 'Buy more fiffiwobbles'; } else { say 'Sell the xupptumblers'; } # $ ./example.pl --rif=55 --xup=9.52 # Buy more fiffiwobbles # # $ ./example.pl --rif 12 --xup 8.1 # Sell the xupptumblers DESCRIPTION Smart::Options is a lib
ここ何ヶ月かの間、Perl界隈ではやれlocal::libだcpanminusだperlbrewだと、既存環境に手を入れずにローカルなモジュール環境を構築するという系の話が多くなってきてるような気がします。 local::lib はpixiv2rssをサクラ鯖上で動かす時に使ってみました。 perlbrew は環境をごっそり切り替える系なので、今のところ使うアテがない. で、残りのcpanminusですが、この間からApp::cpanminusをインストールしてちょこちょこ使ってみてます。(cpanminusはApp::cpanminus以外に githubからstandalone版を持ってくるとか wget http://cpanmin.us/ | perl するとか色々あるみたい) 以下はその雑感です。 スピードに関しては、余計な事をしていない分やっぱり CPAN や CPANPLUS
gistなどで公開されているPerlスクリプトを実行する際、モジュールが足りないことがよくあります。そういう場合はCan't locate Foo.pm ...というエラーメッセージを見ながらモジュールをインストールするわけですが、決まりきった作業にうんざりしたので自動的にそれをするモジュールを書きました*1。 https://github.com/gfx/p5-lib-xi `perl -Mlib::xi script.pl`とするだけで、足りないモジュールをcpanmで適当にインストールしてくれます。 -Mlib::xi=extlibとすれば既存の環境を壊すことなくlocal::lib的にextlib/にインストールして実行できますし、-Mlib::xi=-L,extlib,-qなどとしてcpanmにオプションを渡すこともできます。 これで退屈なインストール作業をしなくてすむはずです。
追記:なーんだ、やっぱりありました。 cpan -a を使えばいいらしい。 id:hiboma ありがとうございました。 何台かのサーバを扱っていると、サーバによってインストール済みのモジュールのバージョンが違ったり、インストールされてなかったりしてよく困ります。デプロイしてからエラーになって気づいたりするので心臓に悪いです。 どうしたものかと考えて、パッケージ名とバージョン番号のリストだけテキストファイルに書き出しておいて、デイリーで更新するようにすれば最低限の世代管理?にはなるかな、と考えました。 先人の成果にあやかろうと CPAN を探したのですが、どうも望み通りのものが見つからない。 id:tomyhero に教えてもらった Pod::ProjectDocs はブラウザで見るにはとても便利ですが、肝心のパッケージ名が JS オブジェクトとして書かれていて、 Perl から扱うのがち
NAME Cache::Memcached::Fast - Perl client for memcached, in C language SYNOPSIS use Cache::Memcached::Fast; my $memd = Cache::Memcached::Fast->new({ servers => [ { address => 'localhost:11211', weight => 2.5 }, '192.168.254.2:11211', { address => '/path/to/unix.sock', noreply => 1 } ], namespace => 'my:', connect_timeout => 0.2, io_timeout => 0.5, close_on_error => 1, compress_threshold => 100_000
「使っちゃいけない標準モジュール」*1の反響を見ていると、baseが非奨励ということに驚かれた方が少なくありませんでした。そこで、baseについて補足します。 まずbase.pmのドキュメントの最初の文は以下のようになっています。 Unless you are using the fields pragma, consider this module discouraged in favor of the lighter-weight parent. (拙訳: fieldsプラグマを使用しているのでないかぎり、このモジュールは勧められない。かわりに軽量なparent.pmを使う方がよい。) fieldsプラグマは、ハッシュリファレンスのキーを固定したオブジェクトを作成するための機能ですが、あまり一般的ではないためここでは解説しません。特に理由がない限り、ここは素直に忠告に従った方がいいでし
Perlでは、言語仕様的にはSwitch文はありませんが、Switchモジュールを使用することで実現が可能です。 use Switch; switch ($val) { case 1 { print "number 1" } case "a" { print "string a" } case [1..10,42] { print "number in list" } case (@array) { print "number in list" } case /\w+/ { print "pattern" } case qr/\w+/ { print "pattern" } case (%hash) { print "entry in hash" } case (\%hash) { print "entry in hash" } case (\&sub) { print "arg to s
NAME Unicode::Japanese - Convert encoding of japanese text SYNOPSIS use Unicode::Japanese; use Unicode::Japanese qw(unijp); # convert utf8 -> sjis print Unicode::Japanese->new($str)->sjis; print unijp($str)->sjis; # same as above. # convert sjis -> utf8 print Unicode::Japanese->new($str,'sjis')->get; # convert sjis (imode_EMOJI) -> utf8 print Unicode::Japanese->new($str,'sjis-imode')->get; # conve
仕事でperlを触ることになったのでとりえずperlbrewとcpanmを入れてみた。 下準備 とりあえずホームディレクトリにbinを作ってパスに追加する。 $ mkdir -p ~/bin $ export PATH=$HOME/bin:$PATH # ~/.zshrc等にも追加 $ cd ~/bin perlbrewを入れる ホームディレクトリ以下で複数バージョンのperlを管理できる。/usr以下はあまり汚したくないので導入。 perlbrewはデフォルトだと~/.perlbrewに設定ファイルを、~/perl5以下にインストールしたperlを入れてくる。Finderをひらいてperl5が出てくるのも邪魔なので、ここではPERLBREW_ROOTを指定して~/.perlbrewに統一している。もしかしたら悪影響があるかもしれないけど、その時はやり直す。 $ curl -LO http
当サイトのblogのエントリーで検索ワードが多いのはCPANなんですがこの古い記事はperl5.6時代に書いた記事(多分10年近く前だと思う)で今時のperl使いにお勧めできるものではありません。 2010年2月にあの miyagawa さんが書いた cpanminus が非常に素晴らしいので CPAN::shell を捨てて App-cpanminus を積極的に利用しましょう。 と言うことでcpanに関連して新しい記事を書いてみました。 CPAN::shell の欠点 設定が面倒 動作が遅い(cpanmと比較して) 多くのメモリが必要(制約のきついレンタルサーバで使うのは無理) 依存するモジュールが多い 基本root権限が必要 cpanm の利点 一枚岩のプログラムで可搬性に優れる 高速で小メモリでも動作可能 pluginで拡張できる local::lib と組み合わせるとユーザーラン
NAME Text::MicroTemplate - Micro template engine with Perl5 language SYNOPSIS use Text::MicroTemplate qw(:all); # compile template, and render $renderer = build_mt('hello, <?= $_[0] ?>'); $html = $renderer->('John')->as_string; # or in one line $html = render_mt('hello, <?= $_[0] ?>', 'John')->as_string; # complex form $mt = Text::MicroTemplate->new( template => 'hello, <?= $query->param('user') ?
2007年04月19日15:00 カテゴリLightweight Languages perl - Regexp::Assembleのススメ というわけで、Regexp::Assembleのご紹介。 PERL HACKS(日本語版) [英語版] odz buffer - それ Regexp::Assembleん?ループ云々を抜きにして、こういうのは Regexp::Assemble の出番じゃないの? すでにPerl Hackers御用達のモジュールとなっていますが、まだ知らない方もいらっしゃるかも知れないので。 何をするモジュールか、といえば、以下を見れば一目瞭然でしょう。 Regexp::Assemble - Assemble multiple Regular Expressions into a single RE - search.cpan.org use Regexp::Asse
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く