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

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

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

ホームへ

2010年06月20日

■_

・ハーバード白熱教室
第6回以降ついていくのがかなりきつかった。 この最終回なんかは何度も見返しそうな気がする(HDDレコーダーの容量がアレなので 全部を残せないのはちと悲し)。 そして NHK ハーバード白熱教室 視聴者のみなさんからの好評にお応えして、8月、サンデル教授が来日、特別講義を行う予定です。 その模様は、秋に特別番組として放送する予定です。特別講義に当たり、みなさんから参加者を 募集する予定です。場所、日時、応募要項について、このホームページなどでまもなくお知らせします。 「我こそはサンデル教授と正義について議論したい」という方、ぜひご参加ください。(2010/6/20) 実に興味はあるがこういうのは若い人が積極的に行くべきだろう。うん。

ということですでに買ってはいたこれを読みながらゆっくり考えるとしよう。
これからの「正義」の話をしよう――いまを生き延びるための哲学

■_

これも訳したい。 たまる一方だよ ○| ̄|_


Advanced C++ Idioms
Advanced C++ Idioms

C++ is a multi-paradigm programming language. This means that there is no single style 
that is always the right one to use on C++ programs. It all depends on the task at 
hand. For example, it is completely fine to use C++ only as a structured language, 
since it has all elements of C and a few more that make structured programming even 
easier in C++.

(以下略)

■_ 完全であろうとするな

それとも目指すな?

You're not perfect, so don't try to be. (あなたは完全ではないし、またそうあろうとしてはいけない)


Don't Be A Perfectionist
Don't Be A Perfectionist

by Matt on June 12, 2010
Submit to reddit

This one's short and sweet, guys, and it goes for life as much as for programming:

You're not perfect, so don't try to be.

Perfection is a dream, an illusion. It resides in the gossamer realms of theory and 
divinity, but not here. Don't try to capture it. Don't try to touch it. Don't waste 
your valuable time.

In code, abandon the vacuous notions of perfect interfaces and perfect encapsulation. 
Leave behind your ideas about perfect design. Screw up. Catch yourself. Fix it. It is 
only through failure that we learn to succeed. Refactoring – not planning – is a 
programmer's best friend.

In life, embarrass yourself. Admit weakness. Flaunt it – for it is only our imperfections
that make us human. Screw up. Catch yourself. Fix it. The man who claims perfection is a
coward. The man who owns imperfection is real.

Your thoughts?

In life, embarrass yourself. Admit weakness. Flaunt it - for it is only our imperfections that make us human. これもまた、なんとなく意味は取れるけど日本語にできないやつだな(^^; embarrass → ~を複雑にする、 flaunt → 誇示する、みせびらかす あたりだから、

■_ Perl 6

だんだん追いかける気力も尽きかけて

Perl6/Parrotスレ - Part2 
320 nobodyさん [sage] 2010/06/18(金) 23:34:56 ID:??? Be:
    Rakudo Star のリリース予定日が7月29日になった 

321 nobodyさん [sage] 2010/06/19(土) 21:22:43 ID:??? Be:
    出る出る詐欺に騙され続けたけど今回は現実味があるな。
    遅れても2~3年以内ぐらいには出るだろう。 

322 nobodyさん [sage] 2010/06/20(日) 00:30:19 ID:??? Be:
    それ出る出る詐欺ちゃうん 

323 nobodyさん [sage] 2010/06/20(日) 04:33:51 ID:??? Be:
    出来ていようが出来ていまいが必ず7月29日にリリースするよ、というようなことを言ってる
    ttp://use.perl.org/~pmichaud/journal/40407

Journal of pmichaud (6013)

Rakudo Star (a "usable Perl 6") to be released by July 29

[ #40407 ]

As many of you know, last summer we announced that we would be releasing a 
"usable release of Rakudo Perl 6" to be called "Rakudo Star" in 
the second quarter of 2010. We later refined our target release date to be April 2010.
(略)


Therefore, we've decided to to let the release date slip one more month and release 
Rakudo Star not later than July 29, 2010. We are firmly committed to the July 29 date; 
whatever we have available then, that's what we release. I know that another delay 
will be frustrating to many (it is very frustrating to me), and that some will 
undoubtedly cite this delay as yet more "evidence" that there will never be 
a release of Perl 6. But given the circumstances, I think we feel that we promote Perl 
6 better by moving the release date by a month than we would by releasing something 
less than our vision.

For those who might claim that we should "release early", we are still 
continuing to make regular monthly compiler releases. The most recent release (#30, 
"Kiev") comes with a lot of improvements over previous releases, and I truly 
expect the next release (#31, "Atlanta") to continue the trend. As always, 
we continue to invite people to try out the compiler releases and to visit the Perl 6 
website to see what Perl 6 is already doing today.

Finally, on a personal note, my wife and I sincerely appreciate the ongoing support, 
prayers, and understanding we have received from the Perl community (and especially 
the Rakudo and Perl 6 teams) during these difficult times. While my wife is still not 
"out of the woods" yet, things are far better now than they were in the 
Spring, and we continue to work towards and pray for her full recovery.

More details about the Rakudo Star release will be forthcoming over the next couple of 
weeks.

Pm

ふむ。 we've decided to to let the release date slip one more month and release Rakudo Star not later than July 29, 2010.

■_

Why computers have two zeros: +0 and -0 — The Endeavour

The Endeavour

The blog of John D. Cook

Why computers have two zeros: +0 and -0

by John on June 15, 2010

Here's a strange detail of floating point arithmetic: computers have two versions of 0: 
positive zero and negative zero. Most of the time the distinction between +0 and -0 
doesn't matter, once in a while signed versions of zero come in handy.

コンピューターは正のゼロと負のゼロという二種類の 0 を持っています。
ほとんどの場合、+0と-0を区別することには意味がありません。
once in a while signed versions of zero come in handy.


If a positive quantity underflows to zero, it becomes +0. And if a negative quantity 
underflows to zero, it becomes -0. You could think of +0 (respectively, -0) as the bit 
pattern for a positive (negative) number too small to represent.

正の値(positive quantity) はゼロ方向にアンダーフローすると +0 になりますし、
負の値(negative quantity)がゼロ方向にアンダーフローすると -0となります。
+0 (respectively, -0) は表現するには小さすぎる正(あるいは負)の数の
ビットパターンとみなすことができるでしょう。

The IEEE floating point standard says 1/+0 should be +infinity and 1/-0 should be 
-infinity. This makes sense if you interpret +/- 0 as the ghost of a number that 
underflowed leaving behind only its sign. The reciprocal of a positive (negative) 
number too small to represent is a positive (negative) number too large to represent.

IEEEの浮動小数点数標準では、1/+0 は +infinity に、1/-0 は -infinityになるべきであると
しています。これは+/-0 を underflowed leaving behind only its sign な
ghost of a number であると解釈 (interpret) するのであれば意味がありますが、
The reciprocal of a positive (negative) number too small to represent is a positive
(negative) number too large to represent.


To demonstrate this, run the following C code.
これをデモするために次のCコードを実行します。


int main()
{
    double x = 1e-200;
    double y = 1e-200 * x;
    printf("Reciprocal of +0: %g\n", 1/y);
    y = -1e-200*x;
    printf("Reciprocal of -0: %g\n", 1/y);
}

On Linux with gcc the output is

Linux上のgccの出力はこうなりました

Reciprocal of +0: inf
Reciprocal of -0: -inf

Windows with Visual C++ returns the same output except Windows prints infinity as 
1#INF rather than inf.

Windows上 の Visual C++ でも無限大が inf ではなく 1#INFのように表示されることを除けば
同じ出力を返します。


There is something, however, about signed zeros and exceptions that doesn't make sense 
to me. The aptly named report “What Every Computer Scientist Should Know About 
Floating Point Arithmetic” has the following to say about signed zeros.

しかし符号付きのゼロやわたしにとっては意味のない例外が存在しています。
“What Every Computer Scientist Should Know About Floating Point Arithmetic”
という題名のレポートは符号付きのゼロについて以下のように述べています:


    In IEEE arithmetic, it is natural to define log 0 = -∞ and log x to be a NaN when x < 0.
    Suppose that x represents a small negative number that has underflowed to zero. Thanks
    to signed zero, x will be negative, so log can return a NaN. However, if there were no
    signed zero, the log function could not distinguish an underflowed negative number from
    0, and would therefore have to return -∞.

    IEEEのarithmeticでは、log 0 = -∞とし、x < 0 のときに log x を NaN と定義することは
    自然なことです。x がゼロの方へアンダーフローした小さな負の数であると仮定すると、
    符号付ゼロのおかげで x は負 (negative) となり、so log can return a NaN.
    しかし符号付ゼロがなかったならば、この log 関数はアンダーフローした負の数と
    0とを区別することができず、したがって -∞を返さなければならなくなるでしょう。


This implies log(-0) should be NaN and log(+0) should be -∞. That makes sense, but 
that's not what happens in practice. The log function returns -∞ for both +0 and -0.

これは log(-0) が NaN になり、log(+0) が-無限大になるべきであることを想定しています
これには意味ああるものですが、実際に使われているものではありません。
実際の log 関数は +0 と-0 の両方に対して-∞ を返すのです。

I ran the following code on Linux and Windows.

わたしは次のようなコードをLinuxとWindowsで実行してみました。

int main()
{
    double x = 1e-200;
    double y = 1e-200 * x;
    printf("Log of +0: %g\n", log(y));
    y = -1e-200*x;
    printf("Log of -0: %g\n", log(y));
}

On Linux, the code prints
Linux ではこのコードの出力はこうなります

Log of +0: -inf
Log of -0: -inf

The results were the same on Windows, except for the way Windows displays infinities.

無限大の表示を除けば、Windowsでも同じ結果となります。

■_ 本日の巡回から

■_

今週はいろいろと買うものがあるような気がするなあ ○| ̄|_

2010年06月19日

■_

・シグルイ
本当に次で最終回なんか…

・今川義元
センゴク

・ 空振り
山手線一周して先行販売してたやつとか買おうと思ってたの全然見つけられず。 タイミング悪かったのかなあ。 悔しいのでこの辺買った。
秋葉原は今
ってこれも先行販売だったのか。 ざっと読んでみたところではなかなか面白そうです。 進駐軍の文書だかを見て、地名の読みがはっきりわかったとか。
20歳のときに知っておきたかったこと スタンフォード大学集中講義
ぱらぱらと眺めてたら心に響くくだりがあったのでつい(笑) 感想なりはまあ書くかもしれないし書かないかもしれません。いつものとおり。 「20歳のときに知っておきたかったこと スタンフォード大学集中講義」はなぜ日本で売れているのか - Innovation, Creativity and Entrepreneurship
あんまり買いまくるのもアレなので (あれとかあれとかあれとかを買う資金がなくなっちゃうじゃあないですかw)、 これは断念。
一万年の進化爆発 文明が進化を加速した

http://virtualrealityblog.com/articles/using-the-c-stl-part-1-intro-and-sequence-containers/ http://virtualrealityblog.com/articles/using-the-c-stl-part-2-associative-containers/

■_ こういう事例も集めといたほうがいいのかなあ

キーワードは「GPL互換」?

【GNU】アンチGPLなプログラマ2【汚染対策】
518 仕様書無しさん [sage] 2010/06/18(金) 21:19:17 ID: Be:
    俺の作ったライブラリ(非GPLでかつ、非GPL互換かつ、非プロプラかつ、ソースは公
    開)が、他人の作ったGPLアプリケーションからリンクされてしまった。。
    これ自体はまー、いいし、ソースは公開してるんでそのアプリのtarballに俺のソー
    スが含まれる事も構わない。ただし、俺のライブラリが非GPLである事だけは保ちた
    いんだけど、現状それは保たれてるでしょうか。

    識者の方、御教示下さい。よろしくです。

519 仕様書無しさん [sage] 2010/06/18(金) 23:13:16 ID: Be:
    >>518
    他人がGPLを何も弄ってなければ、その他人自身がGPLの条件を満たせてないと思う。
    GPLなソフトからリンクしただけでは>>518のライブラリは盗めない。
    他人が全部のライセンスを守ってGPLで頒布するには次の条件を満たす必要があるな。

    ・ >>518のライブラリに対するライセンス条件を守る
    ・ >>518のライブラリのライセンスがGPLで定める権利を制限しないことを確認する。
     例えば>>518のライブラリのライセンスに宣伝条項が付いている場合、GPLかライブラリの条件のどちらかを破ることになってしまうのでアウト。
    ・ GPLなソフトに>>518のライブラリとリンクすることを許可する例外条項を加える
    ・ GPLなソフトが第三者のGPLソースを使っている場合、第三者がそのような例外条項を加えることを許可している

    全部満たした場合、>>518のライブラリは非GPL、それ以外の部分はGPLになって、特に問題は発生しなくなる。 

520 仕様書無しさん [sage] 2010/06/18(金) 23:51:38 ID: Be:
    >518-519
    ここでパクった奴やユーザーから、GPL化を求められた際、
    GPL化を拒否したら>518が叩かれると言う理不尽がありがち。

    そんな事を起こさないように徹底しない限りは、GPLは嫌われて当然だと思う。 

521 仕様書無しさん [sage] 2010/06/19(土) 00:43:28 ID: Be:
    >>518
    >>518が配布してるライブラリ → 非GPL
    リンクした人が配布物に同梱している>>518のライブラリ → GPL

    しかしながら、>>518のライブラリが「非GPL互換」と言うのであれば
    そのリンクしてる人は「著作権違反」してることになるからクレームでも入れてみれば?

    もっとも、「ダイナミックリンクは派生物の構成要件ではない」とする理論を相手が取り、
    なおかつライセンス改変なしで>>518のライブラリをそのまま再配布している場合は
    リンクした人が配布物に同梱している>>518のライブラリ → 非GPL
    となるので、何の問題も無い


    要するにそのリンクしてきたアプリのライセンスと配布物の中身を確認しろ 

528 518 [sage] 2010/06/19(土) 18:23:30 ID: Be:
    レス、どうもです

    ライセンス的に矛盾した状態になるんじゃないかと思ってたんだけど
    やっぱりそうですね。「他人」て書いたけど、実はまんざら全然知らない
    奴じゃないんで連絡したらすぐに変更するって言ってた。 


■_ ××考古学

確かにこういうの必要だと思いますです。

http://twitter.com/tnozaki/status/16552549006
"やっぱり技術考古学ひつようだよなーと某アーカイブを読んでオモタ"


http://twitter.com/tnozaki/status/16552586557
"まぁ老いも若くもキレるようなのは以下略"

http://twitter.com/tnozaki/status/16552839640
"前も似たようなこと書いたけど、古代遺跡いじってる意識がないからイデ発動するのよ。"

http://twitter.com/tnozaki/status/16553531203
"@finalfusion ある意味こういうのはインタビューこなせるテクニカルライターの仕事でしょう、
まぁあの手の人たちじゃ無理でしょうけど。"


http://twitter.com/tnozaki/status/16553783288
"前も書いたけど、howばっかの本はいらんのですよ、whyがほしい"

http://twitter.com/tnozaki/status/16553858762
"ロキノンみたいに開発者とっつかまえて2万字インタビューとかやりゃいいのよ"

「ロキノン」ってナニ? という状態だったのでまずは ask ぐぐるせんせい。 ロキノン - Google 検索 ふみゅ。

■_ 後で考える

なんか引っかかるものがあるんだけど眠い。

xyzzyの使い方が分からぬやし 励ましあえ その12 
782 名無しさん@お腹いっぱい。 [sage] 2010/06/17(木) 00:16:23 ID:mjEf1+A/0 Be:
    xyzzyの正規表現について質問があります。

    (string-match "_\\([^ ]\\|[^ ].+?[^ ]\\)_" "_A AA_")
    がnilとなってマッチしないようですが、その理由が分かりません。

    (string-match "\\(_[^ ]_\\|_[^ ].+?[^ ]_\\)" "_A AA_")とか
    (string-match "_\\([^ ].+?[^ ]\\)_" "_A AA_")
    は0になってマッチするのですが...

    こちらの環境は以下のとおりです。
    * Windows XP Home Edition SP3
    * xyzzy 0.2.2.235

    試しにMeadow 3.02-r4261-3でやってみたら0になってうまくいくようです。
    よろしくお願いします。 

783 名無しさん@お腹いっぱい。 [sage] 2010/06/17(木) 07:03:19 ID:0cx/695o0 Be:
    >>782
    (string-match "^\\(b\\|a+?\\)$" "aaa")
    でも nil となった。バグかなあ。

784 名無しさん@お腹いっぱい。 [sage] 2010/06/17(木) 12:56:30 ID:G+KFG1Qp0 Be:
    現在のカーソル行のコピー(viのyy)ってどうやればいいですか? 

785 名無しさん@お腹いっぱい。 [sage] 2010/06/17(木) 21:30:35 ID:O76gmge/0 Be:
    >>784
    vi 使ったことないから妄想で書いた
    挙動がお気に召さなかったらスマソ

    (defun copy-current-line (&optional (arg 1))
      (interactive "p")
      (save-excursion
        (multiple-value-bind (start end decr)
            (values-list (if (plusp arg)
                            '(goto-bol goto-eol 1-)
                          '(goto-eol goto-bol 1+)))
          (funcall start)
          (setq *clipboard-newer-than-kill-ring-p* nil
                *kill-ring-newer-than-clipboard-p* t)
          (ed::kill-new (buffer-substring (point)
                                          (progn
                                            (forward-line (funcall decr arg))
                                            (funcall end)
                                            (point))))))) 

786 784 [sage] 2010/06/18(金) 13:19:52 ID:rrYblBvZ0 Be:
    >>785
    まさにそれです!
    ありがとうございます 

■_

うーむ。 まとめてる途中とか訳している途中で止まっているのが多いことよ○| ̄|_

■_ 本日の巡回から

2010年06月18日

■_

あれやらこれやら全然すすまね~

■_ てーぶる


C言語なら俺に聞け(入門編)Part 66 
169 デフォルトの名無しさん [sage] 2010/06/16(水) 10:29:49 ID: Be:
    初歩的な質問です

    (1) int hoge1[10] = {0,1,2,3,4,5,6,7,8,9};
    (2) static int hoge2[10] = {0,1,2,3,4,5,6,7,8,9};
    (3) static const int hoge3[10] = {0,1,2,3,4,5,6,7,8,9};

    プログラムを実行すると(1)と(2)はRAMメモリ上のどこかに確保されますよね
    (3)もRAMメモリ上のどこかに確保されるんでしょうか? 

170 デフォルトの名無しさん [sage] 2010/06/16(水) 10:46:08 ID: Be:
    >>169
    環境が具体的に示してないので何とも言えないが、組み込み用の
    Cコンパイラでは(3)の場合オプションを付ける事でROM上に置くような
    環境も存在する 

171 デフォルトの名無しさん [sage] 2010/06/16(水) 10:56:11 ID: Be:
    >>169
    その他、通常(1)はスタックに確保されてその宣言に到達するたびに初期化される。
    (2)は静的領域に確保されて起動時に一度だけ初期化される。
    (3)は(2)とは別の静的領域に確保されて初期化される。また、更新できない。

    それはさて、初期値を全て列挙するなら要素数は省略した方が意図が判りやすいかと。 

172 デフォルトの名無しさん [sage] 2010/06/16(水) 10:59:10 ID: Be:
    ありがとうございます。
    組み込みコンピューターの開発でsinとcosの計算結果を予め360*2個分
    static constで定義しておいて利用するのが目的です
    実行時にRAMに再び確保されるのはなんかメモリの無駄だなーと思いまして
    質問させて頂きました 

173 デフォルトの名無しさん [sage] 2010/06/16(水) 11:00:16 ID: Be:
    >sinとcosの計算結果を予め360*2個分
    なんと無駄なことを。 

174 デフォルトの名無しさん [sage] 2010/06/16(水) 11:19:21 ID: Be:
    >>172
    要求するスピードや、RAM、ROM容量にもよるけど、最低45°分あれば可能。 

175 デフォルトの名無しさん [sage] 2010/06/16(水) 11:43:35 ID: Be:
    助言ありがとうございます
    45度分用意すればいいのは知っているのですが、今回は速度最優先なので
    fn_sin(angle)という関数より sin[angle] で処理することにしました
    余談ですが、始め0.1度づつ3600個*2のデーター用意したら
    「そこまで精度はいらん」と怒られちゃいました(汗 

176 デフォルトの名無しさん [sage] 2010/06/16(水) 12:05:52 ID: Be:
    速度最優先ならsinのテーブルじゃなくて、sinを使った式の結果をテーブルにした方がよくないか?
    メモリはたくさん使っていいみたいだし。 

177 デフォルトの名無しさん [sage] 2010/06/16(水) 12:19:46 ID: Be:
    >>172
    >組み込みコンピューターの開発で
    その開発環境の説明書見たほうが良いよー
    何処に配置するかの説明が必ずあるハズ

    (or 上司に聞く 明示的にROMに配置させるには どう記述するれば良い? って 

181 デフォルトの名無しさん [sage] 2010/06/16(水) 22:30:17 ID: Be:
    >>175
    速度最優先なら内臓RAMに展開を考慮
    内臓Flashへのアクセスがノーウェイトで出来るなら良いが
    CPU動作クロックが高い場合はウェイトが入っている可能性が高い 

182 デフォルトの名無しさん [sage] 2010/06/16(水) 23:10:51 ID: Be:
    × 内臓
    ○ 内蔵 

183 デフォルトの名無しさん [sage] 2010/06/17(木) 00:00:48 ID: Be:
    そもそもターゲットCPUが浮動小数点演算苦手な可能性があるから
    整数を固定小数点数として扱って計算したほうがいいかも知れない 

184 デフォルトの名無しさん [sage] 2010/06/17(木) 01:02:29 ID: Be:
    >>183
    FPUがないCPUで速度最優先なのに浮動小数点演算するって低脳だろ
    必然と固定小数点数にして整数演算することになる 

185 デフォルトの名無しさん [sage] 2010/06/17(木) 01:50:39 ID: Be:
    ここの人たちで、だれが一番高速なsin関数を書けるか競争してみたら?
    ターゲットCPUはもっとも一般的なcore2で 

186 デフォルトの名無しさん [sage] 2010/06/17(木) 01:54:07 ID: Be:
    精度や使用メモリなどの制限をつけないと意味なくね? 

187 デフォルトの名無しさん [sage] 2010/06/17(木) 01:54:28 ID: Be:
    >>185
    sin(theta) 

188 デフォルトの名無しさん [sage] 2010/06/17(木) 02:03:11 ID: Be:
    CPUにCore2使うような環境ならメモリは十分あるだろうからテーブル引くのが一番速い 

189 デフォルトの名無しさん [sage] 2010/06/17(木) 04:44:01 ID: Be:
    てか内部的にテーブル持ってたりしないの? 

190 デフォルトの名無しさん [sage] 2010/06/17(木) 04:51:03 ID: Be:
    ないな 

191 デフォルトの名無しさん [sage] 2010/06/17(木) 05:07:29 ID: Be:
    そなんだ。
    毎回計算してるとかライブラリさんも大変なんだなぁ 

192 デフォルトの名無しさん [sage] 2010/06/17(木) 05:54:48 ID: Be:
    FSIN命令はFPU内部にテーブル持ってる
    精度に問題がない限り、ライブラリはその結果を必要に応じて丸めてるだけ 

初代Pentium の除算バグも確か内部的なテーブルのデータの間違いが原因じゃなかったっけか。 sin と cos のテーブルの容量云々ってのは、 どちらか片方のテーブルがあればもう片方もそのテーブルを使って (引数をちょっと調整するけど)求められるから二つはいらないってのと、 引数を調整して値を求め、その値をさらに調整する(符号ひっくり返すとか)で 求められるからその分テーブルを小さくできるということですね。 って45度分?

■_


初心者です。 perlについて質問させてください。 ループでの、ファイルを読み込ん... - Yahoo!知恵袋

初心者です。

perlについて質問させてください。
ループでの、ファイルを読み込んでの変数について

foreach $data (@NEW) {

($aa1,$bb1,$cc1,$dd1,$ee1,$aa2,$bb2,$cc2,$dd2,$ee2) = split(/\,/,$data);


↑

一行に10のデータがあり、前半5つと 後半の5つを2回のループで呼んで表示させる事は出
来ますでしょうか?



##################


for ( $i=1; $i<=2; $i++) {

print "<TABLE border=\"0\">\n";
print "<TBODY>\n";
print "<TR>\n";
print "<TD>$aa$i</TD>\n";
print "<TD>$bb$i</TD>\n";
print "<TD>$cc$i</TD>\n";
print "<TD>$dd$i</TD>\n";
print "<TD>$ee$i</TD>\n";
print "</TR>\n";
print "</TBODY>\n";
print "</TABLE>\n";

}

試した所、ループ回数のみが表示されました><;

お詳しい方、宜しくお願いいたします。


どうして split の戻り値をリスト(配列)で受け取らないんだろう?

■_

■_

2010年06月17日

■_

しまっちゃうおじさんに見つかってしまったらしまわれちゃうような状態です。ええ。

■_ 金が出て行くなあ

O'Reilly Japan News 第149号                      2010-6-17

(略)

-----------------------------------
●ビューティフルセキュリティ
Andy Oram 、John Viega 編
伊藤 真浩 訳
定価2,940円(税込)
ISBN978-4-87311-459-0

[書籍紹介]
http://www.oreilly.co.jp/books/9784873114590/

『ビューティフルコード』、『ビューティフルアーキテクチャ』に
続くビューティフルシリーズ第3弾。セキュリティの第一線で活躍
する19人のエキスパートたちが、いまあるセキュリティの脅威とそ
の対処法を実際の体験を織り交ぜて紹介しています。編者の一人は
『セキュリティの神話』をはじめ、多数のセキュリティ関連書籍を
執筆しているJohn Viega。著者にはPGP開発者のPhilip Zimmermann、
有名なハッカー集団ロフトのメンバーPeiter "Mudge" Zatkoをはじ
め、多彩なメンバーが揃っています。セキュリティの歴史から、現
在ある脅威、セキュアなシステムの設計、開発者の心理、将来への
指針など幅広い分野をカバーしています。

===========================================================
■Coming Soon

来月発売予定の書籍情報です。7月は以下の5点。鋭意制作中につき、
楽しみにお待ちください。
-----------------------------------
●アプレンティスシップ・パターン
徒弟制度に学ぶ熟練技術者の技と心得
Dave H. Hoover、Adewale Oshineye 著
柴田 芳樹 訳
定価2,310円(税込)
ISBN978-4-87311-460-6
-----------------------------------
●Erlangプログラミング
Francesco Cesarini、Simon Thompson 著
佐藤 嘉一 訳
定価3,780円(税込)
ISBN978-4-87311-465-1
-----------------------------------
●初めてのコンピュータサイエンス
Jennifer Campbell、Paul Gries、Jason Montojo、Greg Wilson 著
長尾 高弘 訳
定価2,520円(税込)
ISBN978-4-87311-463-7
-----------------------------------
●Head Firstデータ解析
頭とからだで覚えるデータ解析の基本
Michael Milton 著
大橋 真也 監訳
木下 哲也 訳
定価3,360円(税込)
ISBN978-4-87311-464-4
-----------------------------------
●Android Hacks
プロが教えるテクニック & ツール
株式会社ブリリアントサービス 著
定価3,360円(税込)
ISBN978-4-87311-456-9

ぶっちゃけ全部買いたいところ ○| ̄|_

■_ 網にかかった

Type-Level Programming in Scala, Part 4a: Peano number basics « Apocalisp

なんかここ数日で二回くらいアンテナに引っかかってきていて、 On Monoids « Apocalisp これとか。 過去のエントリーのタイトルを見ても面白そうなので追いかけてみることにした。

■_

Scala は better Java じゃあないよ? とか。


John Fremlin's blog: Scala is not a better Java

Posted 2010-06-16 18:42:34 GMT

The Scala programming language has all the features of Java, and supports all sorts of 
fun things like closures, higher-kinded types and inline XML. If you're starting a new 
project for the JVM, shouldn't you just use Scala?

The Scala environment is very interesting and in 2.8 has the ability to pass around 
unboxed primitive types through to functions that are specified over multiple types — 
so that generic functions no longer have a massive performance penalty.

Scala has operator overloading, and even the ability to give the appearance of adding 
new methods to existing types via the implicit mechanism.

These things make the task of writing code much more convenient. There's less need to 
explicitly distinguish between arrays and other sequences and unboxed doubles and 
other numeric types. Papering over the division between arrays, primitive types and 
reference types in the JVM actually reduces to some extent the conceptual complexity 
of using it.

But these ideas are fundamentally opposed to the reason Java came into being. Scala 
positions itself as "multi-paradigm programming language designed to express 
common programming patterns in a concise, elegant" way. Java is culturally 
opposed to these ideas: it is deliberately simple. The "Java design team examined 
many aspects of the "modern" C and C++ languages to determine features that 
could be eliminated in the context of modern object-oriented programming" while 
still retaining some similarity to C++ syntax.

(略)

Java was supposed to start small and grow as a reaction against the perceived causes 
for which languages like Lisp and Smalltalk were rejected. Scala is proud of the power 
of its higher-kinded types: Java is proud of removing multiple inheritance. They're 
not really competitors: the cultural gulf is huge.

Perhaps Scala will be able to drag the JVM into competition with numerous other 
platforms. It has a good set of web companies (for example, Foursquare) using it as a 
replacement for programmer-orientated scripting languages, and that's where Scala has 
a natural fit, albeit with strong-typing.

Java is deliberately not programmer-orientated. That's the point of using it — it was 
designed to restrict the kind of trouble programmers can get themselves into. If 
you're stuck with the JVM, I guess the question is: how much rope do you want to give 
your programmers? Scala is essentially the opposite answer to Java.

小さく始めて大きく育てるのを reject したのが Java と。

■_ 本日の巡回から

■_

18日分は休むかもしれないのでヨロシク。

2010年06月16日

■_

・個人スポンサー
何とか間に合ったみたい。 が、チケットが2枚に。どうすべえ(笑)

■_ sort

ちょっと追いかけた(GNU sort)

/* sort - sort lines of text (with all kinds of options).
   Copyright (C) 1988, 1991-2010 Free Software Foundation, Inc.

(略)

/* Compare two lines A and B trying every key in sequence until there
   are no more keys or a difference is found. */

static int
keycompare (const struct line *a, const struct line *b)
{
  struct keyfield *key = keylist;

  /* For the first iteration only, the key positions have been
     precomputed for us. */
  char *texta = a->keybeg;
  char *textb = b->keybeg;
  char *lima = a->keylim;
  char *limb = b->keylim;

  int diff;

  for (;;)
    {
(略)
      /* Sorting like this may become slow, so in a simple locale the user
         can select a faster sort that is similar to ascii sort.  */
      else if (hard_LC_COLLATE)
        {
          if (ignore || translate)
            {
              char buf[4000];
              size_t size = lena + 1 + lenb + 1;
              char *copy_a = (size <= sizeof buf ? buf : xmalloc (size));
              char *copy_b = copy_a + lena + 1;
              size_t new_len_a, new_len_b, i;

              /* Ignore and/or translate chars before comparing.  */
              for (new_len_a = new_len_b = i = 0; i < MAX (lena, lenb); i++)
                {
                  if (i < lena)
                    {
                      copy_a[new_len_a] = (translate
                                           ? translate[to_uchar (texta[i])]
                                           : texta[i]);
                      if (!ignore || !ignore[to_uchar (texta[i])])
                        ++new_len_a;
                    }
                  if (i < lenb)
                    {
                      copy_b[new_len_b] = (translate
                                           ? translate[to_uchar (textb[i])]
                                           : textb [i]);
                      if (!ignore || !ignore[to_uchar (textb[i])])
                        ++new_len_b;
                    }
                }

              diff = xmemcoll (copy_a, new_len_a, copy_b, new_len_b);
(略)
}


とまあ、「行」のバイト列の比較は↑に出てくる xmemcoll ってのがやるわけなんですが、

/* Compare S1 (with length S1LEN) and S2 (with length S2LEN) according
   to the LC_COLLATE locale.  S1 and S2 do not overlap, and are not
   adjacent.  Temporarily modify the bytes after S1 and S2, but
   restore their original contents before returning.  Report an error
   and exit if there is an error.  */

int
xmemcoll (char *s1, size_t s1len, char *s2, size_t s2len)
{
  int diff = memcoll (s1, s1len, s2, s2len);
  int collation_errno = errno;

  if (collation_errno)
    {
      error (0, collation_errno, _("string comparison failed"));
      error (0, 0, _("Set LC_ALL='C' to work around the problem."));
      error (exit_failure, 0,
             _("The strings compared were %s and %s."),
             quotearg_n_style_mem (0, locale_quoting_style, s1, s1len),
             quotearg_n_style_mem (1, locale_quoting_style, s2, s2len));
    }

  return diff;
}

そのまま memcoll へパスして ↓

/* Compare S1 (with length S1LEN) and S2 (with length S2LEN) according
   to the LC_COLLATE locale.  S1 and S2 do not overlap, and are not
   adjacent.  Perhaps temporarily modify the bytes after S1 and S2,
   but restore their original contents before returning.  Set errno to an
   error number if there is an error, and to zero otherwise.  */
int
memcoll (char *s1, size_t s1len, char *s2, size_t s2len)
{
  int diff;

#if HAVE_STRCOLL

  /* strcoll is slow on many platforms, so check for the common case
     where the arguments are bytewise equal.  Otherwise, walk through
     the buffers using strcoll on each substring.  */

  if (s1len == s2len && memcmp (s1, s2, s1len) == 0)
    {
      errno = 0;
      diff = 0;
    }
  else
    {
      char n1 = s1[s1len];
      char n2 = s2[s2len];

      s1[s1len++] = '\0';
      s2[s2len++] = '\0';

      while (! (errno = 0, (diff = strcoll (s1, s2)) || errno))
        {
          /* strcoll found no difference, but perhaps it was fooled by NUL
             characters in the data.  Work around this problem by advancing
             past the NUL chars.  */
          size_t size1 = strlen (s1) + 1;
          size_t size2 = strlen (s2) + 1;
          s1 += size1;
          s2 += size2;
          s1len -= size1;
          s2len -= size2;

          if (s1len == 0)
            {
              if (s2len != 0)
                diff = -1;
              break;
            }
          else if (s2len == 0)
            {
              diff = 1;
              break;
            }
        }

      s1[s1len - 1] = n1;
      s2[s2len - 1] = n2;
    }

#else

  diff = memcmp (s1, s2, s1len < s2len ? s1len : s2len);
  if (! diff)
    diff = s1len < s2len ? -1 : s1len != s2len;
  errno = 0;

#endif

  return diff;
}

と、strcoll で locale に応じた変換をしたうえで比較しているわけです。 が、これは同じ変換でも毎回毎回変換してしまうので エンコーディングの変換にかなりの時間を要してしまうことが想像できます。 プロファイリングして strcoll (とそれが呼び出す関数)の呼び出し回数や 消費している時間を調べればかなりここで食ってんじゃないですかね。

最初に変換をまとめてやってしまってその結果を使うというのもメモリを倍(以上)消費してしまいますし、 元データを捨てたとしても逆変換でおかしなことが発生する可能性があるでしょうし。 なにかうまい方法はあるんでしょうか。

■_


Journal of chromatic (983)

The Perl 6 design team met by phone on 12 May 2010. Larry, Allison, Patrick, and Will attended.

Larry:

    * clarified usage of brackets around infixes
    * added various 128-bit types to the spec; we might make them arbitrarily extensible
      via role
    * at least LLVM could support this, even to non-powers-of-two sizes
    * modernized the paleolithic grammatical category description in S02
    * STD now uses double-quote rules for interpolating @foo[] into regex
    * STD now gives better message on 1__3
    * added the specced 128-bit types to CORE.setting
    * added minmax function to CORE.setting
    * implemented circumfix:«X Y» as grammar derivation
    * currently only allows a >> inside
    * now also recognizes foofix:("\x[face]") and foofix:
      ("\c[YOUR CHARACTER HERE]") without actually evaluating
    * playing with factoring yaml out of gimme5, since viv is not likely to go that route.
    * mostly just answered a lot of questions on irc
    * egged people on about concurrency issues

(略)

興味深い機能だなあとは思うけど、うーーーーん

■_ 本日の巡回から

■_

R まで手が回らなかった ○| ̄|_

2010年06月15日

■_

Rubyist Magazine - 0030 号 巻頭言 今回の一番の難関らしい。

・ムダヅモ
意外な人物(?)がっ!

■_ ちょっと追いかけた

Windows版 R のコマンドプロンプト用のを起動したときに Vista で文字化けが起きるやつ。


R version 2.11.0 (2010-04-22)
Copyright (C) 2010 The R Foundation for Statistical Computing
ISBN 3-900051-07-0

Rは、自由なソフトウェアであり、「完全に無保証」です。
一定の条件に従えば、自由にこれを再配布することができます。
配布条件の詳細に関しては、'license()'あるいは'licence()'と入力してください。

Rは多くの貢献者による共同プロジェクトです。
詳しくは'contributors()'と入力してください。
また、RやRのパッケージを出版物で引用する際の形式については
'citation()'と入力してください。

'demo()'と入力すればデモをみることができます。
'help()'とすればオンラインヘルプが出ます。
'help.start()'でHTMLブラウザによるヘルプがみられます。
'q()'と入力すればRを終了します。

これは正常に出力されたときの起動時のメッセージですが、 該当の文字列をソースから探してみると、ja.po に

#: src/main/version.c:39
msgid ""
"R is free software and comes with ABSOLUTELY NO WARRANTY.\n"
"You are welcome to redistribute it under certain conditions.\n"
"Type 'license()' or 'licence()' for distribution details.\n"
"\n"
msgstr ""
"Rは、自由なソフトウェアであり、「完全に無保証」です。 \n"
"一定の条件に従えば、自由にこれを再配布することができます。 \n"
"配布条件の詳細に関しては、'license()'あるいは'licence()'と入力してくださ"
"い。 \n"
"\n"

というのを発見。version.c で使用されているとあるので、それを見る。

src/main/version.c

void attribute_hidden PrintGreeting(void)
{
    char buf[128];

    Rprintf("\n");
    PrintVersionString(buf);
    Rprintf("%s", buf);
    Rprintf("\nCopyright (C) %s The R Foundation for Statistical Computing\n",
	    R_YEAR);

    Rprintf("ISBN 3-900051-07-0\n\n");
    Rprintf(_("R is free software and comes with ABSOLUTELY NO WARRANTY.\n\
You are welcome to redistribute it under certain conditions.\n\
Type 'license()' or 'licence()' for distribution details.\n\n"));
    Rprintf(_("R is a collaborative project with many contributors.\n\
Type 'contributors()' for more information and\n\
'citation()' on how to cite R or R packages in publications.\n\n"));
    Rprintf(_("Type 'demo()' for some demos, 'help()' for on-line help, or\n\
'help.start()' for an HTML browser interface to help.\n\
Type 'q()' to quit R.\n\n"));
}

_("ほげほげ") というマクロは良く使われるあれなので省略して、 Rprintf というので出力していると。

src/main/printutils.c
void Rprintf(const char *format, ...)
{
    va_list(ap);

    va_start(ap, format);
    Rvprintf(format, ap);
    va_end(ap);
}

src/main/printutils.c

void Rvprintf(const char *format, va_list arg)
{
    int i=0, con_num=R_OutputCon;
    Rconnection con;
#ifdef HAVE_VA_COPY
    va_list argcopy;
#endif
    static int printcount = 0;

    if (++printcount > 100) {
	R_CheckUserInterrupt();
	printcount = 0 ;
    }

    do{
      con = getConnection(con_num);
#ifdef HAVE_VA_COPY
      va_copy(argcopy, arg);
      /* Parentheses added for FC4 with gcc4 and -D_FORTIFY_SOURCE=2 */
      (con->vfprintf)(con, format, argcopy);
      va_end(argcopy);
#else /* don't support sink(,split=TRUE) */
      (con->vfprintf)(con, format, arg);
#endif
      con->fflush(con);
      con_num = getActiveSink(i++);
#ifndef HAVE_VA_COPY
      if (con_num>0) error("Internal error: this platform does not support split output");
#endif
    } while(con_num>0);


}

げ。(con->vfprintf)(con, format, arg); とかって、デバイスごとに関数ポインターのテーブルを持たせて…というやつか? というところで時間切れ。 情報量0だ ○| ̄|_

■_ 無名 or 匿名

翻訳記事だと思うんですが


Microsoft Visual StudioでC++0xのラムダ式を使う - japan.internet.com デベロッパー

はじめに

多くのプログラミング言語が匿名関数(本体はあるが名前のない関数)の概念をサポートしてい
る。匿名関数は呼び出す場所で定義され、たいていは短い計算を実行する。C++プログラミング
言語の初期バージョンでこれに近いことをしようとすると、関数もしくは関数オブジェクトへの
ポインタを使うしかなかった。これらの回避策はいずれも理想的とは言えない。関数へのポイン
タはステートレスであるため、前のコールの値を保持することができない。関数オブジェクトは
ステートを維持できるが、本格的なクラス定義が必要とされる。C++0x 標準は現在、「ラムダ式」
と呼ばれる新機能をサポートするようになった。ラムダ式は匿名関数と似ている。そのコンパク
トなインラインシンタックスは、手作業によるクラス定義を不要にする。さらに、C++アプリケ
ーションのステートを保持することもできる。ここでは、Visual C++ 10(ベータ2)での C++0x 
のラムダ式の使い方を紹介していく。現在、Intel C++ 11.0や GCC 4.5をはじめ複数の主要 C++
コンパイラが既にラムダ式をサポートしている。ほかのものも、まもなく追随する可能性が高い。

(以下略)

本体はあるが名前のない関数 まで書いているのに、 その用語に「匿名」ってのはそぐわないとは考えないんだろうか? 考えないんだろうなあ。

■_ 左 or 右

arton さんところ L'eclat des jours(2010-06-16) 経由で。

バグか?バグなのか? - stehan の日記
void count_down( int i )
{
    while( 0 < i-- ){
        printf( "%d, ", i);
        ::Sleep( 1000 );
    }
    puts("今週のビックリドッキリメカ 発進!!");
}
  

== で比較するときに定数を左に置くというルールはまああるみたいですけど、 こういう while の判定で左側に定数を置くというのはあまり見ないような気がするのだけど どうなんだろう(情報求む)。

まあこの場合、while (--i > 0) だと一個ずれちゃうし while (i-- > 0) も今ひとつ収まりガ悪いな(わたしの視点で、ですが)。 ここはやはり while (i--) で!(マテ あ、二番目のパターンってずいぶん前にここでも紹介したことのある while (i --> 0) というなんとなく数学っぽい表記にできるw

■_ <本日の巡回から

2010年06月14日

■_

第6回R勉強会@東京(Tokyo.R#06) : ATND

そろそろ夏ボーナスでるところもあるのかしらん。

■_ DRY

openFile == null という記述を二回書かなければいけないのは 納得いかんのじゃーというお悩み。

Can I avoid repeating myself in this situation (Java) - Stack Overflow

Can I avoid repeating myself in this situation (Java)

 if (openFile == null) {

      new AppFileDialog().chooseFile("Save", appFrame);

 }

 if (openFile == null) {

      return;

 }

Here I need to check to see if the user has already chosen a file. If not, they are 
given a prompt to. If the file is still null, the function returns without saving. The 
problem is the two identical if statements, can I avoid it? I take DRY very seriously, 
but at the same time KISS. Ideally the two go hand in hand, but in a situation like 
this, it seems they are mutually exclusive.


What does AppFileDialog.chooseFile return? 

Put it in a loop? The file the user selects should never be null though

However you've cut out too much code give any concrete answer. All I see is two 
identical checks which I would merge into one, but I think you coming here for 
something more.

Not quite, although I think a different structure would make the issue more obvious:

// If no file, give the user a chance to open one
if (openFile == null) {
    new AppFileDialog().chooseFile("Save", appFrame);

    // still no file, user must not want to do this
    if (openFile == null) {
        return;
    }    
}


Ill do something like:

int tries = 0;
int maxTries = 3;
do {
   openFile = new AppFileDialog().chooseFile("Save", appFrame);
   if (openFile != null) 
      tries = maxTries;
   tries++;
} while (tries < maxTries);

if (openFile == null)
   return;


They are actually different conditions. What I think you really mean is:

if (openFile == null) {
    openFile = new AppFileDialog().chooseFile("Save", appFrame);

    if (openFile == null) {
        return;
    }
}

Which shows that they don't mean the same thing, but yours is more elegant if you wish 
to add more conditions (more ways that the file could be opened, like using a default 
filename if the user doesn't supply one himself)

However I'd prefer:

openFile = getOpenFile()
if(openFile == null)
    return;

public File getOpenFile() {
   if(openFile == null)
       openFile = new AppFileDialog().chooseFile("Save", appFrame);

   return openFile;
}

This allows the getOpenFile() method to control the openFile variable completely, 
never accessing the openFile variable from any other methods (except perhaps a 
closeFile() method. I use this trick sometimes, making a variable that is 
"Logically private" to just a couple methods in order to reduce complexity a 
little.

まあお手軽なのはループとの組み合わせかなあ。 上の回答の中にもあるけど。

■_ functor


On Functors - good coders code, great reuse

Computer Science 9 Comments May 17, 2010

On Functors
ファンクターについて


It's interesting how the term "functor" means completely different things in 
various programming languages. Take C++ for example. Everyone who has mastered C++ 
knows that you call a class that implements operator() a functor. Now take Standard ML. 
In ML functors are mappings from structures to structures. Now Haskell. In Haskell 
functors are just homomorphisms over containers. And in Prolog functor means the atom 
at the start of a structure. They all are different. Let's take a closer look at each 
one.

“ファンクター”(functor) という用語が、様々な言語において全く異なる意味で使われている
のはとても興味深いことです。C++ を例にとってみると、C++ をマスターした誰もが 
operator() を実装しているクラスをファンクターと呼ぶことを知っています。Standard ML で
はどうかというと、structures から structures へのマッピングです。Haskell では、ファン
クターはコンテナーに対する単なる  homomorphisms です。そして Prolog でのファンクターは 
ある structure の先頭に位置する atom (atom at the start of a structure) です。
これらはすべて異なっています。
Let's take a closer look at each one.


Functors in C++ (C++におけるファンクター)

Functors in C++ are short for "function objects." Function objects are 
instances of C++ classes that have the operator() defined. If you define operator() on 
C++ classes you get objects that act like functions but can also store state. Here is 
an example,

C++ におけるファンクターとは“関数オブジェクト”(function object) の短縮表現です。関数
オブジェクトは operator() が定義されている C++ クラスのインスタンスです。あなたが C++ 
クラスで operator() を定義すると、関数のように振る舞うけれども状態を保持できるようなオ
ブジェクトが得られます。例を挙げましょう


#include <iostream>
#include <string>

class SimpleFunctor {
    std::string name_;
public:
    SimpleFunctor(const char *name) : name_(name) {}
    void operator()() { std::cout << "Oh, hello, " << name_ << endl; }
};

int main() {
    SimpleFunctor sf("catonmat");
    sf();  // prints "Oh, hello, catonmat"
}

Notice how I was able to call sf() in the main function, even though sf was an object? 
That's because I defined operator() in SimpleFunctor's class.

main 関数の中で sf() という呼び出しができたことに注目してください。sf はオブジェクトだ
ったのに関数のように呼び出せたのはなぜでしょうか? それはわたしが SimpleFunctor のクラス
定義で operator() を定義していたからです。


Most often functors in C++ are used as predicates, fake closures or comparison 
functions in STL algorithms. Here is another example. Suppose you have a list of 
integers and you wish to find the sum of all even ones, and the sum of all odd ones. 
Perfect job for a functor and for_each algorithm.

C++ におけるファンクターのほとんどは、STL の algorithms での predicates (述語) や fake 
closures (クロージャーもどき?)、 もしくは comparison functions (比較関数)として使われ
ています。別の例を挙げましょう。あなたの手元に整数のリストがあって、そのうちの奇数のも
のの合計と偶数のものの合計をそれぞれ知ろうとしているとします。

Perfect job for a functor and for_each algorithm.

ファンクターと for_each アルゴリズム向けの perfect job です。

#include <algorithm>
#include <iostream>
#include <list>

class EvenOddFunctor {
    int even_;
    int odd_;
public:
    EvenOddFunctor() : even_(0), odd_(0) {}
    void operator()(int x) {
        if (x%2 == 0) even_ += x;
        else odd_ += x;
    }
    int even_sum() const { return even_; }
    int odd_sum() const { return odd_; }
};

int main() {
    EvenOddFunctor evenodd;
    
    int my_list[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
    evenodd = std::for_each(my_list,
                  my_list+sizeof(my_list)/sizeof(my_list[0]),
                  evenodd);

    std::cout << "Sum of evens: " << evenodd.even_sum() << "\n";
    std::cout << "Sum of odds: " << evenodd.odd_sum() << std::endl;

    // output:
    // Sum of evens: 30
    // Sum of odds: 25
}

Here an instance of an EvenOddFunctor gets passed to for_each algorithm. The for_each 
algorithm iterates over each element in my_list and calls the functor. After it's done, 
it returns a copy of evenodd functor that contains the sum of evens and odds.

この例では EvenOddFunctor のインスタンスが for_each アルゴリズムに渡されています。
for_each アルゴリズムは my_llist 中の各要素を iterates over しながらファンクターを呼び
出します。イテレートが完了したら、for_each アルゴリズムは偶数と奇数の合計を保持してい
る evenodd ファンクターのコピーを返します。


Functors in Standard ML (Standard MLにおけるファンクター)

Vaguely talking in object-oriented terms, functors in ML are generic implementations 
of interfaces. In ML terms, functors are part of ML module system and they allow to 
compose structures.

Vaguely (大雑把) にオブジェクト指向用語で言うと、ML におけるファンクターとはインターフ
ェースの generic な実装です。ML 用語ではファンクターは ML のモジュールシステムの一部分
であり、structures を compose することが可能です。


Here is an example, suppose you want to write a plugin system and you wish all the 
plugins to implement the required interface, which, for simplicity, includes only the 
perform function. In ML you can first define a signature for plugins,

ここで例として、あなたがプラグインシステムを書こうとしていて、かつすべてのプラグインが
要求されているインターフェースを実装することを望んでいるとします。ここでは単純のため、
関数を実行させるだけのインターフェースとします。


In ML you can first define a signature for plugins,

ML では最初にプラグインのためのシグネチャーを定義できます


signature Plugin =
sig
    val perform : unit -> unit
end;

Now that we have defined an interface (signature) for plugins, we can implement two 
Plugins, let's say LoudPlugin and SilentPlugin. The implementation is done via 
structures,

これでプラグインのためのインターフェース(シグネチャー)を定義し、わたしたちは二つのプラ
グインを実装できるようになりました。ここではその二つのプラグインを  LoudPlugin と 
SilentPlugin と呼ぶことにします。その実装は structures を通じて行われます。


structure LoudPlugin :> Plugin =
struct
    fun perform () = print "DOING JOB LOUDLY!\n"
end;

And the SilentPlugin,

structure SilentPlugin :> Plugin =
struct
    fun perform () = print "doing job silently\n"
end;


Now we get to functors. Remember functors in ML take structures as their arguments, so 
we can write one that takes Plugin as its argument,

これでファンクターが手に入りました。MLのファンクターはその引数として structures を取る
ので、プラグインを引数とするものを記述できるのです。

functor Performer(P : Plugin) =
struct
    fun job () = P.perform ()
end;


This functor takes Plugin as P argument, and uses it in the job function, that calls P 
plugin's perform function.

このファンクターは 引数 P としてプラグインを取りそれを job 関数内でプラグイン P の 
perform 関数を呼び出すのに使用します。


Now let's use the Performer functor. Remember that a functor returns a structure,

ではここで Performer ファンクターを使ってみましょう。ファンクターが structure を返すこ
とを思い出してください。


structure LoudPerformer = Performer(LoudPlugin);
structure SilentPerformer = Performer(SilentPlugin);

LoudPerformer.job ();
SilentPerformer.job ();

This outputs,

これは以下の内容を出力します

DOING JOB LOUDLY!
doing job silently

This is probably the simplest possible example of Standard ML functors.

これはおそらく Standard ML ファンクターの可能な限り最も単純な例です。


Functors in Haskell (Haskellにおけるファンクター)

Functors in Haskell is what real functors are supposed to be. Haskell functors 
resemble mathematical functors from category theory. In category theory a functor F is 
a mapping between two categories such that the structure of the category being mapped 
over is preserved, in other words, it's a homomorphism between two categories.

Haskell におけるファンクターは本物のファンクター (real functors) が supposed to be さ
れているものです。Haskell のファンクターは category theory (圏論) でいうところの数学的
なファンクターに似ています。圏論では、あるファンクター F は二つの圏の間で
the structure of the category being mapped over is preserved
のような mapping (写像)を行います。
言い換えると、二つの圏の間の homomorphism です。


In Haskell this definition is implemented as a simple type class,

Haskell ではこの定義は単純な型クラスとして実装されます。

class Functor f where
  fmap :: (a -> b) -> f a -> f b

Looking back at ML example, a type class in Haskell is like a signature, except it's 
defined on types. It defines what operations a type has to implement to be an instance 
of this class. In this case, however, the Functor is not defined over types but over 
type constructors f. It says, a Functor is something that implements the fmap function 
that takes a function from type a to type b, and a value of type f a (a type 
constructed from type constructor f applied to type a) and returns a value of type f b.

Haskell における型クラスはシグネチャーのようなものですが、それが型として定義される点が
異なります。型クラスではそのクラスのインスタンスとしてある型が実装しなければならない操
作 (operations)を定義します。しかしこの場合のファンクターは型ではなく型コンストラクター
f を定義しています。この定義では、あるファンクターとは fmap 関数を実装している何か
(something) で、それは型 a から型 b への関数と型 f の値 a (型コンストラクター f を型 a
に適用して構築された型)を引数に取り、型 f b の値を返すものです。


To understand what it does, think of fmap as a function that applies an operation to 
each element in some kind of a container.

これを理解するために、なんらかのコンテナーに存在している各要素ごとに operation を適用
する関数としての fmap を考えてみましょう。


The simplest example of functors is regular lists and the map function that maps a 
function to each element in the list.

最も単純なファンクターの例は、通常のリストとリストの各要素に対して関数を map する map 
関数です。


Prelude> map (+1) [1,2,3,4,5]
[2,3,4,5,6]


In this simple example, the Functor's fmap function is just map and type constructor f 
is [] - the list type constructor. Therefore the Functor instance for lists is defined 
as

このシンプルな例では fmap 関数は単に 型コンストラクター f と リスト型のコンストラクター []
です。したがって、このファンクターのリストに対するインスタンスは以下のように定義されます

instance Functor [] where
  fmap = map

Let's see if it really is true by using fmap instead of map in the previous example,

先の例の map の代わりに fmapを使ってこれが本当かどうか確認しましょう

Prelude> fmap (+1) [1,2,3,4,5]
[2,3,4,5,6]

But notice that Functor definition does not say anything about preserving the 
structure! Therefore any sensible functor must satisfy the functor laws, which are 
part of the definition of the mathematical functor, implicitly. There are two rules on 
fmap:

しかし注意してください。ファンクターの定義では structure の perserving には一切言及し
ていません! ですから当然、any sensible なファンクターは数学的なファンクターの定義の一
部である functor laws を暗黙のうちに満足しなければなりません。


fmap には二つのルールがあります:

fmap id = id
fmap (g . h) = fmap g . fmap h

The first rule says that mapping the identity function over every element in a 
container has no effect. The second rule says that a composition of two functions over 
every item in a container is the same as first mapping one function, and then mapping 
the other.

最初のルールではコンテナー内にある各要素に対して identity 関数をマッピングすることがな
んの効果も持たない (has no effect) ことに言及しています。二番目のルールでは、二つの関
数の合成をコンテナー内の各アイテムごとに適用するのと、一つの関数をマッピングしてからも
う一つの関数をマッピングするのは同じであるということを述べています。


Another example of Functors that illustrate them the most vividly is operations over 
trees. Think of a tree as a container, then fmap maps a function over tree values, 
while preserving the tree's structure.

もっとも vividly (鮮やかに、はっきりと) にファンターを illustrate するもう一つの例が 
trees に対する操作です。コンテナーとしての tree  を考え、tree の strucure を 
preserving (保存、保つ) している間 fmap が関数をその values に対して map します。


Let's define a Tree first,

まず Tree を定義しましょう

data Tree a = Node (Tree a) (Tree a)
            | Leaf a
              deriving Show

This definition says that a Tree of type a is either a Node of two Trees (left and 
right branches) or a Leaf. The deriving Show expression allows us to inspect the Tree 
via show function.

この定義は Tree という型がふたつの Tree (右と左の枝) のノードか Leaf のいずれかである
ことを述べています。deriving Show という式は show 関数を通じて Tree を inspect できる
ようにしています。


Now we can define a Functor over Trees,

これで、Trees に対する Functor を定義できます


instance Functor Tree where
    fmap g (Leaf v) = Leaf (g v)
    fmap g (Node l r) = Node (fmap g l) (fmap g r)


This definition says, that fmap of function g over a Leaf with value v is just a Leaf 
of g applied to v. And fmap of g over a Node with left l and right r branches is just 
a Node of fmap applied to the values of left and right branches.

この定義では、値 v を持った Leaf に対する関数 g の fmap は v に適用された g の Leaf で
あることを述べています。そして left l と right r のブランチを持った Node に対する g の 
fmap は 単に左右のブランチの値に fmap が適用された Node であることを言っています。


Now let's illustrate how fmap works on trees. Let's construct a tree with String 
leaves and map the length function over them to find out the length of each leaf.

では fmap が trees に対してどのように動作しているかを illustrate しましょう。String の
葉を持った tree を構築し、それか個々の葉の長さを得るためにそれらに対して length 関数を 
map します。


Prelude> let tree = (Node (Node (Leaf "hello") (Leaf "foo")) (Leaf "baar"))
Prelude> fmap length tree
Node (Node (Leaf 5) (Leaf 3)) (Leaf 4)


Here I constructed the following tree,

ここでわたしは次のような tree を構築しました

           *
          / \
         /   \
        *  "baar"
       / \
      /   \
     /     \
    /       \
 "hello"  "foo"

And mapped length function over it, producing,

そしてこれに length 関数を map して生成されたものが

           *
          / \
         /   \
        *     4
       / \     
      /   \
     /     \
    /       \
   5         3


Another way of saying what fmap does is that is lifts a function from the "normal 
world" into the "f world."

fmap が行っていることを述べるもう一つの方法が "normal world" から "f 
world"への関数の lift です。


In fact Functor is the most fundamental type class in Haskell because Monads, 
Applicatives and Arrows are all Functors. As I like to say it, Haskell starts where 
the functors start.

事実、ファンクターは Haskell において最も fundamental な型クラスです。なぜなら
Monads、Applicatives、 Arrows はすべてファンクターだからです。
As I like to say it,
Haskell starts where the functors start.


If you wish to learn more about Haskell type classes, start with the excellent article 
Typeclassopedia (starts at page 17).

もしあなたが Haskell の型クラスについてもっと学びたいのであれば、
すばらしい article である Typeclassopedia (starts at page 17) から始めましょう。


Functors in Prolog (Prolog におけるファンクター)

Finally, functors in Prolog. Functors in Prolog are the simplest of all. They refer to 
two things. The first is the atom at the start of the structure. Here is an example, 
given an expression,

最後は Prolog のファンクターです。Prolog でのファンクターはこれまで挙げてきた中で最も
単純なものです。Prolog でのファンクターは二つのことがらを参照しています。一つ目は
structure の先頭に位置するアトム (atom at the start of the structure) です。
例を挙げましょう。


?- likes(mary, pizza)

the functor is the first atom - likes.

という式が与えられたとき、ファンクターは最初のアトム、この例では likes です。


The second is built-in predicate called functor. It returns the arity and the functor 
of a structure. For example,

二番目が、functor と呼ばれる組み込みの述語 (predicate) です。
これは arity (引数の個数) と、ある strucuture のファンクターを返します。
例を挙げましょう


?- functor(likes(mary, pizza), Functor, Arity).
Functor = likes
Arity = 2


That's it for functors in Prolog.

これはPrologにおけるファンクターのためのものです。


Conclusion (結論)

This article demonstrated how a simple term like "functor" can refer to 
completely different things in various programming languages. Therefore when you hear 
a the term "functor", it's important to know the context it's being 
mentioned in.

本アーティクルでは、ファンクターのような単純な用語 (simple term) が様々なプログラミン
グ言語においていかに異なることがらに対して使われているかを示しました。したがって、あな
たがファンクターという用語を耳にしたときにはそれがどんなコンテキストで使われたのかとい
うことを知るのが重要なのです。

いろいろあるんだねい。

■_

2010年06月13日

■_

はやぶさ
ついったーのわたしのタイムラインもまあ大変でした(笑) 一緒になって騒ぎたいところでしたが Twitter からの Jun Mukai さんのバズ などでちょっと思うところがあったので自重。 ひとつだけ書くとしたら、 カール・セーガン博士やアイザック・アシモフが存命であってこのニュースを知ったとしたら どんなコメントをしたのだろうかと (がきんちょのことろにセーガン博士の(監修かな?)「COSMOS」というスペシャル番組を観て 大いに知的好奇心を刺激されたクラスターw ヴァンゲリスもこれで知った)。 Yomiuri On-Line (読売新聞) 星空を進む「はやぶさ」。天の川(左)の中にある南十字星の上で消えた=尾崎孝撮影 asahi.com(朝日新聞社):はやぶさ、ありがとう 砂漠から管制室からファン見守る - サイエンス YouTube - Hayabusa re-entry BBC - Spaceman: A perfect view of the asteroid capsule's Earth return He will burn up and be reborn - a "Phoenix" for Japan. (略) おめでとう、日本 泣かせるなよコメントで。

Amazon.co.jp: 97 Things Every Programmer Should Know: Collective Wisdom from the Experts: Kevlin Henney: 洋書
の日本人プログラマー編を作るとしたらどんな人が挙げられるだろうか とちょっと考えてみたり。 自分がどんな人たちを考えたかはナイショ(笑)

・トイデジカメ
家から歩いて十分弱のところにあるビレッジバンガードで 結構いろいろ扱っているのに気がつく。 割と種類あるんですね~。みねこあさんが買ったやつもありました。 んが、一万円以上するのも「トイ」デジカメと呼ぶのはなんとなく違和感が (メーカーとか型番忘れましたがあったんですよ)。

・80x24
開発環境:柴田 芳樹 (Yoshiki Shibata):So-netブログ XDE上での開発は、80桁x24行の端末とは比較にならないぐらい便利でした。 80桁なのはパンチカードの容量(というのか)から来ているらしいというのを 以前どこかで目にしたのですが、ではそのカードのスペックはどこから来たのかという。 あと24行(25行)になった理由も知りたかったり。

・参照の値渡し
「参照」という言葉を使わずに何かうまく説明できる言い回しがないだろうかとしんきんぐ。

■_ ちゃうねん

「正しい」発音を知らんのですが(^^;


ちゃうねん駆動開発 
1 仕様書無しさん [sage] 2010/05/28(金) 18:30:58 ID: Be:
    こうですか?
    ちゃうねん!
    じゃあこうですか?
    ちゃうねん!
    じゃあどうすればいいですか?
    とりあえず作ってみてや!
    こうですか?
    ちゃうねん!

    (´ω`)・・トホー 

2 仕様書無しさん [sage] 2010/05/28(金) 18:50:14 ID: Be:
    殺せ 

3 仕様書無しさん [sage] 2010/05/28(金) 21:37:16 ID: Be:
    【類語】 なんでやねん駆動開発 

4 仕様書無しさん [sage] 2010/05/29(土) 02:31:55 ID: Be:
    中年工藤開発かとオモタ。アッー 

5 仕様書無しさん [sage] 2010/05/30(日) 00:39:15 ID: Be:
    >1
    ワロタ

    当事者になったら違う意味で笑うしかなさげだが 

6 仕様書無しさん [] 2010/05/30(日) 09:47:39 ID: Be:
    >>1
    それ何て三菱伊丹?
    しかも金払わんと踏み倒すし。


    三菱の案件は二度と受けない。 

7 仕様書無しさん [] 2010/06/12(土) 13:20:20 ID: Be:
    上が客の欲しいもの理解してなくて、情報持って帰ってなくて
    確かにこういうものを作ってほしいといいましたが、
    私がほしかったのはこれではありません 

○| ̄|_

■_

ボツ

■_

いくつか反応があるようですけど


知ってそうで意外と知られていないperlの小技 10選 - ダウンロードたけし(寅年)の日記

意外と知られていないperlテクってのが、意外とあるもんですね。

最近身の回りでいくつか話題に上がったものがあったので、ちょっと書いてみます。

どれも最新のモダパ的なモノではないけども、知っておくと地味に便利かもしれないノウハウです。

(略)

ランダムシャッフル

続いてこれもソートねた。

配列をランダムにシャッフルします。

use Data::Dumper;

my @data = qw( 0 1 2 3 4 5 6 7 8 9 );

my @shuffle = sort { rand() <=> 0.5 } @data;

print Dumper \@shuffle;  #結果はランダムにシャッフルされている

え、これだけ?なんで?って思うかもしれませんが、よーく考えてみてください。

ふーむ。よく考えたもんだ!

これって、数学的にいうと「正しい」シャッフルになってないんじゃなかったっけ? (すべての要素が同じ確率で混ぜられない(交換されない))


Re: 知ってそうで意外と知られていないperlの小技 10選 - a geek born in Tomakomai

(略)

こういうトリビア的なのはなかなか面白いなあと思ったので便乗させて頂きました。

Re: ランダムシャッフル

    続いてこれもソートねた。

これは List::Util::shuffle の方がベターでしょう。

% perl
use List::Util;
print join ' ', List::Util::shuffle qw( 0 1 2 3 4 5 6 7 8 9 );
print "\n";
1 8 6 3 0 2 7 5 9 4

まあ一度は自分で組んでみて、微妙な落とし穴にはまるというのも以下略。

■_ LC_ALL

これ


LC_ALL環境変数とsortコマンド - sileの日記

自分の環境では、sortコマンドを実行する時にLC_ALL環境変数に'C'をセットするかしないかで、
処理終了までの時間が著しく変わる。

# 約40万行のデータ
> wc -l words 
392126 words

# 入っているのはUTF-8の日本語(IPA辞書を利用)
> head words
やぼったい
やぼったし
やぼったから
やぼったかろ
やぼったかっ


# 普通のソート
> time sort words > /dev/null
real	0m37.158s
user	0m37.098s
sys	0m0.056s

# LC_ALL=Cでのソート
> time LC_ALL=C sort words > /dev/null
real	0m0.293s
user	0m0.284s
sys	0m0.008s

ロケールを考慮してソートするかどうかの違いだと思うが(LC_ALL=Cの場合は、多分単純にバイ
ト列としてソートされる)、全然時間が違う。

処理時間以外に、デフォルトのロケールがUTF-8の環境で、euc-jpで作成されたファイルをソー
トしようとすると(無理やりUTF-8として解釈しようとするため?)変な順番になったりすることも
あるので、最近はLC_ALL=Cをつけてソートすることが多い。 あと、文字列=バイト列のプログラ
ミング言語との相性もLC_ALL=Cをつけたソートの方がいいかな

GNU grep のアレと似たような現象な気がするけど ひょっとして原因も一緒? まあ、locale 意識したソートはそれはそれでめんどっちいところがあるんですが。 などと @tnozaki さんの方をチラッと見たりして。

■_ 本日の巡回から

2010年06月12日

■_

・画集とか
コミックの単行本は大抵シュリンクされて中身がわからない (店員さんに断って~というのはとりあえずなしで)ようになってますが、 画集なんかはどうなんですかね。 確かに単価も高いし、駄目になったときの被害もでかいでしょうけど 買うほうにしても表紙だけで買うのって結構冒険ですよね。 サムネイル画像だけでも間単に確認できるようにしてもらえないかなあと思ったり。 や、最近とある画集を買おうか買うまいか悩んだんですが、 シュリンクされて中身がわからなかったので 財布の中身とを相談してギャンブルに出るのを止めたという話なんですが(笑)

■_ そこで D

Linus がまた。という話は昨日辺りから流れてたと思うんですが、 リナス vs C++ あるいは: 言語、コンテキストそしてコミュニケーション。 - karasuyamatenguの日記 と言いつつもC++はボロクソにけなしている 「C++の阿呆なnewキーワード、、」


Real World Technologies - Forums

Linus Torvalds (torvalds@linux-foundation.org) on 6/8/10 wrote:
---------------------------
>But C++? I really don't think the "good features" of it
>are very good at all. If you leave C behind, do it properly
>and get some real features that matter. GC, some
>concurrency support, dynamic code generation, whatever.

The D programming language has some features you may find interesting according to 
your requirements. (First of all, D source is very close to C, and D follows the C abi 
so it can interoperate directly with any C code.) I'll just talk about the language 
features, as opposed to library features.

1. concurrency support - transitive immutability of types, and transitive sharing of 
   types

2. functional support - closures, lambdas, function purity.

3. the combination of immutability, transitive constness, and function purity reduces 
   the amount of context required to understand snippets of code

4. the scope guard statements eliminate much of the need for goto statements, and help 
   in localizing changes. In other words, this reduces the context needed to understand 
   snippets.

5. separation of code into safe (where memory safety is guaranteed) and system code.

6. a module system that makes for much better isolation of abstractions

-Walter Bright
D programming language - http://www.digitalmars.com/d/2.0

P.S. I'm not expecting you to switch to D, but I am interested in your comments about 
strengths & weaknesses of D.

差出人の名前に注目。

■_

ボツ

■_ strcmp

strcmp の戻り値をどう扱おうかという話。


C言語なら俺に聞け(入門編)Part 65
941 デフォルトの名無しさん [sage] 2010/06/12(土) 10:06:31 ID: Be:
    if (! strcmp(...))

    というのをよく見るんだが、読みにくいのでやめて欲しい。
    if (strcmp(...) == 0) でいいじゃん、と思ってしまう。
    == で比較するのはコストがかかるのだろうか。
    だったらコンパイラが最適化(否定形に置き換え)してくれるのではないだろうか。

    どうなの? 

942 デフォルトの名無しさん [sage] 2010/06/12(土) 10:12:26 ID: Be:
    慣れろ 

943 デフォルトの名無しさん [sage] 2010/06/12(土) 10:13:15 ID: Be:
    最適化しなくても変わんね 

944 デフォルトの名無しさん [sage] 2010/06/12(土) 10:13:30 ID: Be:
    >>941
    私もstrcmp() == 0 と書くね。
    まぁ、! strcmp() は慣用句だから。
    ちなみに、まともなコンパイラなら同じコードになるように最適化する。 

945 デフォルトの名無しさん [sage] 2010/06/12(土) 10:13:36 ID: Be:
    では何故。 

946 デフォルトの名無しさん [sage] 2010/06/12(土) 10:14:41 ID: Be:
    読みにくくないから。
    ==0より簡単に書けるから。 

947 デフォルトの名無しさん [sage] 2010/06/12(土) 10:15:54 ID: Be:
    しかし違和感がある。
    慣用句だから、と言えばそれまでだが。。 

953 デフォルトの名無しさん [sage] 2010/06/12(土) 10:53:40 ID: Be:
    読めるけど使わないからどうでもいい。 

955 デフォルトの名無しさん [sage] 2010/06/12(土) 11:38:53 ID: Be:
    ()の中が0かどうか、0じゃなければすぐ後ろが真で次が偽、慣れたらこちらのほうが簡単。
    文も短くなるしね。 

959 デフォルトの名無しさん [] 2010/06/12(土) 13:25:57  ID: Be:
    >>950
    そう、C ではね
    C では strcmp() == 0 とも !strcmp() とも書くというだけ
    言語と喧嘩しても仕方ないって 

960 デフォルトの名無しさん [sage] 2010/06/12(土) 13:30:55 ID: Be:
    if (0 == strcmp(...)) と書くやつだっているし。 

963 デフォルトの名無しさん [sage] 2010/06/12(土) 14:29:58 ID: Be:
    >>960
    代入と比較を間違えないようにと左辺に定数とか
    もってくる奴がいるけど、正直きもすぎるw 

964 デフォルトの名無しさん [sage] 2010/06/12(土) 14:42:04 ID: Be:
    = で代入できてしまう言語仕様の方がきもい。 

966 デフォルトの名無しさん [sage] 2010/06/12(土) 15:10:31 ID: Be:
    >>941
    おれもブール値のばあいは
    if (b) ・・・
    if (!b) ・・・
    と書くけど
    strcmp()のリターン値はブールじゃないから==や!=で比較する。 

967 デフォルトの名無しさん [sage] 2010/06/12(土) 15:22:24 ID: Be:
    !strcmp って書くやつは英語ができないやつだと思ってる。 

968 デフォルトの名無しさん [sage] 2010/06/12(土) 16:15:05 ID: Be:
    英語圏のプログラマで!strcmp()って書くヤツは英語ができないのかw 

969 デフォルトの名無しさん [] 2010/06/12(土) 16:15:35 ID: Be:
    !strcmp じゃ意味ちゃうべ 

970 デフォルトの名無しさん [sage] 2010/06/12(土) 16:25:03 ID: Be:
    >>969
    常に false だな。 

983 デフォルトの名無しさん [sage] 2010/06/12(土) 18:43:09 ID: Be:
    メモリをダンプしながら検証してたけど、うまくいかないので質問させてください。

    文字列の一部を動的に確保したchar *hogeにコピーしようと思ってます。

    char*piyo="ABCDEFG";
    とやって、"BCDEF"をコピーする場合、

    ・hoge = (char*) malloc(5)ですか(6)ですか?
    ・strncpy(hoge, piyo+1, 5)とやったあと、*(hoge+5+1)=0は必要ですか? 

984 デフォルトの名無しさん [sage] 2010/06/12(土) 18:45:00 ID: Be:
    0で終端させたいのかさせたくないのかどっちかわからんと何とも言えない 

985 デフォルトの名無しさん [sage] 2010/06/12(土) 18:46:40 ID: Be:
    ↑は*(hoge+5)=0の間違いでした。たぶん。
    その後printf("%s\n", hoge)としたいので\0で終端させたいです。

986 デフォルトの名無しさん [sage] 2010/06/12(土) 18:54:32 ID: Be:
    hoge = (char *)malloc(6);
    strncpy(hoge, piyo+1, 5);
    *(hoge + 5) = '\0'; 

987 デフォルトの名無しさん [sage] 2010/06/12(土) 18:56:26 ID: Be:
    即レスthxです! 

988 デフォルトの名無しさん [] 2010/06/12(土) 18:59:52 ID: Be:
    せっかく n 系使っても、この使い方じゃセキュリティ対策にならないな 

992 デフォルトの名無しさん [sage] 2010/06/12(土) 19:48:43 ID: Be:
    >>983>>986
    sprintf()なら一発だぜ。
    sprintf(hoge, "%.5s", piyo + 1); 

999 デフォルトの名無しさん [sage] 2010/06/13(日) 00:58:18  ID: Be:
    >>992
    thxです。これでsprintf覚えました。
    切り出す文字列が固定幅かそれに準ずる時はかなり使えますね。 

1000 デフォルトの名無しさん [sage] 2010/06/13(日) 01:07:10 ID: Be:
    >>999
    固定じゃない場合は %.*s 

確かに strcmp の戻り値は 0/非0 じゃあないけど、自分は ! 使ってるような気がする。 strEQ とか定義している LL (のソースコード) とかもあったような記憶が。

sprintf も意外に使われないような。んで、一生懸命自分で strcpy やら strca tやらを組み合わせてたり (藤原さんの本にもそのネタがあったような)。

■_


関数型プログラミング言語Haskell Part12 
432 デフォルトの名無しさん [sage] 2010/06/09(水) 22:37:12 ID: Be:
    実行性能が必要だったり、複数人で開発したり、自分以外の人間が保守したり、
    有り物のライブラリを使って楽をしたかったり、長期間稼働する必要があったり、
    ハードウェアに近い処理を実装する場合だったり、リソースの限られた機械で
    動作させる必要があったり、誰かに使ってもらう為のライブラリを作る時や、
    コンパイラのバグはコンパイラベンダーに丸投げしたい場合なんかは Haskell は
    あんまり向いてないかもね。 

437 デフォルトの名無しさん [sage] 2010/06/10(木) 07:52:20 ID: Be:
    >>432
    抽象データ型とかをつかってインターフェースをしっかりと定義しておけば、
    C++ や Java と同程度に複数人で開発できる。

    したがって、自分以外の人間が保守することも普通にできる。

    汎用的に使える応用度の高いライブラリも多く公開されてるから、
    有り物のライブラリを使って楽をすることも問題ない。

    ハードウェアに近い処理を直接実装するのはたしかに向かんかも。
    ただ、ハードウェアに近い処理を抽象的に書く能力自体はあるし、むしろ向いてる。
    それを実際のハードウェアに対して実行できるものに変換できればいい。

    誰かに使ってもらう為のライブラリを作るのに
    Haskell が向かない理由が思いつかない、説明してくれ。

    残りは、Haskell の言語としての特徴が招く問題ではなく、
    全て純粋に現在のコンパイラの問題だ。 

439 デフォルトの名無しさん [sage] 2010/06/10(木) 09:06:39 ID: Be:
    >>437
    >C++ や Java と同程度に複数人で開発できる。
    >したがって、自分以外の人間が保守することも普通にできる。

    Haskell プログラマの人数が圧倒的に少ない
    共同開発者や保守要因の確保が困難(もしくは高コスト)

    >汎用的に使える応用度の高いライブラリも多く公開されてるから、
    >有り物のライブラリを使って楽をすることも問題ない。

    当然、C/C++/Java のライブラリの数に比べたら圧倒的に少ない

    >誰かに使ってもらう為のライブラリを作るのに
    >Haskell が向かない理由が思いつかない、説明してくれ。

    C でライブラリを作れば、殆どの言語から呼び出せる
    Haskell でライブラリを作っても Haskell でしか使えない

    >残りは、Haskell の言語としての特徴が招く問題ではなく、
    >全て純粋に現在のコンパイラの問題だ。

    現実的な視点では、コンパイラの問題も言語の問題。 

442 デフォルトの名無しさん [sage] 2010/06/10(木) 16:17:28 ID: Be:
    >>439
    Haskellプログラマの数が少ないというより、Haskellプログラマ自身を開発するコストがバカ高いと思われ 

482 デフォルトの名無しさん [sage] 2010/06/12(土) 10:09:42 ID: Be:
    >>442
    大学を思想的に侵略して関数型言語以外はクズという主義を学生に叩き込もうぜ 

483 デフォルトの名無しさん [sage] 2010/06/12(土) 10:27:19 ID: Be:
    その前に関数型言語の定義をめぐって内ゲバしないと 

484 デフォルトの名無しさん [sage] 2010/06/12(土) 12:21:48 ID: Be:
    Lispは関数型言語かどうかで死闘をくりひろげるわけですね 

485 デフォルトの名無しさん [sage] 2010/06/12(土) 12:24:41  ID: Be:
    世間一般ではともかく、今時大学で Lisp を関数型扱いしてたら相当の時代遅れだろう 

486 デフォルトの名無しさん [sage] 2010/06/12(土) 12:32:16 ID: Be:
    関数型言語の歴史を知っている人間ならLISPが関数型言語だというのは明らか 

487 デフォルトの名無しさん [sage] 2010/06/12(土) 13:42:09  ID: Be:
    マルチパラダイムとお呼び! 

488 デフォルトの名無しさん [sage] 2010/06/12(土) 14:03:07 ID: Be:
    yes, sir! 

489 デフォルトの名無しさん [sage] 2010/06/12(土) 16:11:17 ID: Be:
    lispって型にはまらない言語なんだから、
    枠にはめて考えること自体合わないんだと思うよ。
    今じゃマルチパラダイムになってるからね。

    型にハメる系統と対照的だといえるよ。 

大学を思想的に侵略 → 内ゲバという流れがw

■_ まだやっていたらしい

週明けには/.J あたりでも取り上げられるかな?


Groklaw - Stewart Rules: Novell Wins! CASE CLOSED! - Updated

Stewart Rules: Novell Wins! CASE CLOSED! - Updated

Thursday, June 10 2010 @ 04:14 PM EDT

Here you go, munchkins. Judge Ted Stewart has ruled for Novell and against SCO. 
Novell's claim for declaratory judgment is granted; SCO's claims for specific 
performance and breach of the implied covenant of good fair and fair dealings are 
denied. Also SCO's motion for judgment as a matter of law or for a new trial: denied. 
Novell is entitled to waive, at its sole discretion, claims against IBM, Sequent and 
other SVRX licensees.

CASE CLOSED!


(略)

Here's the Final Judgment wording:

    This matter came before the Court for trial on March 8, 2010, through March 26, 
    2010. Based on the Jury Verdict and the Court's Findings of Fact and Conclusions
    of Law, Final Judgment is entered as follows:

    1. Judgment is entered in favor of Novell and against SCO on SCO's claim for 
       slander of title pursuant to the Jury Verdict.

    2. Judgment is entered in favor of Novell and against SCO on SCO's claim for 
       specific performance pursuant to the Court's Findings of Fact and Conclusions
       of Law.

    3. Judgment is entered in favor of Novell and against SCO on Novell's claim for 
       declaratory relief pursuant to the Court's Findings of Fact and Conclusions of
       Law. Specifically, the Court declares:

        a. Under § 4.16(b) of the APA, Novell is entitled, at its sole discretion, to 
           direct SCO to waive its purported claims against IBM, Sequent and other
           SVRX licensees;

        b. Under § 4.16(b) of the APA, Novell is entitled to waive on SCO's behalf 
           SCO's purported claims against IBM, Sequent and other SVRX licensees,
           when SCO refuses to act as directed by Novell; and

        c. SCO is obligated to recognize Novell's waiver of SCO's purported claims 
           against IBM and Sequent.

    4. Judgment is entered in favor of Novell and against SCO on SCO's claim for 
       breach of the implied covenant of good faith and fair dealing pursuant to
       the Court's Findings of Fact and Conclusions of Law. The Clerk of the Court
       is directed to close this case forthwith.

    SO ORDERED.

    DATED June 10, 2010.

    BY THE COURT:

    ______[signature]__________________
    TED STEWART
    United States District Judge

Novell の完全勝利。ということらしいです。

■_ BOF


めもがき:2010年6月12日分
○[NetBSD] BoF

W-ZERO3ユーザ会 NetBSD BoF 2010参加申し込み受付中

私も NetBSD/Citrus goes POSIX.1-2008 and C1X という発表を予定しとります。

行こうかなあ。 んで、柱の陰からそっと(ry

■_ 本日の巡回から

2010年06月11日

■_

・エキスパート Python
いい本だとは思うんだけど気になるところがなくもなく。 論文でもないのに(翻訳のチェックをお願いしたことに対して) 「査読」を使うのはどうなのかということと、 BDFL、 Benevolent Dictator For Life - Wikipedia, the free encyclopedia に対して「慈悲深き終身独裁者」という訳を当てていること。 確かに、“Benevolent Dictator”だけとれば「慈悲深き(優しい)独裁者」 で問題ないと思うんですが、その後ろに “For Life”ってついていて これを「終身」としたときにおかしくなるんじゃないかと。 というのも、終身~というのを考えたときに、 「終身大統領」とか「終身刑」とか「終身名誉監督」のように役職などがくると思うのですよね。 でも「独裁者」は大統領のような役職(地位)を指すものではありません。 その語源にさかのぼって、Dictrator を「独裁官」とすれば そのままユリウス・カエサルが就いた「終身独裁官」になるのでバランスも悪くないとは 思うんですが、そうすると「終身」がつかなかったときのこれまでの訳語との 関係が…と。 どうするのがよかったんでしょうかねえ。 と本の内容そっちのけで悩んでいるのでした(笑) 独裁官 - Wikipedia

■_

回答長いの多い。


プログラミングへの危機感 | OKWaveプログラミングへの危機感

こんにちは。
私はC/C++/Javaでプログラミングをしています。
中学2年生でもあります。
実際にはコンソロールアプリや.NETを使用した、ごく簡単なプログラムをしかつくれない初心者見習いプログラマーです。(プログラマーと言ったら本物のプログラマーに失礼かもしれませんが)
プログラミングの概念は理解しています。
本題ですが、私はプログラミングへの将来に不安があります。
なぜかというと、今現在、私のように中学生でプログラミングをしている方は少ないと思いますが、ほとんどの家庭にPCがあり、これからプログラミングというものは小学生でもでき、義務教育として導入され(もう導入されてますがまだ中学校で習うプログラミングはPCは用いません)、レベルの高いものではなくなってしまうのではないかと思ってるんです。
つまり、プログラマーというのはそれほど高い存在ではなくなってしまうのではないかという危機感を抱いております。
行き過ぎかもしれませんが、就職でも必須になるような存在になるのではと...
私自身も1ヶ月間、本を読みプログラミングというものを理解できました。(実際はそれから何を作れるかが一番難しいのですが)
なぜ高い存在になると危機感を感じるかというと、私自身プライドが高いことや、将来に不安を感じることがあげられます。
みなさんはどうおもわれますでしょうか。
皆さんの意見をきき、これからプログラミングと、どう付き合っていくか考えたいと思っています。
僕はプログラマーに憧れています。
夢はプログラマーしか考え尽きません。
大学も工学系を考えています。
プログラミングは大好きなのですが、一般の社会人や、自分の他の中学生も私よりレベルの高いプログラムを作っているのを見て、今の状況に危機感を抱いておりまして...
コンピュータサイエンスの世界ではプロミング言語は手段であり、IT企業でもプログラマーの存在は重要ではないと言います。


純粋なプログラミングの仕事は、減る一方です。今でも、開発の多くが、インド、中国にオフシ
ョアされます。一昔前は、言葉の壁や品質の問題があったのですが、いまや、品質、コスト、日
本語対応含め、国内のコストの半分以下で完璧な開発を請け負う会社がいっぱいあります。した
がって、あと10年もしたとき、デザインやコンセプトの設計ができる人材のニーズはあっても、
プログラマという職業は、低価格競争のきびしいマーケットになっているとよそうされます。

コンピュータのニーズはますます広がるので、より広い意味のスキルをつけて、プログラマとは
別の道を目指されることをお勧めします。

文章の構成がちょっと分かりにくく、理解が間違っていたらごめんなさいなのですが、プログラ
ミングが出来る人は限られてる「高い存在」だとプライドが満たされる。プログラミングが出来
る人が沢山いる「高い存在」ではないとプライドが満たされないから危機感を感じる。という理
解でよろしいでしょうか?これを前提に話を進めます。
 
>本題ですが、私はプログラミングへの将来に不安があります。

 私もあなたのようにプログラミングが大好きな中高生でした。散々、中高でプログラミングに
のめり込み、中高のうちにあなたと同じような危惧を持ちまして、プログラミングとは全く関係
の無い大学に進みました。プログラミングは簡単なので本を沢山読めば大丈夫だと思ったからで
す。ですが、現実は二つの意味で違いました。
 大学ではプログラミングとはまったく関係の無い授業ですし、人によりますが私の大学生活は
大学で学ぶ事柄が多くてなかなか本を熟読する時間が取れませんでした。
 それでも、プログラミングの本を色々と読み進めるうちに、大学生が工学部4年間みっちり行
う事柄にはやはり自習では敵わないという感触を掴んだからでした。その理由は多くの情報系学
生が書いているプログラミング系ブログを見ると、やはり有名大学に所属している人の内容のほ
うがレベルが高い事。プログラミングに使う小手先テクニックのような話題よりは本質的な話題
を取り扱っている事。でした。本質的な話題についていくには前提の基礎学力というものが必要
でして、それを中高時代に蔑ろにしてはとてもついていけない事を知ったからです。

 よって>コンピュータサイエンスの世界ではプロミング言語は手段であり、IT企業でもプログラマーの存在は重要ではないと言います。
 というのは的を射ています。
 プログラミングなど小手先テクニックに過ぎません。例えるならば、日本人は日本語を読み書
きできるが、それを回りは誰もすごいとは思わないのと一緒です。通訳者はまわりから見ればす
ごいかもしれませんが、通訳者の仲間うちに入ったらそれほどすごいとは思いませんよね。みん
な出来るのですから・・・それと同じです。IT企業に入ればそんなの当たり前で「数が多い少
ない」で測る重要性で見れば圧倒的に多いのでそういう考え方になります。
 
 >これからプログラミングと、どう付き合っていくか考えたいと思っています。
 以上の内容からプログラミングはソフトを作るとかではなく、Google Code JamやTopCoderなどの時間が取られないコンテストくらいにしておき、基礎学力を重視せよ としておきます。特に英語です。翻訳者並にスラスラ理解できるようにしてください。目標はプログラミング系の洋書をネイティブ並にスラスラ読めて、内容も事細かに理解できるレベルです。英語から情報を迅速に取ってこれる事は一番の武器となります。
 ソフトを作るのは大学生になって時間が出来たときで良いのではないかと思います。
 
 
>つまり、プログラマーというのはそれほど高い存在ではなくなってしまうのではないかという危機感を抱いております。

 前述の通訳者の例のようにプログラマーの中で高い存在を目指せばよいのではないでしょうか?
私はプログラム以外の世界にも触れてきましたが、どちらも「高い存在」になるには血も滲む様
な努力が必要な事を実感しましたよ。
 昔は機械語という難解で、プログラミングするのにもディスプレイの前に座ってぶっ倒れるま
でプログラミングしないとソフトが作れないような状況があったのでプログラミングできるだけ
で「高い存在」というような概念が出来たのだと思います。

>なぜ高い存在になると危機感を感じるかというと、私自身プライドが高いことや、将来に不安を感じることがあげられます。


 前述の機械語の話のように今までプログラマーは特殊な技能だと思われていました。
 しかし、中学生という若いうちに特殊な技能を持っているという物珍しさで周りがスゴイと思
ってくれるだけで本質はまったく変わらないのです。ゴルフの遼くんだって最年少とか若手では
なくベテランだったらまた違った印象を受けたでしょう?プログラミングは小学4年生程度の能
力で可能だというような記事もどこかで見ましたし、プログラミングは本質的には難しくないの
だと思いますよ。私の中ではプログラミングが「高い存在」という概念は無く、ただの技術、技
法に過ぎません。

続く
>一般の社会人や、自分の他の中学生も私よりレベルの高いプログラムを作っているのを見て、今の状況に危機感を抱いておりまして..
 自分の他の中学生も同様です。今現在のプログラミングとはベンダーから提供された出来合い
のAPIを使い、小手先テクニックを使い、すごそうな画面の動きをさせて素人に凄い!カッコ
イイ、「高い存在」と思わせているだけです。(これで仕事になる事もあるのですが・・・)
 とかく中高生のうちは自己顕示欲が強いので「高い存在」的な幻想がありがちですが、今はそ
んな事はカッコワルくて(カッコイイ、カッコワルイとかどちらでもイイのですが・・・)大人
になった時の貯金とでも思って、基礎学力の向上を頑張ってください。目標は中学生以内にセン
ター試験の問題を全問回答できるレベルになるです。それも超えたら、いち早く大学基礎教養ま
での内容を勉強してください。要するに先どり学習です。
 それらの勉強に必要な参考書は調べればすぐに分かるはずです。
 こうすれば後ほど「高い存在」的な幻想が変わったときでも後の祭りにならないで済むと思い
ますし、基礎学力向上後に別の観点から考え直す事が出来ると思っています。様々な方向で応用
が利きますので危機感も感じなくて済むとは思いませんか?
 私も今になって色々と考えてなぜ、基礎学力を向上させなかったのか後悔しています。
 

私の思うことに関してですが、

 >プログラミングは大好きなのですが、
が真に本当なのであれば、「僕はプログラマーに憧れています。夢はプログラマーしか考え尽き
ません。大学も工学系を考えています。」を忠実に目指せば精神衛生上、問題は無いと思います
よ。

 ただ、プログラミングとは関係無く「高い存在」が無性に欲しいのであれば私には分かりませ
ん。あなたは社会の流行や慣習のような「高い存在」幻想に振り回されて雲を掴むような努力が
必要とされ、神経が参ってしまうかもしれないと感じています。私には高い存在という事を頭で
は理解できますが、心では理解できません。そのような事をプライドとして守ったとしても自分
の意思が通じず神経が参るだけだと思っているからです。
 向上心なら理解できますが、プログラミングの能力を向上させるとか。
 
 つまり、私に分からないのは「プライド」と「好きな事」を天秤にかけるのか、それとも両方
とるのかという事です。
 プライドを重視するならば日本で言う「高い存在」幻想のトップの医者や弁護士を目指せばよ
いでしょう。
 好きな事を重視するならばマイペースにプログラミングしていれば良いでしょう。
 両方とるならば、必死に基礎学力の向上に努めて、プログラマーの中でも頭角を現す事が出来
るように勤めればよいでしょう。
 私が勝手に3択に縮めるのは良くないとは思うので、いろんな方向に広げてください。


>行き過ぎかもしれませんが、就職でも必須になるような存在になるのではと...プログラミン
グはさておき、英語は必須にして欲しいと思う今日この頃・・・

P.S.他の回答者の回答を見て、プライド=収入 といった考え方では書いていなかった。でも、
今改めて考えてみるとこういった図式ってあるのかもしれないとも思った。

■_ 本日の巡回から

■_ 81(灰)になるまで

佐藤大輔 81になっても 
19 名無し三等兵 [sage] 2010/06/12(土) 00:39:52 ID:??? Be:
    オレはまだしねない 

20 名無し三等兵 [sage] 2010/06/12(土) 01:16:01 ID:??? Be:
    >19

    コチャックもゴダンもバーコフもザキも死んだんだぜ・・・・ 

21 名無し三等兵 [sage] 2010/06/12(土) 01:51:31 ID:??? Be:
    >>20
    それは「俺達は死なねえ」とか調子に乗ったからだよ
    キリコが余計なこと言うもんだから 

22 名無し三等兵 [sage] 2010/06/12(土) 02:00:20 ID:??? Be:
    何もかもが、未完の中に沈んだ。
    微笑みかけた皇国も、芽生えかけたA君も、デビルも。
    そして、あらゆる既刊も同じだ。
    全てが振り出しに戻った。
    儲は、死んだ魂を疲れた身体に包んで、ドラゴンエイジとアニメの地に向かった。
    次回、『HIGHSCHOOL OF THE DEAD』。
    儲は、誰も完結を見ない。 

23 名無し三等兵 [sage] 2010/06/12(土) 02:15:54 ID:??? Be:
    新作のための未完。
    文庫のための新書。
    歴史の果てから、連綿と続くこの愚かな行為。
    ある者は悩み、ある者は傷つき、ある者は自らに絶望する。
    だが、営みは絶えることなく続き、また誰かが呟く。
    「たまには、漫画原作の本を買うのも悪くない」
    次回、『思惑』。
    神も、ピリオドを打たない。 

■_ 15 years of PHP

あんまり面白くなかった○| ̄|_

15 years of PHP - The H Open Source: News and Features

8 June 2010, 17:15

15 years of PHP

Fifteen years ago today, on the 8th of June, 1995, Rasmus Lerdorf launched 
PHP with a post to the comp.infosystems.www.authoring.cgi Usenet news group. He 
announced version 1.0 of his "Personal Home Page Tools", software that was 
originally intended for managing job applications on a web site. As Lerdorf made the 
tools available as open source code (originally under the GPL, since version 4.0 under 
the PHP Licence) his PHP software, written in C, was bound to find a wide audience.

15年前の今日、1995年6月8日に Rasmus Lerdorf はUsenet のニューズグループ 
comp.infosystems.www.authoring.cgi にポストして PHP をローンチしました。彼は自分の 
"Personal Home Page Tools" という、元は web サイト上のジョブアプリケーション
を管理するのを目的としていたソフトウェアのバージョン1.0をアナウンスしたのです。
Lerdorf は C で書かれたそのツールを彼の PHP ソフトウェアのオープンソースコードとして入
手できるようにしていたので(最初は GPL の下で、Version 4.0 からは PHP ライセンスの下で)
広く知られることとなりました。


Current PHP software no longer has much in common with the original 1.0 release. 
"Serious" applications only became possible with PHP/FI (FI is for 
"Form Interpreter"), which was released as version 2.0 in November 1997. 
However, even then only seasoned hardcore developers used this scripting language that 
allowed the addition of dynamic content to otherwise static HTML pages.

現在の PHP ソフトウェアはもはや1.0リリースの頃とは比較にならないほど一般的なものとなり
ました。本格的 ("Serious") なアプリケーションはwhich was released as version 
2.0 in November 1997. 1997年11月にリリースされた version 2.0 のPHP/FI (FI is for 
"Form Interpreter"),によってのみ可能となりました。しかしこの、静的な HTML ペ
ージに動的コンテンツを付加できるスクリプティング言語は経験豊富な hardcore developer
のみに使われていました。


The big breakthrough of PHP came with the arrival of version 3.0, which was released 
on the 6th of June, 1998. With this version, PHP development became the task of not 
just one, but several developers. Zeev Suraski and Andi Gutmans, the founders of Zend 
Technologies, had rewritten the code base for this version, bringing it up-to-date and 
making it even faster.

PHP にとっての big breakthrough は1998年6月6日にリリースされた version 3.0 とともに訪
れました。このバージョンで、PHP の開発はただ一人によるタスクから複数人のデベロッパーに
よるものとなったのです。Zend Technologies の founders (創立者)である Zeev Suraski と
Andi Gutmans はこのバージョンのコードベースを書き直して up-to-date にし、高速化を行い
ました。


It would still be some time before modern concepts like object-oriented programming 
would be integrated into the language but when version 4.0 was released on the 22nd of 
May, 2000, PHP offered not only object-oriented programming, but also the Zend Engine, 
a combined interpreter and compiler which uses a two-step approach to interpret and 
compile the program code and then execute the resulting opcodes via a bytecode-like 
mechanism. This discernibly improved the performance of the language.

それでもこの言語は、オブジェクト指向プログラミングのようなモダンなコンセプトが言語に統
合される以前の時代にとどまっていましたが、2000年5月22日に version 4.0 がリリースされた
ときに PHP はオブジェクト指向プログラミングだけでなく、インタープリターとプログラムを
コンパイルしてからその結果のオペコードをバイトコード的な機構を通じて実行するという二段
階アプローチを採用したコンパイラーを結合した Zend Engine を offer しました。これは
discernibly に言語のパフォーマンスを向上させました。
#見てわかるほど?


PHP didn't just want to conquer the web, a CLI (command line interface) was integrated 
into the language with the 4.30 release in December 2002. This allowed PHP to be 
executed on the command line without bulky CGI overheads, parameters to be parsed with 
ease and many other advancements to be implemented. Developers who previously had to 
write additional shell scripts for such tasks as software deployment were now able to 
use PHP, which gave them easy access to already existing components.

PHPは単にweb を征服 (conquer) するのを望むだけでなく2002年12月リリースの 4.30 で CLI 
(command line inteface)が言語に統合されました。これは PHP が bulky な CGI のオーバーヘ
ッド抜きにコマンドラインで実行できるようにするもので、
parameters to be parsed with ease
and many other advancements to be implemented.
それまでソフトウェアのデプロイのための additional なシェルスクリプトを書かなければなら
なかったデベロッパーたちはそれに、既に存在しているコンポーネントに簡単にアクセスできる
PHP が使えるようになったのです。


The language's most important turning point was likely the release of PHP 5.0 in 2004. 
The new Zend Engine II was given an enhanced object model and many extensions as well 
as modern language constructs, such as namespaces, closures and Late Static Bindings 
and native PHP archives, were included in subsequent versions, particularly in version 
5.3.0, released in June 2009.

この言語のもっとも重要なターニングポイントは 2004年の PHP 5.0 のリリースであったでしょ
う。新しい Zend Engine IIは拡張されたオブジェクトモデルと、名前空間やクロージャー、遅
延静的バインディングといったモダンな言語の構造である数多くのエクステンションを PHP に
もたらしました。そして後続のバージョン、特に 2009年6月リリースの 5.3.0 で
native PHP archives が含まれるようになりました。

The development of PHP 6.0 has been on the agenda for the past two years. It is 
expected to offer full unicode support that allows even method names to be written in 
other languages such as Chinese. However, the developers have repeatedly encountered 
difficulties, which has caused various related functions to "remigrate" to 
version 5.3. What great features version 6 will offer and whether it will be the 
planned "unicode release" has been left open by the developers. (Björn 
Schotte)

The development of PHP 6.0 has been on the agenda for the past two years.
このバージョンではメソッド名を中国語のような言語で書くことすらできるようなUnicode の完
全なサポート (full Unicode support) の提供が予定されていました。しかしながら、開発者た
ちは繰り返しversion 5.3に対する  "remigrate" に関係したさまざまな要因による
困難に直面しました。バージョン 6がもたらすであろう great features や 「Unicodeリリース」
がどのように計画されるかの決定は開発者たちに残されています。
#なんかちがう
(Bjorn Schotte)


See also:

    * PHP creator joins payment service WePay, a report from The H.

Copyright © 2010 Heise Media UK Ltd. Privacy Policy Contact us


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

ホームへ


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

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