ときどきの雑記帖 i戦士篇

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

一つ前へ 2009年1月(下旬)
一つ後へ 2009年2月(中旬)

ホームへ

2009年02月10日

■_

・購入
モダンPerlはあったがCの方はみつからず(って発売予定は休み明けか)。

■_ 見ていてイライラするプログラミングスタイル (stackoverlow: Most frustrating programming style you've encountered)

Most frustrating programming style you've encountered - Stack Overflow
Most frustrating programming style you’ve encountered

When it comes to coding style I'm a pretty relaxed programmer. I'm not firmly dug into 
a particular coding style. I'd prefer a consistent overall style in a large code base 
but I'm not going to sweat every little detail of how the code is formatted.

Still there are some coding styles that drive me crazy. No matter what I can't look at 
examples of these styles without reaching for a VIM buffer to "fix" the 
"problem". I can't help it. It's not even wrong, I just can't look at it for 
some reason.

For instance the following comment style almost completely prevents me from actually 
being able to read the code.

たとえば次のようなコメントのつけ方は、ほんとーっに自分がコードを読むときの邪魔に
しかならない。

if (someConditional) 
// Comment goes here
{
  other code
}

What's the most frustrating style you've encountered?
あなたがこれまでに遭遇した最もフラストレーションが溜まったスタイルってどんなのですか?

Interestingly enough, that's

if (0 == foo()) {}

i.e. putting the constant on the left to avoid an == / = mixup. I know it would be 
better to do it, and I feel bad for it, but reading it is for me a mental speedbump.

Doesn't say much except that being annoying doesn't mean it's necessarily bad.


Placement of commas like this:
こーゆーカンマの置き方:

enum Whatever 
{
      SomeValue
    , AnotherValue
    , YetAnotherValue
}

I understand the rationale, but my eyes bleed when I have to read something like that. 
Very inhumane.

What I don't understand is why language syntax designers do not allow to have 
redundant delimiter characters at the ends of character-delimited lists. Of course, 
something like this

オレがよくわかんね-のは、なんだって言語の構文を設計しているやつらが
リストの最後に余計な区切り記号を置くのを許さないのかってことだね。
こういう風にさ

enum Whatever 
{
    SomeValue,
    AnotherValue,
    YetAnotherValue,
}

would be a little inhumane too but, in my humble opinion, not nearly as ugly as the 
first sample...


GNU style, of course.


When the variable and method/function names are as unintuitive as they can be:

void function1(int i, int j) {
    for(index, index++, index < 5) 
       for(index1, index1++, index1 < 10)

Code is meant to be as self-explanatory as possible and the most control we as 
programmers have is on things we can name/define ourselves (comments is really the 
next level and should be done only if required).


Explicitly testing against boolean literals:
boolean リテラルに対してワザワザ検査すること:

if(foo == true)
{
   ...
}

and (Joel Spolsky mentioned this on the podcast) refusing to return boolean expressions:
それと(これはJoelがpodcastで云ってたけど)

if(x < 24)
{
    return true;
}
else
{
    return false;
}

that makes me crazy.
こういうのは頭に来るね。


I just don't like prefixes in front of class field names: string m_name;

m_name のようにクラスのフィールド名の先頭に prefix つけるのは好かんなあ

Useless variable names
意味のない変数名

int temp1 = 10;
int temp2 = 5;
string a = "test";



Hungarian notation in any form
ハンガリアン記法のすべて


Putting statements on multiple lines, especially when it's really not necessary, as in 
this case:

必要もないのに複数行にわけること。こんなん:


if (bOne &&
    bTwo &&
    bThree &&
    bFour &&
    (!bFive ||
    !bSix))
{
   // do something
}

And it's even more ugly counterpart:
もっとひどいこういうのとか:

if (bOne
    && bTwo
    && bThree
    && bFour
    && (!bFive
    || !bSix))
{
   // do something
}

■_ Porting code to Python 3 with 2to3 - Dive into Python 3 (6～8)

Porting code to Python 3 with 2to3 - Dive into Python 3
http://diveintopython3.org/porting-code-to-python-3-with-2to3.html


has_key() dictionary method (has_key() ディクショナリメソッド)

In Python 2, dictionaries had a has_key() method to test whether the dictionary had a 
certain key. In Python 3, this method no longer exists. Instead, you need to use the 
in operator.

Python 2ではディクショナリ (辞書) はそのディクショナリがある特定のキーを持っているか
どうかを確かめるための has_key() メソッドを持っていました。
Python 3 ではこのメソッドはなくなりました。代わりに in 演算子を使う必要があります。



  
    
Notes Python 2 Python 3

  
  
  
① a_dictionary.has_key("PapayaWhip") "PapayaWhip" in a_dictionary

  
② a_dictionary.has_key(x) or a_dictionary.has_key(y) x in a_dictionary or y in a_dictionary

  
③ a_dictionary.has_key(x or y) (x or y) in a_dictionary

  
④ a_dictionary.has_key(x + y) (x + y) in a_dictionary

  
⑤ x + a_dictionary.has_key(y) x + (y in a_dictionary)




   1. The simplest form.
      最も単純な形式

   2. The or operator takes precedence over the in operator, so there is no need for
      parentheses here.
      or 演算子は in 演算子より高い優先順位を持っているのでこの例ではカッコは不要です。

   3. On the other hand, you do need parentheses here, for the same reason — or takes
      precedence over in.
      こちらの例では同じ理由(orのほうがinより高い優先順位である)でカッコが必要です。

   4. The in operator takes precedence over the + operator, so this form needs
      parentheses too.
      in演算子は + 演算子より高い優先順位を持っていますので、この例でもカッコが必要です。

   5. Again with the parentheses, for the same reason.
      カッコについて同じ理由になります

Dictionary methods that return lists (リストを返すディクショナリのメソッド)

In Python 2, many dictionary methods returned lists. The most frequently used methods 
were keys(), items(), and values(). In Python 3, all of these methods return dynamic 
views. In some contexts, this is not a problem. If the method's return value is 
immediately passed to another function that iterates through the entire sequence, it 
makes no difference whether the actual type is a list or a view. In other contexts, it 
matters a great deal. If you were expecting a complete list with individually 
addressable elements, your code will choke, because views do not support indexing.

Python 2ではディクショナリのメソッドの多くがリストを返していました。
最もよく使われていたメソッドに keys(), items(), values() があります。
Python 3ではこれらのメソッドすべてが dynamic views (動的なビュー) を返すようになっています。
一部のコンテキストにおいてはこのことは問題になりません。
これらのメソッドが返す値が即座に
シーケンス全体を通してイテレートされている別の関数に対して渡されている場合には
メソッドが実際に返した値がリストであるかビューであるかは違いをもたらしません。
それ以外のコンテキストの場合は非常に大きな違いをもたらします。
もしあなたが個々の要素に添え字付け可能な完全なリスト
(complete list with individually addressable elements)を期待していても、
ビューはインデクシングをサポートしていないので
あなたのコードは窒息 (choke) することになるでしょう。



  

Notes Python 2 Python 3


  
    
① a_dictionary.keys() list(a_dictionary.keys())


② a_dictionary.items() list(a_dictionary.items())


③ a_dictionary.iterkeys() iter(a_dictionary.keys())


④ [i for i in a_dictionary.iterkeys()] [i for i in a_dictionary.keys()]

  
⑤ min(a_dictionary.keys()) no change





   1. 2to3 errs on the side of safety, converting the return value from keys() to a
      static list with the list() function. This will always work, but it will be
      less efficient than using a view. You should examine the converted code to see
      if a list is absolutely necessary, or if a view would do.

      2と3 は errs on the side of safety で
      keys() の戻り値を list() 関数を使って static list へ変換します。
      このような変換は常に正常に動作するものですが、ビューを使ったものより効率が
      悪くなります。本当にリストである必要があるのなら、
      変換されたコードを確かめてみるべきでしょう。
      あるいはビューでも問題ないことを確認しましょう。

   2. Another view-to-list conversion, with the items() method. 2to3 will do the same
      thing with the values() method.

      もうひとつ item()を使った ビューからリストへの変換があります。
      2to3 は同じことを values() メソッドを使って行います。

   3. Python 3 does not support the iterkeys() method anymore. Use keys(), and if
      necessary, convert the view to an iterator with the iter() function.
      Python 3 は iterkeys() メソッドをもうサポートしていません。keys() を使ってください。
      もし必要であれば iter()関数を使ってビューをイテレーターに変換してください。

   4. 2to3 recognizes when the iterkeys() method is used inside a list comprehension,
      and converts it to the keys() method (without wrapping it in an extra call to
      iter()). This works because views are iterable.

      2to3 は iterkeys() メソッドがリスト内包 (list comprehension)の中で
      使われていることを認識した場合、それを keys()メソッドに置き換えます
      (このときiter()でラップすることは行いません)。

   5. 2to3 recognizes that the keys() method is immediately passed to a function which
      iterates through an entire sequence, so there is no need to convert the return
      value to a list first. The min() function will happily iterate through the view
      instead. This applies to min(), max(), sum(), list(), tuple(), set(), sorted(),
      any(), and all().
      2to3 は keys()メソッドがシーケンス全体に対してイテレートしている関数に即座に
      渡されていることを見分けるので、keys()メソッドの戻り値をリストに変換する必要は
      ありません。このような操作はmin(), max(), sum(), list(), tuple(), set(), sorted(),
      any(), all() に対して適用されます。

つづく。

■_

■_ アセンブリ言語プログラミングって教える必要あるの? (stackoverflow: Why do we teach assembly language programming?)

stackoverflow からもうひとつ。 

Why do we teach assembly language programming? - Stack Overflow

Is assembly language programming taught just for the sake of history ?

Do compilers generate better assembly code than the one written by a novice programmer?

DEFINE better -> from the point of the execution time of the assembly program

One of the reasons we teach assembly to novice programmers is so that they will no 
longer be novice programmers, that is to help them gain insight to the low level 
functioning of the machine.

I would teach assembly in every curriculum because any computer scientist or 
programmer should know how the chip works at a very low level. Registers, L2 cache, 
vector units, branching, pipelining... these are all things a programmer even working 
in a high level language like Ruby should be aware of.


    Do compilers generate better assembly code than the one written by a novice programmer ?

Yes.

    Is assembly language programming taught just for the sake of history ?

I'd guess it's taught so that you understand what instructions are seen and executed 
by the CPU, and understand what a compiler is doing.

    DEFINE better -> from the point of the execution time of the assembly program

"Better" meaning:

    * Easier (cheaper) to write

    * And, more likely to run correctly

    * And, probably, quicker (faster to execute): Michael Abrash's book titled Zen of 
      Code Optimization, for example, shows something of using assembly to optimize the 
      efficiency of code ... and it is an interesting read ... but one of the take-aways, I 
      thought, was that by the time you get to writing for the Pentium (whose performance is 
      complicated) then it's so difficult and time-consuming to optimize the assembly that, 
      unless you really have to (which is rare), you're usually better off letting the 
      compiler (and the people who write compilers) do it.


Novice programmers don't write assembly. :-)
新米プログラマーはアセンブリで書かないよな :-)

I've seen assembly used for
自分が見たアセンブリ言語を使ったものは

    * the first steps in booting the computer
     コンピューターの起動の第一段階(のプログラム)
    * wrappers for interrupts
      割り込み処理のラッパー
    * low-level locking
      低レベルでのロッキング
    * other similar stuff in the OS where specific machine instructions are needed
      そのほか、OSの中で特定の機械語命令が必要な箇所
    * extremely optimized code
      ガリガリに最適化したコード
    * code for extremely small machines
      極限まで小規模な機械用のコード
    * code for machines where no compiler exists
      コンパイラーがないマシン向け

Everything else is best left to compilers, for ease of programming and portability.

Given the number of Microsoft security updates out there that are specifically 
targeted at known attacks that manipulate buffer overflows, I'd say that there is 
still a thriving assembler savvy community out there ;) I used to do much of my 
programming in assembly back in the days of 8 bit, and it certainly taught me how to 
program efficiently. Is it a necessary skill for most programmers? Probably not. Is it 
a desirable skill for those who really want to understand how computers work? 
Absolutely.

There is another good reason to teach assembly--debugging. If there is a problem in a 
call to a third party library sometimes the only way a developer even has to isolate a 
problem is to look at the assembly. Granted this does not require a deep knowledge of 
assembly language coding but at least a passing familiarity with assembly is helpful 
in that particular case.

2009年02月09日

■_

・今日の森北出版の本
だいぶ前に買ってたものですが、整理中に出てきたので（笑）

基礎から学ぶコンピュータアーキテクチャ
出版社のページに目次が…ってあんまり詳細に書いていないなあ(^^; 森北出版｜基礎から学ぶコンピュータアーキテクチャ 論理の基礎(and やら or やらね)からCOMET-IIを使ったアセンブリ言語プログラミングまで 「低レベルな」お話が詰まった一冊です。例によって持ち歩くにも最適な版型ですので 通勤中のお供にどうぞ :) アセンブリ言語とそれに関連したハードウェアの説明はあるけど「プログラミング」は微妙な量かも

・闘うプログラマ
この手の本なら、文庫版で出してもいいと思うんだけどやってくれないもんかいのう。 という話はさておき、わたしの家の近くにある図書館の蔵書にもあったので、 読みたいという人は一度図書館に行ってみるといいと思うよ。 その際、書架だけじゃなくて、「保存庫」(という名称かわからないけど)にあるかもしれないから、 蔵書データベースもあたるといいんじゃないかな。

・例の本
早売りしているところだと今日あたり手に入る? 

危ないRiSKのブログ うつ期ver.
とのことですが、


→『C言語 はじめてのプログラミング』 & 『C言語 はじめて学ぶCの仕組み』 | 株式会社きじねこ

によると

http://www.amazon.co.jp/exec/obidos/ASIN/4798118060/hadirisbl-22/ref=nosim/
http://www.amazon.co.jp/exec/obidos/ASIN/4798118079/hadirisbl-22/ref=nosim/

これっぽいですね。どちらも￥ 1,974のようです。

モダンPerlと一緒に買うかなあ。

■_ ぱろっと

ちょっとだけソースを覗いてみた。 

/*

=item C<PMC * Parrot_io_open_win32>

Calls C<CreateFile()> to open C<*spath> with the Win32 translation of
C<flags>.

=cut

*/

PARROT_CAN_RETURN_NULL
PMC *
Parrot_io_open_win32(PARROT_INTERP, ARGMOD(PMC *filehandle),
               ARGIN(STRING *path), INTVAL flags)
{
    ASSERT_ARGS(Parrot_io_open_win32)
    DWORD fAcc, fShare, fCreat;
    PIOHANDLE fd;

#  if 0
    if ((Interp_flags_TEST(interp, PARROT_DEBUG_FLAG)) != 0) {
        fprintf(stderr, "Parrot_io_open_win32: %s\n", spath);
    }
#  endif
    if ((flags & (PIO_F_WRITE | PIO_F_READ)) == 0)
        return NULL;

    /* Set open flags - <, >, >>, +<, +> */
    /* add ? and ! for block/non-block */
    if (convert_flags_to_win32(flags, &fAcc, &fShare, &fCreat) < 0)
        return NULL;

    /* Only files for now */
    flags |= PIO_F_FILE;

    { /* enclosing scope for temporary C string */
        char * const spath = string_to_cstring(interp, path);
        fd = CreateFile(spath, fAcc, fShare, NULL, fCreat,
                    FILE_ATTRIBUTE_NORMAL, NULL);
        string_cstring_free(spath);
    }
    if (fd != INVALID_HANDLE_VALUE) {
        PMC *io;
        if (PMC_IS_NULL(filehandle))
            io = Parrot_io_new_pmc(interp, flags);
        else {
            io = filehandle;
            Parrot_io_set_flags(interp, io, flags);
        }

        Parrot_io_set_os_handle(interp, io, fd);
        return io;
    }
    else {
        int err = GetLastError();
        if (err) {
            errno = err;
        }
    }

    return PMCNULL;
}

なんとなくアチャーなよかーん。

■_ stackoverflow て訊いてみた: メタプログラミングって一体ナニ?

What exactly is metaprogramming? - Stack Overflow

I was reading an article on TheServerSide on ployglot programming on the Java platform. 
Some comments in the article refer to metaprogramming as the ability to generate code 
(perhaps on the fly).

Is metaprogramming the ability to generate code on the fly or is it the ability to 
inject methods and attributes into existing objects at runtime (like what some dynamic 
languages like Python, Ruby, and Groovy allow).

メタプログラミングってのはプログラムの実行時にオンザフライでコード生成できる能力とか
やはりプログラムの実行時にすでに存在しているオブジェクトに対してメソッドやアトリビュート
を注入できる能力ということでいいのかなあ

edited--- Thanks to everyone who answered. Reading all the answers have helped clarify 
what metaprogramming means. Since the answer emerged after reading several answers, it 
is hard to select an answer as the 'selected one'.




Metaprogramming is writing a program which outputs another program. This is something 
languages like Lisp are really good at. It is much easier to do in a language that 
supports real macros (not C++ macros, but rather ones that can manipulate the code 
they output) such as Ruby, Lisp, Scheme, etc. than in a language like Java.

メタプログラミングとは別のプログラムを出力するプログラムを書くことです。
これはLispのような言語が特に向いているものです。
RubyやLisp、Schemeなどのようにホンモノのマクロ(C++のマクロのようなものではなく、
出力するコードを操作することのできるもの)をサポートしている言語が
Javaのような言語よりも簡単にメタプログラミングを行えます。

One implementation is to create a "domain specific language" which is a way 
of enhancing a programming language to accomplish a specific task. It can be 
incredibly powerful if done correctly. Ruby on Rails is a good example of this sort of 
programming.

If you interested in exploring this method, check out the Structure and Interpretation 
of Computer Programs which is one of the seminal books covering the subject.



This is just my personal opinion. Which is probably the most liberal definition of metaprogramming.
これはわたしの個人的な意見。
メタプログラミングの最もリベラルな定義じゃないかと思う。

I think it includes:
1) Compile code generation or Runtime code generation (or both)
   コンパイル時のコード生成か実行時のコード生成(もしくはこの両方)
2) Aspect-Oriented Thinking or Aspect Oriented Programming
   アスペクト指向思考もしくはアスペクト思考プログラミング
3) DRY Thinking
   DRY 思考

I think you can get there by using any of these and in combination:
1) Reflection (リフレクション)
2) DSLs (Domain Specific Languages) (ドメイン特化言語)
3) Attributes (.NET) or Annotations (Java) (.NET のアトリビュートやJavaのアノテーション)
4) Generics (.NET/Java) (ジェネリクス)
5) Templates (C++) (テンプレート)
6) method_missing (Ruby) 
7) closures / first class functions / delegates
8) AOP - Aspect Oriented Programming

I like some of the answers also. Just thought I would throw in the 10,000 foot view.

■_

Fortran は90以降どの年があるのか良くワカランw 



くだすれFORTRAN（超初心者用）その4 
41 デフォルトの名無しさん [sage] Date:2009/02/07(土) 00:28:19  ID: Be:
    CrayがFortran2003完全対応のコンパイラをリリースしたらしいな。

    ついでにFortran2008にも部分対応らしいな。
    といっても、CoArrayはもともとCRAYがやっていたので当然なんだが（笑

42 デフォルトの名無しさん [sage] Date:2009/02/07(土) 02:48:21  ID: Be:
    caryってまだ生きてたんだ・・・ 

43 デフォルトの名無しさん [sage] Date:2009/02/07(土) 11:42:24  ID: Be:
    >>42
    Crayはここ１０年くらいのアメリカの護主義のおかげで復活してる。
    一時期の低迷は脱している。


    そういえば、東工大のつばめに刺さっていたクリアスピード社が、イギリスの経済壊滅の
    余波で株価急落、資金繰りにもつまってきたというニュースが先週流れてきてた。
    ETA１０の夢ふたたびｗ

44 デフォルトの名無しさん [sage] Date:2009/02/07(土) 16:20:54  ID: Be:
    この不況でスパコン業界の勢力図も相当変わるだろうな

    つーかCrayってもう石は作ってないんだよな？
    その他大勢の単なるシステム屋さんに成り下がっちまった

2008なんてあるのか… 



スレを勃てるまでもないC/C++の質問はここで 7 
415 デフォルトの名無しさん [] Date:2009/02/07(土) 01:54:09  ID: Be:
    質問があります。

    <と==を定義しているクラスMyClassがあって

    　bool MyClass::operator<(const MyClass& m);
    　bool MyClass::operator==(const MyClass& m);

    これをstd::multimapに入れました。

    　std::multimap<int, MyClass> mm;

    このmmに対して、

    mm.insert();　　でoperator<()が呼ばれるのは確認できたのですが
    mm.find();　　　でoperator==()が呼ばれません。

    何故でしょうか？ 

416 デフォルトの名無しさん [sage] Date:2009/02/07(土) 02:00:30  ID: Be:
    findの対象になるのはintの方 

417 デフォルトの名無しさん [sage] Date:2009/02/07(土) 02:56:55  ID: Be:
    >415
    >416 の通りなんだけど仮に MyClass がキーだったとしても operator==() ではなくて、
    !a.operator<(b) && !b.operator<(a) として判断が行われる。 

421 デフォルトの名無しさん [sage] Date:2009/02/07(土) 09:34:01  ID: Be:
    >>415 等値と等価だね　詳しくは Effective STL 読んでくれ 

432 デフォルトの名無しさん [] Date:2009/02/07(土) 14:35:57  ID: Be:
    >>471
    そう言うのは何を見ればわかりますか？

    VC++のオンラインマニュアルには「Finds an element that matches a specified key.」としか書いてなく
    どうやってmatchesを判定するのか書いていませんし、
    「C++ STL multimap find」とか「std::multimap::find 比較」とかでググっても出てきません。 

433 デフォルトの名無しさん [] Date:2009/02/07(土) 14:36:54  ID: Be:
    >>421
    Effective STL を読んでみます。ありがとうございます。 

434 デフォルトの名無しさん [sage] Date:2009/02/07(土) 15:28:42  ID: Be:
    >432
    STL には色々と落とし穴も多いので Effective STL は読んどくべき。

    で、君が見ているのは STL じゃなくて STL/CLR のオンラインヘルプではないかね？
    STL はこっち。

    ttp://msdn.microsoft.com/en-us/library/9987620f.aspx
    > Remarks
    > The member function returns an iterator that addresses an element in the multimap
    > whose sort key is equivalent to the argument key under a binary predicate that induces
    > an ordering based on a less than comparability relation.

    これで分かれっちゅうのも酷な話だと思うが。

    >そう言うのは何を見ればわかりますか？

    今回は find に固有の挙動ではなくて associative container(set とか map) 一般の挙動についてなので、
    set とか map の使い方を説明してるところでは書いてあるんじゃない？

    最良の資料は規格だろうけど買えってのも厳しいとは思うので前の版の C++ 規格の最終 draft なんかも参考になる。
    ttp://www.hep.wisc.edu/~pinghc/isocppstd/lib-containers.html#lib.associative.reqmts 

435 デフォルトの名無しさん [] Date:2009/02/07(土) 15:59:17  ID: Be:
    >>434
    >STL はこっち。

    そちらも見ましたよ。
    「equivalent」がボールドになっていたのが意味不明だったのですが、これが>>421の「等価」ですね。

    >set とか map の使い方を説明してるところでは書いてあるんじゃない？

    日本語で記述されているところにはありませんでした。

    最後のリンクを参考にしてみます。ありがとうございます。 

436 デフォルトの名無しさん [] Date:2009/02/07(土) 16:04:09  ID: Be:
    >>417
    それならば、find()でoperator<()が呼ばれるはずですよね。

    operator<()とoperator==()の先頭にブレークポイントを付けているのですが、
    find()のときにはどちらも呼ばれません。

    何故だろう。。

420が回答で書いてることって知らん人多いのかなあ? 



ポインタを難しいと言う奴が理解できない 
323 デフォルトの名無しさん [sage] Date:2009/02/05(木) 08:40:05  ID: Be:
    >>318
    >>6

    >>320
    大昔のHP-Cで =* という独自拡張された演算子
    (*= と同じなんだけど、式の値は演算“前”の左辺) があって
    a=*b なんて書くと「ambiguous だぜ。演算子の後ろに空白入れな。」
    という警告をくらったのを思い出した。
    bがポインタかどうかで判断つくだろうに。
    つか、誰が得するんだあの拡張。 

324 デフォルトの名無しさん [sage] Date:2009/02/05(木) 11:58:49  ID: Be:
    >>323
    無能なプログラマほど、空白を詰めて書きたがる。
    で、そういう馬鹿なミスをやって人件費を無駄遣い。
    それからな、=* の類は「独自拡張」じゃないぞ。 

325 デフォルトの名無しさん [sage] Date:2009/02/05(木) 12:33:45  ID: Be:
    >>324
    >無能なプログラマほど、空白を詰めて書きたがる。
    for 内部の代入は空白あけないぞスタイルだったもんで。

    >で、そういう馬鹿なミスをやって人件費を無駄遣い。
    コンパイル時に警告出てんだから
    数秒以内で修正可能なレベルだろに。
    大袈裟だな君は。

    > =* の類は「独自拡張」じゃないぞ。
    ｍｊｓｋ 

326 デフォルトの名無しさん [sage] Date:2009/02/05(木) 13:42:15  ID: Be:
    > > =* の類は「独自拡張」じゃないぞ。
    > ｍｊｓｋ
    こんなことも知らん割には、ずいぶん上から目線だな。

まあごく初期にだけあった仕様らしいからねえ > 複合代入演算子の等号の位置が逆 知らなくても無理はないかと。 Chistory

■_ 6分であなたもより優れたプログラマーになれ…る?


8 ways to be a better programmer in 6 minutes.

Remember how Justice Gray started that little fad about becoming a better developer in 
6 months?

Well, that was a while ago and most of you failed. Badly.

So here's a simpler challenge, some ways to be a better programmer in 6 minutes.

You've got 6 minutes, right?

Go for it!

   1. Use a bigger font size. (もっと大きなフォントサイズにしよう)

      This is ridiculously easy -- but it works.

      Go to your favourite IDE, and crank the font-size up. I switched from 10pt to 14pt.
      The difference is that a lot less code fits on the screen at once.
      自分の好みのIDEを立ち上げて、フォントサイズを大きいものにしてください。
      わたしは10ポイントから14ポイントに変えました。これによる違いはスクリーンに一度に
      表示できるコードの量がガクッと減るということです。

      The effect is: you're forced to write shorter methods. And that's a Good Thing.
      これによる効果:
      短いメソッドを書くことを強制されます。そしてそれは良いこと(Good Thing)です。

      (Scott Hanselman recommends that one)

   2. string highlightingMake hard-coded strings look ugly.
      (ハードコードされた文字列は(悪い意味で)目立つようにハイライト表示しよう)

      I learnt this from Joe Cooney.
      わたしはこれを Joe Cooney から学びました。

      Go to your favourite IDE, and set it so that literal strings stand right out -- 
      for example a yellow background with a red font. Make 'em ugly. Damn ugly. This 
      will encourage you to perform less hard coding, and to notice when you are
      embedding strings in your text.

   3. Pick an 'obscure' keyword and master it
      “奇妙な”キーワードを取り上げ、それをマスターしてみよう

      Do you fail to yield?. Is there a keyword you never use?

      Every keyword has a purpose. Learn to master those mystery keywords and your 
      powers will become extraordinary.
      すべてのキーワードには目的があります。

      Here are lists for a few .net languages: C#, VB.net, F#.

   4. Increase code-coverage by 1% (コードカバレッジを 1% 増やそう)

      Don't kill yourself striving for 100% coverage of code with automated unit tests. 
      But take a few minutes to increase your coverage by 1%.

      Most likely, that means going from 0% to 1%. And that's the biggest improvement 
      of all.

      Find a particularly ghoulish regular expression. Or a critical piece of business 
      logic. These things can't be trusted without tests.
      特に ghoulish な正規表現を見つけよう。
      あるいはビジネスロジックの critical piece を見つけよう。
      そういったものはテスト抜きには信用することができないのです。
 
   5. Read the code from an open source project (オープンソースプロジェクトのコードを読んでみよう)

      Sometimes, when I'm looking at the code of a complete stranger, I get that same, 
      weird feeling I get when I'm creeping through my neighbour's house. Picking up their 
      stuff, looking through their fridge.

      Learn to overcome the creepy sensation, and bring on the learn.

      Maybe start with Hanselman's Weekly Source Code series.

   6. Run a static analysis tool against your code (自分のコードを静的解析ツールにかけてみよう)

      Use fxcop, or StyleCop, clone detective, ndepend, the code metrics feature of VS 
      2008, or any other static analysis tool of your choice.

      Uncover your greatest weakness. Even a cursory glance at the output will leave 
      you distraught at just how much room you've got for improvement.

   7. Pick an ugly method to refactor (出来の悪いメソッドを取り上げてそれをリファクタリングしよう)

      You know the method. That method you're particularly ashamed of. That one that's 
      long and ugly and horrible. And it's crucial to the whole application.

      You don't have to polish it from a turd to a diamond, but just neaten it up a 
      little. Rename a variable. Hoist part of it out into a separate method. Start simple. 
      The momentum will increase. Watch out.

   8. Stop reading, start writing. (読むのを止めて書き始めよう)

      And don't just write. Write a compiler!
      単に書くだけではなくて、コンパイラーに挑戦してみよう!

      This ol' msdn article is a good place to start. Joel Pobar will get you writing 
      your own language compiler in but a handful of minutes.
      MSDNにある ol のアーティクルは始めるのに良い場所です。
      Joel Pobar は

That's all I've come up with for now. But what've you got?

What are some 6 minute activities that helped you be a better programmer?

reddit での反響。 8 ways to be a better programmer in 6 minutes. : programming 訳してる余裕がねえええ

■_ bashの機能?



[shell-fu:view-196]$Manipulate Bash sockets using /dev/tcp
Don't have telnet or netcat handy for making a socket connection? Most Linux distros - not likely Debian - have this functionality built directly into Bash. The following will pull my site's index source on port 80, replace with any URL.

#!/bin/bash

exec 3<>/dev/tcp/kinqpinz.info/80

echo -e "GET / HTTP/1.1\nHost: kinqpinz.info;\nConnection: close\n\n">&3

cat <&3

なんだその /dev/tcp ってデバイスわ。 まあ gawkにもあるけどさ。

■_

  • Webサイトで何故PHPが圧倒的になってきているんでしょうか？何故JAVAが主流にならないのでしょうか？ -OKWave
  • Eligis: OpenLisp, ISLISP, ISO Lisp
    OpenLisp is a KISS (Keep It Small and Simple) full conforming implementation of ISO/IEC 13816:1997 ISLISP Language, the International Standard version of Lisp. Entirely written in C, OpenLisp has been ported on more than 90 different architectures (compiler/OS/processor) from small 16 bits MS-DOS systems to 64 bits systems such as DEC Alpha processor.
  • 2009-02-07 - うっくつさん本を読む。: 多値と意味論
  • 総称関数の先行実行 - リリカル☆Lisp開発日記
  • C++ Soup!: Programming: Principles and Practice Using C++
    すっぽすっぽ先生の新刊に対する感想
  • JavaScript, 5 ways to call a function - Sergio Pereira
  • Wataru's memo(2009-02-08)
    これからの季節、"プログラミング言語C" を小脇に抱えてニコニコ近づいてくる先輩にも、要注意です。
  • Embedded.com - Why aren't developers interested in Ada?
  • Why aren't developers interested in Ada? : programming

    • 2009年02月08日

    ■_

    ・ラザーニャ
    久しぶりに食った。おいしゅうございました。

    ・読書>br /> 図書館で小説フランス革命の一巻(革命のライオン)と 二巻(バスティーユの陥落)を一緒に予約していたのですが、 二巻だけ順番が回ってきたという連絡が来てうろたえるw 『小説フランス革命シリーズ』佐藤賢一　悩める漢たちの群像 - あんとに庵◆備忘録

    で、一巻は結局買ったw 革命のライオン (小説フランス革命) (小説フランス革命 1) バスティーユの陥落 (小説フランス革命) (小説フランス革命 2)
    歴史ものとか、フランス革命に興味がないとつらいかもしれませんが 面白いです。三巻以降は買ってくかなあ。 一巻の表紙はミラボー。二巻はロベスピエールです(だと思う)。 ロベスピエールというと、恐怖政治の代名詞みたいに扱われることがほとんどだと思いますが それは誤解というか構成のレッテル貼りの影響があるのではないのかと 「 alt="ナポレオン獅子の時代" />」を読んだとき(4巻から5巻くらい)に感じたことがあります。 オノーレ・ミラボー - Wikipedia フランス革命　人物スケッチ　ま行 マクシミリアン・ロベスピエール - Wikipedia ロベスピエール 小部屋　ロベスピエール　目次

    ・読書その2
    もうこの人の書いた本は買わない。 スティーブ・ジョブズ神の交渉力―この「やり口」には逆らえない! (リュウ・ブックスアステ新書 48)
    どんなことでもジョブズは持ち上げゲイツは貶す。 ゲイツ・メリンダ財団のことは全く念頭にないかのように、 ゲイツは儲けるだけ儲けているけどそれを還元していないとかなんとか。 ジョブズの名がタイトルにあるということで何冊かこの人の本を買って読んだけど どの本も読後感が最悪だった。今度から著者名チェックするよ○|￣|＿

    ・読書その3
    15巻までマンガ喫茶で読んだけど、 ひじょーに面白くこのままでは作者に申し訳ないので最後の4冊は買ったw
    ONE OUTS 16 (16) (ヤングジャンプコミックス) ONE OUTS 17 (17) (ヤングジャンプコミックス) ONE OUTS 18 (18) (ヤングジャンプコミックス) ONE OUTS 19 (19) (ヤングジャンプコミックス)
    どう面白いかというのを書きたいのだけど、そうすると実際に読むときの興味を削いでしまう (要するにネタバレしてしまいかねない)のでにんともかんとも。 でもまあ、日テレのアニメでは「アカギ」と「カイジ」とあわせて三部作ということに されているので(前二作と作者違うのにw)、そういう方面の作風が好きなら読んで外れはない。 と思います。 以前にも書きましたが途中二軍でもお荷物とされている三人を一軍に引き上げてという 話があるんですが、この三人のうちの一人が土下座して主人公に頼みごとをする 場面があります。このとき主人公が土下座をしている人物に対して吐いた言葉が 自分にもぐさっと来ました。どういう台詞かはそれこそネタバレですので 書けというのはご勘弁。多分12巻か13巻辺りだったと思います。 まあわりと見かける類のものなんですけどね。

    ■_

    たくさんあって削るのがたいへん。 

    

【ぼくの権利を守って】使えない新人 0x19 
64 仕様書無しさん [sage] Date:2009/02/08(日) 15:13:05  ID: Be:
    新人君から
    「どうしたら、もっと技術を上げることができますかね？」
    と聞かれたので
    「俺は家帰ってから勉強したり、最低パソコンの使い方程度のことは自分で調べて身に着けるようにしてるよ」
    「最低限、ソフト屋で働くレベルに達して無いと、誰かに教えてもらっても理解できなかったりするしね」
    と答えた
    新人君は、
    「家でまで勉強とかしたくないっすね！」
    と満面の笑みで答えた。



    もしかして、パソコンの使い方から全部会社で教えてくれるものだと思ってるのかね・・・ 

65 仕様書無しさん [sage] Date:2009/02/08(日) 15:18:06  ID: Be:
    >>64
    満面の笑みで「勉強しないんじゃ、技術は上がらないね」と答えればいいよ 

66 仕様書無しさん [sage] Date:2009/02/08(日) 16:02:48  ID: Be:
    >>65
    当然言っときましたよ。
    しかし、返答が
    「作業するのが遅いから勉強する時間無いんですよね」
    と、

    なんかもう勝手にすればと思いました。 

67 仕様書無しさん [sage] Date:2009/02/08(日) 16:17:47  ID: Be:
    いつまでも自分が一番優秀なのがいいじゃん
    社内でちやほやされるし 

68 仕様書無しさん [sage] Date:2009/02/08(日) 16:21:17  ID: Be:
    「君が一番優秀だ」って言葉に騙されて
    毎日深夜まで残業してるわけですね。
    結局忙しい人は固定して、他の人間は定時で帰ると。
    残業代は人より多いかもしれないが、確実に寿命は縮まっている。 

69 仕様書無しさん [sage] Date:2009/02/08(日) 16:25:51  ID: Be:
    >>66
    スレタイ通りの新人君だww 

70 仕様書無しさん [sage] Date:2009/02/08(日) 16:30:17  ID: Be:
    >>66
    作業が遅いから勉強できない
    ↓
    勉強しないから作業が遅い
    ↓
    作業が遅いから勉強できない
    ↓
    勉強しないから作業が遅い
    ↓

    何という負の連鎖。 

71 仕様書無しさん [sage] Date:2009/02/08(日) 16:46:00  ID: Be:
    >>70
    違うだろ

    >>66の場合
    作業が早いので仕事が集まる
    ↓
    業務中に勉強する時間がない
    ↓
    家で勉強する
    ↓
    作業が早いので仕事が集まる
    ↓

    >>66の新人
    作業が遅いので仕事がほかに回る
    ↓
    定時に帰れる
    ↓
    家で勉強しない
    ↓
    作業が遅いので仕事がほかに回る
    ↓

    という負の連鎖。 

72 仕様書無しさん [sage] Date:2009/02/08(日) 16:55:00  ID: Be:
    >>71
    >>66と新人の間で負のループが出来ているわけですね。 

73 仕様書無しさん [] Date:2009/02/08(日) 17:04:35  ID: Be:
    勉強嫌いなのにPGになった俺はマジで道を誤った・・・。
    勉強してても内容が理解できなくてひどい。 

74 仕様書無しさん [sage] Date:2009/02/08(日) 17:26:17  ID: Be:
    勉強だと思わなければいい。
    趣味感覚でやってると意外と覚えるよ。
    内容が理解できないってのは、難しく考えすぎてるからではないだろうか。 

75 仕様書無しさん [sage] Date:2009/02/08(日) 17:47:24  ID: Be:
    別にこの業界に限らず勉強やそれに類することが出来ない奴は一生使い走りの
    ままだよ。 

76 仕様書無しさん [sage] Date:2009/02/08(日) 17:52:16  ID: Be:
    しかし業務に必要な知識は本来会社が教えるものだろ
    一から全て教えてる余裕がないから経験者を中途で採ったり
    学歴や資格を採用条件にしたりしてるんじゃなかったのか 

77 仕様書無しさん [sage] Date:2009/02/08(日) 17:53:51  ID: Be:
    >>76
    会社は仕事をするところ
    勉強は私有時間に行うのが義務だ

78 仕様書無しさん [sage] Date:2009/02/08(日) 18:04:16  ID: Be:
    業務に必要な知識と勉強の線引きは難しいところやね

79 仕様書無しさん [sage] Date:2009/02/08(日) 18:08:13  ID: Be:
    業務に必要な知識のうち、組織独自のプロセス等により組織内で教育しなければ
    伝わらないもの

    は、会社が教える。

    そうでなく書籍やネットでいくらでも自分で調べられることを
    業務時間中に教えてもらおうとか（自分の時間だけでなく自分より
    仕事のできる先輩社員の時間まで無駄になる）一体どこまでゆとりなんだ。頭おかしい。 

80 仕様書無しさん [sage] Date:2009/02/08(日) 18:17:47  ID: Be:
    新人に仕事がなく待機だったので
    いろいろ本渡してほっといたら
    スーパーハッカーになってましたorz 

81 仕様書無しさん [sage] Date:2009/02/08(日) 18:21:05  ID: Be:
    どんだけ待機させたらｽｰﾊﾟｰﾊｶｰになってくれるんだよｗ 

82 仕様書無しさん [sage] Date:2009/02/08(日) 18:23:23  ID: Be:
    6ヶ月だよ。 

83 仕様書無しさん [sage] Date:2009/02/08(日) 18:25:22  ID: Be:
    むしろ与えた本を聞きたいところｗ 

84 仕様書無しさん [sage] Date:2009/02/08(日) 18:35:34  ID: Be:
    その本俺も欲しいｗ 

85 仕様書無しさん [sage] Date:2009/02/08(日) 18:51:52  ID: Be:
    なぜか80自身はスーパーハッカーでない様子
    ふしぎ 

86 仕様書無しさん [sage] Date:2009/02/08(日) 19:03:55  ID: Be:
    新人がスーパーハッカーになったら
    本気で自分が楽になるしうれしい限りだわ。

87 仕様書無しさん [sage] Date:2009/02/08(日) 19:03:58  ID: Be:
    その新人の初期ポテンシャルが気になる所でもある

    ネタだろうけど80の読ませた本に興味津々w 

    

推薦図書/必読書のためのスレッド 44 
552 デフォルトの名無しさん [sage] Date:2009/02/07(土) 09:46:48  ID: Be:
    猫はどうですか？ 

553 デフォルトの名無しさん [sage] Date:2009/02/07(土) 09:58:53  ID: Be:
    とても可愛いですよ。 

554 デフォルトの名無しさん [sage] Date:2009/02/07(土) 10:01:54  ID: Be:
    もふもふしてると癒されるな 

555 デフォルトの名無しさん [] Date:2009/02/07(土) 15:41:01  ID: Be:
    　　　　　　　　　　　　　　　　　　　　　ヽ_人_人_人_人_人_人_人_人_人_人_ノ
    　　　　　　　ﾊ,_,ﾊ　　　 ｍ　　　　　　　）　　　　　　　　　　　　　　　　　　　（
    　　？ 　　,:'　´∀';　　　ﾉ　　　 ｒ ､　　）　うおぉー　ﾓﾌﾓﾌさせろー！！　（
    　　　 l＾ヽ'"'"~/＾i'ﾂ'∧＿∧　／　　　 ）　　　　　　　　　　　　　　　　　　　（
    　　ヽﾞ　　　　　　　 'ﾐ, 　　　）　　　＿＿Y⌒Y⌒Y⌒Y⌒Y⌒Y⌒Y⌒Y⌒Y⌒
    　　ﾐ　　´　∀　｀　 と,　　　ヽ　==---￣￣
    　　ｯ　　　　　　 _　　 "ミ＿＿>　　====----
    　(´彡,.　 　　 （,,_,ﾉ　　_ヽ＿）＿）
    　　　　 "'"'ﾞ''""''''ﾞ""´
    　　　　　　　　　　　　ばふっ 

556 デフォルトの名無しさん [sage] Date:2009/02/07(土) 16:11:32  ID: Be:
    俺は猫が飼いたいんだが、母親とか妹は犬を飼いたいと仰る
    何で女は犬好きなんだろう 

558 デフォルトの名無しさん [sage] Date:2009/02/07(土) 16:41:56  ID: Be:
    母と妹は犬が好き
    ↓
    女は犬が好き

    非論理的ですね 

559 デフォルトの名無しさん [sage] Date:2009/02/07(土) 16:56:38  ID: Be:
    ヒント：統計学 

560 デフォルトの名無しさん [sage] Date:2009/02/07(土) 17:14:31  ID: Be:
    一億二千万分の2ですね。
    くだらん流行だな、ヒント。 

561 デフォルトの名無しさん [sage] Date:2009/02/07(土) 17:21:21  ID: Be:
    キレれるなよｗｗ 

562 デフォルトの名無しさん [sage] Date:2009/02/07(土) 17:22:38  ID: Be:
    ネットで誰でも文章を公開できる世の中になってから
    出版に対する敷居が低くなり書籍のレベル低下が著しい 

563 デフォルトの名無しさん [sage] Date:2009/02/07(土) 17:23:51  ID: Be:
    帰納法 

564 デフォルトの名無しさん [sage] Date:2009/02/07(土) 17:25:16  ID: Be:
    典型的な女なら結果として「女は犬好き」が当たっちゃうのかもね
    論理的には大アウトだが 

565 デフォルトの名無しさん [sage] Date:2009/02/07(土) 17:29:51  ID: Be:
    バカみたく論理的、論理的言ってるバカは、一度論理学勉強してこい 

566 デフォルトの名無しさん [sage] Date:2009/02/07(土) 17:30:59  ID: Be:
    ヒント厨の逆ギレｗ 

567 デフォルトの名無しさん [sage] Date:2009/02/07(土) 17:33:34  ID: Be:
    一億二千万分の2の統計学の方が笑った。 

568 デフォルトの名無しさん [sage] Date:2009/02/07(土) 17:38:19  ID: Be:
    一億二千万とか言ってる馬鹿がいるな 

571 デフォルトの名無しさん [sage] Date:2009/02/07(土) 18:32:44  ID: Be:
    人口の半分だから六千万だろ 

572 デフォルトの名無しさん [sage] Date:2009/02/07(土) 18:41:32  ID: Be:
    男の方も調べないと「女は～」とはいえないかと 

573 デフォルトの名無しさん [sage] Date:2009/02/07(土) 18:45:20  ID: Be:
    >>572
    論理学学べよｗ 

574 デフォルトの名無しさん [sage] Date:2009/02/07(土) 18:48:17  ID: Be:
    「XはAである。かつ、YはAである。」 → 「XはAである。」
    「XはAである。かつ、YはAではない。」 → 「XはAである。」

    YがAであっても、Aでなくても、XがAであれば、XはAである。 

575 デフォルトの名無しさん [sage] Date:2009/02/07(土) 19:20:51  ID: Be:
    う～ん　だけど男も犬好きだったら
    「何で女は犬好きなんだろう」じゃなくて
    「「何で人間は犬好きなんだろう」になんない？ 

577 576 [sage] Date:2009/02/07(土) 20:05:22  ID: Be:
    あッ！？
    >>576は>>571へのレス
    下のリンクも参照してね

    出会いは、億千万の胸騒ぎなんですか？
    ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1313805588?fr=rcmd_chie_detail 

578 デフォルトの名無しさん [sage] Date:2009/02/07(土) 20:21:55  ID: Be:
    スレ違い 

580 デフォルトの名無しさん [sage] Date:2009/02/07(土) 20:49:11  ID: Be:
    >>575
    もしかしたら犬猿の中っていわれてる猿も犬好きかもしれないぜ?
    そうするとで霊長類は（ｒｙ
    になるかもしれない.
    けどそれだとどこまでも広げられるからわざわざそんなことはしない. 

582 デフォルトの名無しさん [sage] Date:2009/02/07(土) 21:18:44  ID: Be:
    ベン図を書くまでもなく
    知り合いにい犬好きの女がいることから導けるのは
    「若干の女は猫より犬が好きである」
    これの否定は
    「全ての女は猫より犬が好きではない」
    になる.

    ・・・このスレ的には「プログラマの数学」を勧めれば良いのかな.
    良い本だと思うし.

583 デフォルトの名無しさん [sage] Date:2009/02/07(土) 21:32:55  ID: Be:
    >>>582
    「若干の女は猫より犬が好きである」
    の否定は
    「全ての女は猫より犬が好きではない」
    ではなく
    「若干の女は猫より犬が好きではない」
    だ。

    まず、命題の否定、裏、逆、対偶について教科書見るかググってこいよ。
    話はそれからだ。 

592 デフォルトの名無しさん [sage] Date:2009/02/08(日) 00:30:33  ID: Be:
    >552 を論理学談義に発展させるお前らが好きだ 


    

くだすれPython(超初心者用)　その3 
271 デフォルトの名無しさん [] Date:2009/02/04(水) 12:05:41  ID: Be:
    同じ要素の繰り返しからなるリストを生成する
    シンプルな記述方法はあるでしょうか？

    123,5 という入力から [123,123,123,123,123]
    というリストを得たいと思っています。
    ジェネレータで5回生成するようにもしてみたのですが
    ワンライナーでほんもの？のリストを得たいです。 

272 デフォルトの名無しさん [sage] Date:2009/02/04(水) 12:10:05  ID: Be:
    [123] * 5 

273 デフォルトの名無しさん [] Date:2009/02/04(水) 12:10:19  ID: Be:
    も、もしかして
    5 * [123]
    で終わりっすか？

    もしそうなら死にたい。
    そんなことに気付かなかった自分に絶望した。 

274 デフォルトの名無しさん [sage] Date:2009/02/04(水) 12:10:42  ID: Be:
    鬱だ 

277 デフォルトの名無しさん [sage] Date:2009/02/04(水) 16:51:24  ID: Be:
    [1,2,3,4] * 4

    がどうして[1,2,3,4,1,2,3,4,1,2,3,4]になるんだろうね
    ベクトルの定数倍になってほしい 

278 デフォルトの名無しさん [sage] Date:2009/02/04(水) 17:08:45  ID: Be:
    ベクトルじゃなくてシーケンスだからしょうがない 

279 デフォルトの名無しさん [sage] Date:2009/02/04(水) 17:09:58  ID: Be:
    a * 4 = a + a + a + a

    こういう事だと思う。
    文字列とか連結リストオブジェクト同士を足すとそうなる。 

280 デフォルトの名無しさん [] Date:2009/02/04(水) 17:23:59  ID: Be:
    'SELECT myid FROM mytable WHERE col1=%(col1) AND col2=%(col2)' % vars()

281 デフォルトの名無しさん [sage] Date:2009/02/04(水) 17:29:34  ID: Be:
    >>277
    >>> map(operator.mul, [1,2,3,4], [4]*4)
    [4, 8, 12, 16] 

282 デフォルトの名無しさん [sage] Date:2009/02/04(水) 17:50:48  ID: Be:
    和とかスカラーの積の場合は単純だけど、
    リスト*リストだと内積をとるべきなのか外積をとるべきなのか迷うなあ
    いやベクトルの要素同士を掛けてベクトルを返すというのもありなのか
    行列を考えるとさらに面倒だな

    やはり現状のが自然か

    演算子多重定義はことほど斯様に難しいということで。 

    
軍オタが好きな名言、名ゼリフ　Ausf 

66 名無し三等兵 [sage] Date:2009/02/05(木) 01:12:30 ID:??? Be:
    「人類にとっては小さな一歩だが、
    　　　　俺にとっては大きな一歩だ」

    　　　　　ピート　コンラッド　人類2度目の月着陸船アポロ12号船長 

68 名無し三等兵 [sage] Date:2009/02/05(木) 16:21:52 ID:??? Be:
    >>66
    それは
    「ニールのやつには小さい一歩かもしれんが、俺様にはでけえ一歩だぜ」
    でなかったか？ 

69 名無し三等兵 [sage] Date:2009/02/05(木) 19:09:42 ID:??? Be:
    「ひとりの人間にとっては小さな一歩だが、人類にとっては大きな飛躍である」
    アポロ１１号　二ール・アームストロング

    「ヤッホー！二ールにゃ小さい一歩でも、俺にはでっけえ一歩だぜ！」
    アポロ１２号　ピート・コンラッド海軍大佐

    「長い道のりだったが、今俺達はここにいる」
    アポロ１４号　アラン・シェパード海軍大佐

    「人間は冒険しなくてはならない、そしてこれは人類史上最大の冒険である」
    アポロ１５号　デイヴ・スコット空軍大佐

    「おお、我がいとしのデカルト高原よ、アポロ１６号が未知と神秘に満ちたお前を解き明かすことになるだろう」
    アポロ１６号　ジョン・ヤング海軍大佐

    「歴史は、今のアメリカの挑戦が人類の未来を築き上げたことを記録することになるだろう」
    アポロ１７号　ジーン・サーナン海軍大佐 

83 名無し三等兵 [sage] Date:2009/02/06(金) 15:57:11 ID:??? Be:
    「大陸は、孤立した!!」

    　　イギリス人　　（ヒトラーの英仏海峡封鎖により、イギリスの方が孤立した時の新聞見出し） 

89 名無し三等兵 [sage] Date:2009/02/07(土) 03:57:03 ID:??? Be:
    >>83
    いいなあ
    さすがジョンブル
    首を絞められながらでも強がりを言える
    そこが大英帝国魂ってやつだな 

90 名無し三等兵 [sage] Date:2009/02/07(土) 07:53:13 ID:??? Be:
    物は言いようってことを感じさせないブリテン 

91 名無し三等兵 [sage] Date:2009/02/07(土) 17:24:49 ID:??? Be:
    　" Charlie don't surf ! "　（ベトコンがサーフィンをするかっ!）

    　　　第１騎兵師団　ビル・キルゴア米国陸軍中佐（映画"地獄の黙示録"より）

    　　※意味は訳のとうりであるが、米国の敵に対する蔑みの感情の表れとも解釈されている。
    　　　　（キルゴア好きにはどうでも良いことだがw） 

93 名無し三等兵 [sage] Date:2009/02/07(土) 21:19:13 ID:??? Be:
    >>91
    「チャーリーは波に乗らない」 - Call of Duty 4

    アクティビジョン翻訳は迷言の宝庫だぜ 

94 名無し三等兵 [sage] Date:2009/02/07(土) 22:08:02 ID:??? Be:
    >>93
    たしかにCoD4の他のミッションタイトルにも、
    本来の深い意味があるのでは？と考えさせられますw

    誰だそのアクティビジョン翻訳とやらを手がけたのはw 

    
軍オタが好きな名言、名ゼリフ　Ausf 

38 名無し三等兵 [sage] Date:2009/01/31(土) 17:57:55 ID:??? Be:

    「合言葉は―自由。目標、ﾘｻｶ。23時」

    (コルスン包囲戦時、解囲部隊の消耗により独力で包囲突破を目指さざるをえなくなったコルスン包囲下『シュテマーマン戦闘団』の指揮官シュテマーマン大将に対して。)
    「マンシュタイン」

    シュテマーマン大将は殿部隊を指揮し、戦死する。

    こーゆーのに弱いのよねえ。 → コルスン包囲戦 - Wikipedia

    ■_

    以下後でチェック。 

    The Best Place to Start Learning C++ - Stack Overflow
http://stackoverflow.com/questions/525726/the-best-place-to-start-learning-c

What is the best language to focus on when starting as a programmer? - Stack Overflow
http://stackoverflow.com/questions/525790/what-is-the-best-language-to-focus-on-when-starting-as-a-programmer

Hidden features of Lua - Stack Overflow
http://stackoverflow.com/questions/523867/hidden-features-of-lua

What would your own programming language look like? - Stack Overflow
http://stackoverflow.com/questions/525425/what-would-your-own-programming-language-look-like

    2009年02月07日

    ■_

    ・そうかアキバUDXでまつもとさんがってのは今日だったのか

    ・WindowsMobile用の2ch専用ブラウザで新しいのを知ったちょっと試してみる。

    ・はてなダイアリーがRSSリーダを拒否している件 - ここにいるだれか
    なんだってーっ(AA 略)。 sage と cococ 併用してて sageでは問題なくとれてたから変だとは思ってた。 とはいえ cococってUAどこで設定するんだ?

    ・Gyao
    うは、イデオンがあるw http://www.gyao.jp/sityou/catedetail/contents_id/cnt0051749/ 無料配信は第一話だけなのか。

    ■_ 記憶の上書き

    shiro さんにチェックされていたので 

    Shiro
(2009/02/06 12:31:32 PST 文字列検索)


    
  
    文字列検索 - ときどきの雑記帖 i戦士篇

    KMPとかBM ってマルチバイト文字とか幅広文字に使うの面倒だよねえ。 
  
    

    

* BMはナイーブに書くと文字集合と同じ大きさのテーブルが必要になっちゃうけど、 utf-8文字
  列ならオクテット列に対して直接使えるからテーブルエントリは256で済む。
* KMPのリスタートベクタは文字集合の大きさとは関係無く検索文字列の長さで決まるから wide 
charでもutf-8なmultibyte charでもさして問題ない。 

というわけで、mb1 : utf-8のように文字境界を誤ることのないmultibyte encoding、
mb2 : euc-jpのようにランダムアクセスで文字境界が確定しないmultibyte encoding、
とすると、こんなふうに理解してる：
	wchar 	mb1 	mb2
BM 	× 	○ 	×
KMP 	○ 	○ 	×

    BM をナイーブに実装した場合というのは念頭においていました。また、 UTF-8の場合なんですが、確かに256個のエントリがあればというのはそのとおりなんですが、 性能的にどうかというのを以前ちょっとだけ考えたことがあります。 つまり、本来意図している文字ではないけれどもバイトの並びが同じ部分がある文字が たくさんあるような場合に性能向上はシングルバイトよりは小さいだろうと。 暇があったら一遍計測してみようかとも思っているのですが例によって[お察しください]。 文字をまたいだマッチの心配はしないでいいのはありがたいですね。 以前どこかで、ShiftJISだかEUC-JPだかの文字列に対してBM使えるように修正した とかいうのを見た記憶があるんですが、さてどこだろう(年単位での過去の話なので ほとんど忘却のかなた)。

    KMP については… あまりに使ってこなかったので、アルゴリズムが部分的に BMで上書きされてたみたいです ○|￣|＿ 1) 表を作る 2) 後戻りしない というのは覚えていたのですが、その表がどういうものだかが BMに摩り替わっていたという。 クヌース-モリス-プラット法 - Wikipedia 

    Knuth-Morris-Pratt algorithm

void preKmp(char *x, int m, int kmpNext[]) {
   int i, j;

   i = 0;
   j = kmpNext[0] = -1;
   while (i < m) {
      while (j > -1 && x[i] != x[j])
         j = kmpNext[j];
      i++;
      j++;
      if (x[i] == x[j])
         kmpNext[i] = kmpNext[j];
      else
         kmpNext[i] = j;
   }
}


void KMP(char *x, int m, char *y, int n) {
   int i, j, kmpNext[XSIZE];

   /* Preprocessing */
   preKmp(x, m, kmpNext);

   /* Searching */
   i = j = 0;
   while (j < n) {
      while (i > -1 && x[i] != y[j])
         i = kmpNext[i];
      i++;
      j++;
      if (i >= m) {
         OUTPUT(j - i);
         i = kmpNext[i];
      }
   }
}



    Boyer-Moore algorithm

void preBmBc(char *x, int m, int bmBc[]) {
   int i;
 
   for (i = 0; i < ASIZE; ++i)
      bmBc[i] = m;
   for (i = 0; i < m - 1; ++i)
      bmBc[x[i]] = m - i - 1;
}
 
 
void suffixes(char *x, int m, int *suff) {
   int f, g, i;
 
   suff[m - 1] = m;
   g = m - 1;
   for (i = m - 2; i >= 0; --i) {
      if (i > g && suff[i + m - 1 - f] < i - g)
         suff[i] = suff[i + m - 1 - f];
      else {
         if (i < g)
            g = i;
         f = i;
         while (g >= 0 && x[g] == x[g + m - 1 - f])
            --g;
         suff[i] = f - g;
      }
   }
}
 
void preBmGs(char *x, int m, int bmGs[]) {
   int i, j, suff[XSIZE];
 
   suffixes(x, m, suff);
 
   for (i = 0; i < m; ++i)
      bmGs[i] = m;
   j = 0;
   for (i = m - 1; i >= 0; --i)
      if (suff[i] == i + 1)
         for (; j < m - 1 - i; ++j)
            if (bmGs[j] == m)
               bmGs[j] = m - 1 - i;
   for (i = 0; i <= m - 2; ++i)
      bmGs[m - 1 - suff[i]] = m - 1 - i;
}
 
 
void BM(char *x, int m, char *y, int n) {
   int i, j, bmGs[XSIZE], bmBc[ASIZE];
 
   /* Preprocessing */
   preBmGs(x, m, bmGs);
   preBmBc(x, m, bmBc);
 
   /* Searching */
   j = 0;
   while (j <= n - m) {
      for (i = m - 1; i >= 0 && x[i] == y[i + j]; --i);
      if (i < 0) {
         OUTPUT(j);
         j += bmGs[0];
      }
      else
         j += MAX(bmGs[i], bmBc[y[i + j]] - m + 1 + i);
   }
}

    なんで混同してたんだろう○|￣|＿

    ん? なんだ Turbo って。 Turbo-BM algorithm あー、こっちがふつーBMって言ってるやつか(微妙に違うけど)。 表を二個使ってがんばるという。

    ■_

    マ板は死屍累累だなあ。 

    【ぼくの権利を守って】使えない新人 0x19 
31 仕様書無しさん [sage] Date:2009/02/05(木) 06:55:28  ID: Be:
    ここ数年は入社時点で普通にプログラム書ける子が多い。

    今年も全員当たりを引きますように。 

32 仕様書無しさん [] Date:2009/02/05(木) 07:36:25  ID: Be:
    プログラム経験一切無いのに採用する会社もすげえ。 

33 仕様書無しさん [sage] Date:2009/02/05(木) 07:53:53  ID: Be:
    キーボードすら触ったことないやつらばっかりだぞ
    コピーの事すらしらず同じ単語を永遠と書いてるゴミもいた 

35 仕様書無しさん [] Date:2009/02/05(木) 10:20:38  ID: Be:
    >>32-33
    最近は、昔みたいに趣味でパソコンを触って、独学で勉強して、
    パソコンをもっと使いたい、俺はこれで仕事がしたい！で就職活動している人の
    割合が鬼のように少ないからな。

    最近のこの業界にくるやつのちゃらんぽらん思考は
    　「金が稼げるらしい。極めれば月1000万とかも可能。」
    　「最先端の仕事らしい」
    　「製品の開発中から触れるらしい」
    　「IT関係って言えばかっこいい」
    　「私服で仕事できて時間も自由に決めれるらしい」
    ってのが多くなってきている。

    せめて、「パソコン触ったことないです」「家にはパソコンなんてありません」なんて奴は
    採用枠からはずせよ、と思うのだが・・・ 

36 仕様書無しさん [sage] Date:2009/02/05(木) 11:50:38  ID: Be:
    そういう若者の甘い期待をぶち壊すことに
    悦びを見出す人たちもいるのだろう

    それでもなおしぶとく生き残った奴らが逞しく成長していくことに
    悦びを見出す人たちもいるのだろう

    奇麗事だけじゃやっていけないのは自明の理 

39 仕様書無しさん [sage] Date:2009/02/05(木) 13:56:17  ID: Be:
    >>35
    それは学生が悪いんじゃなくて、
    進路指導の先生が軒並み現実を理解していないのが諸悪の根源。

    俺は兄貴がケータイ開発やっていたので現状をいろいろ聞いていたが、
    進路指導の先生（本とかいろいろ出しているそこそこ有名な教授の弟）に
    相談したら　
    「いまや飛ぶ鳥を落とす勢いの最先端の現場だ、
    　携帯電話を作るなんて相当IQが高い人間じゃないと無理だ。
    　君の成績では、そんな大企業に入るなんて無理じゃないかな」
    とか言われた。

    大企業じゃなくて、提携している会社に入って、そこから出向するんですと言ったら
    「携帯電話は全て自社で作っているんだぞ。そんなことも知らないのか」
    と偉そうな顔して論じられた。

40 仕様書無しさん [sage] Date:2009/02/05(木) 15:17:59  ID: Be:
    だって大学の先生だもの(´・ω・｀) 

41 仕様書無しさん [sage] Date:2009/02/05(木) 18:17:59  ID: Be:
    > 本とかいろいろ出しているそこそこ有名な教授の弟

    > の弟 

52 仕様書無しさん [sage] Date:2009/02/07(土) 10:03:31  ID: Be:
    幸い自社じゃないんだけど、客先の新人が激しく使えない。
    昨日、資料をメールで送ってもらう約束になってたんだが
    夕方になっても来ないんで電話したら
    「何度送っても”送信できません”ってなるんですよ！」
    「もう何度も！何度も！何十回も送ってんですよ！」
    「だから今日の午後ほか何にも仕事できなかったんですよ！」
    「お宅のメールサーバおかしいんじゃないの！？」
    とぶち切れてた。

    送信アドレス確認したらドメイン名間違ってやがった。
    ドメイン名、英語のスペルなんだから
    途中の"o"(オー)を"0"(ゼロ)を間違うなよ・・・
    て言うか、よそ様のサーバの心配する前に自分の作業疑えよ・・・

    んで、こっちからメール送るからそれに返信してくれって
    頼んだんだけど、メール送ってもまた音沙汰なし。
    また確認の電話したら、相変わらず送れないと切れてた。
    送ったメールに返信しろってのが理解できず、送ったメールの
    メールアドレスを見て、送信先を手打ちしてやがった。
    で、お約束のようにタイプミスで配信不能になってた。
    最後までこっちのメールサーバのせいにして、午後が丸つぶれに
    なったと腹を立ててた。

    客先の親しい人にチクっといた。 

53 仕様書無しさん [sage] Date:2009/02/07(土) 13:28:03  ID: Be:
    >>52
    いや、それ以前に

    「他社にメールを送る場合、ccに必ず上長を入れておく」
    という常識を教えておいたほうがいいような気がするけどな。 

54 仕様書無しさん [sage] Date:2009/02/07(土) 13:33:05  ID: Be:
    ゆとりに何を言っても無駄ｗ 

55 仕様書無しさん [sage] Date:2009/02/07(土) 13:40:14  ID: Be:
    >>53
    まじでccに上長つけなかあんの？
    報告書になんもつけてないんだけどｗ
    注意もされなかったって事は呆れられてるん？ 

56 仕様書無しさん [sage] Date:2009/02/07(土) 13:44:30  ID: Be:
    >>55
    入れておけば何かあったときに上長の責任問題にできることがあるｗ 

    スレッドを立てるまでもない質問雑談スレ36
57 仕様書無しさん [] Date:2009/02/07(土) 10:57:25  ID: Be:
    システムエンジニア
    出典: フリー百科事典『ウィキペディア（Wikipedia）』

    プログラマとの違い
    システムエンジニアがプログラム仕様を作成し、それに基づいてプログラマがプログラミングを行う



    ってことはプログラムも書けない奴がSEってことなんですか？
    プログラム書けないけどLAN構築だけは分かりますって程度の。
    予算考えずにとりあえず高いアンチウイルスソフト入れてみましたっていう。
    家のパソコンはバイオ。壊れたらとりあえず電気屋で修理みたいな。
    コマンドプロンプトできねーけど、エクセルとワードできますみたいな。

    そういう奴がSEってことだろ？


58 仕様書無しさん [sage] Date:2009/02/07(土) 11:03:46  ID: Be:
    プログラマからSEに昇格するんだよ

59 仕様書無しさん [sage] Date:2009/02/07(土) 11:12:10  ID: Be:
    PG と SE とは本来全く別物だろ。

    今回、初めて自分のプログラムの面倒を最後まで見ることが出来なかった。
    他人のケツ拭きならさんざんやったけど、される方ってこんな気持ちなのか。
    それともなにも感じてなかったのか。悔しい。。。 

61 仕様書無しさん [sage] Date:2009/02/07(土) 11:55:01  ID: Be:
    >>58
    肩書き的には昇格だが
    そのときに大事なものを喪ってしまうんだ 


    

この会社辞めようと思った腐れ上司の一言0x23
728 仕様書無しさん [] Date:2009/02/04(水) 10:00:34  ID: Be:
    昨日
    『すまん、割り込みになるが最優先でここのチームのフォローに回ってくれないかな』
    「わかりました」

    で自分の作業を一旦停止にして不具合だらけのチームのフォローに回ることになった。


    先ほど
    『連日ですまんが、あっちのチームもフォローしてやってくれ。今週末仮納品なのにまだ単体試験もできてないんだ』
    「え、いや、今フォローしているチームも今週末仮納品なのに不具合だらけでまともに動かないんですよ。両方は無理です」
    『そこをなんとか。』
    「どうしてもというなら、どちらを優先するべきですか」
    『そこは、君が自分で考えるべきことだろう』


    無茶だろと。なんで俺が優先度設定できるんだ。どっちも緊急だろうが。
    とりあえず　「両方は無理なので、ひとまず昨日のフォローを続けます。他をあたってください」と言って切ったが、
    なぜ依頼だけしておいてどちらかひとつを取れとかいう無茶な選択肢を突きつけるんだ。氏ねよ。 

729 仕様書無しさん [sage] Date:2009/02/04(水) 10:29:32  ID: Be:
    >>728 ２シフトこなせば無問題ということだな。

    どうしても一つ選ぶ必要があるなら自分で考えろ、もしくは体壊してでも両方ともやれ。
    どちらか落ちた場合は君の責任。体壊しても君の選択だから君の責任。

    選択権は君にある。 

730 仕様書無しさん [sage] Date:2009/02/04(水) 11:57:10  ID: Be:
    上司は「どっちもやれ、でもどっちか優先しろ。自己責任で。」と言っているんだろ。
    そりゃムチャだわ。

734 仕様書無しさん [sage] Date:2009/02/04(水) 20:01:34  ID: Be:
    >>728
    おれなら「最初のがNMIですから」と答えて反応を見る。

    似たような経験あるなあ(苦笑い 

    

この会社辞めようと思った腐れ上司の一言0x23
651 仕様書無しさん [] Date:2009/01/31(土) 12:32:34  ID: Be:
    自分の手伝いさせるために何人も休日出勤させといて
    肝心の自分は来ないって、馬鹿なの死ぬの？ 

653 仕様書無しさん [sage] Date:2009/01/31(土) 12:42:28  ID: Be:
    >>651
    管理職は指示だけ出していればいいんだよ。
    最終的な責任さえ取れれば、ね。

    部下が五月雨式に転属願いを出したら面白い事になるだろうね 

654 仕様書無しさん [] Date:2009/01/31(土) 13:29:00  ID: Be:
    >653
    PMのくせにやらなくてイイって言ってんのにモジュール1つ
    自分で担当して、そのくせセミナーだ旅行だインフルエンザだで
    全然手がつかないままやばい時期まで来た

    先週のうちに手伝いましょうかと申し出た時は、
    いろいろ考えて進めてるから手を出すなとまで言われた

    それが昨日の17時になって実は進捗0と判明して、
    開き直って明日分担してやろうな、と 

655 仕様書無しさん [sage] Date:2009/01/31(土) 13:37:10  ID: Be:
    >>654
    マネジメントできてねぇww

    ↓コピペシリーズ 

    
この会社辞めようと思った腐れ上司の一言0x23

739 仕様書無しさん [saga] Date:2009/02/06(金) 00:44:51  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　　　 「早く済んだのなら△△君の仕事手伝ってあげなさい。」


    退職を決断した瞬間であった。 

751 仕様書無しさん [sage] Date:2009/02/06(金) 14:32:00  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　　　 「早く済んだのなら△△君の仕事手伝ってあげなさい。」
    　俺　「残業代フルででますよね。△△君みたいにタバコ休憩ばっかしてて
    　　　　仕事がいつまで経っても終わらない人の手伝いをするんですから、
    　　　　別途特別手当もほしいぐらいです」


    俺こう言い切って、手伝い組に入らずに済んだことあるけどな。

    結局その△△君がある日突然仕事場に出てこなくなり、連絡つかなくなり
    どうしようもなく手伝う羽目になったが。（手伝うというか引き継いだというか） 

758 仕様書無しさん [sage] Date:2009/02/06(金) 20:18:18  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　俺　「いけませんか？」

    定時退社は俺のポリシーだ 

762 仕様書無しさん [sage] Date:2009/02/06(金) 21:28:36  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　俺　「朝残してますからね。」 

763 仕様書無しさん [sage] Date:2009/02/06(金) 22:13:09  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　俺　「いいえ？」

    影が薄いのかなあ。 

764 仕様書無しさん [sage] Date:2009/02/06(金) 22:31:04  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　俺　「わたしが定時で帰る事により△△さん（上司）に気を遣わせまいという」 

765 仕様書無しさん [sage] Date:2009/02/06(金) 22:39:59  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰れ！」
    　俺　「好きにさせて！」

766 仕様書無しさん [sage] Date:2009/02/06(金) 22:42:38  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、定時で帰りたければわたしを倒してからにしろ！」
    　俺　「ここで出会い、拳で語るもまた宿命か・・・」 

767 仕様書無しさん [sage] Date:2009/02/06(金) 22:44:56  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、定時で帰ってくれないか；；」
    　俺　「鍵閉めても気になってたまらないんでしたね、課長は・・・」 

768 仕様書無しさん [sage] Date:2009/02/06(金) 22:47:05  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、国定忠治についてどう思うかね？」
    　俺　「呉越同舟、って奴でしたっけ？」 

769 739 [sage] Date:2009/02/06(金) 23:28:16  ID: Be:
    ちょｗｗｗｗｗ
    俺のレスがこんなに使い回しされるとはｗ
    糞ﾜﾛﾀｗｗ 

773 仕様書無しさん [sage] Date:2009/02/07(土) 04:53:25  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　俺　「定時って24時のことですか？」 

774 仕様書無しさん [sage] Date:2009/02/07(土) 08:58:57  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　俺　「定時って24時のことですか？」
    俺の彼女「いつも仕事大変よね」
    　俺　「うん、周りもみんな残ってるしね。」
    俺の彼女「ところで、あなた仕事できないの？転職考えたほうがよくない？」
    　俺　「いきなりなんだよ」
    俺の彼女「馬鹿でどうしようもないからズルズル職場にいる人って、太るのよね」
    　俺　「○×■△！！！！」
      

775 仕様書無しさん [sage] Date:2009/02/07(土) 09:19:50  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　俺　「残業規制かかってますからね」

776 仕様書無しさん [sage] Date:2009/02/07(土) 10:33:53  ID: Be:
    上司 「○○君、ちょっと…」
    　俺　「はい」
    上司 「キミ、いつも定時で帰ってるよね。」
    　俺　「残業規制かかってますからね」
    上司 「このあと・・・どうだい？」
    　俺　「俺のリビドーに、規制はかかりませんよ？」

    上司＆俺「アッーーーー！」

    ■_

    あとで(ry

    2009年02月06日

    ■_

    ・週刊ベースボール
    今週号は毎年恒例の選手名鑑号なのか。

    ■_ ネタにのってみる

    c言語が持っていなかったせいで書式が統一されてなくて困る要素 - くらげのChangeLog
2009-02-03

■[ネタ]c言語が持っていなかったせいで書式が統一されてなくて困る要素

c言語が悪いわけじゃないけど、困る。

文字列結合演算子

そもそも文字列が存在しなかったc言語と、「+」オペレータを文字列結合っぽい動作として割り
当てていたc++言語のせいで、明らかに異なる動作である加算演算子と文字列結合演算子が同じ
記号になっている処理系は多い。

また、文字列結合演算子がある場合も、「.」(php)だったり、「&」(vb)だったり、「||」
(oracle)だったりと安定しないこと甚だしい。

foreach構文

c言語の頃はそもそもforeachという概念が存在しなかったため、c言語ライクな言語でもforeach
構文が安定しない。

forキーワードでなくforeachキーワードを使って見たり、繰り返すべき要素を示すキーワードが
inだったりasだったり=>だったり。

連想配列リテラルの書き方

配列は[a, b, c]で統一されているのに、連想配列になるととたんに書き方がバラバラになる。

継承元、インターフェイスの書き方

c++がもっと分かりやすい書き方にしてくれていれば……！

    そういや配列(やコレクション)に対する foreach (添え字変数がない)ループって 何が元祖で、いつ頃実装されたものなんだろう? ってUNIX shell のあれがそれっぽい?

    「文字列」という型があって、その連結をする「演算子」を持った言語って何が最初だろう? awk は「演算子」ないしw そういや VBとかVBAは文字列の連結は確かに & だけど、 昔のBASIC て + つかってなかったっけ?

    ■_ あとで(ry

    正規表現がどうのというと読まずにはいられないw グーグル、「Google Chrome」高速化で新たな取り組み--独自の正規表現を実装:ニュース - CNET Japan 

    グーグル、「Google Chrome」高速化で新たな取り組み--独自で正規表現を実装:ニュース - CNET Japan
 JavaScriptの他の部分は改善してきたが、他の部分よりも正規表現の遅れが目立ち始めた。そ
こで、われわれは、外部ライブラリを利用するよりも、われわれの既存のインフラと統合するこ
とにより、JavaScriptの性能が向上するはずだと考えた」と述べている。

 その結果として、Google独自のプロジェクトである「Irregexp」が生まれた。Irregexpは、新
しい開発者向けプレビュー版「Chrome2.0.160.0」の重要機能（リリースノートはこちら）とな
っている。ネイティブコード生成、バックトラッキング回避、中間オートマトン表現に関して
Googleが選んだ技術的な詳細に関心のある方はブログ投稿を参照されたい。

    んで、 

    
Chromium Blog: Irregexp, Google Chrome's New Regexp Implementation

Irregexp, Google Chrome's New Regexp Implementation

Wednesday, February 04, 2009

One of the new features in the most recent dev-channel release of Google Chrome 
(2.0.160.0) is Irregexp, a completely new implementation of regular expressions 
(regexps) in the V8 JavaScript engine. Irregexp builds on V8's existing infrastructure 
for memory management and native code generation and is tailored to work well for the 
kinds of regexps used by JavaScript programs on the web. The result is a considerable 
improvement in V8's regexp performance.

Google Chrome の至近の dev-channel リリース (2.0.160.0) での新機能の一つに
Irregexp があります。これは V8 JavaScript エンジン向けの完全に新規な正規表現実装です。
Irregexpは


While the V8 team has been working hard to improve JavaScript performance, one part of 
the language that we have so far not given much attention is regexps. Our previous 
implementation was based on the widely used PCRE library developed by Philip Hazel at 
the University of Cambridge. The version we used, known as JSCRE, was adapted and 
improved by the WebKit project for use with JavaScript. Using JSCRE gave us a regular 
expression implementation that was compatible with industry standards and has served 
us well. However, as we've improved other parts of the language, regexps started to 
stand out as being slower than the rest. We felt it should be possible to improve 
performance by integrating with our existing infrastructure rather than using an 
external library. The SquirrelFish team is following a similar approach with their 
JavaScript engine.

    ■_ 追加とか訂正とか

    arton さんから 「だといやだよね」というような憶測を喋ったので、実際にどうかは読んでいないのでわからないです。 と指摘されたので、昨日メモから写し忘れた分を含めて追加で。 えーとまずこの指摘の部分ですが、 たぶんこっちの聞き落としの面のほうが強いと思うので気を使わせるようなことをさせて申し訳ないです。

    でまあ箇条書きで印象に残った部分など。 

    高橋会長もスーツ姿で登場でした。
artonさんはFSF (GNU) のパーカー?
(外見的に)会場のスーツ率高し


コーディングの掟編
・ダメだった事例を見せることによる教育効果
・文体に注意すると、その章を誰が書いたのか見分けられます
・想定していた読者層は開発リーダーとかその上とか
   (バリバリ自分でプログラム組む人ではない。知識も怪しい?)
  コーディングを自分はしないでも(したことがなくても)人であっても、
  コーディングを「わかってない」のはまずいだろう。

・台帳駆動システム
  ハンコがないとクラスも作れないとかあります
  あんな面倒なシステム誰が得をするの?
  デグレったときのお客様向けの説得材料になる
    ex (ほら、こうやって再発防止を(ry
  svn とかから台帳の自動生成ってできないの?

・バージョン管理システムの説明でcvsを使ったわけ
  ・subversion とか git とかだと、自分でインストールしなければならない(ことが多い)
    でも cvs ならLinux のどのディストロでもあるっしょ?
 → 「インストール」という手間があると、嫌がる人は多いです

・Eclipse からしかcvs (など)を使えない人がいるらしい

・マルチスレッド難しいよね
   難しいから使っちゃいけないという人たちがいる
   PHPでよかった (高橋会長)
   レースコンディションを理解しておこう
   スレッドを使ったほうが良い場合/良くない場合を見分けよう
　　なんでもかんでもクリティカルセクションに放り込む人がいる

・泥水をすすったことがない(現場を知らない)作戦本部の人と、
  現場のたたき上げの「鬼軍曹」
    → でもその鬼軍曹も、知識が50年前のものだったりする。
       今役に立つもの? 逆効果だったりしない?


Ruby本編

・(本の内容に関して)伏線張ってます
・内容 (contents) と 表現 (representation)
・オブジェクト指向の説明で、
   dog と cat を使うとケチつけるやつがいるけど、rectangle と triangle なら
   そういう批判? も受けにくくなるのではないか

・「プログラミングの入門書」で、ユーザーが打ち込んだソースプログラムが
   どういう過程を経て処理がなされてコンピューターがどのように実行するか
　　をきちんと 説明してないのはまずいんじゃないの?
    → ということでこの本ではちゃんと書いています
       字句解析とか構文解析とか(入門者が引っかかる「エラー」なんてのは
       大概このレベルで引っかかるもの(構文エラーとか)だから。

・編集サイドから「コンソールベース」でやってくれという希望がだされてました。
・1 の先頭から70ページくらいまでは「書き手の良心」です。
　　(hello,world が84ページ目)

・口で言ってもわからないやつには手を動かさせる

・オレ様実装をやってみた後でライブラリをつかう。
   ・シーザー暗号 → AES
   ・連長圧縮 (ランレングス) → zlib
   実装の何たるかを知るために「車輪の再実装」をやることは有用。
   なんでもかんでも「車輪の再発明」にして止めさせるのは良くないだろう
   自分で作ってみたうえで(からくりを理解して)、できの良いライブラリを使わせてもらう

・世にある「入門書」はユーザーが打ち込んだプログラムがどのように処理されて
 どう実行されるのか説明していないんじゃない?

・字句解析と構文解析の説明を入れたのは、入門者がひっかかるエラーというのは
  大半がここでひっかかるものだから(シンタックスエラーとか)
・全角スペースを入力してエラーというのを避けるために、コードはASCII限定でがんばった。
  鶴亀算でも鶴の英語表記を辞書で調べて変数名つけました


JavaとRuby編
   第4章と第5章が一番書きたかった部分


    JavaScript(1) はじめてのプログラミングとJavaScriptの基礎
PHP(1) はじめてのPHPプログラミング	翔泳社
Ruby(1) はじめてのプログラミング	翔泳社

    PHPだけ「はじめてのPHP～」になっているのはなにか深い意味が?

    ■_ 

    Ｃ言語なら俺に聞け（入門篇） Part 43
970 デフォルトの名無しさん [sage] Date:2009/02/07(土) 00:19:32  ID: Be:
    ポインタなら俺に聞け 

971 デフォルトの名無しさん [sage] Date:2009/02/07(土) 00:27:00  ID: Be:
    ポインタは分かるがダブルポインタが分からない 

972 デフォルトの名無しさん [sage] Date:2009/02/07(土) 00:28:33  ID: Be:
    はいはい 

973 デフォルトの名無しさん [sage] Date:2009/02/07(土) 00:43:03  ID: Be:
    ダブルポインタはないわー 

974 デフォルトの名無しさん [sage] Date:2009/02/07(土) 00:48:10  ID: Be:
    ポインタのポインタをダブルポインタって呼ぶのがそもそもおかしいんだよ

    日本銀行は銀行の銀行だけどダブル銀行って呼んだらおかしいだろ？ 

975 デフォルトの名無しさん [sage] Date:2009/02/07(土) 00:49:49  ID: Be:
    別に何もダブルになってないもんな

    自分もそう思ったことがあって調べてみたことがあるんだけど、 英語圏でも double pointer って言い方は結構しているみたい。 double pointer usage - High Level Programming - The UNIX and Linux Forums Arrays and pointers in C Use of double pointer in functions - C 

    【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
781 デフォルトの名無しさん [sage] Date:2009/02/06(金) 02:17:40  ID: Be:
    pythonはヨーロピアンな感じがするな…と思ってたら、オランダ人か。
    それに比べて、perlはアメリカ臭が強すぎ。
    ちょうどCとPascalに感じた匂いの差を感じる。(Pascalはスイス人？)

    どうもヨーロッパ発祥だと、実装効率を多少犠牲にしてでも、言語の
    一貫性とか、美観にこだわる(ような気がする)ところに好感が持てる。
    それに比べると、アメリカ性言語は…なんというか粗雑… 

782 デフォルトの名無しさん [sage] Date:2009/02/06(金) 02:22:00  ID: Be:
    C++のBjarne Stroustrupはデンマーク人だが 

784 デフォルトの名無しさん [sage] Date:2009/02/06(金) 02:57:55  ID: Be:
    >>780
    逝って下さい 

785 デフォルトの名無しさん [sage] Date:2009/02/06(金) 03:14:51  ID: Be:
    Pascalは実装効率犠牲にしてないぞ 

786 デフォルトの名無しさん [sage] Date:2009/02/06(金) 03:16:04  ID: Be:
    >>783
    ある夜 


    Prologでまったり Part3 
868 デフォルトの名無しさん [sage] Date:2009/02/03(火) 17:57:45  ID: Be:
    なんで Prolog の人ってソクラテスが好きなの？死ぬの？ 

869 デフォルトの名無しさん [sage] Date:2009/02/03(火) 18:45:07  ID: Be:
    >>868
    実は出典知らない。
    >死ぬの? ヨーロッパ人にとって死とは絶対の証であって、忌み嫌う対象では
    ないと犬養道子が書いていた。十代に読んだ随筆がトラウマのような状態に
    なっていて、すぐこのことを思い出してしまう。

870 デフォルトの名無しさん [sage] Date:2009/02/03(火) 21:40:45  ID: Be:
    http://mtlab.ecn.fpu.ac.jp/turing_ihon.html
    > もっとも、ソクラテスの名前があるといかにもアリストテレスが言いそうだなと
    > 思ったりするんですが、アリストテレス本人はソクラテスといった固有名は三段論法には
    > 含めないことにしてたみたいです。つまり、このソクラテス云々って例は、後の世の人が、
    > 三段論法に固有名詞も含めちゃうことにしちゃって、それから作られて広まったもんみたいです。

    へえ 

871 デフォルトの名無しさん [sage] Date:2009/02/03(火) 22:32:28  ID: Be:
    "Socrates is mortal"の初出ってどこなんでしょうね。論理学書として非常に影響力のあった、

    　J. S. Mill, A System of Logic, Ratiocinative and Inductive, vol.1, 1843.

    にも登場してるのが確認できますが、中世の論理学書あたりに出てきそうなフレーズですね。

    http://books.google.com/books?id=y4MEAAAAQAAJ&printsec=titlepage&as_brr=3&hl=ja&source=gbs_summary_r&cad=0#PPA228,M1 


    プログラミング言語 Scala 
689 　 [sage] Date:2009/02/04(水) 10:00:11  ID: Be:
    Scala初心者なんですけど
    val a = List(1,2,3,4)

    とした後

    a.foreach( println( _ ) )
    a.foreach( x => println( x + 3) )

    はエラーにならないのに

    a.foreach( println( _ + 3 ))

    はエラーになります。どうしてですか？ 

690 デフォルトの名無しさん [sage] Date:2009/02/04(水) 13:01:34  ID: Be:
    a.foreach( println( x => x + 3 ) ) 
    と展開さえてエラーになってるみたいだね。
    理由や原理は分からないけど。 

691 　 [sage] Date:2009/02/04(水) 17:25:00  ID: Be:
    expanded functionなんたらっていうエラーメッセージはそういう意味なんですか。
    この略記法みたいのは、展開のしくみがよくわからないから複雑なのには自重しときますか。
    ありがとうございました。 

692 　 [sage] Date:2009/02/04(水) 17:40:31  ID: Be:
    　_ を使った式ががprintlnに対して展開されてるってことですね。foreachではなく。
    そう考えるとa.foreach(println(_))はよくforeachに対して展開されてますね。

693 デフォルトの名無しさん [sage] Date:2009/02/04(水) 21:19:14  ID: Be:
    どう展開されるかはコンパイラの気分次第ってことか？ 

694 デフォルトの名無しさん [sage] Date:2009/02/04(水) 21:30:45  ID: Be:
    println( _ + 3 ) は「+ 3」を解決するために _ を評価しなければならなくなる
    からでわ？
    println( _ ) だと println を評価するまで _ の評価を遅延できるのに対して 

695 デフォルトの名無しさん [sage] Date:2009/02/04(水) 21:42:00  ID: Be:
    _が予約語ってどうなの？
    困らない？ 

696 デフォルトの名無しさん [sage] Date:2009/02/04(水) 21:51:03  ID: Be:
    _ 単独で変数名とかクラス名にするやつがいるとは思えないんだが。 

697 デフォルトの名無しさん [sage] Date:2009/02/04(水) 21:57:14  ID: Be:
    _の正確な意味を知るにはScala言語仕様の6.23 Anonymous Functionの
    Placeholder Syntaxを読むのが良いと思う。特に英語圏のブログでScala
    やってる人が多用してる気がするけど、正確な意味を解説した記事ってないんだよな。

    不正確だけどおおざっぱな説明としては、_を囲む最も内側の式が無名関数化される。
    だから、println(_)だと、(x) => println(x)になるけど(_を囲む一番内側の式がprintln(_)
    だから)、println(_ + 3)はprintln((x) => x + 3)になる(_を囲む一番内側の式が_ + 3だから)
    あと、無名関数化される式はsyntactic category(文法定義上の非終端記号みたいなもの)が
    Exprである必要がある。

    基本的に、_がどう展開されるかは純粋に構文的に決まり、型とかは一切関係しない。 

698 デフォルトの名無しさん [sage] Date:2009/02/04(水) 23:17:55  ID: Be:
    println((_)) とかやると内側の括弧で阻害できるのか？ 

699 デフォルトの名無しさん [sage] Date:2009/02/04(水) 23:34:42  ID: Be:
    >>698
    試してみるとわかるけど、それはできない。
    仕様書にはproperly containsという文言があるんだけど
    単に式を囲む(_)は構文解析で_と同じになっちゃって、
    (_) properly contains _とはみなされないということだと思う。 

700 　 [sage] Date:2009/02/05(木) 00:11:19  ID: Be:
    >>697
    おお、わかりやすい説明ありがとう。
    それでちっとまた実験してみた。

    val a = List(1,2,3,4);

    a.map( x => x)
    はエラーにならないけど

    a.map( _ )
    はエラーになった。

    この場合は
    a.map( _ + 3)
    にするとエラーにならない。
    なるほど。 

701 デフォルトの名無しさん [sage] Date:2009/02/05(木) 00:23:42  ID: Be:
    酔っぱらっているので一つだけ。(>>697の括弧が構文解析できないレベル)
    Scalaの_は、C++のboost/bind.hppの_1, _2, _3から来ているんだと思う。
    >>697が解説してくれているけどそっくり。おやすみ 

702 　 [sage] Date:2009/02/05(木) 00:32:11  ID: Be:
    しかし算術式はなにかとくべつなのかな？

    a.filter( 2 < 1 + _ )

    はエラーにならない。
    1 + _ が最も内側の式ではなく　2 < 1 + _を最も内側の式と見てくれる。

    でも
    a.filter( (2).<( 1 + _　) 　)

    だと1 + _　を最も内側の式と見てエラーになる。

    2 < 3 は (2).<(3)と同じことだと読んだような気がするけど 、上の場合は挙動が違う。 

703 　 [sage] Date:2009/02/05(木) 00:35:41  ID: Be:
    あ、でも

    a.filter( 2 < 1 + _　)
    はエラーにならないけど

    a.filter( 2 < (1 + _ )　)
    はエラーになる。
    この場合は ( 1 + _ )が最も内側の式とみなされるから。 

704 　 [sage] Date:2009/02/05(木) 00:42:17  ID: Be:
    明示的にかっこでくくちゃうと、そこでもっとも内側の式とみなされるけど
    演算子の優先順位のためにかっこがいらなければセーフなのか。 

705 　 [sage] Date:2009/02/05(木) 00:58:57  ID: Be:
    ただし明示的な括弧といっても ( _ )は意味がないl。　_ とおなじ。
    それ以外の場合は括弧の段階で一番内側の式とみなされる。 

706 697 [sage] Date:2009/02/05(木) 01:01:19  ID: Be:
    >>701
    >>702
    その辺の挙動は、>>697で最後にさらっと書いたsyntactic categoryというのが絡んでくる。
    >>697では最も内側の式という風に書いたけど、実はもうちょっと正確に言うと、もっとも内側で、
    syntactic categoryがExprの式が無名関数化される。

    まず、
    a.filter(2 < 1 + _)
    についてだが、1 + _の部分だけではInfixExprとみなされる。その外側の
    2 < 1 + _も同じくInfixExprだが、メソッド呼び出しの引数の位置に来ることによって
    Exprに昇格(適当にでっち上げた用語だが)し、結果として、2 < 1 + _が(x) => (2 < 1 + _)
    のように無名関数化される。

    a.filter( (2).<( 1 + _　) 　)

    については、1 + _は同様にInfixExprだが、メソッド呼び出し引数の括弧の位置に
    現れたことによって、Exprに昇格してしまう。そのため、1 + _が無名関数化される。

    a.filter( 2 < (1 + _ )　)

    でも、やはり1 + _はInfixExprだが、式をグルーピングする括弧があることによって、
    Exprに昇格してしまう。そのため、1 + _が無名関数化される。 

707 デフォルトの名無しさん [sage] Date:2009/02/05(木) 01:01:43  ID: Be:
    _はどのくらい強いの？
    括弧以外は突き抜けられるぐらい強いの？ 

708 697 [sage] Date:2009/02/05(木) 01:04:40  ID: Be:
    >>707
    基本的にはメソッド呼び出しの引数の括弧 or 式のグルーピングの括弧が区切りになっているという
    認識で良いと思う。あとは、使っているとなんとなくわかるようになってくる感じ。上では言語仕様の
    記述を元に挙動を説明したけど、そこまで知っていなくてもまあだいじょうぶだと思う。 

709 　 [sage] Date:2009/02/05(木) 01:11:54  ID: Be:
    >>706
    697さん、詳しくわかりやすくどうもありがとう！
    すっきりして寝れます。

    よくわからんがなんかすごそうだw

    ■_ 

    Allegro Barbaro > Delphi書籍プロジェクト、翻訳終わったー、音楽つき。 : ITmedia オルタナティブ・ブログ

Part II: Delphi 2009 とそのコンパイラ
　Chapter 4: IDEの新機能
　Chapter 5: ジェネリクス
　Chapter 6: 無名メソッド
　Chapter 7: その他の言語およびRTLの変更

    あれ、「無名メソッド」?

    2009年02月05日

    ■_

    ・世の中には不思議な人がいっぱいいる
    ジュンク堂池袋店でのイベント。 書店で見かけてもあえて中身を見ないようにしてたんだけど、 執筆時のエピソードを聞いてたりするとかなりの力作であると思った。 つーか三部作ですかっ

    Ruby1 はじめてのプログラミング (CD-ROM付) (プログラミング学習シリーズ) Ruby2 さまざまなデータとアルゴリズム (CD-ROM付) JavaプログラマのためのRuby入門

    しかし最初の二つのシリーズ? でC版も出るってマジですかい? arton さんいわく stack もきちんと説明してないとか何とかいうことらしいですが。 たぶん関数の引数のやり取りのあたりを指していったんだと思うけど、 スタックというものがないハード上のCでプログラム組んだことがありますw どういう風に引数の受け渡しやってたのか思いだせないけど。 多分に事実誤認の可能性がありますので上記の一文は削除します。 arton さんの話の流れでは、Cを使った入門書であればスタックの説明もしないような ものはダメだろうとあったものの、それがこのシリーズのC版にもあてはまるとは 言及されていませんでした。

    「不思議な人」ってのはハッシュ(表のほう)というデータ構造がどういうものか わかってなくてプログラマーやってる人がいるのって信じられないよねえ とかいう話題が途中で出ましたのでまあそゆこと。 質問掲示板見てると、まあさすがにプロのプログラマーではないでしょうが 配列も良くわかってない(知らない)ような方がちらほらと。

    ■_ Orderd Hash

    Ruby 1.9 でハッシュが登録順を保存する Orderd Hashになったということについて Ruby 1.9 Internals: Ordered Hash - igvita.com その最後の部分。 

    Ruby 1.9 Internals: Ordered Hash - igvita.com
Hash performance in 1.8 and 1.9

Ruby mailing list archive is full of heated discussions on whether a Ruby hash should 
be an ordered hash: simplicity vs performance vs least surprise. And strictly speaking, 
the new Ruby Hash is slower, because deletion and insertion requires more pointer 
manipulation. However, value fetch has not changed, and traversal is now much faster 
(since we can just follow the pointers):

→ hash-bench.rb

# Ruby 1.8.7     user   system  total     real
Hash insert      0.350   0.610   0.960   ( 0.990365)
Hash access      0.770   0.010   0.780   ( 0.801897)
Dict insert      1.000   1.240   2.240   ( 2.333807)
Dict access      1.100   0.020   1.120   ( 1.304059)
RBTree insert    4.820   1.000   5.820   ( 6.293545)
RBTree access    5.180   0.110   5.290   ( 6.060176)
 
# Ruby 1.9.1     user   system  total     real
Hash insert      0.650   0.150   0.800   ( 0.828039)
Hash access      0.650   0.000   0.650   ( 0.683463)


The performance numbers are slightly obscured by the fact that the Ruby 1.9 
interpreter is faster to begin with, so we can't attribute the performance gains to 
Hash implementation alone, but I think it highlights the fact that the right decision 
was made: more powerful Hash in 1.9, faster.

Red-Black Trees

One interesting alternative to consider is a Red-black tree, which is a data structure 
commonly used to maintain associative arrays with a nice property of O(log n) access 
time for all operations. Unlike a simple binary tree, a red-black tree introduces 
additional constraints which force it to be a balanced tree after every operation - 
meaning, there are no worst case scenarios as you get in a binary tree. It is a 
nontrivial structure, but thankfully it's also available as a Ruby 1.8 gem: rbtree.

Due to the nice access properties, Red-black tree powers the default ("completely 
fair") scheduler in the Linux 2.6.23 kernel. It turns out, the extra overhead of 
maintaining a tree is well compensated for large tasksets, where the O(log n) runtime 
really delivers.

Unfortunately rbtree is not yet 1.9 compatible, but it is definitely worth a look as 
in certain cases it may be far better suited than a simple Hash.

    是非実測してチョー

    ■_ The History of Python: Early Language Design and Development

    パパの英文て微妙なところで訳しにくいところがあって往生する。 

    The History of Python: Early Language Design and Development
Early Language Design and Development (初期の言語デザインと開発)

From ABC to Python (ABC から Python へ)

Python's first and foremost influence was ABC, a language designed in the early 1980s
by Lambert Meertens, Leo Geurts and others at CWI. ABC was meant to be a teaching
language, a replacement for BASIC, and a language and environment for personal
computing. It was designed by first doing a task analysis of the programming task and
then doing several iterations that included serious user testing. My own role in the
ABC group was mainly that of implementing the language and its integrated editing
environment.

Pythonが最初に、そして最も影響を受けたのは ABC という言語です。
これは1980年代の初めにLambert Meertens, Leo Geurts のほかCWIにいたメンバーによって
設計された言語です。ABCは教育用言語となることを目指し、個人向けのコンピューティング
環境やプログラミング言語としてBASICを置き換えることを狙っていました。
It was designed by first doing a task analysis of the programming task and
then doing several iterations that included serious user testing.
ABCグループにおけるわたし自身の役割は主に言語の実装とそれを編集環境へ
統合することでした。


Python's use of indentation comes directly from ABC, but this idea didn't originate
with ABC ― it had already been promoted by Donald Knuth and was a well-known concept of
programming style. (The occam programming language also used it.) However, ABC’s
authors did invent the use of the colon that separates the lead-in clause from the
indented block. After early user testing without the colon, it was discovered that the
meaning of the indentation was unclear to beginners being taught the first steps of
programming. The addition of the colon clarified it significantly: the colon somehow
draws attention to what follows and ties the phrases before and after it together in
just the right way.

Python が使っているインデントでコードのブロックをあらわすという考え方は
ABCから直接きたものですが、それのアイデアはABCがオリジナルであるというわけではありません。
すでに Donald Knuth によって promote されていて、プログラミングのスタイルとして
よく知られているものでした(Occamというプログラミング言語でも使っていました)。
しかしABCの作者たちは
the lead-in clause from the indented block
をコロンで分割するということを発明したのです。
初期ユーザーがコロン抜きで試したあとで
it was discovered that the
meaning of the indentation was unclear to beginners being taught the first steps of
programming.
#全くの初心者が「インデント」という概念をプログラミングの一歩目で
#出されるのはハードルが高いとかそんなん。
コロンを追加したことはclarified it significantly:
コロンはその後ろに続いているものに対する注意を喚起し
その前にあるフレーズとあとにあるフレーズを
正しいやり方でまとめるのです。


Python's major data types also derive from ABC, though with some modifications. ABC's
lists were really bags or multisets, which were always kept sorted using a modified
B-tree implementation. Its tables were associative arrays that were similarly kept
sorted by key. I found that neither data type was suitable to represent, for example,
the sequence of lines read from a file, which I anticipated would be a common use case.
(In ABC you'd have to use a table with the line numbers as keys, but that complicates
insertions and deletions.) So I changed the list type into a flexible array with
insert and delete operations, giving users complete control over the ordering of items
in a list. A sort method supported the occasional need for sorted results.

Pythonの主なデータ型も、多少の修正はありますがABCからきたものです。
ABCのリストは本当のバッグ (bag) だとかマルチセット(multisets)といえるもの でした。
これはalways kept sorted using a modifiedB-tree implementation. 
そのテーブルはやはりキーの順序によりソートされた状態を保つ連想配列でした。
そのようにして表現するのは適切でないと考えているデータがありました。
わたしが適切でなくまた良くあるケースだろうと考えていたのはたとえば
ファイルから読み込んできた行のシーケンスがそうです。
(ABC では行番号をキーとしたテーブルを使わなければなりませんでしたが
そうすると挿入や削除が複雑になってしまいます)
そのためわたしはリスト型を挿入や削除といった操作を備えたflexible array に変更し、
リスト中でどのように並ぶかの決定権をユーザーの手にゆだねたのです。
sort メソッドがソートされた結果が必要な状況のためにサポートされました。


I also replaced the sorted tables with a hash table implementation. I chose a hash
table because I believed this to be faster and easier to implement than ABC's B-tree
implementation. The latter was theoretically proven to be asymptotically optimal in
space and time consumption for a wide variety of operations, but in practice it had
turned out to be difficult to implement correctly due to the complexity of the B-tree
algorithms. For the same reason, the performance was also sub-optimal for small table
sizes.

わたしはまた、ソート済みテーブルをハッシュテーブルでもって置き換えました。
わたしがハッシュテーブルを選んだのは、ABCで使っていたB-treeによる実装よりも
すばやくかつ簡単に実装できるだろうと確信していたからです。
B-treeを使った実装は理論的に言えば
to be asymptotically optimal in
space and time consumption for a wide variety of operations,
なのですが、実際には(in practice)
B-treeのアルゴリズムの難しさによって、それを正しく実装するのはとても困難でした。
同様に、
the performance was also sub-optimal for small table sizes.

I kept ABC's immutable tuple data type ― Python's tuple packing and unpacking
operations are taken directly from ABC. Since tuples are internally represented by
arrays, I decided to add array-like indexing and slicing.

ABCのタプルというデータ型はそのまま残しました。
Python のタプルはpackとunpackという操作をABCから直接受け継いでいます。
タプルは内部的には配列として表現されているので、
わたしはタプルに配列のようなインデクシングとスライシングを追加しました。

One consequence of adding an array-like interface to tuples is that I had to figure
out some way to resolve the edge cases of tuples with length 0 or 1. One of the rules
I took from ABC was that every data type, when printed or converted to a string,
should be represented by an expression that was a valid input to the language's
parser. So, it followed that I needed to have notations for 0- and 1-length tuples. At
the same time I didn't want to lose the distinction between a one-tuple and a bare
parenthesized expression, so I settled for an ugly but pragmatic approach where a
trailing comma would turn an expression into a one-tuple and "()" would
represent a zero-tuple. It's worth nothing that parentheses aren't normally required
by Python's tuple syntax, except here ― I felt representing the empty tuple by “nothing”
could too easily mask genuine typos.

One consequence of 
タプルに対して追加した配列のようなインターフェースによって
わたしは長さが0であったり1であったりするタプルのような edge ケース
を解決するなんらかの方法を figure out することがひつようとなりました。
わたしがABCから貰ったルールの一つはすべてのデータ型は
それを出力する際には言語のパーザーに対する正しい入力となる式として表現される
文字列に変換すべきであるということです。
ですから、わたしには長さが0だったり1だったりした場合のタプルに対する表記が必要だったのです。
同時に、わたしは長さ1のタプル(one-tuple) と中身が空のカッコ対 (a bare parenthesized expression)
との区別を失いたくはなかったので、醜いけれども現実的なやり方として
長さ1のタプル やを表現するのに後ろにくっついたカンマ (trailing)を使い、
"()" を長さゼロのタプル (zero-tuple)にしたのです。
It's worth nothing that parentheses aren't normally required by Python's tuple syntax,
except here ―
わたしには空のタプルを“なにもないこと”(nothing)によって表現することが
genuine typos をあまりにも簡単に隠してしまうように思われたのです。

Python's strings started with very similar (immutable) semantics as ABC's strings,
but with a different notation, and 0-based indexing. Since I now had three indexable
types, list, tuples, and strings, I decided to generalize these to a common concept,
the sequence. This generalization made it so certain core operations such as getting
the length (len(s)), indexing (s[i]), slicing (s[i:j]), and iteration (for i in s)
worked the same on any sequence type.

Pythonにおける文字列は ABCの文字列と非常に似通ったセマンティクス (immutable 変更不可能 であること)
から始まっていますが、異なる表記と0から始まる添え字付けとを持っています。
その時点でわたしは リスト(list)、タプル(tuples)、文字列(strings) という
三つの indexable(添え字付け可能) な型を持っていたので
これらの三つをシーケンス (sequence) という共通のコンセプト (common concept)でもって
一般化したのです。
この一般化によって長さを得たり (len(s))、添え字付けをしたり (s[i]),
あるいはスライシング (s[i:j])、イテレーション (for i in s) といったコアオペレーション
(core operations)があらゆるシーケンス型 (any sequnce type) に対して
同じように動作するようになりました。

Numbers are one of the places where I strayed most from ABC. ABC had two types of
numbers at run time; exact numbers which were represented as arbitrary precision
rational numbers and approximate numbers which were represented as binary floating
point with extended exponent range. The rational numbers didn't pan out in my view.
(Anecdote: I tried to compute my taxes once using ABC. The program, which seemed
fairly straightforward, was taking way too long to compute a few simple numbers. Upon
investigation it turned out that it was doing arithmetic on numers with thousands of
digits of precision, which were to be rounded to guilders and cents for printing.)
For Python I therefore chose a more traditional model with machine integers and machine
binary floating point. In Python's implementation, these numbers are simply
represented by the C datatypes of long and double respectively.

Numbers are one of the places where I strayed most from ABC.
ABCは実行時に二つの型の数値を持っていました。
exact numbers which were represented as arbitrary precision rational numbers
と
approximate numbers which were represented as binary floating point with extended exponent range.
です。
有理数 (rational numbers ) は  didn't pan out in my view.
(Anecdote: I tried to compute my taxes once using ABC. The program, which seemed
fairly straightforward, was taking way too long to compute a few simple numbers. Upon
investigation it turned out that it was doing arithmetic on numers with thousands of
digits of precision, which were to be rounded to guilders and cents for printing.)
(Anecdote:
わたしは一度、自分の税金をABCを使って計算しようとしたことがあります。
その which seemed fairly straightforward なプログラムは
数個の単純な数値を計算すうのにさえ長い時間を要したのです。
調査の結果それは to be rounded to guilders and cents for printing のために
算術演算が何千桁もの精度を持った数値に対して行われていたからだということが
判明しました)
したがってわたしはPython 向けには
機械依存の整数(machine integers) と 機械依存の浮動小数点数 (machine binary floating point)
というより伝統的なモデルを選択したのでした。
Python の実装においては、これらの数値は単純にそれぞれ Cのデータ型の long や double
を使って表現されています。


Feeling that there was still an important use case for unbounded exact numbers, I
added a bignum data type, which I called long. I already had a bignum implementation
that was the result of an unfinished attempt at improving ABC's implementation a few
years earlier (ABC's original implementation, one of my first contributions to ABC,
used a decimal representation internally). Thus, it made sense to me to use this code
in Python.

unbounded exact numbers (束縛されていない正格数?) のためのユースケースが重要であると
感じていたので、わたしは長整数とわたしが呼んでいた bignum データ型を追加しました。
それよりも何年か前にわたしはすでにABCの実装を改良を行っていた結果として
(改良字体は未完でしたが)bignum の実装を持っていましたから、
it made sense to me to use this code in Python.
(そのbignum はABCオリジナルの実装で、ABCに対するわたしの最初の cotributions のひとつであり
内部的には十進表現を用いていました)


Although I added bignums to Python, it's important to emphasize that I didn't want to
use bignums for all integer operations. From profiling Python programs written by
myself and colleagues at CWI, I knew that integer operations represent a significant
fraction of the total program running time of most programs. By far, the most common
use of integers is to index sequences that fit in memory. Thus, I envisioned machine
integers being used for all of the most-common cases and the extra range of bignums
only coming into play when doing "serious math" or calculating the national
debt of the US in pennies.

わたしは bignum (多倍長数)をPythonに追加しましたが、
すべての整数操作 (integer operations)に対して bignum を使うことは
わたしの望むところではなかったなかったということは特に強調しておきます。
わたし自身やcolleagues at CWI によって書かれたPython プログラムのプロファイリングから
I knew that integer operations represent a significant
fraction of the total program running time of most programs.
#わたしは整数操作が大部分のプログラムにおける実行時間全体のなかで
#かなりの部分を占めていることを知っていました。
By far,
整数を使う最も一般的なものはメモリに収まるシーケンスに対する添え字のためでした。
したがって、
すべての most-common cases に対しては machine integers (機械が直接表現できる整数) を使い、
"serious math" や national debt of the US in pennies を計算するようなときにのみ
bignum の extra range が使われるようにしたのです。


The Problem With Numbers
数値に関する問題

The implementation of numbers, especially integers, is one area where I made several
serious design mistakes, but also learned important lessons concerning Python's design.

数値、特に整数の実装はわたしがいくつかの設計上の重大な誤りを犯してしまった領域ですが、
同時にPython の設計に関して重要な教訓を得た部分でもありました。

Since Python had two different integer types, I needed to figure out some way to
distinguish between the two types in a program. My solution was to require users to
explicitly state when they wanted to use longs by writing numbers with a trailing L
(e.g., 1234L). This is one area where Python violated the ABC-inspired philosophy of
not requiring users to care about a uninteresting implementation details.

Python は異なる二つの整数型を持っていましたから、
プログラムの中でそれら二つを区別するためのなんらかの方法が必要でした。
わたしが選んだ解決策は、長整数として使いたい場合に 1234Lのようにその末尾に Lをつける
ということをユーザーに要求するというものでした。
これは ABCにインスパイアされた、ユーザーに対して care about a uninteresting implementation details
を求めないという哲学をPython が violate しているものの一つです。


Sadly, this was only a minor detail of much larger problem. A more egregious error was
that my implementation of integers and longs had slightly different semantics in
certain cases! Since the int type was represented as a machine integer, operations
that overflowed would silently clip the result to 32 bits or whatever the precision of
the C long type happened to be. In addition, the int type, while normally considered
signed, was treated as an unsigned number by bitwise and shift operations and by
conversions to/from octal and hexadecimal representations. Longs, on the other hand,
were always considered signed. Therefore, some operations would produce a different
result depending on whether an argument was represented as an int or a long. For
example, given 32-bit arithmetic, 1<<31 (1 shifted left by 31 bits) would
produce the largest negative 32-bit integer, and 1<<32 would produce zero,
whereas 1L<<31 (1 represented as long shifted left by 31 bits) would produce a
long integer equal to 2**31, and 1L<<32 would produce 2**32.

残念なことに、これはより大きな問題の minor detail にすぎないのです。
より egregious な間違いはわたしの行った整数と長整数の実装は
slightly different semantics in certain cases!
int 型は machine integer として表現されていましたから、
オーバーフローが発生した操作は32ビットかPythonをコンパイルするのに使用した
Cコンパイラの long 型の長さで clip されていました。
さらに int 型は通常のケースでは符号付きであると見なされていましたが、
一方ではビット毎の論理演算だとかシフト、
あるいは十六進表記や八進表記からの変換(と逆方向の変換)
によって数値が操作される場合には符号なしとして扱われました。
その一方、長整数型は常に符号付と見なされました。
その結果、一部の操作においてその引数が整数であるか長整数であるかによって異なる結果になります。
たとえば例を挙げると、
32ビットの算術演算であったとき 1<<31 (1を左へ31ビットシフト)は
32ビット整数での負の最大値を生成しますし、 1<<32  の結果は0です。
そして 1L<<31 (長整数の1を左へ31ビットシフト) は2**31 に等しい値の長整数を生成し、
1L<<32  は 2**32 を生成します。

To resolve some of these issues I made a simple fix. Rather than having integer
operations silently clip the result, I changed most arithmetic operations to raise an
OverflowError exception when the result didn't fit. (The only exception to this
checking were the "bit-wise" operations mentioned above, where I assumed
that users would expect the behavior of these operations in C.) Had I not added this
check, Python users would have undoubtedly started writing code that relied on the
semantics of signed binary arithmetic modulo 2**32 (like C users do), and fixing the
mistake would have been a much more painful transition to the community.

こういったことがらのいくつかを解決するための単純な修正をわたしは行いました。
整数演算がこっそりとその結果を clip してしまうのではなく大部分の算術演算の結果が
その型に収まらない場合には OverflowError 例外を送出するように変更したのです。
この検査についてのただ一つの例外が前述した "bit-wise" 演算です。
where I assumed that users would expect the behavior of these operations in C.)
Had I not added this check,
Python ユーザーは
relied on the semantics of signed binary arithmetic modulo 2**32 (like C users do),
(Cのユーザーがやるような) 符号付き二項算術の modulo 2**32 のセマンティクスに依存した
コードを書き始めてしまっていました。
間違いを訂正することは much more painful transition to the community でした。


Although the inclusion of overflow checking might seem like a minor implementation
detail, a painful debugging experience made me realize that this was a useful feature.
As one of my early programming experiments in Python, I tried to implement a simple
mathematical algorithm, the computation of “Meertens numbers”, a bit of recreational
mathematics invented by Richard Bird for the occasion of ABC's primary author's
25ths anniversary at CWI. The first few Meertens numbers are small, but when
translating the algorithm into code I hadn't realized that the intermediate results
of the computation are much larger than 32 bits. It took a long and painful debugging
session before I discovered this, and I decided there and then to address the issue by
checking all integer operations for overflow, and raising an exception whenever the
result could not be represented as a C long. The extra cost of the overflow check
would be dwarfed by the overhead I was already incurring due to the implementation
choice of allocating a new object for the result.

オーバーフローのチェックを含めることは取るに足らない実装上の詳細であるのように
思われるかもしれませんが、苦痛に満ちたデバッグの経験は
これが  useful feature であったことをわたしに認識させたのです。
自分の初期のPythonプログラミングの経験の一つとしてわたしは単純な数学的アルゴリズム
である“Meertens numbers”の計算を実装しようと試みたことがあります。
これは occasion of ABC's primary author's 25ths anniversary at CWI のために
Richard Bird によって発明された recreational mathematics です。
最初の数個の Meertens numbers は小さいのですが、アルゴリズムをコードとして書いているときには
わたしは computation の中間結果(intermediate results) が32ビットよりも
ずっと大きくなるということに気が付かなかったのです。
このことに気づくまで長く苦痛に満ちたデバッグセッションが必要で、
わたしはC の long として表現できないような結果となった場合にはいつでも
例外を送出することによってこの問題に対処すると決めたのです。
オーバーフローを検査するための extra cost は
すでにわたしが結果を収めるための新しいオブジェクトを割り付けるという実装上の選択を
incurring していたオーバーヘッドによって dwarf 化されました。


Sadly, I'm sorry to say that raising an overflow exception was not really the right
solution either! At the time, I was stuck on C's rule “operations on numeric type T
return a result of type T”. This rule was also the reason for my other big mistake in
integer semantics: truncating the result of integer division, which I will discuss in
a later blog post. In hindsight, I should have made integer operations that overflow
promote their result to longs. This is the way that Python works today, but it took a
long time to make this transition.

残念なことではありますが、オーバーフロー例外を raise することが本当に正しい解決策では
なかったのです! そのときわたしは C のルールである
“operations on numeric type T return a result of type T”
(数値型 Tに対して操作を行った結果は型 Tとなる) にこだわっていました。
このルールは also the reason for my other big mistake in integer semantics:
整数の割り算の結果を丸めてしまうことがそれですがこれはまた別の機会に記事にすることにします。
In hindsight,
わたしは、オーバーフローを引き起こすような整数に対する操作はその結果を長整数に昇格するように
しておくべきだったのです。これは現在のPytonで行っている方法ですが、このやり方に移行するまでに
は長い時間を要したのです。


Despite the problem with numbers, one very positive thing came out of this experience.
I decided that there should be no undefined result values in Python ‐ instead,
exceptions should always be raised when no correct return value can be computed. Thus,
Python programs would never fail due to undefined values being silently passed around
behind the scenes. This is still an important principle of the language, both in the
language proper and in the standard library.

数にまつわる問題はありましたが、
一つの非常に positive な thing がわたしの経験として come out しました。
わたしはそのとき、Python においては未定義な結果 (undefined result values) を
なくすべきであると決意したのです。
未定義の値を操作の結果とするのではなくて、
正しい値を計算できそうにない場合にはいつでも例外が送出されるすべきなのです。
したがって、Pythonプログラムは
undefined values being silently passed around behind the scenes のために
決して fail しないようになりました。これはPython という言語の
language proper と標準ライブラリ双方において
重要な原則 (important principle)でありつづけています。

    ■_ ませまちか

    高い高いといつもぶーたれている Machematica ですが、 Home Edition ってのが $295 で入手できるとか? 

    Wolfram Mathematica Home Edition: Q&A
Q&A about Mathematica Home Edition

*General

Q: Is Mathematica Home Edition for anyone using Mathematica at home?

Yes. For years, people have been excited about using Mathematica to "play" 
or to pursue serious research outside of their commercial or academic jobs. Now 
Mathematica Home Edition provides an inexpensive version of Mathematica for those who 
want to use its powerful technology to explore their ideas. For those who want to 
integrate Mathematica into their teaching, research, or work, Mathematica Professional 
is always available.

    *Purchasing and Registration

Q: How do I prove that I'm buying Mathematica Home Edition for my personal use?

Mathematica Home Edition cannot be registered to a business, institution, or other 
non-personal address. Also, Mathematica Home Edition cannot be purchased using a check 
or credit card account belonging to a business, institution, or other non-personal 
entity, or with a purchase order.

    ふむふむと読みすすめていくと･･･ 

    *Policies

Q: Where is Mathematica Home Edition available?
Mathematica Home Edition is for sale in the United States and Canada.
It can be downloaded from the Wolfram web store.

    げーん。北米のみー? ○|￣|＿ 日本支社だか販売代理店だか知らないけど、そっちはやってくれねえだろうなあ。

    ■_ Rubinius

    InfoQ だからすぐに訳されるだろう。でもrssないからちぇっくめんどー 

    InfoQ: Rubinius Progress - Interview with Brian Ford
Rubinius Progress - Interview with Brian Ford

We talked to Brian Ford (brixen on the IRC) about what's been going on in the Rubinius project.
Brian lists some of the changes in Rubinius that have happened in the past few months:

    [..] There's been hundreds of commits and thousands of lines of changes in the 
      past two months. A couple highlights:
    * Evan has added a JIT framework that can be enabled, along with a dynamically 
      generated bytecode interpreter.

    * Contributors have fixed and improved performance for a number of Ruby core library classes.

    * We've reworked our bootstrap process to improve the quality of code in the core library.

    * We've got a working instrumenting profiler that produces the same output as 
      MRI's but better than 10x faster.

    * Adam Gardiner has been getting the Ruby debugger working again on the new VM.

    * I've update our FFI implementation to be closer to that released by JRuby and the MRI FFI gem.

    * I've completely redone our compiler specs in a much better format.

    * The Rubyspecs for 1.8 and 1.9 are merged and I've added significant features to 
      MSpec to facilitate running the specs for 1.8 and 1.9. Keep in mind that Engine Yard, 
      through my work, continues to be the major financial backer of the RubySpecs which 
      benefits *every* Ruby implementation out there, MRI included. 

(略)

Evan Phoenix gave an overview of some Rubinius design improvements at RubyConf '08. 
Brian also summarizes the changes:

    There are some big areas that we are exploring but they basically reduce to better 
    compiler technology, better GC, better data structures, and better type system. Of 
    course, this is iterative. But keep in mind that Rubinius is a project that is barely 
    2 years old. Evan has made outstanding architecture decisions throughout the life of 
    the project and we've got an excellent foundation in the new C++ VM, Ruby compiler, 
    and Ruby core library. 

The Rubinius project has already brought many improvements to the Ruby space; Brian 
already mentioned the RubySpecs which are used by all Ruby implementations nowadays. 
Another library that originated in Rubinius is the Ruby FFI library:

    First of all, while the push into FFI was started by Rubinius, the JRuby folks 
    deserve credit for getting the MRI gem out there. It's a win-win solution for all Ruby 
    implementations, but especially ones like JRuby who cannot ever support Ruby C-API 
    extensions like MRI and Rubinius can.

    We chose to implement FFI because we had an arguably better API than DL and 
    because it is very tied to the implementation. All the implementations can agree on 
    the API that is provided to Ruby code, but there is almost nothing in the FFI 
    implementation itself that can be shared.

    ■_

    ■_ 文字列検索

    文字列の中から効率良くキーワードを探し出せ － ＠IT

http://www.atmarkit.co.jp/fcoding/articles/algorithm/07/algorithm07a.html
http://www.atmarkit.co.jp/fcoding/articles/algorithm/07/algorithm07b.html
http://www.atmarkit.co.jp/fcoding/articles/algorithm/07/algorithm07c.html
http://www.atmarkit.co.jp/fcoding/articles/algorithm/07/algorithm07d.html

    まあ定番といえば定番(brute-force, KMP, BM, n-gram)なんだけど、 KMPとかBM ってマルチバイト文字とか幅広文字に使うの面倒だよねえ。 こうやって紹介するのはいいけどどうなんだろう。 って詳細はライブラリの実装者に任せるって話なんかねえ ソートみたいに。

    って文字列マッチングの本買ったけどまだろくに読んでねー○|￣|＿

    2009年02月04日

    ■_

    ・いいのかそれで
    みんな大好きExcelには「配列数式」つーものがあります。 自分もよくわかってなかったのですが、使いどころが難しい一面はあるものの これが使えると手間を大幅に減らせる局面があるというのでちょっと調べたり。 それはまあいいんですが、ふと、「この『配列数式』って元の英語ではどういう名称なんだろうか」 という疑問をもったわけです。んで、わかったこと。 プロパティとしては「FormulaArray」らしい(Fomula と Arrayが逆じゃん!)ということ。 とはいえ My intention is to apply an array formula with a dynamic argument to a worksheet. 「配列数式」的な順序でも英語的にはOK? 別な意味になりそうな気がしないでもないけどよくわからん。 formulaarray - MSDN Search 日経PC21 / エクセル「配列数式」講座 EXCEL生産性向上委員会 ちょっと便利テクニック２１

    Ctrl+Shift+Enter で入力て。 

    コンピュータージャーナリズムの行方：ジェリー・パーネル「続・混沌の館にて」
私は主に商用BASIC（堅固に構造化されたコンパイルされたBASIC）とFORTRANでプログラミング
を学んだ。しかし、私はPascal、Turbo Pascal、Modula-2も学習した。それでいくつかのプログ
ラムを書き、今まで使っている。さらに、Cを十分に学習して、Cプログラムはデバッグや維持が
難しいと確信した。そしてCプログラマーには絶対になりたくないと考えた。もちろん、当時使
えたハードウエアは非常に制限されていた。また、Cはアセンブリ言語がほんの一歩進歩しただ
けのものだったが、コンパイルもランタイムも他のどんなものよりはるかに速かった。ハードウ
エアが制限されている限り、「実際に仕事をするプログラマーがCで作業する」のは当たり前だ
った。

    Road To IT-Engineer / ITエンジニアの生きる道: 自己実現に関わる根幹のお話
以前、日経新聞にも載っていましたが、高尾山・薬王院、真言宗智山派の大本山に、十か条の看板があります。

    * 高いつもりで低いのが教養
    * 低いつもりで高いのは気位
    * 深いつもりで浅いのは知識
    * 浅いつもりで深いのは欲
    * 厚いつもりで薄いのは人情
    * 薄いつもりで厚いのは面の皮
    * 強いつもりで弱いのは根性
    * 弱いつもりで強いのは我
    * 多いつもりで少ないのは分別
    * 少ないつもりで多いのは無駄

　「つもり十か条」というのだそうですが、あまりにうまく言い当てているので、面白さを通り越してドキリとします。

    ■_ UNIX

    なんとなく立脚点の違いに面白さを感じたので。 

    http://www.rubyist.net/~matz/20090202.html#p01
MacBook Pro2009/2/3 18:21Yukihiro -matz- Matsumoto

  朝、出かける前に荷物が届いたら、MacBook Proだった。

RubyCentralが「もっとOS Xサポートしっかりしてくれ」ということで、送ってくれたものだ。
Mac所有は初めてのことになる。

で、しばらく使ってみた印象は

    * わかりやすい
    * わかりにくい
    * わからない

(略)

わかりにくい

ずーっと、Unix系OS(特にLinux)で過ごしてきた身としては、一応Unix系とは言えやはりMacOS X
は違いすぎる。

常識が通用しなくてつらい。これはWindowsでも言えることだけど。

しばらく使っているうちに慣れるだろうか。

◆2009-02-02のツッコミ[2] (YOUsuke)2009/2/4 05:17YOUsuke
Mac OS Xは一応ではなく完全にUNIXです。

    まあガワはともかく、カーネルなんかはFreeBSDからの派生ですから完全にUNIX という意見が正しいのでしょうが(たしかどこぞの認定も通ってましたよね)、 まつもとさんがなぜ「MacOS Xは違いすぎる」と感じたかですよね。 まあ「見た目」はひとつあるとして、デスクトップOSとしての操作感。なのかなあ。

    ■_ Emacs Lis is sucks

    本編? 部分はこれで終わり。 

    EmacsWiki: Emacs Lisp Limitations
EmacsWiki: Scheme And Lisp


EmacsLisp Isn't CommonLisp/Haskell/Other
EmacsLispは CommonLisp/Haskell/その他諸々 ではない

I don't know enough about any of these to offer any informed commentary, except to 
note that aside from Common Lisp, they all seems to be edge cases that either no one 
supports seriously, or only one or two people in the universe actually want.

わたしは、Common Lispを除けばそういった言語について何かコメントできるほどよく知りません。
そこで挙げられている言語はみな、edge cases that either no one supports seriously か
#まともにサポートしているものがないような極端な例?
only one or two people in the universe actually want のようなものののように
#そんなのを欲しがるのは全宇宙で一人か二人くらいなこれも極端なもの
思われます。

The Emacs APIs Suck
(EmacsのAPIは腐ってる)

I heard this a lot as well, but I have no idea what exactly is being referred to. 
Elucidation greatly appreciated.

わたしはこれを散々聞きましたが、その言葉が実際にどのようなことを指していっているのか
わかりません。
Elucidation greatly appreciated.
# → きちんと説明すること?

My wild guess would be “because they're not OO”, which doesn't really bother me, 
but can be seen as a problem given the typical Java-centric way people are taught CS 
in the US.

わたしが漠然と考えたのは“Emacs Lispはオブジェクト指向言語じゃないから”
というものですが、これはわたしを悩ませるものではないものの、
アメリカでコンピュータ科学を学んだ典型的な Java-centric way people
には問題となりうるものでしょう。

Do You Mean EmacsLisp (Language) Or EmacsLisp (Library)?
(君が言っているのは言語としての Emacs Lisp のこと? それともライブラリとしての Emacs Lisp?)

I don't know. Which do you, the EmacsLisp detractor, mean?

わかりません。どちらだとしても、EmacsLispを貶めるものだと仰りたいのでしょうか?

Most people seem to hate EmacsLisp-the-language, but the primary obstacle to replacing 
EmacsLisp is, of course, EmacsLisp-the-library. 30+ years and 80+ megabytes of Emacs 
functionality, all in EmacsLisp. Redoing even the core editing functions is a 
terrifying thought to me[4].

ほとんどの人は言語としての Emacs Lisp を嫌っているように見えますが、
Emacs を置き換えるための primary obstacle(障害となる主たるもの)
はライブラリとしての Emacs Lispなのです。
30年以上にわたり蓄積されてきて、80メガバイト以上の規模をもつ Emacs のfunctionality は
すべてEmcas Lispの中にあるのです。
コアとなる編集機能 (core editing functions) のみの再作業でさえも、
わたしにとっては考えるだに恐ろしいことであるのです。

Who Is EmacsLisp For? Who Wants EmacsLisp Dead?
(Emacs Lispって誰のためのもの? Emacs Lispを死んだことにしたいのは誰?)

This is the larger question I referred to in the Scheme section. I can't say for sure, 
but my gut feeling is that most of the people who are unhappy with EmacsLisp are the 
people who are using Emacs as an application development platform rather than as an 
extensible editor.

これはScheme セクションで触れたもののより大きな疑問です。確実なことはいえませんが、
拡張可能なエディタとしてよりもアプリケーションの開発プラットフォームとしてEmacsを
使っていている人の中でもEmacs Lisp を不承不承使っているような人が大半であるように
感じられたのです。

I am, of course, aware of the kitchen-sink nature of Emacs, and revel in it. I know 
that the design of Emacs evolved in the time when a programmer only had access to a 
single terminal session to a computer, thus becoming in effect the world's first 
Integrated Development Environment so a user could meet all their needs without 
dropping in and out of their primary application: the editor.

わたし自身はもちろんEmacs のキッチンシンク的な性質に価値を見出してそれを楽しんでいます。
プログマラーが一つのコンピュータに対する一つのターミナルセッションへの
アクセスだけを有していた時代にEmacs の設計が発展したことをわたしは知っています。
それは世界最初の Integrated Development Environment (IDE, 統合開発環境)となって、
ユーザーは自分が必要とすることすべてをEmacsの中でできるようになったのです。
本来のエディターという枠組みを超えて。

But I believe there is a difference between making Emacs read mail or news or have a 
shell because you needed to in the 1970s and making Emacs browse web sites or act as 
an httpd because you can in the 2000s. I wonder if perhaps the people who want to fix 
all of EmacsLisp's problems want to do so more for their own benefit ? so it will be 
a better general-purpose development base and toolkit ? than to make Emacs better for 
everyone. I wonder if they have lost sight of the primary application: the editor[5].

しかしながら、1970年代には必要であった Emacs でメールやニューズを読んだりシェル機能を
持つようにすることと、2000年代において Emacs でwebサイトを閲覧したり Emacs がhttpd
として振舞うことようにすることとの間には違いがあるはずだとわたしは確信しています。
Emacs Lispにまつわる問題のすべてを解決したいと考えている人たちが彼ら自身が享受する
であろう利益のために行動してくれたらよいだろうなあとわたしは思っています。
そうすればEmacs はより優れた汎用開発ベース/ツールキット
(general-purpose development base and toolkit) となるでしょう。
I wonder if they have lost sight of the primary application: the editor
#Emacsがエディタであるという先入観を捨てろとかいう話?

Conclusion
(結論)

This is meant to be polemic but not dogmatic[6]. I have stated my observations, 
opinions, and conclusions, but I have done this to show my point of view and lack of 
full understanding rather than to try and convince others that I am correct. I am not 
against fixing or replacing EmacsLisp, but I have yet to see any logical, thorough, 
and cogent arguments for it. Therefore: get to arguing!

以上述べてきたことは dogmatic ではなく polemic (反論) です。
わたしは自分の observations (批評、意見),  opinions (見解), conclusions (結論) 
を明確に述べましたが、それを行ったのはわたしが修正したその他の convince 

わたしの視点とlack of full understanding を示すためです。
わたしはEmacs Lispを修正したりそれを置き換えたりすることに反対はしませんが、
I have yet to see any logical, thorough, and cogent arguments for it.
Therefore: get to arguing!

--ShawnBoyette
Other commonly-named problems (その他の commonly-named な問題)

  ** 続く **

    ■_ dive into python 3 with 2to3

    Porting code to Python 3 with 2to3 - Dive into Python 3
http://diveintopython3.org/porting-code-to-python-3-with-2to3.html
Porting code to Python 3 with 2to3


Unicode string literals (Unicode 文字列リテラル)

Python 2 had two string types: Unicode strings and non-Unicode strings.
Python 3 has one string type: Unicode strings.

Python 2では二つの文字列型がありました: Unicode文字列と非Unicode文字列です。
Python 3では文字列型は一つだけです: Unicode文字列のみです。


    
  
    
    Notes Python 2 Python 3
    
      
  
    
    ① u"PapayaWhip" "PapayaWhip"
    
  
    ① ur"PapayaWhip\foo" r"PapayaWhip\foo"
    
      

    

   1. Unicode string literals are simply converted into string literals, which, in
      Python 3, are always Unicode.
      Unicode文字列リテラルは単純に文字列リテラルへと変換され、
      Python3では文字列リテラルは常にUnicodeになります。

   2. Unicode raw strings (in which Python does not auto-escape backslashes) are
      converted to raw strings. In Python 3, raw strings are always Unicode.
      Unicode raw 文字列 ()は raw文字列に変換されます。
      Python 3ではrawも字列は常にUnicodeです。

unicode() global function (グローバル関数 unicode())

Python 2 had two global functions to coerce objects into strings:
unicode() to coerce them into Unicode strings, and str() to coerce them into 
non-Unicode strings. Python 3 has only one string type, Unicode strings, so the str() 
function is all you need. (The unicode() function no longer exists.)

Python 2では、オブジェクトを文字列に coerce (強制的な型変換)するための
グローバル関数が二つありました:
unicode() はオブジェクトをUnicode文字列へと coerce し、
str() は非Unicode文字列へとcoerceします。
Python 3では文字列型はUnicode文字列ただ一つなので、
str() 関数が常にあなたが必要とするものになります
(unicode()関数はPython 3にはありません)。


    
  
    
    Notes Python 2 Python 3
    
      
  
    
    unicode(anything) str(anything)
    
      

    
  
long data type long データ型

Python 2 had separate int and long types for non-floating-point numbers. An int could 
not be any larger than sys.maxint, which varied by platform. Longs were defined by 
appending an L to the end of the number, and they could be, well, longer than ints. In 
Python 3, there is only one integer type, called int, which mostly behaves like the 
long type in Python 2. Further reading: PEP 237: Unifying Long Integers and Integers.

Python 2は浮動小数点数でない数を表すのに int と long という別々の型を持っていました。
int は (プラットフォーム依存の値である)sys.maxint 以上の値を保持することができませんでした。
long は数値の後ろに L を付加することで定義されるもので、
int が表すことができるものよりも大きな値を保持することができました。
Python 3では整数のための型はPython 2における long 型とほぼ同じである
int ただ一つとなりました。
Further reading: PEP 237: Unifying Long Integers and Integers.

Since there are no longer two types, there is no need for special syntax to distinguish
them.
整数型は二つの型ではなくただ一つとなったので、両者を区別するための特殊な構文の必要はなくなりました。


    
  
    
    Notes Python 2 Python 3
    
    
  
    
    ① x = 1000000000000L x = 1000000000000
    
    
    ② x = 0xFFFFFFFFFFFFL x = 0xFFFFFFFFFFFF
    
    
    ③ long(x) int(x)
    
    
    ④ type(x) is long type(x) is int
    
    
    ⑤ isinstance(x, long) isinstance(x, int)
    
    

    
   1. Base 10 long integer literals become base 10 integer literals.
      基数が10である long integer (長整数) リテラルは基数が10である integer のリテラルとなります。

   2. Base 16 long integer literals become base 16 integer literals.
      基数が16である long integer (長整数) リテラルは基数が16である integer のリテラルとなります。

   3. In Python 3, the old long() function no longer exists, since longs don't exist.
      To coerce a variable to an integer, use the int() function.
      Python 3では以前あった long() 関数は long 自体がなくなったのでなくなりました。
      強制的に integer へと coerce (強制型変換) するには int() 関数を使ってください。

   4. To check whether a variable is an integer, get its type and compare it to int,
      not long.
      ある変数が integer であるかどうかを検査するにはその変数の型を取得して
      long ではなく int と比較してください。

   5. You can also use the isinstance() function to check data types; again, use int,
      not long, to check for integers.
      データ型の検査に isinstance() 関数を使うこともできます。繰り返しますが
      integer かどうかを検査するには long ではなく int を使ってください。

<> comparison (<> を使った比較)

Python 2 supported <> as a synonym for !=, the not-equals comparison operator.
Python 3 supports the != operator, but not <>.

Python 2は != と同じ意味を持つ演算子 (not-equals comparison operator) として
<> をサポートしていました。
Python 3では != 演算子がサポートされていますが <> は削除されました。


    

  
    Notes Python 2 Python 3
    
    

  
    ① if x <> y: if x != y:
    
  
    ② if x <> y <> z: if x != y != z:
    
    

    

   1. A simple comparison.
      単純な比較
   2. A more complex comparison between three values.
      三つの値の間のより複雑な比較

    つづく。

    ■_ The History of Python

    時間的に微妙なんだよなあ。更新に気づいたときには訳している余裕がない時間だったり。 

    The History of Python: Early Language Design and Development
Early Language Design and Development (初期の言語デザインと開発)

From ABC to Python (ABC から Python へ)

Python's first and foremost influence was ABC, a language designed in the early 1980s 
by Lambert Meertens, Leo Geurts and others at CWI. ABC was meant to be a teaching 
language, a replacement for BASIC, and a language and environment for personal 
computing. It was designed by first doing a task analysis of the programming task and 
then doing several iterations that included serious user testing. My own role in the 
ABC group was mainly that of implementing the language and its integrated editing 
environment.

Pythonが最初に、そして最も影響を受けたのは ABC という言語です。
これは1980年代の初めにLambert Meertens, Leo Geurts のほかCWIにいたメンバーによって
設計された言語です。ABCは教育用言語となることを目指し、個人向けのコンピューティング
環境やプログラミング言語としてBASICを置き換えることを狙っていました。
It was designed by first doing a task analysis of the programming task and 
then doing several iterations that included serious user testing. My own role in the 
ABC group was mainly that of implementing the language and its integrated editing 
environment.

Python's use of indentation comes directly from ABC, but this idea didn't originate 
with ABC--it had already been promoted by Donald Knuth and was a well-known concept of 
programming style. (The occam programming language also used it.) However, ABC’s 
authors did invent the use of the colon that separates the lead-in clause from the 
indented block. After early user testing without the colon, it was discovered that the 
meaning of the indentation was unclear to beginners being taught the first steps of 
programming. The addition of the colon clarified it significantly: the colon somehow 
draws attention to what follows and ties the phrases before and after it together in 
just the right way.

Python が使っているインデントでコードのブロックをあらわすという考え方は
ABCから直接きたものですが、それのアイデアはABCがオリジナルであるというわけではありません。
すでに Donald Knuth によって promote されていて、プログラミングのスタイルとして
よく知られているものでした(Occamというプログラミング言語でも使っていました)。
しかし ABCの作者たちは
というコロンの使い方を発明したのでした。

    木曜日はアレがあるからどうかなあ。

    ■_ 

    5 Secrets To Ninja Writing : Rob Conery
http://blog.wekeroad.com/blog/nothing-to-say/

GCC 4.3.3 Released - PLNews: Programming Language News
http://plnews.org/posts/gcc_433_released_20090204_074712.html

Eagle 1.0 beta 3 Released - PLNews: Programming Language News
http://plnews.org/posts/eagle_10_beta_3_released_20090204_074245.html

nwcc 0.7.7 Released - PLNews: Programming Language News
http://plnews.org/posts/nwcc_077_released_20090204_074039.html

EiffelStudio 6.4.7.6930 Released - PLNews: Programming Language News
http://plnews.org/posts/eiffelstudio_6476930_released_20090204_073814.html

IsForth 1.22b Released - PLNews: Programming Language News
http://plnews.org/posts/isforth_122b_released_20090204_073359.html

IKVM 0.38 Update 1 RC 0 Released - PLNews: Programming Language News
http://plnews.org/posts/ikvm_038_update_1_rc_0_released_20090204_073643.html

Ctalk 0.0.93a Released - PLNews: Programming Language News
http://plnews.org/posts/ctalk_0093a_released_20090204_073241.html

Seed7 2009-02-01 Released - PLNews: Programming Language News
http://plnews.org/posts/seed7_20090201_released_20090204_073013.html

IronScheme 1.0 Beta 2 Released - PLNews: Programming Language News
http://plnews.org/posts/ironscheme_10_beta_2_released_20090204_072806.html

    2009年02月03日

    ■_

    ・2to3
    Python 3に添付の、Python 2.x用のスクリプトを3へ移行するための手助け(変換)をしてくれる 2to3というツールを223て書いたらわけわかんねーな。とふと思ったり。

    ・ONEOUTS
    アニメになってから初めてこの作品を知ったのですが、 自分のアンテナの感度の低さをというよりはたくさん作品があってどうしたって 見落としが出るよなあという気がしました。 まあこれはメジャーな雑誌(ヤングジャンプ)に掲載されていた作品ですが、 ここ数年はまるきりノーマークな雑誌だったし。

    というのはどうでもよくて、情報科学とかコンピュータ関係でも知らないものを紹介されているものを 見て知ってそれが「アタリ」だったときはとてもうれしいです。 ぜひ皆様、それぞれの秘蔵のオススメ品などを紹介お願いしまする～ できれば出版されたてのバリバリの新刊じゃなくて、ちょっと時間がたってて 話題を集めるようなこともなかったけど実はというのだとサイコーです。

    ・センゴク→馬場美濃守→銀英伝のアッテンボロー→フィッシャー でちょっと書こうかと思ったけど気力が続かないので日を改めて。 ってそういや一兆クレジット艦隊ネタも投げっぱなしじゃ内科○|￣|＿

    ■_ なんかきてたー

    Test Release: grep-2.5.4-20090201
Test Release: grep-2.5.4-20090201
An updated test release is now available: grep-2.5.4-20090201. It
includes the latest translations and a few minor updates.

Please test this pre-release and share your findings (both
positive and negative). My testing has been on Ubuntu and Mac OS X. If
you have access to other systems or distributions, please share your
findings with the group.

Download site:

    http://alpha.gnu.org/gnu/grep/

We are waiting for an update to dfa.c from Bruno. If that happens by
Friday then we will have another test release. Otherwise, an actual
release will follow, unless a *critical* problem is found before then.

Cheers,

TAA

    って、リンク先見たら 2.5.4-* ってけっこうあるじゃん。 全然チェックしてなかった。 メンテナンスリリースということで大きな変更はない模様。

    ■_ ボタンの掛け違い

    いやまあArnoldの言うことももっともなんだけどさー 

    

Re: sprintf() of gawk in cvs works very slow under ja_JP.UTF8

Hi.

Is this an issue for a real application, or is it something that
you just happened to notice?

Gawk is smarter than the average awk, and it understands multibyte
characters for things like  %.5s in format strings. But to do this it
has to parse the raw string, and that is not without cost.  There's
no free lunch here. :-(

If this is really an issue for an application, I will revisit this;
otherwise I am reluctant to do so because it means the code will probably
have to get messier than it already is.

Thanks,

Arnold

    そもそもなんのためにそういうこと(s?printfの書式指定の精度でバイト単位じゃなくて キャラクタ単位にする)をするのかということと、どう考えてもお前それ わしらの使ってる漢字やらかなやらがラテンアルファベットの倍の幅を持ってるとか わかってないだろうとかあるんですが、まあそれはそれで。 そもそも現状の gawk のマルチバイト文字の扱い方が(ry

    いやまあ iconv リンクして内部Unicode (UTF-8でも16でも32でも)でごにょるとか しないで対応するのは大変なんでしょうけどね。

    ■_

    なんかRubyスレが荒れる気配を見せてるなあ。 

    

推薦図書/必読書のためのスレッド 44 
412 デフォルトの名無しさん [sage] Date:2009/02/02(月) 01:15:31  ID: Be:
    オライリーから12月に出た『JavaScript: The Good Parts』が
    今日某書店に行ったら3冊あったけど3冊ともJavaの棚に並べられていた。
    直しといたろと思って勝手にJavaScriptの棚に持って行ったら
    棚がぎゅうぎゅうで1冊も入らなかった。
    まわりに店員もいないしレジまで言いに行くのも大げさだし、
    あとでメールしといたろと思ってそのまま帰ってきたけど、
    調べてもメールアドレスわからないのでもうほうっておくことにする。 

413 デフォルトの名無しさん [sage] Date:2009/02/02(月) 01:29:18  ID: Be:
    そんなの気にすんなよ
    俺はthe art of computer programmingが現代美術の棚に並べられていたのを見たことがある 

    

推薦図書/必読書のためのスレッド 44 
435 デフォルトの名無しさん [] Date:2009/02/03(火) 10:36:15  ID: Be:
    林晴比古という人が経歴を明らかにしない理由を教えてください
    プログラミングなど技術系の本では簡単に経歴を載せるのが普通だと思います 

436 デフォルトの名無しさん [sage] Date:2009/02/03(火) 10:45:03  ID: Be:
    俺が東大卒とかの経歴だとして、プログラミングの本を書くとする
    経歴載せるかな？
    ちょっと躊躇するね
    本名で執筆することもためらうね 

437 デフォルトの名無しさん [sage] Date:2009/02/03(火) 10:56:36  ID: Be:
    経歴・本名を書いてくそ本と揶揄されることを恐れる人は
    たとえペンネームで経歴も隠しても良本を書くことはできない 

438 デフォルトの名無しさん [sage] Date:2009/02/03(火) 11:01:40  ID: Be:
    じゃあ、仮に名著が書けたとしよう
    それでも本名・経歴は隠したいかもな 

439 デフォルトの名無しさん [sage] Date:2009/02/03(火) 11:05:49  ID: Be:
    ２ちゃんねるのおかげで、
    作家がペンネーム使う理由がよく分かったw 

    

Linus「C++プログラマはウンコ。寄ってくるな」 
461 デフォルトの名無しさん [sage] Date:2009/02/02(月) 00:01:39  ID: Be:
    まぁ、自分もカスだから人のこと言えないけど
    そのカスである俺よりもひどい能力の人が上司だったりしたこともあるので
    カスはカスで生きる方法があるんだと思う今日この頃。 

462 デフォルトの名無しさん [sage] Date:2009/02/02(月) 00:02:25  ID: Be:
    まあカスの生きる道がないと世の中死屍累々だと思う 

463 デフォルトの名無しさん [sage] Date:2009/02/02(月) 01:22:59  ID: Be:
    最上層と最下層の間の幅が一番小さいのはやっぱりHSPなのか？
    一番大きいのはいうまでもなくC++だろうが。 

464 デフォルトの名無しさん [sage] Date:2009/02/02(月) 03:43:42  ID: Be:
    HSPのきれいなソースを見ると才能の無駄遣いだと思うけどなｗ
    >>463が想像するより人によってかなり差がある 

465 デフォルトの名無しさん [sage] Date:2009/02/02(月) 13:20:46  ID: Be:
    >>463
    いちいちそんなカス言語を引き合いに出してくれるなよ。 

466 デフォルトの名無しさん [sage] Date:2009/02/02(月) 14:34:28  ID: Be:
    いや、C++の問題点を浮きあがらせるためには
    その正反対のパラダイムをもつHSPを知ることが先決。 

467 デフォルトの名無しさん [sage] Date:2009/02/02(月) 14:38:36  ID: Be:
    Σ (ﾟДﾟ;）ﾊｯ この流れもしやHSPオンリー？

468 デフォルトの名無しさん [sage] Date:2009/02/02(月) 15:19:35  ID: Be:
    >>466
    正反対とは？ 

469 デフォルトの名無しさん [sage] Date:2009/02/02(月) 15:29:58  ID: Be:
    マルチパラダイムの正反対…なんだろ。意味不明。 

470 デフォルトの名無しさん [sage] Date:2009/02/02(月) 15:32:18  ID: Be:
    てか、HSP使いなんていくら頑張ってもC++を
    マスターすることなんてできないだろうから、
    このスレで発言するいること自体間違ってる。 

471 デフォルトの名無しさん [sage] Date:2009/02/02(月) 15:59:18  ID: Be:
    するいる 

472 デフォルトの名無しさん [sage] Date:2009/02/02(月) 16:30:40  ID: Be:
    >>463
    > 最上層と最下層の間の幅が一番小さいのはやっぱりHSPなのか？
    > 一番大きいのはいうまでもなくC++だろうが。

    人によってそんなに差がある言語は困るんだよ
    ウンコプログラマーには分からんと思うけど 

473 デフォルトの名無しさん [sage] Date:2009/02/02(月) 18:19:14  ID: Be:
    そもそもなんでHSPが出てくるのかわからないのだが… 

474 デフォルトの名無しさん [sage] Date:2009/02/02(月) 19:29:46  ID: Be:
    >>472
    誰と戦ってるんだお前 

475 デフォルトの名無しさん [sage] Date:2009/02/02(月) 19:58:01  ID: Be:
    >>474
    C++ と、じゃね？ 


    

Linus「C++プログラマはウンコ。寄ってくるな」 
456 デフォルトの名無しさん [sage] Date:2009/02/01(日) 22:06:47  ID: Be:
    プログラムくらいアホでも組める 

457 デフォルトの名無しさん [sage] Date:2009/02/01(日) 22:16:21  ID: Be:
    Linuxもアホでもかけるんだね。 

458 デフォルトの名無しさん [sage] Date:2009/02/01(日) 22:25:41  ID: Be:
    Linuxはアホじゃなくてライナス
    アホはAWK

    Aho はお国の言葉の読みだと本当に「アホ」のように読むんだとか聞いたことがあるなあ。 「阿呆とは俺のことかと Aho 言い」 

    【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】 
716 デフォルトの名無しさん [sage] Date:2009/02/02(月) 01:26:58  ID: Be:
    Emacs Lispは一度はまるとなかなか抜けだせんね…
    Emacsの機能を活用できる便利さに感動してから
    Emacsの限界にぶち当たるまでは。 

717 デフォルトの名無しさん [sage] Date:2009/02/02(月) 02:12:53  ID: Be:
    >>716
    Emacsの限界って何だ？

718 デフォルトの名無しさん [sage] Date:2009/02/02(月) 02:35:23  ID: Be:
    >>717
    Emacs Lispのパホーマンス
    Emacs Lispの記述能力
    画像処理（画像レイアウトが文字と同基準）
    言語処理（RtoL、縦書き実装しようとして死んだ）
    シングルスレッド 

719 デフォルトの名無しさん [sage] Date:2009/02/02(月) 09:26:54  ID: Be:
    >>718
    ひどい。ｗ
    テキストエディタに求めることじゃない。

    ＞言語処理（RtoL、縦書き実装しようとして死んだ）
    つ　Mule

720 デフォルトの名無しさん [] Date:2009/02/02(月) 17:18:10  ID: Be:
    インタプリタはただでさ遅いんだから
    LL文法で簡単に解析できる
    安全で強い静的片付けにするべきだと思うな。

721 デフォルトの名無しさん [sage] Date:2009/02/02(月) 17:30:47  ID: Be:
    おれ真逆だわ
    どうせ遅いんならその分便利に扱える動的型付けにするべきだと思うわ 

722 デフォルトの名無しさん [] Date:2009/02/02(月) 17:37:04  ID: Be:
    >>721
    コンパイル型にすれば動的片付け言語特有の遅さを緩和出来るのでは？ 

723 デフォルトの名無しさん [sage] Date:2009/02/02(月) 18:29:16  ID: Be:
    >>720
    もろちん実装次第だけど、静的型付けなら
    自動的に速いわけではない。

    静的型付け＋全文プリコンパイルよりも、
    動的型付け＋部分インタプリタのほうが
    きっと速いと思う。

724 デフォルトの名無しさん [] Date:2009/02/02(月) 18:31:30  ID: Be:
    >>723
    なるほどね。
    やったみたことはないけどそうかもしれない。

    2009年02月02日

    ■_

    ・日本電産の社長
    会社での掲示板にあった新聞記事(の写し)で知ったのだけど、 日本電産の永守社長の話として役員も含めて給与を(数%～?)下げることをしても解雇はしない。 このような状況で人件費を減らす目的で解雇するのは後々の会社の活力を失わせるとか発言しているらしい (ちょっと見ただけなのでだいぶ不正確ですが大筋は間違ってないと思います)。 たしかこの方は数ヶ月くらい前にのんびりしたいのなら退職してから好きなだけすればいいとか なんとか発言して(曲解されて?)、ネットで叩かれてた人ですよね。

    これじゃないなあ asahi.com（朝日新聞社）：日本電産、社員の給与を１―５％削減 - 日刊工業新聞ニュース - デジタル 

    ・センゴク
    
美濃守…

    ■_ そろそろなんかいっとかないとまずいけど英語が(ry

    CVS での gawk の更新状況を追いかけているSさんから「なんじゃこりゃ」なつぶやきがあったので 調べてみたところ locale が MAX_MBLEN> 1 な環境のときにとんでもなく遅くなるということが判明。 そのこと自体は、grepの正規表現マッチングをはじめ到るところで発生しているので、 あーはいはい。ってはもんなんですが、 

    sprintf() of gawk in cvs works very slow under ja_JP.UTF8

Hello,

The sprintf() function of latest gawk in CVS is very very slow.
I've checked the script below.

$ cat test.awk 
BEGIN {
    str = "abc";
    for (i = 1; i <= 10000; i++) {
        result = sprintf("%s%s", result, str);
    }
    print result;
}

$ time gawk -f test.awk > /dev/null 
gawk -f test.awk > /dev/null  7.61s user 0.01s system 99% cpu 7.674 total

But under C locale, it works very fast (over 100 times faster!!).

$ time LC_ALL=C gawk -f test.awk > /dev/null
LC_ALL=C gawk -f test.awk > /dev/null  0.05s user 0.00s system 18% cpu 0.301 
total

The release version of gawk-3.1.6 works fast under ja_JP.UTF8.

$ time ../gawk-3.1.6/gawk -f test.awk > /dev/null 
../gawk-3.1.6/gawk -f test.awk > /dev/null  0.05s user 0.00s system 95% cpu 
0.056 total

regards,

Hirofumi Saito.


    Re: sprintf() of gawk in cvs works very slow under ja_JP.UTF8
Re: sprintf() of gawk in cvs works very slow under ja_JP.UTF8
From: 	Aharon Robbins
Subject: 	Re: sprintf() of gawk in cvs works very slow under ja_JP.UTF8
Date: 	Sat, 31 Jan 2009 23:18:25 +0200

Hi. Re the below.

Thanks for the report. A patch is attached. It will show up in the CVS
in the next few days.

Arnold
---------------------------
(略)
Sat Jan 31 23:14:00 2009  Arnold D. Robbins  <address@hidden>

        * builtin.c (format_tree): For '%s', don't count the multibyte
        characters if we are just copying all the characters. Gives
        big speedup. Thanks to  Hirofumi Saito <address@hidden>
        for reporting the problem.

Index: builtin.c
===================================================================
RCS file: /d/mongo/cvsrep/gawk-stable/builtin.c,v
retrieving revision 1.29
diff -u -r1.29 builtin.c
--- builtin.c   29 Dec 2008 20:44:02 -0000      1.29
+++ builtin.c   31 Jan 2009 21:13:35 -0000
@@ -984,11 +984,13 @@
                                fill = zero_string;
                        parse_next_arg();
                        arg = force_string(arg);
-                       char_count = mbc_char_count(arg->stptr, arg->stlen);
                        if (fw == 0 && ! have_prec)
                                prec = arg->stlen;
-                       else if (! have_prec || prec > char_count)
-                               prec = char_count;
+                       else {
+                               char_count = mbc_char_count(arg->stptr, arg->stlen);
+                               if (! have_prec || prec > char_count)
+                                       prec = char_count;
+                       }
                        cp = arg->stptr;
                        goto pr_tail;
                case 'd':

    しかしこの修正は結局のところ、 すべてのケースで mbc_char_count() を呼んどでおくというのを止めて 書式文字列が一定の条件(%sで精度指定がある)を満たすときに呼ぶようにするというものなので、 

    Re: sprintf() of gawk in cvs works very slow under ja_JP.UTF8
Re: sprintf() of gawk in cvs works very slow under ja_JP.UTF8
From: 	Hirofumi Saito
Subject: 	Re: sprintf() of gawk in cvs works very slow under ja_JP.UTF8
Date: 	Mon, 2 Feb 2009 00:54:38 +0900

On Sat, 31 Jan 2009 23:18:25 +0200
Aharon Robbins <address@hidden> wrote:

> Hi. Re the below.
> 
> Thanks for the report. A patch is attached. It will show up in the CVS
> in the next few days.

Thank you for your patch.
Your patch works very fine.
But if I change the argument of sprintf() function from "%s" to "%10s",
gawk works slow again.

BEGIN {
    str = "abc";
    for (i = 1; i <= 10000; i++) {
        result = sprintf("%10s%s", result, str);
    }
    print result;
}

regards,

Hirofumi Saito.

    問題の関数 mbc_char_count() がガンガン呼ばれるような状況になれば結果は同じなのだった。

    そもそも、s?printf の出力を「バイト幅」で指定するのはおかしくね? というクレームが発端だったと 思うんだけど(該当のレポートは見つけられなかった)、 たとえば UTF-8 で 2バイト(以上)になるけれども、キャラクタとしてはいわゆる半角な表示幅の もののときに s?printf で整形しづらいじゃねーかという話。 ところが、それは一文字は常に同じ表示幅だという前提を置いちゃうことになるので、 わたしらのように「半角文字」の倍の表示幅を持つ「全角文字」を使う人たちにとってはいい迷惑になる。 といって、まあたとえばUTF-8(≒Unicode)に限ったとしてそのコードポイントを与えたときに それに対応するキャラクタの表示幅を取得できるか。というと完全に信頼できる手段は今のところは、 たとえOSを限定したとしても存在していないはず(ですよね? ＞偉い誰か)。 なので、踏まないでもいいヘビの尻尾を踏みに行ってパフォーマンスバグ(でしょうこれは)を 招いたと。しかし英語でこれを説得する文章が書けるか。つーと…○|￣|＿

    もいっちょ。 

    Re: bug in windows??

Hello,

liutaoxwl wrote:
> When I used gettext in windows like this:
> 
> #include <locale.h>
> #include "libintl.h"
> #define _(string) gettext(string)
> #pragma comment(lib, "../libintl.lib")
> fprintf (stdout, _("hello world!\n"));
> I get a error when run at fprintf.

You are not saying what kind of error you are getting. No diagnose without
detailing the symptoms.

> When I include gettext.h but not libintl.h, there has no error, but it do
> nothing.

See the gettext FAQ:
http://www.gnu.org/software/gettext/FAQ.html#integrating_noop
http://www.gnu.org/software/gettext/FAQ.html#windows_howto
http://www.gnu.org/software/gettext/FAQ.html#windows_setenv

Bruno

    gettext のFAQにこういう項目(windows_ほげほげ)があったのか!

    ■_ Pythonのソースを読んでみるでござるよ

    って前にもちょっとだけやったような気もするけど気にしなーい。

    まずソースツリーの構成から。 

     C:\work\src\python\Python-3.0 のディレクトリ

2008/12/04  02:30       <DIR>          Demo        その名の通りデモ関連
2008/12/04  02:57       <DIR>          Doc         ドキュメント。下位ディレクトリもあり大量 *1
2008/12/04  02:30       <DIR>          Grammar     構文定義ファイル? がある
2008/12/04  02:30       <DIR>          Include     C/C++用のヘッダーファイル
2008/12/04  02:31       <DIR>          Lib         .py なライブラリ (ctypesはちと違う?)
2008/12/04  02:31       <DIR>          Mac         Mac OS X 用の基準ディレクトリ
2008/12/04  02:30       <DIR>          Misc        その名の通りいろいろ
2008/12/04  02:32       <DIR>          Modules     *.c なコンパイルするライブラリ(モジュール)
2008/12/04  02:30       <DIR>          Objects     string や list 等々のオブジェクトを定義する .c
2008/12/04  02:31       <DIR>          Parser      そのまんま
2008/12/04  02:31       <DIR>          PC          Windows とかOS/2とかの基準ディレクトリ
2008/12/04  02:30       <DIR>          PCbuild     たぶんWindows のデフォルト (python.org出配布しているのを作るときのもの?)
2008/12/04  02:30       <DIR>          Python      グローバル関数とか
2008/12/04  02:31       <DIR>          Tools       名前のまま
2008/11/17  03:33              667,772 configure
2008/12/01  07:46              103,699 configure.in
2003/06/14  15:58                7,122 install-sh
2007/01/14  12:31                  941 INTBENCH
2008/03/02  02:45               13,801 LICENSE
2008/11/19  07:37               38,374 Makefile.pre.in
2008/09/07  15:24               29,283 pyconfig.h.in
2008/12/04  02:15                6,305 README
2008/12/04  02:15                1,452 RELNOTES
2008/10/17  21:05                2,168 runtests.sh
2008/11/05  05:45               65,234 setup.py
              11 個のファイル             936,151 バイト


*1 ファイルの拡張子が .rst ってのに統一されていて、一見プレインテキストにも
見えるけどなんか決まってるのかな(Perl の .podみたいに)?

    とりあえず Objects, Parser, Python あたりから見ていけばいいっぽい。 あ、オブジェクト型の定義を知るために Include もいるか。 

     C:\work\src\python\Python-3.0\Parser のディレクトリ

2004/06/29  23:03                2,829 acceler.c
2008/05/28  05:34               11,627 asdl.py
2008/10/26  00:49               39,918 asdl_c.py

  (略)
  
2008/02/24  03:30               27,103 spark.py
2008/10/17  12:38               36,072 tokenizer.c
2008/10/17  12:38                2,703 tokenizer.h
2002/08/05  02:29                   36 tokenizer_pgen.c
              24 個のファイル             189,395 バイト


     C:\work\src\python\Python-3.0\Objects のディレクトリ

2008/12/04  02:30       <DIR>          stringlib
2008/09/27  06:49               60,742 abstract.c
2008/08/31  04:21                4,379 boolobject.c
2008/11/20  07:05               96,184 bytearrayobject.c

   (略)

2008/12/01  07:46              260,939 unicodeobject.c
2008/09/10  23:08              105,673 unicodetype_db.h
2008/09/11  06:57               29,239 weakrefobject.c
              39 個のファイル           1,692,160 バイト

 C:\work\src\python\Python-3.0\Objects\stringlib のディレクトリ

2008/09/27  07:48                  713 count.h
2008/06/14  07:53                2,613 ctype.h
2007/12/11  00:50                  601 eq.h

(略)

2008/06/14  07:53               37,237 string_format.h
2008/06/14  07:53                9,582 transmogrify.h
2008/06/14  07:53                1,956 unicodedefs.h
              13 個のファイル              99,157 バイト


     C:\work\src\python\Python-3.0\Parser のディレクトリ

2004/06/29  23:03                2,829 acceler.c
2008/05/28  05:34               11,627 asdl.py
2008/10/26  00:49               39,918 asdl_c.py

(略)

2008/03/31  14:14                4,350 Python.asdl
2008/02/24  03:30               27,103 spark.py
2008/10/17  12:38               36,072 tokenizer.c
2008/10/17  12:38                2,703 tokenizer.h
2002/08/05  02:29                   36 tokenizer_pgen.c
              24 個のファイル             189,395 バイト


     C:\work\src\python\Python-3.0\Include のディレクトリ

2008/08/27  07:40               41,610 abstract.h
2007/02/27  04:14                1,038 asdl.h
2005/12/18  05:54                  230 ast.h
  
  (略)

2008/10/17  04:34               31,541 object.h
2007/12/19  11:45               12,273 objimpl.h
2008/06/12  00:59                4,575 opcode.h

  (略)

2006/03/10  20:20                  861 ucnhash.h
2008/10/19  23:07               56,497 unicodeobject.h
2008/06/14  07:53                  512 warnings.h
2007/12/19  11:45                2,428 weakrefobject.h
              84 個のファイル             374,764 バイト

    んで、すべての源? な PyObject について。 

    Include/object.h

#ifndef Py_OBJECT_H
#define Py_OBJECT_H
#ifdef __cplusplus
extern "C" {
#endif


/* Object and type object interface */

/*
Objects are structures allocated on the heap.  Special rules apply to
the use of objects to ensure they are properly garbage-collected.
Objects are never allocated statically or on the stack; they must be
accessed through special macros and functions only.  (Type objects are
exceptions to the first rule; the standard types are represented by
statically initialized type objects, although work on type/class unification
for Python 2.2 made it possible to have heap-allocated type objects too).

An object has a 'reference count' that is increased or decreased when a
pointer to the object is copied or deleted; when the reference count
reaches zero there are no references to the object left and it can be
removed from the heap.

An object has a 'type' that determines what it represents and what kind
of data it contains.  An object's type is fixed when it is created.
Types themselves are represented as objects; an object contains a
pointer to the corresponding type object.  The type itself has a type
pointer pointing to the object representing the type 'type', which
contains a pointer to itself!).

Objects do not float around in memory; once allocated an object keeps
the same size and address.  Objects that must hold variable-size data
can contain pointers to variable-size parts of the object.  Not all
objects of the same type have the same size; but the size cannot change
after allocation.  (These restrictions are made so a reference to an
object can be simply a pointer -- moving an object would require
updating all the pointers, and changing an object's size would require
moving it if there was another object right next to it.)

Objects are always accessed through pointers of the type 'PyObject *'.
The type 'PyObject' is a structure that only contains the reference count
and the type pointer.  The actual memory allocated for an object
contains other data that can only be accessed after casting the pointer
to a pointer to a longer structure type.  This longer type must start
with the reference count and type fields; the macro PyObject_HEAD should be
used for this (to accommodate for future changes).  The implementation
of a particular object type can cast the object pointer to the proper
type and back.

A standard interface exists for objects that contain an array of items
whose size is determined when the object is allocated.
*/

(略)

#ifdef Py_TRACE_REFS
/* Define pointers to support a doubly-linked list of all live heap objects. */
#define _PyObject_HEAD_EXTRA		\
	struct _object *_ob_next;	\
	struct _object *_ob_prev;

#define _PyObject_EXTRA_INIT 0, 0,

#else
#define _PyObject_HEAD_EXTRA
#define _PyObject_EXTRA_INIT
#endif

/* PyObject_HEAD defines the initial segment of every PyObject. */
#define PyObject_HEAD		        PyObject ob_base;

#define PyObject_HEAD_INIT(type)	\
	{ _PyObject_EXTRA_INIT		\
	1, type },

#define PyVarObject_HEAD_INIT(type, size)	\
	{ PyObject_HEAD_INIT(type) size },

/* PyObject_VAR_HEAD defines the initial segment of all variable-size
 * container objects.  These end with a declaration of an array with 1
 * element, but enough space is malloc'ed so that the array actually
 * has room for ob_size elements.  Note that ob_size is an element count,
 * not necessarily a byte count.
 */
#define PyObject_VAR_HEAD      PyVarObject ob_base;
#define Py_INVALID_SIZE (Py_ssize_t)-1

/* Nothing is actually declared to be a PyObject, but every pointer to
 * a Python object can be cast to a PyObject*.  This is inheritance built
 * by hand.  Similarly every pointer to a variable-size Python object can,
 * in addition, be cast to PyVarObject*.
 */
typedef struct _object {
	_PyObject_HEAD_EXTRA
	Py_ssize_t ob_refcnt;
	struct _typeobject *ob_type;
} PyObject;

typedef struct {
	PyObject ob_base;
	Py_ssize_t ob_size; /* Number of items in variable part */
} PyVarObject;

(略)


#ifdef __cplusplus
}
#endif
#endif /* !Py_OBJECT_H */

    ■_ 水滸伝。だろうなあ(北方健三の?)

    だだもれ
今は槍の人が死ぬのかどうかドキドキしている。
“豹子頭”林冲 のことかな? ＞槍の人
「旅するボス」とか「影が薄いボス」
どっちかが宋江だろうけどもう一方は誰だ? 張蓋とか。
「飛脚」
これは “神行太保”戴宋だろうな
とか、「槍の人」とかいう言い方になると思う。

 軍師候補が死ぬとは思わなかった。
“智多星”呉用…はアレだよなあ。誰だろう。

豪傑女がレギュラーになるのかどうかも気になるな。
“一丈青”扈三娘かな?
そうえいば敵忍者ボスのあっけない死に様には吹いた。
忍者。誰だ?
コエンシャクは違うだろうしなあ。

    ■_

    ■_ Pythonのソースツリーを見ていたら

    Grammar つーディレクトリに、Grammar というファイルがあるのを発見。 BNF とは違うけど、似たような感じのもので構文規則を定めているもの? で、2.6.1と3.0とで大きさが違ったので (まあ少なくとも printやら例外やらで違いが出るはずだから当然ちゃあ当然だけど) diff を取ってみてぱっと見気になったのがこの部分。 

    -funcdef: 'def' NAME parameters ':' suite
(略)
+funcdef: 'def' NAME parameters ['->' test] ':' suite

    なんですかこの ['->' test] は? testの定義を見ると test: or_test ['if' or_test 'else' test] | lambdef とか。この先の or_test とか lambdef には潜ってかないけど、想像するに 何かの条件で関数定義(funcdef)をどうこうすることができるということなのか? 

    >python3
Python 3.0 (r30:67507, Dec  3 2008, 20:14:27) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 100
>>> y = 50
>>> def hoge() -> x > y :
...     print("hello")
...
>>> hoge()
hello
>>> def fuga() -> y > x :
...     print("fuga")
...
>>> fuga()
fuga
>>>

    違うっぽい。 たぶんこの関数で処理しているんだと思うんだけど (RARROW ってのが '-'gt;'に対応する名前) 

    static stmt_ty
ast_for_funcdef(struct compiling *c, const node *n, asdl_seq *decorator_seq)
{
    /* funcdef: 'def' NAME parameters ['->' test] ':' suite */
    identifier name;
    arguments_ty args;
    asdl_seq *body;
    expr_ty returns = NULL;
    int name_i = 1;

    REQ(n, funcdef);

    name = NEW_IDENTIFIER(CHILD(n, name_i));
    if (!name)
        return NULL;
    args = ast_for_arguments(c, CHILD(n, name_i + 1));
    if (!args)
        return NULL;
    if (TYPE(CHILD(n, name_i+2)) == RARROW) {
        returns = ast_for_expr(c, CHILD(n, name_i + 3));
        if (!returns)
                return NULL;
        name_i += 2;
    }
    body = ast_for_suite(c, CHILD(n, name_i + 3));
    if (!body)
        return NULL;

    return FunctionDef(name, args, body, decorator_seq, returns, LINENO(n),
                       n->n_col_offset, c->c_arena);
}

    なにがなにやら。

    ■_ Dive into Python 3

    Python 3への移行のためのいろいろがあるみたい。 

    Porting code to Python 3 with 2to3 - Dive into Python 3
http://diveintopython3.org/porting-code-to-python-3-with-2to3.html
Porting code to Python 3 with 2to3

    ❝ Life is pleasant. Death is peaceful. It’s the transition that's troublesome. ❞
                                                                 — Isaac Asimov (attributed)

   1. Diving in
   2. print statement
   3. Unicode string literals
   4. unicode() global function
   5. long data type
   6. <> comparison
   7. has_key() dictionary method
   8. Dictionary methods that return lists
   9. Modules that have been renamed or reorganized
         1. http
         2. urllib
         3. dbm
         4. xmlrpc
         5. Other modules
  10. Relative imports within a package
  11. next() iterator method
  12. filter() global function
  13. map() global function
  14. reduce() global function (3.1+)
  15. apply() global function
  16. intern() global function
  17. exec statement
  18. execfile statement (3.1+)
  19. repr literals (backticks)
  20. Exceptions
  21. try...except statement
  22. raise statement
  23. throw method on generators
  24. xrange() global function
  25. raw_input() and input() global functions
  26. func_* function attributes
  27. xreadlines() I/O method
  28. lambda functions with multiple parameters
  29. Special method attributes
  30. __nonzero__ special class attribute
  31. Octal literals
  32. sys.maxint
  33. callable() global function
  34. zip() global function
  35. StandardError() exception
  36. types module constants
  37. isinstance() global function (3.1+)
  38. basestring datatype
  39. itertools module
  40. sys.exc_type, sys.exc_value, sys.exc_traceback
  41. List comprehensions over tuples
  42. os.getcwdu() function
  43. Metaclasses
  44. Matters of style
         1. set() literals
         2. buffer() global function
         3. Whitespace around commas
         4. Common idioms

Diving in

Python 3 comes with a utility script called 2to3, which takes your actual Python 2 
source code as input and auto-converts as much as it can to Python 3. Case study: 
porting chardet to Python 3 describes how to run the 2to3 script, then shows some 
things it can't fix automatically. This appendix documents what it can fix 
automatically.

print statement (print文)

In Python 2, print was a statement. Whatever you wanted to print simply followed the 
print keyword. In Python 3, print() is a function ― whatever you want to print is 
passed to print() like any other function.

Python 2 では print は文でした。あなたがprint というキーワードの後ろにただ単に
並べていたものが出力されていました。Python 3では、print()は
関数になっています。あなたが出力したいものは他の関数と同様に print() に
渡されます。


Notes 	Python 2 	Python 3
  
    
  
  
    
    
      ①printprint()
    
    
    
    
      ②print 1print(1)
    
    
    
    
      ③print 1, 2print(1, 2)
    
    
    
    
      ④print 1, 2, print(1, 2, end=' ')
    
    
    
    
      ⑤print >>sys.stderr, 1, 2, 3print(1, 2, 3, file=sys.stderr)
    
    
      

    

   1. To print a blank line, call print() without any arguments.
      空行を出力するには引数なしで print() を呼びます。

   2. To print a single value, call print() with one argument
      あるひとつの値を出力したい場合にはひとつの引数を与えて print()を呼びます。

   3. To print two values separated by a space, call print() with two arguments.
      二つの値をスペースで区切って出力するには二つの引数を与えてprint()を呼びます。

   4. This one is a little tricky. In Python 2, if you ended a print statement with a
      comma, it would print the values separated by spaces, then print a trailing
      space, then stop without printing a carriage return. In Python 3, the way to do
      this is to pass end=' ' as a keyword argument to the print() function. The end
      argument defaults to '\n' (a carriage return), so overriding it will suppress
      the carriage return after printing the other arguments.
      ここでひとつのトリッキーな小技があります。Python 2 では、print文の末尾にカンマを
      つけておくと、値をスペース区切られた値と、末尾にも空白を出力するのです。
      そして改行を出力することなく終わります。Python 3では、このような出力を行うには
      キーワード引数を使って end=' ' を print() 関数の呼び出し時に与えます。
      end 引数はデフォルトでは '\n' (改行)であり、それを上書きすることによって
      他の引数を出力したあとの改行の出力を抑制することになります。

   5. In Python 2, you could redirect the output to a pipe ? like sys.stderr ? by using
      the >>pipe_name syntax. In Python 3, the way to do this is to pass the pipe
      in the file keyword argument. The file argument defaults to sys.stdout (standard
      out), so overriding it will output to a different pipe instead.
      Python 2では、>>pipe_name syntax を使うことで sys.stderr のようなところに
      リダイレクトすることが可能でした。Python 3では。パイプに出力を送り込むには
      キーワード引数 file を使用します。file 引数はデフォルトでは標準出力である
      sys.stdout になっています。ですからこれを上書きすることによってその出力を
      異なるところへ送り込むことができるのです。

    (例によって)続く。

    2009年02月01日

    ■_

    ・ネタ本
    矢沢さんのネタ本 (Amazon.co.jp： IT言葉はオレに聞け!―日経パソコン用語読本: 矢沢 久雄, カモシタ ハヤト, 日経パソコン編集: 本 Amazon.co.jp： ifとelseの思考術 プログラマ脳育成講座: 矢沢 久雄: 本)、誰か読んでみたいという人います? 資源ゴミの回収に出そうかと思いましたがそれは週末なので、希望があればその前に。 完全常識とかセオリーはすでに処分済みw

    ■_ すげえw

    なんか事務局削除があるかも? 

    緊急事態です!!! -OKWave

これから未来のIT業界像を見据えたとき、PHPとPerl CGIとどちらを習う方がいいのでしょうか。
自分はどちらとも初心者なので、PHPの長所と短所、Perl CGIの長所と短所が分かりません。
後、プログラマーを目指している訳ではないので、ホームページを作る際とか掲示板を作る際と
かWebアプリケーションを作成するとかで使い勝手の良いプログラミング言語はどっちですかね。

即答して頂けると、大変有り難いです。
どこかで重複した質問になってしまって本当に申し訳ありません。
どうか今日１日だけ許して頂ければ、後は削除されても構いませんので、１つお願い申し上げます。

    では即答するとPHPの方がおすすめです。
最初はHTMLの感性から入れます。
プログラムが必要なとこだけ <? echo 'unko' ?> と書けばよいです。
ファイル名を aaa.php にしてアップロードすればそれで動作します。
あと、本家マニュアルがかなり親切な部類だと思います。

    この回答へのお礼
即レス、ありがとうございます。
そんなに簡単ですかね。まぁ、簡単だから良いとは思えませんが。
因みに、将来性とかに関してはどうなんでしょう。
これからも長く使われ続けるスクリプト言語なのですかね。
問題はそこなんですけどね。

    排他的なものでもないですので、どっちでもいいんじゃないでしょうか。

    この回答へのお礼
レスを頂き、ありがとうございます。
そうなんですけどね。
何故緊急事態なのかと言うとあるプログラム通信講座がありまして。
ちょうど今日１月３１日まで講座の受講料が大幅割引してるんです。
それで、１つは以前学んだ事のあるJavaで、もう１つ受講しようと思いまして。
そこで、Perl/CGIにするかPHPスクリプトにするか悩んでいるわけなのです。
将来的にどっちを学んだ方がお得なんでしょうか。

    PHPとPerl CGIのどちらかが良いかと言えば、趣味で組むならどちらでも問題は有りません。と
いうか一つの言語を理解していれば、どちらも難しくありませんよ。特にＣ＋＋かＪａｖａをち
ゃんと理解していたら簡単に理解できます。

昔はPerlを知っていれば小規模なＷＥＢサイドのプログラムは問題ありませんでしたが、色々な
言語が登場して状況が変わってきました。なので将来は何が有効かなんて誰にも分りません。状
況が変わったらプログラム言語を乗り換えれば良いだけです。

とりあえず、ここ５年を見据えて選ぶとしたら文法的にはＰＨＰの方が分りやすいと思いますの
で、ＰＨＰをお勧めしておきます。

    この回答へのお礼
貴重なアドバイスを頂き、ありがとうございます。
確かにそうですね。将来性を聞いたのは間違いでした。
自分はへそ曲がりでは、ないのですが、PHPのソースを見て独学で習得も不可能ではないかな、と正直思いました。
その分、分かりにくいPerl/CGIを学んだ方がいいのかな、とも思っています。
ですが、やはり分かりやすい方が学びやすいですよね。
そう考えると、やはりPHPですか……。
実は、これとほぼ同じ内容の質問をCGIにも書いています。
ただ、反応はこちらしかないのも、人気の高さと言うのでしょうか。
十分に参考にさせていただきます。

    >その分、分かりにくいPerl/CGIを学んだ方がいいのかな、とも思っています。ですが、
>やはり分かりやすい方が学びやすいですよね。

Perlは見た目が分りづらいだけで言語的に難易度が高いわけではありませんし、同じ事をするな
らPHPの方が分りやすく書けると私は思います。所詮、目的の機能を作るための言語なんですか
ら、あえて面倒な方を選ばなくて良いと思います。PHP自体CやC++やPerlの良いとこ取りをした
言語なので似ています。必要になったらPerlを覚えればよいだけです。

    この回答へのお礼
貴重なアドバイスを頂き、ありがとうございます。
なるほど、PHPについての分かりやすい解説は物凄く参考になります。
そうですよね。同じ事をするのにわざわざ難しい方を選ぶ必要性はありませんよね。
よく理解できました。

    これからのIT業界像を見えすえたら、両方廃れるでしょう。
なぜなら、マルチコア時代に入るからです。
まぁ、プログラマーを目指している訳ではないということで、PHPの方がいいですよ。ここ２年ぐらいはもつと思います。
・・・質問の意図がわかりませんけど。。。

    個人的にはPerlは癖がありますね。
覚えやすさはPHPでしょう。

>なぜなら、マルチコア時代に入るからです。
サーバサイド側はクライアントサイドがマルチコアに入るだいぶ前から
マルチCPUが当たり前でした。
サーバサイド側は一人で使うわけではないので
常時何人もの人にアクセスされるのが当たり前です。
PHPやPerlそのものがマルチスレッド対応して無くても
そんなのあまり関係ないでしょう。

    >なぜなら、マルチコア時代に入るからです。
ＷＥＢサーバは、マルチコＣＰＵ、マルチスレッドで動いていますので、別にＰＨＰやＰｅｒｌ
がマルチＣＰＵ、マルチスレッドに対応する必要がありません。そのままで対応してると言えま
す。ＰＨＰをサーバサイドで動かす限りマルチコアを意識したプログラミングって必要ないでし
ょう。
サーバサイドでスレッド制御が必要だったら、もっと別の言語があります。って事でそこは気に
しなくて良いです。今の所、数多くのサイトがＰＨＰが書かれていますので２年で消えてなくな
るって事はないと思います。企業がそんな開発費の無駄を許すとも思えませんしね。

    後、PHPって言語仕様が変わりやすい言語だと思います。

レンタルサーバなんかだとPerlは使えるけどPHPは使えないってサーバもまだまだあります。
逆にPHPが使えるところはPerlも使えるのが多いです。

それとPHPでもPerlでもいいけど
両方とも昔ながらの構造化プログラミングもできますけど
オブジェクト指向を意識したプログラミングをした方がいいです。


zwiさん自分も後から気がつきましたが専門家回答している人。
専門学校生のまだ就職もしていないプロではないアマです。
専門家気取りをしたい年頃なのでしょう。

    マルチスレッドとマルチコアは別物です。100%とCPUについて無知な方々なんですね。
だから、PHPやPerl使いをプログラマーと呼びたくないんです。
全然プロじゃないよ。

おそらく他の方は、小規模プロジェクトばかりやっている方々なんでしょう。（そもそも、大規
模プロジェクトでは、PHPやPerlを使うことじたいないけど）コア数が1024などのような環境で
の、プログラミングをしたことがないのでしょうね。想定もしていないようですし。マルチコア
に関して調べてもいないみたいですし。ただ、単にアムダールの法則を適応すればいいじゃない
とか思っているのでは？それと、仕事をして専門家とって言っている人は、視野が狭すぎる。研
究職って知ってますか？学生でも、大きなプロジェクトにかかわっている人もいます。

いったい、どんな視点を持って、顧客の問題を解決しようとしているのかさっぱりです。

価格の心配をしている方もいます。
２年後の動向を探ってみてください。どれだけのスピードでコア数が上がるのか。CPUの値段の
予測をしてみてください。それらを計算して、見積もり金額を出してください。どう計算しても、
今より安くなりますから。

最後に、マルチコアに関して調べてもいないのに、書き込まないでください。

    自分でもおっしゃている通り、一般人にはコア数が1024なんて使うことはありませんよ。なので
質問者さんの話の方向とはかけ離れています。
スレッドがどのＣＰＵコアに割り当てられるか気にするような高速性が求められるプロジェクト
をPerlやPHPで書くわけ無いじゃないですか。PerlやPHPの存在する意義を考えてみてください。
あなたがどう思おうとPerlやPHPの市場は存在し使われ続けています。これからも続いていくで
しょう。大規模なプロジェクトしか知らない人には、どうでもよい事だと思いますので質問者さ
んのスレをこれ以上荒らさないで下さい。

    >マルチスレッドとマルチコアは別物です。
「なぜなら、マルチコア時代に入るからです。」とあたかも
これから入るみたいな言い方の人には言われたくないですね。
もう何年も前に入っているし
マルチコアどころかマルチCPUならもうかなり前からサーバサイドでは
当たり前のようにあります。

>大規模プロジェクトでは、PHPやPerlを使うことじたいないけど
Web系の大規模プロジェクトはJavaって言いたいのかな?


>コア数が1024などのような環境での、プログラミングをしたことがないのでしょうね。
Webサーバ系ではまぁまず無いでしょうね。
あったとしてもクラスターを組んである程度でしょうね。
でこんなところで「コア数が1024」なんていうWebサーバしかも
質問者が求めているレベルでこんな事を書く学生さんは
周りが見えていませんね。

>仕事をして専門家とって言っている人は、視野が狭すぎる。
自信過剰な井の中の蛙の学生も視野が視野が狭すぎる。

>研究職って知ってますか？
専門学校のレベルは程度が知れていますね。
自分はすごいと思って卒業後即戦力になると勘違いしている学生さんは多いですからね。

>学生でも、大きなプロジェクトにかかわっている人もいます。
ttschoolさんはそうなんですか?
そりゃSoftEtherを開発した人は大学在学中に開発したような人はいますけどね。

>どんな視点を持って、顧客の問題を解決しようとしているのかさっぱりです。
だからこそ、何が何でも高性能サーバを求める必要は無い。
案件規模によって
共用サーバ
VPSサーバ
専用サーバ
と切り分ける。
で専用サーバにしたとして4コアや8コアとしてもWebシステム上、
マルチプロセスで複数のプロセスが動く。
Webシステムの特性上、一人だけが同時利用するわけではない。
別にバックで動くデータベースなどの各種プロセスがある。
そう考えれば別にマルチスレッドに対応して無くても
マルチタスクで動けばマルチコア/マルチCPUは有意義に動く。

    実際に仕事をしています。
それからWebの大規模プロジェクトとは、CやC++が必ず必要なプロジェクトのことです。また、
ソースコードの行数が多いから大規模プロジェクトという訳でもありません。それから、私の携
わるプロジェクトでは、提供されているドライバを使用することはほぼありません。提供されて
いるドライバなどでは、ボトルネックがあり、必要な部分をC/C++で記述しています（ボトルネ
ックとならないと判断できた場合は、提供されているドライバを使います）。

AD（アプリケーション記述）の作成もしています。英語で。


> 別にバックで動くデータベースなどの各種プロセスがある。
> そう考えれば別にマルチスレッドに対応して無くても
> マルチタスクで動けばマルチコア/マルチCPUは有意義に動く
Oracleならコア数を指定するだけですやん
OSの仕組み知っていますか？自動的に各コアに命令を発行してくれると思っているんですか？


それから、私は最初、単にPHPを薦めただけです。
マルチコアに関することを少しだけ付け加えて。
コア数が1024などの文章は、あなた方に向けたものです。

    >実際に仕事をしています。
専門学生君のバイト?

>それからWebの大規模プロジェクトとは、CやC++が必ず必要なプロジェクトのことです。
オイオイ。それだけで大規模プロジェクトで区別するなんて
まさに井の中の蛙ですね。
>CやC++が必ず必要なプロジェクトのことです。
こんなのが大規模プロジェクトの定義ならPHPでPECLを使ったら大規模プロジェクトだ(笑)

>なぜなら、マルチコア時代に入るからです。
>ここ２年ぐらいはもつと思います。
これの部分に対する突っ込みに対してその返答で
>コア数が1024などの文章は、あなた方に向けたものです。
これは無いでしょう。

>> 別にバックで動くデータベースなどの各種プロセスがある。
>> そう考えれば別にマルチスレッドに対応して無くても
>> マルチタスクで動けばマルチコア/マルチCPUは有意義に動く
>Oracleならコア数を指定するだけですやん
>OSの仕組み知っていますか？自動的に各コアに命令を発行してくれると思っているんですか？
文書読解力無い?
バックで動くプロセスの一つの例としてDBをあげただけですよ。
「など」の意味わかっていますか?
それなのにこの返答内容はあり得ないですよ。

>それから、私は最初、単にPHPを薦めただけです。
だったらPHPとだけ書けばよかったのに井の中の蛙が知ったかぶりして
>なぜなら、マルチコア時代に入るからです。
>ここ２年ぐらいはもつと思います。
なんて書かなければいいのにね。

    だから質問者さんに関係ない話題は止めてください。ttschoolさん、あなたの自慢を聞きたいわ
けでは有りません。質問者さんに関係の無い話題(マルチコア、マルチスレッド、マルチＣＰＵ)
に関しては削除依頼します。ご了承ください。

    ■_ 1.9.1リリースについての反響?

    1.9.1リリースについての反響? 

    
Ruby 1.9.1, the first stable version of the 1.9 series released : programming

What's the rationale for making hashtables ordered by default? The time and space 
overhead is non-trivial and in most cases ordering does not need to be preserved, so 
why not offer a separate ordered hashtable class that people can use when they need 
the functionality?

    The overhead is around two pointers per element plus a few pointer updates on 
insertion (up from 4 words + 8+ bytes of malloc overhead). Keep in mind that there's 
already so much overhead in Ruby's runtime that these two pointers don't change things 
that much, in fact; they'd represent a difference in a more efficient implementation. 
For instance, an object with just one instance variable needs no less than 27 words 
(plus a couple for malloc overhead), or ~116 bytes on x86 (it gets obviously worse on 
x64). Even a String key is going to take several dozens of bytes, so the 2 words 
needed to keep insertion order are two drops in the sea of inefficiency.

The reason why there's no separate class is probably that you'd need a different 
syntax (or an extension of the current one) for literals, or extra care when passing 
hashes around.

(There's no overhead for internal hash tables with less than 5 elements for which key 
equality = pointer equality, e.g. for small instance variable/method tables.)

    I've never ever used that. I find it weird in a funny sort of way that people use the 
same language to do roughly the same things in very different ways.

    For better or worse I think that is one of the defining differences between the Ruby 
and Python cultures.

    Why is 1.9.1 the version of the first stable release?

Also, if you're going to break backward compatibility, why not go straight to 2.0?

    Well, yes and no. I use ruby only infrequently, and the way I mentioned it makes more 
intuitive sense to people like me or to new users. And obviously if the difference 
between 1.7 and 1.8 is much less than the difference between 1.8 and 1.9, that should 
be indicated in some way. Also, I think of .0s as the first stable release of any 
series (see KDE fiasco).

But it wasn't as much a criticism as an honest question. I don't actually care, I just 
wonder why they did it that way.

    Because for a while they flirted with the "stable even, unstable odd" 
version numbers.

1.9 was supposed to be the unstable branch of 2.0 and it was supposed to go to 2.0 
when it was stable.

eventually people realized that was silly and decided to keep it 1.9.

    

Ruby 1.9.1 released » Josh the Outspoken
Ruby 1.9.1 was released today. You wouldn’t know it from the version number “1.9.1″ 
but this is a big deal in the Ruby community. It’s the Python 3000 of Ruby, except it’
s an even bigger deal than that because it’s not only a bunch of 
backward-incompatible language changes, but it’s also a totally new implementation 
with much better performance than the Ruby 1.8.x line.

I’m glad to see this release, because I was starting to worry it would never happen, 
sort of like Perl 6. Now that Perl 6 has become the Duke Nukem Forever of programming 
languages, I was worried that Ruby 2.0 (oops, 1.9.x now) was going to suffer the same 
fate, and cause stagnation in the Ruby community.

But now it’s out, and the performance number show it still lagging behind Python a 
bit, but significantly faster than Ruby 1.8. It also apparently has native threads, 
which Ruby 1.8 did not.

I like Ruby quite a lot as a language. But I’m finding it harder to buy into its 
culture and its future. One major example is the documentation (or lack thereof) that 
accompanies this release. Being that this is a major release with major improvements 
and backward-incompatible changes, you would expect a great deal of information about 
what has changed. But here is what the “NEWS” file (their release notes) looks like:

    ■_ 今日のム板から

    【初心者歓迎】C/C++室 Ver.63【環境依存OK】 
724 デフォルトの名無しさん [sage] Date:2009/01/31(土) 19:39:26  ID: Be:
    C言語よこんにちは的な初心者が出会っておくと得な
    Ｃ言語独習参考書と無料の統合開発環境を教えてください。 

728 デフォルトの名無しさん [sage] Date:2009/01/31(土) 20:54:00  ID: Be:
    >>724
    参考書=K&R
    IDE
    windows=VS EE、QtCreator、Code::Blocks、DialogBlocks、DevC++
    Linux=Code::Blocks、emacs、…monoとかも？
    macは知らん
    勧めてないけど、borlandが初心者にはやさしいかもな 

730 デフォルトの名無しさん [sage] Date:2009/01/31(土) 21:17:34  ID: Be:
    >>728
    K&Rなんか初心者に薦めんなボケ 

731 デフォルトの名無しさん [sage] Date:2009/01/31(土) 23:00:38  ID: Be:
    >>730のオススメも是非教えてくれ。 

732 デフォルトの名無しさん [sage] Date:2009/01/31(土) 23:15:36  ID: Be:
    この手の話題は結論出ないからなぁｗ
    そんなに答えが欲しいならスレ総力を挙げて本を作るのだ 

733 デフォルトの名無しさん [sage] Date:2009/01/31(土) 23:25:08  ID: Be:
    お前らの方が良い本作れそうだなｗ
    あくまでも初心者対象としてだが 

734 デフォルトの名無しさん [sage] Date:2009/01/31(土) 23:33:36  ID: Be:
    それは2chねらーに夢見すぎだｗ

    いかにも有能そうに、自分以上の存在を小馬鹿にする技術が
    発達してるだけだよ、2chねらーなんてｗ 

735 724 [sage] Date:2009/01/31(土) 23:33:52  ID: Be:
    結局独習Ｃにした。糞たかいが仕方ない。未来への投資と考えて・・・orz 


    推薦図書/必読書のためのスレッド 44 
322 デフォルトの名無しさん [sage] Date:2009/02/01(日) 02:02:43  ID: Be:
    洋書を買って勝手に翻訳しているんだけど、こういうのってどこかが出版してくれないのかな
    自分と周りだけに見せているのは何かもったいないような気がする 

323 デフォルトの名無しさん [sage] Date:2009/02/01(日) 02:06:29  ID: Be:
    全訳した後に持ち込んでみれば？ 

324 デフォルトの名無しさん [sage] Date:2009/02/01(日) 02:06:46  ID: Be:
    持ち込めば？
    結構のってくると思うよ。
    翻訳者探し大変だから。

325 デフォルトの名無しさん [sage] Date:2009/02/01(日) 02:09:16  ID: Be:
    翻訳の質が悪いと書き直しとかあるかもしれないけど
    More Effective C++ を見るとそうでもないのかもしれない・・・ 

326 デフォルトの名無しさん [sage] Date:2009/02/01(日) 02:13:56  ID: Be:
    いわばRubyの解説をまつもとさんが書いたような本が
    ずらりと並んでるからね洋書は。
    和書がそれらに対して質で劣るのはしょうがない。 

327 デフォルトの名無しさん [sage] Date:2009/02/01(日) 02:16:13  ID: Be:
    >>322
    持ち込まなくてもブログで発信してれば
    出版社のほうから食いついてくるよ。 

328 デフォルトの名無しさん [sage] Date:2009/02/01(日) 02:20:02  ID: Be:
    何を発信するんだよｗ
    見せられませんが～を翻訳しました！って報告するのか？ 

329 デフォルトの名無しさん [sage] Date:2009/02/01(日) 02:22:01  ID: Be:
    とりあえず周りと相談してどこかに持ち込んでみるわ
    訳の内容はMore Effective C++とかよりはマシなつもりなんだぜ…
    C++ in Depth Seriesの未訳なのが一冊まるごとあるからとりあえずこれ持ち込んでみるね 

330 デフォルトの名無しさん [sage] Date:2009/02/01(日) 02:29:37  ID: Be:
    Depthなら、ピエソンエデュケーション一択じゃん。
    出てないのはGraph, Network, Applied, Boost, Common Knowledgeくらい? 

331 デフォルトの名無しさん [sage] Date:2009/02/01(日) 03:14:04  ID: Be:
    >>329
    それなら、SiB Accessがいいかも知れない。

    ただ、C++の本は、最近、ほんとに売れないので出版社、嫌がるんだよな…。 

332 デフォルトの名無しさん [sage] Date:2009/02/01(日) 04:10:18  ID: Be:
    C++は改定される日も近いからな。0xはいつだろう。
    駆け込みでMore Exceptionalとboostは翻訳されたっぽい。 

334 デフォルトの名無しさん [sage] Date:2009/02/01(日) 04:24:41  ID: Be:
    C++は時々C++のことをまったく分かってないやつが翻訳したりするからな

    そなの? ＞出版社が嫌がる C++とCはまあ違うんだろうけど、Cの入門書が(入門書ってとこもポイントなんだろうけど) 途切れることなく手を変え品を変え出てるってのにねえ。

    一つ前へ 2009年1月(下旬)
    一つ後へ 2009年2月(中旬)

    ホームへ

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

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