■_
読んだ。
何週間かぶりに神保町の明倫館書店 (明倫館書店 店舗のご案内) に行った。 欲しいと思った本が何冊かあったんだけどなかなか。 次に行ったときはもうないだろうなあ。
・今月の皇帝陛下
アルプス越え。でもこのあたりのエピソード軽く流す感じだなあ。
保証と保障の使い分けが間違ってるのを見るととても気になる。 まあ自分もあまり自信がなかったりするのだけど。
2011年04月29日
■_
Hasekll 本を買ったの何冊目だ
5月半ばのお届けになってたはずなのになぜ。
まあ早くなる分にはいいんですが。
■_ locale
某所でも locale に絡んでいろいろあったようですが。
Case insensitivity seems to ignore lower bound of interval From: Eric Bischoff Subject: Case insensitivity seems to ignore lower bound of interval Date: Tue, 26 Apr 2011 17:27:49 +0200 Hi all, $ echo "ijklmnopqrstuvwxyz" | awk '{ gsub(/[R-Z}/, "X"); print } ijklmnopqrXXXXXXXX please notice that "r" is not matched, i.e. case insensitivity is applied only to [S-Z] interval. $ awk --version GNU Awk 3.1.7 (...) $ echo $LANG fr_FR.UTF-8 The problem does not appear when locale is C. The problem does not appear when interval is specified as [r-z] (lower case).. This contradicts http://www.gnu.org/software/gawk/manual/gawk.html#Locales which documents $ echo something1234abc | gawk '{ sub("[A-Z]*$", ""); print }' as returning something1234 while it returns something1234a Bug reproduced both on Ubuntu Natty beta 2 and on Fedora 15. I hope that helps,
とまあ、[R-Z] という範囲指定なのに、なんで小文字の s から z までが ひっかかってるんじゃ。という事情を知っている人にとってはまたかという話題。
Re: Case insensitivity seems to ignore lower bound of interval From: Davide Brini Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Tue, 26 Apr 2011 18:49:27 +0100 (引用部略) This is not a bug but expected behavior (not that I agree, but that's the way it is). The executive summary is that many non-C locales have different collation orders (mostly dictionary order, regardless of case). In those locales, an expression like [R-Z] may match (at least) "RsStTuUvVwWxXyYzZ", plus perhaps any other character that sorts between them (note that the above does not include "r"). Similarly for other range expressions. To work around, either use LC_ALL=C to get plain ASCII orgering, or use [[:upper:]] or [[:lower:]] etc. as appropriate, or if using partial ranges, make it explicit eg [RSTUVWXYZ].
Re: Case insensitivity seems to ignore lower bound of interval From: Aharon Robbins Date: Wed, 27 Apr 2011 21:48:41 +0300 Greetings. Re the below. First, thank you for the bug report. Second, it's not a bug, but rather the consequence of how locales behave. This is documented somewhat in the released gawk manual and documented better in the upcoming one. I do agree that the behavior is suprising, disconcerting, undesirable, and so on. For this reason, the upcoming version of gawk translates ranges of the form [d-h] into '[defgh]' before compiling the regular expression. You can check out the development version from the git repository on savannah.gnu.org, if you like, to try it. Thanks, Arnold
Re: Case insensitivity seems to ignore lower bound of interval From: John Cowan Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Wed, 27 Apr 2011 16:40:21 -0400 Aharon Robbins scripsit: > I do agree that the behavior is suprising, disconcerting, undesirable, > and so on. For this reason, the upcoming version of gawk translates > ranges of the form [d-h] into '[defgh]' before compiling the regular > expression. Alas, that means that in a locale where e-acute sorts after e, the regex [d-h] will not match it. You can't have everything at once, but it would be good to have a switch to turn this behavior on and off.
Re: Case insensitivity seems to ignore lower bound of interval From: Eric Blake Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Wed, 27 Apr 2011 14:55:49 -0600 (引用部略) POSIX already states that the regex [d-h] is unspecified in all but the C locale, because there is no one-size-fits-all intepretation of what it _should_ represent. If you want e-acute in the set, it is always better to ask for it explicitly. Meanwhile, I welcome this change, as it is easier to document that the expansion always mirrors the C locale rather than the expansion depends on the collation order of the current locale. -- Eric Blake address@hidden +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: Case insensitivity seems to ignore lower bound of interval From: Eric Bischoff Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Thu, 28 Apr 2011 06:06:37 +0200 (引用部略) Hi Aharon, First, thank you for your kind answer. I am really sorry, but I think you did not read my bug report accurately. It looks like you gave the answer to another question than the one I asked. What you are answering here is a Frequently Asked Question about un undesired behaviour of the locales, but this is not what I am speaking about. What I am speaking about is not documented. On the contrary, I showed you where the behaviour contradicts the documentation. Let me restate my bug report, perhaps it was not clear enough. 1) Contradiction with the documentation : http://www.gnu.org/software/gawk/manual/gawk.html#Locales says that $ echo something1234abc | gawk '{ sub("[A-Z]*$", ""); print }' returns something1234 while it returns something1234a Please notice the *a* at the end. That's what this bug report is about. This "a" has no reason to appear. 2) Another way to reproduce : $ echo "ijklmnopqrstuvwxyz" | awk '{ gsub(/[R-Z}/, "X"); print } ijklmnopqrXXXXXXXX Please notice the "r". Why does the "r" not be changed into "X", while "s", "t", "u", "v", "w", "x", "y", "z" do? I think this is a real bug. The fact that the locales are taken into account in the intervals is indeed questionable, but is another topic. Sorry to be insisting. I still hope that helps. -- Éric Bischoff - Bureau Cornavin Technical writing and translations http://www.bureau-cornavin.com
まあ locale の問題だからとだけ言われても納得いきませんわなw
Re: Case insensitivity seems to ignore lower bound of interval From: Paul Jarc Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Thu, 28 Apr 2011 00:17:07 -0400 That example behaves as described in the documentation for some locales, but not in others (such as yours, apparently). That's the whole point of that section of the documentation--different locales have different behavior for character ranges. Note that case-insensitivity is not an intended feature at all. It's just an accidental result of the character collation of some locales. Some locales arrange characters in the order aAbBcC...zZ, so a range like [A-Z] includes all upper- and lowercase letters except lowercase a. Other locales may arrange them as AaBbCc...Zz, so [A-Z] excludes lowercase z instead. But the usual expectation, and the actual behavior in the C locale, is that [A-Z] includes only uppercase letters, and [a-z] includes only lowercase letters. paul
Re: Case insensitivity seems to ignore lower bound of interval From: Eric Bischoff Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Thu, 28 Apr 2011 07:32:18 +0200 (引用部略) Oh, ok, now I understand, then the problem is that [R-Z] evaluates either as RrSsTtUuVvWwXxYyZz or as rRsStTuUvVwWxXyYzZ (引用部略) OK. Thanks for explanation, now I get it. But there is still something deeply wrong here. My understanding of the word "collation" is : "A", "a", and "à" are "equivalent"with respect to alphabetical order It is not : "A", "a" and "à" are "next to each other" in alphabetical order. Current situation is : a < à < A < b < B < c < C ... while it should be : a = à = A < b = B < c = C ... My two cents. -- Éric Bischoff - Bureau Cornavin Technical writing and translations http://www.bureau-cornavin.com
Re: Case insensitivity seems to ignore lower bound of interval From: John Cowan Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Thu, 28 Apr 2011 01:59:02 -0400 Eric Bischoff scripsit: > My understanding of the word "collation" is : > "A", "a", and "à" are "equivalent"with respect to alphabetical order > It is not : > "A", "a" and "à" are "next to each other" in alphabetical order. Proper collation algorithms do work this way: differences in letters are most important, but if they are equal, accents are looked at, and if *they* are equal, case is looked at. But that's not the way strcmp() works in C, unfortunately; the best approximation available to case-blindness is to sort b either before or after B.
Re: Case insensitivity seems to ignore lower bound of interval From: Eric Bischoff Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Thu, 28 Apr 2011 09:38:55 +0200 Le jeudi 28 avril 2011 07:59:02, John Cowan a écrit : (略) > Proper collation algorithms do work this way: differences in letters > are most important, but if they are equal, accents are looked at, and > if *they* are equal, case is looked at. Yes, that's more or less what I described as the correct algorithm. But you are right, there are three stages of comparaison, not two. > But that's not the way > strcmp() works in C, unfortunately; the best approximation available > to case-blindness is to sort b either before or after B. Then it's using strcmp() that is plain wrong :-(. -- Éric Bischoff - Bureau Cornavin Technical writing and translations http://www.bureau-cornavin.com
Re: Case insensitivity seems to ignore lower bound of interval From: arnold Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Thu, 28 Apr 2011 08:28:01 GMT Hi. > > But that's not the way > > strcmp() works in C, unfortunately; the best approximation available > > to case-blindness is to sort b either before or after B. > > Then it's using strcmp() that is plain wrong :-(. Gawk does not use strcmp() for regex matching. (You may not have been saying that it did, I admit.) The issue is indeed as described in the previous mails, and the development version of the gawk doc explains these issues considerably better. I recommend checking out a copy from the git repo on savannah.gnu.org and reviewing the doc; I will welcome feedback on it! Thanks, Arnold
Re: Case insensitivity seems to ignore lower bound of interval Re: Case insensitivity seems to ignore lower bound of interval From: Eric Bischoff Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Thu, 28 Apr 2011 12:21:37 +0200 Le jeudi 28 avril 2011 12:00:33, vous avez écrit : > You seem to think this is gawk-specific, but in fact any locale-aware tool > that uses regular expressions behaves the same (try eg with sed or grep). Not here: $ echo 'ijklmnopqrstuvwxyz'| sed 's/[r-z]/X/g' ijklmnopqXXXXXXXXX $ echo 'ijklmnopqrstuvwxyz'| sed 's/[R-Z]/X/g' ijklmnopqrstuvwxyz $ echo 'ijklmnopqrstuvwxyz'| awk '{gsub("[r-z]", "X"); print}' ijklmnopqXXXXXXXXX $ echo 'ijklmnopqrstuvwxyz'| awk '{gsub("[R-Z]", "X"); print}' ijklmnopqrXXXXXXXX $ echo 'ijklmnopqr'| grep "[r-z]" ijklmnopqr $ echo 'ijklmnopqr'| grep "[R-Z]" $ awk --version | head -n 1 GNU Awk 3.1.7 $ sed --version | head -n 1 GNU sed version 4.2.1 $ grep --version | head -n 1 GNU grep 2.6.3 Those results were predictable for sed and grep, not for awk. Furthermore, they are inconsistent between awk and sed. -- Éric Bischoff - Bureau Cornavin Technical writing and translations http://www.bureau-cornavin.com
Re: Case insensitivity seems to ignore lower bound of interval From: Davide Brini Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Thu, 28 Apr 2011 11:43:52 +0100 On Thu, 28 Apr 2011 12:21:37 +0200 Eric Bischoff <address@hidden> wrote: > Le jeudi 28 avril 2011 12:00:33, vous avez écrit : > > You seem to think this is gawk-specific, but in fact any locale-aware > > tool that uses regular expressions behaves the same (try eg with sed or > > grep). > > Not here: > > $ echo 'ijklmnopqrstuvwxyz'| sed 's/[r-z]/X/g' > ijklmnopqXXXXXXXXX > $ echo 'ijklmnopqrstuvwxyz'| sed 's/[R-Z]/X/g' > ijklmnopqrstuvwxyz This is strange, since with GNU sed 4.2.1 I get $ echo 'ijklmnopqrstuvwxyz'| sed 's/[R-Z]/X/g' ijklmnopqrXXXXXXXX And this shows the converse: $ echo 'IJKLMNOPQRSTUVWXYZ' | sed 's/[r-z]/_/g' IJKLMNOPQ________Z ("[r-z]" does not include "Z", because of ... vVwWxXyYzZ) I get the above results with all the UTF-8 locales I can try on this box (admittedly, not too many). > $ echo 'ijklmnopqrstuvwxyz'| awk '{gsub("[r-z]", "X"); print}' > ijklmnopqXXXXXXXXX > $ echo 'ijklmnopqrstuvwxyz'| awk '{gsub("[R-Z]", "X"); print}' > ijklmnopqrXXXXXXXX Same here. > $ echo 'ijklmnopqr'| grep "[r-z]" > ijklmnopqr > $ echo 'ijklmnopqr'| grep "[R-Z]" This is expected, since "[R-Z]" does NOT match "r" in the locales under discussion. But nonetheless, you are right that grep seems to behave differently, although I was almost sure I had seen it show the same behavior at some point; I may be misremembering. Furthermore, the above is in direct contradiction to grep's documentation, which states "Within a bracket expression, a "range expression" consists of two characters separated by a hyphen. It matches any single character that sorts between the two characters, inclusive, using the locale's collating sequence and character set. For example, in the default C locale, `[a-d]' is equivalent to `[abcd]'. Many locales sort characters in dictionary order, and in these locales `[a-d]' is typically not equivalent to `[abcd]'; it might be equivalent to `[aBbCcDd]', for example. To obtain the traditional interpretation of bracket expressions, you can use the `C' locale by setting the `LC_ALL' environment variable to the value `C'". So I would definitely expect grep to follow awk's and sed's behavior. For further thought, "sort" is another command whose collating order is affected by the locale ("consistently", so to speak, with awk and sed). $ printf '%s\n' A b Z | sort A b Z $ printf '%s\n' A b Z | LC_ALL=C sort A Z b -- D.
Re: Case insensitivity seems to ignore lower bound of interval From: Eric Bischoff Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Thu, 28 Apr 2011 15:12:14 +0200 Le jeudi 28 avril 2011 14:04:28, Davide Brini a écrit : > But you got me curious. My original test system used mostly vanilla tools > built from source, so I thought I would try on stock distros instead. > And guess what, both on a standard RHEL 6 and Debian squeeze, I see your > results (ie gawk behaves differently). OK, that's interesting information. That means that either those distributions patch the tools, either there's some compilation option that differs. I have tested 6 stock distros too, all with the same behaviour forgawk (I have not tested sed nor grep yet). > Maybe, but my point was that it was no gawk-only bug. But now, having been > able to reproduce your results, it may well be that gawk does something > different. Arnold is the authoritative source here. Yes, and let me take the occasion to thank him for all the great work on gawk and the nice documentation. (略) > The only way you would get > output is if [R-Z] was implemented as "RrSs..." etc., which seems not to > be the case; rather, it seems to be the other way round ("rRsS..." etc.). Correct. Ah, you were right, grep behaves as awk on this, I did not test thoroughly enough: $ echo 'ijklmnopqs' | grep '[R-Z]' ijklmnopqs $ echo 'ijklmnopqr' | grep '[R-Z]' $ $ echo 'ijklmnopqs' | awk '/[R-Z]/ { print }' ijklmnopqs $ echo 'ijklmnopqr' | awk '/[R-Z]/ { print }' $ That does not make it more logical :-), and sed is definitely different: $ echo 'ijklmnopqs' | sed '/[R-Z]/p' ijklmnopqs $ echo 'ijklmnopqr' | sed '/[R-Z]/p' ijklmnopqr $ echo 'ijklmnopqR' | sed '/[R-Z]/p' ijklmnopqR ijklmnopqR $ echo 'ijklmnopqS' | sed '/[R-Z]/p' ijklmnopqS ijklmnopqS -- Éric Bischoff - Bureau Cornavin Technical writing and translations http://www.bureau-cornavin.com
Re: Case insensitivity seems to ignore lower bound of interval From: Eric Bischoff Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Fri, 29 Apr 2011 09:03:52 +0200 (引用部略) OK, at that time I did not understand how that would solve the problem (nor even why that was relevant). That's really good news for all awk developpers. Thanks for pointing me to that comment again, Paul. -- Éric Bischoff - Bureau Cornavin Technical writing and translations http://www.bureau-cornavin.com
Re: Case insensitivity seems to ignore lower bound of interval From: Aharon Robbins Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Fri, 29 Apr 2011 10:55:23 +0300 Eric, Hi. > At this point, my personal opinion is that all intervals are simply > unusable with gawk, as they gives results that are both unpredictable and > counter-intuitive with any locale other than "C". Indeed - this is why the (development) documentation clearly explains not to use them, and why the development code converts [R-Z] into [RSTUVWXYZ]. I have been fighting this issue for years now. Davide Brini states: > You seem to think this is gawk-specific, but in fact any locale-aware tool > that uses regular expressions behaves the same (try eg with sed or grep). And this too is correct. POSIX locales (in my not-so-humble opinion) are a total and utter botch. (I'll point out also that all of this happens down in the library routines that gawk uses, and which are (complicated, messy) black boxes as far as I'm concerned.) > Asking non-English users to write explicit [abcdefghijklmnopqrstuvwxyz] > choices is not a solution either. [[:lower:]], [[:upper:]] and so on exist to mitigate this issue. They are not perfect solutions. > Collation [...] Collation has to do with sorting order, and less so with regular expression matching. Gawk doesn't support [[=e=]] which is supposed to match all versions of the letter 'e'. > My point is that [R-Z] should either be defined to [rRsStTuUvVwWxXyYzZ] > or to [RSTUVWXYZ], but not to a surprising thing like [RsStTuUvVwWxXyYzZ] > (no "r"). The current situation where [R-Z] catches "t" but does not > catch "r" is really weird, even if it's compatible with the freedom > offered by the POSIX standard. I agree, which is why I've clarified the doc and changed the code, but again, this is not a gawk-specific issue but a general locale issue. > One technical possibility would be to simply use Unicode code positions. Unfortunately, no. Gawk is used in many parts of the world where Unicode is not the standard character set (Japan, China, etc.) and restricting gawk to just Unicode would not be a good idea. You can today use octal escapes inside [...] if you want. (It's even documented! :-). But that's only good for single bytes. Maybe in another 10 years it'll be safe to move exclusively to Unicode. To sum up, it's a thorny issue, of which I'm well aware, but there is no simple easy solution. If you still disagree, then I'm sorry, there's nothing else I can do to help. Thanks, Arnold
Re: Case insensitivity seems to ignore lower bound of interval From: Aharon Robbins Subject: Re: Case insensitivity seems to ignore lower bound of interval Date: Fri, 29 Apr 2011 10:57:12 +0300 Hi. (引用部略) I have been fighting this issue for at least 10 years (I think). To turn it off, just use --posix. Gawk already has too many command-line options; I don't want to add another one. Thanks, Arnold
まあそうだろうねえ＞10年以上
■_ 50 years ago
Abstract Heresies: 50 years ago — April 28, 1961 Thursday, April 28, 2011 50 years ago — April 28, 1961 Compatability of LISP 1 and LISP 1.5. 1. EVALQUOTE has two arguments while APPLY has three. To change a LISP 1 program for LISP 1.5 simply eliminate the p-list if it is null. If the p-list is needed, then the function apply is available in LISP 1.5, 2. Arithmetic in LISP 1.5 is new, improved, and generally incompatible with LISP 1. 3. LISP 1.5 has many extra features. There [sic, these] are being written up for the new LISP 1 Programmer's Manual. Until it comes, check in Room 26-265.
そういや、1.5 はわりと取り上げられるのをみるけど 1 はそうでもないような?
■_
Stand up for your communities and projects - Perlbuzz Slipping away from the Perl community - Perlbuzz
■_
- 暇人＼(＾o＾)／速報 : 猫 を 飼 っ て い て 驚 い た 事 - ライブドアブログ
- バカが征く
- ueBLOG | 4月28日に「428 封鎖された渋谷で」をオススメしてみる
-
モノレールと新交通システム、仰ぎ見た未来とやってきた現実 | WIRED VISION
色々書いてきたが、モノレールと新交通システムを調べてきて、強く実感したことがある。何を大げさなと言われそうだが、「日本経済がダメになった理由はこれか」ということだ。
- 本の虫: Translation is impossible
- Tech LION vol.2 開催します！ - USP友の会
- 100人規模の勉強会を開催するための(オレオレ)10個の流儀 - ゆーすけべー日記
- Google Objective-C Style Guide
- Groovy v1.8の新機能をサクっと紹介するよ - No Programming, No Life
- Amazon.co.jp： ITエンジニアのためのハイプレッシャー下での対応術: 鳥山 康見: 本
- サインコサインタンジェント教えれ
- YouTube - 答一発！カシオミニ
- Amazon.co.jp： 学生のための基礎Java: 照井博志: 本
- Amazon.co.jp： 大学生のICT活用標準テキスト―2011年版大学生の情報リテラシー: 富山大学情報教育研究会: 本
-
投げだしたいプロジェクトをどうするか。：島国大和のド畜生
正直、敗戦処理やツマラン仕事なんか、どんだけうまくやっても評価されにくいので、「自分を成長させるエサに使うしかない」と思うんだ。
- 書籍『Test Driven Development for Embedded C』：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
- 関数適用演算子 - iorateの日記
![日経ソフトウエア 2011年 06月号 [雑誌]](http://ecx.images-amazon.com/images/I/61HeZFMnexL._SL160_.jpg)
