web-based Perl editor/interpreter/everything だそうです。 これがおもしろいのは、ブラウザで実行できるとこで、これ Perlito5 つかってるみたいですね。 Perlito5 ってのは https://github.com/fglock/Perlito のことで、なんか Perl5 を JS に変換してくれたりするやつです。直也さんとは関係ないです。
いろいろ方法があるとおもうのですが、以下のようなシェルスクリプトですませるのはどうでしょうか? #!/bin/bash function kill_children { # jobs -l | perl -ne 'print "kill $1\n" if /^\S+?\s+(\d+)/' | sh; pkill -P $$; wait; } trap "kill_children" EXIT HOSTS="192.168.1.1 192.168.1.2" for host in $HOSTS do ssh $host tail -F /service/foo/log/main/current & done wait ちょっと箇条書きで解説すると以下のようなことをおこなっています。 & でバックグラウンドジョブをはしらせるwait でそれらの終了を待つtrap 〜 EXIT は atexit
http://www.ibm.com/developerworks/jp/opensource/library/os-createcompilerllvm1/ 最初なのでとりあえず↑の記事を基本なぞってますが、わかりやすく解説をいれています。 llvm であそぶには、まあいろいろな方法がありますが、わかりやすく大きくわけると以下の4ステップです。 llvm IR の動的生成llvm IRの最適化llvm IRの JIT コンパイルllvm IRのネイティブコードへの変換それぞれのフェーズごとに分離して動作させることができるので、創りたいところだけつくればいいのです。 とりあえず基本となる llvm IR の動的生成をおこなってみます。 とりあえずなにもしない main 関数をつくりましょう。 #include "llvm/LLVMContext.h" #include "llvm/Modu
3つのツールをためすhelloworld.c はこちら。 #include <stdio.h> int main( ) { printf("Hello World!\n"); }llvmアセンブリを生成! $ llvm-gcc -S -emit-llvm helloworld.c helloworld.s ができてた。 ; ModuleID = 'helloworld.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-apple-darwin11.4" @.str
yacc や lex をつかっていても「なんかよくわからんけどうごく」という状態になりがちだったり、グローバル変数にまみれたりしがちだが、re2c + lemon だとそのへんがすっきりする。 レキサを以下のようにかく。yyfill を自前でかかなければいけないのがちょっと面倒だが、このようなクラスを手軽にかけるのはやはり便利である。flex ではこうはいかないのだ。 #ifndef CALC_SCANNER_H_ #define CALC_SCANNER_H_ #include <stdio.h> #include <string.h> #include <string> #include <sstream> #include <vector> #include <iostream> #include <fstream> #include "scanner.def.h" #include
node.js というか npm で依存されているライブラリの上位10個ぐらいがどういうものがはいっているのかをまとめます! 具体的には serach.npmjs.org の Most depends on にのっているリストに註釈をつけただけです! http://search.npmjs.org/ 1位 underscore.js 392個http://search.npmjs.org/#/underscore クライアントサイド JS で人気のたかいユーティリティーライブラリの underscore.js が堂々の第1位。 クライアントサイドでつかってるからそのままつかってる人が多いのかな、とおもっています。
(この記事は Node.js アドベントカレンダー不参加記事です) チャットサーバー的な使い方とか意外とみんな興味なくて、普通のウェブアプリケーションなどをかく、という用途にちょっと node.js がつかえたらいいのにな、とおもっている人がおおいようにかんじています。Node.js が人気なのは、v8 をうまくパッケージングしているのが node.js ぐらいで、そして v8 をうまくパッケージングするのが結構めんどくさいから、というところが大きいのです。ぶっちゃけ node.js が〜 とさわいでる人のうち8割は I/O multiplexing だからとかそういう理由で支持しているわけではなかったりするのです(偏見)。 さて、普通の web application のようなものを書こうとしたときに Node.js って基本シングルスレッドだし、なんかうっかり重い処理したときにどうした
UNIVERSAL::require$module->require() or die $@ ってかけるのが cool という話ではあるのだが、UNIVERSAL をつかうのに抵抗があるかもしれない。 そして、Module::Load にたいする優位性はとくにないので、最近はあまりつかってない。 Class::Load上記2つにくらべると、機能がおおい。これは Moose から派生したパッケージで、Moose の is_class_loaded 相当の機能もそなえている。 Moose 由来ということで、%INC の中にはいっていなくても、package がすでにつかわれていれば、ファイルをよみにいかないという点がすぐれている。具体的には package Foo; sub bar { } package main; use Class::Load qw/load_class/; load_c
ちょっとした RPC サーバーを C/C++ でかきたいな、なんてケースはままあるわけですが、そんなときに便利なライブラリがあったので紹介します。 KyotoTycoon をつかうと、TSVRPC over HTTP な RPC サーバーが超簡単にかけて便利だった。libkyototycoon は GPL だけど、それが問題にならない場合なら、とてもいいとおもう。商用ライセンスかえるならそれもいいとおもう。 RPC サーバーとしては他にもいくつか実装があるんだけど、HTTP の上で実装されているから、デバッグが容易だったりとか、直接 telnet ではなしたりとか tcpdump できたりして、いろいろ便利なので、よいとおもう。 SConstruct でビルドルールをかいてから e = Environment() e.Program('ktechoserver', ['ktechoserv
http://github.com/typester/shipit-step-uploadgithub CPAN モジュールのアップロードは ShipIt をつかうと楽なことがしられていますが、CPAN にあげたくないモジュールなどのアップロード場所としては、リポジトリに github をつかっているなら、github が最適でしょう。 で、CPAN にアップするのとおなじような感覚で github にあげるには、typester 先生の ShipIt::Step::UploadGithub をつかうとよいです。 cpanm-github typester/net-github-upload-perl cpanm-github typester/shipit-step-uploadgithubとかやってインストールすればいいとおもいます(cpanm-github は toktools には
http://search.cpan.org/dist/Cache-KyotoTycoon/ KyotoTycoon の Perl 用クライアントライブラリをだしました。 straight forwardsimpleless dependenciesstabilityといったところを重視してつくってあります。 TSVRPC::Client も同梱してあり、基本的にこれを利用してアクセスするようになっています。KT 仕様の TSVRPC を採用するアプリが他にもでるようなら、別 dist にわけます。今は管理の都合上、一つの dist で配布した方が楽なのでそうしています。わけてほしい人がいたらいってください。 Cache::KyotoTycoon は HTTP based protocol を採用していますので、HTTP client library を使う必要がありましたが、ここでは W
http://blog.nomadscafe.jp/2010/09/apachestartservers-minmaxspareservers-maxclients.html 僕はプロのサーバー管理者じゃないけど(いや、うそかも。サーバー管理でお金をもらってたこともなくはないので。でも専業じゃないし)、単に、たとえば、アクセスが集中したときとかに fork(2) が発行されまくって重くなるので、最初っからたちあげとけや、という理由で Min=Max 派ですね。 あとまあ httpd がつかえるメモリの量がどんぐらいってのはあらかじめ決めてあるはずなんで、Min によせてケチる意味がないよねーという。 MinSpareServers!=MaxSpareServers にするのって昭和の風習なんじゃないかなっておもってる。 という駄文。
chdirのときもエラー処理は必須ですな〜自分で使うスクリプトだからええ加減な書き方してた〜反省 #ubuntu #perl http://twitter.com/mukumaru/status/20694618336 perl5.10.1 以後では autodie.pm が標準添付されているので、それを利用するとよい。 % perl -E 'use autodie; chdir "/foo"' Can't chdir('/foo'): No such file or directory at -e line 1こんなかんじ。use strict; use warnings; につづけて use autodie; と書くだけ。 使い捨てスクリプトでは use autodie; しておくと、いちいち組み込み関数のエラー処理かかなくていいので便利。
5.6以前現状、CPAN モジュールにおいて5.6系に対するサポートは、toolchain 系をのぞいてほとんどおこなわれていません。 そもそも 5.6 系は誰もメンテしていないので、5.6 をコンパイルするのがまずむずかしいですw で、レガシーシステムにおいてはまだのこるとおもいますが、新規にえらぶ必要はありませんね。あたりまえながら。 5.8系5.8系は非常に安定しておりまして、一番安定しているのはたしかです。バグなどが含まれている可能性がいちばん低いかとおもいます。 5.8系を新規のシステムで利用する場合には 5.8.9 をつかうのがよろしいでしょう。 5.10系5.10.0 にはわりと致命的なメモリリークやSEGVをひきおこすバグがありますので、つかわない方がいいです。 5.10系をつかう場合にはかならず 5.10.1 以後をご利用ください。 5.10系以後を現在新規に採用するメリ
HTTP::Lite依存すくないのがうり。速度重視じゃないし、機能もすくない。インターフェイスも、LWP にくらべるとナマナマしいかんじ。 CPAN module をいれたくなくてしょうがない場合にのみつかうべき。LWP の存在が保証されていないような環境に配布したい場合に bundle して配布するとかが主用途。 (実際に HTTP::Lite は cpanminus に bundle されている) LWPデファクトスタンダード。連鯖でもたいがいはインストール済だし、とりあえず LWP つかっておくべき。 どれつかうか迷ってる人はとりあえず LWP つかっておけばよい。 WWW::Curl速度がクリティカルな場合には WWW::Curl つかうとよいんだけど、相当数のリクエストをなげるよほど大規模なクローラでもないかぎりは、LWP で十分。 どうしてもどうにもならないときにだけつかうよう
一般的な OSX 環境および Linux 環境における、モダンな Perl 開発環境の構築方法についてまとめてみたよ。 perlbrew のインストールperlbrew をつかうことにより、簡単に最新版の Perl5 を利用することができるようになる。 perlbrew をいれる。% curl -L http://xrl.us/perlbrew | perl - install % ~/perl5/perlbrew/bin/perlbrew init ~/.bashrc (または ~/.zshrc)に source ~/perl5/perlbrew/etc/bashrc を追記。あたらしいシェルをたちあげる。最新版の perl をインストールする。% perlbrew install perl-5.12.1 % perlbrew switch perl-5.12.1 ここまできたら、she
http://mxcl.github.com/homebrew/ 昨日 mac mini を購入しまして、「さて、mac ports いれなきゃなあ。でも mac ports での環境構築って時間かかるし、CPU パワーもくうし、電気代かかるしエコじゃないし」とかおもっていたところ、そういえば hsbt さんが homebrew ってのをオススメしてたなーとおもって、いれてみたところ、非常に快適。 mac ports は、システムにもともとはいっている perl とか ruby とかもいちいちコンパイルするので、序盤の環境構築が非常に時間がかかるのが難点です。 しかし homebrew は、system にもともとはいっているものはそのままつかうので、初動がはやい。自分の場合、macbook の調子がわるくって、mac mini にかいかえたので、すぐにでもつかいはじめたかったので、非常に
開発版の Perl 5.13.2 がリリースされたが、5.13.2 の目玉はなんといっても package NAMESPACE BLOCK 構文だろう。 use 5.13.2; use warnings; package Point { use Moose; has 'x' => (is => 'rw', isa => 'Int'); has 'y' => (is => 'rw', isa => 'Int'); __PACKAGE__->meta->make_immutable; no Moose; }; のように、パッケージを宣言することができるようになった。 この構文は非常に大きい変化をもたらす。 1 ファイルに複数のクラスを書くことが苦でなくなる。package NAME BOCK 構文を利用する場合、BLOCK の中はインデントすることになるため、複数パッケージを1つのファイルにか
HTML::TreeBuilder の ->lookup だの ->find だのを覚えるのは、学習の効率がよくない。つぶしがきかないので、もっと一般的な CSS Selector や XPath などを覚えて、それをつかった方がお得であるといえる。 HTML::TreeBuilder で XPath を利用するには、HTML::TreeBuilder::XPath をインストールすればよく、これは pure perl なので容易に利用できる。 my $tree = HTML::TreeBuilder::XPath->new; $tree->parse($content); my @items = $tree->findnodes(q{//*[@id='topicsfb']//li}); print $_->as_text."\n" for @items; とすればよい。 XPath はむ
または、Pros と Cons をまちがえて書いてしまうような人でもできる英文バグレポートの方法。 まあ小手先のノウハウだけど、俺はこうやってるよ、という話。 ともかく再現可能なテストケースをかく再現可能なテストケースを書けば、コミュニケーションコストを大幅に削減することが可能。これは日本人同士の場合でもそうだし、プログラマにとっては必須の技能の一つであるから、是非身につけて実践するべき。 マルチスレッドに起因するものなど、再現可能なテストコードがかきづらいものはともかく、それ以外であれば、再現テストコードを書くべき。 再現テストコードを書けない場合、そもそも自分がバグの原因を把握できていない場合がおおいので、そんな状況でなれていない言語によるコミュニケーションをとるのは困難。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く