PerlでWebAppの開発に必要なN個のこと - Islands in the byte stream (legacy)
あるプログラミング言語で実際にWebAppを開発できるようになるまで、何が必要だろうか。言語仕様の習得は終えているとしよう。おそらく、最低限以下のような知識が必要だと思われる。とりあえずPerlについて知っていることを書いた。 パッケージマネージャ まずライブラリの管理。モジュールをインストールし、可能であればバージョンを固定し、適切にロードする機能が必要だ。Perlの場合は cpanm というCPANクライアントでライブラリをインストールする。バージョンの固定とライブラリパスの設定は carton で行う。 https://github.com/miyagawa/cpanminus https://github.com/miyagawa/carton アプリケーションサーバ Webサーバへのインターフェイスとしては、PSGIという仕様がある。PSGIに準拠したツールキットとしてPlack
Released Plack::Middleware::DevFavicon - Islands in the byte stream (legacy)
開発環境と本番環境で favicon を変える というのに感動したのでPlack middlewareでやってみました。 単に favicon.ico ないし favicon.png という名前にマッチしたらグレースケールにして返すというだけの代物ですが、enable_ifで簡単に導入できるのが楽かなと。 使い方は以下のとおり。P::M::Staticの前にenableしてください。 builder { enable_if { $ENV{PLACK_ENV} eq 'development' } 'DevFavicon'; enable 'Static', path => qr{/favicon\.(?:ico|png)$}, root => $path_to_assets; ...; }; https://github.com/gfx/Plack-Middleware-DevFavico
JSX minifierの圧縮性能 - Islands in the byte stream (legacy)
JSX compilerのソースコードで検証してみました*1。 Mode Size(KiB) Ratio original 1507 1.00 JSX minifier 277 0.18 Closure Compiler/D 602 0.40 Closure Compiler/A 301 0.20 対象にしたソースコードがJSXから変換したJSというやや特殊な状況ですが、Closure CompilerのADVANCED_OPTIMIZATIONSよりもサイズが小さくなりました。また、ADVANCED_OPTIMIZATIONSと異なりJSX minifier*2はコードを破壊する圧縮は一切行わないので、圧縮したらコードが動かなくなるということが非常に起こりにくくなっています。しかしそれでも、JSXの豊富な型情報を使って圧縮すればADVANCED_OPTIMIZATIONSよりもサイズを小
RubyのMethod#source_locationをPerlで - Islands in the byte stream (legacy)
[追記]Cside先生がUNIVERSAL::source_location_forとしてリリースしておりますのでcpanmでご利用ください！[/追記] asakusa.rbでsource_locationというメソッドを教えてもらいました。 それによれば、Rubyのメソッドオブジェクト(UnbountMethod, Method, Procなど)にはsource_locationというメソッドがあり、そのメソッドが定義されたファイル名と行番号を取得することができます。これはクラス階層が複雑なときにデバッグに役立ちそうです。 Perlでも標準ライブラリに含まれるBモジュールを使って同様のことができるのでやってみました。 Ruby版： #!/usr/bin/env ruby2 require 'fileutils'; p FileUtils.method(:pwd).source_locat
JSでi++と++iどっちが速い？ - Islands in the byte stream (legacy)
結論から言うと、現在のChromeのみをターゲットにして最適化するという特殊なケースを除き*1、どちらでも変わらないといえます。 [追記] 指摘を受けて再考してみました。そもそもjsperfでは初期化コード（今回はdataなどの初期化に使用）は一度しか走らないにもかかわらず、このベンチマークコードではdataの中身を書き換えています。これがスコアに影響を与えていたようです。 data[index] = data[index] * 2をdata[index] = index * c にした結果はChromeでも安定して双方有意差なしという結果になりました。 http://jsperf.com/postfix-or-pretfix-increment/4 JSのベンチマークの難しさを思い知りました。 [/追記] http://jsperf.com/prefix-or-postfix-incre
quick sortよりも高速でmerge sortのように安定しているソートアルゴリズムtim sort [勘違い] - Islands in the byte stream
<追記>ベンチマークプログラムに誤りがありました。ソート済のシーケンスに対してソートを掛けていました。ご指摘ありがとうございます＞ak氏 そんな夢のようなソートアルゴリズムがあるのかというと、あるらしいんです。それがtim sortと呼ばれるアルゴリズムです。 画期的（？）なソートアルゴリズム「Sleep Sort」：濃縮還元オレンジニュース｜gihyo.jp … 技術評論社 このあたりで拾ってきたネタですね。 merge sortを改良したアルゴリズムで、安定*1しており、しかも実行速度にも優れているとか。アルゴリズムの性能の評価は済んでいるらしく、CPythonやJDK7には既に導入済みのようですね。 ならば当然Perlのソートも…と考えるわけですが、まず評価のためにJavaのソースをC++にそのまま移植してみました。それがこれ（いちおうテスト済）： https://github.co
![quick sortよりも高速でmerge sortのように安定しているソートアルゴリズムtim sort [勘違い] - Islands in the byte stream](https://cdn-ak-scissors.b.st-hatena.com/image/square/f9103c273a45047a455a47c2322a4ec545cd77ee/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127143682567%2F17680117127143702106%2F1558185862)
なぜ bytes::length($str) はよくないのか - Islands in the byte stream (legacy)
bytes.pm will be deprecated in Perl 5.12の話の続きです。 なぜ bytes::length()*1を使うべきでないか。それは、一般論としてコードの意味がおかしく、また実際にバグの温床になるからです。 まず、入力されたバイト列をデコードして内部表現にし、出力の際にエンコードをするというモデルでは、文字列もその他のデータ型もまったく変わりません。たとえば、{ "foo" : 42 }というJSONのデータをデコードして{ foo => 42 }というPerlの内部表現にするプログラムを考てみます。この際、内部表現のサイズを直接得る関数を提供するのは妥当といえるでしょうか。 #!perl use strict; use warnings; use JSON qw(encode_json decode_json); my $input = <<'JSON';
Perlのメモリリークを見つける方法 - Islands in the byte stream (legacy)
Perlではメモリリーク検出ツールがいくつか開発されているので、top(1)の結果を眺めるよりそういうツールを使うほうが楽である。 さて、メモリリークが発生しているとき、その可能性としてはだいたい以下の4つが挙げられる。 Perlレベルでの循環参照 グローバル変数に値をどんどん足しているとき*1 XSレベルでリファレンスカウントの管理ミス XSレベルでmalloc()したメモリの管理ミス この1-3についてはすべてPerlインタプリタ内の出来事であり、Test::LeakTraceを使って検出できる。4を検出するのは難しいが、Test::Valgrindが役に立つ。 Test::LeakTraceのSYNOPSISは歴史的経緯によりごちゃごちゃしているが、テストで使うべき関数はno_leaks_ok()とleaks_cmp_ok()だけである。 たとえば、以下のようにして使う*2。 #!p
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
XSでメモリークを避けるたった一つの方法 - Islands in the byte stream (legacy)
XSでメモリリークを避ける基本原則は、それほど難しくない。すなわち、作ったSV(およびSVファミリ)はすぐsv_2mortal()するのである。mortalなSVはスコープ*1から抜けるときに解放されるため、メモリリークは起こらない。つまり、あるスコープ内で新しく作ったすべてのSVをmortalな状態にしておくということだ。 この原則のもとでコードを書くと、誤ってリファレンスカウントを増やさなかったケースでは警告が頻繁に起きる。しかし、少なくともメモリリークは起こらない*2。メモリリークの検出は難しいので、警告が出るのは福音であろう。 もちろんこれは原則で、メモリリークにまつわることで覚えなければならないことは決して少なくない。 たとえば、XSUBの戻り値をSV*にするとき、sv_2mortal(RETVAL)してはいけない。これはPerlの仕様ではなくxsubppが勝手にsv_2mort
Mooseの速度が遅いという議論のまとめと感想 - Islands in the byte stream (legacy)
Adam Kennedy (ADAMK)が「Array::CompareでMooseを使わないようにしてくれ」とRTでチケットを作成したことがきっかけとなり，Mooseの速度について議論が起きています。以下ラフなまとめ。 #49270: Remove the use of Moose - RT Array::CompareではMooseを使わないでほしい。Mooseを使いつづけるならばコマンドラインアプリケーションでは使うに堪えないし，PadreでもArray::Compare依存をなくすつもりだ。 Moose or No Moose - Perl Hacks (Array::Compareの作者ブログ) 最近いくつかのモジュールをMoose化しはじめたのだが，「Mooseを使うな」と言われてしまった。Mooseは楽なので使い続けたいが，どうしたものか。 Re: Moose Or No M
Multi-threaded perl vs. Single-threaded perl - Islands in the byte stream (legacy)
perl5 ithread についての個人的な見解。そして Coro について。(tokuhirom)より ithreads を有効にしてコンパイルするだけで perl インタープリタの速度が低下する[要出典] これをちょうど試そうと思っていたところなのだった。ナイスタイミング。 結論からいえば，シングルスレッドなperlはマルチスレッドなperlよりロード時間・実行時間共に10%ほど高速である。 以下詳細を記す。 まず，perlバイナリを2つ用意する。バージョンはパッチなしの5.10.0で，ビルド/実行環境はLinux 2.6.18-92.el5pae, gcc 4.3.2 20081007 (Red Hat 4.3.2-7)である。 sperl (single-threaded perl): $ ./Configure -des -Doptimize=-O3 -Dprefix=~/sp
XSで共有文字列を活用する - Islands in the byte stream (legacy)
Perl 5.8以降には共有文字列というメカニズムがあり，非常に限定的ながら，うまく使用するとメモリと速度の双方を節約できる。 基本的な使い方： SV* sv = newSVpvn_share(pv, len, hash); SV* sv = newSVpvs_share("..."); これでsvの文字列部分がインタプリタ全体で共有されるため，同じ文字列を複数個生成してもmalloc(3)は一度で済む。 実際には，共有文字列SVの生成速度そのものは通常の文字列SVよりも遅いことがある。しかし，共有文字列の真価は，ハッシュキーとして使用する際に発揮される。 ハッシュからキーを検索する際にはキーとなる文字列の照合*1を行わなければならないが，共有文字列はポインタ値がインタプリタを通して等しいので，文字列の照合は行わなくてすむ。また，共有化文字列SVは内部にハッシュ値*2を持っているので，ハッ
Re: XSの勉強を始めるためのエントリーポイントは？ - Islands in the byte stream (legacy)
Re: XSの勉強を始めるためのエントリーポイントは？ あまり参考にならないかもしれませんが，私がXSを勉強するにあたっては，CPANのモジュールのソースコードを読むより実際に書いてみるのが一番だと思います。ただし，何か特定の目的があって，そのために関係がありそうなコードを探して読む，ということは非常によくあります。 以下，思いついたことを適当に並べてみます。 自分でコードを書いてみて初めて分かることが少なくない 学ぶのに適した理想的なコードは，そう簡単には見つからない 古い書き方やおかしな書き方をしているコードも大量にあるので，そういうコードをフィルタリングするためにも，いろいろな作者のコードを読んだほうがいい 多くのコードの中から理想的な部分を抜き出して，それを身につけていく 目的とまったく関係ないコードから閃きを得ることも多い perlのソースコードをすぐ参照できるようにしておくのは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
