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

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

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

ホームへ

2010年03月10日

■_

バーチャファイターやりたい。 それも2とか3あたり。

■_ Delphiでは?

VirtualAllocについて - Yahoo!知恵袋 からたどって


Windowsプログラムでゲームを作りたい。
79 名前: 13の書換 投稿日: 2000/06/04(日) 03:11
    Win クラスらしきものを作ってるのに、肝心のWinProcが継承出来ないから
    WinProc側の課題が出ないのだと思う。 という事で、WinProcをVirtualにしてみた

    struct Win{
     HWND hwnd;
     HDC  hdc;
     int  kcode;
     static Win * callbackSelf;
     WNDPROC cb; //サンクポインタ
    virtual LRESULT WndProc(HWND hw,UINT uMsg,WPARAM wParam,LPARAM lParam)
     { switch(uMsg){
      case WM_PAINT: { PAINTSTRUCT ps;HDC hdc= BeginPaint(hw,&ps);
        TextOut(hdc,0,0,"再描画しました",14);
        EndPaint(hw,&ps);
        } return 0;
      case WM_DESTROY: PostQuitMessage(0);
      return 0;
      }
      return DefWindowProc(hw, uMsg, wParam, lParam);
     }

    static LRESULT CALLBACK WndProcGate(HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM lParam)
      { return callbackSelf->WndProc(hwnd,uMsg,wParam,lParam);  }

    void makeClass(char *WinClassName)
    {   cb=(WNDPROC)VirtualAlloc(NULL,10+5 , MEM_COMMIT, PAGE_EXECUTE_READWRITE);
      char *b=(char*)cb;            //コールバックゲートをこしらえる
        *b++= 0xC7; *b++= 0x05;       //MOV [adr],xxxx
        *((int *)b)++=(int)(&callbackSelf); //メモリアドレス
        *((int *)b)++=(int)this;       //オブジェクトアドレス
        *b++= 0xE9;             //jump long xxxx
        *((int *)b)= ((int)WndProcGate)-(4+(int)b);//ジャンプ先
     WNDCLASS wndclass= { 0/*CS_SAVEBITS*/ ,//UINT  style;
                cb,   //WNDPROC lpfnWndProc;
                0,0,     //int   cbClsExtra,cbWndExtra;
                0,               //HANDLE hInstance;
                LoadIcon(NULL,IDI_APPLICATION),//HICON  hIcon;
                LoadCursor(NULL,IDC_ARROW),  //HCURSOR hCursor;
        (HBRUSH)    GetStockObject(WHITE_BRUSH),  //HBRUSH hbrBackground;
                NULL,             //LPCTSTR lpszMenuName;
                WinClassName, };        //LPCTSTR lpszClassName;
      RegisterClass( &wndclass );
    }
    void beginWin(char *WinClassName,int xs,int ys,int xsz,int ysz)
     {
     kcode=-1;
      HINSTANCE hinst = 0;
      hwnd=CreateWindow(WinClassName,"testWindow",WS_POPUPWINDOW,xs,ys,xsz,ysz
               , NULL , NULL , hinst , NULL);
      ShowWindow( hwnd , SW_SHOWNORMAL );
      UpdateWindow(hwnd);
      hdc  =GetDC( hwnd );
     }
    void init(){hdc=0;hwnd=0;cb=0;}
     Win(void){init();};
     Win(int xs,int ys,int xsz,int ysz)
      { init();makeClass("sample1");
       beginWin( "sample1",xs,ys,xsz,ysz); }

     ~Win()
     {if(hdc) ReleaseDC( hwnd, hdc );
      if(hwnd) DestroyWindow( hwnd );
      if(cb)  VirtualFree(cb, 0,MEM_RELEASE);
     }
    int kbhit()
     { MSG msg;
       if(PeekMessage(&msg , (HWND)NULL , 0, 0,PM_REMOVE) )
        {  TranslateMessage(&msg);
          if(msg.message==WM_CHAR)
           { kcode=0xff &((TCHAR)msg.wParam); }
          DispatchMessage(&msg);
        }
      if(kcode<0) return ::kbhit() ;
       else   return 1;
     }
    int getKB()
     {
      while(!kbhit());
      if(kcode>=0){int k=kcode;kcode=-1;return k;};
      return getch();
     }
    };
    Win *Win::callbackSelf;



80 名前: 79 投稿日: 2000/06/04(日) 03:15
    MFCでは hWndからハッシュテーブルを検索してWinProcコールバックから
    該当するクラスを検索してるみたいだが、79の方法は、Delphiとかで使っているサンク方式だ
    (この板で知った方法なのだが、過去ログはみつからない)



81 名前: >80 投稿日: 2000/06/04(日) 04:01
    ATLだと構造体つかってやってるけど、それも同じだね。
    でもこの方法だとx86(ATLはAlphaもサポート)でしか動かないんだよね。


87 名前: 79  投稿日: 2000/06/06(火) 19:50
    折角なので、継承してみた。 これで上に他の窓が重なっても大丈夫・・・
    struct GDIBMPWin:Win
    {
     HDC  winhdc;
     HBITMAP hBitmap;
      cls(void){RECT r;GetClientRect(hwnd,&r);
          InvalidateRect(hwnd, NULL,FALSE);
          return FillRect(hdc,&r,(HBRUSH)GetStockObject(WHITE_BRUSH));
          }
    GDIBMPWin(int xs,int ys,int xsz,int ysz): Win()
      { makeClass("className2");
       beginWin( "className2",xs,ys,xsz,ysz);
       winhdc=hdc;//画面用DCは保存しておいて
       hdc = CreateCompatibleDC(winhdc );
       hBitmap=CreateCompatibleBitmap(winhdc, xsz,ysz);
       SelectObject(hdc,hBitmap);
       cls();
      }
     ~GDIBMPWin()
     {
      if(hdc) DeleteDC( hdc );
      if(hBitmap)DeleteObject(hBitmap);
       hdc=winhdc;
     }
    LRESULT WndProc(HWND hw,UINT uMsg,WPARAM wParam,LPARAM lParam)
     {switch(uMsg){
       case WM_PAINT: { PAINTSTRUCT ps;HDC ndc= BeginPaint(hw,&ps);
       RECT Client;
       GetClientRect( hw, &Client );
       BitBlt( ndc,    Client.left,         Client.top,
        (Client.right - Client.left),(Client.bottom - Client.top), hdc,
         Client.left,         Client.top,     SRCCOPY );
       EndPaint(hw,&ps);
       } return 0;
      case WM_DESTROY: PostQuitMessage(0);
      return 0;
      } return DefWindowProc(hw, uMsg, wParam, lParam);
     }
    int getKB() //画面をリフレッシュさせる為に継承する
     {
      InvalidateRect(hwnd, NULL,FALSE);
      return Win::getKB();
     }
    };


88 名前: 79 投稿日: 2000/06/06(火) 19:55
    87のコードを追加して
    今までの Win w(10,10,100,100); ->GDIBMPWin w(10,10,100,100); に替える
    GDIビットマップを使って 一旦バッファ上に描画し、WinProcで画面を書換えている

    だから、実際に表示されるタイミングを考慮して書換える事
    例:
    case 'T': //3角形を表示するサンプル
      {
       for(double d=0;d<2*M_PI;d+=0.03)
       { POINT pt[3]={{0,0},{30,30},{-30,30}},wk[3];
        double s=sin(-d),c=cos(-d);
        for(int i=0;i<3;i++){wk[i].x=pt[i].x*c+pt[i].y*s+50;wk[i].y=pt[i].y*c-pt[i].x*s+50;}
        w.cls(); //画面バッファのクリア
        Polygon(w.hdc, wk, 3);//この行で三角形が表示出来る
        if( w.kbhit() )break; //ホントウに表示されるのはこのkbhit内
        Sleep(30);
       }
      }break; 

なるほどなかなか楽しいことやってたんだなあ>でるふぁい。 むかーーーーーーし、スタックを数十バイト~数百バイト確保してそこに サブルーチンを動的に生成して飛び込むとかやったなあ。 何でやったかはナイショですがw

■_

■_

2010年03月09日

■_

あー、思い切り毒(愚痴ともいう)吐きてー

豊富でもない戦力を分散させといた挙句に 主力を叩かれるってどんだけ抜作なんだか。

■_ Algol 68から?

perl6 journal: The ghost of Algol 68 (??) : programming 経由で。


Journal of masak (6289)

Ever wonder why bash closes if blocks with fi? This practice was inctroduced in Algol 
68, a language that Perl 6 was accused of reinventing yesterday on the perl6-language 
list.

(略)

Besides that, there's all these other little parallels, such as

    * Algol 68 seemingly playing with words (they borrowed the term 'gomma' from 
      Finnegan's Wake, but the feature it denoted got scrapped in a 1973 revision),
    * something junction-like called 'multiple value',
    * a whole heap of values for different forms of nothing and undefinedness,
    * a newly-invented grammar formalism, and
    * a general feeling of deep ambitiousness and a desire to get things right.

So, there are deep similarities between Algol 68 and Perl 6. There's not much to say 
to that, except perhaps "huh".

If there's anything in it all that's uplifting though, it's the second paragraph of 
the article:

Contributions of ALGOL 68 to the field of computer science are deep and wide ranging, 
although some of them were not publicly identified until they were passed, in one form 
or another, to one of many subsequently developed programming languages.

If that's not spot on for Perl 6, I think it will be in a decade or so.

Algol 68 は自身の普及はそれほどでもなかったけど、後の言語には多大な影響を及ぼしたという話。 しかしそれと Perl 6が似ているとかって縁起でもないと考えるのは 日本人的なんだろうなあ。うん。

■_ あれ?

ムムリクさんのせいではないのでしょうが



メモ:nariさんのGC本: つらつらぐさ
メモ:nariさんのGC本

 なんだか落ち着かずにいると忘れてしまいそうなのでやっぱりメモしておこう。nari さんの GC 本。

(略)

ガベージコレクションのアルゴリズムと実装
竹内 郁雄
秀和システム 2010-03-18

by G-Tools

著者名が!

■_ global

Python の仕様について。

Pythonのお勉強 Part36 
656 デフォルトの名無しさん [sage] 2010/03/08(月) 20:58:43 ID: Be:
    a=10
    def msg():
        a=1
        print (a)

    msg()

    これでエラーがでない言語なんて怖くて使ってられない 

657 デフォルトの名無しさん [sage] 2010/03/08(月) 21:02:32 ID: Be:
    OOあるから環境依存部分は切り替えれば済むだろ
    なんのためのOOだ 

658 デフォルトの名無しさん [sage] 2010/03/08(月) 21:02:39 ID: Be:
    使わなければいいと思うよ 

659 デフォルトの名無しさん [sage] 2010/03/08(月) 21:02:54 ID: Be:
    え?何かおかしいか? 

660 デフォルトの名無しさん [sage] 2010/03/08(月) 21:04:06 ID: Be:
    >>656
    global-aを生成してmsg.aを表示してるだけじゃん。 

661 デフォルトの名無しさん [sage] 2010/03/08(月) 21:06:25 ID: Be:
    >>660
    そこが問題なんだよ

    ローカル変数とグローバル変数が同じ変数名で定義できるなんて
    恐ろしいことができてしまうなんて・・・ 

662 デフォルトの名無しさん [sage] 2010/03/08(月) 21:08:15 ID: Be:
    >>656
    Pythonユーザがそのコードを読むときは、msg()の中の
    a=1を(set! a 1)ではなく(let ((a 1))と読むので
    意図は伝わらないだろう

663 662 [sage] 2010/03/08(月) 21:09:06 ID: Be:
    と、思ったが勘違いだったか

    >>661
    君が使っていて、それが「できない」言語を教えて欲しい 

664 デフォルトの名無しさん [sage] 2010/03/08(月) 21:10:35 ID: Be:
    Cでもできるが 

665 デフォルトの名無しさん [sage] 2010/03/08(月) 21:21:37 ID: Be:
    俺も公式のマニュアル読んでて変数の衝突がありえる言語だと思ってる
    http://www.python.jp/doc/release/tut/node11.html
    9.2 Python のスコープと名前空間と9.4 いろいろな注意点が難解 

667 デフォルトの名無しさん [sage] 2010/03/08(月) 21:36:01 ID: Be:
    def setAge():
     a=12
    a=21
    setAge():
    print(a)

    はわわわわ・・・・ 

668 デフォルトの名無しさん [sage] 2010/03/08(月) 21:37:53 ID: Be:
    >>661
    Name Hidingがある言語の方が普通だろ?
    ローカルとグローバルで名前被ったらエラーとか勘弁してくれ 

669 デフォルトの名無しさん [sage] 2010/03/08(月) 21:40:12 ID: Be:
    >>667
    それが はわわわ だと思ってるのはお前ぐらいだから
    一年後に読み返して赤面する前に巣に帰ったほうがいいぞ 

670 デフォルトの名無しさん [sage] 2010/03/08(月) 21:41:19 ID: Be:
    >>667
    動作確認してないけどこれで動くだろ
    def setAge():
        global a
        a=12

    a=21
    setAge()
    print(a) 

671 デフォルトの名無しさん [sage] 2010/03/08(月) 21:45:23 ID: Be:
    はわわ・・・直った 

672 デフォルトの名無しさん [sage] 2010/03/08(月) 21:45:49 ID: Be:
    global文ってキモいよね
    Cのプラグマとか
    MFCあたりで昔多用されていたUSES_CONVERSIONマクロみたいに見える
    もちろん意味も役割も全然別物だが 

673 デフォルトの名無しさん [sage] 2010/03/08(月) 21:46:14 ID: Be:
    >>670
    そうすりゃできるのはわかっているが
    グローバルとローカルが
    ソースの見た目上明確に区別されてないなんて・・・ 

674 デフォルトの名無しさん [sage] 2010/03/08(月) 21:47:01 ID: Be:
    大文字でも使っときなさいよ 

675 デフォルトの名無しさん [sage] 2010/03/08(月) 21:48:21 ID: Be:
    >>673
    いやあんた、Cでもグローバルとローカルの区別は
    関数の中で定義したかどうか、そんだけだべ 

676 デフォルトの名無しさん [sage] 2010/03/08(月) 22:03:04 ID: Be:
    うーむ、値だけを保持したメソッドのないクラスは作れないのか・・・ 

679 デフォルトの名無しさん [sage] 2010/03/08(月) 22:22:22 ID: Be:
    >>673
    def setAge() {
     a=12
    }
    a=21
    setAge():
    print(a)

    こうしたらどう?
    一応インデントで明確に区別されてるのよ
    まぁ Perl の my とか JavaScript の var 的なものが欲しいと思うことはあるけどね

680 デフォルトの名無しさん [sage] 2010/03/08(月) 22:33:34 ID: Be:
    そのsetAge()の例は、Pythonの仕様を理解してしまえば特に困ることはないよ
    困るのは、以下のような単純なケース

    bar = 123
      :
      :
    var = 456 # barのつもりだった

681 デフォルトの名無しさん [sage] 2010/03/08(月) 22:40:23 ID: Be:
    それって、もしかしてvarやmyの必要性を訴えてるの?
    varやmyを付け忘れて意図せずグローバル変数にアクセスするバグのほうが遥かに確率高いと思うんだが 

682 デフォルトの名無しさん [sage] 2010/03/08(月) 22:41:48 ID: Be:
    >>681
    PerlやJavaScriptのように、varやmyを「つけなくてもいい」、
    「つけなければグローバルになる」言語ではそうだね

695 デフォルトの名無しさん [sage] 2010/03/09(火) 01:46:34 ID: Be:
    おいおい・・・まじかよ・・・・

    x=1000
    def mymoneyis():
    return x*2

    money=mymoneyis()
    print str(money)+"en" 

696 デフォルトの名無しさん [sage] 2010/03/09(火) 02:05:10 ID: Be:
    それのどこが問題なのかはっきり言えよ 

697 デフォルトの名無しさん [sage] 2010/03/09(火) 02:11:16 ID: Be:
    グローバルと宣言しなくてもグローバル変数として
    処理しちゃってるじゃん・・・ 

698 デフォルトの名無しさん [sage] 2010/03/09(火) 02:13:10 ID: Be:
    えっ 

699 デフォルトの名無しさん [sage] 2010/03/09(火) 02:22:10 ID: Be:
    そういえば初めの頃俺もそれで迷ったことが有った。
    今はなんとも思わんけど。 

700 デフォルトの名無しさん [sage] 2010/03/09(火) 02:25:44 ID: Be:
    いちいちモジュールもglobal宣言すんのか 

701 デフォルトの名無しさん [sage] 2010/03/09(火) 02:29:02 ID: Be:
    global文なんてあんまり使わないと思うけどなあ。なんのための関数なんだよ、と 

702 デフォルトの名無しさん [sage] 2010/03/09(火) 04:14:22 ID: Be:
    まずチュートリアルで勉強したからglobalでは迷わなかった。 

703 デフォルトの名無しさん [sage] 2010/03/09(火) 04:24:35 ID: Be:
    確かに不思議仕様だが、実に合理的な素敵仕様でもある。

    書き込み時にglobal宣言しなければならないのは、
    globalで同じ名前の変数が宣言されていることを知らずにglobalに上書きしてしまうのを防ぐため。
    というか、プログラマは自分が見たくも触りたくないglobal変数については、そもそも知っている必要がない。

    あるいは、globalを作る人が、別の関数で既に使われている名前の変数を作ってしまっても問題にならないように。
    これも、プログラマは関数の内部でどんなローカル変数が使われているかなんて、知っている必要がない。

    ローカル変数を明示的に宣言する文法にしてもよかったのだけど、
    globalに書き込む必要があるときよりも、ローカル変数だけで済ませられるケースの方が圧倒的に多いので、
    特別な処理が必要な場合にだけ、わざわざ宣言しなければならない。


    読み込み時にglobal宣言しなくてもよいのは、
    プログラマは自分の作っている関数については把握しているべきだし、
    そしたら、ローカルで宣言していない変数を読んでいることはプログラマ自身が自覚しているはずだから。

    わざわざ明示しなくても、スコープ内にない変数を読んでいるのは外のスコープにあるからに決まっている。
    だから、わざわざ明示する必要はない。 

705 デフォルトの名無しさん [sage] 2010/03/09(火) 06:26:31 ID: Be:
    >>703
    つまり、プログラマはクラスの内部も
    関数の内部も把握してプログラミングしなければいけないということですね
    それって小規模ならいいが規模が大きくなるほどものすごく大変な作業
    テレビの内部構造を理解していないとリモコンもおちおち触れないなんて
    ものすごい言語ですね

    どの関数が勝手にグローバルの関数や変数の値を
    拾っていったか探しながら、気をつけながらやらなければいけないなんて・・・ 

706 デフォルトの名無しさん [sage] 2010/03/09(火) 06:33:31 ID: Be:
    君の使ってる言語のある関数は内部であんなことやこんなことをしているかもしれないぞ
    そういう物騒なことをしないと担保するものは何か考えたらよろし 

707 デフォルトの名無しさん [sage] 2010/03/09(火) 06:41:06 ID: Be:
    その場合はコンパイラがエラーを吐いてくれる
    Pythonの恐ろしいのはエラーを吐かないこと 

708 デフォルトの名無しさん [sage] 2010/03/09(火) 08:10:54 ID: Be:
    標準出力に吐きますが? 

709 デフォルトの名無しさん [sage] 2010/03/09(火) 08:42:23 ID: Be:
    >>705
    どの関数がグローバル変数を書き換えるか、にくらべると、
    どの関数がグローバル変数をひろったか、は重要じゃないから
    合理的だろ。

    だいたい、Pythonにとってはクラスも関数もモジュールもグローバル変数だ。
    import os
    def foo(): pass
    def bar():
        global os
        os.listdir('.')
        global foo
        foo()

    なんていちいち必要だなんてゾッとする 

703 のような見方は気がつかなかった。 なるほどねー。

■_ 時間が

ぶつ切りにしか取れないので、じっくり例の問題を考える余裕がない ○| ̄|_

■_ そして

翻訳も進まない ○| ̄|_

■_ How To Write Unmaintainable Code

How To Write Unmaintainable Code ですが、こんなのが。

Miscellaneous Techniques (その他の雑多な技法)

    If you give someone a program, you will frustrate them for a day; if you teach 
    them how to program, you will frustrate them for a lifetime.

    もし誰かにプログラムをあげたなら、あなたは一日悩まされるでしょう。
    もし誰かにプログラミングを教えたら、あなたは一生悩まされるでしょう。
    - Anonymous
  

元ネタは魚をあげるか釣り方を教えるかってアレだと思いますが、 これはまあなんというか(笑)

■_ 本日の巡回から

2010年03月08日

■_

ある本の書評を新聞で見かけたときに とても興味を惹かれたのでぽちっとなしてみました。 届いてからどんな本か紹介します(えー

■_

どうもやる気が失せかけたので、これで放り投げます(笑)

On Coding in C++, Java, Perl, Scheme, and Ruby

On Writing Code

Coding in C++ is like a knife fight. The compiler is your first enemy, and the system 
you're writing is the second. With each line of code, you use every underhanded trick 
you can think of to gain advantage. And if you mess up, the compiler stabs you with 
incomprehensible errors and mysterious warnings. Should you survive them, your system 
viciously attacks you with segmentation faults, and then, only after you have defeated 
those, do you get to battle the actual correctness bugs.

C++ でのコーディングは knife fight に似ています。コンパイラーがあなたの最初の敵であり
あなたがプログラムを書くそのシステムが二番目の敵です。コードの一行ごとにあなたは使うこ
とでアドバンテージをもたらすと考えられるような理解しているトリックを使います。そしても
しあなたが下手を打ったりすれば、コンパイラーはあなたを不完全なエラーと謎めいた警告で
stab (突き刺す、傷つける) するでしょう
Should you survive them,
あなたのシステムはセグメンテーション違反であなたを viciously に攻めますそしてさらに、
これらのことを defeated したあとでだけあなたは actual correctness bugs と戦う (battle) 
ことができるのです。


"Bugs" is an understatement. A better image is ugly, man-eating insectoids 
roughly the size of SUVs, each surrounded by a horde of smaller beasties that aid and 
assist it, and you equipped with your measely fighting knife. While I must admit that 
debuggers, lint tools, and other things C coders will point to in their defense add 
some more weapons to your arsenal, the fundamental metaphor remains intact.

“バグ”というのは控えめな表現です。もっとふさわしいイメージは、醜くて SUV ほどもある
ような大きさの人食い insectoid どもで、それぞれが援護とアシストをする smaller beast の
群れを従えています。そしてあなたが装備しているものと言えばちっぽけな戦闘用ナイフ
(fighting knife) なのです。
While I must admit that 
debuggers, lint tools, and other things C coders will point to in their defense
add some more weapons to your arsenal, the fundamental metaphor remains intact.



Coding in Java is like walking. You move along, slowly, methodically, irrevocably 
making progress toward your goal. It takes time, and you must occasionally walk around 
strange language idioms and syntax requirements, but it is not actually dangerous. 
Nothing is trying to kill you with segmentation faults, and you will, inevitably, 
reach your destination. And sometimes, depending on where you are going, you may even 
have time to contemplate some pretty sights along the way.

Java でコーディングすることはウォーキングに似ています。あなたはぶらぶらと、ゆっくり 
methodically (整然と)に後戻りできない道のりをゴールに向けて移動しますそれは時間がかかる
し、ときには奇妙な言語イディオムや要求される構文の周りを歩かなければなりませんが、しか
しそれは本当に危険なものではありません。セグメント違反 (segmentation faults) であなた
を殺そうと試みるものはありませんし、そしてあなたは必然的にあなたの目的とするところに到
達します。時にはあなたの向かう場所によっては、道中の素晴らしい景観をじっくりと楽しむた
めの時間すら持つことができるかもしれません。


Coding in Perl is like dancing Argentine Tango. There is a learning curve of no little 
steepness, but once you've started using Perl you can hardly stop. Programming becomes 
almost a carnal pleasure. You find yourself writing scripts to do things that you 
would have unthinkingly done by hand only a couple years ago. And you find that those 
scripts are really elegant, in their own, Perlish way, and yet each is new and unique, 
in each you take a different twist on a standard move, that works better in that 
context.

Perl でのコーディングはアルゼンチンタンゴを踊ることに似ています。その学習曲線には 
little  steepness (勾配がなだらかになるところ?) すらありませんが、ひとたび Perl を使い
始めれば止めるのは困難であるかもしれません。プログラミングはほぼ carnal (現世的な、肉
欲的な)な喜びとなりました。あなたは、スクリプトを書くことがほんの二、三年前に手作業で
軽率に行ったことであったことに気がつくでしょう。あなたはまた、そういったスクリプトが本
当に elegant であることに気がついて、in their own, Perl 的なやり方でありかつそれぞれが
新しくユニークであるような別の twist をその context で work better な standard move で
take するでしょう。

On the other hand, Perl code is as ephemeral as a dance. If you try to extend it too 
far, fatigue overcomes you, and once you finish a dance, you can never again recapture 
its spirit. Trying to understand Perl that is already written is as fruitful as trying 
to recreate a dance from the dancers' footprints.

その一方で Perlのコードはダンスのように ephemeral (儚い) ものです。
If you try to extend it too far,
疲労があなたを圧倒してしまってダンスを終えてしまえば、二度とその精神を recapture する
ことは決してできません。既に書かれた Perl のコード (Perl that is already written) を理
解しようと試みることはダンサーの足跡からダンスを再演しようと試みるのと同じくらい 
fruitful です。


Coding in Scheme is like playing Mozart. Even the apprentice can begin, and the 
results will be recognizable. But when you get reasonably good at it, you sit down, 
and code flows from your mind in beautiful waves that seem hardly to pass through your 
fingers at all --- you think, and your thoughts take form. Each program must be 
approached with careful study and forethought, but when you actually write it, the 
process is a brilliant, ravishing experience. And no matter how good you are, you 
always have the feeling that if you were smarter, you would be better. Always, some 
clever new way of structuring your programs is just beyond your grasp.

Scheme でコーディングすることはモーツァルトを演奏することに似ています。apprentice (初
心者、見習い) であってさえも始めることはできますし、その結果は recognizable なものにな
るでしょう。しかし you get reasonably good at it したとき、
you sit down, 
and code flows from your mind in beautiful waves
that seem hardly to pass through your fingers at all
--- you think, and your thoughts take form.
それぞれのプログラムはcareful study と予見 (forethought)を持ってアプローチされたもので
なければなりませんが、あなたが実際にプログラムを書いたときのプロセスは brilliant であ
り経験 (experience) を ravishing します。そしてあなたがどの程度 good であるかは問題で
はなくもし自分がもっと賢かったなら、もっと良くなっていただろうということを常に感じるの
です。いつでも、あなたのプログラムを構築する新たな賢い方法は単にあなたの理解 (grasp) 
を飛び越えているだけなのです。


Coding in Ruby is like coding in Scheme. Yet somehow both more and less. Less 
otherworldly, more down-to-earth. Ruby code may not be Mozart, but it is still music. 
Yet at the same time, it is more comfortable than Scheme: the I/O is nicer, the 
foreign language bindings are easier, the libraries are more practical (albeit less 
intellectual). After only a short courtship, Ruby had become my language of choice.

Ruby でのコーディングは Scheme でのコーディングに似ています。
Yet somehow both more and less.
Less otherworldly, more down-to-earth.
Ruby のコードは Mozart のようにあることは許されませんが、それでも音楽には変わりありま
せん。と同時に、Scheme と比べてより comfortable (気持ちよく感じる、居心地がよい) です。
I/O はより nice であり、他言語 (foreign language) のバインディングも容易で、ライブラリ
はより実践的 (practical) です (albeit less intellectual)。
short courtship のあとで、Ruby はわたしの language of choice となりました。


A short courtship, however, proved to presage a short romance. It took only a year or 
so of coding in Ruby for me to see that the things I liked about the design of the 
language itself (as opposed to, say, its libraries) I liked for their resemblance to 
Scheme; and the things I disliked I disliked because Scheme had shown me a better way. 
So now my heart is filled with yearning: to live forever in the elegance and 
simplicity of Scheme, and yet have the volume and quality of support, libraries and 
tools that have been built for other tongues.

short courtship はしかしながら proved to presage a short romance.
わたしにとって言語の設計そのものについてScheme によく似ていて好きなもの(これはまあライ
ブラリなのですが)を見つけ出すためにRuby でコーディングするのは一年かそこらの期間しか要
しませんでした。そしてわたしが好きでなかったものは Scheme がもっと良いやり方をわたしに
示していたものです。今、わたしの心は Scheme の elegance と simplicity の中で永遠に生き
ることに対する yearning (あこがれ、羨望)で満たされているのです:

and yet have the volume and quality of support,
libraries and tools that have been built for other tongues.

Last modification: Tue Jun 24 12:40:22 -0400 2008

うーむ。いつにも増してぐだぐだな文だ ○| ̄|_

■_

■_ FQA

つづき


C++ FQA Lite: Defective C++

Part of C++ FQA Lite


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

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

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


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

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

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

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

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

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

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


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

■_ 本日の巡回から

■_

うだうだやってる間に nishio さんが解答を出してしまったもより。 見てないけどさてどーすっかいねえ。

2010年03月07日

■_

・iPhone
さいとーさんも iPhone に転んじゃったのかあ

・献本
~で~(という本を)いただきました的な発言を見かけると正直うらやましいとは 思うけど、そうすっと書きたいことも書けなくなるからなあ。 ここでは色々な本にケチつけてますが(苦笑)、 最低限自腹で買ったものという縛りを自分につけてます。 ものによっては二冊買ってたり。 あー、日向さんの本で、図書館で借りたのが一つ二つあったかも。 ということで、はやみずさんは Scala の入門書を書いて 僕にください(何様)。

■_ CUMP?

これからは LAMP じゃなくて CUMP だってんですが。


From LAMP to CUMP | GeekTantra

From LAMP to CUMP

06 Mar 2010 | Programming, Server Administration, Web Architecture | 12 Comments

LAMP, an acronym for Linux Apache MySQL PHP, happens to be one of the most common 
server side solution stack. It has been almost 12 years since this stack has been 
ruling. But is there a scope that this can be replaced in the near future?  With 
Oracle taking over Sun, and therefore MySQL, there is little hope that MySQL will get 
enough attention from it’s company to grow. The most common free distribution to work 
as the server OS has been CentOS for sometime now. But again it’s configuration and 
package management is not as easy to handle as it should be for a modern server OS. 
Configuring Apache without an expensive control panel could be a nightmare at times. 
More over,  it is too bulky on the memory side and does sadly on the performance side. 
May be the future solution stack overcomes all these issues and becomes a bit more 
easy to use. The most promising contender for this seems to be CUMP.

LAMP to CUMP

So what is CUMP? It is an acronym for Cherokee Ubuntu MariaDB PHP. It seems to be a 
very promising contender in becoming a popular solution stack of the future.

Components of CUMP:

   1. Cherokee: (略)

   2. Ubuntu: (略)

   3. MariaDB: (略)

   4. PHP: (略)

I expect CUMP to be the solution stack of the future.

12 Responses to “From LAMP to CUMP”

   1. Raymundo says:	
      March 6, 2010 at 1:59 pm

      I think FreeBSD/OpenSolaris will make a stand on the web hosting and database 
      arenas thanks to ZFS.

            GeekTantra says:	
            March 6, 2010 at 3:07 pm

            FreeBSD/OpenSolaris do not have a community as Huge as that of Linux and 
            now Ubuntu which is going to be a pivotal factor. As for ZFS, although an
            opensource project has license incompatibility of Sun’s CDDL with the Linux
            kernel’s GNU GPL, a very weired case of conflicting opensource project
            licenses so only way left is via FUSE but which will lead to degraded
            performance. Again EXT4 or XFS also look promising with linux. You can
            check out a comparison of the three here. 
            http://manyeyes.alphaworks.ibm.com/manyeyes/datasets/89ade5ae14209c140114bcee8c082d35/versions/1

© 2010 GeekTantra
Ajatus Software

P → PHP は同じなのかw あと、FreeBSD やらを do not have a community as Huge as that of Linux and now Ubuntu which is going to be a pivotal factor. って(こっちはコメントですが)。

■_ 欲張りだなw


将来の為にC言語を勉強しようと思ってます。お薦めの良書を教えて下さい。 高1の自... - Yahoo!知恵袋

将来の為にC言語を勉強しようと思ってます。お薦めの良書を教えて下さい。
高1の自分にもちゃんと理解できるような易しくて丁寧に書き記してて
文字だけで説明じゃなくて練習問題がたくさんあって

尚且つ丁寧に解説してる本ってありますかね?
質問が多くてすみません;;


2冊セットで、どうぞ。
「新版 明解C言語入門編」。
http://www.bohyoh.com/Books/MeikaiC01/index.html
「解きながら学ぶC言語」
http://www.bohyoh.com/Books/TokinagaraC01/index.html
高校一年なら、読めば分かるはずです。

練習問題を解くためにも、かならずコンパイラ環境を導入して動かしながら学習して下さい。と
言うより動かさないと学習出来ません。

C言語の開発環境のインストールと使い方。
http://cvwww.ee.ous.ac.jp/vc08inst.html
http://cvwww.ee.ous.ac.jp/vc08prog.html

私は「猫でもわかる~」というものを使っています。


まずは過去の知恵を参考に、書店などでさっと中身を見てみるのが良いと思います。
http://search.chiebukuro.yahoo.co.jp/search/search.php?p=C%E8%A8%80...

技術書は、マンガなどと違って中身を見られるようにして販売されていることが多いので、その
中で自分に合ったものを選べば良いでしょう。

質問者が望むそのものズバリを挙げられないんだけど、 あったりするんだろうか。

■_ 継承されない?


継承について質問させていただきます(1/1) | OKWave

Java初心者です。

privateなフィールドは継承されない
と書籍にありましたが、理解に苦しんでおります。

具体例で申しますと、下記コードの
cat.setCount(3);
です。

CatクラスにはAnimalクラスの変数countは継承されないと考え、
エラーとなることを想像していたのですが。。。
なぜエラーとならないのでしょうか?

宜しければ、解りやすくご説明していただければ幸いです。
どうかよろしくお願いいたします。

----------------------------------------------
class Animal{

private int count;

int getCount(){
return count;
}
void setCount(int c){
this.count = c;
}
}

class Cat extends Animal{
}

public class test{
public static void main(String[] args){

Cat cat = new Cat();

cat.setCount(3); // ここが理解できません
System.out.println(cat.getCount()); // ここも同様
}
}
ご指摘の通り、Javaでは private のメソッド・フィールドは継承されません。ですが、メソッ
ドと違い、参照するフィールドに関してはコンパイル時に型によって決定されます。(静的束縛)

したがって、Animal クラスの getCount setCount では、必ず、Animal クラスの count を参照
することになります。

ちなみに、サブクラスでフィールドを再定義しても、オーバーライドにはならず、隠蔽になりま
す。(参考URL)

(略)

アクセスできない(不可視)だけであって、存在はしている(==継承している) と思ってたんだけど違うんでしょうか。 って sun のドキュメントを見ると


Inheritance (The Java™ Tutorials > Learning the Java Language > Interfaces and Inheritance)

Private Members in a Superclass

A subclass does not inherit the private members of its parent class. However, if the 
superclass has public or protected methods for accessing its private fields, these can 
also be used by the subclass.

A nested class has access to all the private members of its enclosing class—both 
fields and methods. Therefore, a public or protected nested class inherited by a 
subclass has indirect access to all of the private members of the superclass. 

does not inherit the private members of its parent class ってありますね。ふうむ。

■_ 見分け方

ついったーから。



Twitter / しょーた: 「やさしい」も。 RT @Iori_o: 10日で、 ...

「やさしい」も。
  RT @Iori_o: 10日で、とかつくともうね。
    RT @tototoshi プログラミングの本を買いたいけどいっぱいあってよくわからない。そんなとき
    はタイトルに「わかる」「できる」「簡単」という言葉が入っていないのを選ぼう。

「はじめての~」もお仲間?

■_ 今日の知らなかった


ハイジャック - Wikipedia
「ハイジャック」の単語の由来

ハイジャックの語源は様々に述べられている。有名なものは以下のとおり。

    * 追いはぎを意味する「Highwayman」と密猟者を意味する「Jacker」を組み合わせた単語で
      ある「Hijacker」から転じたもの
    * 「Stick'em up high,Jack(手を高く上げろ)」という強盗の文句から成立した
    * 駅馬車強盗が駅馬車の御者を呼び止める時に「Hi,Jack!」(やい、おめぇ)と声をかけた
      事から

したがって、対象が船でも車でも、乗り物を乗っ取る行為はすべて「ハイジャック」である。し
かし、日本においてはよど号ハイジャック事件の際に「Hi」を「高い」という意味の英単語「
high」と間違えて「高い所を飛ぶ=飛行機」の意味と捉え、「jack」を「乗っ取り」の意味とし
て捉えたため、その後「バスジャック」、「シージャック」、果ては放送電波への重畳を「電波
ジャック」、番組への乱入を「番組ジャック」と呼ぶなど多数の「ジャック」を使った和製英語
が生まれることになった。
(以下略)

Hijack | Define Hijack at Dictionary.com
hi·jack
   /ˈhaɪˌdʒæk/ Show Spelled[hahy-jak]
–verb (used with object)
1. to steal (cargo) from a truck or other vehicle after forcing it to stop: to hijack 
   a load of whiskey.
2. to rob (a vehicle) after forcing it to stop: They hijacked the truck before it 
   entered the city.
3. to seize (a vehicle) by force or threat of force.
4. to skyjack.

–verb (used without object)
5. to engage in such stealing or seizing.

–noun
6.an act or instance or hijacking.

なるほど。

■_ InfoQだからすぐに訳されるでしょう

なんか興味深い話題。


InfoQ: What Standardization Will Mean For Ruby

What Standardization Will Mean For Ruby

Posted by Mirko Stocker on Mar 06, 2010

At RubyKaigi 2008, Ruby's inventor Matz announced plans to standardize Ruby in order 
to "improve the compatibility between different Ruby implementations [..] and to 
ease Ruby's way into the Japanese government". The first proposal for 
standardization will be to the Japanese Industrial Standards Committee and in a 
further step to the ISO, to become an international standard. For now, a first draft 
(that weighs in at over 300 pages) and official announcement are available. 
Alternatively, there's a wiki under development to make the standard available in HTML 
format.

A very different approach to unite Ruby implementations is the RubySpec project (more 
RubySpec related news on InfoQ), a community driven effort to build an executable 
specification. RubySpec is an offspring of the Rubinius project: 

(以下略)

■_ concept さんは超がつく大物


C++0x 8 
518 デフォルトの名無しさん [sage] 2010/03/07(日) 18:31:34 ID: Be:
    コンセプトさんなんで死んでしまったんや 

519 デフォルトの名無しさん [sage] 2010/03/07(日) 18:40:26 ID: Be:
    違うわ!コンセプトさんはまだ死んでなんかいない、眠っているだけよ! 

520 デフォルトの名無しさん [sage] 2010/03/07(日) 18:49:07 ID: Be:
    何年後に起きてくれるんだろうか 

521 デフォルトの名無しさん [sage] 2010/03/07(日) 19:25:15 ID: Be:
    現在conceptは深海の都ルルイエで深き者どもにかしずかれ死よりも深い
    眠りについているが、星辰が然るべき位置に戻りルルイエが再び浮上する
    ときconceptは甦り、地上の全てを支配すると信じられている。 

524 デフォルトの名無しさん [sage] 2010/03/07(日) 21:59:45 ID: Be:
    Conceptさんってそんなに大物なのかw 

C++ に近づくには SAN値チェックが必要。と。「

■_ 本日の巡回から

■_

ああ、ヒントをもらったのに時間がががが。 朝の出勤時にでも考えよう。

2010年03月06日

■_

・歴群
通産100号到達だそうで。
歴史群像 2010年 04月号 [雑誌]
確か創刊号から買ってるんですよねえ。これ。 もちろん手元に残ってたりはしないんですが。 創刊号は関ヶ原だか三国志の特集じゃなかったかなあ。

"Every language has its flaws. What are the three things you dislike most strongly in C++?" Scott Meyers: "complexity, complexity, complexity!" : programming
Bookpool: A Virtual Interview with Effective C++ Author Scott Meyers
For all you haters of C++, take a look at the languages used by top ranking coders in the Google AI challenge. : programming

このネタ続くなあ、

そして、「初めての人のための Lisp 増補改訂版」を先行販売でげと。

■_ Perl 6

そうか、Parrot のリリースまで一月ないんですね。もう。

Perl 6 Delta Tablet / Perl 6
http://www.perlfoundation.org/perl6/index.cgi?perl_6_delta_tablet

This summary lists things people should be aware of, that change from Perl 5 to 6.

Changes

    * use strict and warnings are on by default

    * consistent sigils: so @array[1] replaces $array[1] and %hash{'key'} replaces $hash{'key'} or @hash{'key', 'key2'}
      一貫した sigils
    * arrays, hashes, formats, directories and filehandles are internal objects with 
      procedural Interfaces and can be saved in scalar variables.
      配列、ハッシュ、format、辞書、ファイルハンドルは procedual インターフェースを持った
      内部オブジェクトであり、スカラー変数に収められるもの
    * special variables have their own namespace ($VARNAME and $?VARNAME), also token (__LINE__) will now be found there
      特殊変数は固有の名前空間を持っている
      __LINE__ というトークンもある
    * Methods: . (dot) replaces -> (arrow) : object.method;
      メソッドの呼び出しはアロー (->) ではなくドット (.) に
    * concatenate strings: ~ (tilde) instead of . (dot): $string = 'Shinmen Musahashi: ' ~ 'Sho Rin No Sho';
      文字列の連結の記号はドット . からチルダ ~ に
    * smartmatch (regex and more): ~~ instead of =~
      スマートマッチ。マッチ演算子は =~ から ~~ に
    * < ... > replaces qw( ... )(exists still): interpolating << ... >>
      qw( ... ) は < ... > に(残ってはいる)
      interpolate するのは  << ... >>
    * ternary operator: ?? ... !! ... instead of ? ... : ...
      三項演算子は ? ... : ... から ?? ... !! に
    * no more 'foreach'. 'for' now iterates only on arrays
      'foreach' はなくなりました。'for' だけ
    * c-style loops: loop ( ; ; ) instead of for ( ; ; )
      C形式のループは for ( ; ; ) から loop ( ; ; ) に
    * after loop flow control: repeat { ... } while ... ; replaces do { ... } while (...);
      後判定形式のループは do { ... } while (...) から repeat { ... } while に
    * define classes with 'class' and modules with 'module'
      クラスの定義は 'class' で、モジュールの定義は 'module' で
    * no more source filters, but macros
      ソースフィルターの代わりにマクロ
    * no more references, bind variables on the symbol table
      リファレンスはなくなりました。シンボルテーブルに束縛される変数

News

    * new contexts: hashlist, lazy list, bool, int, num, string
      新しいコンテキスト
    * optional typing, traits (properties of variables), binding
      optional typing (って何か定訳がありましたっけ?)
      変数の属性である traits 
    * loop and say commands
      loop コマンドと say コマンド
    * zip, err, yadda and pipe operators
    * hyper / reduction operators
      hyper 演算子
      reduction 演算子 (hyper はハイパーとカタカナ書きとして、こっちは?)
    * chained comparison operators
      low < x < high みたいな?
    * case construct with given and when
      given と when を使った case 構造
    * junctions : if $a = 1|2|3
      ジャンクション
    * currying
      カリー化
    * smartmatch / rules (regex++, own sublanguage within the language like in Rebol)
    * named parameters for subroutines, multimethods, coroutines
    * more explicit OOP:
          o autogenerated getters/setters
          o roles (similar to Ruby's Mixins, or Java's Interfaces)
    * delegation, design by contract (Eiffel)
      デレゲート、契約による設計 (Eiffel から)
    * exceptions, continuations
      例外と継続
    * macros
      マクロ

Native Perl 6

    * no parentheses required for control expressions after if, unless, while ... (but still allowed)
    * $hash<key> instead of $hash{'key'}, or $hash<<key>> instead of $hash{"key"}

  

■_ Haskell でコンパイラーを

同様のものが他にもあったような? でそれを追っかけるのを忘れているような。


Let's build a compiler (in Haskell): Part 1 - Introduction at AlephNullPlex

Let's build a compiler (in Haskell): Part 1 - Introduction

posted by Geoff Ford on 12 Jan 2010

When looking for information on getting started with learning how to build an 
interpreter or compiler, inevitably two resources come up. First, the canonical 
compiler resource, the Dragon Book, and second, the noob guide, Let's Build a Compiler 
(LBaC) by Jack W. Crenshaw.

インタープリターやコンパイラーの作り方を学ぼうとしたときにその教材として見つかるのは
cannonical なコンパイラーリソースのドラゴンブックか、
Jack W. Crenshaw による noob ガイドな Let's Build a Compiler (LBaC) があります。

So rather than spending time and money diving into the deep end, I decided to start 
with LBaC. I don't have a CompSci degree so I need to start at the very beginning and 
LBaC seems to fit the bill.

However there was one problem with LBaC:

    This is a "learn-by-doing" series. In the course of the series I will be 
    performing experiments on a computer. You will be expected to follow along, repeating 
    the experiments that I do, and performing some on your own. I will be using Turbo 
    Pascal 4.0 on a PC clone.

Yep, this series was written way back in the 90's when Turbo Pascal was cool. 
Thankfully the theory and basic practices are still relevant.

So why Haskell? なぜ Haskellで?

First and formost because it is my Language of the Year, and considering I have done 
nothing with it in the last 6 months, I owe it to myself to actually start a project 
in Haskell.

Haskellを「今年の言語」に選んだはいいけどここまで六ヶ月(え?)適当なのが見つからなかった
ので、Haskell で行うプロジェクトにいいと思った

Secondly there is extensive tools for more advanced compiler writing such as parsers, 
lexers and LLVM bindings etc.

パーザーやレキサー、LLVM バインディングのような、more advanced なコンパイラーの記述の
助けになるようなツールがあったから。

(略)

Part 2 >
http://alephnullplex.appspot.com/blog/view/2010/01/12/lbach-2-the-cradle

Let's Build a Compiler ねえ。聞き覚えがないような。 これかな? Let's Build a Compiler Let's Build a Compiler: Tiny Kiss in iForth Turbo Pascal の4.0でって。

■_ 本日のム板から


スレを勃てるまでもないC/C++の質問はここで 13
716 sage [] 2010/03/06(土) 13:52:32 ID: Be:
    Perlの変数やJavaのantのような、文字列に埋め込まれた
    「$変数」を解釈するようなC++のライブラリってない? 

717 デフォルトの名無しさん [sage] 2010/03/06(土) 13:54:56 ID: Be:
    まずはboostを調べる。なかったら諦める 

まずは Boost。そうなのか。


C++相談室 part78
606 デフォルトの名無しさん [sage] 2010/03/06(土) 16:54:52 ID: Be:
    abort() if (!p);

    みたいに書けるようにはならんのか。

607 デフォルトの名無しさん [sage] 2010/03/06(土) 17:25:45 ID: Be:
    if (!p) abort() ;  

608 デフォルトの名無しさん [sage] 2010/03/06(土) 17:35:50 ID: Be:
    >>606
    C++などのほかの言語なんかに手を出さず、一生perlを使い続けるべきだと思います。 

609 デフォルトの名無しさん [sage] 2010/03/06(土) 17:42:02 ID: Be:
    perlではif文を後に書くのか? 

610 デフォルトの名無しさん [sage] 2010/03/06(土) 17:56:39 ID: Be:
    >>596
    言語の文法は最小限でライブラリで拡張できるほうがいい。 

611 598 [sage] 2010/03/06(土) 18:17:05 ID: Be:
    すいません嘘です 

612 デフォルトの名無しさん [sage] 2010/03/06(土) 19:54:49 ID: Be:
    abort() if(!p) else exit();
    とか普通に書きたいんじゃないの? 

613 デフォルトの名無しさん [sage] 2010/03/06(土) 19:55:27 ID: Be:
    >609
    文修飾子という扱いで後ろにも置ける。

    if(e) { func(); }
    func() if e;

    は OK だけど、

    if(e) func();
    { func() } if e;

    はできない。 

614 デフォルトの名無しさん [] 2010/03/06(土) 20:00:36 ID: Be:
    >>613
    2種類の書き方があるっていうか、そういうのって分りにくくないのかな?
    後に書くということは
    func(すっげー長い式なんたらかんたらどうのこうの) if e;
    だと読むときifを読み落としそうだなあ。

615 デフォルトの名無しさん [sage] 2010/03/06(土) 20:01:35 ID: Be:
    ワケ分からんw

    C++だと、func() ;も{ func() ; }も、ひとつのstatementなので、ものすごい違和感があるな。
    { func() ; } if e ;
    ができないというのは、ものすごく違和感があるな。 

616 デフォルトの名無しさん [sage] 2010/03/06(土) 20:06:35 ID: Be:
    struct A;
    struct B{ B( A& ); }
    A a(); // これとか
    B b( A() ); //これが
    関数宣言にみなされない書き方ないの?
    A a;
    B b( a );
    とかじゃない方法で。 

617 デフォルトの名無しさん [sage] 2010/03/06(土) 20:09:39 ID: Be:
    >>615
    思うに。
    {
    すげーー長い文
    なんたらかんたら
    だらだらだらだら
    }
    if e;
    って読むのに困るよね。
    do{}while()でも読みにくいのね。 


if 修飾子が else を取れたりしたらカオスな気が。 あ、Python の conditional expression。


【Perl,PHP】LLバトルロワイヤル9【Ruby,Python】
32 デフォルトの名無しさん [] 2010/03/06(土) 01:52:00 ID: Be:
    Pythonは互換性なくなったからもう選択肢に入らない。
    今後もこういうのが将来ありそうなだめ言語は選択肢に入れない。 

33 デフォルトの名無しさん [sage] 2010/03/06(土) 04:56:21 ID: Be:
    ageてまで釣りたいのか
    それならメジャーなLL全部使えないだろ 

34 デフォルトの名無しさん [] 2010/03/06(土) 09:22:32 ID: Be:
    そうだね、個人が仕様を決める安定しない言語は使うべきじゃないね。
    将来に渡ってコード資産が失われるリスクを抱えたくないからね。 

35 デフォルトの名無しさん [sage] 2010/03/06(土) 09:25:31 ID: Be:
    そして「委員会によるデザイン」の罠にはまった言語という罠にはまる、と。 

36 デフォルトの名無しさん [sage] 2010/03/06(土) 09:53:12 ID: Be:
    Ruby 1.9
    Python 3
    Perl 6
    PHP 5.3

37 デフォルトの名無しさん [sage] 2010/03/06(土) 10:00:59 ID: Be:
    >>36
    まるでPerl 6がリリースされてるみたいじゃないか
    もう22世紀になったのか? 

38 デフォルトの名無しさん [sage] 2010/03/06(土) 12:17:27 ID: Be:
    >>35
    名前がインクリメントされてる言語のことですねわかります 

39 デフォルトの名無しさん [] 2010/03/06(土) 13:05:31 ID: Be:
    名前が宝石、生き物の言語は総じて糞 

40 デフォルトの名無しさん [sage] 2010/03/06(土) 15:51:00 ID: Be:
    HaskellとかPascalとかAdaは「生き物」に分類されるんだろうか? 

41 デフォルトの名無しさん [sage] 2010/03/06(土) 19:23:37 ID: Be:
    そりゃ人間が生き物に含まれない道理はない 

36 が挙げてる中で、PHP も 6にした方が他とのバランスが取れるような気がするなあ

■_ 本日の巡回から

■_ 不調

うーむ。一つ二つ訳を仕上げようと思ったが調子が上がらん。

2010年03月05日

■_

つーことで、Visual Studio 2008 Std をぽちっとなしました。 アップグレード版ですが。

■_ 考えてみる

クイズということなので。

melancholic afternoon
http://homepage1.nifty.com/herumi/diary/1003.html#4
3月4日_

指数関数に関わる浮動小数点数のクイズ

次の関数はfmat.hppのexp()に使われているロジックをCで書いたものである. そこに現れる
各定数は何を意味するのか, どういうロジックなのか答えよ(ただし -88 <= x <= 88としてよい
-- そうじゃなければ0か∞なので).
# 本当は並カンの"SIMD パズルの森"で話してみたかったが, あまりにニッチ過ぎる感があっ
#てお蔵入りしたままになってしまった.

unsigned int tbl[1024]; // 実行時に一度だけ初期化される

union fi {
    float f;
    unsigned int i;
};

float expC(float x)
{
    float t = x * 1.4773197e3 + 12582912; // (1)
    fi fi;
    fi.f = t;
    t = x - (t - 12582912) * 6.7690155e-4; // (2)
    unsigned int u = ((fi.i + 130048) >> 10) << 23; // (3)
    fi.i = u | tbl[fi.i & 1023]; // (4)
    return (1 + t) * fi.f; // (5)
}

たとえばx = 1のときは1行目でt = 1.258439e+7, (2)でt = 2.164107e-004, u = 0x40000000, 
tbl = 0x2deeb1となって2.718282を出力する. 同様にx = -4.3ならt = 1.257656e+7, t = -3.215451e-4, 
u=0x3c000000, tbl = 0x5e60f5で0.013569. x = 5.8ならt = 1.259148e+7, t=3.077103e-4, 
u = 0x43800000, tbl=0x251958で330.299591となる. 
  

数値を抜き出してみると

1.4773197e3
12582912
6.7690155e-4
130048
10
23
1023

こんなかんじか。 まずは意味ありげな大きな整数値を十六進表記にすると

>printf "%x" 12582912
c00000
>printf "%x" 130048
1fc00
  

どっちも float の指数部に関係ありそうなパターンが。 23はfloatの mantissa のビット数だろうし、 1023 は double の exponent の大きさっぽいなあ。

■_ また××かっ!

http://blogs.wankuma.com/pizyumi/archive/2010/03/04/186774.aspx
[その他]最近読んだ本

.NETフレームワークのためのC#システムプログラミング―Visual Studio2008対応 ★★☆☆☆

何と言っても、内容の水増し感が凄いです。

(略)

> 本書は、既刊書の『Visual C++ .NETではじめるWin32APIシステムプログラミング』のC#最
新対応版という側面もあり、取り扱う題材も共通する部分があります。双方を比較すれば、プロ
グラミングにおけるC++/Win32APIとC#の差異を理解する一助にもなるでしょう。

手応えのある高度なプログラム例など全くなく、明らかに初心者向けだと思いました。

私にとって少しは有用だった部分は、二章の「DLL」だけです。一章は、「C#の基本」というこ
とでC#に移行してきた人向けの内容だったので読み飛ばしました。三章以降は、(期待して)読
みましたが、マルチスレッドやプロセスについてひたすら基本的な説明とプログラムが載ってい
るだけでした。

それから、誤字脱字はともかく(誤字脱字の多さも異常ですが)、日本語自体おかしい部分が多々
あります。私も場合によってかなり変な日本語を使ったりするので人のことは言えないような気
もしますが、助詞の使い方と品詞感覚が変です。

  

どこの出版社の本だろうと思って調べてみたら… .NETフレームワークのためのC#システムプログラミング Visual Sutudio 2008対応 Amazon.co.jp: .NETフレームワークのためのC#システムプログラミング―Visual Studio2008対応: 北山 洋幸: 本 Amazon.co.jp: .NETフレームワークのためのC#システムプログラミング: 北山 洋幸: 本

あら~、つい最近も話題に上ったScala本の出版社じゃああーりませんか。 でも著者は違うみたいw 2005 版についてるレビューを見るとまあ。

■_ 本日の巡回から

■_


ちんこさんの就活を応援するスレ /a>
345 仕様書無しさん [sage] 2010/02/28(日) 18:16:05 ID: Be:
    きむら(k)さん

    いつか本書いてください、おながいします
    建設的にやって業界を盛り上げていきましょう 

どんな題材で書けと。

2010年03月04日

■_

今週末は買う予定の本がたくさん待っているような気がする。 金が。

■_ 電卓

Windowsのcalcでは違う動きをするようですがそれはさておき。

1 ++ 5 = と入力すると 6と結果が出ると思いますが、 ここから続いて 6 = と入力すると、結果はどうなるでしょうか?

■_ rant

てあんまりいい意味では使わないのだっけ?

http://github.com/candlerb/string19/raw/47b0cba0a2047eca0612b4e24a540f011cf2cac3/soapbox.rb
=begin rant

For me, I absolutely hate all this encoding stuff in ruby 1.9, and I'll try
to explain why here.

* As a programmer, the most important thing for me is to be able to reason
 about the code I write.  Reasoning tells me whether the code I write is
 likely to run, terminate, and give the result I want.

 In ruby 1.8, if I write an expression like "s3 = s1 + s2", where s1 and s2
 are strings, this is easy because it's a one-dimensional space.

              s3     =     s1   +   s2


            ----->       ----->    ----->
            string       string    string

 As long as s1 and s2 are strings, then I know that s3 will be a string,
 consisting of the bytes from s1 followed by the bytes from s2. End of
 story, move to the next line.

 But in ruby 1.9, it becomes a multi-dimensional problem:

              s3     =     s1   +   s2

         enc^         enc^      enc^
            |            |         |
            |            |         |
            +---->       +---->    +---->
            string       string    string

 The number possibilities now explodes. What are the possible encodings
 that s1 might have at this point in the program? What are the possible
 encodings that s2 might have at this point? Are they compatible, or will
 an exception be raised? What encoding will s3 have going forward in the
 next line of the program?

(略)

* It's too stateful. If someone passes you a string, and you need to make
 it compatible with some other string (e.g. to concatenate it), then you
 need to force it's encoding. That's impolite to the caller, as you've
 mutated the object they passed; furthermore, it won't work at all if they
 passed you a frozen string. So to do this properly, you really have to
 dup the string you're being passed, which needlessly copies the entire
 content.

 # ruby 1.8
 def append(str)
   @buf << str
 end

 # ruby 1.9
 def append(str)
   @buf << str.dup.force_encoding("ASCII-8BIT")
 end

However I am quite possibly alone in my opinion.  Whenever this pops up on
ruby-talk, and I speak out against it, there are two or three others who
speak out equally vociferously in favour.  They tell me I am doing the
community a disservice by warning people away from 1.9.  The remainder are
silent, apart from the occasional comment along the lines of "I wish this
encoding stuff was optional."

I will now try very hard to find something positive to say about all this.

* You can write programs to truncate a string to N characters, e.g.

 if str.size > 50
   str = str[0,47] + "..."
 end

 I can only think of one occasion where I've ever had to do this. Maybe
 other people do this all the time.

* You can write regular expressions to match against UTF-8 strings.  Of
 course, ruby 1.8 can do that, by the much simpler approach of tagging the
 regexp as UTF-8, rather than every other string object in the system.

* I can see how it might appeal to be able to write programs in non-Roman
 scripts. Howver this is rather defeated by the fact that constants
 must start with a capital 'A' to 'Z'.

* Erm, that's all I can think of at the moment.
  

とまあ滔々と不満を述べていらっしゃるご様子。 ruby-talk で話を振っても賛成者はいないとかって書いてるけどそうなんか。 面倒に感じるというのはわからんでもないけど、 UTF-8 あればいいだろうというのは @tnozaki さんに小一時間ほど説教していただかないと。

■_ C++ FQA

いかんなあ。とっとと片付けていかないと


C++ FQA Lite: Defective C++

Defective C++

Part of C++ FQA Lite

* No reflection (リフレクションの欠如)

It is impossible to programmatically iterate over the methods or the attributes or the 
base classes of a class in a portable way defined by the C++ standard. Likewise, it is 
impossible to programmatically determine the type of an object (for dynamically 
allocated objects, this can be justified to an extent by performance penalties of RTTI, 
but not for statically allocated globals, and if you could start at the globals, you 
could decipher lots of memory pointed by them). Features of this sort - when a program 
can access the structure of programs, in particular, its own structure - are 
collectively called reflection, and C++ doesn't have it.

あるクラスのメソッドやアトリビュート、あるいはそのベースクラスをC++ の標準で定義されて
いる可搬性のある方法でプログラム的にiterate over することは不可能です。同様に、あるオ
ブジェクトの型をプログラム的に決定することも不可能です。(動的に割り当てられたオブジェ
クトについては、RTTI に伴うパフォーマンス上のペナルティを支払うことでextent のために 
justified することが可能ですしかし静的に割り当ての行われたグローバルなオブジェクトに対
しては使えませんし、また、グローバルオブジェクトから始めることができるのならそこからポ
イントされるメモリの多くを decipher できるかもしれません)。この種の機能は、あるプログ
ラムがプログラムの構造にアクセスできるとき、特に自身の構造に対してアクセスできるときに
collectively にリフレクションと呼ばれるものですが C++ はこれを持っていません。


As mentioned above, this makes generating wrappers for C++ classes and shoveling 
through memory snapshots a pain, but that's a small fraction of the things C++ 
programmers are missing due to this single issue. Wrappers can be useful not only to 
work around the problem of shipping C++ interfaces - you could automatically handle 
things like remote procedure calls, logging method invocations, etc. A very common 
application of reflection is serialization - converting objects to byte sequences and 
vice versa. With reflection, you can handle it for all types of objects with the same 
code - you just iterate over the attributes of compound objects, and only need special 
cases for the basic types. In C++, you must maintain serialization-related code and/or 
data structures for every class involved.

既に述べたように、これは C++ クラスのためのラッパーを生成させます。メモリーのスナップ
ショットを shoveling through することは苦痛ですがしかしそれは、C++ プログラマーがこの 
single issue のために見失ってしまっていることがらの small fraction にすぎません。ラッ
パーは C++ でインターフェースの shipping 問題に対処するだけにとどまらない有用なもので
す。ラッパーによりリモートプロシージャコールやロギングメソッドの起動などのことがらを自
動的に扱うことが可能です。リフレクションの非常に一般的な応用例が、オブジェクトをバイト
列に変換したり逆にバイト列をオブジェクトに変換する操作であるシリアライズです。リフレク
ションを使うことで、同じコードでもって全ての型のオブジェクトに対する処理が可能になりま
す。あなたは単に複合オブジェクトの属性を iterate over して基本的な型に対する特殊なケー
スのみが必要になります。C++ ではシリアライズに関連するコードやデータ構造に関係するコー
ドをあなたがすべての involve されるクラスに対してメンテナンスしなければなりません。



But perhaps we could deal with this problem programmatically then? After all, 
debuggers do manage to display objects somehow - the debug information, emitted in the 
format supported by your tool chain, describes the members of classes and their 
offsets from the object base pointer and all that sort of meta-data. If we're stuck 
with C++, perhaps we could parse this information and thus have non-standard, but 
working reflection? Several things make this pretty hard - not all compilers can 
produce debug information and optimize the program aggressively enough for a release 
build, not all debug information formats are documented, and then in C++, we have a...


しかしこの問題にプログラム的に対処することはわたしたちには可能なのでしょうか?結局のと
ころオブジェクトなどを表示するためにデバッガーは管理しているものがあるのです。デバッグ
情報、あなたの使っているツールチェイン (tool chain) がサポートしているフォーマットで
emit されたもの、クラスのメンバーの describes とオブジェクトのベースポインターからのメ
ンバーに対するオフセット、そしてメタデータの類のすべてといったものです。もしわたしたち
が C++ に stuck するのなら、おそらくわたしたちはこの情報を解析可能でしょうが、それは当
然標準から外れるということです。それでリフレクションは動作するのでしょうか?いくつかの
事象がこれをとても難しくしています、すべてのコンパイラーがデバッグ情報を生成しつつプロ
グラムをリリースビルドにも充分なほどアグレッシブにオプティマイズできるわけではありませ
んし、すべてのデバッグ情報のフォーマットがドキュメント化されているわけではありません。

そして C++ でわたしたちが持っているものといえば…

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

■_今日の知らなかった

ボタン型電池 - Wikipedia
http://ja.wikipedia.org/wiki/%E3%83%9C%E3%82%BF%E3%83%B3%E5%9E%8B%E9%9B%BB%E6%B1%A0

ボタン型電池の規格は、LR44、CR2032などと表される。

最初に数字が付くことがあるが、これは電池の積層数(内部で直列につながっている電池の数)を表す。

次は電池系(化学構造)で、ボタン電池に使われるのは次のとおり。

          記号      電池系                         陽極          電解液             負極        公称電圧
一次電池    B       フッ化黒鉛リチウム電池      フッ化黒鉛      非水系有機電解液    リチウム      3.0
            C       二酸化マンガンリチウム電池  二酸化マンガン  非水系有機電解液    リチウム      3.0
            G       酸化銅リチウム電池          酸化銅(II)      非水系有機電解液    リチウム      1.5
            L       アルカリ電池                二酸化マンガン  アルカリ水溶液      亜鉛          1.5
            P       空気亜鉛電池                酸素            アルカリ水溶液      亜鉛          1.4
            S       酸化銀電池                  酸化銀          アルカリ水溶液      亜鉛          1.55
二次電池    H       ニッケル水素電池            ニッケル酸化物  アルカリ水溶液      水素吸蔵合金  1.2

次は形状で、ボタン型電池では常にR (円形)である。

最後は寸法を表す。CR2032では、20は直径20 mm、32は厚さ3.2mm(0.1 mm単位)である。

 

あのアルファベットや数字にそんな意味があったなんて!

■_ 本日の巡回から

2010年03月03日

■_

最終講義行きたかったでござる ○| ̄|_

あー、サマーウォーズのBD限定版、いちまんえんだったか。 予約したのを取りに行くけどうみみ。

■_

なんか、Java, Love, Hate あたりの単語がちりばめられたお題をここ数日よく見かける気がする…


Proggit: Why Do People Hate Java? : programming

from where i'm sitting, Java seems to be falling out of favor in the programming 
community. indeed, most people seem to be developing a strong negative attitude to the 
language, the intensity of which surprises me. why is this?

わたしが座っている場所からは、Java はプログラミングコミュニティにおける人気が落ちてし
まっているように見受けられます。確かに、ほとんどの人はこの言語に対してとてもネガティブ
な態度を取っているようですが、それはわたしにとって驚きでした。一体なぜなんでしょうか?

is it the language itself? personally, i like Java, and i find that it lets me write 
good software quickly and easily. what do you guys think? do the missing features -- 
for example, first-class functions and lambdas -- get in your way? do you just hate 
explicit typing, or static typing in general?

言語そのものが原因でしょうか? わたし個人の話をすれば、Java が好きですし、この言語はわ
たしに良いソフトウェアを素早く簡単に書かせてくれるものだということに気がつきました。あ
なた方が考える理由はどんなものですか? たとえばファーストクラスの関数やラムダがないとい
った機能の欠如でしょうか? あるいは、型を明示するのが嫌いなのでしょうか? それとも静的型
付けそのものが嫌いだったりするんでしょうか?

or is it the jobs available with Java? most Java jobs involve working in a 
soul-sucking corporate environment, with other programmers who don't know what they're 
doing, for an "architect" who's pedantic and overpaid.

そうではなくて、Javaで得られる仕事に問題があるのでしょうか?
Javaでの仕事の大部分は soul-sucking corporate environment で、
自分が何をしているのかすら分かっていないプログラマーと一緒に
知ったかで給料ぼりすぎの“アーキテクト様”のためにするような仕事だから
でしょうか?

either (or another!) answer is valid, but i'm interested to know why Java seems to be 
falling out of vogue. if it's the language, that's fair, but i want to understand why; 
if it's the environment, that sucks, but it doesn't seem fair to condemn a whole 
language because of the way it's used.

いずれの答え(あるいはさらに別の答えでも)であってもそれは正当なものでしょう。
でもわたしは、なぜ Java が流行遅れ(falling out of vogue) になってしまったように
見えるのかを知りたいのです。それが言語によるものであれば
fair ですが、わたしはなぜそうなのかを理解したいのです。
環境に問題があるのなら、それは sucks ですが、
使われ方に理由があるのであって言語そのものは無罪であるように思えるのです。

例によって超訳全開ですのでその辺よろしゅう。

現在800個近くレスがついてますが正直もう追えないw

■_ふむ

Joel Spolsky On Why He Is Quitting Blogging : programming

How Hard Could It Be? By Joel Spolsky: Let's Take This Offline
Let's Take This Offline

A decade ago, I started Joel on Software, a blog that put my company on the map. But 
as the business matures, I've come to realize that blogging is holding me back.

You've started a business. You've built a great product. Now you're trying to get the 
word out. You don't have the budget to buy ads or to retain a PR agency. You'd like to 
hire a salesperson, but the experienced salespeople are smart enough not to work for 
you.

Well, there's always blogging.

(略)

My hope is that giving up blogging and the rest of it will be the equivalent of making 
a cross-eyed kid wear an eye patch on his good eye for a while: The weaker eye will 
grow stronger. My company needs to get better at what every other company already 
knows -- how to promote and market products without depending on one single channel. 
We've completely saturated a small slice of the target market, and now we have to go 
after a much larger group of potential customers.

To my readers: Thank you for your attention over the past 10 years. I couldn't have 
done it without you, and the nice e-mails, comments, tweets, and blog replies have 
made it a joyous journey. I enjoyed meeting you virtually, and I look forward to 
meeting many of you in person in the next phase of my company's life.

■_ Actors are not a good concurrency model

Twitter / tama: 長いので誰か訳して>< http://pchiusa ... というついっとがあったので。


Prettt-tty, pretty, pretty good!: Actors are not a good concurrency model

Actors are not a good concurrency model
(アクターは並列性の良いモデルではない)

Posted by Paul Chiusano on Friday, January 15, 2010

Actors are not a good concurrency model, and neither are Erlang processes.

アクターは並列性モデルとしても、Erlang のプロセスとしても良いものではない。


Wait, what? Isn't Erlang the king of high-uptime distributed systems? If Erlang can do 
all this using the actor model (Erlang processes are identical to actors in the 
essential ways, discussed below), isn't there something good about it? Isn't there??

待ってください。なんですって? Erlang は high-uptime な分散システムの王様(king of 
high-uptime distributed systems) ではなかったのですか?アクターモデルを使ってできること
はすべて Erlang で行えるということなのに (Erlang のプロセスは本質的な意味ではアクター
と同一のものです。後で論じます)、良くない点が何かあったりするのでしょうか?


Well, yes. What's good about it is it's better than the dinosaur era alternative of 
shared-state preemptive multithreading. But so what? Just because the actor model is 
better than dinosaur era technology doesn't mean we should keep using it. Remember the 
rise of OO? Before OO, the alternative was programming in languages like C, with 
pretty much zero support for polymorphism. Any approach to polymorphism was better 
than nothing at all, so OO's concepts of classes and subtyping was a huge improvement 
(my opinion is that polymorphism was the real unfilled niche that OO filled). Now that 
we've learned a bit more, OO has started to seem less appealing to some - parametric 
polymorphism exists independent of OOP, and bounded polymorphism can be implemented 
with either typeclasses or a combination of first-class and higher-order modules. It's 
possible there are some other ideas from OO worth salvaging, but more likely I think 
OO is just an evolutionary dead-end.

ええ、存在します。Erlang が良い (good) というのは、状態を共有するプリエンプティブなマ
ルチスレッディング (shared-state preemptive multithreading) の恐竜時代の代替技術よりは
良いということです。でもそれがどうかしたのでしょうか? 単にアクターモデルが恐竜時代のテ
クノロジーよりも良かっただけということは、わたしたちがそれを使い続けなければならない理
由にはなりません。オブジェクト指向の勃興期のことを思い出せますか? オブジェクト指向以前
には、代替技術といえば C のようなポリモーフィズムのサポートが全くといっていいほど皆無
な言語で行うプログラミングでした。ポリモーフィズムに対するどんなサポートも全くないより
はマシであって、特にオブジェクト指向のクラスやサブクラス化というコンセプトは大きな改良
であったのです(わたしの意見ではポリモーフィズムはオブジェクト指向が実際には埋めきって
いなかったニッチな領域です)。


現在までにわたしたちはさらに学びました。オブジェクト指向は一部の人に対してはあまりアピ
ールしないものとして始まりました。parametric なポリモーフィズムはオブジェクト指向プロ
グラミングとは独立して存在していましたし、そして束縛されたポリモーフィズムはtypeclass 
によっても、ファーストクラスのモジュールと高階モジュールの組み合わせによっても実装可能
です。オブジェクト指向の worth salvaging (価値のサルベージ?) からきた別のアイデアをいく
つか挙げられます。しかしわたしが考えているのは、オブジェクト指向は単なる進化の行き止ま
り (evolutionary dead-end) にすぎないということです。


And so it might be with actors. Though I don't know exactly what the replacement looks 
like yet (I'd like to look at some alternatives and explore ideas in a future post), I 
do know what's wrong with actors, and that's what I'd like to explore here. But going 
further, I'd like to use actors as an example to show what's also problematic with 
side effects and impure functions in general. In doing so I'll try to avoid the usual 
FP evangelizing and make this a more precise, technical argument.

そしてそれはアクターにも言えるかもしれないのです。わたしはそれを置き換えるものがどんな
のものなのかを未だに正確に知らないのですが
(I'd like to look at some alternatives and explore ideas in a future post)、
将来のポストでいくつかの代替物を見たりアイデアを探したいと思っています。
わたしはアクターの何が悪いかのを知っていますし、これからここで調査することです。
But going further,
わたしは、副作用や一般的に純粋でない関数 (impure functions) も同様に問題であることを示
す例としてアクターを使いたいと考えています。そういったことを行うことでわたしはよくある 
FP evangeliging (関数プログラミングの伝道者?) の排除を試み、そしてこれをより precise 
で技術的な主張にしたいのです。


So what's wrong with actors? The problem which dooms the actor model is that actors 
are fundamentally not composable. I'm going to leave that term undefined for now, 
except to say vaguely that entities are composable if we can easily and generally 
combine their behaviors in some way without having to modify the entities being 
combined. I think of composability as being the key ingredient necessary for acheiving 
reuse, and for achieving a combinatorial expansion of what is succinctly expressible 
in a programming model. (Also see this explanation by Tony Morris.) It goes without 
saying that code reusability is a very desireable property for programs to have, and 
many of the other virtues of good software engineering end up tying back to 
reusability - for instance, testability is nothing more than the ability to reuse a 
component in the context of a test.

それで、アクターの何が間違っているというのでしょうか?アクターモデルに判決を下している 
(dooms) 問題点とはアクターが根本的に composable なものでないというものです。わたしは現
時点で未定義の用語はわたしたちが容易に、かつ、一般的にそれらの振る舞いを結合すべきエン
ティティを修正する必要なしに何らかの方法で結合するのが容易にできるのであればエンティテ
ィが composable であるという冗長な言い回しを除いてはそのままにしておきたいと考えていま
す。わたしは composability を再利用を促進するために必要なキーとなる要素のように考えて
いて、そして combinatorial expansion を促進することがあるプログラミングモデルをずばり
表現すると考えています (Also see this explanation by Tony Morris.)。

#ingredient 成分、構成要素
#succinctly ぴったりな、ずばりの

コードの再利用性はプログラムが持っているべき非常に desireable な属性であることは言を待
たず、かつ、その他の virtues of good software engineering の多くは結局は再利用性に 
tying back するのです。たとえば testability とはテストのコンテキストにおけるコンポーネ
ント再利用のための能力にすぎません。


So what makes actors not composable? Well, an actor (and an Erlang process) is 
constructed from a function A => Unit. That this function returns Unit rather than a 
meaningful type means that it must hardcode some action to take once the result (whose 
type is not even shown) is available. It is this unfortunate property that destroys 
any chance we have at combining actors in any sort of general way like we would in a 
typical combinator library.

ではアクターを composable にさせていないものとは何なのでしょうか? さて、あるアクター 
(や、ある Erlang プロセス) がfunction A => Unit によって構築されます。この関数は 
(whose type is not even shown な) 結果を取得するためのなんらかのアクションをハードコー
ドしなければならない meaningful な 型ではなく、Unit を返します。それは、わたしたちがよ
くあるコンビネーターライブラリでやるような一般的な手法でアクターを結合するときにわたし
たちが持っているすべての機会を破壊してしまうこの unfortunate な属性なのです。
#わかんねー

As a simple example, consider the following two actors: 1) an actor that accepts lists 
of integers and turns the list into a min-heap. 2) An actor that accepts (heap,k) 
pairs and extracts the top k elements in order from the given heap. Can we write a 
function that accepts these two actors and returns an actor which accepts (list,k) 
pairs and pulls out the k minimum elements in sorted order? And generalizing a bit, 
can we write the more general combining function, the one that doesn't care whether 
the types are 'heap', 'int' and 'list' or A, B or C?

単純な例として、以下の二つのアクターで考えてみましょう:

1) 整数のリストを受付けてそのリストを min-heap へ変換するアクター
2) (heap, k) というペアを受付け与えられた heap から順番に最初の k 要素を extracts するアクター

これら二つのアクターを受理し、 (list, k) というペアを受け取ってそこからソートされた順序
で最小値から k 個の要素を取り出すアクターを返す関数をわたしたちは記述できる
でしょうか? また、さらにもう少し一般化して、型が 'heap', 'int' and 'list' なのか A, B or 
C のいずれなのかを気にしないような、より一般的な結合関数 (combining function) を書ける
でしょうか?

You just can't do this with actors since you can't make any assumptions about what the 
actor will do with the result - it might forward it to some other actor, write it to a 
file, extract from it the missile launch codes and launch the missile, etc. In fact, 
if you actually try to achieve the composability I'm talking about using actors, what 
you end up doing is having all actors return their result as a response to their 
sender, essentially recreating pure functions within the actor model, badly, losing 
type information in the process. What this should tell you is that actors, if worth 
anything, might be useful more as a tool for building some other higher-level 
abstraction. But if that's the case, perhaps we shouldn't even expose actors as a 
programming model and instead just program directly in the higher-level model.

あなたはこれを単にアクターを使っては行えません。なぜならアクターがその結果に対して何を
行うのかということについて一切の仮定ができないからです。あるアクターが他の、ファイルへ
書き込みするようなアクターに向けて forward してそこからミサイル発射のコードを取り出し、
ミサイルを発射してしまうといったことをするかもしれません。もしあなたが本当に 
composability を achievie しようと試みるのならわたしはアクターの使用についてお話しまし
ょう。すべてのアクターがその結果を自分の sender に対する response として返すということ
は本質的にはアクターモデルの中で pure functions を再生成することであり、それによって困
ったことにプロセスにおける型情報を失ってしまうのです。これがあなたに伝えるべきことは、
if worth anything, アクターが何かほかの高水準の抽象を構築するツールとしてよりも有用かも
しれないということです。しかしそういった場合であっても、わたしたちはおそらく高水準のモ
デルによって直接プログラムする代わりにプログラミングモデルとしてアクターをさらす
(expose) ことすらすべきではないのです。


In practice, I suspect actors are basically only used at the top level of a program, 
where the damage to composability is minimized, and pure functions (which are 
composable and work fine at any level of the program) are used to everywhere else to 
achieve reuse. The problem with this approach is when you find out a few months later 
that what you thought was going to be the top level of your program actually is going 
to become a very small embedded component in some larger system, and this top level 
now contains a large amount of unreusable complex logic that must be gutted to work as 
an embedded component.

実際のところは、基本的にアクターは composability に対するダメージが最小化される場所が
プログラムのトップレベルでしか使われないだろうとわたしは推測しています。また、再利用を 
achieve するところ以外でもあらゆる場所で(composable で、プログラムの任意のレベルで 
work fine な)
 pure 関数が使われるだろうと考えています。このアプローチについての問題は、あなたが自分
のプログラムのトップレベルになるだろうと考えたものが実際にはなにか大きなシステムに埋め
込まれた非常に小さなコンポーネントになってしまっていることに数ヵ月後に気がついたときに、
このトップレベルが埋め込みコンポーネント (embedded component) として動作するために 
gutted されなければならない再利用不可能な複雑なロジックの大きな塊からなっているという
ことです。

The problem I am talking about here is not in any way specific to actors. It applies 
to any functions with side effects. I claim the only way to achieve true composability 
is to program with pure functions, and this applies to concurrent programs or to any 
other programs you'd like to write. (Sometimes, you decide it's worth taking the 
composability hit and you write functions with side effects - of course I don't object 
to this in absolutely all cases - but I don't think the fundamental model underlying 
concurrent and distributed programming should have to take this hit.)

わたしがここで述べている問題はアクターに特有のものではなく、副作用を伴うすべての関数に
適用されます。true composability を獲得するための唯一の方法はpure functions を使
ってプログラムすることであり、これを並列プログラムやその他あなたが書きたいと考
えているプログラムに対して適用することであるとわたしは主張します(ときには、taking 
the composability hit して副作用を伴う関数を書くことが worth であるとあなたは決定する
ことがあるでしょう。もちろんわたしはすべてのケースにおいてそうした決定に反対するわけで
はありませんが、しかし concurrent programming (並列プログラミング) や distributed programming
(分散プログラミング) の基礎をなす 
fundamental model を take this hit すべきであるとはわたしは考えません)。

What makes pure functions composable is they are only the logic of the computation. A 
pure function makes no decisions about what actions to take with the result of the 
computation, and also makes no decisions about what actions to take before the 
computation is executed. By keeping these concerns separate, we can reuse the function 
elsewhere in places where we need to do something different with the result, or where 
we need to do something different before the computation is executed (for instance, in 
testing, to generate an instance of the input type rather than obtaining the input 
from some impure function).

純粋な関数を composable にするものは computation のロジックなもののみです。純粋な関数
は結果を計算するために取るアクションに関して意思決定をしません (makes no decisions)。
また計算を実行する前にとるべきアクションについての意思決定もしません。これらの 
concerns を分割したままにしておくことによって、わたしたちは結果を得るために何か異なっ
たことをしなければならない場所や、あるいは(たとえばテストにおいて、なにか impure な関
数から入力を得るのではなく入力型のインスタンスを生成するために)計算を実行する前に何か
違ったことをしておく必要がある場所以外での関数の再利用が可能になります。

In fact, you can think of any impure function as having three "steps": 1) An 
"input" side effect, Unit => B, a pure function (A,B) => C, and an 
"output" side effect C => Unit. It makes perfect software engineering sense 
to decouple these components - and that is exactly what is done in purely functional 
programming.

実際、あなたは任意の impure な関数を
三つの“ステップ”を持つものとして考えることができます:

1) An "input" side effect,
Unit => B,
a pure function (A,B) => C,
and an "output" side effect C => Unit.

このステップはこれらのコンポーネントを decouple するための perfect software engineering 
sense を make します。そしてそれは厳密に純粋な関数プログラミング (purely functional 
programming) で行われることなのです。


Let's look at a very simple example. Suppose I write a sort function, which sorts the 
input list in place. For this function, we have no input side effects. The pure core 
of this function is (conceptually) a sorting function that returns a new list. What is 
the output side effect? It is to rebind the name that the input list is bound to in 
the caller to the sorted version of the list. So if the caller were something like

では非常に単純な例を見てみましょう。ここで入力リストをその場 (in place) でソートする 
sort 関数をわたしが書いたと仮定しましょう。この関数に対する入力では一切の副作用はあり
ません。この関数の pure core は、(コンセプトとしては) ソートを行い新しいリストを返す関
数です。出力の副作用とはなんでしょうか?それは呼び出し元で束縛された入力リストをそのリ
ストをソートした結果への束縛にするという名前の再束縛です。ですから呼び出し元で次のよう
にしていると

def foo(list: ArrayList[Int]): Foo = { 
  ...
  sort(list)
  ...
}

then sort will rebind the name list to the sorted version of that list. Since list is 
itself a parameter of foo, this rebinding will occur in the caller of foo, and 
possibly its caller, all the way out to the place where that list was originally 
declared. The question is, should the sort function really be making the decision 
about whether to do this? If we let the sort function make this decision, we're 
allowing it to make an assumption about the caller, namely, that the caller no longer 
intends to maintain references to the unsorted version of the list (an assumption 
which, incidentally, is not even tracked by the type system).

そして sort はその名前のリストをリストのソート済みバージョンで再束縛します。リストそれ
自身が foo に対するパラメーターであるのでこの再束縛は foo の呼び出し元で発生しますが、
更に呼び出し元の呼び出し元からそのリストが宣言された大元までに経由されるすべての関数で
も再束縛の可能性があります。疑問となるのはつまり、この sort 関数は本当にこの再束縛を行
うか否かの意思決定をすべきなのか? ということです。もしわたしたちが sort 関数に再束縛の 
decision をさせるようにすればわたしたちは呼び出し元について仮定するのを許すことになり
ます。つまり、呼び出し元はもはやソートされていないリストに対する参照を保持しつづけなく
てもよくなります(型システムによって追跡されていないことを仮定しています)。


Of course, this example of an in-place sort isn't too terrible. The caller just needs 
to be aware of this side effect and has to adjust its calling convention accordingly. 
But the lack of uniformity in chaining and combining logic caused by side effects 
starts to add up very quickly. In practice, what actually occurs in large systems with 
impure functions sprinkled about is that many functions end up with so many 
assumptions about their callers (and these assumptions propagate to their callers, as 
above) that the call graph becomes very static, with functions often having only a 
single or small number of callers. This makes the system a lot more rigid, more 
difficult to test without elaborate mocking and dependency injection frameworks (which 
brings with it its own set of problems), and results in a lot of (often hidden) 
duplication of logic.


もちろん、この in-place sort はそれほど terrible な例ではありません。呼び出し側はただ
単にこの副作用に注意して、その呼び出し規約 (calling convention) に従って adjust する必
要があるだけです。しかし副作用によって引き起こされる連鎖したロジックや結合したロジック
における uniformity の欠如が add up very quickly のために start します。impure 
functions が impure を撒き散らす (sprinkled) ことで大規模システムで実際に起きることは、
多くの関数が自身の呼び出し元 (callers) についての想定を多く持つようになって(そしてこれ
らの想定は前述したようにその呼び出し元に伝播 (propagate)します)、呼び出しグラフがしば
しば一つ乃至極少数の呼び出し元だけを持つ非常に静的 (very static)なものになるというもの
です。このことはシステムをより一層 rigid (強固) にし、依存性注入フレームワーク 
(dependency injection frameworks)を抜きにしたテストをさらに困難にします(which brings 
with it its own set of problems)。そしてその結果としてたくさんの (ほとんどの場合は隠れ
た)ロジックの重複が発生することになります。


Other simple examples show more obvious destruction of composability. If I write a 
function that reads a bunch of things from a file and then performs some complex logic, 
we can't easily reuse that logic elsewhere (unless we want to populate a file first, 
which may not be what we want). If a function performs some complex logic and then 
launches the missile, we can't easily reuse that complex logic elsewhere in places 
where we don't want to launch the missile.

別の単純な例でもっとはっきりと composability の破壊をお見せしましょう。もしわたしが、
ファイルから bunch of things を読み込んで、それからちょっとした複雑なロジックを実行す
る関数を記述したと仮定すると、わたしたちがそのロジックを他の場所で再利用するのは容易で
はありません
(unless we want to populate a file first, which may not be what we want)。
もしある関数が複雑なロジックを実行したあとでミサイルを発射するものであれば、
その複雑なロジックはミサイルの発射を行わないどこか他の場所でなければ
わたしたちが簡単に再利用することはできません。


Taking a step back from all this bashing of actors and side effects, I do certainly 
agree that actors and side effects in general have a certain "intuitive" 
appeal, a rough analog to how the real world works. But that does not justify their 
usage as a programming model. The technical challenges of engineering large pieces of 
software mean that a good programming model may have to tradeoff intuitiveness for 
attributes like composability. But I suspect even this tradeoff is overplayed - 
intuitiveness is also often code language for "what system I am familiar 
with". Once you learn and internalize a different model your ability to reason 
within that model (and thus, I believe, its intuitiveness) is more a function of the 
features and formal structure of that model than of some inherent 
"intuitiveness" metric.


アクターや副作用に対するこの種のバッシングから一歩引いてみれば、わたしはアクターや副作
用が一般的には明らかな "intuitive" appeal (直感的なアピール?)を持っていて、
現実世界がどのように動いているかの大まかか相似形 (rough analog) であるということにはっ
きりと賛成します。しかしプログラミングモデルとしてそれらの使われ方は調整 (justify) さ
れてはいません。ソフトウェアの large pieces に対するエンジニアリングについての技術的な 
challenges は、良いプログラミングモデルがcomposability のような属性 (attributes) に対
する tradeoff intuitiveness を持たなければならないかもしれないことを意味します。
#intuitiveness 直観
しかしわたしはこのトレードオフすら overplayed であると推測しているのです。
intuitiveness もまたしばしば "what system I am familiar with" (わたしが慣れ
親しんでいるシステム)に対する code language となります。一度異なるモデルの学習と その 
internalize (内在化、自分のものにする)とをすれば、あなたの ability to reason within 
that model (そのようなモデルの中にある理由に対する能力… わからん) (and thus, I 
believe, its intuitiveness) はsome inherent "intuitiveness" metric の機能と
いうよりむしろfeatures and formal structure of that model の機能なのです。

■_ 本日の巡回から

2010年03月02日

■_

・R
久しぶりにいじったら、かなり忘れててしょんぼりんぐ。 関数定義どうやんだっけとしばし悩んでしまった ○| ̄|_

伸びたなあ Debian refuses to package the embedded PHP library. Reason ? "it's a rotten language whose use should not be encouraged". WTF ? : programming

■_ 順調だなあ

もう 2.6.5 か。

Python 2.6.5 release candidate 1
http://www.python.org/download/releases/2.6.5/

Python 2.6.5 is a maintenance release for Python 2.6.4, fixing dozens of issues in the 
core, builtin modules, libraries, and documentation. This is not a final release; it 
is the first release candidate for 2.6.5. Python 2.6.5 final is currently scheduled 
for March 15, 2010.

Python 2.6 is now in bugfix-only mode; no new features are being added. The NEWS file 
lists every change in each alpha, beta, and release candidate of Python 2.6.

       * What's New in Python 2.6.
       * Report bugs at http://bugs.python.org.
       * Read the Python license.
       * PEP 361 set out the development schedule for 2.6.

Help fund Python and its community by donating to the Python Software Foundation.
  

■_ エンジンの能力が違うような

GNU regex の使い方教えれというお悩み。

Working with GNU regex functions in C or C++ - Stack Overflow
http://stackoverflow.com/questions/2359811/working-gnu-regex-functions-in-c


Can anyone give me complete example program how to work with GNU regex functions in 
gcc C or C++ (http://docs.freebsd.org/info/regex/regex.info.GNU_Regex_Functions.html), 
with re_pattern_buffer, re_compile_fastmap?

For example, translate this small Python program:

import re
unlucky = re.compile('1\d*?3')

nums = ("13", "31", "777", "10003")

for n in nums:
   if unlucky.search(n) is None:
       print "lucky"
   else:
       print "unlucky"

Thanks!"

でもまあ、知らない人には結構わかりづらいかな。あのインターフェース。 とはいえ検索すればつかっているソースコードはいくらでも見つかりそうなもんだけどね。

■_ stable stable

mixi で同じ質問を見かけたような記憶があるけど。


awk / sed のテキスト処理について - Coding Edge会議室

はじめまして。質問させていただきます。
09:00 1
10:00 2
11:00 3
12:00 4
13:00 5
・・
・・
・・
09:00 11
10:00 12
11:00 13
12:00 14
13:00 15
・・
・・
・・
09:00 21
10:00 22
11:00 23
12:00 24
13:00 25
・・
・・
・・

という風に、毎日指定していした時間に値が取れているファイルを
09:00 1 11 21
10:00 2 12 22
11:00 3 13 23
12:00 4 14 24
13:00 5 15 25
・
・
・

という風にx軸方向に日付、Y軸方向に時刻という風に編集したいと思います。
エディタで等間隔(09:00からその日の最後まで)に矩形選択、最初の行の
行末に貼り付けをするイメージです。
これをExcelでグラフで取込、x軸に時間、y軸に値を示す
日毎の折れ線グラフを作成したいのですが
なかなかてこずっており苦慮しております。
sed/awkに限らず、
効果的な手法がありましたらご教授の程お願いします。
かなり適当ですが、ファイルがとりあえず一つ(sample.log)だとして、


sort -k1 -nk2 sample.log | awk -f a.awk



a.awkが


time != $1{
	print time, p
	time = $1
	p = ""
}

time == $1{
	p = p " " $2
}

END{
	print time, p
}


みたいな。
ロジックが良いか分かりませんが、以下はどうでしょう?
cat sample.log | awk -f test.awk

test.awk
-------
BEGIN{
    j=1
}
{
    k=0
    for ( i = 1 ; i < j; i++){
        if( array[i] == $1 ){
            k = i
        }
    }
    if ( k == 0 ) {
       array[j] = $1
       value[j] = value[j] " " $2
       j = j + 1
    }else{
       value[k] = value[k] " " $2
    }
}
END{
    for ( i = 1; i <= j; i++){
        print array[i], value[i]
    }
}

一つ目のは、sort コマンドが stable ソートするとは限らないからだめじゃないかなあ。 一見うまくいったように見えて、使っていくうちに不具合に気づくとか。 二つ目もなんかごちゃごちゃやってるという印象が。

ほかのコマンド使っていいのなら、$1 を連想配列のキーにしておいて その値に文字列を足しこんでいけばいいんじゃないかなあ。 順番は出力を sort に食わせてお任せ(笑)

きっと、さいとうさんがきっちりしたのを書いてくれるに違いない :)

■_

reddit だか stackoverflow 経由で


gist: 319075 - GitHub

/* gcc -o nostdlib nostdlib.c -m32 -z execstack -nostdlib */
/* Who needs libc or asm() when you can abuse the ABI in horrible ways?*/
typedef int (*sc_fun)(int,int,int,int,int,int,int);
 
void _start(void) {
    char syscall[] = "\x60\x83\xc4\x24\x58\x5b\x59\x5a\x5e\x5f\x5d\xcd\x80\x83\xec\x40\x61\xc3";
 
    ((sc_fun)syscall)(4, 0, "Hello, World\n", 13, 0, 0, 0);
    ((sc_fun)syscall)(1, 0, 0, 0, 0, 0, 0);
}
 
  

これは(笑)

■_ 本日の巡回から

■_

ちと急ぎで訳しているのがあるんだけど、まだ終わんなかった。 あともうちょいなのに ○| ̄|_

2010年03月01日

■_

行って逃げて。で三月。

■_ 実は昨日からでした


ビブ: つらつらぐさ

#それにしても、いつの間にサイトタイトルを変えられたのだろう? 気づかずにいましたよ。

3/1 未明のアップロード分から変わってます。 ただし、permanent の方は3月上旬分からの変更です。 もうちょっとうまいのを出したかったんですが。

■_ PHPって

本当にいぢめられっこなのねw Debian refuses to package the embedded PHP library. Reason ? "it's a rotten language whose use should not be encouraged". WTF ? : programming すでに 600オーバーのコメントが。


Debian refuses to package the embedded PHP library. Reason ? "it's a rotten language whose use should not be encouraged". WTF ? : programming

Debian refuses to package the embedded PHP library. Reason ? "it's a rotten 
language whose use should not be encouraged". WTF ? (bugs.debian.org)


    While I support the idea that PHP is a hideous language that should never be used, 
    I do not support the idea that your role as maintainers should allow you to refuse to 
    package something for what is essentially a religious reason.

Not just funny, lol funny.
Because everyone else just wants to bash PHP in this thread, here's better 
justification.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380731#50

    there's also the unfortunate reality that as it stands now the maintainers for for 
    php are few and already overcommitted

    given the short time frame and the focus of our limited efforts is to get 5.3 
transitioned to testing before the freeze.

Pretty clear. Of course the other comments in that bug report are getting more 
attention because they're more "controversial", I'd expect nothing less from 
the Debian maintainers.

#380731 - php5: Embedded PHP interpreter missing - Debian Bug report logs

(略)

Message #45 received at 380731@bugs.debian.org (full text, mbox):


Hi Ondřej,

On Tue, Feb 9, 2010 at 12:06 AM, Ondřej Surý <ondrej@debian.org> wrote:
> Nope, and I doubt there ever will be. I guess we all (php maintainers)
> share Steve's opinion on embedding php5. It's bad enough with php5
> today, no need to make it worse by plugging language create to server
> web pages to another random applications. If you need to embed
> scripting language, use something more suited for the task - lua comes
> to the mind.

While I support the idea that PHP is a hideous language that should
never be used, I do not support the idea that your role as maintainers
should allow you to refuse to package something for what is
essentially a religious reason.

Steve's comment about it being experimental is also incorrect, despite
the file he quoted, which is out of date. The embed APIs have not
changed at all in the four years this bug has been open, it is as
stable and mature as anything else in PHP. I think this argument is
only being used as a strawman to support what has already been decided
based on religious reasons.


Thanks,
Paul
(以下略)

PHP is a hideous language that should never be used, PHP は決して使うべきではないひどく醜い言語て。

■_ 本日の巡回から


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

ホームへ


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

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