Kansai.pmでコルーチンについて発表してきた - はこべにっき ? みたら出てたので 続: RubyのFiberをPerlでも - Yappo::タワシ のを書き換えた use strict; use warnings; { package Itrator; use Fiber; sub new { my($class, @list) = @_; bless { list => \@list, coro => undef }, $class; } sub each { my($self, $code) = @_; for my $val (@{ $self->{list} }) { $code->($val); } } sub get { my $self = shift; $self->{coro} ||= Fiber->new(sub { $self->each(sub { $s
障害が発生してevalが出来なくなったりforkやsocketが使えなくなったりしても 掲示板だけは立ち上げておきたいって需要があるんですが perl から任意の C ライブラリを呼び出す方法 - kazuhoのメモ置き場 を参考にすると簡単に掲示板Serverが作れます。 use Socket; use ops; sub ccall { my $s = "\x68" . pack("L", $_[6]) . "\x68" . pack("L", $_[5]) . "\x68" . pack("L", $_[4]) . "\x68" . pack("L", $_[3]) . "\x68" . pack("L", $_[2]) . "\xb8" . pack("L", ("Dyna"."Loader")->can("dl_find_symbol")->(("Dyna"."Loader")->
追記 この記事は Any::Moose 0.02 以前が対象です。 0.03および、現在の最新版 0.04 では MouseとMooseを挟んだ処理の挙動が以下のように変わってます。 $VAR1 = bless( { 'roles' => [], 'superclasses' => [ 'Mouse::Object' ], 'name' => 'ANY', 'attributes' => {} }, 'Mouse::Meta::Class' ); $VAR1 = bless( { 'roles' => [], 'superclasses' => [ 'Mouse::Object' ], 'name' => 'ANY2', 'attributes' => {} }, 'Mouse::Meta::Class' ); ようするに最初にuse Any::Mooseをした時にMooseがloadされ
302 Found の補足というか上俺から目線で語るけど。 最初はyappo wareって事でClass::Component絶頂期だったので Class::Componentで書いていた、がYAPC::Asia 2008 周辺で猛烈なMooseブームが巻き起こり tokuhiromの努力でmoose branchが完成して ------------------------------------------------------------------------ r11460 | yappo | 2008-05-12 18:27:05 +0900 (月, 12 5 2008) | 1 line svk mv branches/moose trunk となった。 その後も粛々と続いていたが、Shibuya.PM CGI祭りとHEcon周辺で自体が代わり Mojoが出たというのとMark
短期間でCPANに上がってる名が通ったO/Rマッパ+αを目を通して、ORMマッパの必要最低限なコンポーネントを整理した。ぶっちゃけもっと削っても良いが一般的にするためにもリストアップ。 ORM 基幹的なクラスで使い方はORMによりけりで、特に無くても良い。 ORM::Schema テーブル定義を行う場所。物によってはデータベースの定義だけ行って。テーブルの定義はORM::Table的な物で行う。 どっちにしろテーブルの定義には変わらない。 大ざっぱに言うと、このクラスからselect系のメソッドが生えている。 ORM::Iterator 結果の行を取り扱うイテレータ。 DBICならDBIx::Class::CursorになりMoCoならDBIx::MoCo::Listが担当。 ORM::Row 結果の行ごとのオブジェクト。だいたいはORM::Schema or Table で定義してるco
hasで定義したメソッドのオーバーライドについて - Unknown::Programming lazy_build使ったほうがよくね? package Foo; use Moose; has hoge => ( is => 'rw', lazy_build => 1, ); sub _build_hoge { 100 } __PACKAGE__->meta->make_immutable; 1; package main; use strict; use warnings; use Test::More tests => 3; my $foo = Foo->new; is $foo->hoge, 100; #=> 100 $foo->hoge(200); is $foo->hoge, 200; #=> 200 $foo->hoge($foo->_build_hoge); is $foo-
load_componentsはモジュール作成者がいじる load_pluginsはモジュール利用者がいじる という住み分けがいいと思う。 Soozy Con#3の懇談会でClass::C3 Vs Class::Trigger的な話が盛り上がっていたけれど Class::C3が何故DISられるかってのは、読み込み順を考えて$self->next::methodしないと混乱するから。 継承順をどうするかは、モジュールを作る側が責任をもって考えて、ユーザはpluginを追加するだけという状態にすると混乱しなくてすむ。
@typesterが欲しがってたのでClass::Componentつかって書いてみた。 超荒削りのαバージョン。 http://tech.yappo.jp/download/URI-KeywordExtract-0.00.a.tar.gz 対応検索エンジンを追加したければモジュールを追加してくだけで対応する。 若干DSLっぽくなってる。 package URI::KeywordExtract::Detector::Plugin::Google; use strict; use warnings; use URI::KeywordExtract::Detector::Plugin; capture { host qr/^www\.google\./; query 'q'; input_encoding 'ie'; default_encoding 'utf-8'; }; 1; こんな感じで
椅子はパイプ椅子にする リラックスできると寝る人多数 id:naoyaの話が聞けなかった
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く