Re: Perlスクリプトの一行目には何と書くべきなのか - Islands in the byte stream (legacy)
Re: Perlスクリプトの一行目には何と書くべきなのか もしCPAN形式でスクリプトを配布するなら、それは#!/usr/bin/perlないし#!perlとするべきで、env(1)を使うべきではないと思います。 CPAN形式のディストリビューションでは、インストールするスクリプトのshebang行をインストール直前に修正し、正しいパスに書き換えてくれます。ただし、このルーチン*1はいまのところenv(1)を認識してくれません。つまり、env(1)を使った場合、インストールに使用したperlと実際に実行されるperlが一致するとは限りません。perlを一つしかインストールしていないシステムなら、これでも問題なく動きます。しかし最近では、システムにインストールしてあるperlには触らず、アプリケーション用のperlを別途perlbrewなどでインストールしてそちらを使うということもよく行われ
CPAN における Authority の話 - tokuhirom's blog
ざっくりいうと: 他の人にかわりにアップロードしてもらう時は x_authority を設定するとよい CPAN では、共同メンテナ(co-maintainer)を任命するなど、権限まわりでいろいろなことができます。 しかし、この共同メンテナ機能は、基本的にパッケージ単位で管理されていることに注意する必要があります。 得に注意が必要なのは、パッケージの追加時です。新しいパッケージが PAUSE に登録されると、そのパッケージをふくむ dist をアップロードした人が権限をもつことに なってしまいます。 たとえば Teng を例にとると、Teng の primary maintainer は nekokak さんですが、現在は cho45 さんが主にメンテナンスをおこなっています。 ある時、cho45 さんが Teng::Plugin::BeautifulQuery というパッケージを Te
Contextの生成・破棄を任意のタイミングで制御可能にする Scope::Container(仮) - blog.nomadscafe.jp
追記 CPANリリースしました http://search.cpan.org/dist/Scope-Container/ /追記 mod_perl のアプリケーションでは、Apacheモジュールの提供するpnotesを使うとリクエスト毎のデータを簡単に持つことができます。pnotesに入れたデータはリクエストの処理が終了したところで自動的にクリーンアップされます。これを利用したのがリクエストごとにインスタンスを作成破棄できる、Apache::Singleton(::Request)です。 また、pnotesはデータベースの接続の管理にもしばしば使われます。1リクエストを裁いている間だけデータベースとの接続を維持し、リクエストが完了したところで接続を閉じるような処理に利用されています。このようにすることでmod_perlのプロセス数分(数百）の接続がMySQLに常に張られることもなく、また１
おそらくはそれさえも平凡な日々: CPANで意図しない名前空間の取得を防ぐために
だいたいこのへんで教えてもらった話のまとめです。 http://lingr.com/room/perl_jp/archives/2013/04/03 CPANで名前空間を取るのは簡単です。今ならCPANに上げるコードベースの「どこか」に package Hoge; と書けば、CPAN Indexerにインデックスされていとも簡単にHoge名前空間のオーナーになれます。 (執筆時現在Hogeのオーナーはいません) これはlib/以下の.pmファイルやファイル先頭のpackage宣言だけに限った話ではありません。 例えば、example/MyApp.pmとかも対象です。 ちなみに誰がどの名前空間を持っているかは以下を見ることでわかります。 http://www.cpan.org/modules/02packages.details.txt 多くの場合この挙動に困ることはありませんが、以下の様な
本当は難しいCPANモジュールのバージョン特定 - blog.nomadscafe.jp
OrePANを作っていて一番難しいのはディストリビューションからモジュールのパッケージ名とバージョンを抜き出す部分。ExtUtils::MakeMakerやModule::Metadata、PAUSEのソースを参考にして書いているところ。 例えば、Log::Minimalであれば、パッケージを展開して $ tar zxf Log-Minimal-0.04.tar.gz $ cd Log-Minimal-0.04 $ find -name "*.pm" | grep "VERSION" のような処理をします。(実際はperl) これが一筋縄ではいかない作業でかなり苦労している 最初に引っかかったのがcommon::sense。これは*.pmファイルがない。実際にはsense.pm.PLというファイルがあり、実行することでperlのバージョンにあったモジュールを作りだす。 まずこれに対応するた
Perl 5.18 時代における Core module についての捉え方について - tokuhirom's blog
Perl 5.20 で、CPANPLUS とその依存モジュールたちが core distribution から分離されます。 また、5.22 では CGI.pm と Module::Build が分離されそうです。 ここにいたり、Perl 5 の core distribution にはいっている、ということの意味が徐々にかわってきつつあります。 では、現在の状況はなぜおきているのかを考えてみましょう。 configure_requires の普及Perl 5.8.5 あたりの時代では、Module::Build などは core distribution にはいっていないと、つらかったわけですが、configure_requires が普及したことにより、インストーラを CPAN shell で自動的にインストールすることができるようになりました。 これにより Module::Build
Perl5 によるメール送信 - 実践的な Email::Sender の利用方法 - tokuhirom's blog
Perl5 では、E-mail の送信をするためのモジュールが多数 CPAN にアップロードされているが、現在もっともまじめにメンテされていて質がよいのは Email::Sender らしい。 Email::Sender は登場当初はドキュメントもなさすぎるしつかいものにならなかったが、現在ではだいぶマシになっている。Moose 依存が気にならないケースでは、実用としてつかっても問題ないとおもう。 iso-2022-jp の日本語のメールを送るには、以下のようにすればよい。 use 5.12.1; use utf8; use Email::Sender::Simple qw(sendmail); use Email::Simple; use Email::Simple::Creator; use Data::Recursive::Encode; use Encode; # e-mail o
cpan.me - cpan リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
CPANモジュールでサポートしていないOSのTest ReportをNA(Not Available)にする - WebService::Blog->new( user => ’hide_o_55’ )
CPANモジュールでサポートしていないOSのTest ReportをNA(Not Available)にしたい場合はMakefile.PLやBuild.PLで以下のようにする必要があります。 unless ($^O eq "MSWin32" || $^O eq "cygwin") { die "OS unsupported\n"; } CPAN Testersのツールは以下のメッセージを検出した場合に、NAとして扱います。 No support for OS OS unsupported また、Devel::AssertOSを使用することで同様のことが可能です。 See also: CPAN Authors FAQ
Spellunker - Pure perl implementation of Spelling checker. - tokuhirom's blog
https://github.com/tokuhirom/Spellunkerhttps://metacpan.org/release/SpellunkerNowadays, I got trouble by xt/01_spelling.t. Then I wrote a new spelling checker written in perl. Pros. No C compiler required.Dictionaries included in distributionInstallable from CPANReadable code for CPAN AuthorsOptimized for CPAN modulesCons. It's new. Bit unstable.You can use it as testing module like following: use
@yapcasia をフォローしてる人のソーシャルグラフを可視化してみた - Debuginfo
ネットワークって面白いですよね。バラバシの新ネットワーク思考を読んでから、自然科学的好奇心をいつもくすぐる存在です。 で、今週末にGraph::D3というd3.js用のjsonを吐く単純なモジュールをMillaを使ってcpanにアップしたので、Net::Twitterを使ってyapcasiaをフォローしてるの人たちネットワークグラフを描いてみました。(ノードが1000近くなるとforce_directed_graphだとめちゃくちゃになってしまったので、hierarchical_edge_bundlingを使いました） ↑クリックするとグラフを見れます。注)マシンスペックが必要かも^^;; 有名なPerl Mongerな人たちにカーソルを合わせるとグラフが真っ赤になります。彼らはYAPCASIAで影響力があるのが視覚的にわかっておもしろいですね。 Graphvizよりもきれいに書けるのはd
Milla, a Dist::Zilla profile that doesn’t suck (screencast)
Ok, that was a little link bait title. I’ve been a big fan of Module::Install — it automatically figures out the metadata of my module with just all_from, and does the right thing creating META files. Then it bundles itself in inc/ so that if you install from CPAN you don’t need to have Module::Install pre-installed. But not everybody likes it, especially contributors who need to install plugins b
第23回 Module::Build：MakeMakerの後継者を目指して | gihyo.jp
今年もよしなにお願いいたします 連載第18回ではlocal::libの話題を取り上げましたが、今回はそのときにもちらと紹介した、モジュールをインストールするときに利用するいくつかのモジュールについて簡単にまとめてみます。 ExtUtils::MakeMakerが生まれるまで Perlがバージョン3でコンパイル時にユーザ独自のライブラリを組み込んで本体機能を拡張できるようになったとき（1990年）、おそらくもっとも喜んだのがデータベースを使っていたユーザでした。彼らはいそいそと自分の使っていたデータベースのライブラリをPerlに組み込み、それとわかる名前をつけて公開しました。当時の記録によれば、Oracleに対応したOraperlやPostgreSQLに対応したPgperlなど、データベース関連だけで8つないし9つの専用Perlがあったようです[1]。 でも、このアプローチには問題もあ
おそらくはそれさえも平凡な日々: 今週のおーぷんそーす活動と、Dist::MakerのModule::Build対応とか
深夜のテンションで「おりゃっ」とpullreqを送りつける今日この頃、皆様いかがお過ごしでしょうか。 そんな雑なpullreqに対応してくださってる皆様、本当にありがとうございます。 てことで、今週のpullreq活動。 愛用させてもらっているモジュール雛形作成ツール。 Module::Build対応とModule::Buildを使った雛形DefaultMBをpullreqして0.07でshipit してもらいました。 以下のようにすればM::B形式で簡単にモジュールが作成できます。簡単ですね！ % cpanm Dist::Maker # 設定。設定ファイルの位置は ~/.dim/config % dim config --import-from-gitconfig % dim config template.default DefaultMB # 雛形作成 % dim init My::
僕はもうちょっと Module::Install を使った方が良いのではないかと考えている、というお話 - tsucchi の日記 2nd season
僕はもうちょっと Module::Install を使った方が良いのではないかと考えている、というお話 最近ちょっと話題だった、CPANモジュールのパッケージングの歴史 とか、あと twitter とか blog とか色々見てて思ったこと。 「Module::Install って、Plugin があるのがいいとこなんだけど、どのプラグインでどの関数が使えるのか分かんなくてハマるよね」、とか、「他にも罠多いし、その辺考えると、最近だと Module::Build 使った方が良くね？」ってのは、多分正論なんだけど、僕はちょっと違うんでないかな、と思っているという話。 Module::Install の長所は、「プラグイン」と「DSL」と言われることが多いのですが、僕は一番の利点は、「M::I 本体をインストールしなくても対象のモジュールをインストールできること」だと思います。この長所はコアモジ
おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build：MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CPANasium
ついに顕在化しはじめた Exception リスク
CPAN Testers Wiki
Perlゼミ(サンプルコードPerl入門)