nDiki : XS

1999年1月24日 (日)

flex から XS へ、Segmentation fault

Perl から flex の出力した yylex() を呼び出す実験。 まずは簡単な字句解析仕様記述を書いて、flex を通す。 この出力に yylexc2xs と名前をつけたスクリプトを通して XS に変換する。 これは単純に先頭に XS のためのヘッダファイルのインクルードの行を追加し、最後に Perl から yylex を呼ぶためのモジュール定義とコードを追加するだけのもの。

これをコンパイルして Perl から呼び出してみる。 Segmentation fault。 実際には Perl から l2xs_yylex() というCの関数を呼んでそこから flex の出力する yylex() を呼んでいる。 l2xs_yylex() から yylex() を呼ばないようにすると正常終了するので、やはり yylex() か、そこから先でなにかがあるようだ。

入力の問題かと yyin の値を Perl から渡すようにしたり l2xs_yylex() でファイルをオープンしてそれを設定したりしてから yylex() を呼んでも結果は同じ。

flex の出力は shared library にできないのか? Perl + shared library ということでデバッガでどうすればいいのかもわからず。

とりあえず棚上げ。 CPAN から ParseLex-2.05.tar.gz と Parse-Yapp-0.21.tar.gz をとってくる。 Perl 内で済ませられればそれでいいかな。 というかこの2つの出来がよければ自作する必要性もなくなるのだが。

スポンサード リンク
[ 1月24日全て ]

2004年2月19日 (木)

[ Perl ] PDL::PP で C extension を書く

PDLを使ったPerl数値処理プログラムによりインタラクティブ性が求められるようになってきたので、一部をCで書いて高速化する事を検討。 問題は Linux でも Windows + ActivePerl でもすんなり動くかどうか。

.pd ファイルを書く

とりあず PDL::PP のサンプルから sumit 関数あたりを MathEx.pd に書いておく。

Makefile.PLを修正する

Foo::Bar パッケージの中の Foo::Bar::Math の一部を Foo::Bar::MathEx に移して、C extension 化したい。 ということで lib/Foo/Bar/MathEx.pd として、Makefile.PL の各種設定をしてみる。

がどうもうまくいかない。 PDL::PPMakefile.PLサポートは、Makefile.PL と同じ位置に .pd がある事を想定しているようなので、いろいろと小細工をしなければならない。 一方 PerlXS は Foo::Bar のベース名から Bar.so を作る前提になっているようで、これまたパッケージの中の一部のモジュールをどうもXS化しにくい。

Makefile.PLを作る

Perl の ext/SDBM_File を真似て、子 Makefile.PL を使ってみることにした。

 Foo-Bar-x.xx
   |
   +- Makefile.PL
   |
   +- lib
   |    |
   |    +- Foo
   |         |
   |         +- Bar.pm
   |         |
   |         +- Bar
   |              |
   |              +- Math.pm
   |              |
   |              +- MathNoEx.pm
   |              |
   |              ...
   |
   |
   +- blib/...
   |
   +- MathEx
   |    |
   |    +- Makefile.PL
   |    |
   |    +- MathEx.pd
   ...

パッケージディレクトリの下に MathEx ディレクトリを作り、そこに Makefile.PL と MathEx.pd を置く。 Makefile.PL は MathEx.pd 専用になるので、PDL::PP の標準的なものでOKになる。

全体のパッケージング・PPM化・インストール等が面倒にならないかと心配したが、Foo-Bar パッケージ化で perl Makefile.PL、make xxx を実行すれば子Makefile.PLまできちんと面倒をみてくれる。 MathEx 以下でビルドしたものもパッケージの blib に一緒に入れてくれるし(=一緒にインストールできる・PPM化できる)。 逆に make dist の際には子Makefileの方は余計なとりまとめはしないで、親Makefileが一括して tar.gz に入れてくれる。 これはよい。 MathEx.pd もきちんと Foo/Bar/MathEx.so になった。

XSが使えない環境との両対応

XSが使えない環境のために、PerlとPPの両方で関数を書いておく。 XSが使えれば MathEx を、使えなければ MathNoEx.pm を使うように。 表向きのAPIは Foo::Bar::Math とし、ここで AUTOLOAD を使ってどちらか一方を呼び出すようにする。 間接呼び出しにして遅くなるのはいやなので、シンボルテーブルを直接設定する。

 use vars qw($IMPLEMENT_CLASS $AUTOLOAD);
 BEGIN {
   $IMPLEMENT_CLASS = 'Foo::Bar::MathEx';

   eval "use $IMPLEMENT_CLASS";
   if ($@) {
     warn "Can't load $IMPLEMENT_CLASS: $@";
     $IMPLEMENT_CLASS = 'Foo::Bar::MathNoEx';
     eval "use $IMPLEMENT_CLASS";
     die $@ if $@;
   }
 }

 sub AUTOLOAD {
   my $name = $AUTOLOAD;
   $name =~ s/.*://;
   my $implement = $IMPLEMENT_CLASS . '::' .$name;
   no strict "refs";
   *{$name} = \&{$implement}; # ここでシンボルテーブル設定
   return &{$implement}(@_);
 }

最初は、AUTOLOAD の最後の行で die したら、trap してエラーメッセージ中のパッケージ名(Foo::Bar::MathEx や Foo::Bar::MathNoEx)を呼び出された Foo::Bar::Math に置換して die し直すようにしようかと思ったが面倒なのでやめ。

ActivePerl 5.6 + Visual C++ 6

使っているWindows BOX には Visual C++ 6 が入っているので、XSも問題なくビルドでき PDL extension もうまく動いた。

 PPM化までここで済ませば、他のPCにも持っていけるはず。

さて

これでバシバシPPで書けるわけだが、PPがこれまた難解で最初は苦労しそう。

[ 2月19日全て ]

2004年7月20日 (火)

PARActivePerl 5.6.1 build 638 に

昨日 Linux 上で実験してみた PARWindows にも入れてみる。 PDLを使っている関係で ActivePerl は 5.6.1。

インストール

ppm install で入るパッケージは古いので、最新のものを入れておく。 ちょっと手間。

ワンライナーを pp できるところまで動作確認。

モジュール + スクリプトを実行可能形式に

ExtUtils::Makemakerを使ってパッケージ化している開発中のモジュール(スクリプトあり、XS あり)を実行可能形式化してみる。

 perl Makefile.PL
 nmake
 nmake test
 cd blib
 set PERL5LIB=lib;arch (pp の -I オプションが効かなかったので)
 pp -o foo.exe -a lib -a arch -M ... -c  script/foo

Log::Log4perl::Appender::Screen、Jcode::Unicode::NoXS、Unicode::StringGD については依存関係を自動検出できなかったので、それぞれ -M で指定。

できた。動いた。素晴しい。 PDLGD を使っていたのでちょっと不安だったのだがうまく動いて感激。 これでCD-ROMとか USB メモリに入れておいて一発実行とかできる。

[ 7月20日全て ]

2006年12月12日 (火)

PAR::Repositoryビルド済み Perl モジュールをネットワーク配信

実行可能ファイル作成としての PAR

PAR といえば Perl スクリプトを実行可能ファイル(Windows なら EXE 形式ファイル)に変換するモジュールとして有名である。

ちなみに実行可能ファイルを作成する部分はは PAR 0.97 より PAR-Packer パッケージに分けられ、PAR 自体はインストールしやすい pure Perl なパッケージになっている。

PAR モジュールアーカイブからのローダとしての PAR

PAR が提供するもう一つの(こちらが本来はメイン?)機能は、プログラムの実行時に必要な Perl モジュールPAR ファイルと呼ばれる Perl モジュールアーカイブファイルからロードする機能である。 XS モジュールなどもコンパイルすることができるどこかの環境で1度ビルドして PAR ファイルにしておけば、同じアーキテクチャのホスト上でそのまま利用することができる。

PAR リポジトリ

ロードしたい PAR ファイルはファイルパスだけではなく URL でも指定することができ、必要な時にオンデマンドでフェッチさせることができる。 これを使えば Perl プログラムの集中管理可能だ。

PAR 0.951 からは PAR リポジトリというコンセプトが追加され、パッケージ毎に作った PAR ファイルをサーバ上(あるいはローカル)のリポジトリに蓄積してオンデマンドでロードできるようになった。

個別に PAR ファイルを指定する従来の方式に比べてかなり便利そうである。 ということで試用してみた。

まずは

あたりをインストールし準備 OK。

1. PAR リポジトリを作成する

最初に PAR-Repository に含まれている parrepo で。

 parrepo create -r /tmp/PAR

PAR リポジトリファイルの中にはデータベースファイルが作成されるが、これは DBM::Deep というアーキテクチャ非依存のものを使っているので、Linux でも Windows でもどちらからでもアクセス可能である (つまり Linux 上でリポジトリをメンテできるということだ)。

2. Perl パッケージを PAR ファイル化する

次に必要な PAR ファイルを作成する。 作成したいパッケージを展開してビルドし、blib ができている状態で PAR::Dist を使ってパッケージ化する。

 perl Makefile.PL
 make
 make test
 perl -MPAR::Dist -e blib_to_par

例えば ActivePerl*1 上で WWW-Mechanize-1.20 を PAR ファイル化すると

 WWW-Mechanize-1.20-MSWin32-x86-multi-thread-5.8.8.par

というファイルが作成される。

普段から ActivePerl で必要なライブラリは基本的に自前で PPM パッケージ化して、動作確認した上で PPM リポジトリに蓄積するようにしているので、合わせて次の手順でパッケージを作ることになる。

 perl Makefile.PL
 nmake
 nmake test
 perl -MPAR::Dist -e blib_to_par
 make_ppm

*1ここでは Windows 上の

3. PAR リポジトリPAR ファイルを登録する

PAR ファイルができたら parrepo でリポジトリに登録する。

 parrepo inject -r /tmp/PAR -f xxx.par

4. PAR リポジトリ上のライブラリを使用してみる

例えば先ほどの WWW::Mechanize がリポジトリに登録されている状態で

 #!/usr/bin/perl
 use PAR { repository => 'file:///tmp/PAR/' };
 use WWW::Mechanize;
 my $mech = WWW::Mechanize->new;
 $mech->get('http://www.example.com');
 print $mech->content;

というスクリプトを書いて実行すると、PAR リポジトリから WWW::Mechanize がロードされて正しく実行される。

ここでリポジトリを Web サーバアップロードして、repository のところに URL を指定するようにすることもできる。 例えばリポジトリを http://www.example.com/PAR/ に配置したとすると

 #!/usr/bin/perl
 use PAR { repository => 'http://www.example.com/PAR/' };
 use WWW::Mechanize;
 my $mech = WWW::Mechanize->new;
 $mech->get('http://www.example.com');
 print $mech->content;

と書き換えることで、インストールしていない WWW::Mechanize を使用できるようになる。

Perl プログラムを実行形式化する

先ほどの Perl スクリプトを get_top_page.pl という名前で保存して pp で実行可能ファイル化する。

 pp -o get_top_page.exe -M PAR::Repository::Client get_top_page.pl

とすれば get_top_page.exe という実行可能ファイルが作成される。 WWW::Mechanize はオンデマンドで http://www.example.com/PAR/ からフェッチされるので、アップデートが必要な場合は新しい PAR ファイルを作成してリポジトリを更新するだけでよい。 EXE ファイルを作成しなおして利用者に配付しなすといった作業も不要だ。

スクリプトもリポジトリにおく

さらには実行するスクリプトをも PAR リポジトリに置いておくことが可能だ。

例えば WWW-Mechanize に含まれている mech-dump をオンデマンドにフェッチして実行する実行形式ファイルは以下のコマンドで作成できる。

 pp -o mech-dump.exe -M PAR::Repository::Client \
   -e "use PAR { repository => 'http://www.example.com/PAR/', \
                 run => 'mech-dump' }"

まとめ

ActivePerl では PPM があるとはいえ、普通のユーザにちょっとしたプログラムを使ってもらうのに「ActivePerlインストールして、PPM パッケージインストールして、……」というのは手間すぎる。

pp で プログラムに必要なものを全てバンドルした実行形式化ファイルにするという方法ももちろんあるのだが、頻繁にアップデートするようなスクリプトの場合には、起動のための部分だけ pp で作成しておいてあとは PAR リポジトリで集中管理するというのもちょっと魅力的である。

[ 12月12日全て ]

2007年4月7日 (土)

携帯電話(iモード)から Twitter を更新する

Twitter をいろいろ遊んでみて「やはり携帯電話から更新できないと」と思えてきた。

携帯電話からメールを送る事で Twitterアップデートをかけてくれるゲートウェイを設置できれば一番いいのだけれど、そのようなメールアドレスを作る場所が今はない(さすがに会社のサーバはまずい)。

ということでiモードから更新をかけられるように短い CGI プログラムを書くことにした。 CPAN には Net::Twitter という Perl モジュールがあるのだが、JSON::Any (と JSON::XS / JSON / JSON::DWIW / JSON::Syck のどれか)が必要で、ちょっと大げさなので今回は使用は見送り。 普通に CGI.pm と LWP::UserAgent で書いた。

 #!/usr/bin/perl -w

 use 5.005_03;
 use strict;
 use CGI qw(-no_xhtml);
 use Jcode;
 use LWP::UserAgent;

 my $query     = CGI->new;
 my $user_name = $query->param('u');
 my $password  = $query->param('p');
 my $status    = $query->param('s');

 $user_name = '' unless defined $user_name;
 $password  = '' unless defined $password;
 $status    = '' unless defined $status;

 my $message = '';

 if ($user_name ne '' && $password ne '' && $status ne '') {
   my $ua = LWP::UserAgent->new;
   Jcode::convert(\$status, 'utf8', 'sjis');
   $ua->credentials('twitter.com:80', 'Twitter API', $user_name, $password);
   my $request = $ua->post('http://twitter.com/statuses/update.json',
                           {status => $status . ' '});
   if ($request->is_success) {
     $message = '<p>OK</p>';
   }
 }

 print $query->header(-type => 'text/html', -charset => '');
 print '<html><head><title>Twitter update</title></title><body>';
 print '<form method="post" action="twitter">';
 print 'ユーザ名:',   $query->textfield('u'),      '<br>';
 print 'パスワード:', $query->password_field('p'), '<br>';
 print 'ステータス:', $query->textfield('s'),      '<br>';
 print '<input type="submit">';
 print '</form>';
 print $message;
 print '</body></html>';

とりあえずこれで、iモードから送信できることを確認。 パスワードの入力が面倒だけれども、サーバ側に書いておくのも嫌なので毎回送ることにした。FOMA 端末側には定型文として保存しておく以外にいい手はないのかな。

最初うまく送れなくてなんだろうと思ったが、あきやん氏の「Twitterで日本語を入力する方法 (akiyan.com)」の記事にある

  • 全て全角文字で入力して、最後に半角スペースをいれる
  • 半角全角を混在させるときは、半角文字と全角文字の間にスペースをいれる

といった日本語を入力する際の注意点がらみだったようである。 とりあえず CGI プログラムの方で最後に必ずいわゆる半角空白を追加するようにしておいた。

文字数チェックとか Twitter API の返り値チェックとか、改善すべきところはいろいろあるけれど、自分用にはまずこれでいいかな。

気が向いた時に外出先から更新かけます。

[ 4月7日全て ]

2009年8月17日 (月)

今日のさえずり: 限界がきて穴の開いたパンツ靴下は洗濯してからじゃないと処分できない派

2009年08月17日

  • 12:10 限界がきて穴の開いたパンツ靴下は洗濯してからじゃないと処分できない派なんだけれど、みんな使用済みの状態で処分したりしているの? *P3
  • 12:50 今のところ洗濯派2、そのまま捨てる派2。 RT @Naney: 限界がきて穴の開いたパンツ靴下は洗濯してからじゃないと処分できない派なんだけれど、みんな使用済みの状態で処分したりしているの? *P3 *P3
  • 14:07 zakwa がいなくなって以来、久しぶりの社内コーヒーサービス(賞味期限今日まで)。 *P3
  • 14:29 Text::CSV_XS::Encoded 一所懸命探してた。 Text::CSV::Encoded だった。 *P3
  • 16:53 今のところ洗濯派4、そのまま捨てる派4。拮抗している。 RT @Naney: 限界がきて穴の開いたパンツ靴下は洗濯してからじゃないと処分できない派なんだけれど、みんな使用済みの状態で処分したりしているの? *P3 *P3
  • 17:08 歯医者につき退社。 [mb]
  • 17:10 後ろの人に「今帰ったら日焼けするよ」と脅された。 [mb]
  • 18:19 歯医者へ GO。 [mb]
  • 19:07 今日の歯医者終了。インレー詰めて痛む奥歯でしばらく強く噛み続けるプレイを味わった。 [mb]
[ 8月17日全て ]

2010年10月18日 (月)

今日のさえずり: 「東工大は半袖ばかり」は言い過ぎでした

2010年10月18日

[ 10月18日全て ]

2013年5月31日 (金)

グレゴリー ハードテールをミラーレス一眼用ウエストパックに

naney:8901347393

ちょっとした外出の時にはグレゴリーテールランナーに小物を放りこんでいる。見た目は小さいけれどミラーレス一眼の NEX-5N + E 18-55mm F3.5-5.6 OSS SEL1855 も入っちゃうんで重宝している。

しかしながらちょっと長い外出で、さらにスマートフォン用のバッテリ入れておきたかったりなんだりするとさすがにパンパン。ということでもう一回り大きなウエストバッグが欲しくなった。で例によってグレゴリーをチェックしたところハードテール (Hard Tail) というのを発見。2011年夏ぐらいに出た商品らしい。

テールメイトが容量 2.5L に対してハードテールは 4L。一回り上の大きさで丁度良さそげ(ちなみにずっと前に持っていたグレゴリー ランパールーム (Rumper Room) は 14.7L もある化け物だった)。

早速 GREGORY TOKYO STORE に行って商品を確認。形的にも定番ウエストパックのテールメイトXS(3.5L)よりスクエアな感じで好み。ということで店員さんが「残り少ないカラー」といっていたフィギュアエイトを買っちゃうことにした。

 HARD TAIL FIGURE EIGHT GM59575

 VOLUME: 4L
 DIMENSIONs: 16x27x5cm
 WEIGHT: 250g

ランパールームと同様、背面のパッド入りランバーパッドがついているのでちょっと荷物が重くても滑り落ちにくくなっている。

容量的にもやはりテールランナーより余裕がある感じで、もう少しいろいろ入れられる。ただランバーパッドががっしりある分柔軟性がなくテールランナーほど柔軟に大きさが変わってフィットしたりしないので、体感的には 1.5L 増えた感じがあまりしなかった。テールランナーの良さも再認識。

まだ新品なので固い感じなんだけれども、こなれてきたら出し入れももう少ししやすくなるかな。フロントにはアタッチメント用ウェービングがあって何かを留めえおくこともできるし、使い勝手は良さそう。

[ 5月31日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.067936s / load averages: 0.32, 0.39, 0.46
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker