YappoLogs: perlbrew best practice
perlbrew best practice perlbrew には $ perlbrew upgrade-perlというのが実装されてるのがあまりにも有名ですが、これは現在使ってる環境の perl を、そのマイナーバージョンの中で一番新しいバージョンにアップグレードしてくれるんです。 perl-5.16.1 を使っていたら perl-5.16.3 に perl-5.14.2 を使っていたら perl-5.14.4 に。という具合ですね。 同じマイナーバージョンの Perl では XS バイナリの互換性とか保証されているので、すでにインストールされているモジュールはそのまま利用できる状態になっています。 だがしかし $ perlbrew install perl-5.16.2して作った環境を upgrade-perl すると 5.16.3 が入ってるのに perl-5.16.2 って名前が
perlbrewを使うにあたっていろいろな小細工をした件 - （ひ）メモ
最近perlbrewを使っています。で、いろいろ小細工をしたので問題点とその解決方法のまとめです。 補足すると、深遠な理由とかマリファナ海峡より深い事情とかがなければ、バッチ用、shebang用に(↓で書いてる)appperl的なラッパーを用意するだけでいけるんじゃないかと思います。 問題点 perlbrewのサイトを見るとビールがのみたくなる http://perlbrew.pl/ perlbrewedなperlの実行方法 対話シェル上で スクリプトのshebang (#!) cronで実行する場合 サーバーワイドな共通の@INC perlbrewedなperlの実行方法 perlbrewedなperlをどう実行するか、3つの局面にわけて考えます。 対話シェル上で 基本、~/.bashrcで $PERLBREW_ROOT/etc/bashrcを読めばOK。 なのですが、(深淵なる理由があ
rebase for perlbrew Perl on Cygwin
Cygwin で perlbrew 環境の Perl を使うときの、関連する DLL を rebase するシェルスクリプトです。 https://github.com/yunh/brewedperlrebase Cygwin には rebaseall や perlrebase がありますが、perlbrew でインストールした Perl の rebase までは面倒を見てくれません。brewedperlrebase (長い…)は perlbrew 環境用の perlrebase です。 どういうこと？ Cygwin は Windows 上に Linux 風の環境を提供するもので、様々な GNU ツールや UNIX 的な機能を利用できるようになります。Windows と UNIX 系 OS のプロセスモデルの最も大きな相違は自プロセスのコピーを生成する fork の有無です。 Cygwin
perlbrewなperlで共通のパスを@INCに入れたい、もしくはperl実行時にごにょごにょしたい話 - （ひ）メモ
perlbrewでインストールしたperlたちの@INCは$PERLBREW_ROOT配下のディレクトリになります。おかげで互いに影響せずにモジュールを入れられるわけですが、システム全体で共通のモジュールも読ませたい局面もあります。 PERL5LIB(でパスを指定)やPERL5OPT(で-Mlib=/path/to)でもできますが、perl -MOrenoConf とした場合はまだ環境変数が評価される前なのでCan't locateと怒られてしまいます。 Ubuntuのsystem perlは /etc/perl が @INC に入っています。(確かGentooのもこんな感じだったと思います) $ perl -V ... @INC: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl
perlbrewとextlibなアプリのcronとかdaemontools - As a Futurist...
perl は system perl じゃなくて perlbrew で入れて、アプリで必要な CPAN モジュールは全てアプリのディレクトリ下の extlib というディレクトリにインストールする方式は個人的にはいい感じだよなぁと思いつつ、cron とか daemontools がいつもどうやるのが正解なのか分からず困ってた。 またセットアップする機会があったので色々考えた結果、こんな感じなら割とすっきりした感じになった。 env このファイルがキモで、アプリのディレクトリに移動しつつ、いい感じに perl とか PATH とか@INC を設定して、渡されたコマンドを実行してくれる。 # perl -v This is perl, v5.8.8 built for x86_64-linux-thread-multi # ./env perl -v This is perl 5, versi
$GREP_OPTIONSが原因でperlのビルドが失敗した件 - 目の前に僕らの道がある
perl-5.14.2を使いたいなと思い、何気なくperlbrew経由でインストールしようとしたら、なにやらビルドに失敗してしまいました。 % perlbrew install perl-5.14.2 # ... 中略 # Bのビルドに失敗している模様 Running Makefile.PL in ext/B ../../miniperl -I../../lib Makefile.PL INSTALLDIRS=perl INSTALLMAN1DIR=none INSTALLMAN3DIR=none PERL_CORE=1 LIBPERL_A=libperl.a Can't locate ExtUtils/Constant.pm in @INC (@INC contains: /home/masasuzu/perl5/perlbrew/build/perl-5.14.2/cpan/AutoL
perl のリリースサイクルと perlbrew の共存 - punitan (a.k.a. punytan) のメモ
perl のリリースサイクルが短くなったこの頃、みなさまいかがお過ごしでしょうか。 リリースサイクル短期化による影響 perlbrew を使ってリリース毎にバージョンを切り替えたりしていると、意外と面倒に感じるのがインストール済みのモジュール類を別バージョンに移行することではないでしょうか？ さらに頻繁にリリースされるとなると、移行するのが面倒ですね。 移行時にやるべき事 移行時には、 既存のバージョンにインストールされているモジュール一覧の抽出 新バージョンのインストール 既存のバージョンにインストールされていたモジュールを新バージョンでインストール 結構手間がかかります。 そこで こんな bash script を ~/.bashrc などに追記しておくと楽に移行できる tips をお届けします。 ちなみに、最新の perlbrew 0.25 からはエラーが起きた際には exit 1;
each()は遅い上に微妙な問題も起きやすい - Islands in the byte stream (legacy)
特別な条件がないかぎり、each()は使うべきではありません。代わりにkeys()/values()を使うべきです。その理由は2つあります。 each()は遅い each()でハッシュ全体をループするのは遅いです。これは、keys()/values()がその内部の値をそのまま参照する*1のに対し、each()は代入しないとその値を使えないからです。 ベンチマーク： #!perl use strict; use warnings; use Benchmark qw(cmpthese); my %hash = map { $_ => $_ } ( 1 .. 10000 ); cmpthese -1, { each_k => sub { while(my $key = each %hash) { } }, each_kv => sub { while(my($key, $value) = eac
Perlbrew
perlbrew is an admin-free perl installation management tool. The latest version is 0.98, read the release note: Release 0.98. For a quick installation, do this: \curl -L https://install.perlbrew.pl | bash Check the document of Installation for more descriptions and options. Quickstart After installing perlbrew itself, now it is time to install some versions of perl To install the latest stable rel
say no to system perl - システム標準Perlを使わないススメ - D-6 [相変わらず根無し]
say no to system perl - システム標準Perlを使わないススメ 2011年4月30日 10:06 D | ブログ記事のURL | コメント(0) | トラックバック(0) LinuxやMac OS Xを使っていれば、大抵の場合/usr/bin/perl などの位置にPerlが入っていますが・・・これらを使うのはやめたほうがいい、というのが段々定説になりつつあります。 厳密に言うと、別に簡単なスクリプトを書くのにシステム標準Perlを使うのは問題ないのだけれども、CPANからモジュールをインストールするつもりならシステム標準Perlを使わないほうがいいでしょう、という事ですね。 自分としてはシステムPerlを使わない理由はふたつある。 ひとつはシステムPerlはそれに依存するものがあるため、それに変更を加えると何かが壊れることがあること。例えばついうっかりモジュールのバ
Cygwin環境にperlbrewを導入した - 空繰再繰
perlbrewで複数のversionのperlを使う 今まではCygwinのperlを使ってたんですが、Cygwinのperlに当てられたpatchのせいなのか、 Mooseが謎のエラー吐いて使えなかったり、DateTimeが何故か機能しないということもあって散々だったので、 思い切ってオリジナルのPerlを導入するために、perlbrewを使ってみることにしました。 というわけで今日はその作業ログ。 0. 参考にしたページ 今回、 perlbrew + cpanminus + local::lib で環境構築 - Webtech Walker という記事を参考に作業を進めました。 ちなみに上記の記事はよくまとまっているので、僕の記事よりそっち見に行ったほうがいいかもしれません。 1. perlbrewの導入 $ cd ~/tmp $ crul -LO -k http://xrl.us/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Reini Urban - Re: broke my perlbrewed perl with rebase