ときどきの雑記帖 めぐりあい電脳空間篇

最新ページへのリンク
目次ページへのリンク

一つ前へ 2010年3月(上旬)
一つ後へ 2010年3月(下旬)

ホームへ

2010年03月20日

■_

・いってきました
Shibuya.lispテクニカル・トーク#5 : ATND あー。あとで(^^; とりあえず、「Clojure大流行」とだけ(笑)
shibuyalisp#5 その1 会場 shibuyalisp#5 その2 フェイント
ご本人の blog にもありますが、実際には Clojure ネタのセッションでした。
shibuyalisp#5 その3 Haskellの方は撮り逃がしました
詳しくはスライドで。
shibuyalisp#5 その4 懇親会
こういう形式の方が自分は参加しやすかったです。 運営の皆様ありがとうございます。 …おっと、λ神社にお賽銭入れるの忘れた(笑)

・地下鉄サリン15年
あの日、日本にいなかったんだよなあ。 CNNで知ったのだけど、英語のリスニング能力が足りないので 事態がなかなか把握できなかった(苦笑) 地下鉄でガスが~とかは聴き取れたんだけど、 「毒ガス」とはなかなか理解できなかった。

・三銃士
実は「三銃士」ってきちんと読んだことがない(もちろんデュマのあれよ?)。 岩波ジュニア新書あたりで読んでみようかなあ。

■_ 今日のム板

ふらっとC#,C♯,C#(初心者用) Part56 
972 デフォルトの名無しさん [sage] 2010/03/20(土) 01:30:44 ID: Be:
    Directoryみたいな機能があって
    それプラスitem追加した順番に並ぶようなクラスは
    どうすれば作れますか? 

973 デフォルトの名無しさん [] 2010/03/20(土) 01:31:56 ID: Be:
    >>972
    >Directoryみたいな機能があって
    >それプラスitem追加した順番に並ぶようなクラスは
    >どうすれば作れますか?
    えw
    自分で文字にしたのがすでに仕様じゃん 

974 デフォルトの名無しさん [sage] 2010/03/20(土) 01:38:25 ID: Be:
    >>940
    >>941
    こういうことしたいんですけど
    foge<obj1,obj2>
    こんな感じで 

975 デフォルトの名無しさん [sage] 2010/03/20(土) 01:39:32 ID: Be:
    >>974
    で? 

976 デフォルトの名無しさん [] 2010/03/20(土) 01:40:49 ID: Be:
    えw
    DirectoryじゃくDictionaryなの? 

977 デフォルトの名無しさん [sage] 2010/03/20(土) 01:50:11 ID: Be:
    って972=974なのか Directoryとか言うから関連があるとは思わんかった
    内部にDictionary<TKey,TValue>とList<TKey>持ったIDictionary<TKey,TValue>実装クラス作ればいいよ 

978 デフォルトの名無しさん [] 2010/03/20(土) 01:51:43 ID: Be:
    こういう小さいクラスも作れないのはキツイな・・・ 

979 デフォルトの名無しさん [sage] 2010/03/20(土) 01:56:39 ID: Be:
    おっと
    書いてる途中で正解が書き込まれてた 

980 デフォルトの名無しさん [sage] 2010/03/20(土) 02:00:39 ID: Be:
    すいませんDirectoryじゃなくてDictionaryで
    途中から追加した順番に要素を検索するクラスが
    作りたいのです

    と言わなくても理解してくれた超能力者がいたので助かりました
    >>977のようなクラスは例えば

    class foge
    {
      Dictionary<TKey,TValue>
    List<TKey>
    }

    みたいになるんですよね?
    そうじゃなくて

    Foge<string,myclass> f=new Foge<string,myclass>();

    for(int idx=9;idx<f.Count;idx++ )
    {
      myclass mc=f.items[idx];
    }

    のようにしたいのです 

981 デフォルトの名無しさん [sage] 2010/03/20(土) 02:02:46 ID: Be:
    そこまでやりたいこと見えてるんなら
    自分でできそうなもんだが 

982 デフォルトの名無しさん [sage] 2010/03/20(土) 02:06:02 ID: Be:
    できることはできるんですが、
    自分がやるとオシャレじゃないので
    もっとスマートに実現してくれるひとはいるかなと
    思いまして 

983 デフォルトの名無しさん [sage] 2010/03/20(土) 02:07:26 ID: Be:
    すいません間違いました
    こういう感じにしたいのです

    for(int idx=9;idx<f.Count;idx++ )
    {
      myclass mc=f[idx];
    } 

984 デフォルトの名無しさん [] 2010/03/20(土) 02:07:58 ID: Be:
    >>980
    そこまで分かってるなら検索ワードも浮かびそうだし
    ぐぐれば出てきそうだけどな

    というかその程度の実装で答えもらってると後で苦労しそうだけどな・・・・ 

985 デフォルトの名無しさん [sage] 2010/03/20(土) 02:10:38 ID: Be:
    誰か作ってくれるまで続けるつもりなのか? 

986 デフォルトの名無しさん [sage] 2010/03/20(土) 02:12:10 ID: Be:
    頭悪いな

987 デフォルトの名無しさん [sage] 2010/03/20(土) 02:12:28 ID: Be:
    >>1
    >>980を踏んだ人は新スレを建てて下さい。 

988 デフォルトの名無しさん [sage] 2010/03/20(土) 02:15:54 ID: Be:
    Foge<string,myclass> f=new Foge<string,myclass>();
    List<string> g = new List<string>();

    for(int idx=9;idx<f.Count;idx++ )
    {
      myclass mc=f[g[idx]];
    } 

989 980 [sage] 2010/03/20(土) 02:17:06 ID: Be:
    ふらっとC#,C♯,C#(初心者用) Part57
    http://pc12.2ch.net/test/read.cgi/tech/1269018938/

    立てたので教えてくださいお願いします 

990 980 [sage] 2010/03/20(土) 02:18:46 ID: Be:
    >>988
    それだとスマートじゃないですよね
    ひとつの自作クラスだけで実現したいんです 

991 デフォルトの名無しさん [sage] 2010/03/20(土) 02:20:44 ID: Be:
    そう思うのはお前の頭が悪いから

992 980 [sage] 2010/03/20(土) 02:22:18 ID: Be:
    >>988
    これだとアイテム追加する度に
    二つの変数にそれぞれキーとかインデックスとか入れないとだめですよね

    f.Add(string,item)
    だけで済むようにしたいんです

    >>991
    ひとつの行いをするのに二つのクラスを使うなんてスマートじゃないです 

993 デフォルトの名無しさん [] 2010/03/20(土) 02:23:54 ID: Be:
    >>992
    そこまで分かってるならクラス自分で実装しろよ

    お前がわからないのはクラスの作り方だろ? 

994 980 [sage] 2010/03/20(土) 02:25:17 ID: Be:
    >>993
    そうです
    作り方がわからないので教えてください 

995 デフォルトの名無しさん [] 2010/03/20(土) 02:25:52 ID: Be:
    自分でわかってる範囲でクラス作って
    ふらっとC#,C♯,C#(初心者用) Part57
    http://pc12.2ch.net/test/read.cgi/tech/1269018938/2
    のサイトに貼って添削してもらう形で動け 

996 980 [sage] 2010/03/20(土) 02:26:41 ID: Be:
    >>995
    ではそうします 

997 デフォルトの名無しさん [sage] 2010/03/20(土) 02:27:33 ID: Be:
    >ひとつの行い
    いや二つだよ 

998 デフォルトの名無しさん [] 2010/03/20(土) 02:42:20 ID: Be:
    まあがんばれ

    このくらいはできるようにならんと 

次のスレもみると、どうも OrderedHashMap というかそういうのを欲していたらしい。 しかし最近の丸投げ(か?)は手が込んでるというかやり方が迂遠というか。

【Perl,PHP】LLバトルロワイヤル9【Ruby,Python】
410 デフォルトの名無しさん [sage] 2010/03/20(土) 00:04:17 ID: Be:
    まぁ何だ、ミッションクリティカルなシステムに使われないうちは、玩具ではあるな。 

411 デフォルトの名無しさん [sage] 2010/03/20(土) 00:21:18 ID: Be:
    富士通ミッションクリティカルシステムズって会社ができたときはちょっとふいたけど 

412 デフォルトの名無しさん [sage] 2010/03/20(土) 00:27:05 ID: Be:
    そのうち富士通エターナルフォースブリザードって会社ができてもおかしくないな 

413 デフォルトの名無しさん [sage] 2010/03/20(土) 00:55:52 ID: Be:
    富士通火消し&リビルドソリューションズって会社も作ればいいのに 

414 デフォルトの名無しさん [sage] 2010/03/20(土) 01:02:01 ID: Be:
    そのうちクラウドなんとかテクノロジーズとかあふれてくるんだろうな。
    最近この業界も安っぽい話が多いよな。twitterとかミニブログとか
    ミニゲームとかクラウド対応とかIT評論家とか自称ギークプログラマーとか、
    ばかじゃね?みたいなのが
    まあそれだけ業界が成熟してきて、もう技術より企画営業宣伝のダークサイドの
    世界になりつつあるんだろうな 

415 デフォルトの名無しさん [sage] 2010/03/20(土) 01:07:24 ID: Be:
    どーでもいいけど顧客を言葉の魔術でまどわしたあとこっちに丸投げはやめてくれ・・・ 

416 デフォルトの名無しさん [sage] 2010/03/20(土) 04:30:07 ID: Be:
    凄腕で研究熱心なプログラマがmixiアプリとか作って才能潰してるのはもったいないな

417 デフォルトの名無しさん [sage] 2010/03/20(土) 04:35:08 ID: Be:
    なんでそれが才能潰してることになるんだ? 

418 デフォルトの名無しさん [sage] 2010/03/20(土) 05:20:15 ID: Be:
    高学歴だが渋谷でねーちゃんにつかまって絵買わされちゃう感じだな 

419 デフォルトの名無しさん [sage] 2010/03/20(土) 05:49:21 ID: Be:
    タケルンバがPHP始めるらしい
    ブログで頻繁に取り上げるだろうか国内シェア倍増するな
    rubyの敗北は既定路線 

渋谷に絵売りアンいたっけ?(そこか?)

クラウドなんたらって名前の会社。確かに出てきそうだ(笑)

■_ Is learning haskell worth it?

意外に伸びなかったな。 しかしいい意見が並んでるように思う (適当に抜き出しました。全部ではありません)。


Is learning haskell worth it? : haskell
Is learning haskell worth it? (self.haskell)

I am an undergrad math and physic major and the mathematical "niceness" of 
haskell seems quite appealing to me. I have some knowledge of java and C (and category 
theory haha). Is it worth it to take the plunge and learn haskell? Is it a worthwhile 
language to know in those fields?

* 16個のコメント

Chances are, if you're not specifically choosing projects so as to use Haskell, then 
you won't use Haskell "in the large" on any of your work in physics or math. 
That said, I'm a graduate student in mathematics, and I use Haskell all the time just 
to check conjectures, find examples, and just do exploratory computations.

I'd also urge you to learn Haskell just for the reason that it will, to be a bit 
cliche, make you a better mathematician. It will give you a concrete area in which 
build nice abstract formalisms is helpful and commonplace. Haskell is really the only 
widely used programming language where this advice is reasonable; in any other 
language, the messy environment in which your programs run tends to get in the way of 
being able to reason about them, so that writing code is a bit too isolated from 
mathematical thinking.


After learning Haskell, I suggest you also learn Agda.

#…いけがみさん!?

Do you like to broaden your mind? Do you like to get a glimpse of the fundamental 
structures underlying computing? As a math and physics major, I'm sure you enjoy 
learning about fundamental principles that make our universe tick. In Java and C, it 
is hard to see the forest for the trees, but in Haskell, you have a chance of getting 
an idea of what computing is really about.

As a physicist, you might need to calculate some eigenvalues every now and then, which 
is a pain in Fortran/LAPACK. The hmatrix library is much more pleasant to use!

Unless you plan on going the agda/coq route instead, definitely yes.


I'm going to echo most of cdsmith's sentiments but I want to add that Haskell has a 
reputation for being difficult among programmers. I only know one mathematician 
personally who has learned it, and he knew a few other languages going in (at least 
Python, I think also some Java or C) but he found it to be much easier to learn 
Haskell than I have found.

It will help that the parts of Haskell that are hard for programmers aren't 
particularly important to you. I doubt you'll be much concerned about the lack of an 
excellent web framework or that the database interaction is still at this point mostly 
SQL (a factor I like, but it isn't for everyone). If you wind up doing visualization, 
you won't find it harder to do GL in Haskell than anywhere else but the rest of the 
program will be simpler and clearer to you.

I recommend Haskell to you because you will find that you fit in better to the Haskell 
community than to any other language community. You probably could find a fair number 
of like-minded people in some niche of another language, but Haskell's core group are 
mathematically and scientifically inclined folk. Kin, if you will. So you will find 
that the things that you get stuck dealing with are things that others are likely to 
get stuck dealing with, and things that you don't need explained are the kinds of 
things that aren't over explained (except for monads, of course).

You should learn Haskell because, like cdsmith said, you will find it a great 
scratchpad for your research. Writing a large-scale physical simulation is a daunting 
task in any language. You have to ask yourself if you'd rather deal with optimizing 
performance at the end or slogging through mud through the whole process. Even if you 
embark on a large coding project and can't finish it, using Haskell for a prototype 
will help make the core of the system clearer. You will probably also find it easier 
to get help from the Haskell community on the subject of optimizing a program than 
from another language community for holistic help, if for no other reason than that it 
will be less help you'll need.

Because Haskell is a rising star in the math and physics world, I think you'll also 
find yourself at the forefront of a positive trend.

If the Fortress project were a little further along I might suggest taking a look at 
it, but I think it's stagnated somewhat and the Sun/Oracle situation has probably 
slowed development.


I for my own must say that it's a very steep learning curve. Unlike many other 
programming languages it's one of those where you really have to understand most of 
it's syntax AND idioms to get productive. Reading only the first chapters of whatever 
Haskell book or tutorial out there, then think about a problem you feel like to solve 
and continue reading as needed will get you nowhere. Looking back, the only thing you 
need not understand (for easy problems) at the beginning are monads. Simply start 
using the IO monad and think about how the bit's and pieces fit together later.

       1. A language that doesn't affect the way you think about programming, is not 
          worth knowing. -- Alan Perlis

Haskell will most certainly change how you think about coding. It has a number of nice 
features that make math very nice in it - list comprehensions come to mind as an 
example.

Also, Haskell has a REPL (read-eval-print loop), which is a nice change from C and 
Java. Basically, you type Haskell expressions into ghci, and it evaluates them and 
spits out the answer. It has some limitations compared to a Lisp REPL, mostly because 
Haskell is compiled.

自分ももっとがんばらねば。

■_ π

πの日(3/14)に見つけたものですが、せっかくなので。


imagine27 - 2010-03-14 happy pi day in asm

Happy π day/night (in assembly) !

Posted by jgrant, 2010-03-14 07:22:00

//   pi_x64.s - calculates Pi using the Leibniz formula.
//              Each iteration prints a closer approximation to 50 digits.
//              This is not an optimal implementation and it runs forever.
//
//  x86-64/SSE3 with for Linux, Intel, gnu assembler, gcc
//
//  assemble: as pi_x64.s -o pi_x64.o
//  link:     gcc -o pi_x64 pi_x64.o
//  run:      ./pi_x64
//  output: 3.14159264858204423376264458056539297103881835937500
//          3.14159265108366625440794450696557760238647460937500
//          3.14159265191852199450295302085578441619873046875000
//          3.14159265233600137889879988506436347961425781250000
//          .... and on forever ...

.section .data
        .align 16
denom:  .double  1.0, 3.0
numer:  .double  4.0, -4.0
add4:   .double  4.0, 4.0
zero:   .double  0.0, 0.0
msg:    .string  "%1.50f\n"

.section .text
        .globl main
        .type main, @function
        .align 64
main:
        pushq	%rbp
        movq	%rsp, %rbp

        movdqa  (numer), %xmm2
        movdqa  (denom), %xmm6
        movdqa  (add4), %xmm3
        movdqa  %xmm2, %xmm4
        movdqa  (zero), %xmm5
        movq    $100000000, %r12

loop:
        divpd  %xmm6, %xmm2
        addpd  %xmm2, %xmm5
        movdqa %xmm4, %xmm2
        addpd  %xmm3, %xmm6

        subq $1, %r12
        jnz loop

        movq   $100000000, %r12
        movdqa %xmm5, %xmm0
        movdqa %xmm6, %xmm1
        haddpd %xmm0, %xmm0

        movq  $1, %rax
        movq $msg, %rdi
        call printf

        movdqa (add4), %xmm3

        jmp loop

        movq $0, %rax
        popq %rbp
        ret


© 2005, 2006, 2007, 2008, 2009 imagine27 - justin at imagine twenty seven dot com

double の精度(桁数)で計算させるなら、 ループ回数こんなにいらないような気もするんだけどどうなんだろう。 って、どの公式使ってんのかよくわからんなあ(苦笑)

■_ NaN →

とあるついったらー のついっとから


isNaNを「数値かどうか調べる」って説明してるのはどこからの文化なんだろう


と思ったらMozilla Developer Centerでもそう書いてる、えー…

"Evaluates an argument to determine if it is not a number."が
"引数が数でないかどうかを評価します。"に訳されてるのか、非数と訳すべきか迷う感じだ
 
 
https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Predefined_Functions/isNaN_
Function だったら非数の意味なのが明らかだけど

ECMAの規格にはNaNって書いてるんだからJavaScriptリファレンスを作って公開するサイトが
そっちを見て書いてくれればこんなことにはならなかった

この英文だけ見てやったら自分も「非数」とか「NaN」に考えが及ぶか自信がない(^^; が、isNaN の動作を考えると「数でないかどうか」というのは直した方がよさげだなあ。 「匿名メソッド」みたいなもんだろうか(まだ云うか)。

■_ str*_s

この質問なんですが。


_tcscpy_s(wcscpy_s)の第二引数って(1/1) | OKWave
_tcscpy_s(wcscpy_s)の第二引数って

_tcscpy_s(wcscpy_s)の第二引数って
http://msdn.microsoft.com/ja-jp/library/td1esda9%28VS.80%29.aspx

を見て、たとえば以下のような関数を書いたとします。

TCHAR* fn;

void OMG(LPCTSTR c){

int bytes( ( _tcslen(c) + 1 )*sizeof(TCHAR) );
if ( fn = (TCHAR*)malloc( bytes ) ) _tcscpy_s( fn, bytes, c ); //実行しないでください
else return;

/* fnを使用 */

free(fn); fn=0;

}


これ、マルチバイトだと正常に出来るのですが
なぜかUnicodeだと落ちてしまいました。
(略)

質問者の勘違いだか貼り付けた部分以外のコードのバグだろうと思ったんですが、 ちょっと調べてみると(省略されました)

明日以降続きを書きます。 つか誰か事情知ってたら解説して~

2010年03月19日

■_

・パトレイバー
ついったで こちら特車二課 (patlabor_info) on Twitter こういうIDをみつけたのと、 TVアニメーション 乃木坂春香の秘密ぴゅあれっつあ♪ の今週の配信で、パトレイバーが話題に出たり。 いま考えると「バビロンプロジェクト」ってとんでもない代物のような。 なんたって東京湾を丸ごと干拓しようってんだから。 バブルそのものの計画(笑)
EMOTION the Best 機動警察パトレイバー 劇場版 [DVD] EMOTION the Best 機動警察パトレイバー2 the Movie [DVD] EMOTION the Best WXIII 機動警察パトレイバー [DVD]
やっぱ後藤隊長いいわあ。

・SD
ソフトウェアデザイン というか Karetta|『帰ってきたCプログラミング診断室』発売 は読んでおくべき。古田島さんの話とかは泣ける。

・Fireman → Fire Fighter
PCな言い換えがされた単語はたくさんあると思うんですが、 この Fireman から Fire Fighter は言い換えたものの方が好きだなあ。 そして消防士といえば
バックドラフト バックドラフト 【プレミアム・ベスト・コレクション1800円】 [DVD]
テーマ曲を聴くと「アレ・キュイジーヌ」な別の番組を連想するような気もするけど(笑)

■_

【Perl,PHP】LLバトルロワイヤル9【Ruby,Python】 
403 デフォルトの名無しさん [sage] 2010/03/19(金) 02:31:55 ID: Be:
    (a+b)(a-b)
    を因数分解してくれる電卓が欲しい 

404 デフォルトの名無しさん [sage] 2010/03/19(金) 03:34:14 ID: Be:
    >>403
    これ以上因数分解できねぇw

    つisympy 

405 デフォルトの名無しさん [sage] 2010/03/19(金) 03:59:56 ID: Be:
    フリーの数値計算ソフトがあるぞ 

406 デフォルトの名無しさん [sage] 2010/03/19(金) 04:08:54 ID: Be:
    Mathematicaとか、フリーならMaximaとかさ
    ときおり、呆然とするような結果を吐くから
    いじるのが楽しい 

407 デフォルトの名無しさん [sage] 2010/03/19(金) 04:14:32 ID: Be:
    これかMaximaだな
    http://www.ecl.hiroshima-u.ac.jp/~ohno/scilab/introscilab/introscilab.html 

408 デフォルトの名無しさん [sage] 2010/03/19(金) 08:21:11 ID: Be:
    因数分解や展開ならasirでもいける 

409 デフォルトの名無しさん [sage] 2010/03/19(金) 11:51:59 ID: Be:
    >>399
    まあ、まともな選択だけどね。スレタイ言語1つ入ってるし。PHPはずしてPerlでもいいと思うけど。
    PerlはやっぱUnix管理系で多く使われてるからできると便利。 


ネットワークプログラミング相談室 Port25 
935 デフォルトの名無しさん [sage] 2010/03/11(木) 08:10:57 ID: Be:
    WebDBの話、この子か書いたの。
    http://d.hatena.ne.jp/viver/20100224/p1
    日記読んでれば解るけど、ここ2年ぐらいでKVSとかに興味持ち出して
    自分でライブラリ書いてた子だね・・・
    学習スピードが恐ろしく早い子だな 

936 デフォルトの名無しさん [sage] 2010/03/11(木) 15:34:30 ID: Be:
    >>935
    筑波大がすばらしいのか、こいつだけが特別なのか。 

937 デフォルトの名無しさん [sage] 2010/03/11(木) 16:33:44 ID: Be:
    世界で唯一、開発者の名前を冠されたウイルス(Trojan.Hirofu)の
    開発者(古田泰大)も筑波。 

938 デフォルトの名無しさん [sage] 2010/03/11(木) 18:35:51 ID: Be:
    >>935
    学生なんだな。かなり優秀だな
    優秀な学生はアメリカの優秀な大学院に行って、そこの恵まれた環境でさらに
    能力を伸ばして欲しいものだな 

939 デフォルトの名無しさん [sage] 2010/03/11(木) 18:40:04 ID: Be:
    そういえば、Rubyやソフトイーサーを作ったのも筑波だよな 

940 デフォルトの名無しさん [sage] 2010/03/11(木) 18:45:10 ID: Be:
         ____
       /__.))ノヽ
       .|ミ.l _  ._ i.)
      (^'ミ/.´・ .〈・ リ
      .しi   r、_) |  筑波大は(ry
        |  `ニニ' /
       ノ `ー―i´ 

943 デフォルトの名無しさん [sage] 2010/03/12(金) 16:33:17 ID: Be:
    筑波は隔離されてて俗世間の誘惑が少ないからなw
    研究にはいい所かもしれん。若い時にしか出来ない大切な機会を失う気もするけど。 

944 デフォルトの名無しさん [sage] 2010/03/12(金) 23:20:34 ID: Be:
    筑波の3Sって言葉もあるが。 

945 デフォルトの名無しさん [sage] 2010/03/13(土) 04:21:34 ID: Be:
    まあ田舎はほとんど3Sだろう。大した娯楽も無いし。 

946 デフォルトの名無しさん [sage] 2010/03/13(土) 13:45:54 ID: Be:
    >>23
    筑波の先生は
    よく未到のマネージャーもやってたりするね 

947 デフォルトの名無しさん [sage] 2010/03/14(日) 18:17:53 ID: Be:
    >>944
    4Sだろ。 

つくばこわい

■_ なんで head + tail?


ファイルの20行目から30行目までを取り出すには? - 今日の腕試し!:ITpro

ファイルsampleは50行の長さがあるとします。LinuxなどのUNIX系OSで、このファイルの20行目
から30行目までを取り出して表示するコマンドはどれでしょう?

●解答を送信いただくと,すぐに正解と詳しい解説をご覧いただけます。

	1. head -30 sample | tail -10
	2. tail -30 sample | head -10
	3. cat sample | head +20 | tail -10
	4. tail +30 sample | head -11
	5. head -30 sample | tail -11 

なんでsedとかawkつかわないんだろう。

  sed -ne '20,30p'
  awk 'NR==20,NR==30'

これだとでかいファイルも無駄に読んじゃうけど、30行目の処理が終わったら終了とかできるし。

■_ grep

昨日も書いたようにぜんぜん追いかけられていないのだけど


[bug #14472] grep is slow in multibyte locales

From: 	Paolo Bonzini
Subject: [bug #14472] grep is slow in multibyte locales
Date: 	Tue, 16 Mar 2010 14:40:27 +0000

Update of bug #14472 (project grep):

                  Status:               Confirmed => Fixed                  
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #8:

There are more queued patches which will improve speed further; however, the
roughly-quadratic cases should be fixed.



Thank you for the bug report. This bug has been fixed in the
development sources, which can be downloaded using git from
git://git.sv.gnu.org/grep.git

    _______________________________________________________

Reply to this item at:

  http://savannah.gnu.org/bugs/?1447

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

いろいろパッチを適用してるみたいですねえ。

■_ Rakudo

こっちも大変そうだなあ

Perl6/Parrotスレ - Part2 [chaika]
305 nobodyさん [sage] 2010/02/23(火) 01:22:08 ID:??? Be:
    なにげにParrot 2.1.1。
    風も温んできた。4月も近い。 

306 nobodyさん [sage] 2010/03/05(金) 22:03:05 ID:??? Be:
    やっぱりエイプリルフール当日発表かねぇ。 

307 nobodyさん [sage] 2010/03/18(木) 00:31:38 ID:??? Be:
    Late April を目指してるらしいよ
    4月の定期リリースの後くらい
    ただ中心的開発者の pmichaud の奥さんが最近入院して看病に時間を取られてるとかで、
    リリースを遅らせることも視野に入れてるとか
    ttp://use.perl.org/~pmichaud/journal/40248

308 nobodyさん [sage] 2010/03/19(金) 11:20:57 ID:??? Be:
    Rakudo Star は5月か6月リリースになったっぽい
    ttp://github.com/rakudo/rakudo/blob/master/docs/ROADMAP

■_ re2

ソースコードやっと取ってきた。 バージョン管理ツールから入れないといけないと取ってこれないとは。


2010/03/20  02:18    <DIR>          .
2010/03/20  02:18    <DIR>          ..
2010/03/20  02:18    <DIR>          .hg
2010/03/20  02:18                51 .hgignore
2010/03/20  02:18               337 AUTHORS
2010/03/20  02:18    <DIR>          benchlog
2010/03/20  02:18             1,251 CONTRIBUTORS
2010/03/20  02:18    <DIR>          doc
2010/03/20  02:18    <DIR>          lib
2010/03/20  02:18             1,558 LICENSE
2010/03/20  02:18             3,826 Makefile
2010/03/20  02:18    <DIR>          re2
2010/03/20  02:18               350 README
2010/03/20  02:18               267 runtests
2010/03/20  02:18               189 testinstall.cc
2010/03/20  02:18    <DIR>          util

(略)

2010/03/20  02:18            11,035 bitstate.cc
2010/03/20  02:18            27,168 compile.cc
2010/03/20  02:18            70,583 dfa.cc
2010/03/20  02:18             2,774 filtered_re2.cc
2010/03/20  02:18             3,127 filtered_re2.h
2010/03/20  02:18                 1 Makefile
2010/03/20  02:18             2,597 make_perl_groups.pl
2010/03/20  02:18             2,733 make_unicode_casefold.py
2010/03/20  02:18             2,845 make_unicode_groups.py
2010/03/20  02:18             5,930 mimics_pcre.cc
2010/03/20  02:18            20,925 nfa.cc
2010/03/20  02:18            22,064 onepass.cc
2010/03/20  02:18            53,290 parse.cc
2010/03/20  02:18             4,680 perl_groups.cc
2010/03/20  02:18            16,182 prefilter.cc
2010/03/20  02:18             2,932 prefilter.h
2010/03/20  02:18            11,907 prefilter_tree.cc
2010/03/20  02:18             4,750 prefilter_tree.h
2010/03/20  02:18             7,822 prog.cc
2010/03/20  02:18            13,180 prog.h
2010/03/20  02:18            33,607 re2.cc
2010/03/20  02:18            31,891 re2.h
2010/03/20  02:18            14,645 regexp.cc
2010/03/20  02:18            17,834 regexp.h
2010/03/20  02:18            11,765 simplify.cc
2010/03/20  02:18             5,781 stringpiece.h
2010/03/20  02:18    <DIR>          testing
2010/03/20  02:18             8,018 tostring.cc
2010/03/20  02:18             7,908 unicode.py
2010/03/20  02:18             6,416 unicode_casefold.cc
2010/03/20  02:18             2,254 unicode_casefold.h
2010/03/20  02:18            86,922 unicode_groups.cc
2010/03/20  02:18             1,416 unicode_groups.h
2010/03/20  02:18            16,675 variadic_function.h
2010/03/20  02:18             7,709 walker-inl.h
              34 個のファイル             539,366 バイト

(略)

2010/03/20  02:18    <DIR>          .
2010/03/20  02:18    <DIR>          ..
2010/03/20  02:18             6,162 arena.cc
2010/03/20  02:18             3,484 arena.h
2010/03/20  02:18               811 atomicops.h
2010/03/20  02:18             2,923 benchmark.cc
2010/03/20  02:18             1,263 benchmark.h
2010/03/20  02:18               994 flags.h
2010/03/20  02:18             8,510 hash.cc
2010/03/20  02:18               444 hash_map.h
2010/03/20  02:18             1,990 logging.h
2010/03/20  02:18             7,085 mutex.h
2010/03/20  02:18            34,081 pcre.cc
2010/03/20  02:18            27,498 pcre.h
2010/03/20  02:18               776 random.cc
2010/03/20  02:18               622 random.h
2010/03/20  02:18             4,874 rune.cc
2010/03/20  02:18            13,702 sparse_array.h
2010/03/20  02:18             4,585 sparse_array_test.cc
2010/03/20  02:18             2,549 stringpiece.cc
2010/03/20  02:18             1,927 stringprintf.cc
2010/03/20  02:18             3,386 strutil.cc
2010/03/20  02:18               826 test.cc
2010/03/20  02:18             1,353 test.h
2010/03/20  02:18               756 thread.cc
2010/03/20  02:18               482 thread.h
2010/03/20  02:18             1,530 utf.h
2010/03/20  02:18             3,012 util.h
              26 個のファイル             135,625 バイト

     ファイルの総数:
             235 個のファイル           1,849,345 バイト

さて読む時間があるか。

■_ 本日の巡回から

■_ おっと

shibuya.lisp#5 か。 とっと寝よう。

2010年03月18日

■_

Firefox
モジラ、「Firefox 3.0」のサポートを3月末で終了へ - builder by ZDNet Japan 二年でサポート切れっていくら何でもという気がしないでも。

grep マルチバイト処理
http://lists.gnu.org/archive/html/bug-grep/2010-03/index.html 盛り上がってるけど追いかけている余裕が

ニャル子さんきたーっ

■_ 本日の巡回から

■_ COS

まだ中身は見てないんですが。

[1003.2547] The C Object System: Using C as a High-Level Object-Oriented Language
The C Object System: Using C as a High-Level Object-Oriented Language

Authors: Laurent Deniau

(Submitted on 12 Mar 2010)

    Abstract: The C Object System (Cos) is a small C library which implements 
high-level concepts available in Clos, Objc and other object-oriented programming 
languages: uniform object model (class, meta-class and property-metaclass), generic 
functions, multi-methods, delegation, properties, exceptions, contracts and closures. 
Cos relies on the programmable capabilities of the C programming language to extend 
its syntax and to implement the aforementioned concepts as first-class objects. Cos 
aims at satisfying several general principles like simplicity, extensibility, 
reusability, efficiency and portability which are rarely met in a single programming 
language. Its design is tuned to provide efficient and portable implementation of 
message multi-dispatch and message multi-forwarding which are the heart of code 
extensibility and reusability. With COS features in hand, software should become as 
flexible and extensible as with scripting languages and as efficient and portable as 
expected with C programming. Likewise, Cos concepts should significantly simplify 
adaptive and aspect-oriented programming as well as distributed and service-oriented 
computing 

COS (C Object System) はCLOS や Objective-C、あるいはその他のオブジェクト指向プログラ
ミング言語で可能な high-level concepts を実装したちいさなライブラリです:統一されたオブ
ジェクトモデル (クラス、メタクラス、プロパティメタクラス)総称関数、マルチメソッド、デ
リゲート、プロパティ、例外、契約、クロージャ などがあります。COS はC のプログラミング
言語としての自分自身の構文を拡張したりファーストクラスオブジェクトとしてaforementioned 
concepts を実装できるプログラム可能な能力に依存しています。COSは単一のプログラミング言
語ではほとんど見られないような単純性、拡張性、再利用性、効率、移植性、といった幾つかの
原則を満足させることを目指していますCOS の設計は、メッセージのマルチディスパッチやメッ
セージのマルチフォワーディングの効率的かつ移植性にトんだ実装を提供することを目指してい
ます。COS の機能を使うことで、ソフトウェアはスクリプティング言語をともなったかのように
柔軟かつ拡張可能なものになると同時に、Cプログラミングで期待されているような効率と移植
性をそなえたものになるはずです。
Likewise, Cos concepts should significantly simplify adaptive 
and aspect-oriented programming as well as distributed and service-oriented computing 

Comments: 	18p
Subjects: 	Programming Languages (cs.PL)
ACM classes: 	D.3.3; D.1.5
Cite as: 	arXiv:1003.2547v1 [cs.PL]
http://arxiv.org/abs/1003.2547v1


http://arxiv.org/pdf/1003.2547v1
http://arxiv.org/format/1003.2547v1

■_ メンテ不能なコードを書くために

How To Write Unmaintainable Code

Camouflage (カムフラージュ)

    The longer it takes for a bug to surface, the harder it is to find.
    難しいバグは見つけるのも困難
    - Roedy Green

Much of the skill in writing unmaintainable code is the art of camouflage, hiding 
things, or making things appear to be what they are not. Many depend on the fact the 
compiler is more capable at making fine distinctions than either the human eye or the 
text editor. Here are some of the best camouflaging techniques.

メンテ不能コード (unmaintainable code) を書く技術 (skill) の多くはカムフラージュの技法
であり、何かを隠したりあるいは実際にはないものをあるようにみせるといったものです。きち
んと区別をつけるという点において、人間の目やテキストエディターよりもコンパイラーの方が
より capable であるという事実に多くが拠っています。以下にいくつかの優れたカムフラージ
ュ技法を挙げます。

      Code That Masquerades As Comments and Vice Versa

      コメントを偽装したコードやコードを偽装したコメント

      Include sections of code that is commented out but at first glance does not appear to be.

      コメントアウトされているのに一見そうは見えないようなコードのセクションを include します。

            for(j=0; j<array_len; j+ =8)
                  {
                  total += array[j+0 ];
                  total += array[j+1 ];
                  total += array[j+2 ]; /* Main body of
                  total += array[j+3]; * loop is unrolled
                  total += array[j+4]; * for greater speed.
                  total += array[j+5]; */
                  total += array[j+6 ];
                  total += array[j+7 ];
                  }
      Without the colour coding would you notice that three lines of code are commented out?

      色分けコーディングすることなしに、実際にはコメントアウトされている三行を見分けられますか?

      namespaces (名前空間)
      Struct/union and typedef struct/union are different name spaces in C (not in C++). Use
      the same name in both name spaces for structures or unions. Make them, if possible, nearly
      compatible.

      Struct/union と typedef struct/union は (C++ ではなく) C ではそれぞれが異なる名前空間に
      置かれます。構造体や共用体に対して両方の名前空間で同じ名前を使いましょう。可能であれば、
      それら両者を「ほぼ」互換なものにしておきましょう。

            typedef struct {
            char* pTr;
            size_t lEn;
            } snafu;

            struct snafu {
            unsigned cNt
            char* pTr;
            size_t lEn;
            } A;

      Hide Macro Definitions (マクロ定義を隠す)
      Hide macro definitions in amongst rubbish comments. The programmer will get bored and
      not finish reading the comments thus never discover the macro. Ensure that the macro
      replaces what looks like a perfectly legitimate assignment with some bizarre operation,
      a simple example:

      ゴミコメントの山の中に (amongst rubbish comments) マクロの定義を隠してしまいましょう。
      プログラマーはマクロを決して見つけ出せないので飽きてコメントを読むのを止めてしまうで
      しょう。完全に正当な代入 (perfectly legitimate assignment) のように見えるマクロもち
      ょっと奇妙な操作 (some bizarre operation)に置き換えておきましょう。
      単純な例:

            #define a=b a=0-b 


      Look Busy
      use define statements to make made up functions that simply comment out their arguments,
      e.g.:

      渡された引数をただ単にコメントアウトしてしまうような関数をでっち上げるために define を
      使いましょう。

            #define fastcopy(x,y,z) /*xyz*/
            ...
            fastcopy(array1, array2, size); /* does nothing */ 


      Use Continuation to hide variables (行継続を使った変数の隠蔽)
      Instead of using
            #define local_var xy_z break up "xy_z" onto two lines:
            #define local_var xy\
            _z // local_var OK
      That way a global search for xy_z will come up with nothing for that file. To the C
      preprocessor, the "\" at the end of the line means glue this line to the
      next one.

      #define local_var xy_z break up "xy_z" といったものは行継続を使って二行に分
      けます:
            #define local_var xy\
            _z // local_var OK
      このようにすると xy_z をグローバルに検索してもそのファイルからは何も見つかりません。
      C プリプロセッサーに対しては、行末に置かれている "\" はその行と次の行とをく
      っつける (glue) ことを意味します。


      Arbitrary Names That Masquerade as Keywords (予約語と紛らわしい名前)

      When documenting, and you need an arbitrary name to represent a filename use 
      "file ". Never use an obviously arbitrary name like "Charlie.dat" 
      or "Frodo.txt". In general, in your examples, use arbitrary names that sound 
      as much like reserved keywords as possible. For example, good names for parameters or 
      variables would be"bank", "blank", "class", "const 
      ", "constant", "input", "key", "keyword", 
      "kind", "output", "parameter" "parm", "system",
      "type", "value", "var" and "variable ". If you
      use actual reserved words for your arbitrary names, which would be rejected by your
      command processor or compiler, so much the better. If you do this well, the users will
      be hopelessly confused between reserved keywords and arbitrary names in your example, but
      you can look innocent, claiming you did it to help them associate the appropriate purpose
      with each variable.

      ドキュメントを書くときに、あるファイル名を表現する arbitrary name (任意の名前) が必要
      になったら "file " を使いましょう。"Charlie.dat" だとか "Frodo.txt"
      といった明らかに arbitrary name のようなものは決して使ってはいけません。一般的にはあな
      たが書く例では、可能な限り予約語 (reserved keywords) のように聞こえる arbitrary name
      を使います。パラメータや変数によい名前はたとえば次のようなものです。"bank", "blank", 
      "class", "const", "constant", "input", "key", 
      "keyword", "kind", "output", "parameter" "parm", 
      "system","type", "value", "var" and "variable ". 
      あなたの使うコマンドプロセッサーやコンパイラーから拒否 (reject) されるような arbitrary
      names として実際の予約語 (actual reserved words) が使えると so much the better です。
      もしこれをうまくやれれば、ユーザーは絶望的なほど予約語と arbitrary names との間で混乱
      することになりますが、あなたは無罪のように見えて、適切な目的とそれぞれの変数が結びつけ
      てユーザーを助けようとしたのだと主張できるでしょう。

      Code Names Must Not Match Screen Names (スクリーン上の名前にマッチしないコード名)
      Choose your variable names to have absolutely no relation to the labels used 
      when such variables are displayed on the screen. E.g. on the screen label the
      field "Postal Code" but in the code call the associated variable "zip".

      その変数がスクリーン上に表示されるときに使われているラベルとは全く関係を持っていない
      変数の名前を選択しましょう。たとえば、スクリーン上のラベルに "Postal Code" (郵便番号)
      というフィールドがあったら、コードでは  "zip" という変数に結び付けて呼ぶようにします。


      Don't Change Names (名前を変えない)
      Instead of globally renaming to bring two sections of code into sync, use 
      multiple TYPEDEFs of the same symbol.

      二つのセクションにあるコードを  sync させようとするときにはグローバルに名前を変更
      するのではなく、同一のシンボルに対する複数の TYPEDEF を使います


      How to Hide Forbidden Globals (禁じられたグローバルの隠し方)
      Since global variables are "evil", define a structure to hold all the 
      things you'd put in globals. Call it something clever like EverythingYoullEverNeed. 
      Make all functions take a pointer to this structure (call it handle to confuse
      things more). This gives the impression that you're not using global variables,
      you're accessing everything through a "handle". Then declare one statically so
      that all the code is using the same copy anyway.

      グローバル変数は“邪悪”(evil) なものなので、あなたがグローバルにしたいようなもの全て
      を保持するための構造体を宣言して、それを EverythingYoullEverNeed のように賢く呼びます。
      すべての関数がこの構造体へのポインターを引数に取るようにします (それをハンドルと呼ぶと
      さらに混乱を増大させるでしょう)。こうすることで、あなたがグローバル変数を使わずに
      “ハンドル”を通して全てにアクセスしようとしている印象を与えるでしょう。そうしておいて
      から静的に一つ宣言し、すべてのコードで同じコピーを使うようにします。


      Hide Instances With Synonyms (シノニムでインスタンスを隠す)
      Maintenance programmers, in order to see if they'll be any cascading effects to a
      change they make, do a global search for the variables named. This can be defeated 
      by this simple expedient of having synonyms, such as
            #define xxx global_var // in file std.h
            #define xy_z xxx // in file ..\other\substd.h
            #define local_var xy_z // in file ..\codestd\inst.h
      These defs should be scattered through different include-files. They are especially
      effective if the include-files are located in different directories. The other
      technique is to reuse a name in every scope. The compiler can tell them apart, but
      a simple minded text searcher cannot. Unfortunately SCIDs in the coming decade will
      make this simple technique impossible. since the editor understands the scope rules
      just as well as the compiler.

      メンテナンスプログラマーは、自分の行おうとしている変更によってなんらかの cascading
      effects が起きないかどうかを確かめるためにグローバルサーチを行ってその名前の変数を
      探します。この行動は、次のようなシノニムを作るための単純な方法で打破することができ
      ます。

            #define xxx global_var // in file std.h
            #define xy_z xxx // in file ..\other\substd.h
            #define local_var xy_z // in file ..\codestd\inst.h
 
      これらの定義は異なる include ファイルを通じて scatter (ばら撒く) するとよいでしょう。
      include されるファイルが異なるディレクトリに置かれていれば、これは特に効果的です。
      別の手法に、すべてのスコープで名前を再利用するというものがあります。コンパイラーは
      それらを区別できますが、単純なテキストサーチでは区別できません。残念ながら次の十年
      (coming decade) で SCIDs はこの単純なテクニックを使えないようにしてしまうでしょう。
      それはエディターがコンパイラーと同様にスコープルールを理解するようになってきたため
      です。


      Long Similar Variable Names (長くて良く似た変数名)
      Use very long variable names or class names that differ from each other by only one
      character, or only in upper/lower case. An ideal variable name pair is swimmer and 
      swimner. Exploit the failure of most fonts to clearly discriminate between ilI1| or 
      oO08 with identifier pairs like parselnt and parseInt or D0Calc and DOCalc. l is an 
      exceptionally fine choice for a variable name since it will, to the casual glance, 
      masquerade as the constant 1. In many fonts rn looks like an m. So how about a variable
      swirnrner. Create variable names that differ from each other only in case e.g. 
      HashTable and Hashtable.

      一文字だけ違っているとか大小文字だけが違うような非常に長い変数名やクラス名を使いま
      しょう。理想的な変数名のペアは swimmer と swimner です。ほとんどのフォントでの ilI1l
      や oO08 といった文字を parselnt と parseInt や D0Calc と DOCalc のような識別子ペアで
      つかったときの区別のつかなさの失敗を利用してしまいましょう。l は変数の名前の選択とし
      てとても優れたものです。なぜなら、ちらっとみたときに定数の 1 のように偽装できるから
      です。多くのフォントで rn は m と見た目が似ています。ですから、 swirnrner という変数
      名はとても都合がよいのです。HashTable と Hashtable のように、大小文字だけが違っている
      ような変数名を作り出しましょう


      Similar-Sounding Similar-Looking Variable Names
      (同じような読みや同じような外見の変数名)
      Although we have one variable named xy_z, there's certainly no reason not to 
      have many other variables with similar names, such as xy_Z, xy__z, _xy_z, _xyz, XY_Z, 
      xY_z, and Xy_z.

      xy_z という名前の変数を持っているからといって xy_Z, xy__z, _xy_z, _xyz, XY_Z, xY_z,
      Xy_z のような良く似た名前の変数を持ってはいけないという確たる理由はありません。

      Variables that resemble others except for capitalization and underlines have the 
      advantage of confounding those who like remembering names by sound or letter-spelling, 
      rather than by exact representations.

      大小文字の違いやアンダーラインの有無を除いてそっくりな名前の変数には、exact
      represatations ではなく音や文字の並びで名前を思い出すような人を混乱させるアドバ
      ンテージがあります

      Overload and Bewilder (オーバーロードとBewilder)
      In C++, overload library functions by using #define. That way it looks like you 
      are using a familiar library function where in actuality you are using something 
      totally different.

      C++ で、#define を使ってライブラリ関数をオーバーロードします。これは、慣れ親しんだ
      ライブラリ関数を使うように見せかけてその実全く異なるものを使う手法です。

      Choosing The Best Overload Operator (ベストなオーバーロード演算子を選択する)
      In C++, overload +,-,*,/ to do things totally unrelated to addition, subtraction 
      etc. After all, if the Stroustroup can use the shift operator to do I/O, why should 
      you not be equally creative? If you overload +, make sure you do it in a way that i = 
      i + 5; has a totally different meaning from i += 5; Here is an example of elevating 
      overloading operator obfuscation to a high art. Overload the '!' operator for a class, 
      but have the overload have nothing to do with inverting or negating. Make it return an 
      integer. Then, in order to get a logical value for it, you must use '!!'. However, this
      inverts the logic, so [drum roll] you must use '!!!'. Don't confuse the ! operator,
      which returns a boolean 0 or 1, with the ~ bitwise logical negation operator.

      C++ では、+, -, *, / を四則演算とは全く関係のないことがらを行うようにオーバーロードし
      ます。そもそも Stroustoup がシフト演算子を入出力を行うためのものに使えたのだから、なぜ
      あなたが同じように creative なことをすべきでないと言えるのでしょうか? + をオーバーロー
      ドするのなら、i += 5 の意味が全く異なった i = i + 5 のような動作を行うようにします。
      これは elevating overloading operator による高度な難読化技法 (obfuscation to a high art)
      の例です。あるクラスのために '!' 演算子をオーバーロードするけれども、実際には inverting
       か negating を行うようにして、整数を返すようにします。そうすると logical value を取り出
      すためには '!!' を使わなければならなくなります。が、しかし、これは論理を反転しているので、
      [ここでドラムロール] '!!!' を使わなければならないのでした。boolean の 0 か 1 を返す ! 演
      算子と、ビット毎の論理否定演算子 (bitwise logical negation operator) の ~ とを混同しない
      ようにしてください。


      Overload new (new をオーバーロードする)
      Overload the "new" operator - much more dangerous than overloading the 
      +-/*. This can cause total havoc if overloaded to do something different from it's 
      original function (but vital to the object's function so it's very difficult to change). 
      This should ensure users trying to create a dynamic instance get really stumped. You 
      can combine this with the case sensitivity trickalso have a member function, and 
      variable called "New".

      四則演算子 (+-/*) のオーバーロードよりもさらに危険な new 演算子のオーバーロードをしま
      す。 もともとの関数とは異なる何かを行うためにオーバーロードがすでにされている場合には
      この手法は total havoc を引き起こします。そのオブジェクトの持つ関数にとっては致命的な
      もの (vital) なので変更はとても難しいものになります。本当に stumped な動的インスタンス
      の生成をユーザーが確かに試みるようにすべきです。この手法は "New" という名前のメンバー
      関数や変数を持つという case sensitivity trick と組み合わせることもできます。


      #define
      #define in C++ deserves an entire essay on its own to explore its rich possibilities
      for obfuscation. Use lower case #define variables so they masquerade as ordinary
      variables. Never use parameters to your preprocessor functions. Do everything with
      global #defines. One of the most imaginative uses of the preprocessor I have heard of
      was requiring five passes through CPP before the code was ready to compile. Through
      clever use of defines and ifdefs, a master of obfuscation can make header files
      declare different things depending on how many times they are included. This becomes
      especially interesting when one header is included in another header. Here is a
      particularly devious example:

      C++ における #define にはその難読化のための大きな可能性 (rich possibilities) を explore
      するために一本丸ごと essay をしたててもいいだけの価値があります。#define を通した小文字の
      変数を使って普通の変数 (ordinary variables) の振りをさせます。あなたのプリプロセッサー関
      数に対するパラメーターは決して使ってはいけません。すべてをグローバルな #defines によって
      行います。わたしが聞いたことのあるプリプロセッサーの最も imaginative な使い方の一つは、
      コードがコンパイルできるようにするために CPP を 5 回通すことを要求するものでした。難読化
      (obfuscation) の達人は、define と ifdef を賢く使うことを通じて自分が何回 include されたか
      によって異なるものを宣言するヘッダーファイルを作成するのを可能にしました。あるヘッダーが
      別のヘッダーから取り込まれているときにこの手法はとても興味深いものになります。次に挙げる
      のは特に devious な例です:

            #ifndef DONE

            #ifdef TWICE

            // put stuff here to declare 3rd time around
            void g(char* str);
            #define DONE

            #else // TWICE
            #ifdef ONCE

            // put stuff here to declare 2nd time around
            void g(void* str);
            #define TWICE

            #else // ONCE

            // put stuff here to declare 1st time around
            void g(std::string str);
            #define ONCE

            #endif // ONCE
            #endif // TWICE
            #endif // DONE

This one gets fun when passing g() a char*, because a different version of g() will be 
called depending on how many times the header was included.

This one gets fun when passing g() a char* ですが、
それはこのヘッダーファイルが何回 include されたかによって
どのバージョンの g() が呼び出されるのかが異なるためです。


      Compiler Directives (コンパイラーディレクティブ)
      Compiler directives were designed with the express purpose of making the same code
      behave completely differently. Turn the boolean short-circuiting directive on and 
      off repeatedly and vigourously, as well as the long strings directive. 

      コンパイラーディレクティブは同じコードに全く異なる振る舞いをさせることを目的として
      設計されました。boolean short-circuiting ディレクティブを繰り返し vigourously に on
      にしたり off にしたりしましょう。

  

2010年03月17日

■_

・横須賀線
ということで、 先週の土曜日に開業した横須賀線武蔵小杉駅から横須賀線に乗って秋葉原に出てみました。 れまでの目黒線(→目黒→秋葉原)、日比谷線(→中目黒→秋葉原)に比べると かなり時間が短縮されている感じがします。まあ駅に出るまでがちょっと距離があるんですが (南武線/東横線/目黒線 の武蔵小杉駅からは400m弱くらいあるらしい)。 あと、今回は新橋駅で山手線に乗り換えて秋葉原へ出たのですが、 時間帯のせいもあるんでしょうけどちと込み方がきつかった。 東京駅で乗り換えた方が良かったのかなあ。

■_ EDOM

Cでプログラム組んでる人なら分かるんじゃないかなあ>どめいんえらー


時間城年代記:エラーメッセージの意味がわかんない

 Pythonのmath.log10やmath.logに0を渡すと、'domain error'と出る。
 「薄いCラッパだから、ヘンなエラーが出るよ」とは聞いていたけど、とりあえず原因が特定
  できないエラーメッセージはなんとかならんものだろうか。

 とりあえず、こんなコードを書いていた。

import math
def loosePrint(n):
  for x in range(1, n+1):
    z = 10 ** int(math.log10(x))
    if x > z and x % z:
      continue
    print(x)

 1,2,3..から10,20,30..100,200,300,...1000,2000,3000なんて表示できる簡単なプログラムな
  のだが、rangeの最初にうっかり1,を書き忘れて、0が入ってエラーが出た、という次第。
 しかし、'ValueError: math domain error'とか出たら、何が原因だかわかんないよ。 

いやあこの手の引数間違いって domain error でしょ。 と思って


#define	EDOM 33		/* Math arg out of domain of func */
#define	ERANGE 34	/* Math result not representable */

C でごにょごにょしてみると

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int
main(int argc, char *argv[])
{
    log(0.0);
    perror("");
    printf("%d\n", errno);
    return 0;
}
Result too large
34

…あれ?

ということでちょっとぐぐるセンセにお伺いしてみますれば こんなページがみつかりました。


数値計算ガイド: F - 規格への準拠

(略)

SVID の実装
以下の表に示す libm 関数により、SVID に対応するオペランドチェックまたは結果チェックが
行われます。-xlibmil 経由で libm のインライン展開テンプレートを使用する C プログラムか
ら呼び出されたとき、平方根用のハードウェア命令 fsqrt[sd] が関数コールの代わりに使用さ
れるため、sqrt 関数は SVID に準拠しない唯一の関数です。

表 F-1 例外のケースと libm 関数
関数 	errno 	エラーメッセージ 	SVID 	X/Open 	IEEE
acos(|x|>1) 	EDOM 	DOMAIN 	0.0 	0.0 	NaN
acosh(x<1) 	EDOM 	DOMAIN 	NaN 	NaN 	NaN
asin(|x|>1) 	EDOM 	DOMAIN 	0.0 	0.0 	NaN
atan2((+-0,+-0) 	EDOM 	DOMAIN 	0.0 	0.0 	+-0.0,+-pi
atanh(|x|>1) 	EDOM 	DOMAIN 	NaN 	NaN 	NaN
atanh(+-1) 	EDOM/ERANGE 	SING 	+-HUGE (EDOM) 	+-HUGE_VAL (ERANGE) 	+-infinity
cosh overflow 	ERANGE 	- 	HUGE 	HUGE_VAL 	infinity
exp overflow 	ERANGE 	- 	HUGE 	HUGE_VAL 	infinity
exp underflow 	ERANGE 	- 	0.0 	0.0 	0.0
fmod(x,0) 	EDOM 	DOMAIN 	x 	NaN 	NaN
gamma(0 or -integer) 	EDOM 	SING 	HUGE 	HUGE_VAL 	infinity
gamma overflow 	ERANGE 	- 	HUGE 	HUGE_VAL 	infinity
hypot overflow 	ERANGE 	- 	HUGE 	HUGE_VAL 	infinity
j0(|x| > X_TLOSS) 	ERANGE 	TLOSS 	0.0 	0.0 	correct answer
j1(|x| > X_TLOSS) 	ERANGE 	TLOSS 	0.0 	0.0 	correct answer
jn(|x| > X_TLOSS) 	ERANGE 	TLOSS 	0.0 	0.0 	correct answer
lgamma(0 or -integer) 	EDOM 	SING 	HUGE 	HUGE_VAL 	infinity
lgamma overflow 	ERANGE 	- 	HUGE 	HUGE_VAL 	infinity
log(0) 	EDOM/ERANGE 	SING 	-HUGE(EDOM) 	-HUGE_VAL (ERANGE) 	infinity
log(x<0) 	EDOM 	DOMAIN 	-HUGE 	-HUGE_VAL 	NaN
log10(0) 	EDOM/ERANGE 	SING 	-HUGE(EDOM) 	-HUGE_VAL (ERANGE) 	-infinity
log10(x<0) 	EDOM 	DOMAIN 	-HUGE 	-HUGE_VAL 	NaN
loglp(-1) 	EDOM/ERANGE 	SING 	-HUGE(EDOM) 	-HUGE_VAL (ERANGE) 	-infinity
loglp(x<-1) 	EDOM 	DOMAIN 	NaN 	NaN 	NaN
pow(0,0) 	EDOM 	DOMAIN 	0.0 	1.0 (no error) 	1.0 (no error)
pow(NaN,0) 	EDOM 	DOMAIN 	NaN 	NaN 	1.0 (no error)
pow(0,neg) 	EDOM 	DOMAIN 	0.0 	-HUGE_VAL 	+-infinity
pow(neg, non-integer) 	EDOM 	DOMAIN 	0.0 	NaN 	NaN
pow overflow 	ERANGE 	- 	+-HUGE 	+-HUGE_VAL 	+-infinity
pow underflow 	ERANGE 	- 	+-0.0 	+-0.0 	+-0.0
remainder(x,0) 	EDOM 	DOMAIN 	NaN 	NaN 	NaN
scalb overflow 	ERANGE 	- 	+-HUGE_VAL 	+-HUGE_VAL 	+-infinity
scalb underflow 	ERANGE 	- 	+-0.0 	+-0.0 	+-0.0
sinh overflow 	ERANGE 	- 	+-HUGE 	+-HUGE_VAL 	+-infinity
sqrt(x<0) 	EDOM 	DOMAIN 	0.0 	NaN 	NaN
y0(0) 	EDOM 	DOMAIN 	-HUGE 	-HUGE_VAL 	-infinity
y0(x<0) 	EDOM 	DOMAIN 	-HUGE 	-HUGE_VAL 	NaN
y0(x > X_TLOSS) 	ERANGE 	TLOSS 	0.0 	0.0 	correct answer
y1(0) 	EDOM 	DOMAIN 	-HUGE 	-HUGE_VAL 	-infinity
y1(x<0) 	EDOM 	DOMAIN 	-HUGE 	-HUGE_VAL 	NaN
y1(x > X_TLOSS) 	ERANGE 	TLOSS 	0.0 	0.0 	correct answer
yn(n,0) 	EDOM 	DOMAIN 	-HUGE 	-HUGE_VAL 	-infinity
yn(n,x<0) 	EDOM 	DOMAIN 	-HUGE 	-HUGE_VAL 	NaN
yn(n, x> X_TLOSS) 	ERANGE 	TLOSS 	0.0 	0.0 	correct answer

例外のケースと libm 関数についての一般的注意事項

表 F-1 には、各規格の影響を受ける libm 関数がすべてリストされています。値 X_TLOSS は、
<values.h> に定義されています。SVID では、<math.h> に対し HUGE を MAXFLOAT と
定義するように要求しています。これはおよそ 3.4e+38 です。HUGE_VAL は libc で無限大と定
義されています。errno は、C プログラムおよび C++ プログラムにアクセス可能なグローバル
変数です。

<errno.h> では、errno 用として考えられる値を 120 個程度定義しています。数学ライ
ブラリが使用するものが 2 つあります。ドメインエラー用の EDOM と範囲エラー用の ERANGE 
です。intro(3) と perror(3) を参照してください。

ということで、log(0) は EDOM でも ERANGE でもいいっぽいですねえ。 こういうときにせっかく買った H &S が行方不明ってのはどーゆーことだ!

#include 
#include 
#include 

int
main(int argc, char *argv[])
{
    log(-1.0);
    perror("");
    printf("%d\n", errno);
    return 0;
}

Domain error
33

ふむ。

おまけ。

>erl -e "print log(0.0)"
Can't take log of 0 at -e line 1.

>uby -e "puts Math.log(0.0)"
-e:1:in `log': Result too large - log (Errno::ERANGE)
        from -e:1

S・P・ハービソン3世とG・L・スティール・ジュニアのCリファレンスマニュアル

■_ このタイミングでも月例リリースするのか

4/1まであと二週間ほどなのに。


Parrot 2.2.0 Released! | Parrot VM
Parrot 2.2.0 Released!
Submitted by cotto on Tue, 03/16/2010 - 17:23.

"I can't understand why people are frightened of new ideas. I'm frightened of the old ones.”
- John Cage

On behalf of the Parrot team, I'm proud to announce Parrot 2.2.0
"Like Clockwork." Parrot (http://parrot.org/) is a virtual machine aimed
at running all dynamic languages.

Parrot 2.2.0 is available on Parrot's FTP site, or follow the
download instructions at http://parrot.org/download. For those who would like to 
develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the 
source code repository to get the latest and best Parrot code.

Parrot 2.2.0 News:
- Core changes
+ Most internal allocations now use the GC
+ RNG non-randomness fixes
+ Elimination of much dead code
- API changes
+ PMCs can now be initialized from an int
+ Many legacy ops are removed
- Platforms
+ Sun cc and Intel icc support have been restored
+ Compiler invocation no longer goes through a Perl script
- Tools
+ NCI thunks are now generated by self-hosted PIR code

Many thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next scheduled release is 20 April 2010.

Enjoy!

dead codeの削除とか。

■_ 書法

書法と作法は自腹で買って読めとお師匠様に言われましてですね(以下何度も書いたことなので略)

最近見つけた、割と面白い話題を取り上げ続けている blog で書法(の原著)を取り上げてました。

Programming Books, part 2: The Elements of Programming Style « The Reinvigorated Programmer
The Reinvigorated Programmer

Programming Books, part 2: The Elements of Programming Style

March 6, 2010

I said in the first part of this series that one of the books I wanted to talk about 
was written in 1974.  My colleague Dennis Schafroth guessed that it might be 
Kerninghan and Ritchie's classic, The C Programming Language, but the first edition of 
that book actually came out in 1978.  But I awarded half a point anyway, because the 
book I had in mind (A) was co-written by Brian W. “Water buffalo” Kernighan, and (B) 
had a second edition in 1978, the same year as K&R.  It is Kernighan and 
Plauger's The Elements of Programming Style (amazon.com, amazon.co.uk)

(略)

I'm not going to claim that the book hasn't aged.  As you can see from the extract 
above, the typography looks very primitive (it was done on an early version of troff), 
and rules such as “Avoid the Fortran arithmetic IF” and “Initialize constants with 
DATA statements or INITIAL attributes; initialize variables with executable code” 
just don't apply any more in the post-FORTRAN era.  Another rule, “Write first in an 
easy-to-understand pseudo-language; then translate into whatever language you have to 
use”, is also not applicable now that languages like Python and Ruby can read and 
execute the equivalent of the old pseudo-code.  This in itself demonstrates the value 
of one of K&P's more enduring rules: “Let the machine do the dirty work”.  Yes 
indeed: translating pseudo-code into executable code should not be left to humans.

But most of the rules are timeless, and remain as true and important today in 2010 as 
they were in 1974.  The first rule after the introduction remains one of my favourites: 
“Say what you mean, simply and directly”.  (You may not believe it, reading this 
blog, but I try to apply this to my prose writing as well as my programming.)  Others 
that we should all try to live by: “Each module should do one thing well”; “Let the 
data structure the program”; “Make it right before you make it faster” and “Keep 
it right when you make it faster”.


This summary is designed to give a quick review of the points we covered in the book. 
Remember as you read the rules that they were presented in connection with one or more 
examples — go back and reread the pertinent section if a rule doesn't call them to 
mind.

To paraphrase an observation in The Elements of Style, rules of programming style, 
like those of English, are sometimes broken, even by the best writers. When a rule is 
broken, however, you will usually find in the program some compensating merit, 
attained at the cost of the violation. Unless you're certain of doing as well, you 
will probably do best to follow the rules.

Introduction

    * Write clearly — don't be too clever.

Expressions

    * Say what you mean, simply and directly.
    * Use library functions.
    * Avoid temporary variables.
    * Write clearly — don't sacrifice clarity for “efficiency”.
    * Let the machine do the dirty work.
    * Replace repetitive expressions by calls to a common function.
    * Parenthesize to avoid ambiguity.
    * Choose variable names that won't be confused.
    * Avoid the Fortran arithmetic IF.
    * Avoid unnecessary branches.
    * Use the good features of a language; avoid the bad ones.
    * Don't use conditional branches as a substitute for a logical expression.
    * Use the “telephone test” for readability.

Control Structure

    * Use DO-END and indenting to delimit groups of statements.
    * Use IF-ELSE to emphasize that only one of two actions is to be performed.
    * Use DO and DO-WHILE to emphasize the presence of loops.
    * Make your programs read from top to bottom.
    * Use IF … ELSE IF … ELSE IF … ELSE … to implement multi-way branches.
    * Use the fundamental control flow structures.
    * Write first in an easy-to-understand pseudo-language; then translate into 
      whatever language you have to use.
    * Avoid THEN-IF and null ELSE.
    * Avoid ELSE GOTO and ELSE RETURN.
    * Follow each decision as closely as possible with its associated action.
    * Use data arrays to avoid repetitive control sequences.
    * Choose a data representation that makes your program simple.
    * Don't stop with your first draft.

Program Structure

    * Modularize. Use subroutines.
    * Make the coupling between modules visible.
    * Each module should do one thing well.
    * Make sure every module hides something.
    * Let the data structure the program.
    * Don't patch bad code — rewrite it.
    * Write and test a big program in small pieces.
    * Use recursive procedures for recursively-defined data structures.

Input and Output

    * Test input for validity and plausibility.
    * Make sure input cannot violate the limits of your program.
    * Terminate input by end-of-file or marker, not by count.
    * Identify bad input; recover if possible.
    * Treat end of file conditions in a uniform manner.
    * Make input easy to prepare and output self-explanatory.
    * Use uniform input formats.
    * Make input easy to proofread.
    * Use free-form input when possible.
    * Use self-identifying input. Allow defaults. Echo both on output.
    * Localize input and output in subroutines.

Common Blunders

    * Make sure all variables are initialized before use.
    * Don't stop at one bug.
    * Use debugging compilers.
    * Initialize constants with DATA statements or INITIAL attributes; initialize 
      variables with executable code.
    * Watch out for off-by-one errors.
    * Take care to branch the right way on equality.
    * Avoid multiple exits from loops.
    * Make sure your code “does nothing” gracefully.
    * Test programs at their boundary values.
    * Program defensively.
    * 10.0 times 0.1 is hardly ever 1.0
    * Don't compare floating point numbers just for equality.

Efficiency and Instrumentation

    * Make it right before you make it faster.
    * Keep it right when you make it faster.
    * Make it clear before you make it faster.
    * Don't sacrifice clarity for small gains in “efficiency”.
    * Let your compiler do the simple optimizations.
    * Don't strain to re-use code; reorganize instead.
    * Make sure special cases are truly special.
    * Keep it simple to make it faster.
    * Don't diddle code to make it faster — find a better algorithm.
    * Instrument your programs. Measure before making “efficiency” changes.

Documentation

    * Make sure comments and code agree.
    * Don't just echo the code with comments — make every comment count.
    * Don't comment bad code — rewrite it.
    * Use variable names that mean something.
    * Use statement labels that mean something.
    * Format a program to help the reader understand it.
    * Indent to show the logical structure of your program.
    * Document your data layouts.
    * Don't over-comment.

Blog at WordPress.com. Theme: Cutline by Chris Pearson.

日本語版も絶版になっていないはずなので、まあ一遍くらいは読んでみるのをオススメ。 図書館でも見つけられると思います。
プログラム書法 第2版

■_ 本日の巡回から

■_ あーもー

いろいろgdgd ○| ̄|_

2010年03月16日

■_

寒暖の差が激しくて大変すね。

■_ 冗談ですか日向さん

みずしまさんがばっさりやっちゃったし放置しようかなとも思ったのですが、 やっぱり気になるので巻末にあった問い合わせ先に以下のような 文面の質問メールを出してみました。

「やさしいScala入門」を購入して読んでみたのですが、疑問に思うところがありますので
メールいたしました。

28pの「暗黙の型変換」のところで

同じ種類の型の場合、サイズが大きい型の変数などにサイズが小さい型の値を代入すると、
暗黙のうちに型が変換されます。次に示すのは、暗黙の型変換が行われる例です。

(中略)

同様に、Float型の値をDouble型の変数に代入するときも、暗黙の型変換が行われます。ただし、
整数から浮動小数点数に変換されるときや、32ビットIEEE754 単精度浮動小数点数から 64ビット
IEEE754 倍精度浮動小数点数に変換されるときに、数値の内部表現に限界があるために誤差が発
生することがあります。


という部分があるのですが 32ビットの単精度浮動小数点数から64ビットの浮動小数点数に
変換される場合には後者の方が範囲が広いし精度も高く、基数も同じなので誤差が発生
することはないのと思います。もし、わたしの勘違いということであれば、ひとつでも
実例を挙げていただけませんでしょうか? 整数から浮動小数点数に変換の方も、情報落ち
が発生する条件はかなり限定されると思います。

以上よろしくお願いします。
  

んでまあ、「変換」と書いてて「代入時に行われる変換」とはっきり書かなかった こっちも抜かったとは思うんですが、編集さん経由で返ってきた返事はというと

・浮動小数点数の扱い(誤差)の詳細な話は本書の対象とするところではない
・参考リソースで挙げている文献を当たれ
・それでも足りなければ、誤差や技術計算の資料を探して調べてみろ

といった趣旨のものでした。 んでまあ、参考リソースつーと

[1] The Scala Programming Lanuage
[2] Develper Resouces for Java Technology
[3] Scala スケーラブルプログラミング Martin Odersly ほか
[4] コンピュータサイエンス入門 日向俊二
[5] 知らないと恥をかくプログラミングの常識 日向俊二
[6] http://www.eclipse.org/
[7] Scala IDE for Eclipse http://www.scala-lang.org/node/94
[8] http://ja.netbeans.org/
[9] Scala Plugin for NetBeans http://wiki.netbeans.org/Scala
[10] InteliJ http://www.jetbrains.com/idea/
[11] Scala Plugin for InteliJ IDEA http://plugins.intellij.net/plugin/?id=1347
[12] Java API ドキュメントなどのダウンロード http://java.sun.com/javase/ja/6/download.html
[13] 速攻即決! 逆引きハンドブックJava 日向俊二

というラインナップで、 問題のページの注釈記号を見るとおそらく [4] と [5] のことを指しているのだろうとは思うんですが 質問のメールを出す前にすでにチェックしてたりするんですよね。 今手元にないのでちょっと正確ではありませんが、 よくある、十進数の 0.1 が(2を基数とする)浮動小数点数では正しく表現できないとか そういった類の話で、今回質問した(少なくともこっちはそのつもりだった) 「Float型からDouble型へ代入するときに行われる型変換によって発生する誤差」 に関係するような話題はありませんでした。 まあこれ以上深入りするこたないか。

■_

なんか盛り上がってるし。


C++0x 8
620 デフォルトの名無しさん [sage] 2010/03/16(火) 01:06:29 ID: Be:
    >>613
    「C++学園の人々」的に頼む。 

621 デフォルトの名無しさん [sage] 2010/03/16(火) 01:09:23 ID: Be:
    本の虫って査読をブログで募集するくらい学会で浮いてるの? 

622 デフォルトの名無しさん [sage] 2010/03/16(火) 01:13:34 ID: Be:
    学会って? 話が見えないが 

623 デフォルトの名無しさん [sage] 2010/03/16(火) 01:18:08 ID: Be:
    ごめん寄与のとこ見たらニートっぽかった 

624 デフォルトの名無しさん [sage] 2010/03/16(火) 01:20:50 ID: Be:
    禿は校長で本の虫の人は用務員 

625 デフォルトの名無しさん [sage] 2010/03/16(火) 01:37:43 ID: Be:
    ○左辺値
    名前を持ってる普通の生徒。

    ○右辺値
    聴講生。特に名前を持たない生徒。それをいいことに周りから弄ばれる不憫な存在。

    ●右辺値参照さん
    聴講生にあだ名を付けて仲良くなれる能力を持つ。

    さて、「右辺値参照さんと仲良くなった聴講生」は右辺値参照さんにあだ名をもらったのでもはや名無しではない。
    だが聴講生の身分には違いないので周りに弄ばれることにも変わりない。
    右辺値とも左辺値とも違うヘンな性質になってしまった。

    というわけで、聴講生をさらに分類して区別することにした

    ○中辺値
    右辺値参照さんにあだ名をもらった聴講生。

    ○超右辺値
    右辺値参照さんにあだ名をもらってない聴講生。名前はない。

    「右辺値」はこの2つの総称、つまり弄んでもいい生徒ということになった。

    それと、「名前を持ってて呼ぶことができる生徒」というのがまどろっこしいのでこれに名前を付けた。
    ○大左辺値
    左辺値と中辺値の総称。本来の名前か、右辺値参照さんにもらったあだ名を持ってるので
    先生は授業中に名前を呼んで当てることが出来る。


    ごめん余計わかりにくくなった気がする 

630 デフォルトの名無しさん [sage] 2010/03/16(火) 14:14:01 ID: Be:
    r,x,l と rx,lx でいいじゃんかよ
    gl とか pr とか超とか大とかが分かりやすい?ギャグがそれ 

631 [―{}@{}@{}-] デフォルトの名無しさん [sage] 2010/03/16(火) 14:57:19 ID: Be:
    >C++0x規格を厳格に実装したコンパイラがそもそも
    >出るのがいつになるのだろうか?ww

    EDG のフロントエンドがもうじき実装を提供し始めるから、それから。
    独自実装の gcc や msc はもっと後でしょうね 

634 デフォルトの名無しさん [sage] 2010/03/16(火) 20:49:32  ID: Be:
    >>630
    それだとrvalueの意味が変わっちゃうからダメ 

635 デフォルトの名無しさん [sage] 2010/03/16(火) 21:03:04 ID: Be:
    ところでpを訳すと超になるの?
    なんとなくpureの略っぽい気がするから
    最初純右辺値さんだと思った 

636 185 [sage] 2010/03/16(火) 21:07:20 ID: Be:
    >>635
    俺もそう思う。
    ってか、>606 に pure って書いてある。 

637 デフォルトの名無しさん [sage] 2010/03/16(火) 21:08:31 ID: Be:
    pureの略だから純で合ってるけど超の方が強そうじゃん

    prvalueが「純粋な右辺値」ってのもなんか違う気がするし 

638 デフォルトの名無しさん [sage] 2010/03/16(火) 22:46:49 ID: Be:
    pure virtual とか純粋仮想って言ってるし純粋でいいよ
    純だと順かと勘違いしそうだし 

639 デフォルトの名無しさん [sage] 2010/03/16(火) 22:59:20 ID: Be:
    発音的にも
    じゅんうへんち
    だと発音しにくいから
    純粋右辺値
    がいいな 

640 デフォルトの名無しさん [sage] 2010/03/16(火) 23:35:14 ID: Be:
    こんなんでどう?
    lvalue  = left value      : 左辺値
    xvalue = expiring value    : 遷移値
    prvalue = pure right value  : 純粋右辺値
    glvalue = general left value? : 汎左辺値
    rvalue = right value      : 右辺値 

641 デフォルトの名無しさん [sage] 2010/03/16(火) 23:36:37 ID: Be:
    >>639
    同意。

    glvalues も「広義左辺値」や「拡張左辺値」、「拡大左辺値」とかの方が分かりやすいと思う

    > All expressions are now divided into three "value categories":
    >
    > * "lvalues" are the same as what's meant traditionally by lvalue.
    > * "xvalues" are objects created by rvalue reference operations (sometimes previously called "rvalue reference objects"). The "x" can be for "eXpiring value" or a cross between lvalues and rvalues.
    > * "prvalues" are the new name for traditional rvalues (i.e., excluding the xvalue cases). The "p" is for "pure rvalue".
    >
    > There are two compound categories:
    >
    > * "glvalues" are lvalues and xvalues. These are things that have dynamic type and object identity.
    > * "rvalues" are xvalues and prvalues. These are (as now in the draft) things that are potentially movable.

                     ┌左辺値(lvalues)
                     │ 〔従来の左辺値〕
    広義左辺値(glvalues) ─<
    〔名前を持つ〕        │
                     └中辺値(xvalues)                     ┐
                       〔右辺値参照でバインドされた名前付き右辺値〕 │
                                                      >─ 右辺値(rvalues)
                      純粋右辺値(prvalues)                  ┘    〔ムーブ可〕
                       〔従来の右辺値、無名一時オブジェクトなど〕 

642 デフォルトの名無しさん [sage] 2010/03/16(火) 23:38:22 ID: Be:
    ぶっちゃけ左辺値とか右辺値とかわけわからんのだが
    これないと記述出きないくらい必要なこととかあるのかね 

643 641 [sage] 2010/03/16(火) 23:52:49 ID: Be:
    >>640
    かぶった(汗)

    個人的には↓の方が良かった
                               ┌左辺値(lvalue、left value)
                               │ 〔従来の左辺値〕
    名前付きの値(nvalues、named value) ─<
    〔名前を持つ〕                  │
                               └中辺値(xvalue、expiring value)            ┐
                                 〔右辺値参照でバインドされた名前付き右辺値〕 │
                                                                >─ ムーブ可能な値(mvalue、movable value)
                                右辺値(rvalue、right value)               ┘    〔ムーブ可〕
                                 〔従来の右辺値、無名一時オブジェクトなど〕 

644 デフォルトの名無しさん [sage] 2010/03/17(水) 00:10:10 ID: Be:
    JISがどんなセンスのない訳語を当てるか楽しみだ 

■_ 本日の巡回から

■_

訳もそれなりに貯金があるけど、最後の仕上げとかやってる気力がないので 今宵はこれまでにいたしとうございまする ○| ̄|_

2010年03月15日

■_

・オライリー
考えてみると、すぐに必要だとかすぐ読みたいというものでなければ 各種イベント(LLなんとかとか)のときの出張販売で買うって手があるんだよなあ。 10% 引きとかノベルティがついたりするし (ノベルティには目のないわたし)。

・うへ
今月末のカードの引き落としがちょっと予想より多め。 BOXもあるし、DVDやらBDはもうちょっとしぼらんといかんなあ。

・属性
attribute と property って(traitも?)、 どれも日本語にすると属性とか性質とかその辺のニュアンスの言葉になるっぽいけど 違いが良くわからん。 まあ、英英辞典で調べろっつー話なんでしょうけど。

■_ xyzzy

ちょっと調べてみる。 ソースのディレクトリにはやたらとファイルがあるなあ。ということで どんなもんか ruby スクリプトでちょっとごにょごにょ。

Dir.glob(['*.cc', '*.h']) do |e|
  size = File.size(e)
  line = File.open(e, 'r') {|f| f.readlines.size}
  print "%20s\t%4d\t%8d\n" % [e, line, size]
end
            alloc.cc	 246	    5839
           arc-if.cc	 236	    6740
         archiver.cc	1251	   31522
            array.cc	 670	   18440
           assert.cc	  41	     854
            backq.cc	 262	    6956
           bignum.cc	1442	   31594
            binfo.cc	 279	    5755
       buffer-bar.cc	 493	   11665
           Buffer.cc	1933	   46053
      byte-stream.cc	 155	    3516
         bytecode.cc	1624	   35485
              ces.cc	 780	   22307
             char.cc	 645	   15043
           chname.cc	 162	    3684
       ChooseFont.cc	 432	   12603
            chunk.cc	 396	    9349
      ColorDialog.cc	 820	   22115
           colors.cc	  84	    2290
              com.cc	 275	    7618
             conf.cc	 657	   17009
            ctl3d.cc	  83	    2166
             data.cc	2855	   76872
              dde.cc	 427	   10724
          dialogs.cc	1575	   41563
             disp.cc	3813	  111632
              dll.cc	 477	   10777
              DnD.cc	1430	   34887
              doc.cc	 116	    3529
          dockbar.cc	2538	   65590
              dpp.cc	 575	   13006
            edict.cc	 143	    4110
           encdec.cc	 313	    7268
         encoding.cc	2730	   63954
          environ.cc	 869	   23702
             eval.cc	2298	   56143
           except.cc	 457	   12918
           fileio.cc	1476	   38540
            filer.cc	3168	   79610
            fnkey.cc	 470	    9833
             font.cc	 406	   11083
   gen-char-width.cc	  67	    1723
         gen-ctab.cc	 258	    5551
    gen-fontrange.cc	  86	    2188
       gen-ibmext.cc	 463	   10873
 gen-iso2022state.cc	 131	    3491
gen-jisx0212-hash.cc	  56	    1320
gen-jisx0212-width.cc	  54	    1215
         gen-ktab.cc	 241	    7141
 gen-lucida-width.cc	  74	    2049
          gen-msg.cc	 126	    2909
         gen-syms.cc	2911	   94348
      gen-ucs2tab.cc	1143	   31298
     gen-utf2sjis.cc	  50	    1423
         gen-vinf.cc	  59	    1641
             gime.cc	 250	    5877
             glob.cc	 494	   12687
             guid.cc	  20	    1080
             gzip.cc	 228	    5085
             hash.cc	 569	   14693
          hashpjw.cc	  57	    1029
             init.cc	1015	   29525
           insdel.cc	1990	   51000
              ipc.cc	 132	    2195
            kanji.cc	1049	   27214
              kbd.cc	1457	   35765
           keymap.cc	 552	   12792
         largeint.cc	 209	    3531
          ldialog.cc	2022	   54421
              lex.cc	 428	   11209
             list.cc	 801	   15433
           listen.cc	 172	    4060
           lprint.cc	4271	   98705
            lread.cc	2188	   57073
             md5c.cc	 300	    9402
             menu.cc	 824	   22036
          minibuf.cc	1013	   27306
             mman.cc	  44	    1095
            mouse.cc	 450	   10583
             move.cc	2512	   63194
           msgbox.cc	 413	   10003
           number.cc	1190	   26162
          oledata.cc	 872	   22860
          package.cc	 745	   21777
             pane.cc	 537	   11110
         pathname.cc	2444	   62376
            popup.cc	 302	    7091
           popupl.cc	 238	    5433
             pred.cc	 618	   11798
          preview.cc	1010	   25034
            print.cc	2169	   55871
         printdlg.cc	1075	   31551
          process.cc	1507	   36412
           random.cc	 150	    3301
            regex.cc	2689	   67308
         resolver.cc	 208	    5137
           search.cc	1579	   40685
         sequence.cc	1183	   28938
             sha1.cc	 182	    5830
           signal.cc	 826	   23206
             sock.cc	 528	   12780
         sockinet.cc	 154	    3433
         statarea.cc	 310	    6380
           stdctl.cc	 217	    5209
           StrBuf.cc	 268	    5199
           stream.cc	2071	   55023
           string.cc	1253	   28504
        structure.cc	 299	    7707
           symbol.cc	 176	    3582
           syntax.cc	3984	  107223
           sysdep.cc	 255	    5915
           thread.cc	  65	    1215
           toplev.cc	1877	   50527
             ucs2.cc	 609	   19312
             undo.cc	 557	   12476
          usertab.cc	 412	    8870
         usertool.cc	 459	   10571
            utils.cc	 552	   11686
           utimer.cc	 175	    3690
           vector.cc	 414	   12324
          version.cc	  39	    1610
              vfs.cc	 507	   14003
            wheel.cc	 285	    7202
           Window.cc	3456	   97910
          winhelp.cc	 462	   10861
          wstream.cc	  86	    2047
             xdde.cc	 274	    6114
            xlist.cc	  76	    1387
              xpi.cc	  50	    1131
         xyzzycli.cc	 530	   11822
         xyzzyenv.cc	 225	    5047
             alloc.h	  63	    1533
            arc-if.h	 214	    6712
          archiver.h	 229	    8318
             array.h	 226	    5126
            bignum.h	 268	    6008
             binfo.h	  36	    1299
        buffer-bar.h	  58	    1903
            Buffer.h	 936	   24839
       byte-stream.h	 179	    5128
             cdecl.h	 172	    4098
               ces.h	 156	    3334
              char.h	  34	     465
           charset.h	 549	   14858
        ChooseFont.h	  45	    1108
            chtype.h	 374	    9083
             chunk.h	  54	     893
             clock.h	  15	     207
           closure.h	  91	    1391
       ColorDialog.h	 141	    3900
            colors.h	  30	     535
               com.h	  68	    1289
          comm-arc.h	 364	   12782
              conf.h	 124	    5136
              cons.h	  49	     662
             ctl3d.h	  36	     638
           ctxmenu.h	  44	    1363
              data.h	 136	    2963
             dataP.h	  53	    2049
           dialogs.h	  51	    1090
               dll.h	 195	    3934
               DnD.h	 180	    4748
           dockbar.h	 441	   14353
        dyn-handle.h	  98	    1638
                ed.h	 571	    9592
          encoding.h	 766	   21637
           environ.h	 152	    3196
             error.h	  39	     587
            except.h	  22	     437
             filer.h	 639	   12862
             fnkey.h	  70	    1879
               fns.h	 185	    5651
              font.h	 126	    3467
         fontrange.h	 823	   45548
          function.h	 106	    2237
              gime.h	  45	    1337
              glob.h	  59	     964
              hash.h	  85	    1435
               ipc.h	  37	     648
    jisx0212-width.h	  23	    1073
             kanji.h	  15	     350
               kbd.h	 324	    6861
          largeint.h	  18	     423
           ldialog.h	 189	    4369
               lex.h	 137	    2341
              lisp.h	 608	   14567
              list.h	  71	    2823
            listen.h	  20	     302
      lucida-width.h	  38	    2219
         mainframe.h	  47	    1107
               md5.h	  43	    1366
           message.h	  25	     374
              mman.h	  28	     535
             mouse.h	  60	    1530
          mousemsg.h	  53	    1140
            msgbox.h	  63	    1791
            msgdef.h	 658	   23225
            number.h	 333	    6098
               ofn.h	  39	     919
           oleconv.h	  41	     961
           oledata.h	  88	    1955
           package.h	 102	    1834
              pane.h	 100	    2295
          pathname.h	  18	     274
           preview.h	 121	    2734
             print.h	 309	    7854
          printdlg.h	  69	    2278
           process.h	 105	    1643
            random.h	  55	     944
           readtab.h	 109	    2494
            reconv.h	  29	     556
             regex.h	 119	    3498
          resolver.h	  54	    1097
          resource.h	 466	   21261
          safe_ptr.h	  17	     302
          sequence.h	 111	    2123
              sha1.h	  23	     477
            signal.h	  67	    2002
              sock.h	 236	    6375
          sockimpl.h	  57	    3099
          sockinet.h	  61	    1736
          statarea.h	  54	    1291
            StrBuf.h	 127	    1978
            stream.h	 383	    9111
            string.h	 197	    4621
         structure.h	 181	    3127
            symbol.h	  87	    1943
          symtable.h	  48	     745
            syntax.h	 173	    3745
        syntaxinfo.h	  78	    1745
            sysdep.h	 111	    2261
            thread.h	  38	     815
             timer.h	  32	     469
             trace.h	  87	    1213
           ucs2tab.h	8886	  580259
             utils.h	 115	    2623
            utimer.h	  50	    1159
            vector.h	  67	    1408
           version.h	  19	     487
               vfs.h	  47	    2843
            vwin32.h	  53	    1032
           waitobj.h	  46	     769
             wheel.h	  26	     484
            Window.h	 677	   20419
                wm.h	  31	     693
           wstream.h	 124	    2138
            xcolor.h	  30	     682
              xdde.h	 278	    5283
             xlist.h	  64	    2204
               xpi.h	  31	     697
          xstrlist.h	  76	    1950
          xyzzycli.h	  10	     209

おおむねクラスがそれぞれ一つのファイルに分けられているのかなと。 クラスの構成とか関係を図にしないと内容を把握するのが面倒かも。

■_ ネタ

C++0x 8 
613 デフォルトの名無しさん [sage] 2010/03/15(月) 22:55:52 ID: Be:
                   ┌左辺値(lvalue)
    大左辺値(glvalue)←{
                   └中辺値(xvalue) ┐
                             }→右辺値(rvalue)
                 超右辺値(prvalue)┘

    左辺値(lvalue)=今まで通りの左辺値
    右辺値(rvalue)=今まで通りの右辺値。中辺値と超右辺値に分割される。ムーブできる。

    大左辺値(glvalue)=左辺値と中辺値の総称。名前が付いてる。

    中辺値(xvalue)=右辺値参照で作られるオブジェクト。名前は付いてるけどムーブできる。
    超右辺値(prvalue)=中辺値以外の右辺値。名無しの一時オブジェクト。


    あってる? 

いや、内容はまじめなのか。 これの発端はアレだけど。

■_ C++ FQA

これで半分くらい?


C++ FQA Lite: Defective C++

Part of C++ FQA Lite

** Defective operator overloading (不完全な演算子オーバーローディング)

C++ operator overloading has all the problems of C++ function overloading 
(incomprehensible overload resolution rules), and then some. For example, overloaded 
operators have to return their results by value - naively returning references to 
objects allocated with new would cause temporary objects to "leak" when code 
like a+b+c is evaluated. That's because C++ doesn't have garbage collection, since 
that, folks, is inefficient. Much better to have your code copy massive temporary 
objects and hope to have them optimized out by our friend the clever compiler. Which, 
of course, won't happen any time soon.

C++ の演算子のオーバーローディングにはC++ の関数オーバーローディングの問題すべて
(incomprehensible なオーバーロードの解決ルール)とそのほかにも多少の問題があります。た
とえばオーバーロードされた演算子は値によって (by value) その結果を返す必要があります。
new で割り当てたオブジェクトの参照を naive に返してしまうと、a+b+c のようなコードを評
価したときに一時オブジェクトの“リーク”が発生してしまいます。これが C++ がガーベジコ
レクション (garbage collection) を持っていない理由です。つまりは効率的でない 
(inefficient) ということです。あなたのコードで、大量の一時オブジェクトをコピーするよう
にするのは much bettter なことですし、わたしたちの賢き友人であるコンパイラーが最適化し
てくれることを期待しましょう。もちろんそれは今すぐ起きるようなことではありませんが。


Like several other features in C++, operator overloading is not necessarily a bad 
thing by itself - it just happens to interact really badly with other things C++. The 
lack of automatic memory management is one thing making operator overloading less than 
useful. Another such thing is...

C++ の他のいくつかの機能と同様、演算子オーバーローディングはそれ自身が不必要な bad 
thing というわけではありません。ただ単に、C++ のほかの事象と組み合わさったときに 
really badly になことが起きるだけなのです。自動メモリ管理 (automatic memory management) 
の欠如は演算子オーバーローディングを役立たず (less than useful) にしてしまっていること
の一つです。そしてもう一つの原因とは…


** Defective exceptions (不完全な例外)

Consider error handling in an overloaded operator or a constructor. You can't use the 
return value, and setting/reading error flags may be quite cumbersome. How about 
throwing an exception?

オーバーロードされた演算子やコンストラクターの内部でのエラーハンドリングについて考えて
みましょう。return value を使うことはできませんしエラーフラグをセットしたり読み出した
りするのは may be quite cumbersome です。
例外の送出についてはどうでしょうか?


This could be a good idea in some cases if C++ exceptions were any good. They aren't, 
and can't be - as usual, because of another C++ "feature", the 
oh-so-efficient manual memory management. If we use exceptions, we have to write 
exception-safe code - code which frees all resources when the control is transferred 
from the point of failure (throw) to the point where explicit error handling is done 
(catch). And the vast majority of "resources" happens to be memory, which is 
managed manually in C++. To solve this, you are supposed to use RAII, meaning that all 
pointers have to be "smart" (be wrapped in classes freeing the memory in the 
destructor, and then you have to design their copying semantics, and...). Exception 
safe C++ code is almost infeasible to achieve in a non-trivial program.

これは、C++ の例外が何かしら良いものであれば、一部のケースにおいては良いアイデアであっ
たかもしれません。しかし実際にはそんなものではありませんし、そうすることはできません。
いつもと同様に。なぜなら、もう一つの C++ の "feature" である oh-so-efficient 
な手動のメモリ管理のためです。もし例外を使うのならわたしたちは例外安全なコードを書かな
ければなりません。つまり、失敗した (throwが行われた) 地点から実際にエラーハンドリングが
行われた (catchされた) 場所へ制御が移ったときにすべてのリソースを解放するようなコードで
す。


And the vast majority of "resources" happens to be memory,
which is managed manually in C++.

そして、“リソース”の vast majority はメモリーに対して起きるものですが、(メモリーは) 
C++ ではマニュアルで管理されているものです。これを解決するためにあなたは RAII を使うこ
とを考えるでしょうが、これはすべてのポインターが“賢い”(smart, (デストラクターでメモ
リーの解放をするようなクラスにラップされていて、かつ、あなたがそれらの copying 
semantics を設計する必要があって、云々)ものである必要があることを意味します。例外安全
な C++ のコードというものを non-trivial なプログラムで achieve (達成する、獲得する)す
るのはほとんど実行不可能なことなのです。


Of course, C++ exceptions have other flaws, following from still other C++ misfeatures. 
For example, the above-mentioned lack of reflection in the special case of exceptions 
means that when you catch an exception, you can't get the call stack describing the 
context where it was thrown. This means that debugging illegal pointer dereferencing 
may be easier than figuring out why an exception was thrown, since a debugger will 
list the call stack in many cases of the former.

もちろん C++ の例外は C++ の他の misfeatures に起因する別の欠点を持っています。たとえ
ば上述した例外の特殊なケースにおけるリフレクションの欠如は、あなたが例外を捕捉したとき
にその例外を送出したコンテキストを describe している呼び出しスタックを得ることができな
いことになります。このことは、不正なポインターに対するデリファレンス (illegal pointer 
dereferencing) のデバッグはデバッガーが多くの場合における呼び出しスタックをリストする
ので、なぜ例外が送出されたのかを突き止めるよりはおそらく簡単であるということを意味しま
す。

At the bottom line, throw/catch are about as useful as longjmp/setjmp (BTW, the former 
typically runs faster, but it's mere existence makes the rest of the code run slower, 
which is almost never acknowledged by C++ aficionados). So we have two features, each 
with its own flaws, and no interoperability between them. This is true for the vast 
majority of C++ features - most are...

最低でも、throw/catch は longjmp/setjmp と同じ程度には有用です。(ところで前者の方が典
型的には高速に動作するのですが、まれにコードの残りのC++ の aficionados にはほとんど 
acknowledgeされることのない部分の実行速度を遅くしてしまうことがあります)。このようにわ
たしたちはそれぞれが固有の flaws を持ち両者の間に interoperability がないような二つの
機能を持っています。C++ の機能の vast majority でこれは真実です。その最たるものが…

** Duplicate facilities (重複している機能)

  

■_ 本日の巡回から

2010年03月14日

■_

・新規開拓その他
そばもん 1 (ビッグコミックス) そばもん ニッポン蕎麦行脚  2 (ビッグコミックス) そばもん ニッポン蕎麦行脚 3 新そばの季節 (ビッグ コミックス)
とあるところで見かけて、気になったのでとりあえず一巻だけ買って読んだら存外面白かったので 既刊三巻揃えてしまった(笑) 青年誌はあまりチェックしてないからなあ。 宗像教授とか今どうなってんだろう。
信長の忍び 2 (ジェッツコミックス)
信長の忍び 2 (ジェッツコミックス) 神様ドォルズ 6 (サンデーGXコミックス)
先月に出てた模様。見落としてた。 「信長の忍び」は、四コママンガという体裁をとってるけど 歴史好きの人にも結構いけるんじゃないかなあ。

・タッカーときいて
PCの元祖「Alto」設計者のチャールズ・タッカー氏がチューリング賞を受賞 - ITmedia News タッカーという名前を見て、 タッカー (映画) - Wikipedia 『栄光なき天才たち』第4巻 『栄光なき天才たち』第4巻 この辺を連想したり。

・ふりがな
昔の新聞は振り仮名が振られていたそうで。

・もう一つ書籍ネタ
Amazon.co.jp: Coders at Work: Peter Seibel: 洋書 とか Amazon.co.jp: Programming: Principles and Practice Using C++ (Developer's Library): Bjarne Stroustrup: 洋書 って、日本語訳の話が出てたと思うんですが、どうなってんでしょう。 後者は原著を発売直後に買ってますからともかく、 前者はしびれを切らして原著買っちゃいそう。Amazonさんだと3000円してないし。

・さらに
新聞の書評欄で見かけて気になったけど、たけーっ Amazon.co.jp: スターリン―赤い皇帝と廷臣たち〈上〉: サイモン・セバーグ モンテフィオーリ, Simon Sebag Montefiore, 染谷 徹: 本 Amazon.co.jp: スターリン―赤い皇帝と廷臣たち〈下〉: Simon Sebag Montefiore, サイモン・セバーグ モンテフィオーリ, 染谷 徹: 本

■_ サブジェクトは適切にね

てにをはとか。


コマンドプロンプトが使えません!(1/1) | OKWave

最近新しいパソコンを買い、早速javaをやろうと思ってJDKをインストールしました。JDKのイン
ストール→Windowsのパスの設定までできたので、コマンドプロンプトを起動しました。そこで
今いるディレクトリ?(C:\Users\ ~)からcd C:\Users\~と入力して移動はできたのですが、
その後javacやjavac-versionなどと何を入力しても「javacは内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチファイルとして認識されていません。」と出てしまいます。
本によると、正しくインストールまたは設定がなされていないからだというのですが、インスト
ールには成功しているし、環境変数の編集もちゃんとやったのに・・・。どこが問題なのでしょ
うか?

どうしてこの質問で、タイトルが「コマンドプロンプトが使えません」 になるんだろう?

■_

あと半月ほどなのに(いやまあ仕様を完全に満たしたものでもないしと言う事情は あるのでしょうが)。


Journal of chromatic (983)

Perl 6 Design Minutes for 03 March 2010
[ #40242 ]

The Perl 6 design team met by phone on 03 March 2010. Larry, Allison, Patrick, Jerry, 
Will, and chromatic attended.

Larry:

    * noted how lastcall allows nextsame control of nested dispatchers
    * reserved the final paren-based shape declaration syntax without committing to it meaning anything
    * clarified that Nil itself is defined but likes to produce undefined values when indexed
    * added some clarifications of how the series operator deals with type information
    * clarified that Pair.ACCEPTS uses "so" and "not" semantics so :s returns True or False
    * removed the 1/2 and +2-3i literal forms, now rely on angle forms <1/2> and <+2-3i> for literals, and the bare forms now rely on constant folding rather than a fragile special syntax
    * in STD, made undeclared variables more fatal
    * STD now tries to be helpful if the user makes the typical P5-ish variant-sigil mistake on arrays and hashes
    * also improved error message on the -{}> kind of mistake that P5 programmers will make
    * my $a, $b now gives better message
    * STD now reserves the () shape syntax per current spec
    * fixed regression on indirect method knowing that method name is not bound early
    * moved unexpected-!! panic from infixstoppers to infix:<!!> for better extensibility
    * so a user's infix definition isn't ignored if it starts with !!
    * you can define user operators starting with that, and it only complains for the right reasons now
    * STD now gives an accurate message when a prefix is missing its term
    * removed deprecated rational and complex literal forms from STD
    * much preliminary work for moving operator defs to CORE.setting, not yet checked in
    * only blocker is not being in Copenhagen

(ry)

Larry:

    * everyone did take a break over Christmas
    * most of the changes are still simplifications
    * or responses to implementation issues
    * dealing with inconsistencies

remove されたとはあるけど removed the 1/2 and +2-3i literal forms なんてのがあったんか(有理数と複素数のリテラルかな)。 いや、どこかで一回目にしたような記憶がないでもないような。

■_ ~を含まない


Rubyについて Part 39 
360 デフォルトの名無しさん [sage] 2010/03/14(日) 23:11:16 ID: Be:
    ○引数で複数のディレクトリパスを与える
    ○与えられたディレクトリに対して再帰的にファイルを全て削除する
    ○ただし.txt拡張子が付くファイルのみ削除しない

    プログラミングに不慣れながらこんなスクリプトを書こうと思い、以下のようになりました。

    #!/usr/bin/ruby
    require 'fileutils'
    ARGV.each do |i|
    FileUtils.rm(Dir.glob(i + '**/*[^(txt)]'), :force => true)
    end

    突っ込みどころなどありましたら教えていただけないでしょうか。
    簡単なテストをすると意図したように動くのですが少し不安なので質問させていただきました。
    自分で怪しいと思ってる箇所は以下の2箇所です。
    ① i + '**/*[^(txt)]' こんな指定の仕方でいいのだろうか
    ②そもそもFileUtilを使うべきなのか

    宜しくお願いします。 

あ、これ正規表現のマッチングじゃなくてグロビングか。 まあいいや。 以前にも何回か書いていると思うのだけど、 「ある文字列を含まない」文字列を表そうとして [^(txt)] 的なパターンを書いてしまうというのをそこそこ見かけるという気がしているのだけど これって何かうまく警告出せたりしないかなあと思ったり。

■_ xyzzy

xyzzy Part16 
662 名無し~3.EXE [sage] 2010/03/13(土) 19:19:52 ID:iJCZJdSj Be:
    xyzzyのメンテナっているの? 

663 名無し~3.EXE [sage] 2010/03/13(土) 22:37:37 ID:TDIw9DFO Be:
    オリジナルは何年も更新されてないけど、最近は packaged-xyzzy ってのがあったような。 

664 名無し~3.EXE [] 2010/03/14(日) 00:18:14 ID:ZeHBtA3O Be:
    ホントだw
    はじめて知ったわ 

665 名無し~3.EXE [sage] 2010/03/14(日) 00:30:24 ID:wu8r/93/ Be:
    Unicode対応化作業をしてる人は諦めちゃったのかなあ、
    期待してたんだけど…。 

666 名無し~3.EXE [sage] 2010/03/14(日) 12:44:24 ID:Wnda7WBB Be:
    glyph_t を __int64 にしないと文字が収まらないけど無駄が多くなるなぁ、とか
    cp932 も変換テーブル用意しないとなぁ、とか
    DDEわけわからん、とか

    いろいろあって進んでません… 

667 名無し~3.EXE [sage] 2010/03/14(日) 13:01:21 ID:0+R0HpMe Be:
    無駄が多くなっても64ビット版のパフォーマンスが上がりそうとか思った。 

668 名無し~3.EXE [sage] 2010/03/14(日) 13:43:28 ID:TyayYkc4 Be:
    以前も誰か内部に手を加えてたけど、途中で見かけなくなった。

    正直一人でxyzzyを修正及びメンテしていくのは大変。
    もし、今後もxyzzyを長く使っていくなら使用者同士で協力し、
    負担を分散させないと長く続かないと思う。

    これを踏まえてなんだけど、今のxyzzyには協力して開発していく
    基板が整ってるとは言えない。
    なので基板づくりを行いたいが他の方はどう感じてるのかな?

    具体的には共同で開発するために利用するバージョン管理システムを
    決めたりとかからはじめることになると思うけど。 

669 名無し~3.EXE [sage] 2010/03/14(日) 13:55:30 ID:TyayYkc4 Be:
    今まではなんとなく、いつかきっとKameiさんが帰ってくる!
    とか思ってたからあまり内部とかには手をいれるつもりなかったけど、
    正直ここまで更新ないと作者本人も簡単に手を出せる状態じゃ
    なくなってるのかもしれない。

    自分はLispとかで拡張してたけど限界を感じてきたので、
    出来る限り協力したい。 

670 名無し~3.EXE [sage] 2010/03/14(日) 18:19:14 ID:m/BUU/RY Be:
    >>668
    githubのやつは??

671 名無し~3.EXE [sage] 2010/03/14(日) 19:56:23 ID:LIfZWZVR Be:
    ニーズが少なきゃやる気も沸かんだろ 

673 名無し~3.EXE [sage] 2010/03/14(日) 23:24:46 ID:MRsOwvmF Be:
    協力できる物ならしたいとは思うんだが
    いかんせんC言語系はさっぱりなんだな

    >>672
    (make-process "notepad.exe" :environ `(("HOME" . ,*home-dir*))) 

前に xyzzy のソース見たことがあるけど確かにアレを把握するのは結構大変かも。 ソースが汚いとかいうわけじゃないんだけど。

■_ 本日の巡回から

2010年03月13日

■_

・まくあい
泳ぐやる夫シアター やる夫が鉄血宰相になるようです   幕間補足2 以前とある声優さんのラジオ聴いてたら、この「幕間」を「まくま」と云ってて がっくしきた覚えが。中堅からベテランの域の人だったんだけど。 これとは別に、会社でちょっと偉い人が訓辞を述べていたときに 「間断なく~する」を間違って読んでてやっぱり(省略されました)。

・つうこんのいちげき
Amazonさんで限定版のものをちょっと日にちの外れたものと一緒に注文してたのに 気がついたときは手遅れだった。 なぜに ○| ̄|_

■_ FQA

まだまだ続くよ~


C++ FQA Lite: Defective C++

Defective C++

Part of C++ FQA Lite

** Very complicated type system (複雑極まりない型システム)

In C++, we have standard and compiler-specific built-in types, structures, 
enumerations, unions, classes with single, multiple, virtual and non-virtual 
inheritance, const and volatile qualifiers, pointers, references and arrays, typedefs, 
global and member functions and function pointers, and templates, which can have 
specializations on (again) types (or integral constants), and you can "partially 
specialize" templates by pattern matching their type structure (for example, have 
a specialization for std::vector<MyRetardedTemplate<T> > for arbitrary 
values of T), and each template can have base classes (in particular, it can be 
derived from its own instantiations recursively, which is a well-known practice 
documented in books), and inner typedefs, and... We have lots of kinds of types.

C++ では標準の組み込み型 (built-in types) とコンパイラー固有の組み込み型があります。構
造体、列挙、共用体、単純継承のクラス、多重継承のクラス、仮想継承のクラス、非仮想継承の
クラス、const や volatile といった修飾子 (qualifiers)、ポインター、リファレンス、配列、
typedef されたもの、グローバル関数やメンバー関数、関数ポインター、テンプレート、(再度) 
型(もしくは integral constants)に応じて specilizations ができます。また、その type 
structure とパターンマッチングをすることによるテンプレートの "partially specialize"
が可能ですし(たとえば、std::vector<MyRetardedTemplate<T> >の任意の T の値に対する
specialization)、各々のテンプレートクラスはベースクラス(特に、独自に再帰的にインスタン
ス化したものから派生でき書籍に記述されているよく知られた pracrice です)や、inner 
typedefs を持つことができるのです。そしてそして… わたしたちにはたくさんの種類の型があ
るのです。


Naturally, representing the types used in a C++ program, say, in debug information, is 
not an easy task. A trivial yet annoying manifestation of this problem is the 
expansion of typedefs done by debuggers when they show objects (and compilers when 
they produce error messages - another reason why these are so cryptic). You may think 
it's a StringToStringMap, but only until the tools enlighten you - it's actually more 
of a...

当然のことですが、C++のプログラム中のデバッグ情報で使用されている型を表現することは簡
単なタスクではありません。この問題の trivial なしかし manifestation を annoy すること
の問題点は、 (デバッガーが)オブジェクトを表示するときにデバッガーによってtypedef の 
expansion が行われるということです(そしてコンパイラーはエラーメッセージを表示するとき
にこの展開を行います。つまり、エラーメッセージがなぜこんなにも暗号的なのかということの
もう一つの理由がこれです)。あなたはこれが StringToStringMap であると考えるかもしれませ
んが、それはツールがあなたをenlighten(啓蒙、教化)するまでです。
- it's actually more of a...

// don't read this, it's impossible. just count the lines
std::map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >,
std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> >
  >, std::allocator<std::pair<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > >

But wait, there's more! C++ supports a wide variety of explicit and implicit type 
conversions, so now we have a nice set of rules describing the cartesian product of 
all those types, specifically, how conversion should be handled for each pair of types. 
For example, if your function accepts const std::vector<const char*>& (which 
is supposed to mean "a reference to an immutable vector of pointers to immutable 
built-in strings"), and I have a std::vector<char*> object ("a mutable 
vector of mutable built-in strings"), then I can't pass it to your function 
because the types aren't convertible. You have to admit that it doesn't make any sense, 
because your function guarantees that it won't change anything, and I guarantee that I 
don't even mind having anything changed, and still the C++ type system gets in the way 
and the only sane workaround is to copy the vector. And this is an extremely simple 
example - no virtual inheritance, no user-defined conversion operators, etc.

でもちょっと待ってください。まだあるのです! C++ は明示されたものか暗黙のものかを問わず
型変換をサポートしているので、現在のわたしたちにはそういったすべての型に対する 
cartesian product があります特に変換が型のペアごとにどのように取り扱われるべきかを記述
しているルールの nice set があります。たとえばあなたの関数が
const std::vector<const char*>&("a reference to an immutable vector of 
pointers to immutable built-in strings"変更不可能な文字列へのポインターの変更不可
能なベクターの参照) を受け付けるものであり、そしてわたしの手元に 
std::vector<char*> object ("a mutable vector of mutable built-in strings"
変更可能な文字列の変更可能なベクター) があったとすると、わたしはこれをあなたのその関数
に渡すことができません。なぜなら、型に互換性がないからです。あなたはそんなことには何の
意味もないことを認めなければなりません。なぜなら、あなたの関数は何も変更しないだろうこ
とを保証していますし、そして何かが変更されることをわたしは気にしないのに、それでも C++ 
の型システムが邪魔になって (gets in the way) いて、唯一まともな(sane) 回避策はベクター
をコピーすることなのです。そしてこれは、仮想継承もなく、ユーザー定義の変換演算子なども
ないこの上なく単純な例なのです。

But conversion rules by themselves are still not the worst problem with the 
complicated type system. The worst problem is the...

しかしそれでも変換規則それ自体は複雑な型システムに関連する最悪の問題では
ないのです。最悪の問題とは…

** Very complicated type-based binding rules (型に基づくとても複雑な束縛ルール)

Types lie at the core of the C++ binding rules. "Binding" means 
"finding the program entity corresponding to a name mentioned in the code". 
When the C++ compiler compiles something like f(a,b) (or even a+b), it relies on the 
argument types to figure out which version of f (or operator+) to call. This includes 
overload resolution (is it f(int,int) or f(int,double)?), the handling of function 
template specializations (is it template<class T> void 
f(vector<T>&,int) or template<class T> void f(T,double)?), and the 
argument-dependent lookup (ADL) in order to figure out the namespace (is it A::f or 
B::f?).

型 (Types) は C++ の束縛規則 (bindings rules) の核に位置しています。束縛 
("Binding") とは
"finding the program entity corresponding to a name mentioned in the code". 
(コードの中にある名前によって mentions されているものに対応するプログラムエンティティ
を見つけ出すこと) です。C++コンパイラーが f(a,b) (あるいは a+b のようなものでさえ)のよ
うなものをコンパイルするときには、呼び出すべき f (または operator+) のバージョンを判断
するのは引数の型が明らかになっていることに依存しています。これは、f(int,int) と 
f(int,double) のいずれになるかなどのようなオーバーロードの解決、
template<class T> void f(vector<T>&,int) のような 関数テンプレートの
特殊化の処理、template<class T> void f(vector<T>&,int) と 
template<class T> void f(T,double) のいずれを選択するかのような関数テンプレート
の特殊化 、名前空間を figure out (把握、見つけ出す) するための ADL (argument-dependent
lookup) といったものを含んでいます。

When the compiler "succeeds" (translates source code to object code), it 
doesn't mean that you are equally successful (that is, you think a+b called what the 
compiler thought it called). When the compiler "fails" (translates source 
code to error messages), most humans also fail (to understand these error messages; 
multiple screens listing all available overloads of things like operator<< are 
less than helpful). By the way, the C++ FAQ has very few items related to the 
unbelievably complicated static binding, like overload resolution or ADL or template 
specialization. Presumably people get too depressed to ask any questions and silently 
give up.

コンパイラーが(ソースコードからオブジェクトコードへの変換に)“成功”したときでも、それ
はあなたが成功した(つまりあなたが a+b で呼ばれると考えたものがコンパイラーが呼び出した
ものになった)ことを意味してはいません。コンパイラーが“失敗”したとき (ソースコードを
エラーメッセージに変換したとき)、ほとんどの人間も同様に失敗します(エラーメッセージを理
解するためには、operator<< のようなものの可能性のあるオーバーロードすべてを
multiple screens でリスト表示することは less than helpful です)。ところで、C++ FAQ に
はオーバーロードの解決や ADL、テンプレートの特殊化のような、信じがたいほどに複雑な静的
バインディングに関連した項目がほとんどありません。
Presumably people get too depressed to ask any questions and silently give up.
# 多分そういったことを質問しても落胆してしまって静かにギブアップしてしまうのでしょう。
# Presumably たぶん、どうも~らしい
# depress 落胆する


In short, the complicated type system interacts very badly with overloading - having 
multiple functions with the same name and having the compiler figure out which of them 
to use based on the argument types (don't confuse it with overriding - virtual 
functions, though very far from perfect, do follow rules quite sane by C++ standards). 
And probably the worst kind of overloading is...

まとめると、複雑な型システムはオーバーローディングに対する interacts が very badly で
す。複数の関数が同じ名前を持ち、コンパイラーがそれらのうちのどれを使うのかを引数の型に
基づいて決定します(オーバーライドと混同しないでください。仮想関数は、完全にはほど遠い
ながらもC++ の標準によって quite sane (とても健全?) なルールに従っています)。そしてオ
ーバーロードの worst  kind とはおそらく…


** Defective operator overloading (不完全な演算子オーバーローディング)
  

■_ でこれーたー

理屈はわかるんだけど、いざ書くときに悩むんだよなあ(苦笑)


blog.lost-theory.org: Decorator for preventing recursion

Decorator for preventing recursion
(再帰を阻止するデコレーター)

written by stevek, on Mar 9, 2010 7:53 AM.

Here's a decorator that will prevent a recursive function from calling itself:
以下のコード片は自分自身を呼び出す再帰関数を邪魔するものです:

def norecursion(default=None):
    '''Prevents recursion into the wrapped function.'''
    def entangle(f):
        def inner(*args, **kwds):
            if not hasattr(f, 'callcount'):
                f.callcount = 0
            if f.callcount >= 1:
                print "recursion detected %s calls deep. exiting." % f.callcount
                return default
            else:
                f.callcount += 1
                x = f(*args, **kwds)
                f.callcount -= 1
                return x
        return inner
    return entangle

It's based on this recipe. The function in that recipe relies on keeping track of 
which arguments were passed into the function, which means that it could not work on a 
function without any arguments. The decorator above works by attaching an attribute to 
the wrapped function for keeping track of how many calls have been made and exiting 
when the number of nested calls goes above a certain number.

Here's how you use it:

@norecursion(default=1)
def fact(x):
  if x <= 1:
    return 1
  else:
    return x*fact(x-1)

Now when you call fact it won't make the recursive call, instead it will return the 
default value of 1:

>>> fact(0)
1
>>> fact(1)
1
>>> fact(2)
recursion detected 1 calls deep. exiting.
2
>>> fact(3)
recursion detected 1 calls deep. exiting.
3

(略)

■_ PyPy

これも JITか。やっぱりPython自身で書かれてるんだよね?


PyPy Status Blog: Introducing the PyPy 1.2 release
Friday, March 12, 2010

Introducing the PyPy 1.2 release

We are pleased to announce PyPy's 1.2 release. This version 1.2 is a major milestone 
and it is the first release to ship a Just-in-Time compiler that is known to be faster 
than CPython (and unladen swallow) on some real-world applications (or the best 
benchmarks we could get for them). The main theme for the 1.2 release is speed.

The JIT is stable and we don't observe crashes. Nevertheless we would recommend you to 
treat it as beta software and as a way to try out the JIT to see how it works for you.
JITは安定していて、クラッシュは確認されていません。現状のソフトウェアはベータとして
扱ってもらいたいものではあるものの、あなたにとってJITがどのように働くかを
ぜひ確かめてみてください。


Highlights:

    * The JIT compiler.

    * Various interpreter optimizations that improve performance as well as help save 
      memory. Read our various blog posts about achievements.

    * Introducing a new PyPy website at pypy.org made by tav and improved by the PyPy 
      team.

    * Introducing speed.pypy.org made by Miquel Torres, a new service that monitors 
      our performance nightly.

    * There will be ubuntu packages on PyPy's PPA made by Bartosz Skowron, however 
      various troubles prevented us from having them as of now.

Known JIT problems (or why you should consider this beta software) are:

    * The only supported platform is 32bit x86 for now, we're looking for help with 
      other platforms.
      サポートしているプラットフォームは現状では 32bit の x86 のみ。
      他のプラットフォームに関して手助けしてくれる人を求む。

    * It is still memory-hungry. There is no limit on the amount of RAM that the 
      assembler can consume; it is thus possible (although unlikely) that the
      assembler ends up using unreasonable amounts of memory.
      まだまだメモリ馬鹿食い。アセンブラーが消費する可能性のあるRAMの容量を
      制限していない。これはアセンブラーが unreasonable なメモリ量を使って
      しまっているから。

If you want to try PyPy, go to the download page on our excellent new site and find 
the binary for your platform. If the binary does not work (e.g. on Linux, because of 
different versions of external .so dependencies), or if your platform is not supported, 
you can try building from the source.

The PyPy release team,

■_ 本日の巡回から

2010年03月12日

■_

・ついった
発言の大半はどちらかというと自分の癇に障るようなものなんだけど、 面白いことも云う人をフォローするか悩みんぐ(笑) まあ、一度フォローしたものの、癇に障る発言が嫌でリムーブしたんですがね。

■_ 非 Unix系はタイヘン

微妙に現実をねじ曲げたような気もするがまあいいやw


dropping windows support - shedskin-discuss | Google Groups

From: srepmub <mark.duf
Date: Thu, 11 Mar 2010 06:12:59 -0800 (PST)
Local: Thurs, Mar 11 2010 11:12 pm
Subject: [shedskin] dropping windows support

hi all,

I'm considering dropping windows support with shedskin 0.4. if you'd
like to volunteer to maintain the windows version of shedskin, please
let me know.

mark.


From: Jérémie Roquet
Date: Fri, 12 Mar 2010 10:28:22 +0100
Local: Fri, Mar 12 2010 6:28 pm
Subject: Re: [shedskin] dropping windows support

http://www.reddit.com/r/Python/comments/bc34w/shedskin_the_python_to_...

:-)

Is it only a packaging task?

-- 
Jérémie


From: Mark Dufour
Date: Fri, 12 Mar 2010 12:55:58 +0100
Local: Fri, Mar 12 2010 8:55 pm
Subject: Re: [shedskin] dropping windows support

2010/3/12 Jérémie Roquet <arkano...@gmail.com>

> http://www.reddit.com/r/Python/comments/bc34w/shedskin_the_python_to_...

> :-)

> Is it only a packaging task?

essentially, yes, but also testing to see if (most) tests and example
programs still work. since everything worked fine with 0.3, doing a 0.4
release _should_ only take a few hours. it would be useful to also upgrade
MingW at some point, because the version currently shipped with shedskin is
getting a bit outdated, but that would take some more time..

thanks,
mark.

どこも Windows では苦労するってことか。


Shedskin the Python to C++ Converter Needs a Windows Developer : Python

I use shedskin heavily for deploying natively compiled, standalone executables on 
Windows. This and Ironpython seem to be the only promising options for converting to 
compiled machine code that can be deployed to customers. I'd rather not use Ironpython.

If anyone wanted to contribute here, your work would be well appreciated.


    I'd rather not write C++.

FTFY


I was introduced to ShedSkin a while ago, and it's absolutely fantastic. You write 
your code (taking care not to mix types), compile and get a 100x speedup on heavily 
algorithmic code. I would love to help but I switched to Linux a few months ago :/


What's wrong with py2exe? I'm starting to use that and it seems fairly decent, for 
deployment.

Excellent, it is. My problem is that I'm working at a small startup and need a little 
more obfuscation of our core algorithms to protect it from competition than python 
bytecode can provide. Plus c++ is far faster.

If your product is worth decompiling python bytecode, it is worth hiring engineers to 
create it from scratch. Programming is not magic, generally it is easier to create a 
program from scratch than to decompile it. Reverse engineering is used when you need 
to be compatible with something (file formats, or hardware interfaces).
If there is sufficient business benefit your company could consider sponsoring Mark 
(or someone else) to maintain Windows support.

If your competition is decompiling python bytecode, (I hate to be actually saying this) 
but wouldn't it be a violation of the DMCA?

I don't think so. I think the DMCA only applies to reverse engineering security 
devices that protect media. It definitely doesn't apply to reverse engineering 
software in general.

how big the generated files usually are?

The C++ code is basically your Python code converted to C++, no Python calls or 
anything. They're quite small, an assignment I wrote was 300kb.


It's a nice project, but what python really needs is a proper way to call C++ code 
from python. And by that, I mean create classes, convert python lists to std::vectors 
automatically, and so on.
Minor question: did you use any of these? Because there seems to be an aweful lot of 
concurrent solutions, and no clear winner...
That's a tough problem; the C++ ABI is a mess and not standardized as far as I know.
Good point. I guess any good solution will be compiler specific then.
Doing development other than .NET/C# on Windows is a pain, so I can't say I'm 
surprised that there are so few volunteers.

Note that this is exactly what Microsoft wants, so it's not going to change any time 
soon. Why make it easy for people to develop cross-platform applications when you can 
lock them in with nice Windows-only libraries?

■_ ぐぐるさんが

Google releases linear-time, fixed-space, mostly PCRE-compatible regex library : programming 正規表現ライブラリ作った?


RE2: a principled approach to regular expression matching - Google Open Source Blog
Thursday, March 11, 2010 | 12:00 PM

Labels: re2, regular expressions

Regular expressions are one of computer science's shining examples of the benefits of 
good computer science theory. (略)


The feature-rich regular expression implementations of today are based on a 
backtracking search with a potential for exponential run time and unbounded stack 
usage. At Google, we use regular expressions as part of the interface to many external 
and internal systems, including Code Search, Sawzall, and Bigtable. (略)


Today, we released RE2 as an open source project. It's a mostly drop-in replacement 
for PCRE's C++ bindings and is available under a BSD-style license. See the RE2 
project page for details.

By Russ Cox, Software Engineering Team


あとでちぇっく。

■_ とくにふかいいみはありません

IEEE 754 - Wikipedia
http://ja.wikipedia.org/wiki/IEEE_754

指数部はバイアスまたはエクセスと呼ばれる表現形式であり、実際の値にある固定値emax = 127
を加算している。このような表現にしているのは浮動小数点数同士の比較を単純にするためであ
る。指数部は大きな値も小さな値も表せるように負の値にもなるが、これを2の補数で表すと、
全体の符号 S とは別に Exp も符号を持つことになり、単純な大小比較ができなくなってしまう。
そのため、指数部はバイアスされて常に正の値となるような形式で格納される。単精度数の指数
部は?126 ? +127に127を加えて、1 ? 254としている(0と255は特殊な意味を持つ。後述)。浮
動小数点数を解釈するときは、バイアスを減算して実際の指数を求める。

表現可能なデータは指数部の値によって区別され、仮数部の値にも影響される。指数部も仮数部
も符号無しの二進整数であることに注意されたい(指数部は 0 ? 255)。

種類      	Exp(指数部)        Fraction(仮数部)
ゼロ      	0       		0
非正規化数   	0       		0以外
正規化数    	1 ~ 254         	任意
無限大     	255     		0
NaN     	255     		0以外の任意


#include <stdio.h>
#include <stdlib.h>
#include <float.h>

union u_float {
   float f;
   unsigned char   c[4];
};

void
print_float_bits(float f)
{
   union u_float x;

   x.f = f;
   printf("value = %10.8f\n", x.f);
   printf("%02x:%02x:%02x:%02x\n",
          x.c[3], x.c[2], x.c[1], x.c[0]);
   printf("sign = %c\n", (x.c[3] & 0x80) ? '-' : '+');
   printf("exponent = %04x\n", ((x.c[3] & 0x7f) << 1) | (x.c[2] & 0x80 ? 1 : 0));
   printf("mantissa = %02x:%02x:%02x\n\n",  x.c[2] & 0x7f, x.c[1], x.c[0]);
}

int
main()
{
   float v[] = {
       2.0f, 1.0f, 0.5f, 0.25f,
       FLT_MIN*8, FLT_MIN*4, FLT_MIN*2, FLT_MIN,
       0,
   };

   for (int i=0; i< (sizeof v / sizeof v[0]); i++) {
       print_float_bits(v[i]);
   }
   return 0;
}

value = 2f
40:00:00:00
sign = +
exponent = 0080
mantissa = 00:00:00

value = 1f
3f:80:00:00
sign = +
exponent = 007f
mantissa = 00:00:00

value = 0.5f
3f:00:00:00
sign = +
exponent = 007e
mantissa = 00:00:00

value = 0.25f
3e:80:00:00
sign = +
exponent = 007d
mantissa = 00:00:00

value = 9.40395e-038f
02:00:00:00
sign = +
exponent = 0004
mantissa = 00:00:00

value = 4.70198e-038f
01:80:00:00
sign = +
exponent = 0003
mantissa = 00:00:00

value = 2.35099e-038f
01:00:00:00
sign = +
exponent = 0002
mantissa = 00:00:00

value = 1.17549e-038f
00:80:00:00
sign = +
exponent = 0001
mantissa = 00:00:00

value = 0f
00:00:00:00
sign = +
exponent = 0000
mantissa = 00:00:00

ケチビットが存在しているから、仮数部のビットがオールゼロでもゼロにはならんという。

■_ 本日の巡回から

2010年03月11日

■_

○| ̄|_

■_

NaN をどうやって作るかってのは @higepon も以前悩んでたような。 「正しいやり方」ってあんのかしらん。

The Old New Thing : How do I access the magic IEEE floating point values like NaN in code?

How do I access the magic IEEE floating point values like NaN in code?

There are functions like _isnan, _isnanf, _finite, and _fpclass for detecting that a 
floating point value is one of the special values like NaN, but how do you actually 
generate one of these values?

You can access these values from the std::numeric_limits template.

std::numeric_limits::infinity(); // positive infinity
std::numeric_limits::quiet_NaN(); // non-signalling NaN

Wait, where's negative infinity? The compiler folks provided these handy little 
definitions for when you need to generate a special value (as opposed to merely 
detecting one), and for which the numeric_limits template comes up short.

DECLSPEC_SELECTANY extern const float FLOAT_POSITIVE_INFINITY = ((float)(1e308 * 10));
DECLSPEC_SELECTANY extern const float FLOAT_NEGATIVE_INFINITY = ((float)(-1e308 * 10));
DECLSPEC_SELECTANY extern const float FLOAT_NaN = ((float)((1e308 * 10)*0.));

Disclaimer: Applies to Microsoft Visual Studio. Your mileage may vary. Use the 
template when available.

Bonus chatter: Note that you must use functions like _isnan to detect special values, 
because floating point special values behave very strangely in comparisons. (For 
example, NaN does not compare equal to itself!)

Published Friday, March 05, 2010 7:00 AM by oldnewthing

 
© 2010 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement  

へー、((float)((1e308 * 10)*0.)) な NaN の作り方もあるのか。

■_ Java Hate Love

微妙なところを残して投げるという最近頻出のパターン。


Why I love everything you hate about Java ≪ Magic Scaling Sprinkles

Why I love everything you hate about Java
なぜあなたがJavaに関して嫌っていることのすべてをわたしが好きなのか


If you're one of those hipster programmers who loves Clojure, Ruby, Scala, Erlang, or 
whatever, you probably deeply loathe Java and all of its giant configuration files and 
bloated APIs of AbstractFactoryFactoryInterfaces. I used to hate all that stuff too. 
But you know what? After working for all these months on these huge pieces of Twitter 
infrastructure I've started to love the AbstractFactoryFactories.

もしあなたが Clojure や Ruby、Scala、Erlang といったものが大好きなhipster (物知り、進
んでいる人) プログラマーの一人であるのなら、おそらくあなたは Java と、その巨大な 
configuration ファイルや AbstractFactoryFactoryInterfaces のような bloated な API 群を
心から嫌っていることでしょう。わたしもまた、そういった stuff すべてを嫌っててきました。
でもあなたの知っていることって?この数ヶ月 Twitter のインフラの huge piecesで働いてみて、
わたしはこの AbstractFactoryFactories が好きになっていたのです。


Let me explain why. Consider this little Scala program. It uses “futures”, which are 
a way to schedule computation to be done in parallel from the main flow of a program. 
They are sometimes a natural way of modeling the most efficient scheduling of program 
execution. Usually you schedule in advance some expensive work that can be done in 
parallel and then you do something else in the meantime. Only when you really need the 
result of the original computation do you block and wait (and hopefully only very 
briefly since you scheduled the work way in advance!). Here is a “typical” Java-ish 
Futures library used from Scala:

なぜなのかを説明させてください。ここでは小規模な Scala プログラムを考えます。そのプロ
グラムではあるプログラムのメインフローから並行で行う計算のスケジュールをする“futures”
を使っています。それがプログラム実行の最も効率的なスケジューリングモデリングの自然な方
法であるときもあります。通常あなたは並列に実行できる some expensive work をスケジュール
して
and then you do something else in the meantime.
元々の計算結果をあなたが本当に必要としているときにだけブロックとウェイトを行います
(and hopefully only very briefly since you scheduled the work way in advance!
そしてできれば)。これが Scala から使われる “典型的な”Java 的 Futures libraryです:


    private val executor = new ThreadPoolExecutor(
      poolSize, maxPoolSize,
      keepAlive.inSeconds, TimeUnit.SECONDS,
      new LinkedBlockingQueue[Runnable],
      new NamedPoolThreadFactory(name))

    val future = new FutureTask {
      doSomeWork
    }

    executor.execute(future)

If you come from a dynamic language like Ruby or Python you will probably have a 
visceral reaction like “Yeck! Look at all that horrible boilerplate. Convention over 
configuration!” Wouldn't it be nice if you could just do something like:

もしあなたが Ruby や Python のような動的言語からやってきたのなら、
“Yeck! Look at all that horrible boilerplate. Convention over configuration!”
(おいおい、このhorrible boilerplate を見てみろよ。「規約は設定に勝る」ってなんだよ!)
のような visceral reaction をすることでしょう。
 Wouldn't it be nice if you could just do something like:


    val future = new Future {
      doSomeWork
    }

It seems nice but its nicety is just an illusion. All that boilerplate is really 
important when you work at massive scale and where efficiency really matters. These 
magic numbers like the thread pool size and the kind of queue you use to schedule work 
can vastly impact the performance of your application. And the “right” configuration 
depends entirely on the nature of the problem you're solving and how callers of this 
code behave. What all of this weird boilerplate provides is a way to configure the 
behavior of the system; it doesn't assume there's one right way of doing things. And 
that is precisely how modular software behaves: modular code is code designed to grow 
past the assumptions of just one user. Modularity really matters when your software 
isn't a little throw-away program.

これは一見 nice なように見えますが、その nicety は単なる幻想にすぎません。こういった様々
な  boilerplate はあなたが work at massive scale なときに同時に効率が重要な要素である
場合にはとても重要です。スレッドプールの大きさのようなマジックナンバーやスケジュールの
ために使うキューの種類といったものは、あなたの作るアプリケーションに広範な影響をもたら
す可能性があります。そして“正しい”コンフィギュレーションは、あなたが解決しようとして
いるその問題の性質やこのコードの呼び出し元の動作がどういったものであるかに完全に依存し
ています。この種の weird な boilerplate のすべてが提供しているのは、そのシステムの振る
舞いを configure する方法です。そのとき実行するためのただ一つの正しい方法があるとは想
定していません。そしてそれはまさに modular sottware がどのように振舞うのかということな
のです:modular code とは、ただ一人のユーザー (just one user) の asumptions を成長させ
るために過去に設計されたコードです。Modularity はあなたのソフトウェアが小さな使い捨て
プログラム(little throw-away program)でない場合には重要なことです。


Twitter recently open-sourced Querulous, a minimal database querying library for Scala. 
We use it in several projects in Twitter, but it was designed principally to meet the 
extreme demands FlockDB, our distributed, fault-tolerant graph database. FlockDB 
demands extremely low-latency (sub millisecond) response times for individual queries. 
Any excessive indirection from an ORM would be unacceptable. Furthermore, because 
FlockDB processes tens of thousands of queries per second across dozens of shards, 
FlockDB must collect extensive statistics on the performance and health of the various 
shards in order to direct traffic to the most efficient place.

Twitter は Scala 向けの minimal database querying library であるQuerulous を最近オープ
ンソースとしました。わたしたちはこれを Twitter 内の幾つかのプロジェクトで使っていまし
たがそれは principally な設計がわたしたちの分散型でフォールトトレラントなグラフデータ
ベースであるFlockDBに extreme な demands をするようなものでした。FlockDB はこの query 
に対するとことん低いレイテンシー (ミリ秒以下) のレスポンスタイムを要求しますORM からの
一切の excessive indirection は受け付けられませんでした。それに加えて、FlockDB のプロ
セスはdozen of shards を跨いだ毎秒一万件もの query を処理するので、FlockDB はパフォー
マンスについての extensive な統計情報と、最も効果的な場所へトラフィックを振り向けるた
めの health of the various shards を収集 (collect) しなければなりません。

So Querulous was designed for querying databases at low latency, massive scale, and 
with easy operability. It has flexible timeouts, extensive logging, and rich 
statistics. But as FlockDB became more mature and sophisticated, the demands grew 
greater. We needed different health-check and timeout strategies in different contexts. 
It became clear that Querulous would need to be made extremely modular and extremely 
configurable to work at all.

そこで Querulos はデータベースに対する 低レイテシーで、massive scale, easy operability 
な querying のために設計されました。この Querulos は flexible な timeouts、extensive 
logging、rich な statistics を備えていました。しかし、FlockDB がより mature かつ 
sophisticated されていったように要求は grew greater していったのです。わたしたちには別
の heelth-check と異なるコンテキストにおける timeout 戦略が必要になりました。ここで 
Querulous は work at all のために extremerly に modular にし、かつextremerly に 
configurable にする必要があることがクリアになりました


So we set about to re-write Querulous using my favorite modularity techniques: 
Dependency Injection, Factories, and Decorators. In other words, everything you hate 
about Java.

そこでわたしたちは、わたしの好きな modularity 技法である依存性注入(Dependency Injection)、
ファクトリー (Factories)、デコレーター (Decorators) を使って Querulous を書き換えること
を決意しました。これらは、言葉を換えればあなたが Java で嫌っているものすべて (everything)
です。


The design patterns of modularity (modularity のデザインパターン)

In order for code to be modular it must have few hard-coded assumptions. In 
Object-Oriented software this means something very particular since the essence of an 
Object-Oriented program is that its structure is organized around the types of objects. 
Therefore, the most fundamental, anti-modular assumption in Object-Oriented software 
is the concrete type of objects. Any time you write new MyClass in your code you've 
hardcoded an assumption about the concrete class of the object you're allocating. This 
makes it impossible, for example, for someone to later add logging around method 
invocations of that object, or timeouts, or whatever isn't anticipated a priori.

コードを modular にするためにはハードコードされた仮定や想定 (hard-coded assumptions)の
数を少なくしなければなりません。オブジェクト指向ソフトウェアではこれは something very 
particular を意味します。なぜなら、オブジェクト指向プログラムのエッセンス (essence) と
は、その構造がオブジェクトの型を中心として構成されていることだからです。したがって、オ
ブジェクト指向ソフトウェアにおける最も fundamental な  anti-modular な assumption とは
オブジェクトの具体的な型 (concrete type of objects) です。あなたが自分のコードで new 
Myclass と書いた時点であなたは自分が割り当てを行うオブジェクトの具体的なクラス 
(concrete class) についての想定をハードコードしています。これはたとえばあとから誰かが
あるオブジェクトを invocation するメソッドに関するロギングを追加したりとかタイムアウト、
あるいは a priori に anticipated できなかったものすべてを追加することを不可能にしてし
まいます。


In a very dynamic language like Ruby, open classes and method aliasing (e.g., 
alias_method_chain) mitigate this problem, but they don't solve it. If you manipulate 
a class to add logging, all instances of that class will have logging; you can't take 
a surgical approach and say “just objects instantiated in this context”.

Ruby のような動的言語では、オープンクラス (open classes) とメソッドエイリアシング 
(method aliasing。e.g., alias_method_chain) がこの問題を mitigate (軽減する、和らげる) 
しますが解決はしません。もしあるクラスをロギング機能を追加するように操作すると、そのク
ラスのすべてのインスタンスがロギング機能を持つようになります。あなたは surgical 
approach (限定されたアプローチ?) を採用して
 “just objects instantiated in this context”
(このオブジェクトだけこのコンテキストでインスタンス化する)と指示することはできません。


There are standard design patterns to mitigate this, namely Dependency Injection, 
Factories, and Decorators. By injecting a Factory (a function that manufactures 
objects) as a parameter to a function that needs to create objects, you allow a 
programmer to later change his mind about what Factory to inject; and this means the 
programmer can change the concrete types of objects as his heart desires. And by using 
Decorators, the programmer can mix and match functionality easily, stack one thing on 
top of another like so many legos. Let's look at an example.

この制限を緩和 (mitigate) するための Dependency Injection (依存性注入)、Factories(ファ
クトリー)、 Decorators (デコレーター)と呼ばれるデザインパターンが存在します。オブジェ
クトを生成するのに必要となる関数をパラメーターとしてFactory (オブジェクトを構築する関
数) を注入することによりあなたはプログラマーがあとになって注入する Factory について心
変わりすることを許可します。そしてこれはプログラマーが自分の要望としてのオブジェクトの
具体的な型 (concrete types of objects)を変更できるようになることを意味します。さらに
Decoratorsを使うことでプログラマーは functionality を簡単に mix and match でき、たくさ
んのレゴのようにstack one thing on top of another できるのです。

では例を見てみましょう。

Here I have a Query object, with methods like #execute(). I want to add timeouts 
around all queries. I start by creating a QueryProxy that routes all method 
invocations through an over-ridable method: #delegate:

ここで #execute() のようなメソッドを持った Query オブジェクトがあります。わたしはすべ
ての qureries に対して timeouts を追加したいと思っています。オーバーライド可能なメソッ
ド #delegate を通じて起動するすべてのメソッドをルーティングするQueryProxy を生成するこ
とから始めます:

    abstract class QueryProxy(query: Query) extends Query {
      def select[A](f: ResultSet => A) = delegate(query.select(f))
      def execute() = delegate(query.execute())
      def cancel() = query.cancel()

      protected def delegate[A](f: => A) = f
    }

Then, to implement timeouts, I create a Query Decorator:

そしてタイムアウトを実装するために Query Decorator を作ります:

    class TimingOutQuery(timeout: Duration, query: Query) extends QueryProxy(query) {
      override def delegate[A](f: => A) = {
        try {
          Timeout(timeout) {
            f
          } {
            cancel()
          }
        } catch {
          case e: TimeoutException =>
            throw new SqlTimeoutException
        }
      }
    }

This Decorator delegates to the underlying query object the execution of the query, 
but it wraps that execution in a Timeout.

この Decorator は query を実行する query オブジェクトに delegate していますが、
Timeout のある実行としてラッピングしています。


As an aside, it is interesting to note that the Decorator pattern is just the 
Object-Oriented equivalent of function composition in a functional language. Scala 
makes this especially explicit since everything is both an Object and a Function (it 
is a function if it is an object that responds to the method #apply()). A Decorator 
around an object that only implements #apply() is pure Function-composition as you 
would see in Haskell, ML, and so forth. I might phrase this as: function composition 
is a degenerate case of the Decorator pattern.

それはさておいて、オブジェクト指向におけるデコレーターパターンは関数型言語の関数合成 
(function composition) と等価なものであることに言及しておきましょう。Scala ではすべて
が Object であると同時に Function でもあるために、これを特にはっきりとした形にしていま
す(あるオブジェクトが #apply() というメソッドに反応するのであればそれは関数です)。
#apply() しか実装していないオブジェクトに対するデコレーターは、Haskell や ML などに見
られる pure Function-composition です。このように言うこともできるかもしれません: 関数
の合成はデコレーターパターン (Decrator pattern) の degenerate case である。


The implementation of the Timeout function is shown for the curious. It uses threads 
and is weird but cool.

Timeout 関数のこの実装は  shown for the curious です。
スレッドを使っていて weird ではありますが cool です。


    object Timeout {
      val timer = new Timer("Timer thread", true)

      def apply[T](timeout: Duration)(f: => T)(onTimeout: => Unit): T = {
        @volatile var cancelled = false
        val task = if (timeout.inMillis > 0) Some(schedule(timeout, { cancelled = true; onTimeout })) else None
        try {
          f
        } finally {
          task map { t =>
            t.cancel()
            timer.purge()
          }
          if (cancelled) throw new TimeoutException
        }
      }

      private def schedule(timeout: Duration, f: => Unit) = {
        val task = new TimerTask() {
          override def run() { f }
        }
        timer.schedule(task, timeout.inMillis)
        task
      }
    }

(An alternative implementation of Timeout could use Futures, 
but that's a subject for another blog post)

(Timeout の alternatvie な 実装として Futures を使うことができますが、
それは別の blog post の subject になります)


Modularity and testing techniques (Modularity とテスト技法)

One of the principal advantages of (or stated another way, one of the principal 
motivations for) writing Decorator-oriented code is how easy it is to write isolated 
unit tests of that code. To test the timeout functionality of the TimingOutQuery we 
don't need to interact with a database at all. We can write behavioral/mockish tests 
like this:

デコレーター指向 (Decorator-oriented) なコードを書く主なアドバンテージの一つ(もしくは、
そうすることの主要な動機のひとつ) が、そのコードに対する isolate されたユニットテスト
の記述がいかに簡単であるかということです。TimingOutQuery の timeout functionality をテ
ストするためにデータベースなどとの interact を行う必要はありません。次のように 
behavioral/mockish tests を記述できます:

    val latch = new CountDownLatch(1)
    val query = new FakeQuery(List(resultSet)) {
      override def cancel() = { latch.countDown() }

      override def select[A](f: ResultSet => A) = {
        latch.await(2.second.inMillis, TimeUnit.MILLISECONDS)
        super.select(f)
      }
    }
    val timingOutQuery = new TimingOutQuery(query, timeout)

    timingOutQuery.select { r => 1 } must throwA[SqlTimeoutException]
    latch.getCount mustEqual 0

If the timeout functionality was just inlined into the #select() method of the source 
code of the Query class, or “bolted on” as an alias_method_chain in Ruby (or added 
as “advice” in some AOP shit) you could not write this test without talking to the 
database and somehow finding a query that takes long enough that it will actually hit 
the timeout. Because we instead use Decorators, to test the code we can use a fake 
query that implements the Query interface but that doesn't talk to the database at all. 
Here we use a CountDownLatch to “halt” execution for a bounded amount of time, thus 
triggering the timeout.

もし timeout の functionality がただ単にQuery クラスのソースコード中の #select メソッ
ド中にインライン展開されていたものであったり、あるいは Ruby における 
alias_method_chain のように“bolted on”されたもの(または 一部の×××××な AOP の
“アドバイス”として追加されたもの) であれば、あなたはデータベースとの対話をせずにこの
テストを記述することはできなかったでしょうし、タイムアウトを実際に起こすような充分時間
のかかる query を見つけだすようなことをしなければならなかったでしょう。ここではわたし
たちは代わりに Decorators を使っているのでコードのテストのために Query インターフェース
を実装している fake query を使えますが、それはデータベースなどとの会話は行いません。
わたしたちはここで時間制限された実行を“halt”するために CountDownLatch を使っているの
で、タイムアウトを引き起こします。


Tying it together with Factories (ファクトリーを一緒に結びつける)

Back to our original mission. So now we have a way of layering on timeout 
functionality on top of a Query object. But how do we ensure that Timeouts get used 
when we want them to? The thing that glues this all together is to make sure that 
everybody that needs to instantiate a Query object never ever calls new Query directly. 
We provide instead a Factory as a parameter to the method that needs to manufacture 
the object. The programmer chooses which Factory to provide at runtime. Here is a 
Factory that makes TimingOutQueries:

ここでわたしたちの original mission に戻ります。現在わたしたちは Query オブジェクトの
トップにtimeout functionality を layering on する手段を持っています。しかし、Timeouts 
がわたしたちがそれを必要としているときに使われるということをどうやって保証 (ensure) で
きるでしょうか?これらすべてを解決するのは、Query オブジェクトのインスタンス化を行う必
要のあるすべてのひとがけっして new Query を直接呼び出さないようにすることですわたした
ちはオブジェクトを構築するのに必要となるメソッドをパラメーターとして受け取るファクトリ
ーを提供しています。プログラマーは実行時に提供するファクトリーを選択します。以下に示す
のが TimingOutQueries を作るファクトリーです:


    class TimingOutQueryFactory(queryFactory: QueryFactory, timeout: Duration) extends QueryFactory {
      def apply(connection: Connection, query: String, params: Any*) = {
        new TimingOutQuery(queryFactory(connection, query, params: _*), timeout)
      }
    }

Since TimingOutQueries are decorators around regular Queries, to manufacture a 
TimingOutQuery you have to first manufacture a regular Query. In this example, the 
TimingOutQueryFactory takes another Factory as an argument. This could be a simple 
QueryFactory or something more complex-allowing Factories to be composed indefinitely. 
With this we stack together timeouts, logging, statistics gathering, and debugging 
like so many pieces of legos. This smacks of the oft-ridiculed Java 
AbstractFactoryFactoryInterface. But let me put it bluntly: 
AbstractFactoryFactoryInterface's are how you write real, modular software-not little 
fart applications.

TimingOutQueries は通常 (regular) の Queries を修飾するデコレーターなので、
TimingOutQuery を生産 (manufacture) するにはまず通常の Queryを構築する必要があります。
この例では、TimingOutQueryFactory は引数として別の Factory を取っています。これには 
QueryFactory や、曖昧な合成 (composed indefinitely) を許す Factoriesのようなより複雑な
ものを単純にできる可能性があります。これを使ってわたしたちは timeouts, logging, 
statistics gathering を一緒に stack して、たくさんのピースのレゴのようにデバッグします。
これにはたびたび嘲笑されている Java の AbstractFactoryFactoryInterface の雰囲気があり
ます。遠慮なく言わせてもらえば、AbstractFactoryFactoryInterface というのはreal で、
modular なソフトウェア、little fart でないアプリケーションをどのように書くかということ
です。

# bluntly 無遠慮に、ぶっきらぼうに
# fart 嫌な、莫迦な、屁

This seems like a bit of a mind-fuck because we here have Factory Decorators that take 
Decorated Factories that make Decorated Queries. It's so meta! (Actually, “meta” in 
Greek means nothing like “meta” in English. “Meta” plus the accusative means “
after” so Aristotle's Metaphysics is actually just a book “after [the book on] 
physics”. Anyway.) So all these crazy FactoryFactoryDecorators sound kind-of scary at 
first but it is just the kind of abstraction on top of abstraction and closure under 
composition that allows complex software to be made simple. Manage complexity by 
taking many things and re-conceiving of them as just one thing; this one thing is then 
combined with many other things and the process is repeated up the ladder of 
abstraction until you reach the Godhead.

Decorated Queries を作る Decorated Factories を引数にとる Factory Decorators がわたし
たちにはあるので、これは bit of a mind-fuck のように思われます。なんと meta なことか! 
(実際のところは、ギリシア語でいう “meta”には英語の  “meta”のような意味はありません。
 “Meta” plus the accusative means “after” so Aristotle's Metaphysics is actually
just a book “after [the book on] physics”. Anyway.) 。これら crazy 
FactoryFactoryDecorators すべては最初のうちは kind-of scary のように見えますが、
abstr0action のトップにある abstraction の一種であり、複雑なソフトウェアを可能にする合
成の下の closure をシンプルにするためのものです。
this one thing is then 
combined with many other things and the process is
repeated up the ladder of abstraction until you reach the Godhead.
Godeheadにあなたが到達するまで抽象化の階段の繰り返されます

# taking many things による複雑さの管理と
# just one thing としての
# re-conceiving of them

Taking this to the next level (Taking this to the next level)

To take this even further, let's add a new feature: per-query timeouts. At one point 
in the history of FlockDB, there was a global 3-second timeout. This was really stupid 
given that our most common query has a latency of 0.5ms and a standard deviation of 
2ms. If you have a global timeout you must set your timeout around your most expensive 
query not your most common query (otherwise, your most expensive query will always 
timeout!). But for a production system, cheap frequent queries, if they start 
exceeding 2 standard deviations, can take down your site. So a sensible timeout for 
these frequent queries is like 5ms. But we had it set to 3,000 ms!! Yikes. So let's 
change it!

To take this even further,
新しい機能 per-query timeouts を追加することにしましょう。
FlockDB のヒストリー中のあるポイントで
三秒のグローバルなタイムアウトがありました。

This was really stupid 
given that our most common query has a latency of 0.5ms and a standard deviation of 2ms. 

これはとてもバカバカしいことです

わたしたちの一般的な query は0.5ミリ秒のレイテンシーで、
標準偏差が2ミリ秒

もしあなたがグローバルタイムアウトを持っているのなら、
最も一般的な query ではなく最も高価な query に対して
タイムアウトをセットしなければなりません
(さもなければ、最も高価な query が常にタイムアウトしてしまうでしょう!)。
しかし production system の cheap frequent な queriesに対して
start exceeding 2 standard deviations
であれば、あなたのサイトを take down してしまうかもしれません。
ですから、these frequent queries のための  sensible timeout は
おおよそ 5ms なのです。

But we had it set to 3,000 ms!! 
Yikes. So let's change it!

    class PerQueryTimingOutQueryFactory(queryFactory: QueryFactory, timeouts: Map[String, Duration])
      extends QueryFactory {

      def apply(connection: Connection, query: String, params: Any*) = {
        new TimingOutQuery(queryFactory(connection, query, params: _*), timeouts(query)) // YAY
      }
    }

That's it. We've now implemented a new Timeout strategy in one line of code! And to 
wire it all together it is a piece of cake! Querulous makes no assumptions about how 
best to implement a timing-out strategy, it doesn't even assume you'll want timeouts 
(in fact, there are some cases you don't want any timeouts). Querulous achieves 
modularity by providing an “injection point” for the programmer to layer on custom 
functionality. It takes QueryFactories as a parameter to the method, which can return 
arbitrarily decorated Queries.

まさにこれです。新しい Timeout の戦略をコード一行で実装しました!そして、全てをまとめて
しまうことは朝飯前 (a piece of cake)です! timing-out 戦略を実装するのにどうするのが最
善かどうかについてQuerulous では一切の仮定をしていませんし、あなたが timeouts を必要と
することすら想定しません(実際、一部のケースではあなたは timeouts を必要としないでしょ
う)。Querulous は custom functionality を重ねるプログラマー向けの“injection point”を
提供することによってmodularity を達成しています。この “injection point”は任意の 
decorated Queries を返すことができるメソッドに対するパラメーターとして QueryFactories 
を受け取ります


I love this example because it's so simple but yet it's no toy. It also emphasizes the 
value of Dependency Injection more generally than just with Factories. We could have 
written the TimingOutQuery with a static global constant (probably the most common 
programming technique):

シンプルではあっても単なる toy (おもちゃ)ではないので、わたしはこの例が好きです。これ
はまた依存性注入の価値が、単にファクトリだけを使うものよりもさらに一般的なものであるこ
とを強調します。わたしたちは、(おそらくもっとも一般的なプログラミング技法である) 
static な global constant を使ってもTimingOutQuery を記述できたでしょう:


    class TimingOutQuery(query: Query) extends QueryProxy(query) {
      val TIMEOUT = 3.seconds

But intead it is injected as a parameter to the constructor to the TimingOutQuery:
しかしここではコンストラクターのパラメーターとして TimingOutQuery に注入 (inject) されています:

     class TimingOutQueryFactory(queryFactory: QueryFactory, timeout: Duration) extends QueryFactory {
        def apply(connection: Connection, query: String, params: Any*) = {
          new TimingOutQuery(queryFactory(connection, query, params: _*), timeout)
        }
      }

This enables the TimingOutQueryFactory to invoke a function to choose the appropriate 
timeout for this query. In this case, we just look some shit up in a hash table 
(timeouts(query)) and we're done.

これは TimingOutQueryFactory が関数を query に対する適切なタイムアウトを選択する
ために起動できるようにします。この場合、
we just look some shit up in a hash table (timeouts(query)) and we're done.
わたしたちはハッシュテーブル中の some shit up を見て、処理しているだけです。


Yes, all this FactoryFactory bullshit is exactly what you hate about Java. But it's 
amazing not how just short this code is but that it could be configured by any 
programmer anywhere, regardless of whether they have access to the source code that 
actually instantiates and executes queries. Any user of Querulous can decide if she 
want timeouts or not, and she can decide if they also want debugging, stats gathering, 
and so forth?Querulous hard-codes no assumptions. So, yay modularity.

そう、この FactoryFactory という××××があなたが Java で嫌っているものなのです。コードが
これだけ短いということが驚きなのではなく、it could be configured by any programmer 
anywhere, どんなプログラマーがどの場所からでも実際にインスタンス化を行ったりクエリを実
行しているソースコードにアクセスできるかどうかには関係なくconfigure できることが驚きな
のです。Querulous のユーザー誰でも、は自分がタイムアウトを望むのか否かや、デバッグを行
うか否かといったこと、統計情報を集めたり and so forth? ということを自分自身で決定できます。

Querulous hard-codes no assumptions. 
So, yay modularity.

これに応答した Roman Roelofsen's blog: Why I hate everything you love about Java つーのもあったり。

■_ 本日の巡回から


一つ前へ 2010年3月(上旬)
一つ後へ 2010年3月(下旬)

ホームへ


Copyright (C) 2010 KIMURA Koichi (木村浩一)
この文書の無断転載はご遠慮ください(リンクはご自由にどうぞ)。

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp