ときどきの雑記帖 2012

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

一つ前へ 2012年7月(中旬)
一つ後へ 2012年8月(上旬)

ホームへ

2012年07月31日

■_

七月終了

また面白そうなものが サーバ擬人化ユーザ会 コミケ2012夏宣伝

『リーダブルコード』を読んで これ、原題の「The Art of Readable Code」の「Art」を 日本語の「芸術」というか(カタカナ語の)「アート」と同じ意味でとらえているんだけど どうなんですかね。日本語の(漢字の?)「芸」(芸術)も 大きな辞書でその意味を調べてみると結構意外な意味があったりします。 英単語の art もそうなんですよね。

The Art of War - Wikipedia, the free encyclopedia Prologの技芸
Prologの技芸 The Art of Prolog, 2nd Edition: Advanced Programming Techniques (Logic Programming)
The Art of Prolog, 2nd Edition: Advanced Programming Techniques (Logic Programming)

■_

■_ 圏

Does category theory make you a better programmer ? : Ruminations of a Programmer : programming Does category theory make you a better programmer? | Hacker News Ruminations of a Programmer: Does category theory make you a better programmer ? 

Ruminations of a Programmer: Does category theory make you a better programmer ?

Does category theory make you a better programmer

How much of category theory knowledge should a working programmer have － I guess this depends on
what kind of language the programmer uses in his daily life. Given the proliferation of functional
languages today, specifically typed functional languages (Haskell, Scala etc.) that embeds the
typed lambda calculus in some form or the other, the question looks relevant to me. And apparently
to a few others as well. In one of his courses on Category Theory, Graham Hutton mentioned the
following points when talking about the usefulness of the theory :

日を改めて。

■_ ということで

8月も休み確定だったりして。 第十六回TAPL読書会 「まだ終わらんよ」 - [PARTAKE]

2012年07月30日

■_

LL Decade の会場の場所をチェックするなど。

■_ Rakudo

.msi なインストーラーパッケージが。 

Windows .msi available for Rakudo Star 2012.07 | rakudo.org

Windows .msi available for Rakudo Star 2012.07

Posted on 2012.07.30 by pmichaud

I'm pleased to announce that starting with the current Rakudo Star release (2012.07), we will now
be providing Windows .msi distributions with precompiled binaries for Rakudo Star. The .msi
distribution is available in the same location as other Rakudo Star releases, at
 https://github.com/rakudo/star/downloads/ .

On this site, on IRC, and at YAPC::NA 2012 I heard many people comment that Windows users really
wanted a binary install option. We've occasionally done .msi and .exe installers for Rakudo Star
releases in the past, but didn't have any dedicated tools or sufficient environments to be able
to produce them consistently each month. So, this month I dedicated some time to create scripts
and tools that can automate much of the process of building .msi distributions from the Rakudo
Star release tarballs. Over the next couple of weeks I will be documenting the process so that
others can hopefully follow it as well. With the new tools in place I think we'll be able to 
consistently provide Rakudo .msi distributions within a few days (if not hours) of each monthly
tarball release.

(ry)

Enjoy!

やっぱ要望あったのね。＞ binary install option

■_ gawk

gawk の拡張ライブラリの仕様が以前のものとは変わったけど固まりつつあるとか聞いて ちょっと眺めてみた。 

/*
 * ext.c - Builtin function that links external gawk functions and related
 *	   utilities.
 *
 * Christos Zoulas, Thu Jun 29 17:40:41 EDT 1995
 * Arnold Robbins, update for 3.1, Mon Nov 23 12:53:39 EST 1998
 */

/*
 * Copyright (C) 1995 - 2001, 2003-2012 the Free Software Foundation, Inc.
 * 
 * This file is part of GAWK, the GNU implementation of the
 * AWK Programming Language.
 * 
 * GAWK 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 of the License, or
 * (at your option) any later version.
 * 
 * GAWK 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
 */

#include "awk.h"

#ifdef DYNAMIC

#include <dlfcn.h>

/* do_ext --- load an extension at run-time: interface to load_ext */

NODE *
do_ext(int nargs)
{
	NODE *obj, *fun, *ret = NULL;
	SRCFILE *s;
	extern SRCFILE *srcfiles;

	fun = POP_STRING();
	obj = POP_STRING();

	s = add_srcfile(SRC_EXTLIB, obj->stptr, srcfiles, NULL, NULL);
	if (s != NULL)
		ret = load_ext(s->fullpath, fun->stptr, obj);
	DEREF(obj);
	DEREF(fun);
	if (ret == NULL)
		ret = dupnode(Nnull_string);
	return ret;
}

/* load_ext --- load an external library */

NODE *
load_ext(const char *lib_name, const char *init_func, NODE *obj)
{
	NODE *tmp = NULL;
	NODE *(*func)(NODE *, void *);
	void *dl;
	int flags = RTLD_LAZY;
	int *gpl_compat;

	if (do_sandbox)
		fatal(_("extensions are not allowed in sandbox mode"));

	if (do_traditional || do_posix)
		fatal(_("`extension' is a gawk extension"));

#ifdef RTLD_GLOBAL
	flags |= RTLD_GLOBAL;
#endif

	if ((dl = dlopen(lib_name, flags)) == NULL)
		fatal(_("extension: cannot open library `%s' (%s)\n"), lib_name,
		      dlerror());

	/* Per the GNU Coding standards */
	gpl_compat = (int *) dlsym(dl, "plugin_is_GPL_compatible");
	if (gpl_compat == NULL)
		fatal(_("extension: library `%s': does not define `plugin_is_GPL_compatible' (%s)\n"),
				lib_name, dlerror());
	func = (NODE *(*)(NODE *, void *)) dlsym(dl, init_func);
	if (func == NULL)
		fatal(_("extension: library `%s': cannot call function `%s' (%s)\n"),
				lib_name, init_func, dlerror());

	if (obj == NULL) {
		obj = make_string(lib_name, strlen(lib_name));
		tmp = (*func)(obj, dl);
		unref(tmp);
		unref(obj);
		return NULL;
	}

	tmp = (*func)(obj, dl);
	return tmp; 
}


/* make_builtin --- register name to be called as func with a builtin body */

void
make_builtin(const char *name, NODE *(*func)(int), int count)
{
	NODE *symbol, *f;
	INSTRUCTION *b;
	const char *sp;
	char c;

	sp = name;
	if (sp == NULL || *sp == '\0')
		fatal(_("extension: missing function name"));

	while ((c = *sp++) != '\0') {
		if ((sp == &name[1] && c != '_' && ! isalpha((unsigned char) c))
				|| (sp > &name[1] && ! is_identchar((unsigned char) c)))
			fatal(_("extension: illegal character `%c' in function name `%s'"), c, name);
	}

	f = lookup(name);

	if (f != NULL) {
		if (f->type == Node_func) {
			/* user-defined function */
			fatal(_("extension: can't redefine function `%s'"), name);
		} else if (f->type == Node_ext_func) {
			/* multiple extension() calls etc. */ 
			if (do_lint)
				lintwarn(_("extension: function `%s' already defined"), name);
			return;
		} else
			/* variable name etc. */ 
			fatal(_("extension: function name `%s' previously defined"), name);
	} else if (check_special(name) >= 0)
		fatal(_("extension: can't use gawk built-in `%s' as function name"), name); 

	if (count < 0)
		fatal(_("make_builtin: negative argument count for function `%s'"),
				name);

	b = bcalloc(Op_symbol, 1, 0);
	b->builtin = func;
	b->expr_count = count;

	/* NB: extension sub must return something */

       	symbol = install_symbol(estrdup(name, strlen(name)), Node_ext_func);
	symbol->code_ptr = b;
}


/* get_argument --- get the i'th argument of a dynamically linked function */

NODE *
get_argument(int i)
{
	NODE *t;
	int arg_count, pcount;
	INSTRUCTION *pc;
	
	pc = TOP()->code_ptr;		/* Op_ext_builtin instruction */
	pcount = (pc + 1)->expr_count;	/* max # of arguments */
	arg_count = pc->expr_count;	/* # of arguments supplied */

	if (i < 0 || i >= pcount || i >= arg_count)
		return NULL;

	t = PEEK(arg_count - i);
	if (t->type == Node_param_list)
		t = GET_PARAM(t->param_cnt);

	if (t->type == Node_array_ref)
		t = t->orig_array;
	if (t->type == Node_var)	/* See Case Node_var in setup_frame(), eval.c */
		return Nnull_string;
	/* Node_var_new, Node_var_array or Node_val */
	return t;
}


/* get_actual_argument --- get the i'th scalar or array argument of a
	dynamically linked function, allowed to be optional.
*/

NODE *
get_actual_argument(int i, bool optional, bool want_array)
{
	NODE *t;
	char *fname;
	int pcount;
	INSTRUCTION *pc;
	
	pc = TOP()->code_ptr;	/* Op_ext_builtin instruction */
	fname = (pc + 1)->func_name;
	pcount = (pc + 1)->expr_count;
 
	t = get_argument(i);
	if (t == NULL) {
		if (i >= pcount)                /* must be fatal */
			fatal(_("function `%s' defined to take no more than %d argument(s)"),
					fname, pcount);
		if (! optional)
			fatal(_("function `%s': missing argument #%d"),
					fname, i + 1);
		return NULL;
	}

	if (t->type == Node_var_new) {
		if (want_array)
			return get_array(t, false);
		else {
			t->type = Node_var;
			t->var_value = dupnode(Nnull_string);
			return t->var_value;
		}
	}

	if (want_array) {
		if (t->type != Node_var_array)
			fatal(_("function `%s': argument #%d: attempt to use scalar as an array"),
				fname, i + 1);
	} else {
		if (t->type != Node_val)
			fatal(_("function `%s': argument #%d: attempt to use array as a scalar"),
				fname, i + 1);
	}
	assert(t->type == Node_var_array || t->type == Node_val);
	return t;
}

そういやこのチェックがどうのって以前に見かけたなあ gpl_compat = (int *) dlsym(dl, "plugin_is_GPL_compatible");

インタープリターをバイトコードマシンに変更しているので (この変更は3.7→3.8で入ったものだけど)、 拡張ライブラリの関数呼び出しのところが確かに変わってる。

そういやこのコメントは 

	/* Per the GNU Coding standards */
	gpl_compat = (int *) dlsym(dl, "plugin_is_GPL_compatible");
	if (gpl_compat == NULL)

if の条件式の中で代入しないで分けるってことを言ってるのかな (たしかそういう規則があったはず)。

■_

■_

LL Decade の会場ではあの出版社やらあの出版社の出張販売があるだろうから (割引とノベルティつき)、アレとかアレはそこで買うか。 あとは翌週の薄い本祭りでどれだけ使うかだなあ。

2012年07月29日

■_

おお、このシリーズは期待しちゃうぞ 泳ぐやる夫シアター AAで学ぶ南北戦争への道　序　はじまりの砲声

■_

■_ 仕様変更

こういうのをついったで見かけまして。 

#678652 - rgrep and grep -r suddenly decide to ignore symlinks to files - Debian Bug report logs

This change of behaviour is not documented in the manpage, which still
claims that -r and -R do the same thing:

 -R, -r, --recursive
        Read all  files  under  each  directory,  recursively;  this  is
        equivalent to the -d recurse option.

This change breaks existing scripts which rely on "grep -r" reporting
about symbolic links to files, too.

Regardless of the merits of the change, it also breaks compatibility
with BSD grep. I don't think we can accept that.

-R って前からあったのだっけ? (文面からはそう取れるけど記憶にない…) 最初、-r の動作を変更した上で以前の -r の動作をする -R を追加した と思ったのだけどそうではないと。

■_

LLVM 本とか

双六みたいに、ブースに着いたらすでに全部売れてました。 ってのはやだなあ(あれは委託販売されるようになったけど)。 確かサークル組で全部はけちゃったんだよなあのときは。

追記されてた 値段は1部800円です。身内配布用を除いて全部で60部になります。 (LLVM解説本をC82で出します - Boost Your Programming!) うへー厳しそう。 こんな感じだし → twitter ツイッター検索 llvm 解説本

■_ 複数のブロック

忘れないうちに。

「以前どこかで言及していた」 というのは

2012年07月28日

■_

なんか延期だか未定だかになってしまったらしい → Naked Code: The Ultimate Guide to Programming in Any Language: Amazon.ca: Eldad Eilam: Books Amazon さんからお知らせメールが来た。 んー、期待してんだけどなあ。

買った。 乙
乙
とある事情で本放送三回目あたりで差し替えられてしまった OP 曲も収録。 もったいなかったよなあ。これ。

■_ Six languages to master

六番目に注目 :) 

Six languages to master. « Michael O.Church

Six languages to master.

July 27, 2012 by michaelochurch

Eric Raymond, in “How to Become a Hacker”, recommended five languages: C, Java, Python, Perl,
and Lisp. Each he recommended for different reasons: Python and Java as introductory languages, C
to understand and hack Unix, Perl because of its use in scripting, and Lisp for, to use his words
which are so much better than anything I can come up with, the profound enlightenment experience
you will have when you finally get it. That experience will make you a better programmer for the
rest of your days, even if you never actually use LISP itself a lot.

Eric Raymond は “How to Become a Hacker”
(日本語訳 How To Become A Hacker: Japanese)
の中で、五つの言語を勧めていました。その五つとは、C、Java、Python、Perl、Lisp です。
これらそれぞれに、別々の推薦理由がありました。
入門言語 (introductory lanhuage) としての Python と Java、
Unix を理解しハックするための C、
スクリプティングに使う Perl、
そして (略)な Lisp


It's 2012. Many languages have come to the fore that didn't exist when this essay was written.
Others, like Perl, have faded somewhat. What is today's five-language list? I won't pretend that my
answer is necessarily the best; it's biased based on what I know. That said, I'd think the 5
highest-return languages for people who want to become good engineers are the following, and in this
order: Python, C, ML, Clojure, and Scala.

今は2012年です。あのエッセイが書かれたときには存在していなかった言語が数多く登場しました。
そのほか、Perl などは色褪せてしまったようです。
今日の five-language list はどんなものでしょうか?
自分の回答が最善のものであるとは思いません。
それはわたしが知っていることのバイアスがかかっているからです。
ということで、優れたエンジニアになりたいと望む人に推薦する highest-return な言語を五つ
考えてみることにしました。高い順から Python、C、ML、Clojure、Scala です。


Why these 5? Python I include because it's easy to learn and, in-the-small, extremely legible.

なぜこの五つなのか?
わたしが Python を含めたのは、Python が学習しやすいということと
とても legible であるからです。
(以下略)

■_ 八八

【宇宙戦争】横山信義総合スレ25【碧海の玉座】

381 名無し三等兵 [sage] 2012/07/24(火) 12:47:17.23 ID:??? Be:
    今月の中公の新刊に挟まれてた新刊案内に何か情報は無いかな、
    と見たら、20周年記念作という扱いなんだね＜新八八

    これで現在３シリーズも抱えることになるので執筆ペースが気になる所だけど、
    各作とも読んでて楽しめた、と思える内容と結末を願うばかり。 

382 名無し三等兵 [sage] 2012/07/24(火) 16:14:04.04 ID:??? Be:
    とりあえず宇宙戦争と群龍はどちらも面白い
    八八も、旧版のノリと現在の考証が組み合わさるなら期待できそう

新八八ってなんじゃ? と思ったらちょっと前にあったのに読み落としていたっぽい (C★NOVELSの案内ページにもあった) 

【宇宙戦争】横山信義総合スレ25【碧海の玉座】

320 名無し三等兵 [sage] 2012/07/12(木) 17:52:56.84 ID:??? Be:
    C★NOVELS
    八八艦隊海戦譜
    開戦篇

    横山信義 著

    刊行予定日：2012/8/25

321 名無し三等兵 [sage] 2012/07/12(木) 18:13:17.73 ID:??? Be:
    物語の再版か、物語の劣化版かどっちだ？ 

322 名無し三等兵 [sage] 2012/07/12(木) 18:28:15.16 ID:??? Be:
    東西冷戦からの開戦かもしれんぞ
    延々と続く掃海部隊の護衛と対潜哨戒の日々が描かれるとか 

328 名無し三等兵 [sage] 2012/07/13(金) 10:52:50.92 ID:??? Be:
    むむむ…現在のノビーが八八艦隊をセルフリメイク？
    なんかあっという間に日本が負けそうなんだけどｗ
    具体的にはマーシャル沖海戦で 

329 名無し三等兵 [sage] 2012/07/13(金) 11:40:15.03 ID:??? Be:
    はいはい
    日本近海で決戦して講和で終了と 

332 名無し三等兵 [ｓage] 2012/07/13(金) 16:45:15.59 ID:??? Be:
    >八八新刊

    アマゾン予約ページより…
    「独伊と同盟を締結した日本を牽制し、米軍が対日宣戦を布告、トラックを奇襲した。
    　遂に完成した八八艦隊がレキシントン級を迎え撃つ! 」

    おいおい・・・ｗ 

333 名無し三等兵 [sage] 2012/07/13(金) 18:41:21.64 ID:??? Be:
    名前が似てるだけの別物かな 

334 名無し三等兵 [sage] 2012/07/13(金) 19:05:12.86 ID:??? Be:
    何んかもうネタ切れなのかな… 

335 名無し三等兵 [sage] 2012/07/13(金) 19:28:14.24 ID:??? Be:
    >>334
    山本が八八艦隊を率いたら・・・？という流れかな？
    物語の方は指揮官が無能すぎたと言う反省で 

336 名無し三等兵 [sage] 2012/07/13(金) 19:44:56.96 ID:??? Be:
    八八で牙城？ 

337 名無し三等兵 [sage] 2012/07/13(金) 20:12:23.70 ID:??? Be:
    八八艦隊中心なのに、なぜか小口径高速砲無双になる未来が早くも見えている件について。 

338 名無し三等兵 [sage] 2012/07/13(金) 20:18:46.28 ID:??? Be:
    >>335
    物語の方では、史実で山本五十六がやらかした失敗を作中で嶋田にやらせてたな。
    （編集者や出版社サイドの？）山本五十六神話とはこれほどまでに強固なものかと思ったものだった。 

341 名無し三等兵 [ｓage] 2012/07/13(金) 21:17:22.07 ID:??? Be:
    八八は、最近かなり資料発掘が進んで、福井静雄節の『定説』がかなり変わってるから
    翻案する気になったんじゃないかな。
    個人的には、41センチ4連装砲塔搭載艦なんかあまり見たくないんだが。

    隠し味は日英同盟じゃないかね。チャーチル死んでチェンバレンが生きてて、結構有能
    なんでドゴールと組んでて反共戦略、西部戦線は存在しなくて、とか。
    要は中東や蘭印、仏印の資源が確保できてりゃ、ってこりゃ群龍の戦艦版かい。 

342 名無し三等兵 [sage] 2012/07/13(金) 21:22:20.33 ID:??? Be:
    インヴィンシヴル級やセントアンドリュー級が日の目を見る可能性も微レ存

ちょっとだけ期待しつつ待つことにしよう＞八八

■_ しかして

Perlについての質問箱 53箱目

550 デフォルトの名無しさん [sage] 2012/07/27(金) 23:41:19.64 ID: Be:
    しかしてその実態は！！

551 デフォルトの名無しさん [sage] 2012/07/28(土) 00:49:27.32 ID: Be:
    実態は？ 

552 デフォルトの名無しさん [sage] 2012/07/28(土) 00:53:40.72 ID: Be:
    誰もわからないっていう 

553 デフォルトの名無しさん [sage] 2012/07/28(土) 01:07:03.06 ID: Be:
    「しかし」と「はたして」がごっちゃになったんだろうな
    日本語不自由すぎ 

554 デフォルトの名無しさん [] 2012/07/28(土) 02:21:20.03 ID: Be:
    でもこのスレ最近勢いが10位以内に入るくらい活気があるんだよな 

555 デフォルトの名無しさん [sage] 2012/07/28(土) 03:07:37.78 ID: Be:
    >>553
    いちおういっとくが、「しかして」はちゃんとした日本語だぞ
    しかしてその実体は、ってのは昔の映画かなんかではやった言葉

    >>550
    気になって調べてみたが、昭和３５年以前のブームなのか
    さすがに俺も生まれる前だが、お前いったいいくつだ？

556 デフォルトの名無しさん [sage] 2012/07/28(土) 03:35:32.69 ID: Be:
    昭和35年ワラタｗ
    昭和35年生まれだとしたら今62歳くらいか？
    でも生まれたばかりのガキがそんな言葉認識できないし、
    「実態」が認識できるならせめて10歳以上くらいじゃないか？
    つまり昭和35年の時点で10歳とすると 

557 デフォルトの名無しさん [] 2012/07/28(土) 03:36:56.27 ID: Be:
    62歳ではないな、52歳かｗ
    で、昭和35年に10歳だと仮定すると、今62歳くらいか 

558 デフォルトの名無しさん [sage] 2012/07/28(土) 04:17:17.17 ID: Be:
    おまえら　PerlやVB6の生き証人様になんて口をっ！ 

559 デフォルトの名無しさん [sage] 2012/07/28(土) 04:24:36.09 ID: Be:
    昭和45年生まれだが
    「しかして、その実体は！」
    は、なんとなく判る 

560 デフォルトの名無しさん [sage] 2012/07/28(土) 05:19:33.43 ID: Be:
    しかし、しかも、しかり、しからば、しかるに…などの「然り」系の言葉か＜然して
    なるほどね

A 社のみなさまも辞書ひきましょうね… しかして【然して・而して】 の意味とは - Yahoo!辞書

■_

■_ 色数

印刷のときに指定できる色数があと少し、16色くらいあればなあ。 白地図ももうちょっと小さいエリアで区切ったのが… 自作すっか?

コミックマーケット 82 DVD-ROM カタログ
コミックマーケット 82 DVD-ROM カタログ

巡回リストは大体できた。 2日目がメインとしても、3日目もけっこう見に行きたいのがあるので燃え尽きに注意せねば(笑)

2012年07月27日

■_

中国人エンジニア
中国にある弊社の関連会社から研修ということで彼の地のエンジニアがいらしているわけなんですが (関係はあるけどちょっと離れた部署なので直接のやり取りはなかったり)、 紹介のときに 「日本語教えてあげてください」よりは 「中国語を教えてもらいにいってみろ」 というべきなんじゃないかなあなどと思ったり (いやまあ日本語習得も彼らの目的のひとつなんでしょうけども)。

■_

■_

いろいろと以下略

2012年07月26日

■_

教えてください富野です ガンダムエース連載のこれ、次回が最終回という話を聞きましたがさて (オリジンの連載が終わってから買ってないの) GUNDAM A (ガンダムエース) 2012年 09月号 [雑誌]

この後の分はすぐにでるのかなあ → ガンダム世代への提言 富野由悠季対談集　I (単行本コミックス) ガンダム世代への提言 富野由悠季対談集　）ローマ数字２） (単行本) ガンダム世代への提言 富野由悠季対談集　III (単行本コミックス)

アレ
The International Obfuscated C Code Contest 2012-Aug-15 03:14:15 UTC to 2012-Sep-14 09:26:53 UTC

■_

■_ Microsoft は

この記事ぽすとぽーん

■_ 

The ups and downs of strlcpy() [LWN.net]

The ups and downs of strlcpy()
By Michael Kerrisk
July 18, 2012

Adding the strlcpy() function (and the related strlcat() function) has been a perennial request
(1, 2, 3) to the GNU C library (glibc) maintainers, commonly supported by a statement that strlcpy()
is superior to the existing alternatives. Perhaps the earliest request to add these BSD-derived
functions to glibc took the form of a patch submitted in 2000 by a fresh-faced Christoph Hellwig.

strlcpy() 関数 (とそれに関連した strlcat() 関数) を追加することは
GNU C ライブラリ (glibc) メンテナーへの perennial request でした。
この request は一般に、
strlcpy() は既存の代替関数 (alternatives) よりも優れているという statement によって
後押しされていました。
これらの BSD-derived な関数群の glibc への追加リクエストの一番古いものは
おそらく 2000 年に fresh-faced Chrsioph Hellwig によって
submit されたパッチ投稿の体裁をもったものでしょう。


Christoph's request was rejected, and subsequent requests have similarly been rejected 
(or ignored). It's instructive to consider the reasons why strlcpy() has so far been 
rejected, and why it may well not make its way into glibc in the future.

Christoph のリクエストは却下されましたし、続く同様のリクエストも同様に却下され(るか無視され)
ました。strlcpy() がなぜそんなにも reject され続けているのかの理由や
将来においても glibc に取り込まれないであろうかの理由を
推測することは instructive (有益、ためになる) です。


A little prehistory

In the days before programmers considered that someone else might want to deliberately 
subvert their code, the C library provided just:

プログラマーが、自分以外の誰かが自分たちのコードを故意に subvert (破壊) することを望むように
なるかもしれないことを気にするようになる以前の日々、
C のライブラリが提供していたのは次のようなものでした

    char *strcpy(char *dst, const char *src);

with the simple purpose of copying the bytes from the string pointed to by src (up to 
and including the terminating null byte) to the buffer pointed to by dst.

たとえばこれは src によって示されている文字列から dst によって示されているバッファへ
(文字列終端のナルバイトも含めて) バイトごとにコピーするという単純な目的を持っています。


Naturally, when calling strcpy(), the programmer must take care that the bytes being 
copied don't overrun the space available in the buffer pointed by dst. The effect of 
such buffer overruns is to overwrite other parts of a process's memory, such as 
neighboring variables, with the most common result being to corrupt data or to crash 
the program.

当然のことですが、strcpy() を呼び出すときにはコピーされるバイト群が dst で示されているバッファー
の利用可能な領域をオーバーランしないようにプログラマーは注意しておかねばなりません。
そのようなバッファーオーバーランの効果はプロセスのメモリーの他の部分、たとえばすぐそばにあった
変数を上書きしてしまうというもので、最も良くある結末はデータを台無しにしてしまったり
プログラムをクラッシュさせるというものです。



If the programmer can with 100% certainty predict at compile time the size of the src 
string, then it's possible (if unwise) to preallocate a suitably sized dst buffer and 
omit any argument checks before calling strcpy(). In all other cases, the call should 
be guarded with a suitable if statement to check the size of its argument. However, 
strings (in the form of input text) are one of the ways that humans interact with 
computers, and thus quite commonly the size of the src string is controlled by the 
user of a program, not the program's creator. At that point, of course, it becomes 
essential for every call to strcpy() to be guarded by a suitable if statement:

もしプログラマーがコンパイル時に src 文字列の大きさを 100% 予測できるのなら
dst バッファに充分な大きさをあらかじめ割り当てておき、
strcpy() の呼び出し前の引数検査をすべて省略することもできます。
それ以外の場合はすべて、引数のサイズの検査を行う if 文を使って
strcpy() の呼び出しをガードすべきです。
しかしながら(入力テキストの形式としての)文字列は
one of the ways that humans interact with computers であり、
したがって、src 文字列の大きさはプログラムの作り手ではなく
プログラムのユーザーによって制御されるのが一般的なものです。
もちろんこの場合も strcpy() の全ての呼び出しを
suitable な if 文によってガードすることが重要になります。

    char dst [DST_SIZE];
    ...
    if (strlen(src) < DST_SIZE)
        strcpy(dst, src);

(The use of < rather than <= ensures that there's at least one byte extra byte 
available for the null terminator.)

(<= ではなく < を使うことで null terminator のために使える extra byte が少なくとも
一つはあることを保証します)


But it was easy for programmers to omit such checks if they were forgetful, 
inattentive, or cowboys. And later, other more attentive programmers realized that by 
carefully controlling what was written into the overflowed buffer, and overrunning 
into more exotic places such as function call return addresses stored on the stack, 
they could do much more interesting things with buffer overruns than simply crashing 
the program. (And because code tends to live a long time, and the individual 
programmers creating it can be slow to to learn about the sharp edges of the tools 
they use, even today buffer overruns remain one of the most commonly reported 
vulnerabilities in applications.)

しかしプログラマーが forgetful であったり inattentive であったり、あるいは cowboy であったときに、
そういったチェックを省略してしまうのはありがちなことです。
And later,
注意深くオーバーフローしたバッファへの書き込みを制御することによって、
スタック上に置かれている関数呼び出し時の戻り番地のようなもっと exotic な場所にオーバーラン
させることに気づいたもっと attentive なプログラマーが、
バッファーオーバーランで単にプログラムをクラッシュさせるよりもずっと
おもしろいこと (interesting things) を行えるかもしれないのです
(そしてコードは長期間生き延びる可能性があるので、
コードを作り出した個々のプログラマーは自分の使っているツールの
sharp edges について学ぶことが遅くなるかもしれませんし、
今日においてもなお、バッファーオーバーランは
報告される最も一般的なアプリケーションの脆弱性のひとつにとどまっているのです)。
#だーめだー

Improving on strcpy()
strcpy() における進歩


Prechecking the arguments of each call to strcpy() is burdensome. A seemingly obvious 
way to relieve the programmer of that task was to add an API that allowed the caller 
to inform the library function of the size of the target buffer:

strcpy() を呼び出すごとに事前にその引数を検査することは burdensome (厄介なこと、面倒なこと) です。
caller がライブラリ関数にターゲットとなるバッファーの大きさを通知する
ことを許すAPIを追加する task はプログラマーを relieve するための seemingly obvious way です


    char *strncpy(char *dst, const char *src, size_t n);

The strncpy() function is like strcpy(), but copies at most n bytes from src to dst. 
As long as n does not exceed the space allocated in dst, a buffer overrun can never 
occur.

strncpy() 関数は strcpy() に似ていますが src から dst のコピーは最大でも n バイトです。
n がdst に割り当てられたスペースよりも大きくならない限りはバッファーオーバーランは決して起きません。


Although choosing a suitable value for n ensures that strncpy() will never overrun dst, 
it turns out that strncpy() has problems of its own. Most notably, if there is no null 
terminator in the first n bytes of src, then strncpy() does not place a null 
terminator after the bytes copied to dst. If the programmer does not check for this 
event, and subsequent operations expect a null terminator to be present, then the 
program is once more vulnerable to attack. The vulnerability may be more difficult to 
exploit than a buffer overflow, but the security implications can be just as severe.

n に対する suitable value を選べば strncpy() が決して dst をオーバーランしないことは保証されますが、
strncpy() は固有の問題を抱えていることも明らかになります。
Most notably,
src の先頭から n バイトまでの間にナル終端子がなかった場合、strncpy() は dst へのコピーを行った
末尾にナル終端子を置かないのです。プログラマーがこのイベントをチェックせず、
そして後続のオペレーションがナル終端子の存在を仮定していたならば、
プログラムは攻撃に対して再度脆弱なものとなります。
この脆弱性はバッファオーバーフローよりも exploit が困難であろうものですが
the security implications can be just as severe.


One iteration of API design didn't solve the problems, but perhaps a further one can… 
Enter, strlcpy():

One iteration of API design はこの問題を解決しませんでした。
but perhaps a further one can… Enter, strlcpy():


    size_t strlcpy(char *dst, const char *src, size_t size);

strlcpy() is similar to strncpy() but copies at most size-1 bytes from src to dst, and 
always adds a null terminator following the bytes copied to dst.

strlcpy() は strncpy() と似ていますが src から dst へのコピーは最大でも size-1 バイトですし、
コピーしたdstの最後に常にnull 終端子を追加します。


Problems solved?
問題は解決したか?

strlcpy() avoids buffer overruns and ensures that the output string is null terminated. 
So why have the glibc maintainers obstinately refused to accept it?

srrlcpy() はバッファーオーバーランを avoid し、出力文字列がナル終端されていることを保証します。
ではなぜ、glibc のメンテナーたちは obstinately (頑固なまでに) に
strlcpy の accept を拒否し続けているのでしょうか?


The essence of the argument against strlcpy() is that it fixes one problem—sometimes 
failing to terminate dst in the case of strncpy(), buffer overruns in the case of 
strcpy()—while leaving another: the loss of data that occurs when the string copied 
from src to dst is truncated because it exceeds size. (In addition, there is still an 
unusual corner case where the unwary programmer can find that strlcat(), the analogous 
function for string concatenation, leaves dst without a null terminator.)

strlpcy() に対する essence of the argument は、strncpy() が dst の終端を失敗することがあるとか
strcpy() でバッファーオーバーランが置きしまうという問題を解決してはいるけれども、
もうひとつの問題を放置しているというものです。
そのもうひとつの問題というのは、src から dst へ文字列をコピーしたときにサイズが足りなくて
切り詰め(truncated) が起きたときのデータの消失 (loss) です
(In addition, there is still an unusual corner case
where the unwary programmer can find that strlcat(),
the analogous function for string concatenation,
leaves dst without a null terminator.)


At the very least, (silent) data loss is undesirable to the user of the program. At 
the worst, truncated data can lead to security issues that may be as problematic as 
buffer overruns, albeit probably harder to exploit. (One of the nicer features of 
strlcpy() and strlcat() is that their return values do at least facilitate the 
detection of truncation—if the programmer checks the return values.)

少なくとも (ひっそりと起きた) データの消失はプログラムのユーザーにとって望ましいもの
ではありませんし、
At the worst,
切り詰められたデータはバッファーオーバーランと同じくらい問題をはらんでいて、
exploit するのが難しいようなセキュリティ上の問題に繋がる可能性があります
(strlcpy() と strlcat() の nicer features の一つは
その戻り値が少なくとも facilitate the detection of truncation を行うことです。
もしプログラマーが関数の戻り値をチェックしていれば。ですが)。


All of which brings us full circle: to avoid unhappy users and security exploits, in 
the general case even a call to strlcpy() (or strlcat()) must be guarded by an if 
statement checking the arguments, if the state of the arguments can't be predicted 
with certainty in advance of the call.

All of which brings us full circle:
unhappy なユーザーを出さないためや scurity exploit を取り除くために、
一般的には strlcpy() (や strlcat()) の呼び出しに対しても
その引数の状態が後続の呼び出しでうまくいくと予期できないものかどうか検査する
if 文でガードしなければなりません。
#ぐだぐだ

Where are we now?
今わたしたちがいるのはどこ?

Today, strlcpy() and strlcat() are present on many versions of UNIX (at least Solaris, 
the BSDs, Mac OS X, and Irix), but not all of them (e.g., HP-UX and AIX). There are 
even implementations of these functions in the Linux kernel for internal use by the 
kernel code. Meanwhile, these functions are not present in glibc, and were rejected 
for inclusion in the POSIX.1-2008 standard, apparently for similar reasons to their 
rejection from glibc.

今日、strlcpy() や strlcat() は  many versions of UNIX で提供されています
(at least Solaris, the BSDs, Mac OS X, and Irix) が、
すべてのもので提供されているわけではありません (e.g., HP-UX and AIX)。
カーネルコードによって内部的に使用されている Linux カーネル向けの
これらの関数の実装すら存在しています。
Meanwhile,
これらの関数は glibc に存在していないし、
glibc から reject されたのと同様の理由によって
POSIX.1-2008 standard に含めることも reject されたのです。


Reactions among core glibc contributors on the topic of including strlcpy() and strlcat() have been
varied over the years. Christoph Hellwig's early patch was rejected in the then-primary maintainer's
inimitable style (1 and 2). But reactions from other glibc developers have been more nuanced,
indicating, for example, some willingness to accept the functions. Perhaps most insightfully, Paul
Eggert notes that even when these functions are provided (as an add-on packaged with the
application),  projects such as OpenSSH, where security is of paramount concern, still manage to 
either misuse the functions (silently truncating data) or use them unnecessarily (i.e., the
traditional strcpy() and strcat() could equally have been used without harm); such a state of
affairs does not constitute a strong argument for including the functions in glibc.

glic のコア conttributor たちの、strlcpy() や strlcat() を含むこのトピックに対する
リアクションは何年にも渡るものでした。
Christoph Hellwig の early patch は in the then-primary maintainer's inimitable style
で reject されましたが、ほかの glibc 開発者たちからのリアクションは 
もっと nuanced で、indicating なものであり、
たとえば一部の開発者はこの関数の accept に非常に好意的でした。
Perhaps most insightfully,
Paul Egger は (アプリケーションに対するアドオンパッケージとして)
strlcpy() などの関数が提供されている OpenSSH のような
セキュリティが paramount concern であるプロジェクトでさえ、
strlcpy() 関数などが間違った使われ方をして(データの切り詰めがこっそり起きて)いないかや
不必要に使っていないか
(i.e., the traditional strcpy() and strcat() could equally have been used without harm);
を監視しなければならないことに言及していました。
such a state of affairs does not constitute a strong argument for including the functions in glibc.



The appearance of an embryonic entry on this topic in the glibc FAQ, with a brief 
rationale for why these functions are currently excluded, and a note that "gcc 
-D_FORTIFY_SOURCE" can catch many of the errors that strlcpy() and strlcat() were 
designed to catch, would appear to be something of a final word on the topic. Those 
that still feel that these functions should be in glibc will have to make do with the 
implementations provided in libbsd for now.

The appearance of an embryonic entry on this topic in the glibc FAQ,
with a brief rationale for why these functions are currently excluded,
and a note that
"gcc -D_FORTIFY_SOURCE" は strlcpy() や strlcat() が捕捉するように設計されたエラーの
多くを見つけ出すことが可能であり、
would appear to be something of a final word on the topic.
Those that still feel
that these functions should be in glibc will have to make do with
the implementations provided in libbsd for now.
これらの関数は glibc に置かれるべき
現在は libbsd で実装が提供されている


Finally, in case it isn't obvious by now, it should of course be noted that the root 
of this problem lies in the C language itself. C's native strings are not managed 
strings of the style natively provided in more modern languages such as Java, Go, and 
D. In other words, C's strings have no notion of bounds checking (or dynamically 
adjusting a string's boundary) built into the type itself. Thus, when using C's native 
string type, the programmer can never entirely avoid the task of checking string sizes 
when strings are manipulated, and no replacements for strcpy() and strcat() will ever 
remove that need. One might even wonder if the original C library implementers were 
clever enough to realize from the start that strcpy() and strcat() were sufficient—if 
it weren't for the fact that they also gave us gets().

Finally, in case it isn't obvious by now,
もちろん、この問題の根本原因が C という言語そのものにあることに注意すべきです。
C の native 文字列は、Java や Go、D のようなより modern な言語が natively に
提供している形式である managed 文字列ではありません。
言い換えれば、C の文字列は型自身に組み込まれている境界検査の option
(や文字列境界の dynamically adjustingy) を持っていません。
したがってC の native 文字列型を使う場合には、プログラマーは文字列を操作するときの文字列サイズの
task of checking を完全に排除することはできませんし、
no replacements for strcpy() and strcat() will ever remove that need.
元々の C のライブラリでの実装が、最初から strlcpy() や strlcat() が sufficient
であることを認識するほど十分 clever なものでなかったのはなぜだろうと
不思議に思う人もいるでしょう。
if it weren't for the fact that they also gave us gets().
―



Copyright © 2012, Eklektix, Inc.

かなりぐだぐだになってしまった。 あとちょっとだけ手を入れる。 かもしれない。

■_

reddit での反応

snprintf の「仕様」の違いは ruby でもちょっと引っかかってた覚えが 

The ups and downs of strlcpy() : programming

Just use snprintf instead. Portable, have to remember less string functions, and always null-terminates.



Not if your definition of "portable" includes such non-UNIXes as Windows, sadly. snprintf
doesn't null-terminate on overflow there for some reason, they provide snprintf_s which calls an
error handler or truncates the string properly depending on the additional parameter value.

Also, C strings are fundamentally flawed, so you'd be better off using C++ or emulating C++ strings
in C.



    Also, C strings are fundamentally flawed, so you'd be better off using C++ or emulating C++ strings in C.

I'd recommend bstring.



I'm also a fan of a asprintf where appropriate.



anyone have any experiences with -D_FORTIFY_SOURCE? I tend to use snprintf when I have to, but in
general I'm hardly ever in a position to manipulate strings in C.



Ubuntu (and Debian as well, I believe) patch gcc to make -D_FORTIFY_SOURCE=2 the default. It's been
that way for a while -- about 4 years, starting with 8.10 -- so quite a bit of code has been built
with it enabled. I believe it was designed to be relatively low overhead so that having it enabled
by default would be feasible.



We recently had a sudo security vulnerability which was in Debian but not possible in Fedora since
they use _FORTIFY_SOURCE=2 by default and thus in sudo as well.



The most dangerous part of strlcpy/strlcat is the return value. To try and detect incomplete copies,
it runs over the entire length of the source string. (see the while(*s++); part from the function's
source code)

Say you are tokenizing a 10MB XML or CSV file. Every time you used strlcpy() to move a chunk from the
source string to the token string, it would run through the rest of the source string. Thus,
tokenizing the entire document would effectively result in O( n2 ) overhead. If you tokenized every
~10 bytes, that would be 5,000,000,000,000 terminator checks. (10MB/2 * 10M/10)

strncpy has a similar problem, where it fills the target buffer with nulls after the source string is
exhausted. Plus its other faults like potentially not null-terminating the target string at all and
such.

I've been trying to promote my workaround to both of these issues, strmcpy and strmcat. No need to
fight about getting it into a standard. Just stick it in your source file directly.

  //return = strlen(target)
  inline size_t strmcpy(char *target, const char *source, size_t length) {
      const char *origin = target;
      if(length) { while(*source && --length) *target++ = *source++; *target = 0; }
      return target - origin;
  }

  //return = strlen(target)
  inline size_t strmcat(char *target, const char *source, size_t length) {
      const char *origin = target;
      while(*target && length) { target++; length--; }
      return (target - origin) + strmcpy(target, source, length);
  }

(Code condensed for posting purposes. Code is ISC or public domain, your choice.)

略 


    Christoph Hellwig's early patch was rejected in the then-primary maintainer's inimitable style.

This must be the most polite description of Ulrich Drepper I've ever heard.



is this not what the _s suffixed functions are for in C11.

strlcpy/strlcat の危険性云々って確か訳したはずだけど ここに載せたっけか

2012年07月25日

■_

ビッグコミック無印に連載の「星を継ぐもの」が次回で最終回とか。 この雑誌ともお別れかなあ(他に読んでいるものもあるけど)

■_ Undefined Behavior Consequences Contest Winners

ちょっと前に参加を募っていたのを見たような気がするんですが結果発表が Undefined behavior in C: contest winners : programming 

Embedded in Academia : Undefined Behavior Consequences Contest Winners

Undefined Behavior Consequences Contest Winners

The contest that I posted the other day received some very nice entries. I decided to pick multiple
winners since the best entries illustrate consequences of several kinds of undefined behavior.

First, here's the runner up, submitted by Octoploid:

  int main (void) {
      int x = 1;
      while (x) x <<= 1;
      return x;
  }

This program is undefined by C99, where signed left shifts must not push a 1 bit into or past the sign
bit. Recent GCC versions such as r189449 for x86-64 on Linux compile this program into an infinite
loop at -O2 and higher. This entry is great because in general, compiler developers have been very
reluctant to start enforcing the very strict rules for signed left shift in C99. On the other hand,
GCC still performs this optimization when asked to compile in C89 mode, where I don't think the
behavior is undefined. Based on that observation, I filed a GCC bug report. One of the main GCC
developers, Joseph Myers, replied with this:

このプログラムは C99 では未定義です。なぜなら、signed の左シフトでは
1 のビットをシフトの結果符号ビットに入れたりしてはいけないからです。
x86-64 on Linux 向けの r189449 のような最近のGCC ではこのプログラムは
-O2 以上の指定でコンパイルしたときに無限ループとなります。


    Shifts in GCC are supposed to be defined as long as the shift amount is in range, independent of
    the LHS, so it should not be folding like that. (Although we document in implement-c.texi that this
    is subject to change for signed left shift, I don't think changing it would be a particularly good
    idea.)

    GCC におけるシフト演算では、LHS とは無関係にシフト量が一定の範囲に収まっているように定義されていると
    仮定しています。ですからそこでfoldingをすべきではありません

I think it is great to see compiler developers taking this kind of a stand against exploiting certain
undefined behaviors. Anyway, although the matter has not yet been completely resolved, and the
optimization is perfectly valid in C99, it seems that the developers will back out this transformation.
So, while I find this example to be very interesting, it does not seem like a contest winner.

Winner #1

Amonakov submitted this code:

  enum {N = 32};
  int a[N], pfx[N];
  void prefix_sum (void)
  {
      int i, accum;
      for (i = 0, accum = a[0]; i < N; i++, accum += a[i])
          pfx[i] = accum;
  }

This function forms a bit of an argument against the very terse style of for-loop afforded by C
which (in my opinion) makes the undefined behavior harder to see than it might otherwise have been.
The undefined operation here is reading a[32]. Recent versions of GCC, apparently as a consequence,
decide that the loop exit test can be removed, giving an infinite loop that triggers a segfault when
i becomes large enough.

この関数は未定義動作を気がつきにくいものにする簡単な形式の for ループを使っています
#無理矢理
このプログラムでの未定義操作は a[32] の読み込みです。
GCC の最近のバージョンでは、apparently as a consequence,
ループの脱出検査は削除できると判断し、
結果として i の値が十分大きくなったときに segfault を引き起こす無限ループを作ります。


Winner #2

Nick Lewycky submitted this code:
	
  #include <stdio.h>
  #include <stdlib.h>
 
  int main() {
      int *p = (int*)malloc(sizeof(int));
      int *q = (int*)realloc(p, sizeof(int));
      *p = 1;
      *q = 2;
      if (p == q)
          printf("%d %d\n", *p, *q);
  }

Using a recent version of Clang (r160635 for x86-64 on Linux):
Clang の最近のバージョンを使った場合こうなります

    $ clang -O realloc.c ; ./a.out 
    1 2

To see the undefined behavior, you need to read the fine print in the C99 standard, which says:
この未定義動作を理解するには、C99 標準の fine print を読む必要があります。
そこにはこうあります

    The realloc function deallocates the old object pointed to by ptr and returns a pointer to a
    new object that has the size specified by size.

    realloc 函数は ptr によって指し示された古いオブジェクトを deallocate し、
    指定されたサイズをもった新しいオブジェクトへのポインターを返します。

In other words, it is an error to use a pointer after it has been passed as an argument to realloc.
This particular bit of language does not appear in the ANSI C standard and the situation there is
more ambiguous. However, reading between the lines in A.6.2, I believe we can infer that this code
was intended to be undefined in C89 as well.

言い換えると、realloc に引数として渡したポインターを関数呼び出しのあとで使うことはエラーなのです。
この paricular bit of language は ANSI C 標準には見あたらず、
このようなシチュエーションはさらに曖昧なものとなっています。
しかしながら、A.6.2 の行間を読むと、C89 でもこのコードは未定義になるように考えられていると
推測できるとわたしは確信しています。


The man pages for realloc() that I looked at do not mention or imply this caveat. If a major compiler
is going to exploit this behavior, the documentation must be updated.

わたしがみた realloc() の man ページにはこのことに対する言及などはありませんでした。
もしメジャーなコンパイラーがこの振る舞いを exploit しようとしたなら
ドキュメントを更新しなければなりません。

Conclusion
結論

I chose these winners because in each case there is an element of surprise. In other words, I would
not have guessed that the compiler would exploit these particular undefined behaviors, even after I
understood the program or program fragment completely. An entry submitted by Pascal Cuoq, which is
otherwise very interesting, fails this test—I would have expected a modern C compiler to exploit
those undefined behaviors.

■_ Looking for a stable language?

プログラミング言語の選択で。 原文にはリンクがありますのでできればそちらも (反映させるの面倒だったw)。 

Looking for a stable language?

Looking for a stable language?

Do you want to be sure that when you upgrade any upstream stuff your code does not break?

アップグレードしたときに自分の書いたコードが動かなくなったりしないようにしたいですか?

No matter what changes, right?

何が変わったのかは問題ではありません

Starting from the hardware, through the operating system, the the back-end database, down to the
smallest function of the smallest CPAN module your code depends on.

ハードウェアに始まり、オペレーティングシステム、バックエンドのデータベース、
あなたの書いたコードが依存している最小のCPANモジュールの最小の函数に到るまで

You just want to be sure everything works.

あなたはなにもかもが確実に動くことを望んでいるだけです。

I totally understand you. After all who wants to see her code broken by some upstream change?

Upstream changes happen all the time. Some are backward compatible. Some are not.
アップストリームの変更はいつでも起こります。
一部の変更は後方互換が保たれているでしょうし、そうでないものもあるでしょう。

Python

Have you already upgraded to Python 3000? Why not?

もう Python 3000にアップグレードしてますよね? なぜしないんです?

Ruby

Just check out the backward compability matrix on is it Ruby 1.9.
Ruby 1.9 の後方互換マトリクスでチェックしましょう


PHP

Backward Incompatible Changes between PHP 5.2 and 5.3.

PHP 5.2 と 5.3 の間には非互換な変更があります

Perl 5

Have you used Pseudo Hash-es when they were hip? Have you ever relied on the order the keys()
function returns the keys? Just two thing that could have caused you headaches.

Perl 6

The question, how well can Rakudo handle backward compability?

さて、Rakudo はどのくらい後方互換性を handle できているでしょうか?

No, the question was how should Rakudo manage breakages across versions and instead of trying to
give an answer Anonymous Monk went off discussing the meaning of the word stable and backward
compability. No surprise he wanted to say Anonymous.

Of course Rakudo is still changing more frequently and drastically than the above languages. You
probably should not yet build a business upon it, but you can already start to start building web
sites and smaller applications. You can start porting libraries.

So

How to make sure that changes don't hurt much?

I know only one magic bullet. Write lots of tests. When you upgrade something in your 
upstream - regardless if that is the hardware, the compiler or a minor library - the 
only way to ensure that things still work is to test them.

It could be done manually but that's probably a waste of time. That's why you should 
write test.

Which reminds me to quote what I wrote in the latest edition of the Perl Weekly:

I think the story Buddy Burden shares with us is one of the best ways to explain how 
testing in general, and TDD in particular can improve your health. I really mean it.

Conclusion

If you are looking for language that does not change, try Latin. Other than that it's 
up to you. If you are ok with some extra work in exchange of some fun and building 
something new then check out Rakudo.

If you'd like to read articles about Perl 6, check out my new site.

■_

でましたね

■_

2012年07月24日

■_

夏コミの巡回リストを作成ちゅー

■_

■_

やる気ーゼロー

中途半端な状態で放置しているのが幾つもあるんだけどねえ

Introducing Regular Expressions - O'Reilly Media お、買えるようになってる?

翻訳本でないかなーと思ってるもの。 電書で買ってて読み進めてはいるんですけどね (Driving～の方は紙の本も買ってる) The Pragmatic Bookshelf | The Developer's Code The Pragmatic Bookshelf | Driving Technical Change

2012年07月23日

■_

なんというか、Fortress にしても New Programming Jargon にしても 土曜日(上げたのは日曜早朝ですが)にはネタにしてたのに以下略でしょんぼり。

よゆーねー

■_ C を拡張

ユーザー登録をしないとスライドの表紙以外のページを見られないような 感じもしますが結構これ面白かったです。 mbeddr C: An Extensible Version of the C Programming Language for Embedded Programming この種の、動画データが貼り付けてあるアーティクル(でいいのかな)は 残念ながら日本語版に翻訳されて掲載されることはないと思うのでがんばって視聴してください:) ユーザー登録すると、上の方にちっちゃくリンクのある 音声データ(mp3) や スライド(pdf) がダウンロードできるようになります。

■_

■_

xmlgawk やらいじりたいんだけどおおおおお

2012年07月22日

■_

チャンピオンRED連載のジャイアントロボ(副題略)にあの方々が。 まあ(彼らとは別の)あの方はアニメの方(地球が静止する日)にもでてきたし、 この連載でも(さらにまた別の)あの人でたしねえ。

傘袋あるじゃないですか雨の日に良く使われる(使わされる)アレ。 わたしは結構大きな傘(半径だか軸の長さが 70cm)を使っているのですが まず傘本体を収めきらない。たまに先端を破ることもあるし、 袋の開け口がひっついてて苦戦するのもイライラすることこの上ない。 あと、あの傘袋折りたたみ傘を使ってる人にも不親切ですよね。 傘を差し込むと傘袋に入る機械(なんという名前だろアレ)が置かれているとなんとなくうれしい。 さらにあれだ傘袋の材質(省略されました)

石丸電気がエディオンに名称変更されるらしいんですが、 最近できたあのマスコットキャラクターどーすんですかね。 名前に「石丸」って入ってるし。 などということを石丸電気のあの唄が流れる店内で考えてみたり。

■_ numpy

Amazon.com: NumPy 1.5 Beginner's Guide (9781849515306): Ivan Idris: Books のコメントを見てみるとこんなのが 

Amazon.com: NumPy 1.5 Beginner's Guide (9781849515306): Ivan Idris: Books

Kindle edition has formatting problems January 24, 2012

By Patrick McMahon

Format:Kindle Edition|Amazon Verified Purchase

The Kindle edition left justifies all the code listings with none of the indentation of loops,
functions, etc., shown in the print edition and required in NumPy and Python. Multi-dimensional
arrays, which are well laid out in the print edition, are also left justified and difficult to
follow. Stick with the print edition.

…これはひどい。 今でも直ってないんだろか。

■_

2012年07月21日

■_

Amazon.co.jp： 世界でもっとも強力な9のアルゴリズム: ジョン・マコーミック, 長尾高弘: 本 買った。 いつ読むかはわからない(笑) ただこのタイトル、～9個のアルゴリズム とか ～九つのアルゴリズムとした方が良い気も。 数が大きいとそうでもないんだけどなんか違和感(個人的な印象です)が。

コミケカタログ。 DVD-ROM板を購入。二日目と三日目かなあ。しかし昨年は二日目だけでダウンしたんだよなw

■_

■_

まつもとさんが↓に言及してたはずなんだけど見つけられなかった (あまり一生懸命探さなかったせい)

んでまあ「先を見越して設計」は YAGNI って警告もあるし、難しいんじゃないすかね。 もちろん完全無視していいものではないだろうけど(玉虫色)

■_

Coding Horror: New Programming Jargon イラストもあるので元記事をどぞ。 

Coding Horror: New Programming Jargon

Consider this question from two years ago:

    New programming jargon you coined?

    What programming terms have you coined that have taken off in your own circles (i.e. have heard
    others repeat it)? It might be within your own team, workplace or garnered greater popularity
    on the Internet.

    Write your programming term, word or phrase in bold text followed by an explanation, citation
    and/or usage example so we can use it in appropriate context.

    Don't repeat common jargon already ingrained in the programming culture like: kludge,
    automagically, cruft, etc. (unless you coined it).

    This question serves in the spirit of communication among programmers through sharing of
    terminology with each other, to benefit us by its propagation within our own teams and
    environments.

Is this even a question, really? How many answers does it have?

以下略

最初のほうのいくつかは見覚えがあるものだったので古い記事かなと思ったんだけど、 更新日を見るとそうではなかった。 で、反響 → New Programming Jargon (from Coding Horror) : programming New Programming Jargon | Hacker News

■_ QAST

ここんとこ Perl 6の情報もまじめに追いかけてなかったり (一応 RSS にひっかかってはくる) 

The Rakudo move to QAST: progressing nicely | 6guts

The Rakudo move to QAST: progressing nicely

Posted on July 20, 2012

It's been a little while since I wrote anything here. After all the work getting the new regex
engine bootstrapped and alternations having longest token matching semantics, I've been taking
things just a little bit easier. Only a little bit though…things have still been moving along
nicely. :-)

My current focus is on getting Rakudo switched over to QAST, our refreshed abstract syntax tree
design and implementation. What is an AST, you may wonder? Basically, it's just a tree representation
of the behavior of a program. As we parse programs in Perl 6, the grammar engine builds a parse tree.
This is very tied to the syntax of the program, whereas an AST is all about semantics. A chunk of
code known as the actions transforms pieces of the parse tree into an abstract syntax tree. Not all
elements of your program are represented in the AST, however. Declarations are handled differently, 
through a mechanism called the world. If you pre-compile a module, the declarative bits are
serialized; the AST, on the other hand, represents things that will actually run, so it needs to be
turned into code for the target runtime.

略

抽象構文木を変える?

■_ Fortress

音沙汰ないなあと思ったらこんなことに 

Fortress Wrapping Up (Project Fortress)

Fortress Wrapping Up
By gls on Jul 20, 2012

After working nearly a decade on the design, development, and implementation of the Fortress
programming language, the Oracle Labs Programming Language Research Group is now winding down the
Fortress project. Ten years is a remarkably long run for an industrial research project (one to
three years is much more typical), but we feel that our extended effort has been worthwhile. Many
aspects of the Fortress design were novel, and we learned a great deal from building an interpreter
and an initial set of libraries. Nevertheless, over the last few years, as we have focused on
implementing a compiler targeted to the Java Virtual Machine, we encountered some severe technical 
challenges having to do with the mismatch between the (rather ambitious) Fortress type system and a
virtual machine not designed to support it (that would be every currently available VM, not just
JVM). In addressing these challenges, we learned a lot about the implications of the Fortress type
system for the implementation of symmetric multimethod dispatch, and have concluded that we are now
unlikely to learn more (in a research sense) from completing the implementation of Fortress for JVM.
We also note that, over the last ten years, other languages (Chapel, X10, Clojure, and Scala, among 
others) have explored some of the same issues that Fortress has addressed, and we have very much
enjoyed conversations, collaboration, and friendly competition with those who have explored these
ideas in alternative contexts.

プログラミング言語 Fortress の設計や開発、実装に十年ほど費やした後、
Oracle Labs Programming Language Research Group はこの Fortress プロジェクトの終了をさせようと
しています。十年は industrial な研究プロジェクトにはかなり長期のものですが
(典型的なものは一年から三年ほどです)、わたしたちは自分たちの extended effort が十分価値のある
ものであったと感じています。Fortless の設計についての aspects の多くは目新しいものであったし、
わたしたちは (Fortress の) インタープリターやライブラリの initail set の構築から多くのことを学びました。
にもかかわらず、最近二年ほどはコンパイラー実装のターゲットを Java Virtual Machine にフォーカス
したことに見られるように、(かなり野心的であった) Fortress の型システムとそれをサポートすることを
考慮されていない設計のバーチャルマシン (that would be every currently available VM, not just JVM)
とのミスマッチに対処しなければならないなどいくつかの technical challenge にわたしたちは遭遇していました。
それらの challenge に対応するなかで、わたしたちは
symmetric なマルチメソッドディスパッチの実装のための
Fortress の型システムの implications について多くを学びました。
そして、Forress for JVM の実装の完了からはこれ以上学ぶものは(研究という意味において)ない
という結論に達したのです。
略


The Fortress source code remains open-source, and the code repository will remain available for the
foreseeable future to those who wish to work on it. The Programming Language Research Group will
continue to respond to inquiries about Fortress (and requests for minor bug fixes as we can). We not
do not plan to cease work on Fortress suddenly, but will spend the next few months getting the code
and language specification into the best shape that we can. We also plan to write several academic 
papers about various aspects of the Fortress design and implementation technology. Going forward,
we will look for opportunities to apply lessons learned and to transfer Fortress-related technology
to other projects.

Fortress のソースコードはオープンソースのままですし、コードリポジトリも当分の間は
それでなにかをしたいという人のために利用可能にされるでしょう。
Programming Language Research Group は Fortress についての問い合わせには
答え続けます(また、可能であれば minor bug の fix の要望についても)。


(略)

Here are some of the aspects of Fortress with which we are quite pleased, with commentary:

(略)


We thank you for YOUR interest in Fortress, and hope that you will be similarly interested in our
future efforts in other areas.

—Guy Steele, for the Oracle Labs Programming Language Research Group

reddit での反応 → Fortress Wrapping Up : programming

一つ前へ 2012年7月(中旬)
一つ後へ 2012年8月(上旬)

ホームへ

リンクはご自由にどうぞ

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