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

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

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

ホームへ

2010年06月10日

■_

この本
R.O.D オフィシャルアーカイブ
R.O.D オフィシャルアーカイブ
を探そうとしても、'.' は入力できない(ソフトウェアキーボード上にない)、 さらに ROD ではひっかけてくれないような書店の検索システム作ったやつは(ぴー)

アスキー新書の今月の新刊の、 日本人がコンピュータを作った! (アスキー新書 154) いいっすよ。 ってまあ 新装版 計算機屋かく戦えり から十人分抜き出した体裁なんですが。 詳しくは後で書く。かもしんまい。

■_ まだ続いていました

ペースはそれほどでもありませんが。


バグとテストと残業中 

10 仕様書無しさん [] 2010/04/23(金) 22:37:24 ID: Be:
    おJava女どれみ プログラマー猿 カウボーイ・デバッグ JAVAン
    人月を探して 超電磁ロボ コンパイラーVC++ パケットモンスター
    機動戦士GNUDAM エリア8KB 新言語Javaンゲリオン あらいぐまオラクル
    千と千尋のバグ隠し あずまんがI/O ゲットデバッカーズ デバッグNo.1
    Bugって仕様 人月姫 エスイー(SE)魔美 あしたの仕様ー 外注遣いに大切なこと
    ガンダムsed ガンダムOO(オブジェクト指向) ランダムSEED
    ガンパレード・デスマーチ ~新たなる行軍歌~ アルプスの少女High-C
    Cosmic DataBase COMMITさん☆ ARMs ハックしよう大魔王
    魁!プロパティ高校 超時空要塞マクロ 湾岸MID$RIGHT$
    ルパンSun製 グレートマシン語 逆襲のchar ウルトラマンZ80
    バグひな 戦え!超OS生命体TRONスフォーマー gccさくら
    キャプテンmalloc 金色のハッシュ! おねがいt_char typoしちゃうぞ
    フォートラーン戦記 Excelサーガ getcharロボ 焼きたて!!JAVAん
    データセンターあらし 忍者バグトリ君 ときめきメモリ枯渇 修羅のMON
    ゴルゴ1B(バイト) Rubyポップは笑わない ELFを狩るものたち 迷宮組込 

19 仕様書無しさん [sage] 2010/05/05(水) 22:49:35 ID: Be:
    世界の中心でI/O叫ぶ 

20 仕様書無しさん [sage] 2010/05/06(木) 22:21:15 ID: Be:
    Go!Go!Eniac 

21 仕様書無しさん [] 2010/05/07(金) 14:51:09 ID: Be:
    七人月の侍 

22 仕様書無しさん [sage] 2010/05/07(金) 15:02:00 ID: Be:
    隠しフラグの三悪人 

23 仕様書無しさん [sage] 2010/05/07(金) 20:36:40 ID: Be:
    >>10
    >ルパンSun製
    に笑わせてもらった。
    あと、迷宮組曲なつかしい。
    エロゲやフリーソフトの名前とかによくこういうのあるよな。 

24 仕様書無しさん [sage] 2010/05/07(金) 20:48:28 ID: Be:
    >>10のレスが結構いろんなところで人気っぽいぞw
    http://blog.livedoor.jp/deal_with0603/archives/51566893.html 

25 仕様書無しさん [sage] 2010/05/08(土) 06:51:49 ID: Be:
    ときめきメモリ枯渇で死んだ
    ときめかねぇー 

26 仕様書無しさん [sage] 2010/05/08(土) 18:57:46 ID: Be:
    線上(オンライン)にかける橋 

27 仕様書無しさん [sage] 2010/05/31(月) 12:03:04 ID: Be:
    >>10
    あずまんがI/O
    これはすごい 

28 仕様書無しさん [sage] 2010/06/04(金) 00:25:23 ID: Be:
    バグのあらし!
    バグ物語
    狂乱プロジェクト日記

    むずかしいな 

29 仕様書無しさん [sage] 2010/06/06(日) 21:01:19 ID: Be:
    狂乱デスマ日記 

30 仕様書無しさん [sage] 2010/06/07(月) 18:51:15 ID: Be:
    となりのモバゲさん
    迷い猫オーバークロック
    俺のバグがこんなにあるわけがない
    バグマン。 

31 仕様書無しさん [sage] 2010/06/08(火) 01:31:42 ID: Be:
    廃バグ連盟 

32 仕様書無しさん [sage] 2010/06/10(木) 22:39:58 ID: Be:
    そしてパクリがバレた... 


「俺のバグがこんなにあるわけがない」 がいいなあw

■_ 正規表現リテラルがないからねえ

正規表現についての質問です。 | OKWave

正規表現についての質問です。

現在、HTMLのimgタグを使って「/img/jpg/」ディレクトリにある画像ファイルを複数表示しています。

例)
<img src="/img/jpg/1111.jpg" >
<img src="/img/jpg/mm2222.jpg" >
<img src="/img/jpg/kkkkk3333.jpg" >

これをそれぞれ、以下のように置換したいと考えています。
例)
<a href="http://www.xxxxx.jp/1111.jpg"><img src="/img/jpg/1111.jpg" width="240px"></a>
<a href="http://www.xxxxx.jp/mm2222.jpg"><img src="/img/jpg/mm2222.jpg" width="240px"></a>
<a href="http://www.xxxxx.jp/kkkkk3333.jpg"><img src="/img/jpg/kkkkk3333.jpg" width="240px"></a>

imgタグをリンクタグで囲むのですが、リンク先URLには元々の画像ファイル名が使われています。また、imgタグには「width="240px"」が付加されています。

このような置換をPHP5で行うには、どのような正規表現を使用したらよろしいでしょうか。
宜しくお願い致します。



質問者が選んだベストアンサー

たとえばこう

<?
$html=<<<eof
<img src="/img/jpg/1111.jpg" >
<img src="/img/jpg/mm2222.jpg" >
<img src="/img/jpg/kkkkk3333.jpg" >
eof;
$pattern="/(<img .*src=\".*?)([^\/]*?\.jpg\")(.*?>)/";
$replacement="<a href=\"http://www.xxxxx.jp/$2>$1$2 width=\"240px\"></a>";
$html=preg_replace($pattern,$replacement,$html);
print htmlspecialchars($html);
?>

お礼

ばっちりできました!
助かりました。本当にありがとうございました。

正規表現が


"/(<img .*src=\".*?)([^\/]*?\.jpg\")(.*?>)/";

ってなってるけど、エスケープシーケンスが文字列として解釈されてから 正規表現ライブラリに渡されてそこでもう一回正規表現のエスケープシーケンスの 解釈がされるから、なにかを「正規表現として」エスケープしたいのなら '\' を二重にしないといけないはずなんだがなあ。 ってまさかPHPってその辺もよろしくやってくれちゃうとか?

まあその辺の謎は放置しておくと、 \.jpg の . はエスケープされずに(文字列解釈の時点で '\' が消えて) メタキャラクタとして解釈されるんじゃないかなあ。 ブラケットの中で '/' をエスケープしているのも気に入らないけど(笑) マニュアルにはデリミタは変更できるってあったはずだよなあ。

■_ 15周年

面白そうだから訳してみようかなあ(ってまだ途中のがいくつあるのやら)

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

8 June 2010, 17:15

15 years of PHP

PHP Logo 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.


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.

(略)

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)


そういや、6.0以降の話ってその後進展あったのかしらん?

■_ 本日の巡回から

2010年06月09日

■_

ちょっと小さめだけど凹むことがあって縮退運転ちゅー。

■_ Culojureユーザーはどんな人たちか

円グラフが~。 こういうところに貼り付けるようなのをお手軽に作るにはどうすればいいかしらん。


Results from the State of Clojure, Summer 2010 Survey - Chas Emerick - Muck and Brass
http://muckandbrass.com/web/display/~cemerick/2010/06/07/Results+from+the+State+of+Clojure,+Summer+2010+Survey
http://spreadsheets.google.com/ccc?key=0AqULylOQcEq1dDVXY0ZfWlNfdXl0TW43S3dJcTFvU1E&hl=en#gid=0

集計した生データも取れるようになってます。んで、 それをとってきてちょっとごにょごにょ。


What language did you use just prior to adopting Clojure -- or, if Clojure is not your 
primary language now, what is that primary language?

#Clojureよりも先に使うような言語、あるいはもしClojureが使えなかったら
#第一に使う言語

1	Visual Basic
1	TCL
1	Smalltalk
1	O'Caml
1	Jython
1	Haxe
1	D
2	JRuby
2	Delphi
2	Matlab
2	Objective C
3	Erlang
3	R
4	F#
4	Groovy
5	Haskell
5	Scheme
8	Javascript
8	Perl
9	Scala
10	PHP
11	C
18	Ada
23	C++
25	Common Lisp
33	C#
64	Python
83	Ruby
156	Java

回答なしとか無効な回答は除いてあります。 Ada が意外に上のほうにいるような気が(リストでは下ですが)。

んでもうひとつ。

If Clojure disappeared tomorrow, what language(s) might you use as a "replacement"?
#もし明日、Clojure に「幻滅」してしまったら「代わりに」使う言語は?


1	n/a
1	don't even joke about that. :)
1	An open-source Lisp implementation would probably be my first choice.

1	dylan
1	Visual Basic
1	StuartHalloways Cloedjure
1	Pascal
1	Nu (Lisp on ObjC)
1	Lush Lisp
1	Haxe
1	Ada
1	Assembler
2	J
2	AWK
2	TCL
2	Standard ML
2	Shell
3	Ioke
3	Forth
3	Io
3	Matlab
4	Mozart-Oz
5	PHP
6	D
6	ELisp
9	Perl
9	Prolog
11	Lua
12	Objective C
12	Smalltalk
12	C
13	Factor
16	R
18	C++
20	Jython
24	Go
26	O'Caml
28	C#
36	Groovy
50	F#
60	Javascript
62	JRuby
76	Erlang
80	Java
92	Ruby
96	Python
106	Scheme
142	Haskell
143	Common Lisp
171	Scala

こっちはだいぶ票が割れている印象がありますねえ。 Erlang が 8位ですか。F#も割りと上位。

■_ 今日のネタスレ


何でNULLって言うんですか? 
1 しんや [] 2010/06/09(水) 11:13:37 ID: Be:
    C言語を勉強しててNULLというのが出てきました。NULLがどういうものかは
    分かるのですが、何でNULLっていうのか分かりません。
    困ってるので誰か教えてください(><) 

4 デフォルトの名無しさん [] 2010/06/09(水) 14:15:10 ID: Be:
    ぬるぽ 

5 デフォルトの名無しさん [sage] 2010/06/09(水) 14:16:46 ID: Be:
    がっ 

6 デフォルトの名無しさん [sage] 2010/06/09(水) 14:36:05 ID: Be:
    英語で「無効な」とか、そんな意味だったと思う

    ポインタを「意味の無い値」にしておくと便利なことがあるんだよ
    NULLになったの理由は、プリプロセッサ指令でdefineしたトークンは全ての文字をキャピタルにするのが慣例だから
    別に俺様ヌルとして、nilとかnullとかNullとかNullPointerとかNILとかなんでも定義して構わない
    一応規格では、0または(void *)0をnull pointer constantと定義しているので、それに合わせておけば俺様定義で問題ない
    #ifndef NIL
    # define NIL ((void *)0)
    #endif /* NIL */
    こういうことね

    そのほか、ポインタを返すスタブとかでNULLの代わりとして、しばしば0を返すことがある

    といってみるテスト 

7 デフォルトの名無しさん [sage] 2010/06/09(水) 14:51:09 ID: Be:
    >>6
    NULLを返すのか0を返すのか判別する方法は? 

11 デフォルトの名無しさん [sage] 2010/06/09(水) 21:26:12 ID: Be:
    Natural
    Unified
    Linear
    Linkage

    の略だよ。データモデルの一種だね。 

12 デフォルトの名無しさん [sage] 2010/06/09(水) 21:32:39 ID: Be:
    NIL(nil)を使う奴とだけは、頼まれても付き合いたくないw 

13 デフォルトの名無しさん [sage] 2010/06/09(水) 22:34:30 ID: Be:
    ソースにそう書いてあるんだからしかた無い 

14 デフォルトの名無しさん [sage] 2010/06/09(水) 23:10:43 ID: Be:
    NatUraL ni Love shite
    の略だよ
    C言語を作った人はテクノポップアイドルユニットのファンだったんだね。 

11 はガンダム SEEDのノリじゃなあ(笑)

■_

■_

2010年06月08日

■_

・チューリング
昨日書こうと思ってたんですが眠気に負けてしまったので。 アラン・チューリング - Wikipedia 6/7 が命日だったのですね。 ACE (コンピュータ) - Wikipedia の開発に関わり続けていたらその後のコンピューターの発展もかなり違ったものになっただろう とはどこで見た文章だったかなあ。

この辺翻訳して出してくれないかしらん○| ̄|_
The Annotated Turing: A Guided Tour Through Alan Turing's Historic Paper on Computability and the Turing Machine The Man Who Knew Too Much: Alan Turing And the Invention of the Computer (Great Discoveries)

Turing というプログラミング言語がある(あった)のですが、 知っている人はどのくらいいるのやら。 さらに使ったことがあるというと…(わたしも使ったことはない)
Programming with Turing and Object Oriented Turing

なんか面白そうな本が。

Untitled on Turing, Shannon, Wiener and Von Neumann: How Four Mathematicians Launched a Revolution That Isn't over Yet
Untitled on Turing, Shannon, Wiener and Von Neumann: How Four Mathematicians Launched a Revolution That Isn't over Yet
Allen Lane 2011-01-06
売り上げランキング :


Amazonで詳しく見る
by G-Tools

■_ 本日の巡回から

  • Office 2010――Officeシリーズの最新バージョン。パッケージは4エディションを用意:オフィスマイカ「マンガで学ぶ OLアリサのデジタル用語解説」
  • ラムダ式を使用した事例/デザインパターン・ミニカタログ - @IT
  • 誠 Biz.ID:「大画面になるだけで使い勝手が大きく変わる」――iPadでLotus Notesを使ってみた (1/2)
  • どさにっき 通信の秘密の破りかた。
  • 汎用的な問題解決のサイクル - *ListFreak
  • リリカル☆Lisp開発日記 ≫ Blog Archive ≫ ##のわりとどうでもいい話
    もうCommon Lispの処理系に頼るのに嫌気がさして来たのでGaucheを使ってみました。
  • C言語入門 - 非実在黎明日記
    void * を理解しない者がCプログラマではないように、マクロを理解しない者をLispプログラマとは呼ばないからだ。 (というか、プログラマを標榜するなら On Lisp ぐらい理解できて当然なんだよ……、という話をしだすと長くなるのでまた今度)
  • InfoQ: Microsoftのソフトウェアトランザクショナルメモリに関する実験が終了
    去る1月、Microsoftの並列コンピューティングの研究者、Joe Duffy氏はトランザクショナルメモリの回想において、STMに幻滅した4つの理由に言及している。
  • DCIアーキテクチャによるWebアプリケーションの実装:ドメインレイヤ - Digital Romanticism - digitalsoulのブログ
  • 「Zeus/Zbot 2.0」の概要 - 世界のセキュリティ・ラボから:ITpro
  • 神尾寿のMobile+Views:快進撃はいつまで続く?――本格普及期に入ったiPhone(前編) (1/2) - ITmedia プロフェッショナル モバイル
     「『日本でiPhoneは売れない』と言ったメディアやアナリスト、業界関係者は、ぜひ謝罪してほしい」  ソフトバンクの代表取締役社長 孫正義氏が、少し冗談めかしながら皮肉る。ここ最近の同社の記者会見で、よく見かける光景だ。
  • [1]スペック以外で人を魅了するアップルの姿勢 - iPadショック:ITpro
    あるタッチパネル携帯電話のエンジニアは、「どう頑張ってもiPhoneのように滑らかな曲線を描かせることができない」と漏らしていた。
  • 「Word文書にしか見えない!」アイコンと拡張子を偽装したウイルス - ニュース:ITpro
    しかしながら、ファイル名にユニコード(Unicode)の制御文字「RLO(Right-to-Left Override)」を挿入することで、パソコンの画面上では、ファイル名の最後に「doc」の文字列を表示させている。
  • 2010年6月9日のセキュリティリリース予定 (月例) - 日本のセキュリティチーム - Site Home - TechNet Blogs
  • ASCII.jp:生みの親が語るNetWalkerの正体
  • カーデザイナー由良拓也氏とのコラボによる「ポメラ」限定モデル:ニュース
  • Hexenkessel - コンビニは、朝食でも、昼食でも、外食産業を抜いて、もっとも利用されているという別の調査結果を見たことが...
  • 電撃文庫:「俺と彼女が魔王と勇者で生徒会長」を絶版 他作品との類似表現認める - MANTANWEB(まんたんウェブ)
  • プログラミング・セキュリティ関係のスキルをあげたいです 2,3年くらい前から興味... - Yahoo!知恵袋
  • 今の日本の会社でイノベーションを起こせるのか?: プログラマの思索
  • 海外でも通用するエンジニアになる: 海外IT企業で働くのに必要なものって何?(2)
  • ■_ cooked mode の問題じゃなかろか

    Windows版のgzipについて | OKWave
    
    gzip「http://www.gzip.org/」 windows版で
    標準入力からの情報を圧縮しようとするとおかしくなります。
    
    以前にpostgresからのダンプ圧縮としてマニュアルに載っているコマンド(linux用)をWindows
    でも出来ないかと質問させて頂いたところ、
    
    gzipのWindows版を紹介して頂きました。
    
    
    <ダンプ圧縮コマンド>
    pg_dump dbname | gzip > filename.gz
    
    
    <試行1>
    Windows版のgzipをインストール後、試してみました。
    pg_dump.exe --host=localhost --username=postgres template1 | gzip.exe > C:\Temp\test_dump.gz
    しかし、C:\Temp\test_dump.gzを解凍できません。
    一旦、テキストで出した後、改めて圧縮すると解凍できます。
    pg_dump.exe --host=localhost --username=postgres template1 > C:\Temp\test_dump
    gzip.exe C:\Temp\test_dump
    
    
    <試行2>
    一旦、postgresの事は忘れて、適当なテキストファイルを用意し、標準入力から圧縮しました。
    
    type c:\temp\test.txt | gzip.exe > c:\temp\test.txt.gz
    
    結果は、やはり解凍できません。
    
    シンプルに圧縮してみました。
    gzip.exe c:\temp\test.txt
    
    c:\temp\test.txt.gzを解凍する事ができました。
    
    回答(1件中 1~1件目)
    
    ANo.1
    
    kmee
    
    標準出力へ出力する -c オプションと、標準入力から入力を表わす - を付けたらどうなりますか?
    type c:\temp\test.txt | gzip.exe -c - > c:\temp\test.txt.gz
    
    投稿日時 - 2010-06-08 08:54:06
    補足
    
    だめです。
    同じ事になります。
    
    gzip test.txt というシンプルな使いかた以外では全く成功しません。
    
    ちなみに成功した場合は正しく解凍できますが、圧縮に失敗した場合、
    test.txt.gz: not in gzip format
    となります。
    
    左から入れられないなら、windowsにわざわざgzipを入れる意味が無いですし、どうしたものか
    という感じです。
    

    標準入出力をバイナリモードにしてなくて、CRLF→LF変換が起きててデータがおかしくなった って話じゃないかなあ。

    ■_ How to learn another programming language

    コード読み重要。

    
    How to learn another programming language ≪ keyboardy
    
    もう一つ別の言語を学ぶには
    
    This last week I've been learning to C#, and it's had me thinking a lot about the
    process I go through when learning a new programming language. I realized I'm going
    through the same steps that I went through the last time I learned a new language
    (Python).
    
    先週わたしは C# を学びました。そしてそれにより新しいプログラミング言語を学ぶときにわた
    しが通ったプロセスについて考えさせられたのです。わたしは自分が最後に新しい言語 (Python)
    を学んだときにも同じステップを踏んでいたことに気がつきました。
    
    In the hopes that it might be useful to other programmers, here's what I do in a nutshell:
    
    ほかのプログラマーにとっても有用であることを期待してわたしがやったことを簡単にまとめます:
    
    1. Start coding immediately.
       即座にコーディングを始める
    
    As in, right now. I don't know about you, but I tend to get a mental block when I think
    something might be hard, and the temptation is to just procrastinate. Some people might
    call this laziness. I think a lot of programmers and would-be programmers are the same.
    
    そう、即座に。あなたのことをわたしは知りませんが、わたしには自分が難しいかもしれないと
    思う何かにぶつかったときに心理的なブロックを作ってしまい、それに取り掛かるのをできるだ
    け引き伸ばしたいという誘惑に駆られてしまう傾向があります。中にはこれを怠惰 (laziness) 
    と呼ぶ人もいるかもしれません。わたしは多くのプログラマーも、プログラマーになろうとして
    いる (would-be programmers) 人も同様であろうと思っています。
    
    But, if I force myself to bang out some code immediately - without worrying about how
    crappy it is, without even worrying about whether it works - my block usually fades
    away. I think, “Huh, this actually isn't so bad.”
    
    けれども自分で自分自身に即座にコーディングすることを強制すれば
    -
    without worrying about how crappy it is,
    without even worrying about whether it works
    -
    わたしのブロックは大抵消えてなくなってしまうのです。
    そしてこう思うのです “Huh, this actually isn't so bad.”
    (ああ、実際にはそれほど悪いものでもなかったなあ) と。
    
    
    2. Build a project.
       プロジェクトを立ち上げる
    
    Just screwing around with a language can teach a person a huge amount, but eventually
    I like to decide to build a specific thing, preferably a big complicated hard thing.
    IMO, the best way to learn how to things in a language is to say, “I'd like to do X
    in this language,” and then figure out how to do X. The harder X is, the more you'll
    learn about the language.
    
    Just screwing around with a language can teach a person a huge amount,
    but eventually I like to decide to build a specific thing,
    preferably a big complicated hard thing.
    わたしの意見ですが、ある言語でのやり方を学ぶ最善の方法とは“I'd like to do X in this 
    language,”(この言語で X をやりたい) と宣言してX を行う方法を明確にすることではないか
    と思うのです。
    
    The harder X is, the more you'll learn about the language.
    
    より難しい X では、その言語についてさらに学ぶことになるでしょう。
    
    
    For example, right now I'm writing an FTP client in C#. In order to do this, I've
    had to learn all kinds of things like how to put a window on the screen, how to do the
    Aero Glass effect, how to open a socket, how to do multithreading, etc. etc. etc.
    
    たとえば今わたしは C# で FTP クライアントを書こうとしています。FTP クライアントを書く
    ためには、スクリーン上のウィンドウにどのように出力するか、Aero Glass 効果をどのように
    行うか、ソケットのオープンの仕方、マルチスレッドの使い方といった諸々のことを学ばなけれ
    ばなりません。
    
    I've also picked up a lot of small details about C#, like how to write a good class
    constructor, how to convert between types, how to encrypt user passwords, etc.
    
    わたしはまた、C# についてのたくさんの small details を picked up しました。良いクラス
    コンストラクターの書き方、型同士の間の変換のやり方、ユーザーのパスワードの暗号化の方法、
    などなど。
    
    Another idea is to port a project from a language you already know to the new language.
    When I was learning Python, I took a website that I'd developed in PHP and just did a
    line-by-line port to Python.
    
    もう一つのアイデアは、あなたが既に知っている言語から新しい言語へプロジェクトを移植する
    というものです。わたしが Python を学んだときは、PHP で開発した web サイトを持ってきて
    単に line-by-line で Python に移植したのです。
    
    
    3. Read other people's code.
       ほかの人の書いたコードを読む
    
    Ok, confession. I only recently started doing this. I really wish I'd started 10
    years ago. There's no way anyone can overstate the value of reading code in addition
    to writing it. This is especially true if you read code written by people who are
    really, really good at the language.
    
    白状してしまうと、最近はここから始めてばかりいます。十年前に始めていたらよかったのにと
    本当に願っています。誰もが読んだコードの価値を overstate してコードを書く方法など存在
    しません。これはその言語を本当に使いこなしている人の書いたコードを読んだのであれば
    especially に true です。
    
    
    Finding code is surprisingly easy. Just go on SourceForge or Google Code or github and
    find a popular open source project in the language you're learning. Just read through
    the code. Spend however long it takes to figure out how the project is structured. If
    you see something you don't understand, Google it, try it out yourself.
    
    
    コードを見つけることは驚くほど簡単です。SourceForge か Google Code、github へ行ってあ
    なたが学んでいる言語を使っているポピュラーなオープンソースプロジェクトを探せばいいので
    す。そのコードを読み通しましょう。どれほど時間がかかっても、そのプロジェクトがどのよう
    に構成されているかを figure out しましょう。もし理解できない何かにぶつかったらぐぐって、
    自分自身で解決することを試みましょう。
    
    
    4. Read a good book on the language.
       その言語についての良い本を読む
    
    This is the last step because I don't think it's very important. I find that books
    usually teach me 2% of what I need to know about a language, while actual coding
    experience and reading other people's code teaches me the other 98%.
    
    これが最後のステップです。なぜならわたしはこれがそんなに重要だとは考えていないからです。
    本がわたしに教えてくれているのはある言語について知る必要のあることのせいぜい 2% くらい
    で、一方実際のコーディングの経験や他の人のコードが教えてくれたことが 98% であることに
    わたしは気づいたのです。
    
    
    Nonetheless, a book can teach you a deeper understanding of the concepts of the
    language. And “getting it” on a deep conceptual level is an invaluable thing and
    will help you write better code, help you put the language to best use.
    
    にも関わらず、一冊の本はその言語のコンセプトに対する  deeper understanding を教えてく
    れるかもしれません。そして deep conceptual leve で “getting it” (理解) することは
    invaluable thing (評価できないほど貴重なこと) であり、あなたがよりよいコードを書くのを
    助けたりその言語をよりよく使うようにするのを助けることでしょう。
    
    
    Disclaimer yada yada
    
    Of course, what works for me might not work for you. Also, I wrote this for people who
    already know at least one language?things might be different for non-programmers
    learning their first language.
    
    

    ■_ 勇者のごとく倒れよ

    佐藤大輔 80 [chaika]
    917 名無し三等兵 [sage] 2010/06/07(月) 10:21:50 ID:??? Be:
        佐藤大輔の既刊は全て持っていたのだが
        入院中の友人が、暇なのでなにか面白い本はないかというので
        征途全巻を貸したのだが戻ってこないところに行かれてしまった。
        新しく買い直すほかないな
    
    918 名無し三等兵 [sage] 2010/06/07(月) 11:38:29 ID:??? Be:
        >>917
        征途なら文庫本早いトコ仕入れとき。 
    
    919 名無し三等兵 [sage] 2010/06/07(月) 20:25:26 ID:??? Be:
        返して貰いに行けば良いのに。 
    
    920 名無し三等兵 [sage] 2010/06/07(月) 21:10:32 ID:??? Be:
        >>919
        おそらく >>917は、友人の棺に「征途」を納めて見送ったんだろう… 
    
    921 名無し三等兵 [sage] 2010/06/07(月) 21:41:56 ID:??? Be:
        きゅんときた 
    
    922 名無し三等兵 [sage] 2010/06/07(月) 22:06:26 ID:??? Be:
        >>917はこう言ったんですよ航海長。「さよなら」ってね。 
    
    923 名無し三等兵 [] 2010/06/07(月) 23:26:13 ID:A96roiUJ Be:
        >>922
        巧いぞ 
    
    924 名無し三等兵 [sage] 2010/06/07(月) 23:50:41 ID:??? Be:
        なんの台詞だっけ? 
    
    925 名無し三等兵 [sage] 2010/06/08(火) 00:23:54 ID:??? Be:
        >>922
        パナマ2で、病院船船団の護衛隊旗艦(バンドマン)が被雷直後に別れを告げた、最後の信号。 
    
    926 名無し三等兵 [sage] 2010/06/08(火) 00:26:06 ID:??? Be:
        その信号や「我靖国ヘ避退セリ」(だっけ?)は当時読んでて鳥肌立ったなぁ。 
    
    927 名無し三等兵 [sage] 2010/06/08(火) 00:28:06 ID:??? Be:
        >>926
        外伝1の特攻した駆逐艦か 
    
    928 名無し三等兵 [sage] 2010/06/08(火) 00:30:42 ID:??? Be:
        >>923
        パナマ侵攻の一巻で、被曝者輸送船団の護衛駆逐艦が被雷した際、最後に発した信号についての科白だね。 
    
    929 名無し三等兵 [sage] 2010/06/08(火) 00:35:56 ID:??? Be:
        「ソーリィ、ソーリィ、ソーリィ」もなかなか胸に来る 
    
    930 名無し三等兵 [sage] 2010/06/08(火) 13:13:36 ID:??? Be:
        ワレ残燃料著シク不足
        帰投ハ不可能
        ヨッテ貴隊ノ先陣ヲ勤メン 
    
    931 名無し三等兵 [sage] 2010/06/08(火) 18:06:11 ID:??? Be:
        >>930
        それは実際にあった話だし。 
    
    932 名無し三等兵 [sage] 2010/06/08(火) 18:14:58 ID:??? Be:
        靖国へ退避云々は泣いたなぁ 
    
    933 名無し三等兵 [sage] 2010/06/08(火) 21:20:05 ID:??? Be:
        ここの方々はどの作品のどの場面が好きですか? 
    
    934 名無し三等兵 [sage] 2010/06/08(火) 21:30:10 ID:??? Be:
        皇国の丸山中尉が飯を配るシーンかな。 
    
    935 名無し三等兵 [sage] 2010/06/08(火) 21:34:47 ID:??? Be:
        本文「〝汝ラ、彼ラヲ忘ルルコトナカレ〟」
        わずかな沈黙があり、やがて悲鳴のような信号手の応答があった。
    
        「サー、イエッサー!」 
    
    936 名無し三等兵 [sage] 2010/06/08(火) 21:41:43 ID:??? Be:
        >>933
        地球連邦の興亡で永井景明が良子にプロポーズするところ 
    
    937 名無し三等兵 [sage] 2010/06/08(火) 21:48:10 ID:??? Be:
        >>933
        征途一巻から
    
        信号所に返信。
        我、祖国と同胞ト同胞ノ再興ヲ信ズ。サラバ。 
    
    938 名無し三等兵 [sage] 2010/06/08(火) 21:49:12 ID:??? Be:
        遥かな星で屋代幸男が電車の中で自分について考える場面が今の自分の状況にそっくりで凄く最近好き 
    
    939 名無し三等兵 [sage] 2010/06/08(火) 22:08:56 ID:??? Be:
        死線の太平洋1巻
        「一瞬の永遠」
        読みながら敬礼をしそうになる。 
    
    940 名無し三等兵 [sage] 2010/06/08(火) 22:43:08 ID:??? Be:
        虚栄の掟での大内氏のプロとは何かって事は仕事しながら思い出す 
    
    941 名無し三等兵 [sage] 2010/06/08(火) 22:59:23 ID:??? Be:
        フッ毛羽淫は読んでないけど、結婚したら読んでもらうんだ。 
    
    942 名無し三等兵 [sage] 2010/06/08(火) 23:19:18 ID:??? Be:
        「我ハ来タリ
         ソシテ見タリ
         誓ッテ共ニ勝タン
         全軍突撃セヨ」
    
        後に歴史的名台詞のオマージュだと知るわけだが、発売されたばかりの「征途」1巻を
        手にとってこの電信の場面を見た時、こいつはどえらい作家が現れたと鳥肌が立った。
        あれからもう20年くらいになるのか。
    
        征途だと二巻でハインラインが「やまと」乗員と万歳する場面。
        三巻で鹿内が「向こう側」の反応弾開発状況の偽情報をブリーフィングする場面も好きだな。
        ご清聴ありがとうございました、で締めたが拍手は起きず沈黙が降りる場面とか、想像すると
        寒気がするわ。
    
        あと、今見てちょっと驚くのは征途1巻でシャトル・コロンビアの事故云々に触れる場面。
        偶然と思いたいが、何しろこの作家が書いてるだけに。 
    
    

    新作読みてえなあ。 できればパシスト(笑) 皇国の守護者は前にも書いたけど、9巻で終わりにしちゃってもいいと思う。 あの後続けてもスーパー指揮官新城直衛の活躍にしかならないだろうか。 んで、佐藤大輔の作品で好きな台詞ということこれかなあ。

    続報・新防衛大綱関連ニュース - 気になったことを調べるblog ~ソースは2ch~ - 楽天ブログ(Blog)
    
        「諸君、我らの夏は今日で終わった! しかし、秋と冬はまだ始まってもいない。堪え忍び、
          打ち勝たねばならない未来が諸君らの前に待っている。さあ<ヒンデンブルグ>が君達を
          助けてあげられる間に、撤退してくれ。未来に向かって脱出するのだ。幸運を祈る。さよ
          うなら。以上」
    
    
    佐藤大輔著「戦艦<ヒンデンブルグ>の最後」より
    
    

    「死線の太平洋」あたりを読み返したくなった。どの山に隠れてるかな(笑)

    偶然こんなのを見つけた。 Twitter / ju88p: そう、会社のために、勇者のごとく倒れる。それがプロジ ... これは元ネタを知らないで誤解する人も多そうだ。

    Twitter / ju88p: そう、会社のために、勇者のごとく倒れる。それがプロジ ...
    
        そう、会社のために、勇者のごとく倒れる。
        それがプロジェクトマネージャに可能な最後の
        忠誠の誓いなのだ。たとえその会社が、
        史上最悪の愚か者集団であったとしても。
    
    
    続報・新防衛大綱関連ニュース - 気になったことを調べるblog ~ソースは2ch~ - 楽天ブログ(Blog)
    
        そう、王者のため、勇者のごとく倒れる。それが軍人に可能な最後の忠誠の誓いなのだ。
        たとえその王者が史上最悪の愚か者であったとしても。
    
    佐藤大輔著「勇者のごとく倒れよ」より
    

    ■_ 才能と努力と

    なんか昨日あたりからTLに、生まれ持った才能がどうの 努力がどうのというのをちらほら見かけましたが、 この本読んでみるといいと思うよ! ってまあ鵜呑みにするのもまずいだろうけどね。 山形さんの訳者あとがきがサイコー。
    非才!―あなたの子どもを勝者にする成功の科学

    2010年06月07日

    ■_

    眠い。

    ■_

    ■_

    
    Differences Between C and C++ - Cprogramming.com
    
    Where C and C++ Differ
    (C と C++ で違うところ)
    
    C++ was based on C and retains a great deal of the functionality. C++ does not retain 
    complete source-level compatability with C. There are a few gotchas for C++ 
    programmers trying to write C code, and C programmers trying to compile with a C++ 
    compiler.
    
    C++ は C をベースとし、その functionality の great deal を得ました。C++ は C に対する
    ソースレベルでの完全な互換性を持っていません。C++ プログラマーが C コードを書こうとし
    たときの gotcha やC プログラマーが C++ コンパイラーでコンパイルを試みるときの gotcha が
    幾つかあります。
    
    
    Gotchas for a C programmer using C++
    (C++ を使う C プログラマーへの gochas)
    
    Implicit Assignment from void*
    void* からの暗黙の代入
    
    You cannot implicitly assign from a void* to any other type. For instance, the 
    following is perfectly valid in C (in fact, it's arguably the preferable way of doing 
    it in C)
    
    void* から別の型への implicitly な代入は許されません。
    たとえば以下のコードは C であれば完全に valid です
    (in fact, it's arguably the preferable way of doing it in C)。
    
    
    int *x = malloc(sizeof(int) * 10);
    
    but it won't compile in C++. (Try it yourself!)
    
    しかしこれは C++ ではコンパイルできません (自分で試してみてね!)。
    
    The explanation from Bjarne Stroustrup himself is that this isn't type safe. What this 
    means is that you can have a void* that points to anything at all, and if you then 
    assign the address stored in that void* to another pointer of a different type, there 
    isn't any warning at all about it.
    
    Bjarne Stroustrup 自身の説明によれば、これは型安全 (type safe) ではありません。
    What this means is
    that you can have a void* that points to anything at all,
    and if you then assign the address stored in that void*
    to another pointer of a different type,
    there isn't any warning at all about it.
    
    
    Consider the following:
    次の例で考えてみましょう:
    
    int an_int;
    void *void_pointer = &an_int;
    double *double_ptr = void_pointer;
    *double_ptr = 5;
    
    When you assign *double_ptr the value 5, it's writing 8 bytes of memory, but the 
    integer variable an_int is only 4 bytes. Forcing a cast from a void pointer makes the 
    programmer pay attention to these things.
    
    *double_ptr に 5 という値を代入すると 8バイトの大きさのメモリー領域に書き込みが行われ
    ますが、整数変数 an_int の大きさは 4バイトしかありません。void ポインターからのキャス
    トを強制することでプログラマーがこの種のことに注意を払うようにしているのです。
    
    
    Freeing arrays: new[] and delete[]
    配列の解放: new[] と delete[]
    
    In C, there's only one major memory allocation function: malloc. You use it to 
    allocate both single elements and arrays:
    
    C では major なメモリ割り当てを行う関数は malloc だけしかありません。
    一つの要素と配列のどちらでもこれを使って割り当てを行います:
    
    int *x = malloc( sizeof(int) );
    int *x_array = malloc( sizeof(int) * 10 );
    
    and you always release the memory in the same way:
    そして割り当てたメモリーの解放も両方で同じように行います:
    
    free( x );
    free( x_array );
    
    
    In C++, however, memory allocation for arrays is somewhat different than for single 
    objects; you use the new[] operator, and you must match calls to new[] with calls to 
    delete[] (rather than to delete).
    
    しかし C++ では、配列に対するメモリー割り当ては単一オブジェクト (single object) とは異
    なっていて、new[] 演算子を使用します。また、new[] の呼び出しに対応した delete[] の呼び
    出しをしなければなりません(deleteを使ってはいけません)。
    
    
    int *x = new int;
    int *x_array = new int[10];
    
    delete x;
    delete[] x;
    
    The short explanation is that when you have arrays of objects, delete[] will properly 
    call the destructor for each element of the array, whereas delete will not.
    
    簡単に説明すると、オブジェクトの配列があったとき delete[] はその配列の要素ごとに適切に
    デストラクターを呼び出しますが、delete はそうではありません。
    
    You must declare functions before use
    (関数は使う前に宣言しなければならない)
    
    Although most good C code will follow this convention, in C++ it is strictly enforced 
    that all functions must be declared before they are used. This code is valid C, but it 
    is not valid C++:
    
    ほとんどの良い C コードはこの convention に従っていますが、
    C++ では関数は使用する前に宣言されなければならないことが
    strictly に enforce されます
    
    以下のコードは valid な C ですが、vaild な C++ ではありません:
    
    #include <stdio.h>
    int main()
    {
        foo();
        return 0;
    }
    
    int foo()
    {
        printf( "Hello world" );
    }
    
    Gotcha for a C++ programmer using C
    C を使う C++ プログラマーのための gotcha。
    
    Structs and Enums
    
    You have to include the struct keyword before the name of the struct type to declare a 
    struct: In C++, you could do this
    
    ある構造体を宣言するには、その構造体の型名の前に struct キーワードを含めなければなりません:
    C++ では次のようにできます
    
    struct a_struct
    {
        int x;
    };
    
    a_struct struct_instance;
    
    and have a new instance of a_struct called struct_instance. In C, however, we have to 
    include the struct keyword when declaring struct_instance:
    
    これで struct_instance と呼ばれる a_struct のインスタンスが手に入ります。
    struct_instance の宣言を行うときに struct キーワードを含めなければなりません:
    
    struct a_struct struct_instance;
    
    In fact, a similar situation also holds for declaring enums: in C, you must include 
    the keyword enum; in C++, you don't have to. As a side note, most C programmers get 
    around this issue by using typedefs:
    
    In fact, a similar situation also holds for declaring enums:
    C では キーワード enumを含める必要がありますが C++ ではそうする必要はありません。
    As a side note,
    大部分の Cプログラマーはこの問題を typedef を使って回避しています:
    
    typedef struct struct_name
    {
        /* variables */
    } struct_name_t;
    
    Now you can declare a struct with
    
    これで次のように構造体を宣言できます
    
    struct_name_t struct_name_t_instance;
    
    But there is another gotcha for C++ programmers: you must still use the "struct 
    struct_name" syntax to declare a struct member that is a a pointer to the struct.
    
    しかしここには C++ プログラマーに対する別の gocha があります:
    構造体へのポインターであるメンバーを宣言するには
    今でも  "struct struct_name" 構文を使わなければならないのです。
    
    
    typedef struct struct_name
    {
        struct struct_name instance;
        struct_name_t instance2; /* invalid!  The typedef isn't defined yet */
    } struct_name_t;
    
    
    C++ has a much larger library
    (C++ は much larger なライブラリがある)
    
    C++ has a much larger library than C, and some things may be automatically linked in 
    by C++ when they are not with C. For instance, if you're used to using g++ for 
    math-heavy computations, then it may come as a shock that when you are using gcc to 
    compile C, you need to explicitly include the math library for things like sin or even 
    sqrt:
    
    C++ は Cと比較してずっと大きなライブラリを持っていて、
    C++ では自動的にリンクされるのに C ではそうでないものがあります。
    あなたが math-heavy computations のために g++を使っていたのなら
    then it may come as a shock that
    C でコンパイルするために gcc を使ったときには
    sin や sqrt などのために explicitly に数学ライブラリを include する必要があります:
    
    
    % g++ foo.cc
    
    or
    
    % gcc foo.c -lm
    
    
    No Boolean Type (bool型の欠如)
    
    
    C does not provide a native boolean type. You can simulate it using an enum, though:
    
    C は native の bool 型を提供していませんが、enum を使ってシミュレート可能です。
    
    
    typedef enum {FALSE, TRUE} bool;
    
    
    main Doesn't Provide return 0 Automatically
    
    In C++, you are free to leave off the statement 'return 0;' at the end of main; it 
    will be provided automatically:
    
    C++ では main の最後に 'return 0;' という文を置く義務はなく、
    自動的に提供されます:
    
    int main()
    {
        printf( "Hello, World" );
    }
    
    but in C, you must manually add it:
    
    int main()
    {
        printf( "Hello, World" );
        return 0;
    }
    
    
    
    -----
    Interested in advertising with us?
    Please read our privacy policy.
    Copyright © 1997-2006 Cprogramming.com. All rights reserved.
    
    

    ■_

    いろいろ意見が出ていますが

    What skills should a tech leader have? - Stack Overflow
    
    What skills should a tech leader have?
    技術リーダーが持っているべきスキルとは?
    
    Should they have a degree?
    
    A few things I can see, they:
    
        * should know the platform they are working on
        * should know to listen
        * should know how to drive problems
        * should know how to mediate between co-workers
        * many others....
    
    
    
        * Able to to do anything that a team member can do.
        * Able to solve any technical problem without help.
        * Acts as mediator between the team and management.
        * Approves and controls the development process (check-ins, testing, code 
          inspection, documentation)
        * Able to interview candidates (you may not have the final, official say on hiring 
          and firing, but you'll have the ear of the hiring manager and you'll be at least one 
          of the interviewers)
        * Able to design/structure software (architecture)
    
    
    
    The ability to communicate well. Everything else can be taught, learned, faked, begged, 
    borrowed, or stolen. Effective, meaningful communication is hard, and that's why it's 
    the missing link in loads of otherwise very strong teams.
    
    

    コミュニケーション力重要と。

    2010年06月06日

    ■_

    ・第二回
    GC 本読書会でした。 一回目は希望者が確か30人くらいで、 部屋のキャパが16人で出席者が 12人くらいだったと思うのですが、 今回は参加者5名でした。 ひとり「開催されるのを知らなかった(気がつかなかった)」というお方が いらっしゃいましたがさて。

    以下メモに適当に追記しながら。

    
    第3章 参照カウント → スキップ
    
    第4章 コピーGC
    1963年 ミンスキー (人工知能とかで有名な人)
    
    ヒープ領域を From 空間 と To 空間 に分割
    生きているオブジェクトをコピーする
     
     *r = copy(*r)
    # この表記ちょっとわかりづらい?
    # 疑似コードのお約束をチートシートにまとめといた方が良いかも?
    
    copy 関数は再帰的にオブジェクトをたどりながらコピーを実行。
    
       return obj.forwarding で関数から返す
    
    forwarding は特別なフィールドではない
    オブジェクトには最低二つのフィールドが必要
    ミューテーターが使わないところ
    
    new_obj関数
    HEAP_SZIE/2→空間のサイズ
    図7 図8 は繰り返し登場するので良く覚えておくように
    
    メリット
    スループットに優れている
    アロケーションが高速  (フリーリストを使っていないから)
    (マークスイープGCのような)フラグメンテーションが生じない
      → ただし部分的にはマークスイープGCでもコンパクションは可能
    キャッシュメモリとの相性がよい
       参照関係にあるオブジェクト同士がヒープ上で近い位置に配置されているので
          →高速アクセスが可能に!
           コンパクションのおかげで隣接配置!
    
    デメリット
    ヒープ領域の使用効率が悪い(半分しか使えない)
       → マークススイープGCと組み合わせて緩和できる
    保守的GCとの相性が悪い
       → 限定的には組み合わせ可能
    再帰呼び出しをしているので遅かったりスタックたくさん使ったり
      → CheneyによるコピーGC は反復的にコピーを行う手法
    
    4.4 CheneyによるコピーGC
    再帰的にではなく反復的にコピー
    
    copying(){
    }
    
    copy(obj) {
    } 
    
    COPIED タグ使わずに forwarding で判定
     どうやって?
        TO空間を指していればコピー済み!
    
     $freeが右へずれていくのがポイント
     幅優先探索 (前に解説したのは深さ優先)
        隠れキューがある
          →  scan と $free の間の領域がキューになっている!
    
    メリット
    再帰呼び出しに伴うオーバーヘッドなし
      スタック消費少ない
      探索用の余計なメモリ領域要らない
    
    デメリット
    参照関係にあるオブジェクトの配置される位置が離れてしまう
      →キャッシュのヒット率に影響するなど
    
    
    4.5近似的深さ優先探索法
    4.4 のデメリットに対処
      オブジェクトの配置の傾向
      キャッシュのヒット率低下
    
    前提
      変数の役割
    
    実行過程
    
    $local_scan[]  ページ数だけ要素がある?
    
    ページの先頭に配置された場合は$loal_scanを使って探索
     [0] 中断
     [1] 開始 ・・・
    再開
    
    
    4.6 複数空間コピー法
    コピーGCの最大の欠点→ ヒープ領域を半分しか使えない
    
    ヒープ領域をさらに細かく分ける (たとえば十等分)
    ヒープ領域を N等分し、そのうちの二つの領域に対してはコピーGC
    残りはマークスイープGCを使う
    
    mark_or_copy() 関数
    
    4.6.3
    copy() 関数でmark_or_copy() を呼び出す
    
    実行過程
    
    メリットデメリット
    ヒープ領域をより有効利用できる
    マークスイープ GC  コピー GC の「デメリットを両方とも」(少しずつ)背負う
    
    mutlit_space_copying()
    
    コピー GCを採用しているものってあるの? →古典的手法?
    あまりありがたみがないようなアルゴリズムなんじゃね?
    
    ====
    5 マークコンパクトGC
    マークスイープ GC とコピー GC を組み合わせたような手法
    
    マークフェーズとコンパクションフェーズ
    メリット → コピーGCと同じ。ただし領域の無駄遣いなし
    Knuth による Lisp2 のアルゴリズム
    
    オブジェクトヘッダに forwarding ポインタ
    
    コンパクションフェーズ
     三つのステップ
    1)forwading ポインタの設定
     なぜforwadingポインタがヘッダに必要なのか
    
    2) ポインタの更新
    adjust_ptr()
    
    3) オブジェクトの移動
    
    メリット
    領域を有効に利用
    
    デメリット
    コンパクションに計算コストがかかる
       Lisp2 のアルゴリズムではヒープ領域全体を「3回」スキャンする必要があった
         →スキャン 1回の三倍の手間(時間)がかかる
    
    5.4
    Two-Fingerアルゴリズム
    Robert A. Saunders
    スキャンを 2回に抑える
    オブジェクトの大きさを揃えなければならないという制約
    forwardingポインタ用の領域は不要  (フィールドを使用する)
    
    ステップ1 オブジェクトの移動
    $free live 2つのポインタ
    move_obj()
    OBJ_SIZE (サイズ固定)
    
    ステップ2 ポインタの更新
    adjust_ptr()
    
    $freeより右にあるのは 死んでいるオブジェクトか移動前のオブジェクト
      疑似コードでは
        *r = (*r).forwarding
      と
        if (*child >= $free)
    
    メリット
    forwardingポインタ用の領域不要
    スキャン2回でOK
    
    デメリット
    参照関係を考慮しないのでキャッシュのヒット率低下
    オブジェクトサイズが固定という制約がある
     →BiBOP法を使うと…?
    
    ドレッドミルGC
    
    5.5テーブルアルゴリズム
    1967年
    テーブルを用いてコンパクションを行う
    これも2パスでコンパクション可能
    ブレイクテーブル
       テーブルに格納する情報→チャンクの先頭アドレスとチャンクのサイズのペア
    
    ブレイクテーブルはどこに置くの?
    
    ステップ1 前半 オブジェクト群の移動
    
    move_obj()
    slide_objs_and_make_bt()
    (連続した)オブジェクト群を移動
    #なんとなく挿入ソートを思い出したり
    
    
    ステップ1後半 ブレイクテーブルの構築
    
    ブレイクテーブルの構築は2つの操作からなる
       1) オブジェクト群を移動
       2) ブレイクテーブルを移動
    
    「図で説明」
    「なかなか複雑な操作」
    ブレイクテーブルのエントリの順番に注目
    
    ステップ2 ポインタの更新
    adjust_ptr() ポインタの付け替え
    new_address()
    best_entry
    
    すべてのエントリを調べる必要がある
    
    古いアドレスを手がかりにブレイクテーブルを調べる
     →全探索? (テーブルのエントリがアドレスの昇順などの順番になってない)
    
    メリット
      コンパクションのための余分な領域不要
      オブジェクトの順序が保存される (Two-Fingerアルゴリズムとの比較で)
    
    デメリット
      ブレイクテーブルの維持に「結構」コストがかかる
      エントリが順番に並ばない→ソートするとその手間が
      IBM VM 「ブレークテーブル」
    
    5.6 ImmixGC
    2008年
    「高度で難解」→読み飛ばしてもいいよ
     Immix 混ぜる
    「ライン」で管理
    状況に応じてコンパクションを「混ぜる」
    
    でかいメモリブロックは MMTk に任せる。
    
    ブロック→ライン→
    空のラインが見つからなければGC
    
    3つのステップ
      1. Fromブロック候補の選定 (ヒープ領域の消費が激しいときだけ)
      2. 探索フェーズ
      3. スイープフェーズ
    
    ブロックのフィールド
    line
    makr_table
    status
    hole_cnt フラグメンテーションのひどさを表す
    
    ラインにオブジェクトを配置する
    
    マーク
    FREE
    MARKED
    ALLOCATED
    CONSERVATIVE
    
    FREE
    RECYCLABLE
    UNAVAIABLE
    
    コラム
      並列処理
      マルチスレッド
      CAS
    
    5.6.4
    サイズに応じてオブジェクトは三種類に分類される
    小型 ライン以下のサイズ
    中型 小型より大きく大型より小さい
    大型 8Kバイト以上→MMTkまかせ
    
    アロケーション
    
    Immixの途中で今回は中断。
    
    ===
    以下雑談的に
    
    コンパクションてありがたいの?
    フラグメンテーションがどのくらい起きるのか
    ラインをまたがったオブジェクトの配置って面倒(Immixアルゴリズムで)
    解説で「~を改良した」とあっても、実用でそれがどの程度の効果として現れるのがよくわからない。
    
    Java の 64bit integer って1命令で扱われない
    いまどきは64bit CPUも当たり前なのになんで
    90年代からの言語だし
    先を見越して決めるのも結構大変(当時の状況を考えれば)じゃない?
    
    Objective-C 2.0 のGCって?
    MacRuby では~
    
    実装編はどう進めようか
    一回目は出席しなくて二回目出るのって参加しづらい?
    
    

    ■_

    How do I convert an ANSI string directly to UTF-8? - The Old New Thing - Site Home - MSDN Blogs
    
    How do I convert an ANSI string directly to UTF-8?
    ANSI文字列をUTF-8に直接変換するにはどうすればよいですか?
    
    3 Jun 2010 7:00 AM
    
    A customer asked the following question:
    あるカスタマーが次のような質問をしてきました:
    
        Is there a way to convert an ANSI string directly to UTF-8 string? I have an ANSI 
        string which was converted from Unicode based of the current code page. I need to 
        convert this string to UTF-8.
    
        ANS I文字列を直接 UTF-8 文字列に変換する方法はあるでしょうか? 手元には Unicode から
        current のコードページに基づいて変換した ANSI文字列があります。この文字列を UTF-8
        に変換する必要があるのです。
    
        Currently I am converting the string from ANSI to Unicode (Multi­Byte­To­Wide­Char(CP_ACP))
        and then converting the Unicode to UTF-8 (Wide­Char­To­Multi­byte(CP_UTF8)). Is there
        a way to do the conversion without the redundant conversion back to Unicode?
    
        現状では、文字列を ANSI からUnicode へ Multi-Byte-To-Wide-Char(CP_ACP) を使って変換し、
        さらに Unicode から UTF-8 へ Wide-Char-To-Multi-byte(CP_UTF8) を使って変換しています。
        この手順を、Unicode を経由する余計な変換をせずに行う手段はありますか?
    
    There is no multibyte-to-multibyte conversion function built into Windows (as of this 
    writing). To convert from one 8-bit encoding to another, you have to use Unicode as an 
    intermediate step.
    
    すでに書いているとおり、Windows には multibyte-to-multibyte な変換を行う関数はありません。
    ある8ビットエンコーディングから別の8ビットエンコーディングへ変換するには中間ステップとし
    て Unicode を使わなければなりません。
    
    Fortunately, one of my colleagues chose not to answer the question but instead 
    responded to the question with another question:
    
    幸運なことに、わたしの同僚の一人が回答したのですが別の質問で返したのです。
    
        Is the data loss created by the initial conversion to ANSI really acceptable? Convert
        from the original Unicode string to UTF-8, and you avoid the potential mess
        introduced by the Unicode-to-ANSI conversion step. 
    
    Is the data loss created by the initial conversion to ANSI really acceptable?
    Convert from the original Unicode string to UTF-8,
    and you avoid the potential mess introduced by the Unicode-to-ANSI conversion step. 
    
    The customer was puzzled by this data loss remark:
    カスタマーはこのデータ損失の remark によって混乱しました
    
        I'm using the same code page when converting from Unicode to ANSI as I am from 
        converting from ANSI to Unicode. Will there still be a data loss? 
    
        わたしは Unicode から ANSIへ変換するときに、 ANSI から Unicode へ変換したときと同
        一のコードページを使っています。それでもデータの損失が発生するのでしょうか?
    
    None of the code pages which Windows supports as an ANSI code page can express the 
    full repertoire of Unicode characters. It's simple mathematics: Since one of the 
    requirements for being an ANSI code page is that no single character can be more than 
    2 bytes, there simply isn't enough expressive power to encode all of Unicode. Now, if 
    you're lucky, all of the characters you're encoding will exist in the ANSI code page, 
    and they will survive the round trip, but that's just if you're lucky.
    
    Unicode に含まれるキャラクターをすべて表現できる ANSIコードページは Windows がサポート
    しているものの中にはありません。これは簡単な算数です。ANSI コードページが要求している
    ことの一つが一文字が 2バイトを超えることはないということなので、単純に Unicode (の文字)
    のすべてをエンコードするために充分な表現能力がないのです。ここであなたが幸運ならエンコ
    ーディングしようとしているキャラクターすべてが ANSIコードページに存在しているでしょうし、
    そうであればラウンドトリップを生き延びるでしょう。けれどもそれは運が良ければと言う話に
    過ぎません。
    
    
    It's like converting an image from 32-bit color to 8-bit color via the halftone 
    palette. The palette is the "code page" for the conversion. Remembering to 
    use the same palette when converting back is an essential step, but the result of the 
    round trip will be a degraded image because you can't encode all 32-bit colors in a 
    single 256-color palette. If you're lucky, all the colors in the original image will 
    exist in your palette and the conversion will not result in loss of information, but 
    you shouldn't count on being lucky.
    
    これは 32ビットカラーのイメージをハーフトーンパレットを使った 8ビットカラーに変換する
    ようなもので、このパレットが変換のための“コードページ”に相当します。逆変換 
    (converting back) が essential step であったときに同一のパレットを使うとラウンドトリッ
    プの結果は劣化したイメージ (degraded image) となることを忘れないでください。なぜならあ
    なたは 256色パレットひとつで 32ビットのカラーすべてをエンコードすることはできないから
    です。あなたが幸運であれば、オリジナルのイメージで使われている色の全てがパレットに存在
    していて変換しても情報の損失が発生しないこともあるでしょう。しかしそんな幸運なことがあ
    ることをあてにすべきではありません。
    
    
    The customer went on to explain:
    
        Unfortunately, my code does not have access to the original Unicode string. It is a
        bridge between two interfaces, one that accepts an ANSI string, and another that 
        accepts a UTF-8 string. I would have to create a new Unicode interface, and modify
        all existing callers to switch to the new one. 
    
        残念ながら、わたしのコードはオリジナルの Unicode 文字列にアクセスしていません。
        これは二つのインターフェースの間のブリッジで、片方が ANSI 文字列を受け付け、
        もう片方が UTF-8 文字列を受け付けるのです。わたしは新しい Unicode インターフェ
        ースを作らなければならないのでしょうが、それには既存のすべての呼び出し元を修正
        して新しいインターフェースを使うように切り替えてやらなければなりません。
    
    
    If all the callers are generating Unicode strings and converting them to ANSI just to 
    call the original ANSI-based interface, then creating a new Unicode-based interface 
    might actually be a breath of fresh air. Keep the poorly-designed ANSI interface 
    around for backward compatibility, so that callers could switch to the Unicode-based 
    interface at their leisure.
    
    もしすべての callers が Unicode 文字列を生成するようになれば、
    オリジナルの ANSI ベースのインターフェースを呼び出すためには
    それをANSI へ変換するだけで済みます。
    そうしてから新しい Unicodeベースのインターフェースを作ることは
    might actually be a breath of fresh air。
    後方互換性 (backward compatibility)のために poorly-designed な ANSIインターフェース
    を残すことで、callers は Unicode ベースのインターフェースへ
    at their leisure で切り替えることができるかもしれません。
    
    Bonus chatter: Even the round trip from ANSI to Unicode and back to ANSI can be lossy, 
    depending on the flags you pass regarding use of precomposed characters, for example.
    
    

    ■_

    ボツ

    ■_

    ボツその2

    ■_ 需要あるのかなあ

    Ruby に ++

    
    Standards: Incremental Operator in JRuby
    diff --git a/src/org/jruby/lexer/yacc/RubyYaccLexer.java b/src/org/jruby/lexer/yacc/RubyYaccLexer.java
    index 422d4b9..d6173ab 100644
    --- a/src/org/jruby/lexer/yacc/RubyYaccLexer.java
    +++ b/src/org/jruby/lexer/yacc/RubyYaccLexer.java
    @@ -1751,6 +1751,10 @@ public class RubyYaccLexer {
    
         private int plus(boolean spaceSeen) throws IOException {
             int c = src.read();
    + if (c == '+') {
    + yaccValue = new Token("++@", getPosition());
    + return Tokens.tINCR;
    + }
             if (lex_state == LexState.EXPR_FNAME || lex_state == LexState.EXPR_DOT) {
                 lex_state = LexState.EXPR_ARG;
                 if (c == '@') {
    diff --git a/src/org/jruby/parser/DefaultRubyParser.y b/src/org/jruby/parser/DefaultRubyParser.y
    index 66a9fe3..663f46b 100644
    --- a/src/org/jruby/parser/DefaultRubyParser.y
    +++ b/src/org/jruby/parser/DefaultRubyParser.y
    @@ -162,6 +162,7 @@ public class DefaultRubyParser implements RubyParser {
     %type <Token> sym symbol operation operation2 operation3 cname fname op
     %type <Token> f_norm_arg dot_or_colon restarg_mark blkarg_mark
     %token <Token> tUPLUS /* unary+ */
    +%token <Token> tINCR /* ++ */
     %token <Token> tUMINUS /* unary- */
     %token <Token> tUMINUS_NUM /* unary- */
     %token <Token> tPOW /* ** */
    @@ -265,7 +266,7 @@ public class DefaultRubyParser implements RubyParser {
     %left tSTAR2 tDIVIDE tPERCENT
     %right tUMINUS_NUM tUMINUS
     %right tPOW
    -%right tBANG tTILDE tUPLUS
    +%right tBANG tTILDE tUPLUS tINCR
    
     %%
     program : {
    @@ -697,7 +698,7 @@ undef_list : fitem {
     // Token:op - inline operations [!null]
     op : tPIPE | tCARET | tAMPER2 | tCMP | tEQ | tEQQ | tMATCH | tGT
                   | tGEQ | tLT | tLEQ | tLSHFT | tRSHFT | tPLUS | tMINUS | tSTAR2
    - | tSTAR | tDIVIDE | tPERCENT | tPOW | tTILDE | tUPLUS | tUMINUS
    + | tSTAR | tDIVIDE | tPERCENT | tPOW | tTILDE | tUPLUS | tINCR | tUMINUS
                   | tAREF | tASET | tBACK_REF2
    
     // Keyword:reswords - reserved words [!null]
    @@ -1666,6 +1667,12 @@ variable : tIDENTIFIER | tIVAR | tGVAR | tCONSTANT | tCVAR
     var_ref : variable {
                        $ = support.gettable($1);
                    }
    + | tINCR variable {
    + $ = support.assignable($2, NilImplicitNode.NIL);
    + //$.setValueNode(support.getOperatorCallNode(support.gettable2((Node) $), "||", $));
    + ((AssignableNode) $).setValueNode(support.new_call(support.gettable2((AssignableNode) $), (new Token("succ", support.getPosition($2))), null, null));
    + //$->nd_value = NEW_CALL(gettable($->nd_vid), rb_intern("succ"), 0);
    + }
    
     // AssignableNode:var_lhs - Variable on left hand side of assignment [!null]
     var_lhs : variable {
    diff --git a/src/org/jruby/parser/Tokens.java b/src/org/jruby/parser/Tokens.java
    index 1ef6be8..7691243 100644
    --- a/src/org/jruby/parser/Tokens.java
    +++ b/src/org/jruby/parser/Tokens.java
    @@ -104,6 +104,7 @@ public interface Tokens {
         int tNTH_REF = DefaultRubyParser.tNTH_REF;
    
         int tUPLUS = DefaultRubyParser.tUPLUS;
    + int tINCR = DefaultRubyParser.tINCR;
         int tUMINUS = DefaultRubyParser.tUMINUS;
         int tUMINUS_NUM = DefaultRubyParser.tUMINUS_NUM;
         int tPOW = DefaultRubyParser.tPOW;
    
    view raw gistfile1.txt This Gist brought to you by GitHub.
    
    
    
    Standards: Incremental Operator in Rubinius
    diff --git a/lib/ext/melbourne/grammar.y b/lib/ext/melbourne/grammar.y
    index 0536bda..43c9570 100644
    --- a/lib/ext/melbourne/grammar.y
    +++ b/lib/ext/melbourne/grammar.y
    @@ -368,6 +368,7 @@ static NODE *extract_block_vars(rb_parse_state *parse_state, NODE* node, var_tab
     %type <id> cname fname op f_rest_arg
     %type <num> f_norm_arg f_arg
     %token tUPLUS /* unary+ */
    +%token tINCR /* ++var */
     %token tUMINUS /* unary- */
     %token tUBS /* unary\ */
     %token tPOW /* ** */
    @@ -1042,6 +1043,7 @@ op : '|' { $ = '|'; }
                     | tPOW { $ = tPOW; }
                     | '~' { $ = '~'; }
                     | tUPLUS { $ = tUPLUS; }
    + | tINCR { $ = tINCR; }
                     | tUMINUS { $ = tUMINUS; }
                     | tAREF { $ = tAREF; }
                     | tASET { $ = tASET; }
    @@ -2386,6 +2388,11 @@ var_ref : variable
                         {
                             $ = gettable($1);
                         }
    + | tINCR variable
    + {
    + $ = assignable($2, 0, vps);
    + $->nd_value = NEW_CALL(gettable($->nd_vid), rb_parser_sym("succ"), 0);
    + }
                     ;
    
     var_lhs : variable
    @@ -3959,6 +3966,9 @@ yylex(void *yylval_v, void *vstate)
    
           case '+':
             c = nextc();
    + if (c == '+') {
    + return tINCR;
    + }
             if (parse_state->lex_state == EXPR_FNAME || parse_state->lex_state == EXPR_DOT) {
                 parse_state->lex_state = EXPR_ARG;
                 if (c == '@') {
    @@ -5023,6 +5033,7 @@ static const struct {
         {'%', "%"},
         {tPOW, "**"},
         {tUPLUS, "+@"},
    + {tINCR, "++@"},
         {tUMINUS, "-@"},
         {tUPLUS, "+(unary)"},
         {tUMINUS, "-(unary)"},
    @@ -5411,6 +5422,7 @@ void_expr0(NODE *node, rb_parse_state *parse_state)
               case '%':
               case tPOW:
               case tUPLUS:
    + case tINCR:
               case tUMINUS:
               case '|':
               case '^':
    
    

    よく見たらどちらも ujm さんだった○| ̄|_ 気がついた時刻に差があったので見落としてしまった。

    とはいえこの演算子のニーズって高いのかなあ。やっぱし。

    ■_ 本日の巡回から

    2010年06月05日

    ■_

    ・わが青春の4004
    明倫館で発見したので保護。 復刊してほしいよねえこれも。

    ・買った
    大型書店三軒回ってやっと発見(笑) まあ最初から池袋のジュンク堂へ行けばすぐに見つけられたんでしょうけど、 あっちには用事がなかったので。 「わが青春の4004」は比較のためです(笑)

    んでざっと目を通したところでの感想(not 書評)。 ここを読んでいる人の大半にはおそらく必要のないものと思いますが、 この本の想定読者(って著者に聞いたわけじゃないからあれですが)層には お勧めできると思います。 ソースコードリーディングと聞いていくつか思い浮かぶものがありますが、 そのどれとも異なっていてボリュームもいいところでまとまっていると思います。
    デーモン君のソース探検―BSDのソースコードを探る冒険者たちのための手引き書 (BSD magazine Books) デーモン君の本はこれよりも薄いですが、デーモン君の方がちょっとハードルが高めかも?
    これは通勤時のお供にはちとヘビー。 Code Reading―オープンソースから学ぶソフトウェア開発技法
    とはいえこれよりももっとすごいのを通学時に持ち歩いていた人もいますから世界は広い。

    書籍案内:プログラマーのための ソースコードを読む技術|gihyo.jp … 技術評論社
    第1章 プログラムを読もう
    1.1 プログラムを読むということは……
    1.2 プログラムを読む理由
    
        * 1.2.1 知識/技術を学ぶため
        * 1.2.2 開発中のプログラムのレビュー
        * 1.2.3 既存のプログラムをメインテナンスするため
    
    1.3 “駆け出しプログラマー”に足りないもの
    
        * 1.3.1 失敗に取り組む力が乏しい
        * 1.3.2 写経とパッチワークと穴埋めの経験しかない
        * 1.3.3 アルゴリズム,イディオム,デザインパターンなどに対する理解不足
        * 1.3.4 プラットフォームに対する理解不足
        * 1.3.5 良質なソースコードを読み解いた経験が少ない
        * 1.3.6 プログラムの細部の振る舞いを追跡できない
    

    このあたりに書かれている本文を引用して紹介したいところなんですが、 打ち込むの面倒なので勘弁してください(笑)

    プログラミング言語やらUMLやらの「入門書」、「解説書」を読んで 「勉強しました」(します)という手合いがわたしのついったーのTLにいたりするんですが、 んなものは実際に「使えて」なんぼのものであって、 「畳の上の水練」にいくら時間をかけたってそれは何の意味もありません (ってブーメラン飛ばしてる気がするぞ)。

    第2章 読むために書く,書くために読む
    2.1 プログラミングは体で覚えるもの
    
        * 2.1.1 本を読んだだけではプログラミングができるようにはならない
        * 2.1.2 授業や研修を受けただけではプログラミングができるようにはならない
        * 2.1.3 実際に手を動かし,何が起きるかを体験してみる
        * 2.1.4 できないときの悔しさ,できたときの感動を味わう
    
      
    第5章 実際にソースコードを読んでみよう
    
        * 5.1 まずはウォーミングアップ
        * 5.2 printfを読み解く
        * 5.3 vfprintfを読み解く
    

    GNU の ソースコードを集めたCDを買って、 (やってることがわからなくて)泣きながらコードを読んでいた頃を思い出しました。 今は「実用」のソースコードがいくらでも手に入るからいいですよね (おっさんモード)。

    プログラマーのためのソースコードを読む技術

    このあとちょっと時間をかけて読んだら誰かにあげようと思います。 といっても読ませたい人がひっかかるのかどうか(^^;

    ■_ a Tribute to Alan Kay

    なんか本が出たらしく(pdfがダウンロードできるっぽい)。 InfoQの記事なので、ちょっとすれば翻訳されると思いますが。

    
    InfoQ: Book: Points of View - a Tribute to Alan Kay
    Book: Points of View - a Tribute to Alan Kay
    
    Posted by Abel Avram on Jun 04, 2010
    
    Edited by Ian Piumarta, a Senior Scientist for Viewpoints Research Institute, and 
    Kimberly Rose, co-founder of the Viewpoints Research Institute, the book “Points of 
    View - a Tribute to Alan Kay” (PDF) is a homage paid to Dr. Alan Kay for his great 
    contribution for the advance of computer science, celebrating his 70th birthday on May 
    17th.
    
    Dr. Alan Kay, best known for the phrase “The best way to predict the future is to 
    invent it”, is one of the computer science visionaries who has had a significant 
    influence on the evolution of software and hardware sciences over the last 40 years. 
    Inspired by Sketchpad and Simula, Dr. Kay invented dynamic OOP while working on ARPA 
    during late 60’s. Along with Ed Cheadle, Dr. Kay designed the FLEX Machine, an early 
    desktop computer with a GUI and object-oriented OS. He also designed Dynabook, an 
    early laptop computer for children.
    
    (略)
    
    The book “Points of View - a Tribute to Alan Kay” is a collection of previously 
    unpublished essays on Alan Kay written by friends and former or actual colleagues who 
    have known him personally, trying to depict interesting aspects of Dr. Kay’s 
    personality, character, vision, and life. Kimberly Rose wrote in her dedication:
    
        Alan, with this book, Ian and I present to you, on behalf of several of your dear 
        friends and colleagues, a tribute wherein we hope you will also learn something more 
        about what you have given to us, taught us, and been to us— all of us who participated 
        in this project. We believe this book also contains valuable lessons and historic 
        information that will be of interest and value outside our circle and hope we can 
        bring some of the remarkable influence you have had and lessons you have taught to a 
        much larger group of people.
    
    (略)
    
    The first edition of the book was depleted in hours, another being prepared for 
    printing by the end of July. Those interested in getting a copy should contact the 
    editors at info [at] vpri.org. A PDF version is available for download.
    

    日本語訳は…どうなんだろう。直接プログラミングに関係しない本は あまり積極的には翻訳されてないような気がするしなあ。 iPad とか Kindleとか持ってたらぽちってるのかね(笑)

    ■_ λ

    Java の明日はどっちだ!?

    これも InfoQなんで翻訳期待(笑)

    
    InfoQ: First Version of Java Lambda Syntax Sparks Debate
    
    A few days ago Maurizio Cimadamore from Oracle pushed the initial lambda 
    implementation in the OpenJDK Mercurial Repositories. This provided a first glimpse 
    into the new syntax and has created controversy in the community.
    
    The current prototype supports the following features:
    
        * function types syntax
        * function types subtyping
        * full support for lambda expression of type 1 (stateless) and type 2 (final state 
          capturing)
        * inference of thrown types/return type in a lambda
        * lambda conversion using rules specified in v0.1.5 draft
        * support references to 'this' (both explicit and implicit)
        * translation using method handles
    
    Here is a code snippet that declares a simple lambda expression which takes an integer 
    and returns it incremented by one:
    
        int i1 = #()(3).();
        assertTrue(3 == i1);
        Integer i2 = #()(3).();
        assertTrue(3 == i2);
        int i3 = #(int x)( x + 1 ).(3);
        assertTrue(4 == i3);
        int i4 = #(Number x)(x.intValue()).(new Float(3.0f));
        assertTrue(3 == i4);
        Object o = #()(3);
        assertTrue(o != null); 
    
    The prototype supports the syntax described in the strawman proposal and for a better 
    idea of what the syntax looks like, someone can look at the regression tests.
    
    With Java usually preferring long words instead of symbols there are many that feel 
    awkward with this syntax and feel that it does not follow the look-and-feel of the 
    language.
    
    (略)
    
    
    
    InfoQ: Lambdas in Java: An In-Depth Analysis
    
    Lambdas in Java: An In-Depth Analysis
    
    With the acquisition of Sun Microsystems out of the way, Oracle can get down to the 
    serious business of revitalising what many have come to see as a stagnant language. 
    High on many people's requirements is the ability to be able to pass functions around 
    that are independent of classes, so that functions can be used as arguments to other 
    function or method calls. Functional languages like Haskell and F# exist purely using 
    this paradigm, and functional programming goes back eight decades to the Lambda 
    Calculus, leading to the term Lambda being used in many languages to describe 
    anonymous functions.
    
    (略)
    
    Lambdas in Java
    
    Lambdas are related to a new feature in JSR292 called Method Handles, which allow a 
    direct reference to a method syntactically (rather than having to go through several 
    layers of reflection indirection). Apart from anything else, a VM-level concept of a 
    method handle will permit greater optimisations in in-lining of methods, which is the 
    single biggest win that a JIT performs.
    
    The proposed syntax for representing a lambda in Java is using the # character, 
    followed by arguments and then either an expression or a block. This hasn't changed 
    since the initial proposal, so it's fairly likely that it will continue through to the 
    final specification, though of course it may change. (It also follows project coin's 
    decision to use # to denote exotic method names, as previously covered.) For example, 
    the increment lambda above can be represented as either:
    
    inc = #(int x) (x+1); // single expression
    inc2 = #(int x) { return x+1; }; // block
    
    Lambdas will also have the ability to capture variables from the surrounding local 
    scope, so it will be possible to write an equivalent of the addition by doing:
    
    int y = ...;
    inc = #(int x) (x+y);
    
    This can be generalised to capturing variables from a function to generate a function 
    factory, like:
    
    public #int(int) incrementFactory(int y) {
      return #(int x) (x+y);
    }
    
    The type #int(int) is the type of the lambda itself, which means 'takes an int and 
    returns an int' in this case.
    
    To invoke a lambda, ideally we'd like to do:
    
    inc(3);
    
    Unfortunately, that doesn't quite work. The problem is that Java has different 
    namespaces for fields and methods (unlike C++, which shares a common namespace). So 
    whilst in C++ you can't have a field called foo and a method called foo(), in Java 
    that's perfectly possible:
    
    (略)
    
    Conclusion
    
    The lambda draft is progressing, although not in the originally proposed timeframe of 
    the JDK 7 release plan. With the recent addition of defender methods as well, it is 
    unlikely that a full implementation will be ready for this Summer. Whether JDK 7 will 
    ship without lambdas (or without a retro-fitted Collections API) or whether JDK 7 will 
    be delayed to accommodate the lambda extensions remains to be seen.
    
    3 comments
    
       3.  ugly call syntax
    
          Jun 4, 2010 5:54 PM by Francisco Gómez
    
          I really do not like the current proposal of using a period and parenthesis to 
          invoke a lambda
    
          Incrementer.inc.(3)
          #(int x) (x+1).(3)
    
    
          it would be nicer something like
    
          Incrementer.#inc(3)
          #(int x) (x+1)(3)
    
    
          or
    
          Incrementer.*inc(3)
          #(int x) (x+1)(3)
    

    まあ記号類はあらかた使ってるわけだからなかなか難しいんだろうけど # かあ。 呼び出しで int i3 = #(int x)( x + 1 ).(3); みたいに '.' が妙なところに入るのはむずがゆいなあ。

    ■_ 買った

    センゴク外伝 桶狭間戦記(3) (KCデラックス) ゼロ 72 THE MAN OF THE CREATION (ジャンプコミックスデラックス)
    うーむ。知らなかった。一応「美術史」とかゆーの大学で履修したはずなんだけど(^^; マサッチオ - Wikipedia

    ■_ 本日の巡回から

    ■_ 翻訳すすまねえ

    ○| ̄|_

    2010年06月04日

    ■_

    ・ぼのぼの25周年
    だそうで。 そんなになるのか~

    ■_ 本日の巡回から

    ■_ J

    J言語 [chaika]
    47 デフォルトの名無しさん [sage] 2010/06/05(土) 00:11:56 ID: Be:
        保守
        最近はちょっとずつ"learning J"の抄訳+αをやってる。 
    

    ほう。

    ■_ 色々

    予想してなかった本が出てルノー

    どれを先に買ってどれを後回しか、やめるか。

    ■_ レビュー

    ひとつ前のリストの本を追いかけている途中で見つけた。

    Amazon.co.jp: やさしいF#入門―関数型言語を始める: 日向 俊二: 本
    最も参考になったカスタマーレビュー
    
    レビュー対象商品: やさしいF#入門―関数型言語を始める (単行本)
    
    残念ながら「やさしすぎ」で買う意味がありません。
    
    以前、同じ著者の方が書かれた「やさしいScala入門」という本もここでレビューさせて頂きましたが、
    その本と同じく、関数型言語としての特長的な利用方法が全く書かれていません。
    したがって、既存言語プログラミングの経験者には買う意味がありませんし、
    逆に初心者には「情報量・実績・利用者の多いC#やVB.NETから入ったら?」となります。
    
    日本語のF#の本はまだ殆ど出版されていないので、本屋で見つけたときに一瞬期待したのですが、残念です。(当然買いませんでした。)
    
    もう少し、マーケティングというより、本を出版する意義を考えていただいたほうが良いと思います。 
    

    そしてこのレビューを書いた人はこれも

    Amazon.co.jp: やさしいScala入門―平明な例と演習問題で学ぶ: 日向 俊二: 本
    
    レビュー対象商品: やさしいScala入門―平明な例と演習問題で学ぶ (単行本)
    「やさしい」というところがアピールされていますが、
    やさしすぎで実際にこの本を必要とする人がいないように思われます。
    
    本当に初心者の人がプログラムを組むのであれば、インターネット・書籍等の情報が十分にあり、
    まわりに経験者がたくさんいるような言語から入った方が良いと思います。
    しかし、Scalaはまだまだマイナーな言語で情報も経験者も少なく、Scalaを最初の言語としては選ばないでしょう。
    (初心者はJavaなどから入るでしょう。)
    
    一方で、今Scalaを始めようとしている人は、Javaなど既存プログラムで限界を感じている人が多いのではないかと思われますが、
    この本で説明されている言語仕様範囲はあまりに浅く、Javaとの差が分からないくらいです。
    Traitという言葉が出てくるくらいで、クロージャーでさえ説明されていません。
    
    5年後にScalaが主流言語になっていたら、この本にも意味が出てくるかもしれませんが、
    現時点では「明らかに想定読者層を誤っている」としか言いようがありません。 
    

    ■_ 超…?

    
    イオタ、かっこいい!
    
    iotaとは、
    
        Within a constant declaration, the predeclared identifier iota represents successive
        untyped integer constants. It is reset to 0 whenever the reserved word const appears
        in the source and increments after each ConstSpec. It can be used to construct a set
        of related constants:
    
        コンスタント値の定義内で、Integer型としてiota型を使う事ができます。これは「Const」
        命令を区切りとして、ソース内に書かれた変数が0から順番の数値で初期化セットされるコンス
        タント値です。
    
    

    「declaration」 を「定義」にしちゃまずいだろうし、 「predeclared identifier」とか「successive untyped integer constants」 が訳からどっかいっちゃってるし、 「iota型」なんて原文のどこにも書かれてないし Const 「命令」も原文にないし 「can be used 」が説明しているものが変わっちゃってる。 よね?

    あれ、ずいぶんえらそうな書きようじゃないか? わし(^^;

    2010年06月03日

    ■_

    ・「まだ足りぬ学び学びてあの世まで」
    Amazon.co.jp: 仕事で成長したい5%の日本人へ (新潮新書): 今北 純一: 本 を読んだんですが、最後のほうに「江戸時代の川柳」とかで 紹介されていたのが印象に残りました。 でもぐぐってもそれっぽいのひっかからないんだよなあ。 この川柳?自体は引っかかるんだけど、江戸自体とかそういう情報がない。 まだ足りぬ 学び学びて あの世まで - Google 検索

    ■_ まるで

    めもがき:2010年6月1日分
    めもがき:2010年6月1日分
    
    ○[C][i18n] ワイド文字(列)リテラル
    
    ゆにこーどがあらわれた、ソースコードをUTF-8で保存して、実行時はUTF-8 localeのみで動作させるなら
    gcc(1) がアレなせいで動きますが、実際には移植性のないコードなんですよね。
    
    (略)
    
    以下のソースを -lintl つきでコンパイル。
    
        $ cat >foo.c
        /* このファイルは US-ASCII で保存 */
        #include <locale.h>
        #include <libintl.h>
        #include <stdlib.h>
        #include <wchar.h>
    
        #define DOMAINNAME      "foo"
        #define LOCALEDIR       "/usr/local/share/locale"
    
        int
        main(void)
        {
        	char *s;
        	wchar_t *ws;
        	size_t len;
    
        	setlocale(LC_CTYPE, "");
        	setlocale(LC_MESSAGES, "");
    
        	bindtextdomain(DOMAINNAME, LOCALEDIR);
    
        	s = dgettext(DOMAINNAME, "AIU\n");
        	len = mbstowcs(NULL, s, 0);
        	if (len == (size_t)-1)
        		abort();
        	++len;
        	ws = malloc(sizeof(*ws) * len);
        	if (ws == NULL)
        		abort();
        	mbstowcs(ws, s, len);
        	wprintf(ws);
    
        	return 0;
        }
        ^D
        $ gcc -lintl -o foo foo.c
    
    xgettext(1) でソースから文字列をぶっこ抜いてメッセージファイル(.po)の雛形を作成します。
    
        $ xgettext -d foo foo.c
    
    xgettext(1) はデフォルトでは {d, n, dn, dc, dcn}?gettext(3) の引数のみ探すので、もし
    
        #define _(msg)	dgettext(DOMAINNAME, msg)
    
    のようにマクロ組んだりした場合はメッセージファイルには出力されません。
    そんな場合は --extract-all を指定しましょう。
    
    メッセージファイルを編集します。
    
        # SOME DESCRIPTIVE TITLE.
        # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
        # This file is distributed under the same license as the PACKAGE package.
        # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
        #
        #, fuzzy
        msgid ""
        msgstr ""
        "Project-Id-Version: PACKAGE VERSION\n"
        "Report-Msgid-Bugs-To: \n"
        "POT-Creation-Date: 2010-05-31 17:00+0900\n"
        "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
        "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
        "Language-Team: LANGUAGE <LL@li.org>\n"
        "MIME-Version: 1.0\n"
        "Content-Type: text/plain; charset=EUC-JP\n"
        "Content-Transfer-Encoding: 8bit\n"
    
        #: foo.c:20
        msgid "AIU\n"
        msgstr "あいう\n"
    
    charset を変更するのと、msgid に対応する訳文を入力すればおk。
    
    メッセージカタログ(.mo)を作成します。
    
        $ msgfmt -o foo.mo foo.po
    
    メッセージカタログを bindtextdomain(3) の引数で指定したディレクトリに配備します。
    
        # install -d /usr/local/share/locale/ja_JP.eucJP/LC_MESSAGES
        # install -m 444 -o root -g wheel foo.mo /usr/local/share/locale/ja_JP.eucJP/LC_MESSAGES
    
    指定ディレクトリの下に ${locale 名}/LC_MESSAGES/ というサブディレクトリが必要です。
    
    んでこのバイナリを実行すると
    
        * LC_MESSAGESが有効な場合には国際化されたメッセージ
        * 無指定の場合はデフォルトメッセージ
    
    が表示されます。
    
        $ LANG=ja_JP.eucJP ./test
        あいう
        $ ./test
        AIU
    
    まぁワイド文字に変換する必要もあんまり無いので
    
        #include <locale.h>
        #include <libintl.h>
        #include <stdlib.h>
    
        #define DOMAINNAME      "foo"
        #define LOCALEDIR       "/usr/local/share/locale"
        #define _N(msg)          dgettext(DOMAINNAME,msg)
        int
        main(void)
        {
        	setlocale(LC_CTYPE, "");
        	setlocale(LC_MESSAGES, "");
    
        	bindtextdomain(DOMAINNAME, LOCALEDIR);
    
        	printf(_N("AIU\n"));
    
        	return 0;
        }
    
    とする方が普通ですが。
    文字列を全部 _T() に変えろ地獄 → _N() に変えろ地獄ですな:D
    
    

    まるで大昔の、GUIプログラミングで hello, world がどのウィンドウシステムで 短いの長いのやってるみたいですねってついったで話を振ったら、 GNU hello 以下略 と返されました。 確かにアレは(笑)

    ■_ Perl 6

    Journal of masak (6289)
    Tuesday June 01, 2010
    05:45 PM
    Yapsi 2010.06 Released!
    [ #40372 ]
    
    It is with a mien of amusement that I want to announce, on behalf of the whole Yapsi 
    development team, the June 2010 release of Yapsi, a Perl 6 compiler written in Perl 6.
    
    You can get it here.
    
    Yapsi is implemented in Perl 6. It thus requires a Perl 6 implementation to build and 
    run. We recommend the 'alpha' branch of Rakudo for this purpose.
    
    Yapsi releases are 'official and complete', shown here by a circular argument: clearly 
    an official thing like Yapsi must be complete, and Synopsis 1 states that anything 
    complete is official. QED. Yapsi passes 100% of its test suite.
    
    Instructions for getting Yapsi up and running:
    
       1. Make sure you have a built Rakudo alpha in your $PATH as 'alpha'.
       2. Download Yapsi from github.
       3. ...
       4. Profit!
    
    The third (optional) step consists of running 'make' in the Yapsi directory. This will 
    precompile Yapsi, making startup times much more bearable.
    
    The big news since last month is that Yapsi now has a logotype. It's a picture of a 
    Möbius band, to symbolize self-loopiness, recursion and twisted ideas.
    
    (略)
    
    

    a Perl 6 compiler written in Perl 6. なんというブートストラップ。という気が。 未完成(というかサブセット)の自分で自分を定義するってのは昔からある 手法ではありますが。まあなんとなく。

    ■_ それは

    後日書く。たぶん。 Lisp in Small Peices読んでる: なつたん Lexical bindingとclosureがわからない: なつたん Lexical bindingとclosureがわからない その2: なつたん guileじゃ上手く動かなかったです><

    
    2010-06-03 - 猫的怠惰Days
    (define a 100)
    (define (foo) (display a))
    (foo) => 100
    (define a 200) ; redefine
    (foo) => 200
    (define (bar__ a) (lambda () (display a)))
    (define bar (bar__ a))
    (bar) => 200
    (define a 300); redefine
    (bar) => 200
    (foo) => 300 
    
    

    Twitter / Kazuhiro Inaba: @natsutan はてなようせい「環境は変数を受け ... はてなようせいとまなぶ R5RS表示的意味論 を見て納得したのかな? >@natsutan 落ち着いて考えれば、二番目のやつがなんだかわかるはずだ!

    ■_ 本日の巡回から

    ■_ 基礎?

    mixi のC言語コミュで、 "C言語の基礎を固める本は?" なんてのがでてんだけど、 現在PHPを扱っているのですが、基礎固めのためにはC言語が必要と思い、Cについて初心者的に分かりやすく書いた本を探してます!よければ教えてください。 とか、「Cの基礎」ってなにを言いたいのだろうか? 文法とかいう話。なんかねえ。

    ■_ そいや

    「ブティック」(boutique) って、フランス語で「店」とかいう意味だったと思うんだけど、 なんで日本に入ってきたらある特定の分野のお店のことを指すようにしか 使われてないんだろうか。 サクセス国際結婚!プリンセスアリス♪の海外生活日記:ブティック ~Boutique~ - livedoor Blog(ブログ) ブティックって死語? THIRD FACTORY INFO/ウェブリブログ

    そーいや、「ブックブティック」という意味が良くわからない形容の 大型書店があったなあ(苦笑) (フランス語で「本」を表す単語は「livre」)

    2010年06月02日

    ■_

    ・買った
    My story ~まだ見ぬ明日へ~
    某CDショップでは J-PUNK なんて分類されてたから悩んだw

    ・ムダヅモ
    片道だから燃料半分でいいってのは違うような気がするけどまあいいや。

    ■_

    Refactor Pro versus Visual Assist X for C++ Development - Stack Overflow

    ■_ オープンソースむずい

    いやまあ主張は理解できる(つもり)なんですが。

    Allison Randal on how open source is more than code - Perlbuzz
    Allison Randal on how open source is more than code
    By Andy Lester on May 29, 2010 2:52 PM | No Comments
    
    Allison Randal has some insights from her Twitter stream today about how open source 
    is more than just a way to create and share code.
    
        Open source isn't just a licensing/business strategy, it's a better way of producing
        software and a better way of training developers. The driving principle of the academic
        model is to make students fail. The bell curve rules, if all students pass something is
        'wrong'. The driving principle of open source is to help each developer reach their own
        greatest potential. Good developers are good for the project.
    
    

    ■_ Ruby 2.0

    行く先々で訊かれる質問だったりして。

    例によって超訳だから頭っから信じちゃだめよ? (笑)

    EuRuKo 2010, Day 2
    Q/A session
    
    Q: Elaborate on Monkey Patching in Ruby 2.0
       Ruby 2.0 のモンキーパッチングで苦労した点は
    
    A: Replacing e.g. basic operators has huge side effects, so restrict monkey patches to 
       a restrictive scope/namespace so they don't affect other code. Also add method 
       combination/hook to make alias_method_chain obsolete
    
    
    Q: Ruby 2.0 - when?
       Ruby 2.0 はいつになりますか?
    
    A: Still Vaporware, no promises about release date
       まだ Vaporware で、いつリリースかを確約することはできない
    
    Q: alias_method_chain - what about method signatures?
    
    A: Ruby 2.0 will support keyword args, should mitigate problem
       Ruby 2.0 ではキーワード引数をサポートするつもりなので、その問題を軽減してくれるはず
    
    Q: Would you add static typing to ruby if you could start over?
       静的型付けを追加してもらえませんか? 
    
    A: Really hate to type data types. Haskell does great stuff, but don't want to do that
    
       #…えーと(^^; 
    
    
    Q: Other languages you encourage people to learn/look at?
       learn/look at することをお薦めする Ruby 以外の言語は?
    
    A: Languages that use other paradigms, so learn functional lang like Haskell, Clojure, 
       Erlang. Prolog is also very different and interesting to learn.
    
       別のパラダイムを使っている言語が良いのではないでしょうか。ですから、
       Haskell, Clojure, Erlang のような関数型言語がいいと思います。
    
    Q: Alternative implementation that you like the most or see most potential
    
    A: Rubinius has greatest potential, since it's mostly written in Ruby itself, inviting 
       experimentation and easy rewriting. Mixed feeling about other implementations. MacRuby 
       is great, has LLVM as backend, C Ruby have similar plan for backend, but MacRuby is 
       basically a fork that does dev faster. But diversity is a good thing, moves things 
       forward.
    
    
    
    Q: What new features would you like to borrow from other languages for 2.0?
       他の言語から2.0に取り込みたいような機能にはどんなものがありますか?
    
    
    A: Monkey Patching stuff inspired by CLOS. Many ideas to steal. Have to design in a 
       compatible way with existing Ruby system. Pattern matching, actors, STM, would be 
       possible.
    
       モンキーパッチングの stuff (性質?) は CLOS にインスパイアされたものです。
       拝借する多くのアイデアは、既存の Ruby システムに沿うように設計する必要があります。
       パターンマッチングやアクター、STM、といったあたりが取り込まれる可能性があります。
    
    
    Q: alias_method_chain - when you include stuff in a class, new methods are put in between
       superclass and the actual class. Extend doesn't work that way, so can't use super to
       call original method. Solution for 2.0?
    
    A: Have module stuff before stuff in the class, have something like prepend
    
    

    EuRuKo 2010, Day 2 EuRuKo 2010, Day 1

    ■_ フィボナッチ数列を求める尋常でない十のやり方

    まあごそっと削りまして

    
    Blog | 10 unnatural ways to calculate Fibonacci numbers - Encyclopedia of Programming Languages
    10 unnatural ways to calculate Fibonacci numbers
    
    Posted by Mariya Mykhailova on May 30, 2010
    
    The task of calculating first dozen of Fibonacci numbers has lost its practical value 
    ages ago. Nowadays it's used mostly for illustrating some basic programming techniques, 
    recursion and iteration among them. In this writeup I will use it to show several 
    programming languages, in which it acquires uncommon and sometimes definitely 
    unhealthy look.
    
    So, here goes my rating of ten most unnatural ways to calculate Fibonacci numbers of 
    the ones I used for Progopedia project. For a more accurate definition, let's demand 
    that the program outputs first 16 numbers, formatted as
    
    1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, ...
    
    (略)
    
    7. SQL
    
    SQL itself is not a programming language, and in most implementations it's accompanied 
    with procedural extension which makes the task trivial. Let's try to solve the task 
    without using procedural extensions, in "pure" SQL. Unfortunately, standard 
    definition of "pure" SQL has nothing that can be used as a loop. Thus the 
    solutions turn out to depend on concrete implementation and its features.
    
    7.1. Oracle SQL (since version 9i)
    
    The innermost query generates numbers indices (from 1 to 16) using level pseudo-column 
    and connect by construct. Next query calculates Fibonacci numbers themselves from 
    their indices using Binet's formula. Two outermost queries order the numbers by their 
    indices (ascending) and concatenate them in one string of required format.
    
    SELECT REPLACE(MAX(SYS_CONNECT_BY_PATH(fib||', ', '/')),'/','')||'...' 
       FROM ( SELECT n, fib, ROW_NUMBER() 
                OVER (ORDER BY n) r 
                FROM (select n, round((power((1+sqrt(5))*0.5, n)
                                      - power((1-sqrt(5))*0.5, n))/sqrt(5)) fib 
                        from (select level n
                                from dual
                             connect by level <= 16) t1) t2
     ) 
      START WITH r=1 
    CONNECT BY PRIOR r = r-1;
    
    7.2. Oracle SQL (since version 10g)
    
    A convenient but seldom used and thus little-known operator model allows implementing 
    a loop inside of an SQL query.
    
    select max(s) || ', ...'
      from
    (select s
       from dual
       model 
         return all rows
         dimension by ( 0 d ) 
         measures ( cast(' ' as varchar2(200)) s, 0 f)
         rules iterate (16)
         (  f[iteration_number] = decode(iteration_number, 
              0, 1, 1, 1, f[iteration_number-1] + f[iteration_number-2]), 
            s[iteration_number] = decode(iteration_number, 
              0, to_char(f[iteration_number]), 
              s[iteration_number-1] || ', ' || to_char(f[iteration_number]))
         )
    );
    
    7.3. MySQL
    
    The means of calculating query results in a loop is implemented more compactly than in 
    Oracle.
    
    select concat(group_concat(f separator ', '), ', ...')
    from (select @f := @i + @j as f, @i := @j, @j := @f
            from information_schema.tables, (select @i := 1, @j := 0) sel1
           limit 16) t
    
    7.4. Microsoft SQL Server (since version 2005)
    
    Here comes one more rather compact loop implementation, this time using a recursive query.
    
    with fibonacci(a, b) as
    (
     select 1, 1
      union all
     select b, a+b from fibonacci where b < 1000
    )
    SELECT cast(a as varchar)+', ' AS [text()]
      FROM fibonacci
       FOR XML PATH ('')
    
    

    方言ありすぎな気が>SQL

    ■_ If you have to learn just one programming language

    結論。

    
    If you have to learn just one programming language | Babu Srinivasan's blog
    
    Message Passing: It is quite difficult to get multi-threaded programs to work 
    correctly. Locking is a nightmare and it is easy to get it wrong, resulting in 
    deadlocks, starvation etc. Conservative use of locking leads to performance issues. 
    Message passing is an effective alternative. It has been used with great success in 
    Erlang.
    
    メッセージパッシング: マルチスレッドのプログラムを正しく動作させるのはとても難しい。ロ
    ックは悪夢 (nightmare) であり、デッドロック(deadlocks) やスタベーション (starvation, 
    飢餓) といった間違った結果に繋がりやすいものである。conservative なロックの使用はパフ
    ォーマンス問題に繋がる。メッセージパッシングは効果的な alternative (代替策) であり、
    Erlang では great success を伴って使われている。
    
    
    Ericsson uses Erlang to write massively parallel concurrent programs. Some of these 
    applications have been running non-stop on switches for several years. You can even 
    upgrade a live system (hot swapping). Erlang is easy to learn and fun to use. 
    Processes are very light-weight and you can send messages to processes. Until recently 
    speed (criteria #2) was a concern, but this has changed with the availability of HIPE 
    (High-Performance Erlang Project). String processing in Erlang is quite inefficient as 
    they are stored as a list of (32 bit) integers. While Erlang is quite suitable for 
    certain domains, I wouldn't call it a general purpose language. It never came out of 
    its niche until recently with the advent of multi-core processors and interest in 
    functional programming. Lack of 3rd party libraries is an issue. So, with regret, I 
    eliminate Erlang.
    
    Ericsson は Erlang を、massively parallel な並列プログラム (concurrent programs) を記
    述するために使っている。Erlang で記述されたアプリケーションの一部には、スイッチ上で何
    年もの間止まらずに動きつづけているものがある。あなたは稼動している最中のシステム (live 
    system) のアップグレードさえ行えるのだ(ホットスワッピング)。Erlang は学ぶに易しく使う
    に楽しいものである。プロセスは非常に軽量(light-weight)で、プロセス群に対してメッセージ
    を送出できる。つい最近までスピード (criteria #2) が懸案事項 (concern) であったが、これ
    は HIPE (High-Performance Erlang Project) の availability によって状況が変化した。文字
    列を (32ビット長の) 整数のリストとして格納している Erlangにおける文字列処理は非常に効
    率の悪いものである。Erlang は特定の領域には quite suitable であるけれども、わたしはこ
    の言語を general purpose language とはみなさない。Erlang はマルチコアのプロセッサーが
    出現して関数型言語に対する関心が高まってきたつい最近までそのニッチから出てくることはな
    かった。サードパーティのライブラリの欠如は問題 (issue) である。であるから、残念ではあ
    るが Erlang を除外する。
    
    
    Haskell and Clean have a lot in common and so I am combining them as Haskell/Clean to 
    get the top 4: Clojure,OCaml,Haskell/Clean and Scala. At this point, I have to 
    eliminate Clojure. Though it has a lot going for it, the Lisp syntax will still be an 
    issue for most people (#8, #10).
    
    Haskell と Clean は数多くの共通点を持っているので、これら二つを Haskell/Clean のように
    まとめてここまで残ったものをClojure、 OCaml、 Haskell/Clean、Scala の四つにする。この時
    点で、わたしは Clojure を除外しなければならない。Clojure は a lot going for it を持っ
    てはいるが、それでもその Lisp 構文は大部分の人たちにとっては問題であり続けているだろう
    (#8, #10)。
    
    
    Now we are left with 3: OCaml, Haskell/Clean and Scala. These 3 languages have several 
    things in common.
    
    この時点で、OCaml、Haskell/Clean、Scala の三つが残っている。
    これら三つの言語には幾つかの共通点がある。
    
        * All use static types
          すべて静的型を使っている
    
        * All use type inference, so that you get the benefit of static typing without having
          to specify types. Scala's type-inference is not as complete as Haskell ― types 
          for function arguments need to specified.
    
          全て型推論 (type inference) を使っているので、あなたは型指定 (specify types) 抜き
          で静的型付けの恩恵を得られる。Scala の型推論は Haskell のものほど完全なものではな
          く、関数の引数に対する型を指定する必要がある。
    
        * Provide high-level of abstraction (for e.g higher order functions) (Criteria #1)
    
          高度な抽象化を提供している (たとえば高階関数のためのもの)  (Criteria #1)
    
        * Fast: OCaml approaches C in speed, Haskell/Clean are not far behind. These can be
          compiled to architecture specific binaries. Haskell frequently wins the Great 
          Computer Language Shootout. Scala compiles to Java byte code and thus takes advantage 
          of the fast JIT compiler. (Criteria #2)
    
          高速である:
          OCaml はスピードの点で C に比肩する。Haskell/Clean も not far behind である。
          これらの言語はアーキテクチャ固有のバイナリへコンパイル可能である。Haskell は
          しばしば Great Computer Language Shootout で勝利を収めている。Scala は Java
          バイトコードへとコンパイルするので、当然高速な JIT コンパイラーによるアドバン
          テージを得る。(Criteria #2)
    
        * Succinct (Criteria #3)
    
          簡潔である (Criteria #3)
    
        * Scripting Support (Criteria #4)
    
          スクリプティングをサポートしている (Criteria #4)
    
        * They are functional languages. Haskell and Clean are pure functional languages. 
          Rich Hickey who designed Clojure says - and I agree - that “Mutable objects are the 
          new spaghetti code”.
    
          これらは関数型言語である。とくに Haskell と Clean は純粋関数型言語 (pure functional
          lanuguages) である。Clojure を設計した Rich Hickey はこう述べている “Mutable
          objects are the new spaghetti code”(可変オブジェクトは新たなスパゲッティコードであ
          る) と。これにはわたしも賛成する。
    
        * Because they are functional languages, it is much easier to take advantage of 
          multiple-cores. Multi-Core processors are here to stay and I can say that sooner or 
          later you will be programming in a language that provides support for functional 
          programming.
    
          これらは関数型言語なので、マルチコアのアドバンテージを享受するのがとても容易である。
          マルチコアプロセッサーは here to stay であり、あなたは遅かれ早かれ関数プログラミン
          グのサポートを提供している言語でプログラミングすることになるだろう。
    
    
        * They also satisfy criteria #9, #11,#12. Regarding #12, Haskell has something called
          QuickCheck. Scala has ScalaCheck which started out as a port of QuickCheck. They
          automate unit testing and test case generation.
    
          これらの言語は criteria #9, #11,#12 を満足している。#12 に関して、Haskell は
          QuickCheck と呼ばれるものをもっている。Scala には QuickCheck の移植から開始された
          ScalaCheck がある。これらはユニットテストとテストケースの生成を自動化する。
    
    
    My favorite is Haskell as its syntax is absolutely beautiful (personal opinion) - No 
    unnecessary symbols, punctuation or words. It comes close to writing math that can be 
    compiled into an efficient binary.
    
    わたしが好きなのは、構文が (わたし個人の意見だが) absolutely beautiful である Haskell 
    だ。これには不必要なシンボルや記号、ワードがない。これは効率の良いバイナリへコンパイル
    できる math を記述するのに comes close である。
    
    
    
    Regarding OCaml, while it has a rare combination of providing a very high-level of 
    abstraction and at the same time almost matching C++ in speed, I find its syntax ugly - 
    this is personal opinion. We are all used to + as a symbol for adding, - for 
    subtraction etc; and it is natural to write 5+10 or 5.5+12.5. However, it doesn't work 
    like that in OCaml. This was a deal-breaker for me and I couldn't go past that and 
    learn about what the language had to offer. To find the average of 2 numbers you have 
    to write “(a +. b) /. 2.0;;”. To add integers you need to use ‘+', to add floats 
    you need to use ‘+.'. Similarly for the other operators.
    
    OCaml に関しては、これが非常に高水準の抽象化と同時にスピードの点において C++ にほぼ匹
    敵するものを提供しているという稀なコンビネーションを持っている一方で、(これは私的な意
    見であるが) その構文が ugly であることを発見した。われわれは加算を表すシンボルとして + 
    を使っているし、減算などでもそれぞれシンボルを使っている。そして、5+10 だとか 5.5+12.5 
    と書くことはいたって自然なことである。しかしこれは OCaml ではうまくいかないのである。
    これはわたしにとっては deal-breaker であり、
    I couldn't go past that and learn about what the language had to offer.
    二つの数値の平均を求めるには“(a +. b) /. 2.0;;”のように書かなければならない。
    整数を加算するには‘+' を使う必要があり、浮動小数点数を加算するには‘+.' を使
    わなければならないのだ。この他の演算子に対しても同様である。
    
    
    Scala:The language is the brainchild of Martin Odersky, ACM Fellow. He co-designed 
    Java Generics. He implemented Java Generics. His Java+Generics compiler was adopted by 
    Sun as the official Java compiler more than 10 years ago - with the generics switched 
    off, until they became part of the language in Java 5. If you have been programming in 
    Java, you have been using Martin's Java compiler. It is one of the few languages that 
    supports both threads and message based concurrency. Message based concurrency is 
    based on the Actors model (like Erlang) and it is a Scala library and not part of the 
    core language. It supports both object-oriented programming and functional programming 
    and attempts to unify them.
    
    Scala:
    この言語は ACM フェローである Martin Odersky の brainchild である。彼は Java のジェネ
    リクスの co-design とその実装を行った。彼の Java+Generics コンパイラーは十年以上前にオ
    フィシャルな Java コンパイラーとしてSun によって採用されたが、ジェネリクスはJava 5 で
    言語の一部となるまでの間無効にされていた。もしあなたが Java でプログラミングしたことが
    あるのなら、すでに Martin のJava コンパイラーを使ったことがあるはずだ。この言語は、ス
    レッドとメッセージベースの並列性の両方をサポートする数少ない言語のひとつである。メッセ
    ージベースの並列性は (Erlang と同様) アクターモデルに基づくもので、Scala のライブラリ
    であってコア言語の一部ではない。Scala ではオブジェクト指向プログラミングと関数プログラ
    ミングの両方をサポートし、それらを統合 (unifty) しようとしている。
    
    
    Functions are values and values are objects. Therefore functions are objects. Unlike 
    Java which has primitive types int, float etc, Scala is completely object oriented. 
    Numbers, characters, booleans, functions are just objects
    
    関数は値であり、かつ値はオブジェクトである。したがって関数はオブジェクトである。int や 
    float などのプリミティブ型 (primitive types) を持っている Java とは違い Scala は完全に
    オブジェクト指向であり、数値、文字、真偽値、関数は単なるオブジェクトである。
    
    
    A big deal is made of duck typing in languages such as Python and Ruby. In Scala you 
    have “Structural typing” which is Duck Typing done right. While not as powerful, you 
    get compile time checking and no run time overhead.
    
    A big deal is made of duck typing in languages such as Python and Ruby.
    Scala にはダックタイピングを正しく行うものである“Structural typing”がある。
    それはそれほど強力ではないものの、コンパイル時チェックを得て実行時のオーバーヘッドはない。
    
    
    Scala is a huge language with lots of features: traits, abstract types, higher order 
    functions, closures, native threads, concurrency (Actors), xml processing, implicits, 
    pattern matching, partial functions, monads. You can start using it right away and 
    slowly learn about the more powerful constructs. You can easily write a DSL (Domain 
    Specific Language) using scala. There is however a drawback of a functional language 
    like Scala (or Clojure) that runs on top of Java Virtual Machine: it is that recursion 
    is a common paradigm in these languages but the JVM doesn't allow optimization of tail 
    calls.
    
    Scala は traits、抽象型 (abstract types)、高階関数 (higher order functions)、クロージャ 
    (closures)、ネイティブスレッド (native threads) concurrency (Actors)、xml 処理、
    implicits、パターンマッチング (pattern matching)、partial functions、モナド (monads)
    といったたくさんの機能を持った巨大な言語 (huge language) である。
    You can start using it right away and slowly learn about the more powerful constructs.
    Scala を使って簡単に DSL (Domain Specific Language ドメイン特化言語) を記述できる。
    Javaバーチャルマシン上で動作する Scala のような関数型言語の drawback がある。このよう
    な言語では再帰は一般的なパラダイムであるが、JVM は末尾呼び出し (tail calls) の最適化を
    許していない。
    
    
    
    Scala, unlike OCaml and Haskell/Clean satisfies criteria #7 and #8. The extensive set 
    of Java libraries can be put to use.
    
    OCaml や Haskell/Clean と異なり、Scalaは criteria #7 and #8 を満足する。
    The extensive set of Java libraries can be put to use.
    Java のライブラリの extensive set を put to use できる。
    
    
    Scala, unlike OCaml and Haskell/Clean satisfies criteria #8. OCaml and Haskell/Clean 
    have a much higher learning curve than Scala. Haskell is a pure functional language 
    and you have to use something called Monads for side-effects. Scala is much easier to 
    learn for the majority of programmers who have been programming in the imperative 
    style.
    
    OCaml や Haskell/Clean と異なり、Scalaは criteria #8 を満足する。OCaml と 
    Haskell/Clean は Scala と比べるとその学習曲線がより higherなものである。Haskell は純粋
    関数型言語であり、副作用のためにはモナドと呼ばれる何か(something called Monads) を使わ
    なければならない。Scala は、命令型のスタイルでプログラミングを行ってきているプログラマ
    ーの majority にとって学ぶのが格段に簡単である。
    
    
    With Scala, you can start with imperative or object-oriented style of programming 
    (think of it Java without the verbosity) and migrate slowly to the functional features. 
    Even if Martin Odersky's attempt (experiment as he puts it) to unify functional and 
    object-oriented style of programming doesn't pan out, Scala can still be a successful 
    language.
    
    Scala を使うと、命令型やオブジェクト指向型のプログラミングスタイルから始めて (think of 
    it Java without the verbosity)、関数型の機能をゆっくりと migrate できる。Martin 
    Odersly の意図が関数スタイルのプログラミングとオブジェクト指向スタイルのプログラミング
    との unifty がうまくいっていない (does't pan out) としても、Scala はそれでも 
    successsful でありつづけられるだろう。
    
    
    Lift is a web framework written in Scala. You can create web apps as easily as you can 
    do with Rails and Django but it will typically run 4 to 6 times faster, use less CPU 
    and it will be lot more scalable.
    
    Lift は Scala で書かれた webフレームワークである。これは web アプリをRails や Django 
    を使ったのと同じくらい簡単に作れる一方でしかし典型的にはそれよりも四倍から六倍高速にな
    り、CPU パワーも浪費せずによりスケーラブルになる。
    
    
    So, for the reasons mentioned above, I will remove OCaml, Haskell and Clean from the 
    list and declare Scala the winner.
    
    であるから、前述した理由で OCaml と Haskell、Clean をリストから削除して、
    Scala が勝利者 (winner) であると宣言する。
    
    To give a flavor of a Scala program written in imperative style, here is a script I 
    wrote to answer a question posed by Cedric Otaku in his blog. You don't need to write 
    a program to answer his question but you can verify it using a simulation. Otaku wrote 
    it in Ruby; my Scala version is equally concise.
    
    命令型のスタイルで書かれたフレーバーを Scala プログラムに与えるために, Cedruc Otaku が
    彼の blog で pose した質問に回答するためにわたしが書いたスクリプトがある。あなたは彼の
    問いに答えるプログラムを書く必要はないが、それを使ったシミュレーションを verify できう
    る。Otaku はそれを Ruby で書いたが、わたしの Scala バージョンは equally concise である。
    
    
    Here is a sample program
    サンプルプログラムを示す
    
    /*
     * Question: Do you want to play this game?
     * You put down some money and roll a die between 1 and 100
     * Depending on your roll:
     *    1-50: I keep your money.
     *   51-65: You get your money back.
     *   66-75: You get 1.5 times your money
     *   76-99: You get 2 times your money
     *     100: You get 3 times your money
     * Do you want to play?
    */
     
    object game { // object is used to define a singleton class
     
      // alas, type inference doesn't work for function args.
      def play(bet: Double, numPlays: Int)  = {
        // parameter values can't be changed
        import java.util.Random // imports can be inside function
     
        // val is like final in java or const in C
        val r = new Random()
        var moneyStart, money = numPlays * bet
        // type of moneyStart and money need not be specified.
        // However, unlike python or ruby, they are inferred as
        //  Double at compile time. Similarly for r and dice.
     
        for (i <- 1 to numPlays) {
          var dice = r.nextInt(100) + 1  // roll the dice
          if (dice <= 50)
            money -= bet
          else if ( (dice >= 66) && (dice <= 75) )
            money += 0.5 * bet
          else if ( (dice >= 76) && (dice <= 99) )
            money += bet
          else if (dice == 100)
            money += 2 * bet
        }
        printf("%6.0f$ became %6.0f$ after %6d plays: " +
               "You get %.2f for a dollar\n", moneyStart,
               money, numPlays, (money / moneyStart))
      }
    }
     
    game.play(1.0, 100000) // Each bet is $1, play 100000 times
    game.play(1.5, 5000)
    game.play(4.0, 10000)
    
    Run the script:
    scala game.scala
    100000$ became 80426$ after 100000 plays: You get 0.80 for a dollar
    7500$ became 6134$ after 5000 plays: You get 0.82 for a dollar
    40000$ became 31922$ after 10000 plays: You get 0.80 for a dollar
    
    

    ■_ 本日の巡回から

    2010年06月01日

    ■_

    こーゆーイベント BOX発売記念&「宇宙ショーへようこそ」公開記念!「R.O.D」「かみちゅ!」 同窓会(?)ナイト Twitpic Advert に行ってきたので、本日分は更新するほど余裕がありません(笑)

    Twitter / Search - #uchushow

    ■_ 巡回とか

    ■_

    昨日上げた分にあった ■_ ホンモノの~ でよくわからんとか書いたところについて、いけがみさんからいろいろ教えていただきました。

    セミコロンが入ってたりして検索してもだめだろうと思ってたんですが、 そうでもなかったんですねえ(^^; "TL;DR" - Google 検索 で、リストの上位に http://www.urbandictionary.com/define.php?term=tl%3Bdr とか http://en.wiktionary.org/wiki/TLDR とか。

    Literally, "Too long; didn't read" Said whenever a nerd makes a post that is too long to bother reading. 「長くて読む気になるかぼけ」てな感じでしょうか。

    ■_ 無能な働き者

    佐藤大輔 80 [chaika]
    843 名無し三等兵 [sage] 2010/05/30(日) 17:17:28 ID:??? Be:
        RSBCでネタにしてた鮭先生はあの年になってもまだ新作を書くというのに
        御大は・・・ 
    
    844 名無し三等兵 [sage] 2010/05/30(日) 19:37:26 ID:??? Be:
        つ「無能な働き者」
    
        鮭はまだ、呉で武蔵が爆沈したと思いこんでるのかね? 
    
    845 名無し三等兵 [sage] 2010/05/30(日) 20:00:24 ID:??? Be:
        無能な働き者云々の一覧って何の話のどのへんに出ていたっけ? 
    
    846 名無し三等兵 [sage] 2010/05/30(日) 20:03:06 ID:??? Be:
        外伝 
    
    847 名無し三等兵 [sage] 2010/05/30(日) 20:04:11 ID:??? Be:
        >>845
        外伝、征途3巻、自営業先生のユギオ2 
    
    848 名無し三等兵 [sage] 2010/05/30(日) 20:20:03 ID:??? Be:
        おまえら回答早すぎ。
        何回読んだんだよ。 
    
    849 845 [sage] 2010/05/30(日) 20:46:43 ID:??? Be:
        >>847
        サンクス、征途みたら82ページにあったわ 
    
    850 名無し三等兵 [sage] 2010/05/30(日) 20:53:23 ID:??? Be:
        >>848
        何十回と
        なにせ新作が出ないからね 
    
    
    863 名無し三等兵 [sage] 2010/06/01(火) 22:28:08 ID:??? Be:
        >>845 日本じゃ大ちゃんと自営業のおかげでフォン・ゼークトの台詞ってことになってるが、
        正しくはその弟子のクルト・フォン・ハマーシュタインの台詞なんで気をつけてな。
        …ヴァイマル共和国軍きって有能者だが、軍一番の怠け者として知られてた人で、
        ヒトラーを無能な働き者の極みとして嫌いぬいてたんだよなあ。
        フォン・ゼークトは物凄い働き者で知られた人なんでかなりの違和感があったが、
        この人なら納得ではある。 
    
    

    この人です。ハマーシュタイン →
    がんこなハマーシュタイン


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

    ホームへ


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

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