一つ前へ
2011年7月(上旬)
一つ後へ
2011年7月(下旬)
rubykaigi #rubykaigi 2011に行ってきた - Jewel-mmo開発日記 yokohama.rb もいっぺん行きたいとは思ってるんだけど。
そいや、 parse.y のセッションで出た質問。 1.8 の parse.y に手を入れて 1.9 の構文を理解させる云々というのがあったけど、 その場ではどういう意図でそいうことを質問したのかわからなかった (「技術的」にはやれないこたないだろうし)。 が、今にして思い返すと、1.8→1.9への移行は色々面倒だけど、 1.8使いながら1.9の(構文的な。ってなに)おいしいところだけ欲しいとかいう希望だったのかなあ。 それでもよくわからんけど。
QString improved ≫ Thiago Macieira's blog
struct Data {
QBasicAtomicInt ref;
int alloc, size;
ushort *data; // QT5: put that after the bit field to fill alignment gap; don't use sizeof any more then
ushort clean : 1;
ushort simpletext : 1;
ushort righttoleft : 1;
ushort asciiCache : 1;
ushort capacity : 1;
ushort reserved : 11;
// ### Qt5: try to ensure that "array" is aligned to 16 bytes on both 32- and 64-bit
ushort array[1];
};
結構ビットフラグあるな。
■_ C++0x
■_
- [読書]誰を対象にした内容なのか不明確 Java: The Good Parts: 雪羽の発火後忘失
- 高校生がアルゴリズムで世界に挑んできます - 簡潔で覚えやすいタイトルを3秒で思いつく程度の能力
- MS、コンパイラをサービス化する「Roslyn」の詳細公開へ - CNET Japan
- RubyKaigi2011 - Shizuto on Languages
- "最後の"RubyKaigiは"最高の"RubyKaigiだった - (ﾟ∀ﾟ)o彡 sasata299's blog
- スタートWt - How to disappear completely
- 情報デザイン - Wikipedia
- COBS ONLINE：連載 eNEWS＋ １ 『情報デザインって何だろう？』
- LLVMとコンパイラと投資 JavaがC++に圧勝するコード例
- ”えっと、あとがきです”: つらつらぐさ
- 規模拡大で体制に限界、日本Rubyの会が再スタートへ － ＠IT
- Cisco、約6500人の人員削減とSTB工場の売却を発表 - ITmedia エンタープライズ
- コツ？ 開発者の立場になって考えることさ！（1/2） － ＠IT
- 地方からRubyKaigiに参加してみて - A Life Less Ordinary
- ピノキオ - ひげぽん OSとか作っちゃうかMona-
一方、30歳頃のカエサルは…- [連載：ギークな女子会] べにぢょ編⑦－ソフトウエア開発に必要なのって、「エンジニア的発想」だけじゃない ｜ エンジニアtype
以前「Go」のコンパイラを読んでいて、「この人なんかケン・トンプソンみたいな書き方するな」と思っていたら、あとで履歴を見てみたら本人の書いたものだったことがありましたよ。
んー、あれはあきらめないとならない雲行き○|￣|＿
うざい昔話を聞いたり話したりしたいと思うなど。
・スライド
以前高橋会長には伺ったことがあるのですが、
スライドの見出しなんかが微妙に長くて中途半端に折り返しができてしまったときに
どうしてますか?
わたしは、言い回しを変えて短くしたり(逆に長くすることも)、どうしようもない場合には
文字の大きさを落としてでも二行目に数文字だけはみ出すことがないようにしています。
また、改行で単語が泣き別れしないようにといったことでも悩むことが多いです。
86世代やらで、ある一年で限定して「世代」ってのはおかしいんじゃないの? という意見をちらほら見かけるのですが(わたしも同意)、 この辺が起源なんですかね。
松坂世代 - Wikipedia 松坂世代（まつざかせだい）とは、松坂大輔と同学年にあたる1980年4月2日から1981年4月1日ま でに生まれた世代の日本のプロ野球選手のことを総称して呼ぶ語である。 名前の由来 松坂大輔が横浜高校のエースとしてかながわ・ゆめ国体、阪神甲子園球場で開催の第70回選抜高 等学校野球大会及び全国高等学校野球選手権大会で活躍した1998年は松坂など優れた高校球児を 多く輩出したことで知られ中村順司が指揮する第3回AAAアジア野球選手権大会日本代表が同大会 制覇、大学・社会人を経由の者も含め、多くの選手がプロ入りし、活躍した。特に甲子園に出場 した選手や、東京六大学、東都大学と言った有名なリーグで下級生時からエースとして活躍する 選手が非常に多かったこと、さらに他のスポーツ競技者や芸能界にも人材を輩出したことから、 1980年4月2日 - 1981年4月1日生まれに対しマスコミが「松坂世代」と呼ぶようになった。 従来日本のプロ野球界に於いて、その生まれ年の数字を使った「昭和○○年組」というものが一 般的であり、選手達自らが組織を作る場合にも同様に生まれ年を使った「昭和○○年会」という 名称を使用しており、松坂世代も「昭和55年会」を組織している。一選手の名前が使われ、「○ ○世代」と呼ばれるのは（例：1967年度生まれの選手をあらわす「桑田清原世代」、1988年度生 まれの選手をあらわす「マー君・ハンカチ世代」など）この「松坂世代」にはじまったことであ る。
「桑田清原世代」って使ってたっけ? ってこの記述はあれか、「松坂世代」が定着したあとで使われるようになったということか。
小出しに。
「The Final RubyKaigi」2日目 - ただのにっき(2011-07-17) あとLTの客席でLet'snoteが3台並んだりしたので(おれ、@nahi、@_ko1)、お楽しみのLTと懇親会については元気があれば追記する、かも。というか、Rubyの懇親会でMatz がぼっちになってたり、スイーツが瞬殺だったりと、まったくお前らときたら……。
Let's Note 持って行ってたので混ざればよかったかしらん。
確かに、まつもとさんを遠巻きにして見てるんだけど会話に入ってかない っては結構見かけたかも。まあいざとなると何話していいかわからんてのはあるしねえ。
懇親会が始まる前の話ですが、 一人で手持ち無沙汰にしてた中国系の名前の書かれた名札を下げた女性を見かけました。 まったく(ry あわせて読みたい→ バカが征く
懇親会での話その2． 英語でやり取りしてたエンジニア(Web系らしく話が合わなかったw。多数派はこっちなんだろうねえ) に、iPhone 使えと熱心に勧められたw そらまあ使いもせずにあーだこーだ言えないわけだし、 使ってみたいアプリも結構あったりするのだけど先立つものが以下略。
考えることは同じなんだなあと。
今日はHokkaido.pm #5の日です - a geek born in Tomakomai Base64を再実装する / @akiymさん @onagataniさんから、「高校生をアピールして下さい！」という指示が。 * 「高校生」Amon2::Setup::Flavor::Teng 書いたり、WWW::YouTube::Download、Web::Queryのpul-reqとか * YAPCいつか行きたい！ * Base64とは？ → データを6bitずつに分割して変換 * 最近のBase64はいけてない o アルファベット、数字を使ってる o 読めない * 再実装 → Acme::Collector64 o Japanese64 と呼んだらいいよ * 使い方 o 秘密の暗号 o ふっかつのじゅもんに * ひらがなじゃなくても o 魚編の漢字とかかっこいい → demo * まとめ o Acme::Collector64 は github にある。 o お好きなBase64で!
そのむかし、こういうものがあってですね おさかな ‐ 通信用語の基礎知識 enfish/defishの詳細情報 : Vector ソフトを探す！
enfish/defishの詳細情報 : Vector ソフトを探す！ ソフト詳細説明 かな漢字変換のプログラムでも、デフォルトで変換できる"おさかな文字" はごく一部のポピュラーな文字に限られており、おさかな隊(*1)としては 非常に悲しい状況が続いているのでありました。 そこで、普段我々がよく目にする uu や ish 化された情報が"おさかな 文字"で表現されていればもっと"おさかな文字"が世間に認知され、かつま た多くの人のかな漢字変換の辞書に"おさかな文字"が登録され、使用され るのではないか? と言う、はかない願いからこの enfish/defish.exe が生 まれたのでありました(ほんとか?)。
こんな感じ。
begin 86~ sample.txt 鯆鯱魚鰯鰰鮗鮫鮭鯆鯱鰲鰯鰈鮟鰯鯑鯑鯣鮓鱈鰯鯆 `` end size 16 END--cut here--cut here
uuencode/uudecode やら ish なんて知らん人が大半だろうなあ ○|￣|＿
自分で稼ぐようになったらぜひ買ってください。プレミア価格でお売りします
Firebug がなくなる
私は常々どうしてこのような人がもっと報われないのだろうか、と感じていました。
今回、僕がRubyKaigiに参加した目的は「打ちのめされること」でした。
Kaigi 会場で「バカが征く」の中のひととお話したこと(に関連した色々)なども 書きたいのだけどちょっとまだ自分の中でまとまってない(のでまだ書[かけ]ない)。
三日目(最終日) RubyKaigi2011 スペシャルレポート：Ruby会議2011 3日目レポート［随時更新］｜gihyo.jp … 技術評論社
・売り切れ
アジャイルサムライ本が売り切れでしまい、かくたにさんたちのサインをもらい損ねる。
初日にはこんだけあったのに!
７つの言語 ７つの世界
初日に7言語とAlloy本を買ったときにいっしょに買っておくべきだった ○|￣|＿
サイン会は三日目だから初日に買うことはなかろうと思っちゃったのよねえ。
んで、三日目に会場に来た時点ではまだRubyKaigi支店は営業してなくて、
一つ目のセッション中に売り切れの報が入ったという。
かくたにさんの名前が出たので、昨日のかくたにさんのセッションを思い出しながら。 話の中で当然のように Dave Thomas の名前<と写真>が出てそこから自然な流れで 「達人プログラマー」の名前も出たのですが、そのときにメインスクリーンの左で流れていた twitter での発言の中に「読んだ」「読んだことがない」というのに混じって 「そんな本があるのを知らなかった」というのをいくつか見かけました(様な気がする)。 なんらかの理由があって「読んでいない」のはいいとして、 「知らなかった」のはなぜなのでしょうか? その人のアンテナが低かったからという一言で済ませるのが一番簡単だとは思いますが、 それのみで片付けて良いものとも思えません。
このあと長々と書くのは気力がありませんのでここで止めますが
(読みたい場合はわっふる(ry)、
せっかく翻訳されてもすぐに絶版状態になる本も少なくないですよね。
復刊された
のような例もありますけど、たいていはそのまま入手困難になっていってしまいます。
聞くところでは、
がもうほとんどどこにもなかったり、
もこの先どうなるかわからないとも。
電子書籍で、という声が聞こえてきそうですが、それにしてもすべてを解決するとも思えないのですよね。
ひとつの問題を解決しても、別の問題を持ち込むなどという形になりそうな気がします。
まつもとさんのセッションで、
良い心で使うとRubyは絶大な力を発揮するけれども
汚れた心で使うと(言い回しは違いますがまあこんなイメージだったと)云々
というところでそこかしこで某魔法少女を連想した方がたくさんいらっしゃったようですが、
わたしが連想したのはこれでした
年代がばれますねw
切り取り方次第でまた一悶着起こしかねない発言がちらほらあったような気もしますが、 まあそれはそれ。
「蟲毒」を知らない人(北米の方?)に説明するのはそら大変ですよねえ(^^;
そしてオーラス。
↑の写真ではとてもわかりませんが、 スクリーン左の twitter への発言を表示している部分の一番上のところに、 「またあいましょう」「See you again」「Au revoir」の三つの言葉が 順番に繰り返し表示されていました。
なぜ日本語、英語ときてフランス語なんでしょうか? いえ、それが悪いというわけではないのですが、 フランス語を出すのならそれこそ会場に来た人の母語すべてでもよかったんじゃないかなあと (調べるのが大変でしょうけど)。 スタッフの中にフランス語話者がいらしたんでしょうか?
と最後まで細かいところをつつきましたが、 スタッフの皆様お疲れ様でした。
ここぞとばかりにアサマシ貼ってみました(^^;
発売日： 2011/8/10
RDBのデフォルト文字コードを UTF8にするのは、「勿体ないのでけは」と思うようになりました。
身近な人の話は宴会のように顔を合わせて聞くしかないのだろうか. それでもいいけれど, テキスト愛好家としては文字になったのを読みたい. 仕事選びや仕事探しの話をしなくてもいい. 同じ人が書いたものを沢山読めば伝わることはある. 世の blog 書きも Michael Loop にならいもっと仕事の話を書いてほしいと思いました.
チューリング賞受賞者が言うんだから．
July 18-20, 2011 Oracle Corporation: Santa Clara campus About 70 language and VM implementers attended last year—and over one third presented.
Proposal for working around the Python GIL
Javascript Git implementation
昨日の懇親会やら昨日今日のLTの話を書いている余裕はなっしんぐ
安全なプログラムの作り方 | 日本Ruby会議2011(7月16日〜18日) 概要 コミッタなどとして関わっているソフトウェアの脆弱性修正や 脆弱性を IPA へ届出経由で修正して もらった経験をふまえて どのようなプログラムを書くと脆弱性を含みやすいのかという 話をします。
このセッションでの質疑応答で正規表現の使い方についてのやりとりがあったのですが、 細かいところの話で西山さんはご存じなかったらしく、はっきりとした答えが出ていませんでした。 一瞬出しゃばるべきかとも思ったのですが自重してしまいましたｗ 今更ですが、ここに簡単に書いておきます。
発表の中で意図しないマッチをしないように正規表現を記述しようという話があったのですが、 それに関して「locale 設定によっては文字クラスの範囲指定を使った場合に、 [A-Z]に小文字(の大部分)がマッチしてしまうことがあるという話があるけれども その辺についてはどうなのか」と言った趣旨の質問がありました (きちんとメモってないので間違いがあったらごめんなさい)。
西山さんの回答は(Rubyの場合の)localeに関連した文字クラスの範囲指定の動作は よくわからないが、[[:lower:]] や \p{Lower} のようなPOSIX クラスやプロパティで 指定すればよいのではないか。といった感じのものだったと思います
この質問のケースですが、Rubyに限って言えば気にする必要はありません。 1.8でも1.9(鬼車)でも、locale によってマッチ対象が変わるという実装ではなかったはずです。 むしろ \p{Lower}の対象が(文字コードによって)変わってしまう恐れがあるのですが (Perl 辺りで試せば実例が出せると思います)、 こちらも鬼車限定の話として対象がASCIIのみにされているというものだったと記憶しています。
成瀬さんがtwitterで反応するかと思ってたんですがなかったみたいですね。
家に帰ったらほぼすぐにダウン。巡回も何もなしw
RubyKaigi2011 1日目。
RubyKaigi2011 スペシャルレポート：Ruby会議2011 1日目レポート［随時更新］｜gihyo.jp … 技術評論社 なんてのがありますので、もはや自分でまとめる気力はありません<笑> 個々のセッションについて、違った意見を持ったものもあるのですけど、 まあ止めておこうかと。
最後の、とか、LAST、とかFINAL<スタッフTシャツにあった>、とかあると これ → ガンダム ラストシューティング - Google 検索 を連想してしまってですね <正確には映画の予告編>、締めのセッションの最後のスライドで
And now…in anticipation of your insight into the future.
とか出たりしないか期待半分恐れ半分で待ってたりするのですがw
nari3さんさんのスライド、ウサギと亀の追いかけっこじゃないのと
(このキャラクターたち、名前あるんでしょうか?)、
G から始まって C に行くという細かい芸に釘付けで肝心な内容が以下略
aaron の基調講演中にRTで流れてきたものにちょっと気になるものがあった。 その後これに関して話題にならなかったのかな? と思いつつ、dual-life とか知らなかったのでこぴぺ。 Twitter / @miyagawa: Don't Ruby core libraries ...
Twitter / @miyagawa: Don't Ruby core libraries ... Don't Ruby core libraries have a concept of dual-life? #rubykaigi
Twitter / @miyagawa: In Perl many core perl mod ... In Perl many core perl modules are also dual-life and available on CPAN - you don't need to wait for Perl language to be updated
Twitter / @miyagawa: removing third party modul ... removing third party modules from core languages so that it can be dual life on rubygems? Been there, done that :) #perl #rubykaigi
Twitter / @timhaines: @miyagawa what does dual l ... @miyagawa what does dual life mean?
Twitter / @miyagawa: @timhaines available in pe ... @timhaines available in perl language but also upgradable from CPAN
Twitter / @miyagawa: @timhaines dual life means ... @timhaines dual life means a module (Net::HTTP, for example) is available in a core library in the language but also on rubygems/cpan
Twitter / @miyagawa: @miyagawa so that if you w ... @miyagawa so that if you want a new version of the library you don't need to wait for a year for the new release of the *language*
Twitter / @miyagawa: @timhaines ruby's core (st ... @timhaines ruby's core (standard) libraries are only available through the language, perl isn't
Twitter / @timhaines: @miyagawa Ahh. So you can ... @miyagawa Ahh. So you can upgrade to a more recent version even if perl core lags behind? Bug fixes easier to deploy etc?
Twitter / @miyagawa: @timhaines yep ... @timhaines yep
Twitter / @timhaines: @miyagawa hey - you replie ... @miyagawa hey - you replied to yourself hear. You were probably wondering why I asked something you already explained.
Twitter / @miyagawa: @timhaines I tried to make ... @timhaines I tried to make a "thread" - which I know is a moot thing on twitter :)
まあ togatter やら使えというお話もありましょうが ○|￣|＿
正直私もここまで来ると ML モジュールシステムは強力かもしれんが大変で、 ちょっと非力でもいいからお行儀のよい何かを考えんとあかんやろ、と思う。なんというか… Set.Make(A) で Set が作れますよー SML module system イイですねー、の古き良き時代は遠い過去なんだ
あ、闇の集まりには出ませんでしたのでその情報はありません。 面白かったみたいですねえ ○|￣|＿
で、明日から RubyKaigi らしい。
ふと「バリュート」について調べてみると
バリュート (ガンダムシリーズ) - Wikipedia バリュート (ガンダムシリーズ) 出典: フリー百科事典『ウィキペディア（Wikipedia）』 バリュート (valute) は、「バルーン・パラシュート」の略で、アニメ『機動戦士Ζガンダム』 『機動戦士ガンダムΖΖ』などに登場する、モビルスーツ（MS）および宇宙艦艇の大気圏突入用の 装備である。 実在の大気抵抗装置のバリュートに着想を得て、大気圏突入装置としたものである。また映画 『2010年』においても、木星に到達した宇宙船レオーノフ号が行った木星大気圏突入（抗力によ り減速する「大気制動」の為）にて同名の装備を使用しているシーンが存在する。
balloon と parachute からできた言葉ななのに、なんで「valute」?
バリュート - Wikipedia バリュート 出典: フリー百科事典『ウィキペディア（Wikipedia）』 バリュート(Ballute)とは、ガスなどにより展開する袋状の大気制動装置。balloon（風船）と parachute（パラシュート）を組み合わせた造語である。高速時においてパラシュートより耐久 性があるのが特徴。 1958年にグッドイヤー社により開発された。形状は円錐形。 (略) フィクション [編集] * バリュート (ガンダムシリーズ) - 大気圏突入制動装置として使用。
わざわざ変えたのかなあ＞ v
こっちの中身はまだ見てないのですが、似たような話をついったあたりでも見かけたような。
Github is Your New Resume : programming
Github is Your New Resume Github is Your New Resume I have a friend who lives on the West Coast and has been thinking about moving to New York. He has a solid resume that speaks in lengths about the many years of his exceptional software career in the depths of the Enterprise. He wants to press the reset button, learn Ruby or Python and find a job with some web scale. At some point I advised him to get a Github account. Turned out that all the jobs he had been considering were already asking for it! Increasingly companies are asking to see a Github account, followed by references. A resume has become nothing more than a formality to weed out people flipping jobs too often. Github enables individuals and organizations to create projects, fork them and to contribute source code to the forks without approval or oversight from the original authors. Changes can be committed locally, pulled to the parent repository with a code review. Anyone can comment on any single line of code or a pull request. You can use your fork immediately in your project. Github removed the remaining barriers around open-source collaboration and elegantly enabled private repositories for a fee. Github is your new resume. Here's how to make the best of it. College and Personal Projects
New regex engine for nqp and nom, now passing 7K spectests | Pmthium New regex engine for nqp and nom, now passing 7K spectests Nom and nqp now have a new regular expression engine (currently known as “QRegex”) that I've implemented over the past week. (略) Qregex does its backtracking and other core operations more directly, without any method calls for backtracking. So I expect that this one change will reduce the number of method calls involved in parsing by almost a factor of 3. Other common operations have also eliminated the method call overhead of the previous engine. Qregex では、バックトラッキングやそのほかの core operations をより直接的、つまり バックトラッキングのためのメソッド呼び出しなどをしないで実行します。そこで わたしはこの変更がメソッド呼び出しの回数を減らし、解析の速度をおおよそ三倍ほど 向上させると予測しています。 #あやしい そのほかの一般的な operations でも同様に以前のエンジンにはあったメソッド呼び出しの オーバーヘッドが削除されます。 The new engine also uses a fixed-width encoding format internally, which means that we no longer pay a performance penalty for matching on unicode utf-8 strings. This will also enable us to eventually use the engine to do matching on bytes and graphemes as well as codepoints. この新しいエンジンは内部的には固定長のエンコーディングを使っています。 これは、UnicodeのUTF-8文字列でマッチングを行う際の性能についてのペナルティを もはや支払うことはないということを意味します。 これはまた、エンジンがコードポイントを bytes や graphemes としてマッチングする のを可能にもするでしょう。 I also found quite a few places where I could drastically reduce the number of GCables being created. In some cases the old engine would end up creating multiple GCables for static constants, the new engine avoids this. A couple of new opcodes will enable QRegex to do substring comparisons without having to create new STRING gcables, which should also be a dramatic improvement. I've already prototyped some code (not yet committed) that will integrate a parallel-NFA and longest-token-matching (LTM) into QRegex, so we'll see even more speed improvement. (略)
ということで、RubyKaigi期間中は内容がぐだぐだになりまする
困ったときは Jargon File だ!(謎)
糖衣構文 16 デフォルトの名無しさん [] 2011/07/13(水) 08:26:29.00 ID: Be: で、syntactic sugerの適切な訳語って無いのかよ？ 17 デフォルトの名無しさん [sage] 2011/07/13(水) 10:53:01.44 ID: Be: シンタクティック・スージャー？ まぁスペルのツッコミはいいとして、、やっぱり構文砂糖だろう 18 デフォルトの名無しさん [sage] 2011/07/13(水) 12:03:44.07 ID: Be: 日本語能力ない奴に指摘されてもなｗ 19 デフォルトの名無しさん [sage] 2011/07/13(水) 21:49:06.95 ID: Be: 砂はいらんだろ。 構文糖分じゃないか？ 20 デフォルトの名無しさん [] 2011/07/13(水) 22:40:20.24 ID: Be: 構文糖はよく見る。 22 デフォルトの名無しさん [sage] 2011/07/14(木) 08:21:24.19 ID: Be: そもそも原語の syntax sugar は程度の低い駄洒落だし。 sugar を掛けながら、本来の言葉の意味を、より的確に表した 糖衣構文は上手い訳語だと思うよ。 23 デフォルトの名無しさん [sage] 2011/07/14(木) 20:06:43.76 ID: Be: 元は糖衣っていう意味じゃないってこと？
言語は syntactic sugar であって syntax sugar じゃないんだよね云々と 書こうと思ったら訳語について書くのはは先を越されたのでやる気なくしたw Floating Log 14.7.2011
Floating Log 14.7.2011 「糖衣構文」という語は "syntactic sugar" という元の言葉より手が込んでいる感 があって気持ち悪い。 といって「構文糖」は収まりが悪い。 「砂糖」以外の「糖」は日常語で はない。 そもそも「糖衣」というのが糖衣錠の糖衣なのか、お菓子のつや出し(?)技法なのか、と斜めか ら切り込んでみようかと思ったが、後者に対応する英語は icing とか frosting (主にアメリカ の用法)とか出てきて、sugar ですらなかった。 つまり、sugar とは材料そのものというより、 苦いお茶やコーヒーにぶち込んで甘くするもの、というような喩えなのだよ。 多分。 日本文化ではお茶自体を甘くする代わりにお菓子を添えて出すわけで(甘いとは限らないかもし れないけど)、うまく喩えが当てはまるほど「砂糖」はこなれた言葉ではない。 というわけで代 替案としては「構文あめ」かな(ちょーてきとー)。
この手の用語はJargon File に訊けつーことで調べると、しっかりエントリがあります。
syntactic sugar syntactic sugar: n. [coined by Peter Landin] Features added to a language or other formalism to make it ‘sweeter' for humans, but which do not affect the expressiveness of the formalism (compare chrome). Used esp. when there is an obvious and trivial translation of the ‘sugar' feature into other constructs already present in the notation. C's a[i] notation is syntactic sugar for *(a + i). “Syntactic sugar causes cancer of the semicolon.” — Alan Perlis. The variants syntactic saccharin and syntactic syrup are also recorded. These denote something even more gratuitous, in that syntactic sugar serves a purpose (making something more acceptable to humans), but syntactic saccharin or syrup serve no purpose at all. Compare candygrammar, syntactic salt.
「構文あめ」は「candygrammar」と被っちゃわないかなあと思ったり。
candygrammar candygrammar: n. A programming-language grammar that is mostly syntactic sugar; the term is also a play on ‘candygram'. COBOL, Apple's Hypertalk language, and a lot of the so-called ‘4GL' database languages share this property. The usual intent of such designs is that they be as English-like as possible, on the theory that they will then be easier for unskilled people to program. This intention comes to grief on the reality that syntax isn't what makes programming hard; it's the mental effort and organization required to specify an algorithm precisely that costs. Thus the invariable result is that ‘candygrammar' languages are just as difficult to program in as terser ones, and far more painful for the experienced hacker. [The overtones from the old Chevy Chase skit on Saturday Night Live should not be overlooked. This was a Jaws parody. Someone lurking outside an apartment door tries all kinds of bogus ways to get the occupant to open up, while ominous music plays in the background. The last attempt is a half-hearted “Candygram!” When the door is opened, a shark bursts in and chomps the poor occupant. [There is a similar gag in “Blazing Saddles” —ESR] There is a moral here for those attracted to candygrammars. Note that, in many circles, pretty much the same ones who remember Monty Python sketches, all it takes is the word “Candygram!”, suitably timed, to get people rolling on the floor. — GLS]
せっかくなので、「ハッカーズ大辞典」の syntactic sugar からも転載しておこう。 そこのキミも今すぐ復刊リクエストだ! 『ハッカーズ大辞典（エリック・Ｓ・レイモンド）』 復刊リクエスト投票
syntactic sugar 〈原義:構文糖〉[Peter Landinの造語] n. 人間にとって「もっと甘く」するために言語やその他の論理形式に添加されるが、その 論理形式の表現力には影響を与えない機能(chromeと比較せよ)。とくに「糖」機能が、表記 法の中にすでに存在する別の構文に置き換えられる場合に使われる。Cのa[i]という表記法は *(a + i) の構文糖(syntactic sugar)だ。以下略
都大会にすら出たことない高校生が突然「メジャーリーグで活躍したい」と言い出すのと似ていて、 そういう意欲があるのは大変結構なのだが、そういう人に言いたいのは、まず自分がいまいる環境の中で形に残る結果を出し、 それを引っさげて次に行くのが筋、ということ。
Tip： Raymond氏は__（2重アンダースコア）を「あんだーあんだー」と読んでいました。また，カリフォルニアの人たちには「だんだー」と読む人もいるそうです。
作品を作るときには、こういう不思議な巡り合わせがあるものだ。
数学セミナーげと。 立ち読みしてる連中を書き分けて探すのが面倒だった。
なーなせんはっぴゃーくえーん(謎)
ExcelDnaUtil.Application を F# から使ったらえらい遅かったので、色々試してみました。
あんまり溜め込んでおくのもなんなので
LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #3/3 Saturday, May 21, 2011 What Every C Programmer Should Know About Undefined Behavior #3/3 すべての C プログラマーが未定義動作について知っておくべきこと (3/3) In Part 1 of the series, took a look at undefined behavior in C and showed some of the cases that it allows C to be more performance than "safe" languages. In Part 2, we looked at the surprising bugs this causes and some widely held misconceptions that many programmers have about C. In this article, we look at the challenges that compilers face in providing warnings about these gotchas, and talk about some of the features and tools that LLVM and Clang provide to help get the performance wins while taking away some of the surprise. 本シリーズの第一話では C の未定義動作とそれが C を“安全な”言語よりも性能で上回らせている 要因となっていることを幾つかの例を挙げて見てきました。第二話では、未定義動作が引き起こす surprising bugs と多くのプログラマーが広範囲に C に対して抱いている誤解 (misconceptions) の いくつかに注目しました。今回は警告を発するためにコンパイラーが直面しているそういった gotchas に対する challenges に注目し、さらに some of the surpise を taking away しながら performace wins を勝ち取るのを help するために LLVM と Clang が提供している幾つかの機能と ツールについて述べます。 Why can't you warn when optimizing based on undefined behavior? なぜ未定義動作に基づき最適化をするときに警告できないのか? People often ask why the compiler doesn't produce warnings when it is taking advantage of undefined behavior to do an optimization, since any such case might actually be a bug in the user code. The challenges with this approach are that it is 1) likely to generate far too many warnings to be useful - because these optimizations kick in all the time when there is no bug, 2) it is really tricky to generate these warnings only when people want them, and 3) we have no good way to express (to the user) how a series of optimizations combined to expose the opportunity being optimized. Lets take each of these in turn: ある最適化を行うために未定義動作のアドバンテージを使うとき、それは実際にはユーザーコードに 存在しているバグである可能性があるのだから、なぜコンピューターは警告をしないのだと訊ねる人 がたくさんいます。このアプローチを使った challenges は以下のようなものです 1) 警告を数多く発するのは useful からは程遠い - なぜならこれらの最適化はバグが存在していないときに kick in するからであり、また、 2) ユーザーが必要とするときにだけ警告を生成するのはとてもトリッキーである。そして 3) expose the opportunity being optimized のために一連の最適化がどのように combine されるのかを (ユーザーに対して) 説明する良い手段がない。 Lets take each of these in turn: It is "really hard" to make it actually useful これを実際に useful にするのは "really hard" です。 Lets look at an example: even though invalid type casting bugs are frequently exposed by type based alias analysis, it would not be useful to produce a warning that "the optimizer is assuming that P and P[i] don't alias" when optimizing "zero_array" (from Part #1 of our series). 例を挙げて見ていきましょう: 型ベースの別名解析 (type based alias analysis) による型キ ャストバグが頻繁に発生していたとしても、(第一回にあった)「オプティマイザーが P と P[i] が別名付けされていないと仮定している」"zero_array" を最適化するときにその 仮定に対する警告を行うのは有用ではないでしょう。 float *P; void zero_array() { int i; for (i = 0; i < 10000; ++i) P[i] = 0.0f; } Beyond this "false positive" problem, a logistical problem is that the optimizer doesn't have enough information to generate a reasonable warning. First of all, it is working on an already-abstract representation of the code (LLVM IR) which is quite different from C, and second, the compiler is highly layered to the point where the optimization trying to "hoist a load from P out of the loop" doesn't know that TBAA was the analysis that resolved the pointer alias query. Yes, this is "the compiler guy whining" part of the article :), but it really is a hard problem. この “偽陽性”問題以外の logistical 問題はオプティマイザーが reasonable な警告を発す るのに十分な情報を持っていないというものですが、これは第一には、C とは大きく異なる (LLVM IR の) コードとしてすでに抽象化された表現に対して処理を行うためです。 第二に、コンパイラーが “P からのロードをループの外に追い出す”最適化を試みるには、 pointer alias query を解決する解析だったことがわからないような highly layered な場所にTBAAがあるからです。 確かにこれは "the compiler guy whining" part of the article :) ですが、 実際には困難な問題です。 # XXX It is hard to generate these warnings only when people want them ユーザーが必要とするときにだけこれらの警告を行うのは難しい Clang implements numerous warnings for simple and obvious cases of undefined behavior, such as out of range shifts like"x << 421". You might think that this is a simple and obvious thing, but it turns out that this is hard, because people don't want to get warnings about undefined behavior in dead code (see also the duplicates). Clang は "x << 421" といった範囲外シフト (out of range shifts) のような 単純かつ明白なケースでの未定義動作に対する警告を数多く実装しています。あなたはこれを単 純かつ明白なことであると考えたかもしれませんが、それは難しいことが判っています。なぜな ら、ユーザーは dead code に存在する未定義動作についての警告など受け取りたくはないから です (see also the duplicates)。 This dead code can take several forms: a macro that expands out in a funny way when when passed a constant, we've even had complaints that we warn in cases that would require control flow analysis of switch statements to prove that cases are not reachable. This is not helped by the fact that switch statements in C are not necessarily properly structured. この dead code は several forms を取る可能性があります: 定数が渡されたときに funny way で expands out されるマクロで、到達不能なケースを prove するための switch 文の制御フロ ー解析を要求するケースでわたしたちが警告したことについて complaints を受けたことすらあ ります。C の switch 文は properly structured である必要がないということはこれに対する 助けにはなりません。 The solution to this in Clang is a growing infrastructure for handling "runtime behavior" warnings, along with code to prune these out so that they are not reported if we later find out that the block is unexecutable. This is something of an arms race with programmers though, because there are always idioms that we don't anticipate, and doing this sort of thing in the frontend means that it doesn't catch every case people would want it to catch. Clang におけるこの問題に対しての solution は、"runtime behavior" warnings を ハンドリングするための infrastructure の growing です。それは prune out するためのコ ードと関係しているので、そのブロックが実行されないもの (unexecutable)であることが後 になってわかった場合でも警告が行われません。わたしたちが anticipate していないイディ オムは常にあるので、これは something of arms race with programmers though です。 そしてフロントエンドでこの種のことを行うことは、ユーザーが捕捉して欲しいと希望するで あろうすべてのケースを捕捉はしないことを意味しています。 Explaining a series of optimizations that exposed an opportunity opportunity を expose している最適化の series を explaining する If the frontend has challenges producing good warnings, perhaps we can generate them from the optimizer instead! The biggest problem with producing a useful warning here is one of data tracking. A compiler optimizer includes dozens of optimization passes that each change the code as it comes through to canonicalize it or (hopefully) make it run faster. If the inliner decides to inline a function, this may expose other opportunities for optimizing away an"X*2/2", for example. フロントエンドが good warnings の producing に challenges していたら、たぶんその代わりに オプティマイザーから warnings を generate できたでしょう! ここで useful warning を生成す るに際しての最大の問題は data tracking のひとつです。あるコンパイラーのオプティマイザ ーは一ダースを超える最適化パスを含んでいます。そして最適化パスのそれぞれが canonicalize や(希望としては)高速に実行させるようにすることを行ってコードを変更します。もしある関数 をインライン化すると inliner が決めたならば、"X*2/2" を最適化するために他の機会 (other opprtunities) を expose するかもしれません。例をあげましょう： While I've given relatively simple and self-contained examples to demonstrate these optimizations, most of the cases where they kick in are in code coming from macro instantiation, inlining, and other abstraction-elimination activities the compiler performs. The reality is that humans don't commonly write such silly things directly. For warnings, this means that in order to relay back the issue to the users code, the warning would have to reconstruct exactly how the compiler got the intermediate code it is working on. We'd need the ability to say something like: これらの最適化を demonstarate するために相対的に単純かつ self-contained な例を出しましたが、 they kick in are in code な most of the cases はマクロの instantiation やインライン展開、 あるいはその他コンパイラーが行った abstraction-elimination activities から来るものです。 現実には人間はそういった silly things を直接書くことはないのが一般的です。 For warnings 、 これは、ユーザーのコードに relay back the issue するためには その警告はコンパイラーがどのように working on な intermediate code を got したか exactly に再構築しなければならないであろうことを意味しています。 # XXX わたしたちには次のようなことを主張する能力が必要でしょう: warning: after 3 levels of inlining (potentially across files with Link Time Optimization), some common subexpression elimination, after hoisting this thing out of a loop and proving that these 13 pointers don't alias, we found a case where you're doing something undefined. This could either be because there is a bug in your code, or because you have macros and inlining and the invalid code is dynamically unreachable but we can't prove that it is dead. 警告: 三段階のインライン化 (リンク時最適化によりファイルをまたがる可能性があります) 、 一部の共通部分式の削除 (common subexpression elimination) の後、これら 13個のポインターがエイ リアシングされていないことの検出 と this thing の out of a loop への hoisting の後で、 わたしたちはあなたが未定義のなにかを行っている個所を見つけました。 これは、あなたのコードにバグがあったか、あるいはマクロかインライン展開されるものがあって それが動的に到達不能な不当コード (invalid code) となったけれどもそれが dead code であること をわたしたちが検出できなかったかのいずれかの可能性があります。 Unfortunately, we simply don't have the internal tracking infrastructure to produce this, and even if we did, the compiler doesn't have a user interface good enough to express this to the programmer. 残念ながらこれを生成するための内部的な tracking infrastrucure をわたしたちは持っていません。 仮にそれを持っていたとしても、コンパイラーがそれをプログラマーに伝えるための good enough な ユーザーインターフェースを持っていません。 Ultimately, undefined behavior is valuable to the optimizer because it is saying "this operation is invalid - you can assume it never happens". In a case like "*P" this gives the optimizer the ability to reason that P cannot be NULL. In a case like "*NULL" (say, after some constant propagation and inlining), this allows the optimizer to know that the code must not be reachable. The important wrinkle here is that, because it cannot solve the halting problem, the compiler cannot know whether code is actually dead (as the C standard says it must be) or whether it is a bug that was exposed after a (potentially long) series of optimizations. Because there isn't a generally good way to distinguish the two, almost all of the warnings produced would be false positives (noise). 結局のところ、未定義動作はオプティマイザーにとって価値あるもの (valuable) です。なぜな らそれ (未定義動作) は "this operation is invalid - you can assume it never happens" (この操作は不正であり、決して発生しないものと仮定してよい) であるとされているからです。 "*P" のようなケースでは、これは P が NULLにはなりえないと判断する ability をオプティ マイザーに与えます。(一部のsome 定数伝播 (constant propagation) と インライン展開 (inlining) の後に生じるであろう)"*NULL" のようなケースでは、これはオプティマイ ザーがそのコードが到達可能にはなりえないことを知るのを可能にします。ここでの重要な wrinkle は (C standard says it must be 的に)コードが本当に死んでいるかどうかであるとか、 あるいは、(長い可能性もある) series of optimizations の後ではそれがバクかどうかをコン パイラーが知ることはできないということです。なぜならこれら二つを区別する generally good way は存在していないので、生成された警告のほとんどすべては false positives (ノイ ズ) になってしまうだろうからです。 Clang's Approach to Handling Undefined Behavior 未定義動作の handling に対する Clang のアプローチ Given the sorry state that we're in when it comes to undefined behavior, you might be wondering what Clang and LLVM are doing to try to improve the situation. I mentioned a couple of them already: the Clang Static Analyzer, Klee project, and the -fcatch-undefined-behavior flag are useful tools for tracking down some classes of these bugs. The problem is that these aren't as widely used as the compiler is, so anything we can do directly in the compiler offers even higher goodness than doing it in these other tools. Keep in mind though that the compiler is limited by not having dynamic information and by being limited to what it can without burning lots of compile time. 未定義動作へ come to しているときに the sorry state を与えて Clang と LLVM がその 状況を改善しようとしていることをあなたは不思議に思うかもしれません。そのうちの いくつかには既に触れました: Clang Static Analyzer, Klee project, -fcatch-undefined-behavior フラグといったものはこういったバグのクラスの一部を追跡するのに有用なツールです。 問題はこれらのツールがコンパイラーと同程度に広く使われているものではないので、 こういったほかのツールで行うこと以上のなにかを わたしたちはコンパイラーで直接 offer できることです。 コンパイラーは動的情報を持たないように、また、 コンパイル時間を爆発的に増大させることなくできることに 制限されているということを心に留めておいてください。 Clang's first step to improve the world's code is to turn on a whole lot more warnings by default than other compilers do. While some developers are disciplined and build with "-Wall -Wextra" (for example), many people don't know about these flags or don't bother to pass them. Turning more warnings on by default catches more bugs more of the time. An aspect of this that is specific to uninitialized variables is that Clang supports -Wuninitialized even when building at -O0. You may not be aware, but it is only possible to enable this warning with GCC when building at -O1 or higher. world's code を改良するための Clang の第一ステップは、他のコンパイラーが行っているより もさらに多くの警告をデフォルトで有効にすることです。一部の developer たちは (たとえば) "-Wall -Wextra" でビルドしていますが、多くの人はこれらのフラグを知りませんし、 don't bother to pass them です。デフォルトでもっと多くの警告を行うようにすることでより 多くのバグを捕捉できるようになります。 aspect of this のひとつである未初期化変数の特定は -O0 でビルドするときにさえ -Wuninitialized を Clangがサポートすることです。 あなたは気にしていなかったかもしれませんが、この警告は GCC では -O1 以上の指定をしてビルド をしたときにだけ有効にできるものです。 The second step is that Clang generates warnings for many classes of undefinedbehavior (including dereference of null, oversized shifts, etc) that are obvious in the code to catch some common mistakes. Some of the caveats are mentioned above, but these seem to work well in practice. 第二ステップは (null の dereference や oversized shifts 等を含む) コードの中で明らかに捕捉 可能な some common mistakes な未定義動作の many classes に対して Clang が warnings を生 成するというものです。caveats のいくつかはすでに言及しましたが、それらは実践においてはう まく動作するように見えるものなのです。 The third step is that the LLVM optimizer generally takes much less liberty with undefined behavior than it could. Though the standard says that any instance of undefined behavior has completely unbound effects on the program, this is not a particularly useful or developer friendly behavior to take advantage of. Instead, the LLVM optimizer handles these optimizations in a few different ways (the links describe rules of LLVM IR, not C, sorry!): 第三ステップは、LLVM オプティマイザーが未定義動作に対しては本来可能なものよりも一般的 には低い自由度しか take しないというものです。標準では未定義動作のすべての instance は プログラム上では完全に unbound な effects を持っているように書かれていますが、これは特 に有用なものではないし、take advantage of するような developer friendly な動作でもあり ません。代わりに LLVM オプティマイザーは a few different ways でこれらの最適化を取り扱 います (the links describe rules of LLVM IR, not C, sorry!): 1. Some cases of undefined behavior are silently transformed into implicitly trapping operations if there is a good way to do that. For example, with Clang, this C++ function: 未定義動作の一部のケースは、もし良い手段が存在しているのであれば silently に implicitly trapping operations へと transform されます。 たとえば Clang を使っているとき、 int *foo(long x) { return new int[x]; } compiles into this X86-64 machine code: この C++ 関数は次のような X86-64 機械語コードにコンパイルされます。 __Z3fool: movl $4, %ecx movq %rdi, %rax mulq %rcx movq $-1, %rdi # Set the size to -1 on overflow オーバーフローしたら -1 をセット cmovnoq %rax, %rdi # Which causes 'new' to throw std::bad_alloc 'new' が std::bad_alloc を throw する jmp __Znam instead of the code GCC produces: GCC では次のようなコードを生成します: __Z3fool: salq $2, %rdi jmp __Znam # Security bug on overflow! オーバーフロー時にセキュリティバグ! The difference here is that we've decided to invest a few cycles in preventing a potentially serious integer overflow bug that can lead to buffer overflows and exploits (operator new is typically fairly expensive, so the overhead is almost never noticable). The GCC folks have been aware of this since at least 2005 but haven't fixed this at the time of this writing. ここでの違いは、バッファオーバーフローや exploit に繋がりかねない深刻な整数オーバー フローバグの可能性を preventing するためにわたしたちが数サイクルを浪費 (invest) する ことを決断した点にあります (new 演算子は typically fairly expensive なのでそのオーバー ヘッドはほとんど noticable にはなりません)。GCC forks は少なくとも 2005年からこれを 認識していますが、この記事を書いている時点でもまだ修正されていません。 2. Arithmetic that operates on undefined values is considered to produce a undefined value instead of producing undefined behavior. The distinction is that undefined values can't format your hard drive or produce other undesirable effects. A useful refinement happens in cases where the arithmetic would produce the same output bits given any possible instance of the undefined value. For example, the optimizer assumes that the result of "undef & 1" has zeros for its top bits, treating only the low bit as undefined. This means that ((undef & 1) >> 1) is defined to be 0 in LLVM, not undefined. 未定義値に対する算術的な操作は、未定義値に対する操作ではなく未定義値を生成する操作と見な されます。その相違点は、未定義値はあなたのハードディスクをフォーマットすることはできない し、他の undesiable な効果を作り出したりもしないということです。 任意に与えた未定義値のインスタンスに対して算術演算が同じ出力ビットを生成する場合には useful refinement が起きます。 例えばオプティマイザーは "undef & 1" の結果が zeros for its top bits であると仮定して、low bit のみを undefined として扱います。 これはつまり、LLVM では ((undef & 1) >> 1) は undefined ではなく 0 と define されるということです。 3. Arithmetic that dynamically executes an undefined operation (such as a signed integer overflow) generates a logical trap value which poisons any computation based on it, but that does not destroy your entire program. This means that logic downstream from the undefined operation may be affected, but that your entire program isn't destroyed. This is why the optimizer ends up deleting code that operates on uninitialized variables, for example. (符号付き整数オーバーフローのような) 未定義操作を動的に実行する算術演算は それに基づいた計算のすべてを poison する logical trap value を生成しますが、 プログラム全体が破壊されることはありません。 これはつまり、未定義動作からの logic downstream は影響を受ける可能性があるけれども、 プログラム全体が破壊されることはない。ということです。これが、例えば 最終的に未初期化変数に対する操作を行っているコードをオプティマイザーが削除してしまう 理由です。 4. Stores to null and calls through null pointers are turned into a __builtin_trap() call (which turns into a trapping instruction like "ud2" on x86). These happen all of the time in optimized code (as the result of other transformations like inlining and constant propagation) and we used to just delete the blocks that contained them because they were "obviously unreachable". null への格納や null ポインターを通じた呼び出しは __builtin_trap() の呼び出しへと変換さ れます (この呼び出しは x86 上の場合 "ud2" のようなトラップ命令となります)。 これは (インライン化や定数伝播のような他の変換の結果として) 最適化されたコードで起きますが、 わたしたちはそういったものを含むブロックを単に削除します。 なぜなら“unreachable なのが明白”であるからです。 While (from a pedantic language lawyer standpoint) this is strictly true, we quickly learned that people do occasionally dereference null pointers, and having the code execution just fall into the top of the next function makes it very difficult to understand the problem. From the performance angle, the most important aspect of exposing these is to squash downstream code. Because of this, clang turns these into a runtime trap: if one of these is actually dynamically reached, the program stops immediately and can be debugged. The drawback of doing this is that we slightly bloat code by having these operations and having the conditions that control their predicates. これは (pedantic な言語弁護士の視点からすると) strictly に真ですが、ときにユーザーが null ポインターの dereference をすることや、次の関数の先頭に fall into して問題の理解を 非常に難しくしてしまうようなコードを実行してしまうことがあるのを我々は即座に学びました。 性能の観点からは、最も重要な aspect of exposing these は downstream code を squash することです。このために clang はそれらを runtime trap へ turn into しました: もし実際にこれらの一つに動的に到達したならば、プログラムは即座に停止してデバッグ可能と なります。これを行うための drawkback は、 these operations とその predicates を制御する conditions とを持つことでコードを 大幅に bloat させてしまうことです。 5. The optimizer does go to some effort to "do the right thing" when it is obvious what the programmer meant (such as code that does "*(int*)P" when P is a pointer to float). This helps in many common cases, but you really don't want to rely on this, and there are lots of examples that you might think are "obvious" that aren't after a long series of transformations have been applied to your code. オプティマイザーは "do the right thing" (正しく最適化を行う) ために (such as code that does "*(int*)P" when P is a pointer to float) プログラマーの意図が明確であるときに多少の努力をします。 これは多くの common case を救済しますが、実際はこれに頼ろうとは望まないでしょうし a long series of transformations があなたのコードに適用されたあとで “明白である”と あなたが考えるかもしれないたくさんの例があります 6. Optimizations that don't fall into any of these categories, such the zero_array and set/call examples in Part #1 are optimized as described, silently, without any indication to the user. We do this because we don't have anything useful to say, and it is very uncommon for (buggy) real-world code to be broken by these optimizations. 上記のどのカテゴリにも当てはまらない、 Part #1 での例にあった zero_array や set/call のような最適化は、すでに説明したように silently に、ユーザーに対する indication は 一切なしに行われます。言及すべき anything useful を持っていないし、これらの最適化で 壊れる (バギーな) 現実世界のコードにとってとても一般的なので、わたしたちはこの暗黙の 最適化を行います。 One major area of improvement we can make is with respect to trap insertion. I think it would be interesting to add an (off-by-default) warning flag that would cause the optimizer to warn whenever it generates a trap instruction. This would be extremely noisy for some codebases, but could be useful for others. The first limiting factor here is the infrastructure work to make the optimizer produce warnings: it doesn't have useful source code location information unless debugging information is turned on (but this could be fixed). わたしたちが改良できた one major area は respect to trap insertion を伴っています。trap 命 令を生成したときはいつでもオプティマイザーに警告させる warning flag (デフォルトではオ フ) を追加するのは intersting であろうとわたしは考えます。これは一部のコードベースに対 しては extermely noisy になるでしょうが、そのほかのものには有用かもしれません。最初の limiting factor はオプティマイザーに警告を生成させるための infrastructure work です: オプティマイザーは、デバッグ情報が有効にされない限り有用なソースコードの位置情報を持っ ていません (ただしこれは修正できるでしょう)。 The other, more significant, limiting factor is that the warning wouldn't have any of the "tracking"information to be able to explain that an operation is the result of unrolling a loop three times and inlining it through four levels of function calls. At best we'll be able to point out the file/line/column of the original operation, which will be useful in the most trivial cases, but is likely to be extremely confusing in other cases. In any event, this hasn't been a high priority for us to implement because a) it isn't likely to give a good experience b) we won't be able to turn it on by default, and c) is a lot of work to implement. 別のより significant な limiting facor は、ある操作がループを三回アンローリングしさら に4レベルの関数呼び出しのインライン展開を行った結果であることを説明することが可能な“ tracking”情報を warning が 一切持っていないことです。at best で original operation の ファイル/行/カラム の point out は可能でしょうが、それは大部分の trivial cases で useful であろうけれども別のケースでは extremely に混乱するものとなるでしょう。 In any event, これはわたしたちが実装する対象として high priority になることはありませんでした。 それは a) good experience をもたらさないであろう b) デフォルトで有効にはしたくない c) 実装にとても手間が掛かる といった理由からです。 Using a Safer Dialect of C (and other options) 安全な C の方言 (やその他のオプション) を使う A final option you have if you don't care about "ultimate performance", is to use various compiler flags to enable dialects of C that eliminate these undefined behaviors. For example, using the -fwrapv flag eliminates undefined behavior that results from signed integer overflow (however, note that it does not eliminate possible integer overflow security vulnerabilities). The -fno-strict-aliasing flag disables Type Based Alias Analysis, so you are free to ignore these type rules. If there was demand, we could add a flag to Clang that implicitly zeros all local variables, one that inserts an "and" operation before each shift with a variable shift count, etc. Unfortunately, there is no tractable way to completely eliminate undefined behavior from C without breaking the ABI and completely destroying its performance. The other problem with this is that you're not writing C anymore, you're writing a similar, but non-portable dialect of C. "ultimate performance" (最終的な性能) について don't care であるときにあなたの 手にある最後の選択肢は、これらの未定義動作を除去する dialects of C を有効にするための様々 なコンパイラーフラグを使うことです。たとえば符号付き整数オーバーフローの結果による未定義 動作を削除するフラグである -fwrapv を使う (ただし整数オーバーフローによる security vulnerabilities の可能性は削除しないことに注意すること) といったものがあります。 -fno-strict-aliasing フラグ は Type Based Alias Analysis を無効にしてしまうので、これ らの型規則を自由に無視できます。仮に要求があったならば、Clang にすべてのローカル変数を implicitly にゼロにしたりシフトカウントを変数で指定している各シフトの前に“and”演算を 挿入させるフラグを追加できたでしょう。残念ながら、ABI を壊したりパフォーマンスを完全に 破壊することなくC から未定義動作を完全に eliminate する tractable way はありません。そ れに伴うもうひとつの問題は、あなたが書くそれはもはや C ではなく、C と似てはいても移植 性のない C の方言にすぎないということです。 If writing code in a non-portable dialect of C isn't your thing, then the -ftrapv and -fcatch-undefined-behavior flags (along with the other tools mentioned before) can be useful weapons in your arsenal to track down these sorts of bugs. Enabling them in your debug builds can be a great way to find related bugs early. These flags can also be useful in production code if you are building security critical applications. While they provide no guarantee that they will find all bugs, they do find a useful subset of bugs. 移植性のない C の方言でコードを書くのが your thing でないのなら、(すでに言及した他のツ ールの他にも) -ftrapv や -fcatch-undefined-behavior といったフラグはこの種のバグを track down するためのあなたの武器庫 (your arsenal)に収められた useful weapons になるか もしれません。デバッグビルドでこれらのフラグを有効にすることは関連するバグを早期に発見 する great way になるでしょう。あなたが serurity critical なアプリケーションを構築して いるのならproduction コードにおいてもこれらのフラグは useful かもしれません。また(そう いったフラグは)、すべてのバグを見つけ出す保証はしませんが、バグの useful subset を見つ け出してくれるでしょう。 Ultimately, the real problem here is that C just isn't a "safe" language and that (despite its success and popularity) many people do not really understand how the language works. In its decades of evolution prior to standardization in 1989, C migrated from being a "low level systems programming language that was a tiny layer above PDP assembly" to being a "low level systems programming language, trying to provide decent performance by breaking many people's expectations". On the one hand, these C "cheats" almost always work and code is generally more performant because of it (and in some cases, much more performant). On the other hand, the places where C cheats are often some of the most surprising to people and typically strike at the worst possible time. 結論としては、ここでの本当の問題は C が単に“安全な”言語ではないということと、(その成 功と popularity にも関わらず) 多くの人がC という言語がどのように動作するのかを本当には 理解していないということです。1989 年の標準化に先立つ長年にわたる進化 (decades of evolution) の過程で C は、「PDP のアセンブリ上にある tiny layer にすぎない低水準のプロ グラミング言語」("low level systems programming language that was a tiny layer above PDP assembly") から 「多くの人たちの expectaions を breaking することによっ てまずまずの性能 (decent performance) を提供することを試みる低水準のシステムプログラミ ング言語」("low level systems programming language, trying to provide decent performance by breaking many people's expectations") へと migrated しました。 一面ではこういった C の“チート”はほぼ常にうまくいき、コードはチートによって一般的に はより性能の良いものになります(一部のケースではかなり向上します)。その反面、 the places where C cheats は often some of the most surprising to people であり、 typically strike at the worst possible time でした。 C is much more than a portable assembler, sometimes in very surprising ways. I hope this discussion helps explain some of the issues behind undefined behavior in C, at least from a compiler implementer's viewpoint. C は portable assembler をはるかに超え、とても驚くようなやり方で使われることがあります。 わたしはこの discussion が、少なくともコンパイラーの実装者視点からの C の未定義動作の背後に隠れている issues のいくつかを説明するのを助けることを希望します。 -Chris Lattner Posted by Chris Lattner at 12:48 AMAbout The LLVM Blog This blog is intended to be a news feed for information about the LLVM Compiler Infrastructure and related subprojects. Note that comments are disabled here, we prefer you to respond on mailing lists like llvmdev or cfe-dev. We welcome new contributors. If you'd like to write a post, please get in touch with Chris.
おおっと、RubyKaigiのチケットの印刷
数学セミナーが置いてないんじゃよ。 渋谷のジュンク堂あたりまでは出ないとダメかなあ。
たいたにあ
原作小説再開の話ってのはどこ行っちゃったんだろう
同じ言葉でも言った人が違うと
：【ナポレオン】長谷川哲也32【笑う殺し屋】 864 名無しんぼ＠お腹いっぱい [sage] 2011/07/11(月) 18:43:29.24 ID:faIPjIru0 Be: マッセナ「人の嫌がることを進んでします」 ベルティエ「人の嫌がることを進んでします」 865 名無しんぼ＠お腹いっぱい [sage] 2011/07/11(月) 21:15:42.30 ID:f3Dzp44r0 Be: 同じ言葉でも全然違う意味に聞こえる！ 不思議！ 866 名無しんぼ＠お腹いっぱい [sage] 2011/07/12(火) 02:32:53.89 ID:vca4P3go0 Be: ベルティエじゃないな、そこは あれ、長谷川ナポで良い人枠って思いつかない… 867 名無しんぼ＠お腹いっぱい [sage] 2011/07/12(火) 06:41:38.98 ID:4msYZs290 Be: 先月のダヴーとか 868 名無しんぼ＠お腹いっぱい [sage] 2011/07/12(火) 09:48:22.58 ID:dJY3j52+0 Be: サンソン「人の嫌がることを進んでします」 869 名無しんぼ＠お腹いっぱい [sage] 2011/07/12(火) 10:06:32.36 ID:pyc10L8T0 Be: 長谷川ナポでは、処刑人サンソンが一番良い人かもしれないね
どれも一言二言言いたいところだけど、ひとつに絞って。
気分はどうしようもなくSE: ドキュメントの錬金術師 ●Break臭 While文を無条件に使用しまくると、発生する腐臭です。 While(1) { … } みたいな処理があちこちにありました。無限に処理を繰り返したい場合など、書きたくなるコー ドではありますね。 でも、無限ってなんでしょうね？ どこまで行ったら終りになるのか？ その終わりっていうの が実は重要なのではと思ってしまいます。 で、実際、無限に処理をするわけではないので、どこかで処理を終わらせる必要があります。 その時に使うコマンドが break; です。 この一行で、処理中にループの外に飛び出すことが出来ます。まさに「ブレーク」してしまう わけです。さて、While文が１重だったら、読み解くのは楽です。 しかし、これが While(1) { While(1) { While(1) { While(1) { … } … } … } … } って感じだったら（笑）。そして、あちこちに、Breakコマンドが散乱していたら…。もう、そ こら辺のものを破壊したくなりますよね。実際に、頭にきてロッカーを壊した奴もいました。（笑） そして、for文でも、同じような無限ループが作れます。こっちの場合は、もっと意味不明で すね。なぜfor文で無限ループなのでしょうか？人智を超えた産物なのでしょうか。深く突っ込 むことが出来ません。Copyright(c) 2000-2011 ITmedia Inc.
C の話をしているっぽいのですが、「コマンド」ってなんなんでしょ。 まあそれはさておき。
ループが多重にネストすることと、それが無限ループかどうかってのは独立した話だと思うんですけどね。 上記のパターンで問題なのは過剰にループがネストしていることなのではないでしょうか。 それをつかまえて「break臭」と名づけるのもよくわからない。
while の条件式でループの継続判定をせずに無限ループにしておいて、 ループ本体にある条件文と「breakコマンド」でループから抜けるというやり方を ひどく責めておいでですけど、
条件判定のための処理
while (条件判定) {
何かの処理
条件判定のための処理
}
となるような処理のパターンって結構ありませんか? (これは単純に do～while()には置き換えられません) この、条件判定のための処理を二回書くのはあまりよろしくないし、ひとつにまとめたい。 となれば
while (true) {
条件判定のための処理
終了? → break
何かの処理
}
となるのは不自然ではないでしょう。
for文云々についてはいちゃもんつけたいがためのいちゃもんの気がするのでパス (ってブーメラン飛ばした気がするなあ)。
Python Insider: A Python Launcher For Windows A Python Launcher For Windows Windows のためのPython ランチャー Mark Hammond (author of pywin32 and long-time supporter of Python on Windows) has written PEP 397, which describes a new launcher for Python on Windows. Vinay Sanjip (author of the standard library logging module) has recently created an implementation of the launcher, downloadable from https://bitbucket.org/vinay.sajip/pylauncher/downloads Mark Hammond (pywin32 の作者であり、長期にわたって Python on Windows のサポーター を務めています) は Python on Windows のための新しいランチャーを説明する PEP 397 を 書きました。Vinay Sanip (標準ライブラリにあるロギングモジュールの作者)は 最近このランチャーの実装を行いました。 The launcher allows Python scripts (.py and .pyw files) on Windows to specify the version of Python which should be used, allowing simultaneous use of Python 2 and 3. このランチャーはWindows上で Python スクリプトが使用すべき Python のバージョンの 指定を可能にするものです。 Windows users should consider downloading the launcher and testing it, to help the Python developers iron out any remaining issues. The launcher is packaged as a standalone application, and will support currently available versions of Python. The intention is that once the launcher is finalised, it will be included as part of Python 3.3 (although it will remain available as a standalone download for users of earlier versions). Python developers が any remaing issues を iron out するのを助けるために、 Windwos ユーザーはこのランチャーをダウンロードして試してみるべきでしょう。 ランチャーはスタンドアローンのアプリケーションとしてパッケージされていて、 現在使用可能なバージョンのPythonをサポートするでしょう。 その意図するところは、ランチャーを完成させることによって Python 3.3 の一部に含めてしまうことです (although it will remain available as a standalone download for users of earlier versions)。 Two versions of the launcher are available - launcher.msi which installs in the Program Files directory, and launchsys.msi which installs in Windows' System32 directory. (There are also 64-bit versions for 64-bit versions of Windows). Some Details About the Launcher The full specification of the behaviour of the launcher is given in PEP 397. To summarise the basic principles: ランチャーの動作についての full specificaion は PEP 397 にあります。 * The launcher supplies two executables - py.exe (the console version) and pyw.exe (the GUI version). ランチャーにはコンソールバージョンとGUIバージョンの二つの実行ファイルがあります * The launcher is registered as the handler for .py (console) and .pyw (GUI) file extensions. ランチャーは .py および .pyw のファイル拡張に対するハンドラーとして登録されます * When executing a script, the launcher looks for a Unix-style #! (shebang) line in the script. It recognises executable names python (system default python), python2 (default Python 2 release) and python3 (default Python 3 release). The precise details can easily be customised on a per-user or per-machine basis. スクリプトを実行する際に、ランチャーはそのスクリプトから Unix 形式の #! (shebang) 行を探します。 そこにある記述により python の実行ファイル名 (システムのデフォルトのpython)、 python2 (デフォルトの Python 2 リリース)の実行ファイル名、 python3 (デフォルトの Python 3 リリース)の実行ファイル名を認識します。 The precise details can easily be customised on a per-user or per-machine basis. * When used standalone, the py.exe command launches the Python interactive interpreter. Command line switches are supported, so that py -2 launches Python 2, py -3 launches Python 3, and py launches the default version. スタンドアローンで使われたとき、py.exe はPythonの対話的インタープリターを起動します。 コマンドラインスイッチがサポートされていて、py -2 とすると Python 2を、 py -3 とすると Python 3 を起動します。py とした場合はデフォルトバージョンを起動します。 Simple Usage Instructions
あれもこれも手付かずだがや
例の !!~ もあったりして、コマンドラインからいじれるJavaScriptをビルドしようとしたんですが (結構前のSpiderMonkeyでもやりましたが新しいので)、こけまして 色々調べてたらこういうのが引っかかっりました。
javascript - building mozilla NSPR using MinGw on windows without VC++ - Stack Overflow I need to use spidermonkey for my perl javascript engine. For that I need to build spidermonkey with thread-safe libraries. So as I understand I need to first build NSPR and then spidermonkey. So, as I understood from following link https://developer.mozilla.org/en/NSPR_build_instructions I first downloaded the mozilla-build and opened the mingw. I followed the instructions as mentioned like creating target.debug directory and so on ..... when I am doing make, I am getting following error message make[3]: nsinstall: Command not found make[3]: *** [export] Error 127 make[3]: Leaving directory `/c/target.debug/pr/include/md' make[2]: *** [export] Error 2 make[2]: Leaving directory `/c/target.debug/pr/include' make[1]: *** [export] Error 2 make[1]: Leaving directory `/c/target.debug/pr' make: *** [export] Error 2 looks like nsinstall is missing. I am not a professional programmer in C/C++ so looking for your help. I need to successfully build the spidermonkey on window using Mingw. I tried to follow the steps as mentioned in following link: http://jargon.ca/spidermonkey/ but when I am running the js.exe, it's complaining about missing libnspr4.dll file. So please help me how can I build nspr and spidermonkey on windows operating system.There is no straight forward way on Windows. You have two options to do that. Either follow instructions on: 1. Compiming Mozilla with MinGW 2. Or satisfy the pre-requisities mentioned on Windows pre-requisities page and start compiling. I have not personally tried the 1st option, but for second option you will need Microsoft Visual Studio to work with. Then again, if you need just NSPR 4 why don't you pull out those files from your Firefox installation directoy? I guess the DLLs are named something like nspr4.dll, plc4.dll and plds4.dll.site design / logo © 2011 stack exchange inc; user contributions licensed under cc-wiki with attribution required
なんか面倒くさそうだなあ。 VCあるし、こっちでやるか(^^;
睡眠睡眠睡眠睡眠不足♪
一つ前へ
2011年7月(上旬)
一つ後へ
2011年7月(下旬)
リンクはご自由にどうぞ
メールの宛先はこちら