ときどきの雑記帖 再起編

■_

行ってしまった一月

積読の山を眺めつつ、どうしたものかと。

■_

たぶんついったー経由で知った、Emacs の正規表現に対するパッチ。 先読みやら戻り読みを追加するもの。

Index: src/regex.c
===================================================================
RCS file: /sources/emacs/emacs/src/regex.c,v
retrieving revision 1.236
diff -u -r1.236 regex.c
--- src/regex.c	8 Jan 2009 03:15:54 -0000	1.236
+++ src/regex.c	3 Jun 2009 22:35:17 -0000
@@ -735,7 +735,14 @@
   syntaxspec,
 
 	/* Matches any character whose syntax is not that specified.  */
-  notsyntaxspec
+  notsyntaxspec,
+
+  lookahead,
+  lookahead_not,
+  lookbehind,
+  lookbehind_not,
+  lookaround_succeed,
+  lookaround_fail
 
(略)
@@ -3389,13 +3482,40 @@
 		/* If we've reached MAX_REGNUM groups, then this open
 		   won't actually generate any code, so we'll have to
 		   clear pending_exact explicitly.  */
+                lookaround = COMPILE_STACK_TOP.lookaround;
 		pending_exact = 0;
 
 		/* We're at the end of the group, so now we know how many
 		   groups were inside this one.  */
 		if (regnum <= MAX_REGNUM && regnum > 0)
 		  BUF_PUSH_2 (stop_memory, regnum);
-	      }
+                else if (lookaround)
+                  {
+                    if (lookaround > 0)
+                      {
+                        /* Positive/negative lookahead assertion.  */
+                        GET_BUFFER_SPACE (3);
+                        INSERT_JUMP (lookaround == 1 ? lookahead : lookahead_not, laststart, b + 4);
+                        b += 3;
+                      }
+                    else
+                      {
+                        /* Positive/negative lookbehind assertion.  */
+                        int count = exact_chars_in_pattern_buffer (bufp, laststart, b);
+                        if (count == -1) /* variable length */
+                          FREE_STACK_RETURN (REG_BADPAT);
+
+                        GET_BUFFER_SPACE (5);
+                        INSERT_JUMP2 (lookaround == -1 ? lookbehind : lookbehind_not, laststart, b + 6, count);
+                        b += 5;
+                      }
+                    
+                    /* Negative form.  */
+                    if (lookaround > 1 || lookaround < -1)
+                      BUF_PUSH (lookaround_fail);
+                    BUF_PUSH (lookaround_succeed);
+                  }
+              }
 	      break;
 
(略) 

glibc のものを使っているのかと思ったけどどうもそれとは違う感じがするし、 それでいて見覚えがあるような雰囲気。 ということで、regex.c といういかにもなファイルをみてみると

/* Extended regular expression matching and search library, version
   0.12.  (Implements POSIX draft P1003.2/D11.2, except for some of the
   internationalization features.)

   Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
                 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
                 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3, or (at your option)
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
   USA.  */

/* TODO:
   - structure the opcode space into opcode+flag.
   - merge with glibc's regex.[ch].
   - replace (succeed_n + jump_n + set_number_at) with something that doesn't
     need to modify the compiled regexp so that re_match can be reentrant.
   - get rid of on_failure_jump_smart by doing the optimization in re_comp
     rather than at run-time, so that re_match can be reentrant.
*/

ああ、やっぱり以前のやつだ。＞ 0.12 merge with glibc's regex.[ch] なんてのも

しかし、これって Ruby では戻り読みをサポートできないってことになって それで鬼車が作られたという流れがあったような。 このパッチはどういうロジックになっているんだろう? ざっとは見たけど把握できたかあまり自信がない…

■_ アイスコーヒー

IcedCoffeeScript

IcedCoffeeScript

Welcome to IcedCoffeeScript!

IcedCoffeeScript is a fork of CoffeeScript. It is superset of the CoffeeScript language.
The iced interpreter is a drop-in replacement for the standard coffee interpreter since
it will interpret all existing CoffeeScript programs.

IcedCoffeeScript (ICS) adds two new keywords: await and defer. These additions simply and
powerfully streamline asynchronous control flow, both on the server and on the browser.
Say goodbye to callback pyramids; say adios to massive code rewrites when synchronization
requirements change slightly. Say hello to clean, readable, maintainable control flow for
network and asynchronous operations! See the Iced Features tab for more details.

The golden rule of CoffeeScript was: "It's just JavaScript". ICS is doing 
something deeper. It's selectively running code through a continuation-passing style 
conversion. Original-style CoffeeScript will compile as before, but code using the new 
ICS features will be less recognizable. Still, the compiled output is readable and 
pretty-printed, passes through JavaScript Lint without warnings, will work in every 
JavaScript implementation, and tends to run as fast or faster than the equivalent 
handwritten JavaScript.

Latest Version: 1.2.0j

ICS is doing something deeper と。

■_

• 貸会議室とZusaarで安心して勉強会を開催 #zusaar #twtr_hack - 侍ズム
• 3月5日開催：SEA Forum March 2012：実用期を迎えた関数プログラミング-SEA HomePage
• BASE of UGSF-WEST
  アーケードゲーム博物館計画より緊急のお知らせです！！
• 書物を手に取る喜びと、地方都市の未来（第193回）：青木恵美「信州発 ITライターの憂鬱」
• Rust のインターフェース - uasi:ウアシー

■_

買った

Moonlight Mile は最初の頃を考えるとえらい違いが。

■_ Lisp 1.5

modern OS で動く Lisp 1.5 求む。

Is a Lisp 1.5 available for modern OSs? : lisp

I'm wondering if Lisp 1.5 is available on a modern Linux system

This lisp is based on 1.5 IIRC: http://www.aviduratas.de/lisp/prolisp.html

http://www.softwarepreservation.org/projects/LISP/lisp1.5 has various resources. One approach
might be to figure out the simulated environment Paul McJones used to create lisp.lst and run
it there. (It looks like he was able to get a clean assembly run on the sources of the IBM
704/709 version. (Or on one of the other architectures it was ported to.)

What is your real goal? Run a historic piece of Lisp code? Find out how Lisp hackers lived in
the 1960s?

It is hard to separate the language from the environment. You really want character 
I/O to be done in the style of punched cards? With a 48-character character set? You 
want to interact with a 1960s mainframe job control system?

More fundamentally, Lisp 1.5 has the warts of dynamic scoping and FEXPRs that were 
discovered to be bogus in the same process that led to Scheme. Common Lisp borrowed 
the real advances made in lexical scoping (while not making other choices that the 
Scheme community did.)

Dynamic scoping is certainly a wart, although it was good enough for the first generation,
and although elisp got by with it for another generation.

But FEXPRs are not; it just simplifies the world to have only just QUOTE.

As for 48-character, my memory is fuzzy about the 704, so I'll take your word for it, 
but certainly there were plenty of 1.5s on 18- and 36-bit machines, where the 
character width was a choice of either 7 or 9 bits.

I also seem to recall that interactive LISP was more the rule than the exception, even 
prior to the advent of timeshare systems (in which Lisp and McCarthy played a part, 
although that's a different topic).

1.5 did on the other hand have a variety of data structures beyond sexprs, despite the 
common misunderstanding to the contrary. (I'm sure you know that; I'm just saying.)

Interesting topic, actually. I meant to do a 1.5 clone years ago (minus the most 
absurd of warts such job control) but of course never got around to it.

Well, that's sort of the Ur-lisp. I'm referring to Lisp 1.5.
http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf

■_ for

なんで Ruby に for 文があるの? という疑問。

Why is there for-statement in Ruby? : ruby

Even I have just only few experiences of Ruby, I just become aware of there is for in Ruby
(I saw that when I learned Ruby first). Most of Ruby codes seem to use just Enumerable#each
method instead of for statement, but why? Is there any reason to prefer Enumerable#each
method over for statement?

for doesn't introduce a new scope. Consider this:

  foo = :bar

  [1, 2, 3, 4].each do |foo| # should be 4.times, but for the sake of example...
    puts foo
  end

  puts foo #=> :bar, not changed because Enumerable#each has a new scope

  for foo in [1, 2, 3, 4]
    puts foo
  end

  puts foo #=> 4, because `for` changes the variable

There are some specific use cases for for, but you'll almost always prefer 
Enumerable#each. One use case might be the following:

  for user in users
    break if user.valid?
  end

  # ... access user

But more idiomatic Ruby might be something like:

  user = users.select(&:valid?).first
  # ... access user

If there is I'd say it's negligible, in the use case above (selecting a valid user) 
there may be a performance improvement if the first valid user in a sufficiently large 
list isn't at the end, the code using for will stop as soon as it finds a valid user, 
whereas Enumerable#select will iterate over the entire collection regardless and then 
you have to pick the first item out of that set.

So there could be performance benefits from using for, but I only see it in fringe 
cases and if you get that much of a benefit from using for over the Enumerable methods 
then there might be better ways to handle things elsewhere in your code (not always 
though).

EDIT: Actually, as threedaymonk posted in another comment, you could use 
Enumerable#detect to select and stop at the first result, this should have the same 
performance as the for statement (minus the extra call to convert the symbol to a proc).

I don't use for, because of the following reasons:

    for loops doesn't introduce a new scope, as nilved explained

    for loops just delegate to each anyway

    using each makes my code look more consistent: it's blocks everywhere, it doesn't matter if it loops or not.

    you cannot use for loops functionally, like passing lambdas: users.each(&:save)

    you're tempted to miss the other enumerable methods when using for, like select, reject,
    find, map, all?, any?, and dozens more that you really should learn, use and love.

I've been working with Ruby for 2 years, and for loops are very rare.

I grepped through the Rails codebase, and found that there's only 28 for loops, versus 1163 uses of .each.

EDIT: I would say that for loops are more readable when dealing with ranges. Consider the following:

  (1...developers.size).each do |i|
  (3..10).each do |digit|

or

  for i in 1...developers.size
  for digit in 3..10

I often use the for-loop. Here's why:

1) Iteration is such a primitive operation that I think it's more intention-revealing to use
   the syntax designed specifically for it.

2) It's easier to type and easier to read.

3) The difference in the scope of variables in the two constructs should not be an issue in
   any well-written program. It's of academic interest only. If it trips you up, you're not
   doing it right.

4) Ryan Bates uses the for-loop.

これもバイク小屋の議論の類ですかね

■_ awkの挙動

Twitter / @hi_saito: いやいや、awk で FS を ¥t にすれば大丈夫 ... ということで

bash の read に関するイマイチな仕様 - ritchiekotzenの日記

2012-01-30 bash の read に関するイマイチな仕様

■bash の read で空文字のカラムがある場合、そのカラムの存在は無視され、右から詰められてしまう。
例えば、

while read col1 col2 col3
・・・

のようなスクリプトが標準入力から

hoge\t\tfuga

のようなレコードを受け取った場合、
　col1="hoge", col2="", col3="fuga"
ではなく、
　col1="hoge", col2="fuga", col3=""
となってしまう。

awkやsortコマンドでも同じような挙動をしてしまうらしい。
cut コマンドはちゃんと空白文字でもカラムとして認識してくれるみたい。
対処としては、perl等で処理するしかなさそう・・・

NULLが入る可能性のあるカラムを処理で使用しないのなら、cut コマンドでそういったカラムを除いてから処理するというのも手。

■デフォルトの区切り文字はタブとスペース

いつもタブ区切りファイルをインプットに使うので忘れいていたが、実はスペースも区切り文字として扱われる。
よって、文字列の中にスペースがあると、別々なカラムとして認識されてしまう。
IFS=" " <- ctl+v,tab でタブ文字を入力
としておけば、タブだけを区切り文字として扱ってくれる。

whitespace の連なりを一つの区切りと見るのでそうなるわけですが、 これって割とよく見られる既定の動作だと思うけどなあ。 わざわざ cut で前処理しなくても、さいとうさんがツイートしていたように FS に設定してやればOK。

Man page of GAWK

フィールド

入力レコードを読み込むごとに、 gawk はそのレコードを フィールド に分割しま す。分割す
る際には、変数 FS の値がフィールドセパレータとして参照されます。 FS の値が1文字なら、
その 文字を境にフィールドが分割されます。 FS が空文字列の場合、個々の文字がフィールド
セパレータとなります。 いずれでもない場合、 FS は完全な正規表現である と解釈されます。
特殊な場合として FS が単一の空白のときには、フィールドは 連続した空白・タブ・改行によ
り分割されます。

このような規定値が設定されているものは他にもあって たとえばperlのsplit

split 【perldoc.jp】

split /PATTERN/,EXPR,LIMIT
split /PATTERN/,EXPR
split /PATTERN/
split

    文字列 EXPR を文字列のリストに分割して、リストを返します。 デフォルトでは、行頭の空白は
    保存され、末尾の空白は削除されます。 (全てのフィールドが空の場合、これらは末尾であると
    して扱われます。)

    スカラコンテキストでは、見つかったフィールドの数を返します。

    EXPR を省略すると、文字列 $_ を split します。 もし、PATTERN も省略すると、 (先頭の空白
    文字をスキップした後) 空白で split します。 PATTERN にマッチするものは、フィールドを分割
    するデリミタとして扱われます。 (デリミタは、1 文字とは限りません。)

(略)

    特別な場合として、PATTERN にスペース (' ') を指定すると、 引数なしの split のように空白で
    split を行ないます。 つまり、split(' ') は awk のデフォルトの動作をエミュレートするために
    使うことができ、split(/ /) は行頭のスペースの数に応じた空フィールド (空文字列)ができます。
    split /\s+/ は split(' ') と同様ですが、 先頭の空白は先頭の空フィールドとなります。 引数な
    しの split は内部的には split(' ', $_) を実行します。

gawk で -F'\t' とやったときにタブがFSに設定されるのは GNU 拡張だったりするのだけど GNU のであれば他のツールも大抵こうなってんじゃなかろうか。

■_

で、タイミング良くこういう記事が

Know split’s special cases | The Effective Perler

Effective Perl Programming – write better, more idiomatic Perl

Know split's special cases

Posted by brian d foy on November 27, 2011

Perl's split has some special cases and some perhaps surprising cases. The empty pattern,
zero width match, the special argument ' ', and the /^/ act differently than you might
expect from the general rule.

Perl の split にはいくつかの特別なケースと、いくつかの驚きをもたらすであろう
ケースがあります。空のパターン、zero width なマッチ、特別な引数 ' '、
さらに /^ / といったものの振る舞いはあなたが一般的なルールから類推するものとは
異なるものでしょう。

The empty pattern, //

The empty pattern is a special case that's designed to give you a list of characters. 
This pattern specifically has nothing in it and is different than a pattern that 
matches an empty string (that's next). For this, split returns a list of characters:

空のパターンは文字のリストを得るために設計された特別なケースです。

そして空文字列(次の項目です)にマッチするパターンとは異なるものです。
このパターンでは split は文字のリストを返します:

	use utf8;
	 
	use Data::Printer;
	my @characters = split //, 'Büster';
	 
	p( @characters );

The output shows a list of characters:

	[
	    [0] "B",
	    [1] "ü",
	    [2] "s",
	    [3] "t",
	    [4] "e",
	    [5] "r"
	]

This is specifically characters, not grapheme clusters. Depending on the normalization 
of your source code or input, you can get different results:
	use utf8;
	 
	use Data::Printer;
	use Unicode::Normalize qw(NFD);
	 
	my @characters = split //, NFD( 'Büster' );
	 
	p( @characters );

以下略

■_

• Amazon.co.jp： Code Simplicity: The Science of Software Design: Max Kanat-alexander: 洋書
• Software Engineerにお勧めの技術書 - dann@webdev - dann's portal
• [Python-Dev] A new dictionary implementation
• 真・自然言語プログラミングの"the"演算子をClojureで - athosの日記
• Modegramming Style: Scala Tips / Option (3)
• コミックマーケット82 で Scala の記事を書きたい/書いてみたい人 - [PARTAKE]
• 強いリーダーを求めるよりもチームビルディングを志向する先に成功がある - Future Insight
• 技術/組織としてどうスケールするか at GitHub - yaotti's diary
• 「電脳書房技術書バー」＆鎌倉散歩など | スープかガソリンがなくなり次第閉店
• 電脳書房 blog :: 技術書BAR
• 【連載】技術者たちの挑戦 - ARM+Linux組込プラットフォーム「Armadillo」誕生秘話 (1) 技術者たちの挑戦 - ARM+Linux組込プラットフォーム「Armadillo」誕生秘話 | エンタープライズ | マイナビニュース
• 「失敗との付き合い方」をオシム氏に聞く - 記者の眼：ITpro
• 3月5日開催：SEA Forum March 2012：実用期を迎えた関数プログラミング-SEA HomePage

• Twitter / @methane: Python-dev に投稿されていた new di ...
• Twitter / @methane: で、値はまた別に管理している。これで、複数の辞書が同 ...
• Twitter / @methane: ある型のインスタンスを作るとき、__slots__が ...
• Twitter / @methane: 今までのハッシュテーブルは、特に64bit環境ではメ ...
• Twitter / @methane: 似たようなインスタンスをたくさん使うときに、ハッシュ ...
• Twitter / @methane: RailsはActiveRecordの作る大量のオブ ...
• Twitter / @methane: 非常に生存時間が短いオブジェクトを大量にくりかえし作 ...

■_

読み終わった
Clean Coder プロフェッショナルプログラマへの道 さっくり読了。原著で読むスピードもっと上げないとなあ。 感想やら書評やらは他にいろいろ書く人がいるでしょうからパスw。 とはいえコノ職業の人であれば大抵の人は読んでおいていい本じゃないでしょうか。

んで、

という本がありまして。

とどういう関係があるのかと思って買ってざっと見てみると、 後者がCで書かれているのに対して、 前者(今回出たほう)はC++を使っているというのが一番の違いのようです。 でまあ後者には「コンパイラー」ってのもありますが この辺はソースコードを変換したものがファイルとして残るか残らないか といった違いでしょう。 「コンパイラー」のほうは実行するためには別のプログラムでそれを解釈させてましたし (ネイティブコードを吐くものではなかった)。

Javaセキュアコーディングスタンダード CERT/ Oracle版
Fred Long Dhruv Mohindra Robert C. Seacord Dean F. Sutherland David Svoboda 歌代和正

も買おうかどうしようか悩んだのだけど大型本縛りに負けて(個人的事情ですが)、 ペンディング的スルー。 あんまり Java いぢらないしね。

■_

ちょっと前に、こういう話題が掘り返されているのをいつものところ (Hacker NewsとかStackOverflowとかreditとか)で見かけまして Good Ideas, Through the Looking Glass | Lambda the Ultimate

5.5. Using wrong tools

Using the wrong tools is obviously an intrinsically bad idea. The trouble is that often
one discovers a tool's inadequacy only after having invested a substantial amount of
effort to 24 build and understand it, and the tool thus having become “valuable”.
This happened to the author and his team when implementing the first Pascal compiler
in 1969. 

The tools available for writing programs were an assembler, a Fortran and an Algol compiler.
The latter was so poorly implemented that we did not dare rely on it, and work with
assembler code was considered dishonorable. There remained only Fortran.  

Hence our naïve plans were to construct a compiler for a substantial subset of Pascal
using Fortran, and when completed, to translate it into Pascal. Afterwards, the classical
bootstrapping technique would be employed to complete, refine, and improve the compiler. 

(略)

-- From N. Wirth - Good Ideas, Through the Looking Glass, 2005

なんとヴィルト先生の論文(エッセイ?)だったと。 上記のリンク先にあるのは本の一部分らしく、 いろいろ探してみるとまずは感想を書いているものがいくつか。

最近の話題 2006年2月4日

３．Niklaus Wirth先生のGood Ideas, through the Looking Glass

  IEEE Computer誌の2006年1月号にPascalやModulaなどで有名なNiklaus Wirth先生がGood Ideas,
through the Looking Glassと題する文章を書いておられます。題名はGood Ideasですが，中身は
Bad Ideasのリストに近く，過去のBad Ideaの失敗に学ぼうという書き方です。

(略)

Good Ideas through the Looking Glass - $ cd ./.

2006-03-15
Good Ideas through the Looking Glass

IEEE Computer Jan / 2006 の記事。

http://doi.ieeecomputersociety.org/10.1109/MC.2006.20

過去を振り返ってその時点ではよかったアイデアをけなす、というコラム。いろいろ槍玉にあが
っているのだけど、かなり首をかしげるところもあった。まあ、このコラム自体が軽いネタみた
いなものなので、マジレスもよくないのだが、そういうことは考えずに全力で攻撃。

(略)

どうにかして全文読めないものかとさらに探してみたところ、 pdf になっているものを発見。 ということでこれから読みます。

2000 年頃に引退されたとか聞いたけどこのごろはどうされているんだろう＞センセ

■_

海外記事紹介シリーズ(嘘

Jay Fields' Thoughts: Lessons Learned while Introducing a New Programming Language

Tuesday, January 24, 2012

Lessons Learned while Introducing a New Programming Language

I've used a lot of languages (professionally) over the years: (off the top of my head) 
Cold Fusion, HTML, Javascript, php, SQL, CSS, ASP(classic & .net), C#, Ruby, Flex, 
Java, & Clojure. Each language has pros and cons. Being a programmer, it's easiest 
to discuss the cons - and in general I believe it was best said:

    I hate all programming languages - Matt Foemmel

I think it's important to start with this in mind. At some point you're going to hate 
what you're advocating, so imagine how other people feel about it.

In 2008 I introduced Clojure into a DRW codebase. This blog entry focuses on the 
adoption lessons I've learned in the past few years.

■_

今月の Rakudo

This month's Rakudo Star release – and what's coming next | 6guts

(略)

Here's some of the things I'm happiest about in the release.

    The performance improvements in many areas. Yes, we've plenty of work to do here – but
    this is a solid step forward for a wide range of scripts, and in some cases an order
    of magnitude improvement.

    That 6model – something I started designing a year and a half ago – has not only
    cleanly supported all of the things we needed to do in Rakudo, but also opened up so 
    many other doors. For example, the new NativeCall module uses its representation 
    polymorphism support to great effect.

    Protoregexes doing real NFA-driven Longest Token Matching rather than the cheating 
    version we had before that only operated on literals.

    The optimizer, along with the various extra compile time error reporting it gives. 
    This will be an important future area for Rakudo.

    Initial native type support, and bigint semantics for the Int type.

    The POD6 support, thanks to tadzik++'s Google Summer of Code grant in summer.

So, what's next? Currently I'm working hard on getting true bounded serialization support in place.
(略)

そろそろバイナリパッケージの新しいのも出る時期?

■_ Rakudo Star 2012.01 released

これか

Rakudo Star 2012.01 released | rakudo.org
Rakudo Star 2012.01 released
Posted on 2012.01.28 by jnthn	

On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the January
2012 release of “Rakudo Star”, a useful and usable distribution of Perl 6.  The tarball
for the January 2012 release is available from http://github.com/rakudo/star/downloads.

In the Perl 6 world, we make a distinction between the language (“Perl 6″) and specific
implementations of the language such as “Rakudo Perl”.  This Star release includes
release #48 of the Rakudo Perl 6 compiler [1], version 3.11 of the Parrot Virtual
Machine [2], and various modules, documentation, and other resources collected from the
Perl 6 community.

(略)

■_

• 全ての大学は職業教育の場です！ - None is None is None
• (1) 全てのページにcanonicalを！
• Common Lisp書籍ツイートまとめ - はてなまとめ（仮）
• 個性と常識の間：Google社内の様子とSONYの就活: 組み込み技術者の単身赴任日記
• 真夏のアスファルトで干からびるミミミズ。窒息しそうなほど溢れかえる窒素。あるいは、文明の寿命。『土の文明史』 - あおぎみれば、空
• ハーバードの確率の授業が凄い件 - what_a_dudeの日記
• Ruby Gold Programmer になりました - あーありがち(2012-01-28)
  Rubyインタプリタを自分の頭の中に作り上げられれば合格する
• 「木口古兵は死んでもラッパを離しませんでした」とは - BIGLOBEなんでも相談室
• Ideone.com | Online Ruby Interpreter & Debugging Tool
• Ideone.com | Online Ruby Interpreter & Debugging Tool
• 旧いダンプリストから - Togetter
  MSX-BASICのソースってのが本で出てたんですよ。2万円くらいで…。
  値段はさておき、そんなのあったんだ
• tse - Text Stream Editor in Python - atsuoishimotoの日記
• だれでもわかるそうです。 | OKWave
• 真・自然言語プログラミングの"the"演算子をClojureで - athosの日記
• [Python-Dev] A new dictionary implementation

■_

・電脳書房技術書BAR : ATND
行ってきました。

高橋会長とは入れ違いでした。 他の参加者と話もしたかったんですが、 バーのカウンターでしたんで離れた席の人には話しかけづらいしといって席を立って近寄るというのも…w 隣の人はちと話しかけづらかったんだよな(^^; 満席な状態が続いてたので席空けなきゃなあと考えて 18時ちょっと前に退散しました。

日曜日(29日)もあるのでお近くの人は行ってみてはいかがでしょうか (なんとなく今日に集中しちゃったような気もする)。

・ベイスターズ
この辺の話を見聞きするとやっぱり上がどうしようもなかったという気になりますね (親会社が、じゃないよ?w) 【スギのみぞ知る】尾花前監督が初めて明かす“横浜の実像” - スポーツ - ZAKZAK 【スギのみぞ知る】尾花前監督が初めて明かす“横浜の実像” - スポーツ - ZAKZAK

んでまあ、ラミレスにしても全盛期は過ぎているしあれとかあれとかありますが、 ホエールズからベイスターズになったときの駒田のような効果があればいいなという気はします。 監督は…どうしたもんかw。 どうにかしようという意欲は買えるんですがどうも

■_ 23 or 24?

clean code 原著で読んだときに気がつかなかったのは読みが甘いということだよなあ と反省しつつ

Chapter I
Know Your Field

Here is a minimal list of the things that every software professional should be conversant with:

・Design patterns. You ought to be able to desribe all 24 patterns in the GOF book and
have a working knowledge of many of the patterns in the POSA books.

  

訳書でも同じで、「24個」のパターンとあるんですけど GoF のパターンって23個じゃなかったでしたっけ?

Design Patterns - Wikipedia, the free encyclopedia

Design Patterns: Elements of Reusable Object-Oriented Software is a software engineering
book describing recurring solutions to common problems in software design. The book's
authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword
by Grady Booch. The authors are often referred to as the Gang of Four, or GoF.[1] The
book is divided into two parts, with the first two chapters exploring the capabilities
and pitfalls of object-oriented programming, and the remaining chapters describing 23
classic software design patterns. The book includes examples in C++ and Smalltalk.

The original publication date of the book was October 21, 1994 with a 1995 copyright, 
and as of July 2010, the book was in its 38th printing. The book was first made 
available to the public at OOPSLA meeting held in Portland, Oregon, in October 1994. 
It has been highly influential to the field of software engineering and is regarded as 
an important source for object-oriented design theory and practice. More than 500,000 
copies have been sold in English and in 13 other languages.

とりあえず翻訳のほうでひとつ。 原文の

Acknowledgments

My career has been a series of collaborations and schemes.
Though I've had many private dreams and aspirations,
I always seemed to find someone to share them with.
In that sense I feel a bit like the Sith, "Always two there are."
  

この「Sith」を訳書ではシス卿としてたんですが、 卿はいるのかなあと思うのですけどどうなんでしょうか。 でも詳しい人がレビューに参加してただろうしなあ (わたしはSWには詳しくありません)。

Sith - Wookieepedia, the Star Wars Wiki Sith Lord - Wookieepedia, the Star Wars Wiki

■_ GNU

関数型プログラミング言語Haskell Part17

416 デフォルトの名無しさん [sage] 2012/01/27(金) 12:06:04.37 ID: Be:
    ここで問われているのは、
    長年GNUがやってきたように、
    過去の他人の成果を丸パクリして、
    それでも使われるレベルになるのかどうか？
    ということだよな 

んーむそういう見方が多いのかなあ。最近は。

■_

例の Emacs を Common Lisp で～の人の新しい記事。

The Cliffs of Inanity › Difficulties of elisp


Difficulties of elisp
Emacs Lisp の難しさ

The thesis that underlies my project to translate the Emacs C code to Common Lisp is that
Emacs Lisp is close enough to Common Lisp that the parts of the Emacs C code that implement
Lisp can be dropped in favor of the generally superior CL implementation.  This is
generally true, but there are a few difficult bits.

(以下略)

なんて一文が長いんだっw ＞最初の いくつ関係代名詞があるんだか

■_ \

Perl 6 の話。

WITCH hack / Perl 6

WITCH hack

Mnemonics

"backslash", "escape", "hack"

        used to "back out" of a syntax to a character's original meaning
        used to "hack" around, or "escape", special characters

When used inside a regular expression
正規表現中で使ったとき

\ in front of any character will change it from a metacharacter to a literal, or visa versa.
メタキャラクターをリテラルにしたりその逆をしたり

When used in a Signature
シグネチャーで使ったとき

\ before a name is a parcel binding.


Operators containing this character
バックスラッシュを含む演算子

Modifying a reduction operator such as [\+] (modification of [+]) creates a lazy feed of intermediary results..

[\+] のように (この場合は [+] の) reduction 演算子を修飾して
中間結果の lazy feed を作り出す

Other Uses

unary \ as a noun in front of an argument or arguments creates a Capture

\ in front of whitespace creates an unspace which is used to jam spaces in where they don't belong.

\o \c \x and \d used inside an interpolated string introduce literal characters

interpolate された文字列の内側にリテラルキャラクターを持ち込むのに使われる

[ ] の中の演算子に前置するとそういうことになるのかあ。 って散々作例で見てきたような?

■_ Why I love Ruby (Part 1)

とりあえず Part I

Why I love Ruby (Part 1)

Why I love Ruby (Part 1)

So, it occurred to me that so far, my posts (both of them) have been pretty negative. So
I thought today, instead of ranting about something I detest, I'd rave about something I
love. And that something is Ruby. I looooove Ruby. I got into Ruby because of the Rails
web application framework, but my love of Ruby goes so far beyond Rails. Let's start
with a quote from Yukihiro Matsumoto (Matz), the creator of Ruby:

■_ Why I love Common Lisp and hate Java

こっちは hate つき

Why I love Common Lisp and hate Java « Piece of mine

(略)

People say Common Lisp is difficult to learn, but I had more trouble learning Java. My 
first few spoons of Java were to memorize “public static void main(String args[])”, 
before I could start playing with some code. Oh and I forgot, you have to declare your 
class first. What is a class, and why so many lines, just to produce a simple “Hello 
World”? Programming sucks!

皆は Common Lisp が学ぶのには難しいものだと主張しますが、わたしは Java を学んだときに
もっとひどい目にあいました。わたしの first few spoons of Java は、
ちょっとしたコードでもって遊べるようになるよりも前に
“public static void main(String args[])” を覚えることでした。
おっと忘れていました。
最初にクラスを宣言しなければなりませんでした。
クラスとはいったいどういったものであり、
単に “Hello World”とするだけのためになぜあんなにたくさんの行があるのでしょうか。
Programming sucks!

■_ 七つのルール

ちょっと前の記事ですが

7 Rules for Writing Clojure Programs « Two Guys Arguing

#1 – Your brain will think in steps. It can't help it

#2 – loop/recur is not a code smell, but be suspicious of it

#3 – Transformations of lists, not recursion is key
     再帰ではなくリストの変形がカギ

#4 – Don't be lazy
     lazy であってはいけない

#5 – One liners are hard to read
     一行野郎は読むのが難しい

#6 – Use -> and ->> to make one liners easier to read
     一行野郎を読みやすくするために -> や ->> を使おう

#7 – Don't use -> or ->>
      -> も ->> も使ってはいけない

本文は見てのお楽しみ。

■_

R をどうこうというときに名前の挙がる Numpy。

PyPy Status Blog: Py3k and Numpy First Stage: Thanks to all who Gave

Last year was quite successful for PyPy fundraising through the Software Freedom 
Conservancy, and Conservancy and PyPy are very excited to announce that enough was 
raised to begin the first stages on the Py3k and Numpy grant proposals.

As of the end of 2011, 135 different individuals gave to the Py3k campaign, and 114 to 
the Numpy campaign. We thank each of you who donated to help make this work possible. 
Meanwhile, if you haven't given to support these projects, we do hope you'll give 
generously now to help fund their second stages later this year!

■_ New implementation of Python regex

わたしは現状のも結構好きなんですが(速度的にはちと難があるみたいだからそれが動機?)、 置き換えを狙ったものが

mrab-regex-hg - New implementation of Python regex - Google Project Hosting

A new regex implementation intended eventually to replace Python's current re module implementation.

For testing and comparison with the current 're' module, the new implementation is in the
form of a module called 'regex'.

Also included are the compiled binary .pyd files for Python 2.5-2.7 and Python 3.1-3.2 on 32-bit Windows. 

■_

• ML名古屋 - [PARTAKE]
• Electric Magic | Portfolio | Smalltalk in Byte Magazine, August 1981
• 2012-01-28 - きしだのはてな ネットワークに自信のない人は東大講義の情報工学概論Ａを見よう
• この黒くて巨大な物体がまさか、4キロバイトのメモリーとは...！ : ギズモード・ジャパン
• OSに付属するシェルスクリプトを読んで技術を盗む（1/2） － ＠IT
• Colorful Pieces of Game::ハドソンがファミコンに参入するまで（２）
• 「割込み」の名付け親 - Plan9日記
• Innovation “D”: 「呪いの時代」のIT技術者
• Enhancements to /GS in Visual Studio 11 - The Security Development Lifecycle - Site Home - MSDN Blogs
• A Decades-Old Technique to Improve Programming Languages - Modern Perl Books for modern Perl programming
• DVCSもBTSも知らない人達とScrumをやってみた。 - うさぎ組
• 【コラム】『MSDN』の歩き方 (67) 検索に頼らないセミナー情報の集め方 | エンタープライズ | マイナビニュース

■_

の翻訳本が出た。ということで(また読んでる途中で出てしまった)。 Clean Coder プロフェッショナルプログラマへの道(Robert C. Martin/角征典) - capsctrldays(2012-01-27)

似たようなタイトルのこういう本もありましたね

折角なので、わりとオススメな洋書タイトルを。 全部読みきってはいないんですけどねw この辺が翻訳されることはまあないだろうなあ(と踏んでいる)。

今日はこういう本も買っていたり。 1980年代あたりのデザインっていいよなあ(と懐古的なことを)

■_ InfoQ

面白そうなのが右カラムｗにいろいろ。 こっちの記事はあまり訳されないんだよねえ。 ビデオだったりするともう InfoQ: The Future of F#: Type Providers InfoQ: Understanding the Magic of Lean Product Development InfoQ: How to Change the World InfoQ: Event-Driven Programming in Clojure

んでこいつ InfoQ: New Book: Agile Software Engineering with Visual Studio

InfoQ: New Book: Agile Software Engineering with Visual Studio

New Book: Agile Software Engineering with Visual Studio

Posted by Roopesh Shenoy on Jan 26, 2012

In today's hyper-competitive world, later may be too late to adopt Agile development and this
Roadmap for Success will help you get started. Download "Agile Development: A Manager's
Roadmap for Success" now!

InfoQ got in touch with Sam and Neno to explore the topics covered in the new book and 
discuss more about VS-TFS in general.

InfoQ: Agile normally focusses on minimal toolset (like spreadsheets) so that they don't
       spend a lot of time struggling with the tools, whereas Visual Studio + TFS is an 
       end-to-end application lifecycle management system. Why do you think it's still a
       good fit for agile teams?

Sam Guckenheimer: Let me start with the specific question, and then answer more broadly.
       Excel is a spreadsheet, of course, and is also a primary client to Team Foundation
       Server exactly so that Agile teams can use the most familiar tools and gain the
       benefit of history, scale, and the full lifecycle that TFS and the rest of Visual 
       Studio provide.

(略)

そのほかの質問

InfoQ: Do Agile efforts with really large software development projects benefit from better tooling?

InfoQ: Would you recommend VSTS for relatively small co-located agile teams?

InfoQ: You've touched upon this issue of getting the definition of "done" right and
       the corresponding risk of technical debt. Could you elaborate further?

InfoQ: About source control, TFS still does not have features that a lot of DVCSs have. This
       includes the pain of working offline. Do you think there are any improvements coming
       on this front in the future?

InfoQ: The VS-TFS tool-chain is highly customizable, yet with so many options it could be
       overwhelming to choose anything other than the defaults. When would you recommend a 
       team to start customizing things like the process template?

InfoQ: Automated Scenario/Load testing often needs high upfront investment, and requires a
       lot of maintenance whenever there are minor changes in the behavior. From your
       experience, are there any yardsticks that can help determine when it makes sense 
       to go for it?

InfoQ - Scrum puts an extra emphasis on "potentially shippable" software at the
        end of every sprint. But with large development efforts especially with dependencies
        across several projects/products, is it actually feasible to do so?

InfoQ - You have mentioned how VS can create an initial set of unit tests with high coverage
        with help of Pex. How exactly does it work?

InfoQ - VS 2008 shipped with several SKUs including different ones for different roles like
        Test, Architect, etc. All that changed with VS 2010 which has only 3 SKUs -
        Professional, Premium and Ultimate. Does this have anything to do with the Scrum 
        recommendation of everyone doing a bit of everything?

InfoQ - Intellitrace/Historical debugging is a pretty useful feature for developers in 
        almost any project size; however it is present only in the Ultimate Edition of Visual 
        Studio which is targeted towards larger project sizes. Any particular reason for this?

InfoQ - One interesting feature in VS vNext is managing stakeholder feedback. Could you
        elaborate a bit more?

InfoQ: We have seen early previews of TFS cloud coming out, something that you have covered
       briefly in your book. Are there any major changes expected with this move to the cloud?

InfoQ: You took us through some of the problems Microsoft itself faced prior to the VS 2005
       release and the seven changes that helped turned it around. How important was the 
       tooling itself vis-a-vis an organizational push towards better practices?

InfoQ: And then you explained how temporary amnesia can set in after a success that could be
       quite disruptive; something that is quite common when individuals change jobs after a
       major milestone. Any practices you have put in place to avoid that in the future?

■_

• 泳ぐやる夫シアター やらない夫は大砲鳥に乗るようです　最終回
• 中里一日記: Array Considered Harmful あるいは、なぜC言語のポインタは難しいのか
• Android アプリに LGPL ライブラリを組み込むとソースコード開示義務が発生するらしい: あるＳＥのつぶやき
• LGPLとAndroid - 近況
• LGPLとAndroid その２ - 近況
• Comparing JavaScript, CoffeeScript & ClojureScript - dosync
• Real world F#: my experience (part one) | Index Out Of Range
• Real world F#: my experience (part two) | Index Out Of Range
• Hello, Kotlin! « Tapestry 5 Blog - Thoughts on coding, technology and occasional stuff.
• Scalaのfor文を掘ってみる - セカイノカタチ::Techlog
• Big Sky :: 新言語rustでhello world
• プログラミング言語 Rust - M59の記録
• パラメトロン計算機: 除算サブルーチン ところで, PC-1がお手本にした, Cambridge大学のEDSACには, 最後まで除算はなく, サブルーチンを使っていた.
• セマンティックウェブ・ダイアリー : 末尾再帰，継続，アクタ，コルーチン
• プログラミング言語 Rust [chaika]
• Amazon.co.jp： データによるプログラミング―データ解析言語Sにおける新しいプログラミング: John M. Chambers, 垂水 共之, 水田 正弘, 山本 義郎, 越智 義道, 森 裕一: 本
• SQL緊急救命室：第4回　スーパーソルジャー病～すべての問題をやみくもにコーディングで解くべからず｜gihyo.jp … 技術評論社
• Twitter / @SKYH_O_RSE_2: 「地上のエディタ」歌：中島miゆき 風の中のメモ帳　 ...
• Twitter / @SKYH_O_RSE_2: 名立たる言語を追って　使いやすさを追って　人はIDE ...
• だいありー ■他の言語になれた人がRubyに躓く n のポイント Ruby はちょっと特殊なプログラミング言語なので，他の言語になれた人は，ちょっと戸惑うかもしれません．そんな躓きそうなポイントを紹介していきます．
• レポート：マイクロソフトのテスト環境はどう進化したか？－ソフトウェアテストシンポジウム 2012基調講演レポート｜gihyo.jp … 技術評論社
• 標本分散の計算方法による速度差と誤差について - 睡眠不足？！
• 101回死んだエンジニア: 技術にこだわりすぎて見えなかったもの
• 音楽コンテンツの値段：IT's my business：ITmedia オルタナティブ・ブログ
• (1) 120128tokyor

■_

■_

BSプレミアムでやっていた「へうげもの」のアニメも最終回。 モーニング連載の原作も関ヶ原と。

関ヶ原の合戦といえば小早川秀秋の陣取った松尾山ですが、 どうもここに大規模な陣地(陣城)が構築されてたらしいですね。 一説ではかなり本格的な「城」であって、東軍に対する防衛拠点にするつもりのものだったとかなんとか。 そして石田三成自身がそこに入るつもりだったのに小早川秀秋が先に入ってしまって しかたなく三成はあの奥まった場所に陣をはったと

一時間かあ、 Eventer

Escape From the Ivory Tower: The Haskell Journey, From 1990 to 2011

    Simon Peyton Jones
    01:03:51

Thursday December 01, 2011

Haskell is my first baby, born slightly before my son Michael, who is now at university.
From somewhat academic beginnings as a remorselessly pure functional programming language,
Haskell has evolved into a practical tool used for real applications and, amazingly, is
still in a state of furious innovation.

    Simon Peyton Jones, MA, MBCS, CEng, graduated from Trinity College Cambridge in 1980.
    After two years in industry, he spent seven years as a lecturer at University College
    London, and nine years as a professor at Glasgow University, bef… Show more.

Like this way of watching talks? Please tell us what you thought.

  

ちとお高めだのう… パナソニック、「Let'snote」直販向け春モデルにも「SX1」「NX1」が登場 | パソコン | マイナビニュース 「SX1」のハイパフォーマンスモデルは、基本構成価格が187,950円。 「SX1」のプレミアムエディションは、基本構成価格が238,500円。

■_

The Cliffs of Inanity › Emacs and Common Lisp の続きが

The Cliffs of Inanity › Emacs and Common Lisp, Part 2

Emacs and Common Lisp, Part 2

This is a followup to my earlier post on converting the Emacs C code into Common Lisp. This
one is a bit more technical, diving into some specifics of the conversion process.

この記事は、以前ポストした Emacs の C コードを Common Lisp に変換することについてのフォローアップです。
今回は少々テクニカルな内容で、変換プロセスの some specifics に入っていきます。

Basics
基本

One important fact is that we do not need to convert an arbitrary C program to Common 
Lisp.  This might or might not be efficiently possible — but we do not care.  We only 
need to convert Emacs.  This is simpler for two reasons.  First, we can just ignore 
any C construct that Emacs does not use.  If the translator barfs after some new 
update, we can fix it then.  Second, Emacs itself is already written in a relatively 
Lispy style, being a Lisp implementation itself.  We further exploit this by allowing 
the translator to know some details about Emacs.  As a trivial example, all the 
Smumble globals created by the DEFUN marco need not be translated into Common Lisp as 
structure constants — they are an artifact of the implementation, and will show up 
directly in the generated defuns instead.

ひとつ重要なことは、はわたしたちには任意のCプログラムをCommon Lispに変換する必要はない
のだということです。
This might or might not be efficiently possible －
しかし考慮はしません。わたしたちにとっては Emacs のコンバートだけできればよいのです。
それには二つの理由があります。第一に、Emacs では使っていない C construct をすべて無視
できるということです。仮にトランスレーターが新しい更新の一部に対応できなくなってもそれ
を修正することが可能なのです。第二に、Emacs それ自身がすでに相対的に Lisp のスタイルで
書かれていて、Lisp の実装となっているからです。わたしたちはこれをトランスレーターに
Emacs についてのいくつかの詳細を教えることによってさらに exploit します。
trivial な例としては、DEFUN マクロによって生成されたすべての  Smumble globals は
Common Lisp に変換する必要はありません。
－ they are an artifact of the implementation,
and will show up directly in the generated defuns instead.


What to ignore
無視するもの

A good portion of Emacs is simply redundant in the CL world.  There are a few types 
(cons, vector, integers, functions) that are shareable — in fact, sharing these is 
part of the goal of this effort.  There are also a number of functions which are 
effectively identical.  There are also entire redundant modules, like the garbage 
collector, or the bytecode interpreter.

Emacs の good portion は Common Lisp 世界における redundant です。
(cons, vector, integers, functions のような) 共有可能ないくつかの型があります。
実際、これらを共有することは the goal of this effort の一部です。
また、effectively identical な多くの関数があります
ガーベジコレクターやバイトコードインタプリターのように
完全に余分なモジュールもあります。


The question is how to have the translator differentiate between what is useful and 
what is not, without breaking builds of future versions of Emacs.

疑問なのは、どのようにしてトランスレーターに対して有用なものとそうでないものとを
breaking builds of future versions of Emacs させることなく
differentiate させるかということです。


I don't currently think there is a high road to solving this problem.  For modules 
like the GC, I plan to have ad hoc translator rules for the particular source files.  
For functions and data types, I'm adding new GCC attributes that I can use to mark the 
ignorable definitions.

わたしは現状この問題を解決する high road があるとは考えていません。
GC のようなモジュールに対しては、特定のソースファイル向けのアドホックなトランスレーター
規則を持たせることをわたしは計画しています。
関数やデータ型に対しては、無視できる定義をマークするの使うことのできる
新しい GCC アトリビュートを追加します

Types
型

There are two type-related issues that arise when translating the source.

ソースを変換するときに arise な二つの型に関連した問題があります

First, how should Emacs-specific types be represented?  Primarily these types are 
structures, like struct buffer or struct string (we cannot use the CL string type, 
because Emacs adds properties directly to the string, and Emacs has its own 
idiosyncratic character handling).  My answer here is to just straightforwardly 
translate them to defstruct.

第一に Emacs 固有の型をどのように表現すべきなのでしょうか?
Primarily these types are  structures, like struct buffer or struct string
(we cannot use the CL string type, 
because Emacs adds properties directly to the string,
and Emacs has its own idiosyncratic character handling).
My answer here is to just straightforwardly translate them to defstruct.
ここでのわたしの回答は

The other question is when translating a C function, what do we do with the types of 
local variables?  For the most part I am pretending that they don't exist.  This works 
fine except for local arrays and structures, but these are easily handled by 
initializing variables properly. My rationale is that while this is slower, it lets me 
get something working more quickly, and we can always update the translator to emit CL 
type declarations later on.

もうひとつの疑問は C の関数を変換するときに
ローカル変数の型に対して何を行うのでしょうか? ということです。
For the most part I am pretending that they don't exist.
This works fine except for local arrays and structures,
but these are easily handled by initializing variables properly.
My rationale is that while this is slower,
it lets me get something working more quickly,
and we can always update the translator to emit CL type declarations later on.


This simple approach doesn't actually cover all the needed cases.  For example, there 
is code in Emacs that takes the address of a local variable and passes it somewhere.  
This is easy to deal with; much of the remaining work is just digging through the code 
looking for special cases to clean up.

このシンプルなアプローチは実際には必要なケースをすべてカバーしているわけではありません。
たとえば Emacs にはローカル変数のアドレスを取ってそれをどこかに渡してしまうようなコードがあります。
これは対処が簡単です。
much of the remaining work is just digging through the code 
looking for special cases to clean up.


I'm similarly omitting type declarations from the generated structures.  One possible 
nice side effect of this approach is that it will make it easier to lift Emacs' 
file-size restrictions, because there will no longer be any code assuming that the 
size is a fixnum.

同様にわたしは生成された structures から型宣言を omit しました。
One possible nice side effect of this approach is
このアプローチの One possible nice side effect は
that it will make it easier to lift Emacs' file-size restrictions,
because there will no longer be any code assuming that the size is a fixnum.


Macros
マクロ

Many low-level details of the Emacs implementation are hidden in macros.  For example, 
Emacs stuffs some type information into the low-order bits of pointers.  It uses 
macros to add or remove this information.  For this build, I redefine these macros to 
do nothing.  This makes the GCC Gimple representation much closer to the abstract 
meaning of the program, and thus simpler to translate.

Emacs の低水準の詳細の多くがマクロの中に封じ込められています。
たとえば、
Emacs stuffs some type information into the low-order bits of pointers.
It uses macros to add or remove this information.

このビルドのために、わたしはこれらのマクロを何もしないものに再定義しました。
このことは GCC の Gimple の表現をよりプログラムの抽象的な意味に密着した表現にして、
それにより変換は単純でした。


There are also some macros that are useful to redefine so that we can more easily hook 
into them from the translator.  For example, Emacs has a C macro INTEGERP that is used 
to check whether its argument is an integer.  Normally this macro uses bit twiddling 
to get its answer, but I redefine it like so:

There are also some macros that are useful to redefine
so that we can more easily hook into them from the translator.
再定義するのに有用ないくつかのマクロもありますから、
より簡単にトランスレーターからフックできます
たとえば Emacs には、その引数が整数がどうかをチェックするのに使われる
C マクロ  INTEGERP  があります
通常このマクロは答えを得るのに bit twiddling を使うのですが、
私は次のように再定義しました:

  #undef INTEGERP
  extern Lisp_Object *INTEGERP (Lisp_Object)
      __attribute__((lisp_form("integerp")));


Example

The translator is not nearly complete, but it can already do a fair job at translating simple
functions.  For example, here is “forward-point” from the Emacs C code:

トランスレーターは完全なものには程遠いものですが、
すでに簡単な関数の変換であれば十分に仕事を果たせるものです。
以下の C コードは Emacs の “forward-point”のものです:

  DEFUN ("forward-point", Fforward_point, Sforward_point, 1, 1, 0,
         doc: /* Return buffer position N characters after (before if N negative) point.  */)
    (Lisp_Object n)
  {
    CHECK_NUMBER (n);

    return make_number (PT + XINT (n));
  }

Here is what the translator comes up with:
トランスレーターの出力はこうです

  (defun Fforward_point (n)
    (let (
      temp-var-0
      Qintegerp.316
      temp-var-1
      current_buffer.317
      temp-var-2
      )
      (block nil (tagbody
        bb-0
          ; no gimple here
        bb-1
          ; no gimple here
        bb-2
          (setf temp-var-0 (integerp n))
          (if (== temp-var-0 nil)
            (go bb-3)
            (go bb-4))
        bb-3
          (setf Qintegerp.316 Qintegerp)
          (wrong_type_argument Qintegerp.316 n)
        bb-4
          (setf current_buffer.317 current_buffer)
          (setf temp-var-2 (buffer-pt current_buffer.317))
          (setf temp-var-1 (+ temp-var-2 n))
          (return temp-var-1)
    ))))
  
  (defun elisp:forward-point (arg0)
    (Fforward_point arg0))
  
The output looks pretty weird, because the translator works after GCC's CFG is built, 
and so the most straightforward translation is to use this mess with tagbody.  I doubt 
this matters much, but in any case the translator is readily hackable — it is still 
less than 400 lines of Python, including comments.

この出力は pretty weird に見えます。
because the translator works after GCC's CFG is built,
なぜならトランスレーターの出力 (work) は GCC の CFG を使って構築されていて、
and so the most straightforward translation is to use this mess with tagbody.

I doubt this matters much, but in any case the translator is readily hackable
? it is still less than 400 lines of Python, including comments.
それはまだコメントを含めても400行にいかない Python で書かれたたコードです。


One thing to note is the translation of “PT“.  This is actually a macro that refers 
to the current buffer:

これは実際にはカレントバッファを参照するマクロです。

  #define PT (current_buffer->pt + 0)

The translator properly turns this into a reference to “buffer-pt“.

Another detail is the handling of packages.  My plan is to put the Emacs 
implementation into one package, and then any elisp into a second package called “
elisp“.  A DEFUN in the C code will actually generate two functions: the internal one, 
and the elisp-visible one; hence the “elisp:” in the translation.

Next Steps
次のステップ

There's still a good amount of work to be done.  The converter punts on various 
constructs; type translation is implemented but not actually wired up to anything; the 
translator should emit definitions for alien functions; and plenty more.

This was written by tom. Posted on Wednesday, January 25, 2012, at 3:01 pm. Filed 
under Emacs, software. Bookmark the permalink. Follow comments here with the RSS feed. 
Post a comment or leave a trackback.

    Joel McCracken wrote:

    I wonder, are you going to make the source available anywhere soon?

    This sounds like a good project to hack on.
    Wednesday, January 25, 2012 at 6:03 pm

    Scott Turner wrote:

    I find it amusing — or ironic, or something — that you're using Python to translate C into Lisp :-) .
    Wednesday, January 25, 2012 at 6:55 pm

    dtw wrote:

    And if you publish code, choose the version control system that the potential contributors want to use: Git.
    Wednesday, January 25, 2012 at 6:58 pm

    tom wrote:

    Haha, yeah, the Python thing is funny. The reason is just that the Python plugin for GCC is the best one:

    http://tromey.com/blog/?p=714

    I did try MELT once but couldn't even get it to build; plus — yet another idiosyncratic lisp dialect, no thanks, life's too short.

    I'll make the code available soon.
    Wednesday, January 25, 2012 at 7:23 pm

© 2012 ¶ Thanks, WordPress. ¶ veryplaintxt theme by Scott. ¶ It's nice XHTML & CSS.

Emacs and Common Lisp, Part 2 | Hacker News

This is a project that I would like to see succeed. Emacs is my most important tool 
and the best improvement I can think for it to have is to have a better Lisp behind it. 
Threads, better error handling, tail-recursion, all would be huge wins.

このプロジェクトは成功してもらいたいね。
Emacs はわたしの最も重要なツールで、わたしが考えつくEmacs が持っているべき
一番の改良点はより良い Lisp をその背後に置くことです
#こなれてない文じゃのー
スレッドやより良いエラーハンドリング、末尾再帰といったものはみな huge wins です。

For some reason it fascinates me that for a project promoting the strengths of Common 
Lisp, one would write the translator in Python.

EDIT: Apparently this is because GCC has a Python plugin API. All right, I guess if 
there was a CL plugin API then the author would write the translator in CL.

Is the intention to end up with all the emacs lisp code rewritten in Common Lisp? If so
that may be misguided. emacs lisp is a DSL for making an extensible editor whilst Common
Lisp is a general purpose programming language. There are good reasons for emacs lisp
design decisions. Dynamic vs Lexical scope for example
http://www.gnu.org/software/emacs/emacs-paper.html#SEC18

This is really awesome. I wonder if the progress will be shared, at some point.

これは本当に価値のあるものだね、
どこかのタイミングで進捗を共有できれば良いのだけど。

As much as I enjoy writing emacs lisp, scripting in common lisp would have many benefits.

Emacs Lisp で書くのと同じくらい、Common Lisp でのスクリプティングは
多くの利得があることでしょう。

Nice to see s/he's following up with the initial idea. A fork would be interesting, 
but quite a bit of work, especially keeping up with the current emacs C language core 
development. Best of luck though, I look forward to what comes out of this.

To be successful, the fork does not have to keep up with current emacs C language 
development; it just has to attract enough users.

I guess I missed the part about writing a C translator, so that should make keeping up 
with the C code changes quite a bit easier.

■_ Ruby で Lisp

さっき見たら40になってたような

fogus: Lisp in 32 lines of Ruby

Lisp in 32 lines of Ruby
Jan 25, 2012

Playing around yesterday during lunch.1

class Lisp
  def initialize
    @env = {
      :label => lambda { |(name,val), _| @env[name] = val },
      :quote => lambda { |sexpr, _| sexpr[0] },
      :car => lambda { |(list), _| list[0] },
      :cdr => lambda { |(list), _| list.drop 1 },
      :cons => lambda { |(e,cell), _| [e] + cell },
      :eq => lambda { |(l,r), _| l == r },
      :if => lambda { |(cond, thn, els), ctx| eval(cond, ctx) ? eval(thn, ctx) : eval(els, ctx) },
      :atom => lambda { |(sexpr), _| (sexpr.is_a? Symbol) or (sexpr.is_a? Numeric) }
    }
  end

  def apply fn, args, ctx=@env
    return @env[fn].call(args, ctx) if @env[fn].respond_to? :call

    self.eval @env[fn][2], Hash[*(@env[fn][1].zip args).flatten(1)]
  end

  def eval sexpr, ctx=@env
    if @env[:atom].call [sexpr], ctx
      return ctx[sexpr] if ctx[sexpr]
      return sexpr
    end

    fn = sexpr[0]
    args = (sexpr.drop 1)
    args = args.map { |a| self.eval(a, ctx) } if not [:quote, :if].member? fn
    apply(fn, args, ctx)
  end
end

辛口の反応が多め

Lisp in 32 lines of Ruby | Hacker News

I've just started working on full-featured Lisp in javascript over the past few weeks: 
https://github.com/jlongster/outlet

It will compile to js and lua, and I'm focusing on writing games with it. I can attest 
that writing a Lisp compiler is really fun and shockingly simple in some places.

Current features I'm working on: http://jlongster.com/2012/01/16/outlet-gets-a-personality.ht...

It may be worthwhile looking at Shen (a similar lisp-like langauge) which targets 
translation to JS. I haven't checked in on their progress in a while, but it seems the 
largest implementation hurdle is tail recursion.

shen is http://www.shenlanguage.org/

This "lisp in x lines of y" tradition started with the original Lisp paper back
in 1960, which defined lisp in a few lines of lisp. Which, when you think about it, is an
extraordinarily lispy thing to do.

■_

なぜ開発者たちはアンチウイルスが大嫌いなのか。 大盛り上がり。

Founder's Blog - Jitbit: Why Developers Hate Antiviruses

Why Developers Hate Antiviruses
Jan 25, 2012

I hate antivirus software. I really do. Like almost every desktop software developer.

And the reasons are:

#1 - False-positive alarms

I'm sick and tired that my software is being detected as a "virus"...

    ...in spite of being signed with a trusted Verisign certificate.

    ...in spite of being .NET-based (a platform which is not very "virus-authoring-friendly",
    so to speak) and not even using any code-obfuscation.

    ...in spite of using the "ClickOnce" installation-technology (in other 
    words - the code runs in a sandbox).

     etc.

そのほかの理由。

#2 - Antivirus vendors not dealing with false-positive reports properly

(略)

#3 - Antivirus my ass!

Create a simple C program with a code like this:

#include <windows.h>
#include <string>

  int __stdcall WinMain(HINSTANCE,HINSTANCE,LPSTR,int)
  {
      return MessageBoxA(0,(std::string("->")+GetCommandLineA()+"<-").c_str(),"Cmdline",0);
  }


Compile it with a free "express" edition of Visual Studio 2008:
  cl -Os -EHs-c- -GR- -MD test.cpp /link -fixed:no user32.lib -incremental:no -out:test.exe

Now test this program with your favorite antivirus. Voila! A "TR/ATRAPS.Gen" has been detected.

Congrats! You've just wrote your first virus!

Why Developers Hate Antiviruses | Hacker News

Excellent timing. I just alt+tabbed away from writing an email to McAfee because one 
of my users sent me a screenshot of s3stat.com with a bright red "Dangerous Site 
Warning" from McAfee's SiteAdvisor.

Evidently, "We tested this site and found it very risky". Even though it's 
the public site for a 5-year-established (and popular) SaaS product. Even though it 
has no downloadable executables of any description. Even though it has no 
non-moderated user-generated content.

But it's got this: http://www.siteadvisor.com/sites/www.s3stat.com

... which is a page saying that their automated somethingorother scraped the internet 
and decided that my site is crazy dangerous, listing reasons such as... well, nothing 
actually. But look at it. It's RED! Must be bad.

So even if you don't actually write software that could possibly contain viruses, you 
can still end up on the wrong side of the antivirus companies.

nice.

Why programmers hate antiviruses : programming

Actually I hat them because it's a broken model.

1) Don't mix code and data (fuck you MS office)

2) Don't run code that isn't trusted (see 4)

3) Don't let anything write to the trusted area

4) When you must run untrusted code be really really fucking carefu:

    Run an up to date secure browser

    Run up to date secure plugins for it (preferably only on demand)

    The browser should sandbox the code

    The os should sandbox the browser

Ok so there are still rendering bugs but the 4 steps above are a 1000 time more 
effective than AV, have a sane security model and don't hog resources (sandboxes tends 
to have a small overhead)

This is why I run MSE with real time scanning disabled. One of the few antivirus apps 
that actually lets you disable it without taking up a crap ton of memory. It's good 
for the "right click and scan this file i just downloaded from some random site I 
don't trust" stuff. Which is all antivirus is ever good for...

Most AV software is a huge load of shit in the first place. McAfee borders on 
bloatware, Norton has had it's source code stolen multiple times. The best way to 
prevent viruses is software updates and improving user behavior.

If someone really wanted to get access to your machine they would use a 0day exploit, 
and no amount of AV would ever matter.

Besides if you get a virus, your system is compromised and you need a fresh image in 
the first place. The idea that a complex heuristics software is going to solve all 
your problems is utter bullshit.

Of course this is preaching to the choir here.

The main reason I use an AV (MSE) is to avoid those "Why the hell did I click 
that?" downloads and to prevent someone's flash drive from mucking up my computer. 
Basically a safety net.

Considering that most computers have a ton of RAM and fast CPUs, running an AV that 
will STFU until there's a problem won't slow the computer down unless you're using a 
netbook or old hardware.

■_ ネタバレ

山田芳裕 『へうげもの』 第九十七席

611 名無しんぼ＠お腹いっぱい [sage] 2012/01/26(木) 18:47:02.64 ID:JEXdzrJJ0 Be:
    空を飛ぶ ゲヒが飛ぶ　
    雲を突きぬけ　星になる
    火を噴いて 闇を裂き　スーパー武将が舞いあがる.
    ＨＥＵＧＥ 　ＨＥＵＧＥが数寄を抱いたまま.
    ＨＥＵＧＥが空を飛ぶ～♪ 

612 名無しんぼ＠お腹いっぱい [sage] 2012/01/26(木) 18:51:53.53 ID:5xbKczDPi Be:
    そこはHYOUGEだろう 

■_

• 型推論に関わる論理の概念と用語 その1 - 檜山正幸のキマイラ飼育記
• Wolfram Blog : C and a Box of Chocolates: Video Presentations from the Wolfram Technology Conference 2011
• セマンティックウェブ・ダイアリー : 末尾再帰，継続，アクタ，コルーチン
• NEC、従業員5000人を削減へ　今期は1000億円の最終赤字に - ITmedia ニュース
• Twitter / @m2ym: 僕が2009年に送ったEmacsの正規表現にlook ...
• Twitter / @m2ym: 元のパッチメールがこれか。2.5年ぐらいたっててｳﾜ ...
• Twitter / @m2ym: 議論みてると僕のパッチをマージする気はないらしくて、 ...
• Twitter / @m2ym: exponential blowupに強い正規表現エ ...
• Twitter / @m2ym: exponential blowupに強い正規表現エ ...
• Twitter / @m2ym: （使いものにならない）色んな拡張を標準に取り込んでお ...
• ASCII.jp：これでなんでもつながる！ 今すぐ持ちたいモバイルルーター
• Android アプリに LGPL ライブラリを組み込むとソースコード開示義務が発生するらしい: あるＳＥのつぶやき

■_

・イブニング
しばちゅーさんでさりげなく(でもないか)時代が進んで、曹操が退場。

アフタヌーン
むげにん、ヒストリエ、ヴィンサガ全部載ってた

ビッグコミック

日経ソフトウエア

北方三国志 (6) 次は秋に 7, 8, 9 とまとめて出るらしい。 完結にはまだまだだと思うけどなんだろう?

■_ J

おもしろそう

J言語 

182 デフォルトの名無しさん [sage] 2012/01/24(火) 22:23:36.70 ID: Be:
    オプソＪをandroidに実装しようとしてる人がいる。
    http://www.jsoftware.com/pipermail/chat/2012-January/004647.html

    記号使いまくりのＪに対応したソフトキーの実装で悩んでるみたいだが、
    「IMEはgraffiti for android推奨」で済むような気が。。。 

■_ Ada → C++

DoD Buzz | F-35 back in the crosshairs のコメント欄から。

DoD Buzz | F-35 back in the crosshairs

>Have any known issues even surfaced in all that code yet?

You mean apart from the quad-redundant failure of the avionics in 2004? or the court 
case brought by an employee that Lockheed was defrauding the government by producing 
low quality code?

Lockheed is writing it all in C++ rather than ADA because then they can hire cheaper 
engineers. The F-22s ADA code has taken 10 years and they still haven't debugged it. 
We can safely say that the F-35 will never be fully debugged.

You have to understand how the contractors operate - they use the cheapest engineers 
to hack something together and deliver it. When operational testing discovers it 
doesn't work they call that a change in requirements and charge the government to fix 
it.

Everywhere you look at the F-35 program you see a project optimised to deliver the 
lowest quality product at the highest contractor profits to the detriment of the 
American people and our security. 

F-22 で使われたソフトウェアは Ada で書かれた(がデバッグされていない)。 Ada プログラマーよりは安く上がるので C++プログラマーを探すと。 そして We can safely say that the F-35 will never be fully debugged. って…

■_ PowerShell

これはいいかも

南よ! 海の見える方! - 使う気が無い人向けのPowerShell入門

使う気が無い人向けのPowerShell入門

        [info]karino2
        January 22nd, 4:22

    ひどいタイトルだな(^^;

    このシリーズは、PowerShellの面白さを、実際に触る気が無いUnix系のスペシャリストに対して伝える事を目的にしています。
    この記事を読んで実際に触ってみる、という事は想定していません。むしろ一生触らない、と思っている人を対象とします。
    生涯触る気は無いけど、どういう物かは知りたい！という人は、まさに本シリーズのターゲットです。

    想定読者

        Windowsはほとんど知らない
        awkをそれなりに、Javaをかなり知っている

微妙に想定読者と違うな。わし(^^;

■_ それはバグではない

GCCでもそうなのねえ

GCC Bugs - GNU Project - Free Software Foundation (FSF)

Non-bugs

The following are not actually bugs, but are reported often enough to warrant a 
mention here.

It is not always a bug in the compiler, if code which "worked" in a previous 
version, is now rejected. Earlier versions of GCC sometimes were less picky about 
standard conformance and accepted invalid source code. In addition, programming 
languages themselves change, rendering code invalid that used to be conforming (this 
holds especially for C++). In either case, you should update your code to match recent 
language standards.

General

Problems with floating point numbers - the most often reported non-bug.

    In a number of cases, GCC appears to perform floating point computations incorrectly.
    For example, the C++ program

        #include <iostream>

        int main()
        {
            double a = 0.5;
            double b = 0.01;
            std::cout << (int)(a / b) << std::endl;
            return 0;
        }

    might print 50 on some systems and optimization levels, and 49 on others.

    This is the result of rounding: The computer cannot represent all real numbers exactly,
    so it has to use approximations. When computing with approximation, the computer needs
    to round to the nearest representable number.

    This is not a bug in the compiler, but an inherent limitation of the floating point
    types. Please study this paper for more information.

このほかにもいろいろありますがとりあえずひとつだけ。

■_

• WisdomSoft
• 久しぶりに描いたから、イメージ違ってたら... : ついっぷるフォト
• Mozilla、安全性にフォーカスしたコンパイル型言語「Rust 0.1」をリリース - SourceForge.JP Magazine : オープンソースの話題満載
• 遠藤諭の東京カレー日記: 電卓本、キタ！
• 他の言語に慣れた人がPythonを使ったときにつまずきがちな7つのポイント - 西尾泰和のはてなダイアリー
• 最近、結構な高学歴で、さぞ勉強は出来るだろうに、メモが取れない子をときどき見かけるんですよね・・・。業...
• mozilla/rust - GitHub
• Mozilla Firefox Thunderbird の拡張あれこれ-MEMO（2012年1月-13）
  ■(1/25) Rust 0.1
• Closing over the loop variable considered harmful - Fabulous Adventures In Coding - Site Home - MSDN Blogs
  Closures close over variables, not over values.
• Closing over the loop variable, part two - Fabulous Adventures In Coding - Site Home - MSDN Blogs
• F#で素数の無限シーケンスを作る #F# #fsharp - Qiita
• (1) Rolling and Flipping: Vose' Alias Algorithm in Smalltalk
• 不正サイコロの目の出方をシミュレートするエイリアス法（二者択一法）を Squeak Smalltalk で - Smalltalkのtは小文字です
• How to Design Programs - Wikipedia, the free encyclopedia
• Colorful Pieces of Game::ハドソンがファミコンに参入するまで（１）
• Rubyでアレするには何のメソッド使えばいいのか悩んだ時『what_methods』 - 牌語備忘録 - pygo
• 英語には日本語ほど丁寧さの程度による変化がないから，日本語ほど敬語などに気を遣わなくても良いことが多い...
• 【レポート】やらせもステマもありません! 「日本オタク大賞2011」、大賞は『電人ザボーガー』

■_

■_

時間がががが

■_

• 中里一日記: インタプリタがコンパイラになる話
  疑問――なぜPyPyの作者はRPythonなどという世にも使いにくい言語を作る必要があったのか？
• 符号なし整数の演算API、JDK8に導入 | エンタープライズ | マイナビニュース
• ケンコー、懐中電灯としても使える4,400mAhのモバイル電源 - 家電Watch
• Linux におけるシェルの進化

■_ Sonic Physics Guide

ROMから吸出して逆アセンブルして解析。なのかなあ。

Sonic Physics Guide - Sonic Retro

Sonic Physics Guide

ROM Hacks make the process of developing a functional Sonic game with unique art, enemies,
and modifications much easier, since the game engine and basic mechanics are already
functional. However, if the game requires a different game engine, modifying existing
low-level assembly may be inappropriate, and some game designers might choose to program
their own unique game engine. The physics of a game engine are rules that describe how to
transform the player's input (either in the form of buttons, keyboard, or even a mouse if
the designer feels inclined) into appropriate changes in the position of the sprites in
the game (such as the Sonic sprite, or alternatively, how enemy sprites will respond).
These physics guides will hopefully make the process of simulating the rules used in
Sonic games easier.

Since the rules themselves are independent of how they are implemented, many people choose
programming languages such as Java, C, C++, Python, or a Lisp dialect to implement game
physics. In addition, people can choose to use more specialized applications like Flash,
Game Maker, or a Clickteam program like Multimedia Fusion 2.

「ルール」それ自身は実装するのに使うプログラミング言語とは独立したものであるので
ここで紹介した記事が参考になるかもね♪

Hopefully, these guides will provide adequate information to facilitate implementation.

Physics Guides

    SPG:Solid Tiles
    SPG:Running
    SPG:Jumping
    SPG:Rolling
    SPG:Ring Loss
    SPG:Underwater
    SPG:Springs and Things
    SPG:Super Speeds
    SPG:Special Abilities
    SPG:Camera
    SPG:Getting Hit
    SPG:Rebound

↑末尾のリンク先がそれぞれの解説ページになっています。 ぜんぶ訳したりなんだりする元気はありませんw

reddit での反応 Collision detection in Sonic the Hedgehog : programming

■_ Design Patterns in Dynamic Languages

古い記事ですが、書いている人の名前が気になったので。

Design Patterns in Dynamic Languages

Design Patterns in Dynamic Languages
3/17/98

Table of Contents

Design Patterns in Dynamic Languages

Outline

(1) What Are Design Patterns?

What Are Design Patterns?

What's in a Pattern?

Pattern: Abstract Factory

Level of Implementation of a Pattern

Sources on Design Patterns

以下大き目の項目があと三つ。

(2) Design Patterns in Dynamic Languages

(3) New Dynamic Language Patterns

(4) Design Strategies

書いた人の名前を確認すると…

Author: Peter Norvig

Email: peter@norvig.com

Home Page: http://www.norvig.com

Download presentation source

Add or view reader comments 

■_

作った tokyotaplreading @ ウィキ - トップページ

■_ 文字列連結 (C で)

byuu's homepage 作業中

strcpycat 2012-01-08

This is a look at the various means in C to copy strings, and their safety and performance
implications. What is surprising is that all of the available implementations, even the
venerable *BSD strl functions have serious issues.

■_

自分もわりと気軽に sprintf (もしくはそのお仲間) を使って 複数の文字列を連結したりします(前提条件はありますが)。

strcpycat - This is a look at the various means in C to copy strings : programming

In my experience in many cases snprintf() can be used as a safe and standard-compliant 
alternative to strcpy()/strcat(). It has the desirable properties that it takes a 
total buffer length (like strlcpy()/strlcat()), it always zero-terminates the string 
it writes (unlike strncpy()/strncat()) and the return value is such that truncation 
can be detected easily.

For example, instead of writing:

  char buf[1024];
  strcpy(buf, foo);
  strcat(buf, bar);
  strcat(buf, baz);

(Which is totally unsafe, of course.) Instead, one could write:

  if ((size_t)snprintf(buf, sizeof(buf), "%s%s%s", foo, bar, baz) >= sizeof(buf)) {
      /* output was truncated -- handle this somehow (though even if you don't,
      buf[] contains a valid zero-terminated string) */
  }

This is not easily applicable to every situation, but in many cases it is a safer 
alternative to using strcpy()/strcat() that doesn't require inventing yet another 
"safe" variant of these functions.

(The cast to (size_t) in the above is somewhat optional; it is intended to work around 
non-standard-compliant implementations that return negative integers on truncation, 
such as very old versions of glibc. For virtually any reasonable modern libc 
implementation this isn't necessary.)

IIRC, all of the Windows snprintf-family functions return -1 on truncation. But of 
course msvcrt is neither reasonable or modern :)

Ah, that's good to know; in that case the (size_t) cast is useful.

(Returning the total size of the string is required by C99, but that makes sense since 
MSVC doesn't claim to implement C99 at all.)

I just tried this with MSVC++ 2010 Express. It doesn't seem to come with snprintf at 
all as far as I can tell. It does have a version called _snprintf, but it doesn't null 
terminate when truncating. It also suggests _snprintf_s instead, which throws an 
exception when truncating.

msvcrt のあれはねえ。

■_ Java で

パスワードをごにょごにょするのに、string じゃなくて char[] を使ったほうがいいのはなんで?

java - Why is char[] preferred over string for passwords? - Stack Overflow

In Swing, the password field has a getPassword() (returns char[]) method instead of usual
getText() (returns String) method. Similarly, I have come across a suggestion not to use
Strings to handle passwords. Why does String pose a threat to security when it comes to
passwords? It feels inconvenient to use char[]. Can anyone explain this to me?

Strings are immutable. That means once you've created the string, if another process 
can dump memory, there's no way (aside from reflection) you can get rid of the data 
before GC kicks in.

文字列は immutable です。
これはつまり、一度文字列を作ってしまうと他のプロセスがメモリーをダンプ可能であるときに
GC が動き出す前にそのデータを取り除く手段がないということです。

With an array, you can explicitly wipe the data after you're done with it: you can 
overwrite the array with anything you like, and the password won't be present anywhere 
in the system, even before garbage collection.

配列であれば、使い終わった後で explicitly に wipe できます。


So yes, this is a security concern - but even using char[] only reduces the window of 
opportunity for an attacker, and it's only for this specific type of attack.

EDIT: As noted in comments, it's possible that arrays being moved by the garbage 
collector will leave stray copies of the data in memory. I believe this is 
implementation-specific - the GC may clear all memory as it goes, to avoid this sort 
of thing. Even if it does, there's still the time during which the char[] contains the 
actual characters as an attack window.

While other suggestions here seem valid, there is one other good reason. With plain 
String you have much higher chances of accidentally printing the password to logs, 
monitors or some other insecure place. char[] is less vulnerable.

Consider this:

  public static void main(String[] args) {
      Object pw = "Password";
      System.out.println("String: " + pw);

      pw = "Password".toCharArray();
      System.out.println("Array: " + pw);
  }

Prints:

  String: Password
  Array: [C@5829428e

■_ patch

patch を実行する前になんで sed 使ってパッチファイルをごにょごにょしているんでしょうか

hiphop php でPHPからジェネレートされたC++コードを読んでみよう。 - お前の血は何色だ!! 4


# install libcurl  
# うちでは /usr/に上書きした
#
cd /usr/local/src/
wget http://curl.haxx.se/download/curl-7.20.0.tar.bz2
tar -xvf curl-7.20.0.tar.bz2
cp hiphop-php/src/third_party/libcurl.fb-changes.diff curl-7.20.0/
cd curl-7.20.0
sed -i 's/curl-old\///g' libcurl.fb-changes.diff
sed -i 's/curl-new\///g' libcurl.fb-changes.diff
patch -p0 < libcurl.fb-changes.diff
./configure --with-ssl --with-zlib --with-libidn --enable-sspi --enable-ldap --enable-ldaps --prefix=/usr
make
make install


# install libevent
# うちでは /usr/に上書きした
#
cd /usr/local/src/
wget http://monkey.org/~provos/libevent-1.4.13-stable.tar.gz
tar -xvf libevent-1.4.13-stable.tar.gz
cp hiphop-php/src/third_party/libevent-1.4.13.fb-changes.diff libevent-1.4.13-stable/
cd libevent-1.4.13-stable
sed -i 's/libevent-1.4.13-stable\///g' libevent-1.4.13.fb-changes.diff
sed -i 's/libevent-1.4.13-stable-fb\///g' libevent-1.4.13.fb-changes.diff
patch -p0 < libevent-1.4.13.fb-changes.diff
./configure --prefix=/usr
make
make install
ldconfig

patch -p1 にすれば sed の前処理不要?

/ をエスケープしてるのも気になるのよね :) いやまあデリミターを / にしているのであればエスケープしないと しようがないんだけど、別のキャラクターにデリミターを変えられますからね (Perl でも知らない人結構いるんだよねえ)。

■_ 885

ネタ。

やってて楽しいプログラミング言語は？ 3言語

874 デフォルトの名無しさん [sage] 2012/01/17(火) 23:07:10.33 ID: Be:
    やってて楽しいというか、ストレスを感じないのはC#だな
    構文とかライブラリの命名規則とかが

    だがLinqのクエリ式、てめーはダメだ 

875 デフォルトの名無しさん [sage] 2012/01/17(火) 23:24:56.80 ID: Be:
    >>874
    なんで？

    けっこう合理的な設計だと思うが 

876 デフォルトの名無しさん [sage] 2012/01/18(水) 07:00:23.08 ID: Be:
    >>875
    ごめん、なんかえらそーにダメだとか言ったけどただの俺の好みなんだ、すまない

    今までのクラスとメソッドをベースにした文法と掛け離れてるから
    何をしてるのか俺にはぱっと見で理解できない
    SQLをよく触ってる人からしたら分かりやすいのかもしれんとは思う 

877 デフォルトの名無しさん [sage] 2012/01/18(水) 08:08:37.62 ID: Be:
    プログラミング言語と呼べるかは別として、
    SQLは、面白いと思うけどな。
    パズルっぽくて。 

878 デフォルトの名無しさん [sage] 2012/01/18(水) 09:11:09.34 ID: Be:
    SQL書くの楽しいよな
    読むの嫌だけど。 

879 デフォルトの名無しさん [sage] 2012/01/19(木) 00:42:18.90 ID: Be:
    確かにこんな事も出来るのか的な発見は何時もあるよねSQLには。 

880 デフォルトの名無しさん [sage] 2012/01/19(木) 08:31:37.23 ID: Be:
    むしろSQLは読んでるほうが楽しい
    自分が書くと、あんまり色んなこと考えたくなくなって
    ごく単純なSQLで済ませてしまいたくなる 

881 デフォルトの名無しさん [sage] 2012/01/19(木) 08:32:35.84 ID: Be:
    それは楽しんでないだろw 

882 デフォルトの名無しさん [sage] 2012/01/19(木) 08:34:35.87 ID: Be:
    >>881
    そだね、俺自身は楽しんでないと思う 

883 デフォルトの名無しさん [sage] 2012/01/19(木) 14:13:22.88 ID: Be:
    長いSQLは人間が読むものじゃないと思う
    GUIとかで自動認識させてer図でみれないかな 

884 デフォルトの名無しさん [sage] 2012/01/20(金) 03:25:32.42 ID: Be:
    >>883
    guiで作ったクエリで大失敗したことないか？
    七月位に新人が本系にマジで投げよって業務停止させるのが恒例だったな。俺が前居た会社だと。 

885 デフォルトの名無しさん [sage] 2012/01/20(金) 10:14:12.98 ID: Be:
    UPDATE a_tbl SET flg = true;

    　　　　　 　　　＿＿＿_
    　　　　 　／::::::─三三─＼
    　　　　／:::::::: （ ○）三（○）＼　
    　　　　|::::::::::::::::::::（__人__）:::: 　|　＿＿＿＿＿＿＿＿
    　 　　 ＼::::::::::　 　|r┬-| 　 ／　| |　　　　　　　　　　 |
    　　　　ノ:::::::::::::　　`ー'´　 　＼　| |　　　　　　　　　　 | 

886 デフォルトの名無しさん [sage] 2012/01/20(金) 12:46:47.86 ID: Be:
    うあﾞぁあ ･ﾟ･(´Д⊂ヽ･ﾟ･ あﾞぁあぁﾞああぁぁうあﾞぁあﾞぁぁ 

887 デフォルトの名無しさん [sage] 2012/01/20(金) 14:42:46.94 ID: Be:
    >>885
    ぎゃあああああああああ

    CRUD時はWHEREの使用を強制する文法の方が良かったよな… 

888 デフォルトの名無しさん [sage] 2012/01/20(金) 22:04:47.10 ID: Be:
    commitしておきますね^^ 

■_

• スペースシャトル用プログラミング言語HAL/S - Plan9日記
• Mozilla Firefox Thunderbird の拡張あれこれ-MEMO（2012年1月-12）
• ある地方大学元学長のつぼやき
• 0xcc - Google+ - タイピングが速いプログラマは腕が立つ説 …
• Ruby札幌 - qwik.jp/RubySapporo
• 座間・相武台のカフェバーが「IT技術書バー」に－オンライン古書店が開く　／神奈川 （みんなの経済新聞ネットワーク） - Yahoo!ニュース
• What's the Most Readable Computer Language Syntax?
• カレーうどんはなぜ飛び散るか - 悪魔の妄想
• Software Designers～The People Behind the Code～（英語）：#34　Yukihiro “Matz” Matsumoto: Ruby Inventor｜gihyo.jp … 技術評論社
• SlideShare Zeitgeist 2011
• wrong, rogue and booklog - 個人の成績に基づいて給料を決めるという事は、従業員を競争させたら、皆一生懸命働き、組織としての生産性は...
• バグから学ぶ計算機科学 Scalaのハッシュテーブルにおいて並列コレクションのためのコード変更が大量の衝突を引き起こした事例
  きっと世の中のBTSにはこういうおもしろいバグが沢山あるはずです。みなさんも今まで見たおもしろいバグを紹介してみませんか。

■_

ASCII.jp：あのRubyが外箱に描かれた「Radeon HD 7970」が発売開始！

憂国のラスプーチン
現在出ている分の単行本は読んだ。 んで、連載で読んでいるのとつながったのでこれでいいかな。

予約した
電人ザボーガー スペシャルエディション(Blu-ray Disc)

電人ザボーガー スペシャルエディション [DVD]

両方 :)

昨日の読書会のあとでの濃い話について書こうと思ったが

■_ 5.5と5.8の長さが

Visualizing Perl 5 release cycles | David Golden

■_ それ awkで

さいとうさんに任せたほうが良かったかな

テキストファイルを処理するときのUnixコマンドまとめ - nokunoの日記

個人的にテキストファイルを処理することが多いのですが，簡単な処理ならUnixのコマンドをパ
イプとリダイレクトで組み合わせてできることが多くあります．今回はそんななかでもちょっと
マニアックなTIPSをまとめてみました．

sortコマンドでタブ区切りのファイルを指定する

最近知って驚愕したのがこれ．

sortコマンドでタブ区切りのファイルを指定したいときは，Ctrl+v Tabでタブ文字を入力してい
たのですが，

    $ sort -t $'\t' -k 2,2 < input.txt

のようにしてタブ区切りで2番目のキーでソートすることができます．

なんで $ が? -t'\t' (-t の直後にスペースがあってもよし) でいいと思うんだけど。 それとリダイレクトはいらないような。

1000行おきにデータをサンプリングする

1000行おきにファイルからデータをサンプリングしたいときとかは，perlでワンライナーを書くのが速いようです．

    $ perl -ne '$i++; print unless ($i % 1000)' < input.txt

某所のコードゴルフによるとこれだけ短くできるみたいです（気持ち悪い‥）

    $ perl -ne '$.%1e3||print' < input.txt

    $ perl -pe '$_=""if$.%1e3' < input.txt

■_

昨年末に「坂の上の雲」で日本海海戦をやった回が放映された日に、 日露戦争で活躍した人たちが太平洋戦争では～ とかついったで発言してた(フォロアーをたくさん抱えた有名)人がいたんですけど、 日露戦争は1904年から翌05年までで、太平洋戦争の開戦が1941年。 ぶっちゃけこの二つの戦争で「活躍」(力を振るう)って無理なんじゃないでしょか。 大雑把に二つの戦争の間が35年だとして、二十代半ばだった人でも還暦ですよね。 開戦時の連合艦隊司令長官だった山本五十六は日本海海戦にも参加してますが当時は少尉候補生でした。 山本五十六 - Wikipedia

TAPL読書会
やりました。

■_ 違い

Git と Mercurial

The Real Difference Between Git and Mercurial

2012 Jan 19

The Real Difference Between Git and Mercurial

I have a friend who is quite proficient with git but has recently started a job that uses
mercurial for their development and he's been learning how to use it. I used this
opportunity to do some research into the history of git and mercurial and why they've
turned out to be such different (yet similar) tools. I will start off by saying that I am
a fan of git but my intention is not to show that one is better than the other, only to
highlight the differences between the two and why they are the way they are. I will try to
include references where I have found them.

詳しくは元記事を :)

■_

そして記事に対する反響

The Real Difference Between Git and Mercurial : programming

As Scott Chacon (author of ProGit) puts it,it's really not that huge a deal if your 
using Git or Mercurial; they're very similar--it's using a distributed version control 
system that's a huge deal. Many many places are still locked into old school, 
centralized systems that make collaboration much harder than it is using Mercurial or 
Git

I wrote an article with almost exactly the same title almost exactly one year ago, but 
with very different content: 
http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/

    [the git index] encourages people to check in changesets that contain code which they've never tested.

Those people are sloppy! The git index also lets you do partial commits and rollbacks on your
current working set. Those tools help you to avoid making monolithic "Fixed some stuff" commits,
and in my humble opinion I'd rather have to bisect through a dozen non-building commits than to
have bisect lead me to a gigantic +1000/-200 commit.

ずっと見ていくと、darcs なんてのも出てきますね。

■_

Why metaprogram when you can program? « The Real Adam

Why metaprogram when you can program?
by Adam Keys

(略)

Various forms of metaprogramming are weaker or stronger than others. The weaker ones 
are harder to screw up and less likely to require a deep understanding of Ruby. The 
stronger ones have trade-offs that require careful application and possibly need a lot 
of explanation to newcomers to your codebase.

Rubyでメタプログラミングに使う「ワザ」には強いものも弱いものもあって、
弱いものは「威力」はそれほどでもないけれどもRubyに対する深い理解が必要になるほど
難しい代物でもない。強いものは注意深く使うか、新米に対するコードの説明を
念入りにするかしなければいけない。と
#チョー訳

Now, I will present to you a partial ordering of metaprogramming forms, in order of 
weak to strong. We can bicker on their specific placement, but I'm pretty certain that 
the first one is far better to use frequently than the last.

弱いものから強いものへと並べたメタプログラミングの形式。


    Blocks – I hesitate to call this a form of metaprogramming. But, it is sometimes abused,
    and it is sometimes smart to use blocks instead of tricks further down this list. That
    said, if you find yourself needing more than one block parameter to a method, you should
    consider a parameter object that holds those blocks instead.

    ブロック。
    あるメソッドに二つ以上のブロックパラメーターを渡す必要があるように感じたら、
    そのようなブロックを保持するパラメーターオブジェクトを使うことを考えよう

    Dynamic message send on a static object – You set a symbol on an object and later it
    will send that symbol as a method selector to an object that doesn't change at runtime.
    This is weak because the only thing that varies is the method that gets called. On the
    other hand, you could have just used a block.

    静的オブジェクトに対する動的なメッセージ送信
    オブジェクトに対してシンボルをセットしておいて、
    あとで呼び出すときにそのシンボルをメソッドセレクターとして送る
    実行時にオブジェクトを変更しない

    Dynamic message send on a dynamic object – You set a symbol and a receiver object, at
    some point they are combined into a method call. This is stronger than the previous form
    because you've got two points of variability, which means two things to hunt down and two
    more things to hold in your brain.

    動的オブジェクトに対する動的なメッセージ送信
    シンボルとレシーバーオブジェクトをセットして、メソッド呼び出しのときにそれらを組み合わせる
    静的オブジェクトに対する動的なメッセージ送信より強力


    Class.new – I love this method so much. But, it's a source of potential hurt when trying
    to understand a new piece of code. Classes magically poofing into existence at runtime
    makes code harder to read and navigate with simple tools. At the very least, have the
    civility to assign classes created this way to a constant so they feel like a normal
    class. Downsides, err, aside, I love this method so much, having it around is way better
    than not.


    define_method – I like this method a lot too. Again, it's way better to have it around
    than not. It's got two modes of use, one gnarly and one not-so-bad. If you look at how
    its used in Rails, you'll see a lot of instances where its passed a string of code,
    sometimes with interpolations inside said string. This is the gnarly form; unfortunately,
    it's also faster on MRI and maybe other runtimes. There is another form, where you pass
    a block to define_method and the block becomes the body of the newly defined method.
    This one is far easier to read. Don't even ask me the differences in how variables are
    bound in that block; Evan Phoenix and Wilson Bilkovich tried to explain it to me once
    and I just stared at them like a yokel.

    このメソッドにはふたつの「モード」がある
    Rails でどのように使われているか調べてみると
    コードを表す文字列を渡しているインスタンスを大量に見つけるだろう
    中には文字列の中で interpolating しているものもある

    ブロックを define_method に渡して、そのブロックが新しく定義されたメソッドの
    本体になるような使い方もある。
    

    class_eval – We're getting into the big guns of metaprogramming now. The trick with
    class_eval is that its tricky to understand exactly which class (the metaclass or the
    class itself) the parameters to class_eval apply to. The upside is that's mostly a
    write-time problem. It's easy to look at code that uses class_eval and figure out what 
    it intends to do. Just don't put that stuff in front of me in an interview and expect 
    me to tell you where the methods land without typing the damn thing into IRB.

    メタプログラミングの big guns
    class_eval を使った trick は class_eval を適用するパラメーターがどのクラスなのか
    を正確に知ることが tricky


    instance_eval – Same tricks as class_eval. This may have simpler semantics, but I always
    find myself falling back to tinkering with IRB, your mileage may vary. The one really
    tricky thing you can do with instance_eval (and the class <<some_obj trick) is put
    methods on specific instances of an object. Another thing that's better to have around
    than not, but always gives me pause when I see it or think I should use it.


    method_missing – Behold, the easiest form of metaprogramming to grasp and thus the most
    widely abused. Don't feel like typing out methods to delegate or want to build an API
    that's easy to use but impossible to document? method_missing that stuff! Builder
    objects are a legitimate use of method_missing. Everything else requires deep zen to 
    justify. Remember: friends don't let friends write objects that indiscriminately swallow
    messages.

    もっとも広く「間違った使い方」をされる形式。


    eval – You almost certainly don't need this; almost everything else is better off as
    a weaker form of metaprogramming. If I see this, I expect that you're doing something
    really, really clever and therefore have a well-written justification and a note from
    your parents.

    これを必要とすることはほとんどなく、これより弱い形式ですむことが大抵のはず。

■_ 仕様変更

Twitter / @uasi: Perl 6 のアングルブラケットに関する変更、ひど ... という話がありまして。

From 744f7ca348be91f677351ec1a7ef5c7d0c3990f2 Mon Sep 17 00:00:00 2001
From: Larry Wall <larry@wall.org>
Date: Tue, 17 Jan 2012 19:06:07 -0800
Subject: [PATCH] treat angle literals as slightly special

<1/2> and <+1-2i> now produce Rat and Complex as (slightly) special
forms.  Use whitespace or french angles to get the other behavior.
---
 S02-bits.pod |   15 +++++++++++++--
 1 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/S02-bits.pod b/S02-bits.pod
index b59ab34..54244e1 100644
--- a/S02-bits.pod
+++ b/S02-bits.pod
@@ -13,8 +13,8 @@ Synopsis 2: Bits and Pieces
 
     Created: 10 Aug 2004
 
-    Last Modified: 16 Jan 2012
-    Version: 247
+    Last Modified: 17 Jan 2012
+    Version: 248
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -4590,6 +4590,17 @@ visually isolating any known literal format as a single syntactic unit:
     <-1+2i>.polar
     (-1+2i).polar       # same, but only by constant folding
 
+Any such literal, when written without spaces, produces a pure numeric
+value without a stringy allomorphism.  Put spaces to override that:
+
+    <1/2>       # a Rat
+    < 1/2 >     # a RatStr
+
+Or use the the C<«»> form of quotewords, which is always allomorphic:
+
+    «1/2»       # a RatStr
+    « 1/2 »     # a RatStr
+
 =head3 Allomorphic Rats
 
 Any rational literal
-- 
1.7.5.4

Rat と RatStr … 無関係なものというわけではなさそうだけど (awk で出てくる number/stringnumstr みたいなものか?)

■_ dereference →

本の虫: 2011-01 pre-Kona 2012 mailingの簡易レビュー

N3324: Terminology: "indirection" versus "dereference"

規格の文面で、「ポインターを経由した間接アクセス」という意味の用語が統一されていない。
そのため、すべてのdereferenceを、"indirecting through a pointer"という表現に
置き換える提案。単純な置換えだが、かなり広範に渡る変更となる。

dereference はこれ、といううまい訳語がない(気がする)ので こういうもって回った言い方のほうがいいかもしれないなどと考えてしまった。

■_

• Gamasutra - News - Windows NT father joins Xbox 360's multimedia efforts
• 中里一日記: Coders at Work まとめ Part 2
• 中里一日記: Coders at Work まとめ Part 3
• 中里一日記: Coders at Work まとめ おまけ
  おまけと言いつつ、今度こそ本当にまとめる。と言いつつ感想を書く
• pkgsrc/milter-regex
• サーバ構築(7) SPAM対策(sendmail + S25R) | 世迷言
• benzedrine.cx - milter-regex
• アメリカに来て一番驚いたこと - wof_moriguchiの日記
• An Introduction to Scheme for C wizards and witches 5 / CウィザードのためのScheme入門5 | pineapple blog
• エロ話とは違う無知の意味での｢恥ずかしい｣体験 ... - cxx.tumblr.com
• バグから学ぶ計算機科学 Scalaのハッシュテーブルにおいて並列コレクションのためのコード変更が大量の衝突を引き起こした事例
• Twitter / @checkela: 電子書籍で何か出してみたいなあ、という思いはあるにゃ ...
• Twitter / @Nkzn: @checkela リファレンス的な使い方する技術書 ...
• Twitter / @checkela: @Nkzn まあ電子書籍なららくしょーですな。epu ...
• Twitter / @Nkzn: @checkela 課金方法ですかー。達人出版会さん ...
• Twitter / @checkela: @Nkzn 電子書籍だけでは成り立ちにくいかなーとい ...
• Twitter / @takahashim: @checkela @Nkzn ぶっちゃけどのくらい ...
• Twitter / @checkela: @takahashim 収益ってのは印税額のことです ...
• Twitter / @takahashim: @checkela そうですね、書き手として、どれく ...
• Twitter / @checkela: @takahashim ジャンルなど抜きにして、大雑 ...
• Twitter / @checkela: 電子書籍で月額課金しているところってまだ無いんかなー ...
• Twitter / @takahashim: @checkela なるほどー、とても参考になります ...
• Twitter / @checkela: @takahashim それは承知してます。将来的に ...