2011/12/01(木)[Perl5] 騙されたなぁorz
2017/10/12 4:44
use IO::Socket; unlink "/tmp/mysock"; $server = IO::Socket::UNIX->new(LocalAddr => "/tmp/mysock", Type => SOCK_DGRAM, Listen => 5 ) or die $@; $client = IO::Socket::UNIX->new(PeerAddr => "/tmp/mysock", Type => SOCK_DGRAM, Timeout => 10 ) or die $@;しかし、はっきり言って騙されました。 見かけ上は起動するけれど、実際はソケットファイルが作成されないです。 これが、現行で正しい例:
use IO::Socket my $socket_path = '/tmp/wibble'; unlink($socket_path); my $server = IO::Socket::UNIX->new( Type => SOCK_STREAM, Local => $socket_path, Listen => 5 ) or die("Can't create server socket: $!\n"); my $sock = $server->accept() or die("Can't accept connection: $!\n"); my $client = IO::Socket::UNIX->new( Type => SOCK_STREAM, Peer => $socket_path, ) or die("Can't connect to server: $!\n");LocalAddr ではなく Local 、 PeerAddr ではなく、Peer です。
今更ながら気付いたのですが、Perl CookBook 第一版 は、2001年刊行の本でした。
Perl 4 から Perl 5 に移行して間もない頃で、確かにハッシュパラメータ名などは違っていたかも・・・です。
2011/10/02(日)PDFJ は perl5.12 では動作しない模様
2017/10/12 4:40
日本人による日本語の解説などあって重宝 ← 英語判らない者にとって重要
していた訳だが、perl 5.10 用にパッチあてても駄目ぽい。
どこかで無限ループになっているようで、いつまでたっても処理が終わりません。
世の中は PDFJ よりは、PDF::API2 を使わせたいらしいが、どれも定型フォーマットを別途PDF にて作成し、それに差し込みする形態の事例ばかりで、適用したいシステムでは全く参考にできない。。
項目数にあわせて罫線を動的に引く形ですが、定型フォーマット方式では、これが出来ないというわけです。
かといって、日本語の説明があまり無くて、結局使い方がよく判らずという状況。
ぢゃあ、PDFJ を改造すれば? という話になるのでしょうが、そういう時間取れないというわけで。。orz
どうにかしたいですが、どうしようも出来ないので、PDF 出力できないのを我慢してもらうしか・・・
〔追記 2012/02/02〕
このあとすぐに気づいて、無限ループに対処する内容として、 「Safe に対するパッチ」というものを入れましたが、これは Safe 2.27 に対するもので、最新は 2.29 になっており 、このバージョンにおいては、対処されており、パッチは必要ないです。
ですが、無限ループしなくなっただけで、今度は、不明なエラーを吐かれる状況。
原因を追いかける時間は全く取れないので、ほったらかし状態になっていますorz
2011/09/27(火)perl CPAN ExtUtils-MakeMaker のインストール時ハングアップ
2017/10/12 4:38
同じ環境による同じ現象のバグ報告(#70232)が上がってはいます。
https://rt.cpan.org/Public/Bug/Display.html?id=70232
英語がダメダメなσ(^^) はこういう場に出れないのだが。。orz
--- ここから
Manifying blib/man3/ExtUtils::MM_Any.3 MSTROUT/ExtUtils-MakeMaker-6.59.tar.gz /usr/bin/make -- OK Running make test PERL_DL_NONLAZY=1 /usr/local/bin/perl "-Iblib/arch" "-Iblib/lib" "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib','blib/arch')" t/*.t t/00compile.t ............. ok t/arch_check.t ............ ok t/backwards.t ............. ok t/basic.t ................. ok t/build_man.t ............. ok t/cd.t .................... ok t/config.t ................ ok t/dir_target.t ............ ok t/FIRST_MAKEFILE.t ........ ok t/fix_libs.t .............. ok t/fixin.t ................. ok t/hints.t ................. ok t/INST.t .................. ok t/INST_PREFIX.t ........... ok t/INSTALL_BASE.t .......... 1/20--- ここまで
t/INSTALL_BASE.t のところで、こんな感じでハングアップし、crtl+C でテストを中断する羽目になります。
このモジュールが 6.58 になったときからの現象で、perl のバージョンは 5.12 でも 5.14 でもこの現象は発生。現在の公開バージョンは 6.59 ですが、一向に解決されていません。
とりあえず、当方は、 force install ... で凌いでいます。
2011/09/12(月)携帯向け音声ストリーミングファイルの形式
2017/10/12 4:36
docomo
3gpファイル
AAC LC モノラル ビットレート=22kbps サンプルレート=16kbps
ファイルの最大サイズ 10Mbyte
au
3g2ファイル
AAC LC モノラル ビットレート=22kbps サンプルレート=16kbps
ファイルの最大サイズ 2Mbyte
softbank
3gpファイル
AMR-NB モノラル ビットレート= 8kbps サンプルレート=8kbps
ファイルの最大サイズ 300kbyte
上記でないと、どうも上手く再生できないことが多い。
一番制限が厳しいのはソフトバンクで、このパラメータ以外では再生がまともに出来ない。
音質も極限まで落とす形になります。
特にファイルサイズが致命的で、約4分以上の音声ストリーミングは不可能です。
その点、docomo は 10Mbyte で AAR LC であれば、ステレオで 128kbps でも再生できます。但し、10MByte の制限に注意が必要です。
2011/01/17(月)CGI に使う言語
2017/10/12 4:16
日本では、
PHP , Java というのがもてはやされている模様。
ですが、これはちょっとガラパゴス化している可能性が最近出てきた感ありです。
元々当方は、メンテナンスの点で PHP は否定的、 Java は無駄に高性能なハードウェアを要求する点で否定的。
当方的に推奨できるのは Perl です。あと、ruby。C言語や C++,C# もありです。
こう書くと、嘲笑の対象なんですな、、しかしです。嘲笑するような奴らは、はっきり言ってITゼネコンに洗脳されています。
Java は、ITゼネコンのひとつである、富士通が主に推進し、ごり押ししました。
それが実体。資金力に任せてAPIを提供してきたので、そこそこ使えるのでしょう。
しかし、無駄にハードウェアを高性能化することを要求されるため、ハードウェアの売り上げに繋がる、という商業的な理由があります。
だから、当方はそういうのは承服できないのです。
PHP は、バージョンアップの度に、過去の互換性検証を強要されます。
これだけでもうメンテナンス性がダメダメです。
作りっぱなしなら問題ないけれど、ここでも「互換性検証」という名目で売り上げ増や維持に繋がる、という商業的理由があります。
PHP もITゼネコンが半ばごり押しした言語。
一方で、Perl は10年前に作成したものであっても、セキュリティ問題等さえなければ、何の問題もなく、さくっと動作するのです。こういうのを「後方互換性が優れている」と評価します。Windows で言えば、 Windows 95 の時代に作ったアプリケーションが、Windows 7 や Windows XP でも何の問題もなく、さくっと動作するという感じです。
ruby 、C++、C# なんかも、そんな傾向です。
perl であれば、商業的なことで、無駄なことしなくて済むのです。
だから、米国やインドなどの日本以外の国では、Perl や ruby が見直されてきています。
だが、商業的には都合が悪いかもしれません。
日本のITゼネコン達は Perl や ruby を使うことは否定的です。
若干話題から脱線しますが、「フレームワーク」というプログラム制作上の枠組みを設けることが、均質で質のよいプログラムを作る礎と思い込んでいる勘違いマネージャーもおり、ますます日本のソフトウェア産業 の未来は懐疑的です。
無駄削減を従業員に強要する企業が、顧客に無駄を強要しているのです。
システム開発は、ウチのような中小の方がいい仕事できます。
ただ、ITゼネコンの下請け会社のようなところは避けましょう。
弊社は、ITゼネコンの下請けはしていません。下請けになれば、技術者は育たない。それが体感として判っているからです。
だから、最初からプロジェクトを任された場合に限るのですが、ある程度の能力的自信はあります。