■_
・Amazon.co.jp: ブラック会社に勤めてるんだが、もう俺は限界かもしれない: 黒井勇人: 本 を本屋で見かけたがとりあえず様子見。
・7月1日付でちょっと組織変更。 でもわしには(直接は)関係ない。
一つ前へ
2008年6月(中旬)
一つ後へ
2008年7月(上旬)
・Amazon.co.jp: ブラック会社に勤めてるんだが、もう俺は限界かもしれない: 黒井勇人: 本 を本屋で見かけたがとりあえず様子見。
・7月1日付でちょっと組織変更。 でもわしには(直接は)関係ない。
John Graham-Cumming: Advice to a young programmer
John Graham-Cumming: Advice to a young programmer Advice to a young programmer I received a mail from an acquaintance who'd come to the realization that his 13-year-old wanted to be programmer, specifically a games programmer. Here's the advice I gave. Perhaps others have things to add: 1. I'm tempted to tell you that the right way to learn to be a programmer is to start with LISP, or the lambda calculus, or even denotational semantics but you can come back to those after a few years getting your feet wet. プログラマになる正しい学び方はLISPから始めることです。 あるいはλ算法や denotational semantics でもよいです。 まあ何年かたってからこれらに取り組んでもよいです。 2. Lots of programming involves logic (or at least thinking logically) so learning about and enjoying logic is probably a good foundation. You could start by learning about boolean algebra since it's simple and fun and the basis for a lot of what computers do. プログラミングの多くはロジックを必須のものとしていますから、ロジックについて 学んだり楽しむことはおそらく良い基礎となるでしょう。 boolean algebra は単純で楽しくコンピュータが行うことの多くの基礎となるものなので これから始めてもいいかもしれません。 3. Since games programmer involves a lot of physics, you should also learn about Newton's Three Laws and Universal Gravitation and play around with things like springs and pendulums. ゲームプログラマは物理に関連する多くのことを必須としています。 あなたはニュートンの Three Laws と Universal Gravitation についても学ぶべきで、 ばねや振り子のようなものについてそれらを試してみるべきです。 4. Basic trigonmetry is important to the games programmer. It'll be handy to know about Pythagoras and the relationship with sin, cos and tan. 基本的な三角関数はゲームプログラマにとって重要なことです。 ピタゴラス(の定理?)とサイン、コサイン、タンジェントとの関係を知っておくと良いでしょう。 5. Above all, start with a programming language and a good book and commence hacking: try stuff out, make little simple programs (even if it's a program that prints out "Hello" on the screen, or a program that prints out "Hello" ten times, or asks you for the number of times to print "Hello" and then does it). Just write code, whatever takes your fancy. ここまできたら、プログラミング言語と良い参考書でもってハッキングをはじめましょう。 小さく単純なプログラムを作ってみましょう(たとえそれが単に 'Hello' とスクリーンに 出力するものでもかまいませんし、'Hello'を十回出力するとか、あなたに何回繰り返すかを 尋ねてその回数だけ出力するというものでも良いです)。 Just write code, whatever takes your fancy. 6. A good starting language is Python. Get the O'Reilly book Learning Python. 入門に使う言語にはPythonが良いです。 O'Reillyの本を買って、Pythonを学びましょう。 7. Python is dynamic so you'll be able to make progress very quickly, but for games programming you are probably going to need to get a little closer to the machine. And for that you should learn C by reading the classic The C Programming Language. Pythonは動的な言語なので非常にすばやく進めていくことが可能ですが、 ゲームプログラミングのためにはあなたはもっと機械に密着する必要にせまられてくるはずです。 そのためにも、古典的な名著である “The C Programming Language”(邦訳 プログラミング言語 C) を読んで学んでおくべきです。 8. As you learn more there are some great books that will expand on what you can do: read Programming Pearls and The Practice of Programming. Think about getting: Algorithms in C. Read Structure and Interpretation of Computer Programs. 良い本を何冊か読んでいけば、あなたができることは格段に多くなるでしょう。 Programming Pearls (邦訳 珠玉のプログラミング) や The Practice of Programming (邦訳 プログラミング作法)を読みましょう。 また、Algorithms in C (邦訳 アルゴリズム C) や Structure and Interpretation of Computer Programs (邦訳 プログラムの構造と実行) を読みましょう。 9. Also: avoid debuggers, learn to unit test. Debuggers are useful in limited circumstances, most code can be debugged by using your head and a few 'print's. Unit tests will save your life as you go forward. デバッガは使わないようにして、ユニットテストについて学びましょう。 デバッガが便利なのは限定された条件の場合なので、ほとんどのコードはあなたの おつむと少々の 'print' でデバッグすることができます。 ユニットテストはあなたの人生の無駄遣いを防いでくれます。 10. When you are ready, try to write a version of the first ever computer game: Spacewar! 準備が整ったら、最初のコンピュータゲームを作るのに挑戦してみましょう。 そう、Spacewar です! ... 11. When your first company goes public think of me; I'll be an old man and probably won't have saved enough for retirement.
いわゆるUMPCとかミニノートってのが一台欲しいんですが、どうもこれというのがないですねえ。
マウス、約6万円のNetbook「LuvBook U100」 - 重量1.16kg & 10.2型液晶 | パソコン | マイコミジャーナル 仕様は、CPUがAtom N270(1.60GHz)、チップセットがIntel 945GSE Express、メモリが1GB DDR2 SDRAM(オンボード)。グラフィックス機能はチップセット内蔵のIntel GMA 950を利用する。スト レージは80GB SATA HDD。その他の機能は、IEEE802.11b/g対応無線LAN、10/100Base-TX対応有線 LAN、130万画素Webカメラ、4-in-1カードリーダー、USB 2.0など。OSはWindows XP Home Editionがプリインストールされている。 本体サイズは260(W)×180(D)×19.0~31.5(H)mm、重量は1.16kgで、バッテリ駆動時間は約2.5時間 (いずれも3セルバッテリ時)。
MSIのEee PC対抗ノートが日本上陸、5万9800円で7月4日発売:ITpro チップセットはIntel 945GSE+ICH7M、グラフィックスはチップセット内蔵のIntel GMA950。主 なインタフェースは、USB 2.0×3、LAN、無線LAN(b/g)、アナログRGB、メモリーカード(SD/ メモリースティック兼用)など。標準添付の3セルのバッテリーパックを用いた場合、バッテリ ー駆動時間は約2.5時間。オプションの6セルの大容量バッテリーパックを用いると、バッテリー 駆動時間は6時間となる。外形寸法は幅260×奥行き180×高さ19~31.5mm、重さは1kg。プリインス トールOSはWindows XP Home Edition。きょう体色は黒とピンクの2種類を用意する。
こいつらって、サイズだけ見ると
パナソニック、Core 2 Duo U7500を搭載した「Let'snote R6/T5/W5」 インターフェイスはUSB 2.0×2、Type2 PCカードスロット×1、SDカードスロット、IEEE 802.11a/b/g無線LAN、Ethernet、ミニD-Sub15ピン、ミニポートリプリケーターコネクタなどを 備える。 バッテリはリチウムイオンで、駆動時間は約7.5時間。本体サイズは229×187×29.4~42.5mm(同)、 重量は約940g。
Let's Note のRシリーズと大差ないような…(値段はぜんぜん違いますがw)
今日(6/30)、「来月の出版予定」ということで案内のメールが来たんですが
O'Reilly Japan News 第125号 2008-06-30
/==========================================================
このメールは、オライリー・ジャパン発行書籍に同封されている
読者カードまたはWebサイト、電子メールにより購読をお申し込み
いただいた方に配信しております。もし間違いで受信したと思わ
れる方がいらっしゃいましたら、お手数ですが japan@oreilly.co.jp
までお知らせください。
==========================================================/
Bookclubへ参加の皆様、お元気ですか?
今月よりBookclub Newsがパワーアップします。従来のメールに
加え、オライリーWebサイト上に専用ページを設けて、より視覚的に
書籍の最新情報をお伝えいたします。これまでのBookclub News Mail
と同様、オライリーの書籍を知るツールとしてご活用いただけたら
幸いです。ご意見やご要望などもお寄せください。
Bookclub News Web
http://www.oreilly.co.jp/bookclub/news/
では最新のニュースをお伝えします。
===========================================================
●New Release
今月発売される新刊書籍を4点ご紹介します。お買い逃しのないよう
ご確認ください。
-----------------------------------------------------------
■Head First SQL ― 頭とからだで覚えるSQLの基本
イラストや写真を使って、やさしく楽しく深く身につける
Lynn Beighley 著
佐藤 直生 監訳
松永 多苗子 訳
2008年06月07日 発売
608ページ
定価4,410円
ISBN978-4-87311-369-2
(ry
-----------------------------------------------------------
■ミニマルPerl― Unix/LinuxユーザのためのPerl習得法
学習は小さくシンプルに、実用性とパワーはそのままに
Tim Maher 著
安藤 慶一、磯部 孝一郎 訳
2008年06月20日 発売予定
484ページ
定価4,410円
ISBN978-4-87311-368-5
(ry
-----------------------------------------------------------
■JavaScript & DHTMLクックブック 第2版
― Webエキスパート必携テクニック集
AjaxやDOMスクリプティングを追加し、堂々の改訂
Danny Goodman 著
村上 列 訳
2008年06月21日 発売
592ページ
定価4,410円
ISBN978-4-87311-370-8
(ry
-----------------------------------------------------------
■初めてのRuby
日本人著者の書き下ろしによるRubyの基礎知識。Ruby1.8、1.9対応
Yugui 著
2008年06月25日 発売
224ページ
定価2,310円
ISBN978-4-87311-367-8
(ry
===========================================================
●Coming Soon
来月発売予定の書籍情報です。7月は以下の2点。鋭意制作中につき、
楽しみにお待ちください。
-----------------------------------------------------------
■集合知プログラミング
Webアプリに「集合知」を実装するための実践的な解説書
Toby Segaran 著
當山 仁健、鴨澤 眞夫 訳
定価3,570円
(ry
-----------------------------------------------------------
■Prototype & script.aculo.us
― JavaScriptライブラリによるAjaxアプリケーション開発
人気のJavaScriptライブラリ「prototype.js」と「script.aculo.us」
を詳しく解説
Christophe Porteneuve 著
栗山 淳 監訳、吉田 遼二 訳
定価3,360円
(ry
===========================================================
●Event, News
■Event:RubyKaigi 2008 著者Yuguiさんのサイン会を開催
■Event:Interop Tokyo 2008 大勢のご来場、ありがとうございました
===========================================================
… あれ?
推薦図書/必読書のためのスレッド 40 807 デフォルトの名無しさん [sage] Date:2008/06/30(月) 00:19:22 ID: Be: S式で反論してやろうかこの野郎 812 デフォルトの名無しさん [sage] Date:2008/06/30(月) 01:06:46 ID: Be: >>807 この攻撃性がLisperの正体だねw Gaucheなんか使う奴はクソ 813 デフォルトの名無しさん [sage] Date:2008/06/30(月) 01:47:51 ID: Be: くぁぁぁぁぁぁぁぁむかついた 814 デフォルトの名無しさん [sage] Date:2008/06/30(月) 02:02:52 ID: Be: gauche本って初心者向けだよね? 815 デフォルトの名無しさん [sage] Date:2008/06/30(月) 02:29:09 ID: Be: 俺もLispは好きだけどこのスレにはLisperがいるのか? 816 デフォルトの名無しさん [sage] Date:2008/06/30(月) 02:38:07 ID: Be: >>814 ターゲットは恐らく ただ、Scheme処理系の一つとしてのGaucheを 紹介する本も兼ねてるんだと思う 817 デフォルトの名無しさん [sage] Date:2008/06/30(月) 02:38:56 ID: Be: GaucheはLispではない。Schemeだ。 818 デフォルトの名無しさん [sage] Date:2008/06/30(月) 05:05:07 ID: Be: SchemeはLispだろw 819 デフォルトの名無しさん [sage] Date:2008/06/30(月) 06:12:13 ID: Be: C++を教えると言ってる人にLispを強要するGauche厨って頭おかしいのかね? 820 デフォルトの名無しさん [sage] Date:2008/06/30(月) 06:25:58 ID: Be: そんなレスはどこにも見当たらないのだが 821 デフォルトの名無しさん [sage] Date:2008/06/30(月) 07:40:39 ID: Be: SchemaはLispではない 長兄を裏切ったSchemaはLispではない 裏切ったSchemaはLispではない 822 デフォルトの名無しさん [sage] Date:2008/06/30(月) 08:58:06 ID: Be: >>815 アンチLispがいるだけ。 823 デフォルトの名無しさん [sage] Date:2008/06/30(月) 10:05:57 ID: Be: schema? 824 デフォルトの名無しさん [sage] Date:2008/06/30(月) 12:15:53 ID: Be: ドーン!!!! 825 デフォルトの名無しさん [sage] Date:2008/06/30(月) 12:39:27 ID: Be: >>818 >端的に言ってしまえば Scheme は Lisp ではないです。 この2つを混同するのは味噌糞いっしょ、ってやつで、つつしむべきです。 > Confusing Common Lisp and Scheme is permissible once in a human life. -- Erik Naggum SchemeとLispを一緒にするのはカトリックとモルモン教を一緒にするようなもん 826 デフォルトの名無しさん [sage] Date:2008/06/30(月) 12:48:12 ID: Be: 順番のまま紐付けると、 Lispがモルモン教ということですね、わかります。 827 デフォルトの名無しさん [sage] Date:2008/06/30(月) 12:53:24 ID: Be: >>825 下の英文は「Common Lisp」とSchemeを混同するなという 趣旨の文だ どうやら上の文を書いた人は「Common Lisp」と もう少し大きな分類である「Lisp」を混同してしまってるようだな 828 デフォルトの名無しさん [sage] Date:2008/06/30(月) 12:55:27 ID: Be: その文だけだとCommon LispとSchemeを比較しているだけに読めるが どこにSchemeはLispではないと書いてあるんだ? 829 デフォルトの名無しさん [sage] Date:2008/06/30(月) 12:59:45 ID: Be: 「端的に言ってしまえば Scheme は Lisp ではない」 と思いっきり書いてあるな 830 デフォルトの名無しさん [sage] Date:2008/06/30(月) 13:02:50 ID: Be: >>827 Lispといったら今はCommon Lispだろ。 アメリカと言ったら、USAを指してラテンアメリカやカナダを指さないのと 同じこと。 英文は孫引用だから、詳細がしりたければ日本語のほうをぐぐってほしい 831 デフォルトの名無しさん [sage] Date:2008/06/30(月) 13:07:13 ID: Be: は?SchemeがCommon Lispじゃないのは当たり前だろ そんなところにわざわざ異議を唱える奴なんて居るの? カナダがUSAじゃないとわざわざ主張する馬鹿がいないのと一緒 832 デフォルトの名無しさん [sage] Date:2008/06/30(月) 13:09:18 ID: Be: >>831 >端的に言ってしまえば Scheme は Lisp ではないです これ書いてる人はMSIの中の人 833 デフォルトの名無しさん [sage] Date:2008/06/30(月) 13:09:39 ID: Be: スレタイ 834 デフォルトの名無しさん [sage] Date:2008/06/30(月) 13:16:06 ID: Be: >>832 で? どう考えてもSchemeが、もっと大きな分類である「Lisp」の仲間 として認められないという趣旨の主張だろう しかしながら、英文の方はSchemeが「Common Lisp」ではないという 当たり前のことを注意してるだけ 835 デフォルトの名無しさん [sage] Date:2008/06/30(月) 13:18:30 ID: Be: で?英文にこだわるなよ頭固いな。 836 デフォルトの名無しさん [sage] Date:2008/06/30(月) 13:19:14 ID: Be: このスレで続けんなよ、頭悪いな 837 デフォルトの名無しさん [sage] Date:2008/06/30(月) 13:19:42 ID: Be: 根拠としてるらしい英文の引用の仕方が間違ってるってこと 838 デフォルトの名無しさん [sage] Date:2008/06/30(月) 13:24:15 ID: Be: ああ、Shiroさんに反論されちゃったやつねw 839 デフォルトの名無しさん [sage] Date:2008/06/30(月) 14:24:34 ID: Be: つまり >6gt;825 が引用した 「端的に~」を書いた人は、 「Confusing Common Lisp~」を引用して権威付けようとしたけど、 引用元はCommon Lispなので無意味でした (まる) ってことですかね。
アラン・ケイも認めた!Ruby>>>>>Smalltalk 214 デフォルトの名無しさん [sage] Date:2008/05/16(金) 07:19:42 ID: Be: LLに押されて話題にも出なくなったね 215 デフォルトの名無しさん [sage] Date:2008/05/20(火) 01:56:48 ID: Be: mod_SmalltalkとかあればLLなんぞ と思ってぐぐったら12件海外サイト出てくるな よくわからんらん 216 デフォルトの名無しさん [sage] Date:2008/06/25(水) 22:18:41 ID: Be: やっぱ最終決戦はLisp vs Smalltak ですな。 時代が追いつくよ 217 デフォルトの名無しさん [sage] Date:2008/06/25(水) 22:37:13 ID: Be: そうは言ってもPGやMatzに言わせればSmalltalkもLispだからな。ケンカにならんだろ。 218 デフォルトの名無しさん [sage] Date:2008/06/25(水) 22:53:56 ID: Be: PG って略すの始めて見た 219 デフォルトの名無しさん [sage] Date:2008/06/25(水) 22:58:41 ID: Be: なぜかポールギルバートが頭に浮かんだ 220 デフォルトの名無しさん [] Date:2008/06/26(木) 13:44:47 ID: Be: ぽーるぐらはむ? 221 デフォルトの名無しさん [sage] Date:2008/06/26(木) 14:08:27 ID: Be: ぐれあむ、のほうがいいかも。 222 デフォルトの名無しさん [sage] Date:2008/06/26(木) 23:33:53 ID: Be: 「身持ちが堅いな!ガンダム!!」 (デュナメスに焦れて) 「括目させてもらおう、ガンダム」 「抱きしめたいな!ガンダム!! まさに、眠り姫だ」 (デュナメスを鹵獲した際) 「堪忍袋の緒が切れた!許さんぞ!ガンダム!」 (エイフマン教授の死を聞いて) 「私の顔に何度泥を塗れば気が済むのだ!!....ガンダム...ッ!!」 「彼は私以上にフラッグを愛していたようだな。ならばハワード・メイスンに宣誓しよう。 私、グラハム=エーカーは、フラッグを駆ってガンダムを倒すことを」 (ハワードの墓前で) 223 デフォルトの名無しさん [sage] Date:2008/06/27(金) 08:39:22 ID: Be: それ、グラハム・エイカー 224 デフォルトの名無しさん [] Date:2008/06/29(日) 01:34:37 ID: Be: なんでここでガンダム00wwww
【C++】STL(Standard Template Library)相談室 9 795 デフォルトの名無しさん [sage] Date:2008/06/28(土) 20:43:54 ID: Be: どうでもいいけどistream_iterator<char>使うな istreambuf_iterator<char>使え istream_iterator<char>はoperator>>で入力するから、空白とか スキップする。コピーにならんぞ 796 デフォルトの名無しさん [sage] Date:2008/06/28(土) 20:57:41 ID: Be: どうでもいい割には念を押すね。 797 デフォルトの名無しさん [sage] Date:2008/06/28(土) 21:09:48 ID: Be: >>795 それ「どうでもいい」事じゃないと思うw 798 デフォルトの名無しさん [sage] Date:2008/06/29(日) 22:25:50 ID: Be: あげあしはどうでもいいよ。 799 デフォルトの名無しさん [sage] Date:2008/06/30(月) 00:24:58 ID: Be: 揚げ足取り、って言いたかったのかな。 800 デフォルトの名無しさん [sage] Date:2008/06/30(月) 00:30:10 ID: Be: 手羽先、って言いたかったんたと思うよ 801 デフォルトの名無しさん [sage] Date:2008/06/30(月) 01:44:47 ID: Be: コケコッコーーー!!! 802 デフォルトの名無しさん [sage] Date:2008/06/30(月) 08:15:27 ID: Be: お前ら鳥類食ってて何も恥じらいはないのかよ。 哺乳類としてのプライドはどこへ 803 デフォルトの名無しさん [sage] Date:2008/06/30(月) 08:54:17 ID: Be: 意味不明 804 デフォルトの名無しさん [sage] Date:2008/06/30(月) 09:01:33 ID: Be: つーか、ヘビとかトカゲとか、哺乳類を食うのは許せないよな。 やつら爬虫類が生まれた頃にはまだ哺乳類も鳥類も居なかったってのに。 赤外線センサーまでつけやがって。 805 デフォルトの名無しさん [sage] Date:2008/06/30(月) 16:22:47 ID: Be: 面白いと思って書いてるのかな 806 デフォルトの名無しさん [sage] Date:2008/06/30(月) 18:24:07 ID: Be: 鳥類爬虫類は許せるが 鯨だけは愛と権利が与えられるべきだと思います STL 807 デフォルトの名無しさん [sage] Date:2008/06/30(月) 18:27:03 ID: Be: 何故か日本より沢山偶然鯨が掛かる隣の国には抗議しません 808 デフォルトの名無しさん [sage] Date:2008/06/30(月) 19:09:10 ID: Be: 何でこんな流れに
【くそ!】 買ってはいけない技術本 【金かえせ】 704 デフォルトの名無しさん [] Date:2008/06/25(水) 21:41:00 ID: Be: 高くてもせいぜい数千円の投資をけちる程度の自分なら生き方を見直せや 705 デフォルトの名無しさん [sage] Date:2008/06/26(木) 00:02:18 ID: Be: >704 学生時代ならケチってたよ ガンバレ学生 社会人でそれくらいケチるなら見直すべき ネトゲとタバコ止めろよ 706 デフォルトの名無しさん [sage] Date:2008/06/26(木) 17:42:41 ID: Be: >>704 「投資」って……。 本職にしていない趣味グラマのことは無視ですかい。 707 デフォルトの名無しさん [sage] Date:2008/06/26(木) 18:36:28 ID: Be: 趣味にだって投資するだろ 708 デフォルトの名無しさん [sage] Date:2008/06/26(木) 21:27:26 ID: Be: 趣味は消費するもんだ 709 デフォルトの名無しさん [sage] Date:2008/06/26(木) 21:47:18 ID: Be: 無駄な投資は無駄だよな 710 デフォルトの名無しさん [sage] Date:2008/06/26(木) 22:07:39 ID: Be: 失敗した投資はロスだが、 無駄な投資は消費だな 711 デフォルトの名無しさん [sage] Date:2008/06/26(木) 23:54:03 ID: Be: 浪費だろ。 712 デフォルトの名無しさん [sage] Date:2008/06/27(金) 10:38:01 ID: Be: 浪費だな 713 デフォルトの名無しさん [sage] Date:2008/06/27(金) 12:27:05 ID: Be: で、逃避か。 714 デフォルトの名無しさん [sage] Date:2008/06/27(金) 12:47:53 ID: Be: いいえ、浪漫です。 715 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:19:56 ID: Be: だれうま 716 デフォルトの名無しさん [sage] Date:2008/06/27(金) 20:35:00 ID: Be: そもそも、人生とスレの浪費です 717 デフォルトの名無しさん [sage] Date:2008/06/28(土) 13:48:43 ID: Be: 糞本の代名詞である柏原 718 デフォルトの名無しさん [] Date:2008/06/28(土) 15:47:31 ID: Be: goto 文がバファリンだと言ってのけた某氏も kW 級の電波源 720 デフォルトの名無しさん [sage] Date:2008/06/29(日) 14:10:38 ID: Be: 本屋・古本屋・図書館を問わずガバ買い&ガバ借りしてる人を 時々見かけるけど、あれって考えてみたら馬鹿だよね。 1冊買ってその1冊を読破してからもう1冊買いに行けばいいのに 金の無駄すぎる。 721 デフォルトの名無しさん [sage] Date:2008/06/29(日) 14:47:15 ID: Be: さすがインテリだぜ 722 デフォルトの名無しさん [sage] Date:2008/06/29(日) 16:34:35 ID: Be: 本屋で大人買い→何度も本屋に行くのが面倒なので 古本屋で大人買い→他の人に買われたら、もう買えなくなるので 図書館→速読の達人 723 デフォルトの名無しさん [sage] Date:2008/06/29(日) 19:14:24 ID: Be: 最初は当たりかハズレかわからないから、複数買ってみるのもいいだろう。 1冊しか買わないでそれがハズレだったりしたら・・・ 724 デフォルトの名無しさん [sage] Date:2008/06/29(日) 21:24:29 ID: Be: >>20 ほしいと思ったときに買わないと、 無くなっている罠 いまは九天社の本が… 725 デフォルトの名無しさん [sage] Date:2008/06/29(日) 21:36:47 ID: Be: >>720 そんなちんたらやってやれるかよ。あほか。素人はすっこんでろ 726 デフォルトの名無しさん [sage] Date:2008/06/29(日) 21:44:59 ID: Be: 貧乏人はすっこんでろ、の間違いじゃないのか? 729 デフォルトの名無しさん [] Date:2008/06/30(月) 10:04:08 ID: Be: >>724 そうそう これはどうかなと思った時に買って、あとで必要になって見てる本はかなりあるよ #そのときには、大体絶版になってるよ 730 デフォルトの名無しさん [sage] Date:2008/06/30(月) 14:30:55 ID: Be: いやいや、727が既に自演 あ、図書館はゴミ本ばっかだから行くだけムダ 月刊誌や新聞ならいいけど 732 デフォルトの名無しさん [sage] Date:2008/06/30(月) 17:45:15 ID: Be: 図書館が初心者本で溢れてると担当者の感性を疑うね 大学の図書館と較べるとまさに天と地の差 学生時代にもっと読み漁っておけばよかったとつくづく 733 デフォルトの名無しさん [sage] Date:2008/06/30(月) 18:22:42 ID: Be: >>730 お前はひょっとして理解できない部類か? 734 デフォルトの名無しさん [sage] Date:2008/06/30(月) 22:10:19 ID: Be: 九天社ってそんないい技術書あったか? 735 デフォルトの名無しさん [sage] Date:2008/06/30(月) 22:25:24 ID: Be: ほしいと思ったときに金に糸目を付けずに買う。そして必要になるまで積読。 これが大人の時間とお金の使い方。
もちろん自分も読むのはいうまでもない :)
GCC UPC 4.2.3.3 Released - PLNews: Programming Language News GCC UPC 4.2.3.3 Released Posted: 2008-06-29 19:38:05 Languages :: C Platforms :: GCC GCC Unified Parallel C 4.2.3.3 has been released. GCC UPC adds support for Unified Parallel C to the GNU Compiler Collection. This release includes: an update to GCC 4.2.3, bug fixes, and other changes.
B-Prolog 7.1 Released - PLNews: Programming Language News B-Prolog 7.1 Released Posted: 2008-06-29 19:30:51 Languages :: Prolog B-Prolog 7.1 has been released. B-Prolog is a Prolog implementation with extensions for concurrency, constraints, interfacing with C and Java, and interactive graphics. This release includes: performance improvements; improved memory management; new propagators for non-linear, global and disjunctive constraints; new examples; bug fixes; and other changes.
LispForum Announced - PLNews: Programming Language News LispForum Announced Posted: 2008-06-29 19:33:28 Languages :: Lisp Websites LispForum has been announced. It is a website with discussion forums dedicated to various Lisp-related topics.
Unified Parallelって…?
ホームランと単打
Vista かわいそう。
そういえば、 遺伝子組み換え作物に害虫が寄らない(殺虫もする?)というのはどういう理屈なんだろ? よく知らないなあ。 嫌いな匂いを出す、とかじゃないよね?
プロがなぜ、二次創作を願うのか--Gacktが歌い、三浦建太郎が描く「がくっぽいど」:ニュース - CNET Japan これに対して、「ベルセルク」を連載している白泉社のヤングアニマル編集部から連絡があった。 「スケジュールが空いていない上に、締め切りが急すぎるので、多分無理だが、一応三浦先生に 伝えるので企画書を下さいと言われた」(村上氏)。4ページ程度の企画書を送ったところ、三 浦さんが興味を持っているようなので詳しい話を聞きたいという返答があり、村上氏はヤングア ニマル編集部に説明に行った。すると、そこにはすでに、三浦さんの描いたラフスケッチがあっ た。三浦建太郎さんのがくっぽいど「神威がくぽ」イラスト 三浦さんが描いたスケッチ画(ク リックすると詳しい記事に移動します) 「ニコニコ動画という、素人が自分の作品を発表して評価される場所ができたことが素晴らし いと三浦先生が個人的にとても喜んでいること、普通はほとんどこういった仕事は受けないが、 今回の件は受けると言っている、と告げられた」(村上氏) こうして、三浦さんががくっぽいどのイラストを引き受けることが決まった。ただし、そこに は条件が3つあった。「ニコニコ動画はユーザーが無償で作品を発表している場だから、自分も その世界に参加するときは無償で作品を提供したい。そして自分が作ったキャラクターはユーザ ーが自由に二次利用できるようにしてほしい。また、今回は仕事の報酬は受け取らない――と言 われた」(村上氏)
ふーむ。
var/タワゴト(2008-06-29) KENT-WEBと日本のcgi黎明期 (5) って、このシリーズまだ続くのか(汗 JVNを見ていたら、#43906021 KENT WEB 製 WEB MART におけるクロスサイトスクリプティングの 脆弱性が出てた。そのくせベンダの新着情報にも載ってないし…。脆弱性を配布ページにちょろ っと書いているだけか。何気にクレジット決済機能が付いているようなカートシステムがこんな ノリでいいのかな? KENT-WEBなカートシステムな店舗からは逃げろフラグですかそうですか。素人が開発して素人が インテグレーションし、素人エンドユーザがフィッシング詐欺されるという、下流の貧困スパイ ラルなんですかい。
いいぞもっとや(ry というか、きちんとアナウンスしてもそれを見るような人がユーザーなんだろうか という気がしたりしなかったり。 動いたらそのまんまで放置じゃないかなあ。
Inoki Brazil Monster 軍て(笑)
アキバにポータブルHDD買いに行こうと思ってたが (渋谷のビックカメラとかではなぜか扱ってない。そんなにマイナーなメーカーでもないんだが)、 雨が結構強く降っていたので一日引きこもり。
何ヶ所かから。 C++ Style Guide
特に下の二つが興味深かった。 やっぱりそうか。という意味で。
C++ Style Guide Global Variables Global variables of class types are forbidden. Global variables of built-in types are allowed, although non-const globals are forbidden in threaded code. Global variables should never be initialized with the return value of a function. Unfortunately the order in which constructors, destructors, and initializers for global variables are called is only partially specified and can change from build to build. This can cause bugs that are very difficult to find. Therefore we forbid global variables of class types (which includes STL string, vector, etc.) because initialization order might matter for their constructor, now or in the future. Built-in types and structs of built-in types without constructors are okay. If you need a global variable of a class type, use the singleton pattern. For global string constants, use C style strings, not STL strings: const char kFrogSays[] = "ribbet"; Although we permit global variables in the global scope, please be judicious in your use of them. Most global variables should either be static data members of some class, or, if only needed in one .cc file, defined in an unnamed namespace. (As an alternative to using an unnamed namespace, you can use static linkage to limit the variable's scope.) Please note that static class member variables count as global variables, and should not be of class types!Other C++ Features Reference Arguments All parameters passed by reference must be labeled const. Definition: In C, if a function needs to modify a variable, the parameter must use a pointer, eg int foo(int *pval). In C++, the function can alternatively declare a reference parameter: int foo(int &val). Pros: Defining a parameter as reference avoids ugly code like (*pval)++. Necessary for some applications like copy constructors. Makes it clear, unlike with pointers, that NULL is not a possible value. Cons: References can be confusing, as they have value syntax but pointer semantics. Decision: Within function parameter lists all references must be const: void Foo(const string &in, string *out); In fact it is a very strong convention that input arguments are values or const references while output arguments are pointers. Input parameters may be const pointers, but we never allow non-const reference parameters. One case when you might want an input parameter to be a const pointer is if you want to emphasize that the argument is not copied, so it must exist for the lifetime of the object; it is usually best to document this in comments as well. STL adapters such as bind2nd and mem_fun do not permit reference parameters, so you must declare functions with pointer parameters in these cases, too.
クロージャの次にくるものは?
The next big programming language feature after closures Dobbs Code Talk - The next big programming language feature after closures Closures are the current hot feature for programming languages. The inclusion of closures in Java appears to be around the corner, and the C++ committee has recently voted on closures in the upcoming C++ 0x standard. クロージャは現在ホットなプログラミング言語の機能です。 Javaへのクロージャの取り込みは appears to be around the corner C++の委員会は来るべきC++ 0x標準にクロージャを入れることを最近投票しています。 The introduction of closures into many mainstream languages indicate to me that the logicial next big features is going to be primitive aggregate operations. Those are operations that operate on collections such as lists or arrays. クロージャを多くのメインストリームにある言語に組み入れるということは わたしにとっては論理的に次の big features が primitive aggregate operation である ことを示唆しています。これらの操作は、リストや配列のようなコレクションに対する 行われる操作です。 Closures, are anonymous functions created at run-time which can refer to variables that are visible where the function is declared. クロージャとは、名前を持たない無名の関数であり、プログラムの実行時に生成して それが宣言された場所で可視の状態にある変数を参照することができるものです。 Closures are especially useful when performing operations over elements in a collection. The most common collection operations (aggregate operations) in functional programming are map, filter, fold, and unfold operations. クロージャはコレクションの要素をなめていく操作をするときに特に便利です。 関数型のプログラミング言語において最もよく行われるであろうコレクションに対する操作は mapやfilter、fold、unfoldといった操作です。 A map operation transforms a list into a new same-sized list by applying a transformation function (such as a closure) to each element in the original list. A common example of a map operation is when performing a vector scaling operation. A filter operation creates a list from another list using only those items for which a predicate function returns true. The fold operation combines values in a list using a binary function and an initial value. A summation function is a simple example of a fold operation. The unfold operation creates a list from an initial value and by successively applying a generator function, until a terimination predicate returns true. The introduction of closures into C++ and Java make aggregate operations (operations that operate on collections) easier to write and will make their usage more frequent. Aggregate operations like unfold, fold, filter, and "map" have the characteristic that they can be combined allowing significant reduction in the number of intermediate operations and data-structures created. This technique is called deforestation and is well-known when applied to pure functional programming languages such as Haskell. In order for a C++ or Java compiler to take full-effect of deforestation, the compiler would need to know when a particular aggregate operation is occuring and whether or not there are side-effects. This is a very hard task for a compiler, unless the language has a predefined notion of aggregate operation. Providing aggregate operations directly in programming languages have the additional advantage that it is easier for compilers to generate code that exploits multiple cores. A testament of how effective aggregate operations is demonstrated by the success of the array-oriented languages APL, J, and K. These are usually implemented with interpreters which have excellent performance characteristics. There are already some basic predefined operations on arrays in the Java virtual machine (JVM) and Common Language Runtime (CLR) for indexing and computing the size. The introduction of more sophisticated aggregate operations like map, filter, fold and unfold would be a logical extension to the CLR and the JVM. The performance benefits would not only be significant for single processors but there would also be benefit for code running on multiple processirs.
ATOzTOA: Linux Commands I Hardly Knew Linux Commands I Hardly Knew Execute The Last Executed Command !! This will execute the last command you used on the command line. Isn't the UP arrow for that? The !! command is very useful when you forget to start a command with sudo : apt-get update sudo !! Execute The Last Command Starting With ... If you want to execute a command from history starting with the letter S you can use the following: !s - This will execute the last command used on the command line that started with s.
!! なんてさんざん使ったもんだが喃。
9vx 9vx 9vx is a port of the plan 9 operating system to freebsd, linux, and os x, using the vx32 sandboxing library to run "user" programs. 9vx runs as an ordinary user program, but behaves like a separate vm running plan 9. it makes host resources like the file system, network stack, graphics windows, and audio devices available as file systems. 9vx requires no host kernel modifications or special privileges, and it runs unmodified plan9 386 binaries.
VX32 Virtual Extension Environment
むう試してみたいが。
この会社辞めようと思った腐れ上司の一言0x22 14 仕様書無しさん [sage] Date:2008/06/28(土) 15:36:43 ID: Be: そんなことより、デバッグ用ツールがいつの間にか余分な機能が追加されて 製品版として客先に出ている件について そのツール、チェックサム判定してないよ?wwwwww 15 仕様書無しさん [sage] Date:2008/06/28(土) 15:49:00 ID: Be: >>14 サポート担当決定w 乙ww 16 仕様書無しさん [sage] Date:2008/06/28(土) 15:53:43 ID: Be: >>14 データを新規投入する事はない、っていう前提のアプリ作って テスト用にデータ投入ツール(DOS窓レベル)作ったら それもそのままリリースされてた。 しかも、「毎回入力するのが面倒だから直して」ってクレームがきて対応させられた。 いや、金払ってくださいよ、まず。ってか営業担当はその辺ちゃんと調整してよ。 17 仕様書無しさん [sage] Date:2008/06/28(土) 16:31:03 ID: Be: チェックをするなという要件がでたのだから、 チェックをしてはいけないだろ。 デバッグ用のツールなんだから、 本来は入るべきじゃない入力も渡してやる異常系のテストに使うかもしれないし。 18 仕様書無しさん [sage] Date:2008/06/28(土) 17:10:19 ID: Be: >>16 「私はそんなものをリリースしていません」 19 仕様書無しさん [sage] Date:2008/06/29(日) 13:49:06 ID: Be: >>14 ハゲワロタw つーか、よくあることだw ちゃんと納品ドキュメントにも仕様(諸々の前提条件付き)を書いとけって おまけも、もちろん漏れなく付いてるよな。 awkとかシェルスクリプトで小一時間で作れた程度のツールだからこその 価値なんだがねぇ、しみじみ。
あちゃー(笑)
Prologでまったり Part3 272 デフォルトの名無しさん [] Date:2008/06/27(金) 03:45:34 ID: Be: Prologって何か凄そうだな。 とりあえず勉強したいのだが、日本語の良い書籍はないだろうか? 273 デフォルトの名無しさん [sage] Date:2008/06/27(金) 07:00:42 ID: Be: >>272 PrologとAI 「Prologへの入門」 「AIプログラミング」 (2分冊)I.Bratko著 安部憲広訳 近代科学社 解説の丁寧さにやや欠けるきらいがあるが、内容はPrologならではのもので、他の言語の 入門書にこの水準のものはない。 「Prologを学ぶ 文化とその実践」 杉崎昭生著 海文堂 穴場的な本。実はこの本も相当のもの。日本語プログラミングのスタイルで書かれて いることを嫌う向きもあるが、日本語を使った変数名の選択などを見ると、実に考え抜 かれた本であることがわかる。 もっとも高名な本としては 「Prologの技芸」 L.Sterling・E.Shapiro著 松田利夫訳 構造計画研究所発行 共立出版発売 がある。これは掛け値なしの名著。ただし、出版当時の特殊事情から、現在絶版。 入手がやや難しいと思うが、 「Prologとその応用2」 溝口文雄・武田正之・畝見達夫。溝口理一郎共著 総研出版 「Prologで学ぶ AI手法 推論システムと自然言語処理」 高野真著 啓学出版 「Prologを楽しむ」 Ph.O・松田紀之著 オーム社 など、他の言語の解説書ではちょっと見られないものが多い。 274 デフォルトの名無しさん [sage] Date:2008/06/27(金) 11:14:10 ID: Be: 教科書的なものとしては、 「Prologプログラミング入門」 安部憲広著 共立出版 この本はどこかの大学で 教科書として使われているらしく売れているようです。 「情報学概論 Prolog プログラミング」 吉田要著 八千代出版 「Prologプログラミング」 W.F.Clocksin/C.S.Mellish著 マイクロソフトウェア 三番目のものはProlog本の古典。これも入手難だと思います。 275 デフォルトの名無しさん [sage] Date:2008/06/27(金) 11:42:40 ID: Be: 少し、理屈っぽいところでは、 「論理による問題の解決 Prolog入門」 K.コワルスキ著 浦昭二監修 山田眞市 菊池光昭 桑野龍夫訳 培風館 「コンピュータによる推論技法」 第14章 L.ウォス/R.オーバーヒーク/E.ラスク/J.ボイル共著 川越恭二/久野茂/前田康行/光本圭子訳 マグロウヒル 特定分野からの視点では 「自然言語解析の基礎」 第4章 田中穂積著 産業図書 「帰納論理プログラミング」 第5章 古川康一 尾崎知伸 植野研 共著 共立出版 「第五世代コンピュータ入門」 第2章 渕一博監修 古川康一 新田克己 中島秀之 相田仁 共著 オーム社 それから >>273 の最後に 「楽しいプログラミングII 記号の世界」 中島秀之・上田和紀 共著 岩波書店 を追加し、 I.Bratko著の「AIプログラミング (PrologとAI)」の訳者として田中和明氏を追加します。 276 デフォルトの名無しさん [sage] Date:2008/06/27(金) 14:32:21 ID: Be: > 「Prologの技芸」 L.Sterling・E.Shapiro著 松田利夫訳 構造計画研究所発行 共立出版発売 この構造計画研究所って建築関係ですよね。 うちの大学によくアルバイト募集のチラシが貼ってありました。 大学卒業して随分経って、最近Prologに興味を持ち始めたのですが、 ここでバイトしていたら勉強になったのかなぁ…と思うと残念。 277 デフォルトの名無しさん [sage] Date:2008/06/28(土) 03:34:18 ID: Be: >>273~275 thx 結構あるな、と一瞬思ったがやっぱ少ないな。 いくつか密林で購入したので楽しみ。 次はPrologを利用して何を解くかだな。。。
OSC2008北海道閉会式 - すめるまん Broken Diary LTが充実した内容で楽しかったんですが、その後のオープンソースの10年を振り返る企画が特に すごかった。 osakana.factoryの方(以降、中川さん)がproprietaryなソフトが増えているという発言がすごく 心に響いた。オープンソースな物ばかり見ていたからその視点っていうのはハッとさせられるも のがあった。
増えているというのは数? 割合? 両方?
・しもた。
本屋に行ったらキングゲイナーGainer
本を買うつもりだったのに忘れてしまった。
・電撃大王。 それほど読む作品ないから(よつばと!と、えーと?)、無用に厚くなったとしか思えんな(^^;
・乃木坂春香の秘密。 全編コーラスのED曲が妙に気に入る(笑) こういうの好きなんだよなあ。
・今月の皇帝陛下 マントヴァ開城。
PHPカンファレンス2008のパネルディスカッションが自虐的過ぎる件 「激論!PHPの次に学ぶ言語はこれだ」(仮題) (パネラー) サイボウズ・ラボ株式会社 竹迫良範 日本Rubyの会 高橋征義 日本Pythonユーザ会 柴田 淳 Seasarプロジェクト ひがやすを id:amachang
えぴさんをC++で参戦させるとか。
MemeStreams | My programming rules 2.2から。
MemeStreams | My programming rules 2.2 I'm bored today so I decided to update my programming rules, make a 2.2 if you will, I know the smart ones out there never trust a 1.0 anyways... My Rules (2.2): 1. Kludges that we'll fix in the next release never get fixed in the next release... 次のリリースで直すはずの Kludges (一時しのぎのhackとかそゆこと)は次のリリースで 修正されることは決してない。 2. If you don’t do it right now, you (or some poor bastard that replaces you) will have to do it right later... キミが今正しく何かを行っていないのなら、あとでそれを正しくやらなければならない羽目になる。 3. It always costs more to do it later... あとでやるとコストは高くなる。 4. You're not going to have more funding for the next release. (thanks Decius) 5. Beware of anyone in a suit... 6. The man in charge usually didn't get there by being better than everyone else; keep that in mind. 7. If you don't talk to your customers to see what will make them happy, then sooner or later someone else will... 8. Sales guys can be powerful allies for interoffice BS, but if you make yourself too available they will never leave you alone... 9. Management has no idea what the customer wants... 管理部門は顧客が求めることについて何も考えていない。 10. Engineering has even less idea what the customer wants... エンジニアリング部門は顧客の求めるものより劣ったアイデアしか持っていない。 11. Assume every engineer you work with is an idiot, try not to let on that you know...if you find engineers that are obviously not idiots, find a way to keep them... あなたと一緒に働いているエンジニアがぼけ(idiot)であると仮定し、 あなたの知っていることを前提にしないこと。 もし明らかにぼけではないエンジニアに出会ったら、全力でその人物を手放さないようにすること。 12. Never outsource your core competency... あなたの売りをアウトソースしないこと。 13. Laziness and incompetence are contagious... 14. No-one cares if you read Wikipedia all day every day if you get your work done on time... キミが仕事を仕上げたあとでWikipediaを来る日も来る日も一日中読みふけっていたとしても 誰も気にかけやしない。 15. If they do care, find another place to work... もし誰かに見つかったら別の場所を探そう。 16. Your code is not finished until you've tested it... キミの書くコードはキミがテストするまでは完成しない 17. Never assume they have tested their code... 同僚が自分の書いたコードをテストするなんてことを期待してはいけない 18. Simple regression testing is best done when it’s automated; it’s less error prone too. 単純な退行テストはそれが自動で行われるのなら良いことだ。 19. Engineers that think lack of documentation is job security should be fired sooner rather than later (otherwise you'll make them right)... 20. Contrary to popular belief, third party libraries reduce portability of your code... (ry 62. Open source code is filled with bugs. オープンソースのコードはバグに満ち溢れている。 63. Closed source code is even more filled with bugs. クローズドソースのコードはもっとたくさんのバグに溢れかえっている。 64. It doesn't matter how secure your product is if no-one is willing to use it. 誰かが使おうとしないのなら、キミの製品がどれだけセキュアかなんてことは重要ではない 65. 1.0 rhymes with "oh no!" 66. Any time you use open source code in a project, be prepared to maintain your own branch of that code. You never know when the developers will get bored and leave you hanging. 67. Writing a technical book is way more work than you probably think it is. 技術書を執筆するということはキミが考えているよりもたくさん働くための方法だ。 68. From time to time every rule must be broken (even some of these); one of the tests of a good engineer is knowing when those times are.
あんま面白くないな。
変数の宣言がないってのはいろいろ大変な事態を招くのね。
Py3K: Solving the “outer scope” problem « Unspecified Behaviour
Py3K: Solving the “outer scope” problem Py3K: Solving the “outer scope” problem « Unspecified Behaviour I recently built the beta of Python 3000 - the upcoming total revamp of Python (due to be released in September - 992 years before they promised!) Because Py3K is unashamedly “backwards incompatible”, they are finally fixing all the major language flaws and making things “the way they should be!” (Note there will be a somewhat automated conversion process from Python 2 to 3 code). And I love it! Everything is fixed the way I hoped. Hence this is the first in the “ Py3K rox my sox” series of blog posts. You can see a summary of new features here. OK, so one of the major problems I’ve complained about (and heard) in Python is the so-called “outer scope” problem. This is a very definite limitation of what you can do in Python. Read on! How globals really work First a bit of background you may not know. This applies to all versions of Python, not just 3.0. In Python if you don’t declare a variable, Python figures out whether you’re referring to a local or global based on whether you write to it. For example: x = 4 def f(): return x Here, Python figures out that the x you refer to is actually the global x, and returns 4. It figures this out because the function never writes to x, anywhere. Not just because it hasn’t written to x yet, but because it has no statement which assigns to x. (It figures this out statically, not at runtime). So, for example: x = 4 def f(): if True: return x else: x = 2 This would be a neat quiz question actually: What does f() evaluate to? Answer: UnboundLocalError: local variable ‘x’ referenced before assignment. The mere fact that x is assigned somewhere in the function (even somewhere which will never be executed) causes Python to treat it as a local, and hence it is undefined when you go to return it. 関数の内側でxに対する代入があることによって、Pythonはxがローカルな変数であるとみなし てしまうので、return を実行しようとしたときには undefined なものになってしまっている。 The correct solution is to declare it “global” explicitly, which is the only way to make a function which writes to a global. 正しい対処方法は“global”な変数であることを宣言によって明示することである。 これはグローバルなものに対する書き込みをさせるための唯一の方法である。 x = 4 def f(): global x if True: return x else: x = 2 This works well in practice, because you can define constants like MAX_FOO and use them all over the place without declaring them global, but you need to be explicit if you want to update a global (which is usually a good idea because it’s dangerous - see JavaScript for a counter-example). The “outer scope” problem On to the “outer scope” problem. Basically, Python lets you write nested functions, and the nested functions have access to the local variables of their containing code. For example: def outer(): x = 9 def inner_read(): return x return inner_read() If you call outer(), it will return 9. The variable x is local to the outer function. But the inner function can read it, and return it. outer()を呼び出したとき、それは9を返す。変数 x はouter関数にローカルな関数であるが innter 関数から読むことができるのでそれを返す。 The problem comes when you want to write to a non-local variable, like this: 問題は次の例のようにローカルではない変数に対する書き込みをしようとする場合に起きる: def outer(): x = 9 def inner_read(): return x def inner_write(): x = 3 inner_write() return inner_read() As with global variables, Python can find outer scope variables if you only read them (as inner_read does), but if you write to them anywhere in the function, it assumes you are making a new local variable (as inner_write does). Hence inner_write creates a new local x, and assigns it 3, and the function outer returns 9. I would like for inner_write to update the existing x, and hence have outer return 3. グローバル変数に対するときと同じように、Pythonは外側のスコープに属する変数を 読み出しだけする場合には見つけることができる。しかし、関数のどこかで変数に対する 書き込みをしようとするとそれは新しい(inner_writeに属する)ローカル変数の宣言と みなされてしまう。このため innter_write は新しいローカル変数 x を作り出してそれに 3を代入する。そしてouter 関数は9を返す。わたしがやりたいのは、ここですでに存在している xを innter_writeで更新して outer が3を返すようにするということである。 The solution is pretty simple: Have a keyword like global, but rather than going all the way to the top scope, it just tells Python to look for the innermost scope with a bound variable of that name. 解決方法はとても単純なもので、globalというキーワードを使うというものだ。 しかしこれではトップレベルのスコープにまで持っていってしまうのだがやりたいのは その名前を使っているスコープの中でもっとも内側で束縛しているものを探すようにさせる ということだ。 Python 3.0 introduces exactly that: the nonlocal keyword. Let’s give it a try! Python 3.0 は本当にそのように動作させる機能が導入された。 nonlocal キーワードがそれだ。さあ試してみよう! def outer(): x = 9 def inner_read(): return x def inner_write(): nonlocal x x = 3 inner_write() return inner_read() Woot! Python 3.0 compiles this code and the outer function returns 3. The funny thing is, this problem seems to be specific to Python. In most static languages, all variables are declared. In Haskell, all variables are read-only. In Ruby, you refer to global variables by prefixing them with a $dollar. In JavaScript, it’s the inverse of Python: you declare all local variables and they default to global (which is a hideous idea - if you forget to declare a variable you implicitly start sharing where you didn’t expect to be sharing). Of course there are probably other languages with this problem but Python is the only one I’ve ever seen. 奇妙なことにこの問題はPython特有のもののように感じられる。 大部分の静的言語ではすべての変数は宣言される。Haskellではすべての変数はリードオンリーである。 Rubyではグローバル変数は'$'というプリフィックスがついている。 JavaScriptでは、Pythonとは逆の状況になっている。ローカル変数は宣言されたもので、 デフォルトではグローバルな名前を使う (変数を宣言することを忘れてしまったら意図せず変数を共有することになる) もちろんおそらくはPython以外にも同じ問題を持つ言語が存在するのだろうけど わたしが見た中ではPythonが唯一のものだ
Tcl/Tkのバージョンアップのペースはどうなってるんだ?
Tcl/Tk 8.6a1 Released - PLNews: Programming Language News June 27, 2008 Tcl/Tk 8.6a1 Released Posted: 2008-06-27 06:19:53 Languages :: Tcl Tcl/Tk 8.6a1 has been released. Tcl is a dynamic, cross-platform scripting language. This release includes: new commands for supporting object-oriented programming, support for interrupting script evaluation by an embedding application, and other changes.
片っ端から original authorにインタビューしてるんだろうか?
C言語を完全に駆逐するためには 491 デフォルトの名無しさん [sage] Date:2008/06/25(水) 01:01:07 ID: Be: C言語のプログラマは、自分たちを一番優等だと思ってるところが問題だ。 492 デフォルトの名無しさん [sage] Date:2008/06/25(水) 01:54:54 ID: Be: つまりプログラマの殆どはそんなこと思っているのか。 493 デフォルトの名無しさん [sage] Date:2008/06/25(水) 08:28:14 ID: Be: 言語の違いなんてバイオリンとピアノの違いでしかない。 道具が違うからって音楽家は人を馬鹿にしたりしないだろ。 それと同じこと。 ただし、ヴィオリストは馬鹿だけど。 494 デフォルトの名無しさん [sage] Date:2008/06/25(水) 08:40:33 ID: Be: ベーシストをDISる厨バンドマンならいくらでも 495 デフォルトの名無しさん [sage] Date:2008/06/25(水) 11:04:51 ID: Be: >>493 >道具が違うからって音楽家は人を馬鹿にしたりしないだろ。 譬えの誤謬だ。 カズー奏者はどう頑張ってもバカにされる対象。 496 デフォルトの名無しさん [sage] Date:2008/06/25(水) 21:50:27 ID: Be: >>493 >ただし、ヴィオリストは馬鹿だけど。 (^^;;;;; なぜ Va は自虐的なんでしょうね、てスレ違いですけど。 497 デフォルトの名無しさん [sage] Date:2008/06/25(水) 22:21:01 ID: Be: 他の言語を貶す言語廚は、自分の推す言語使いこなせななくて自信がないから他の言語を貶すんだろうね。 自分の目的に合致している言語を使いこなしているのなら、他の言語なんて眼中にないだろう普通 498 デフォルトの名無しさん [sage] Date:2008/06/25(水) 22:27:33 ID: Be: >>497 誰しもそこから出発するわけでして、許してあげましょうよ。 499 デフォルトの名無しさん [sage] Date:2008/06/25(水) 22:30:02 ID: Be: このスレの主旨はそういう言語戦争とは違うと思うけど? そろそろCに変わる言語が欲しいね、という前向きな話だよ。 500 デフォルトの名無しさん [sage] Date:2008/06/26(木) 02:44:29 ID: Be: BCPLとK&Rの頃から愛してる C99になってもっと恋しくなった BSDとEmacsも愛してる Cを知ったその日から 僕のプログラミング地獄に音楽は絶えない 501 デフォルトの名無しさん [sage] Date:2008/06/26(木) 11:02:04 ID: Be: K&Rからなら信じるけど。 BCPLからなんて誰が信じるか。 502 デフォルトの名無しさん [sage] Date:2008/06/26(木) 23:12:49 ID: Be: そこマジレスするところじゃなくね?w 503 デフォルトの名無しさん [sage] Date:2008/06/26(木) 23:15:28 ID: Be: 1億と2千年たってもC言語は健在だお。 504 デフォルトの名無しさん [sage] Date:2008/06/26(木) 23:46:41 ID: Be: そんなに人類生きてんのかな 505 デフォルトの名無しさん [sage] Date:2008/06/27(金) 00:08:34 ID: Be: マジレス乙w 506 デフォルトの名無しさん [sage] Date:2008/06/27(金) 06:25:07 ID: Be: そのころには人類は量子コンピュータ上でシュミレーティッド された世界に住んでるんだろな。動作言語はもちろんC-100002000 507 デフォルトの名無しさん [sage] Date:2008/06/27(金) 07:07:17 ID: Be: シュミレーティッド 508 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:47:05 ID: Be: C++の何がまずいかは語りつくされたようだから、 次はDのなにがまずいかについて聞かせてくれまいか。 509 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:49:19 ID: Be: D言語は良く知らない 510 デフォルトの名無しさん [sage] Date:2008/06/28(土) 00:02:19 ID: Be: DこそCを駆逐してやるという目的で生まれた言語だよね? 511 デフォルトの名無しさん [sage] Date:2008/06/28(土) 02:01:19 ID: Be: でもDコンパイラってCと100%互換なんじゃなかった? むしろ共存したいんじゃないの?
500(笑)
推薦図書/必読書のためのスレッド 40 [bbs2chreader] 650 デフォルトの名無しさん [sage] Date:2008/06/25(水) 21:53:15 ID: Be: 大学院の入試で必要なので 「プログラミング言語」というものについて総括的に学べるような本を探しています。 特定の言語ではなく、 歴史的背景、設計思想、分類、コンパイラ(入門レベル)など といった内容の本を探しています。 もし、いい本があるようでしたら教えていただけないでしょうか。 よろしくお願いします。 プログラミングスキル自体はそこそこあるので、 それなりの本でも大丈夫だと思います。 652 デフォルトの名無しさん [sage] Date:2008/06/25(水) 21:58:38 ID: Be: >>650 多言語にわたる書籍はないと思う。あったら俺も欲しい。 一番近いのはRubyの教祖がやってる(やってた)この連載かなあ。 Rubyist のための他言語探訪 http://jp.rubyist.net/magazine/?CategoryIndices 654 デフォルトの名無しさん [sage] Date:2008/06/25(水) 22:50:42 ID: Be: "History of Programming Languages-II", ACM Press 655 デフォルトの名無しさん [sage] Date:2008/06/25(水) 22:58:24 ID: Be: >>654 あ、それ俺も激同。 でも、かなりレベル高い。 関数型を複数マスターしてるぐらい(継続や型推論は必須)じゃないと読めないかも。 656 デフォルトの名無しさん [sage] Date:2008/06/25(水) 23:52:12 ID: Be: >>652 なるほど。でも、ちょっと方向性が違いますね。 面白いんだけど、テスト対策にはちょっと向きませんね。 >>654 英語は大丈夫なんですけど、たぶん日本語でも理解できなさそうですwww もうちょっと探してみます。 ありがとうございました。 657 デフォルトの名無しさん [sage] Date:2008/06/26(木) 00:04:53 ID: Be: >>656 英語が問題ないなら、 "Programming Language Pragmatics", Michael L. Scott 658 デフォルトの名無しさん [sage] Date:2008/06/26(木) 00:41:58 ID: Be: >>657 少し重過ぎますwww どちらかというと、OSやネットワーク、アルゴリズムといった分野のほうが大事なので、 もう少し手軽なやつでないと、学習する時間を持てません ありがとうございます。 659 デフォルトの名無しさん [sage] Date:2008/06/26(木) 00:48:46 ID: Be: wikipediaでも見とけ、アホ 660 デフォルトの名無しさん [sage] Date:2008/06/26(木) 01:52:52 ID: Be: >プログラミングスキル自体はそこそこあるので なんだ関数型はまだか。CとかJava程度しかわからないのに設計思想とか言ってないよね? どういう言語を勉強してきたのかな?大学院の入試って夏だろ。間に合うのか? 662 デフォルトの名無しさん [sage] Date:2008/06/26(木) 02:11:20 ID: Be: 相変わらずLisperさんは触るものみな傷つける勢いですね。 664 デフォルトの名無しさん [sage] Date:2008/06/26(木) 03:00:08 ID: Be: >650 そんな内容が一冊にまとまってるほど世の中都合良くはないが 大学院でプログラミングを専攻するつもりなら とりあえずSICPとドラゴンブックくらいは基礎教養として読んどけ。 いろんな言語を広く浅く知りたいなら、各言語の設計者が書いた本を 片っ端から買ってイントロ部分だけ拾い読みすればいいんじゃね? K&Rとかラクダ本とかみたいな、所謂"オフィシャル"本な。 言語設計者が何を意図してその言語を設計したのかは だいたい著書のイントロ部分に書いてある。 665 デフォルトの名無しさん [sage] Date:2008/06/26(木) 03:07:32 ID: Be: SICPもいいが、ガウディ本もいいぞ http://www.amazon.co.jp/dp/4798113468 666 デフォルトの名無しさん [sage] Date:2008/06/26(木) 03:20:27 ID: Be: >「プログラミング言語」というものについて総括的に学べるような本を探しています。 >特定の言語ではなく、 >歴史的背景、設計思想、分類、コンパイラ(入門レベル)など SICPもガウディ本もドラゴンブックもいいけど、要求が凄すぎて間に合わないなw 670 デフォルトの名無しさん [sage] Date:2008/06/26(木) 07:24:26 ID: Be: おれなんか、フーリエ変換、信号処理本だけで6冊あるぞ。 殆ど読んでないが。 C++本はビョーン本,STLからデザインパターンまで貯まるねぇ。10冊くらいあるよ。 こんなに読まないと危なくて仕事に使わせられない言語ははっきりいって失敗作だろう。 実装に携われる技術者を育てるのに何年かかるんだよって感じ。 677 デフォルトの名無しさん [sage] Date:2008/06/26(木) 07:43:25 ID: Be: >>670 javaを使えてる人にC++で書いてもらうことになったので、 自動変数のメモリモデルとRAIIを徹底することについて説明して ライブラリはstd名前空間に有るから、と伝えたらそれで十分でした。 703 デフォルトの名無しさん [sage] Date:2008/06/26(木) 22:30:10 ID: Be: この辺に日本に優秀なコンピューター技術者が少ない理由がある気がする。 「自分でやれ、自分でやれ」と突き放すばかりで、とっかかりや順序すら教えてやろうとしない。 そりゃ自分で学ぶ姿勢は必要だけどさ、未経験者にとっては 何からやっていいのかすらわからないだろう。 だから、内容の薄っぺらいマニュアルだけ書いた「厨房本」が売れたりするんだけどな。 何からやっていいかわからず途方に暮れ、父の知り合いのプログラマに訊きに行った若き日の俺。 「逆アセンブラとデバッガの使い方とパケットいじる方法を教えてくれ」と言う俺に その人は苦笑してたなぁ。 704 デフォルトの名無しさん [sage] Date:2008/06/26(木) 22:45:40 ID: Be: 初出は、クラッキングスレで合ってる? 707 デフォルトの名無しさん [sage] Date:2008/06/26(木) 23:50:27 ID: Be: >この辺に日本に優秀なコンピューター技術者が少ない理由がある気がする。 日本に居ないのは研究拠点が海外にあるからだろ。飛躍しすぎw 708 デフォルトの名無しさん [sage] Date:2008/06/26(木) 23:52:27 ID: Be: >>707 コピペにマジレスかっこわるい 709 デフォルトの名無しさん [sage] Date:2008/06/26(木) 23:55:06 ID: Be: 日本は社交性のないヲタばかりで人に教えるという事ができないので一定レベルより上は行けないよ。 710 デフォルトの名無しさん [sage] Date:2008/06/27(金) 00:08:27 ID: Be: PGは99%がオタ その99%うち、精神病者が6割 前科持ちが3割っていう犯罪者予備集団だしな 711 デフォルトの名無しさん [sage] Date:2008/06/27(金) 00:32:22 ID: Be: スレ(ry
初心者のためのプログラミング言語ガイド Part9 690 デフォルトの名無しさん [sage] Date:2008/06/26(木) 04:07:27 ID: Be: マニュアルじゃなくてツールのインスコ設定からスクリーンショットでどこにある何を選択して といった感じで手取り足取り導いてくれる解説サイトないの? 691 デフォルトの名無しさん [sage] Date:2008/06/26(木) 04:46:50 ID: Be: 入門者向けの本でも買ってきては? VisualStudioなら幾つか出てたような。 692 デフォルトの名無しさん [sage] Date:2008/06/26(木) 06:32:38 ID: Be: Windowsでプログラミングを始めようという人はWindowsや「Windows以外のソフト」の操作については それなりに習熟してることが多いからなあ できるシリーズ並にスクショや解説がないとさっぱりわからんという人はプログラミングなんかやめたほうがいい あなたにとってプログラミングは拷問や苦行か何かですか? 693 デフォルトの名無しさん [sage] Date:2008/06/26(木) 12:17:18 ID: Be: どうみても技術本として価格相応の情報量が圧倒的に不足している超初心者本が 多々売られているだけの需要はあるんだろう 694 デフォルトの名無しさん [sage] Date:2008/06/26(木) 12:21:37 ID: Be: ゆとりを馬鹿にされてる気がする 695 デフォルトの名無しさん [sage] Date:2008/06/26(木) 12:34:59 ID: Be: 選択肢が増えたことを素直に喜ぶべし まあ実際、プログラミング以前に変なところでつまづくのももったいない 696 デフォルトの名無しさん [sage] Date:2008/06/26(木) 21:19:26 ID: Be: 少し話変わるけど>692の最後の。 より良いソフトウェアを作ることが目的で、プログラミングが目的ではないんだよな まさに拷問や苦行レベルだよ もっと簡単に!もっと楽に!それが重要なんだと思うことが重要なんだと思う 何かいい言語はないものだろうか? 言語と言わず環境(言語+ライブラリ+ツール)でもいい 697 デフォルトの名無しさん [sage] Date:2008/06/27(金) 00:48:56 ID: Be: 「個人」で「楽」に「よりよいソフトウェアを作る」というのはやっぱ無理なんじゃないかな。 どれかひとつ条件を外してみたら? 1)「個人」で「楽」に「たいしたことないソフトウェアを作る」 2)「個人」で「苦労」して「よりよいソフトウェアを作る」 3)「会社で出世」して「辛い部分は人任せ」にして「よりよいソフトウェアを作る」 698 デフォルトの名無しさん [sage] Date:2008/06/27(金) 03:05:36 ID: Be: 1からこつこつ・・・ってことですね。 699 デフォルトの名無しさん [sage] Date:2008/06/27(金) 13:39:53 ID: Be: 見分けやすいフォントは? 700 デフォルトの名無しさん [sage] Date:2008/06/27(金) 13:42:51 ID: Be: >>696 結局、Prologに戻るんじゃないか。 たいしたことないソフトウェアしか作れないが。 701 デフォルトの名無しさん [sage] Date:2008/06/27(金) 14:57:56 ID: Be: 初級:Python 中級:Java 上級:C/C++ でいいんじゃないの。 702 デフォルトの名無しさん [sage] Date:2008/06/27(金) 15:26:04 ID: Be: Rubyさえあれば家内安全、商売繁盛 肩凝り神経痛もすぐ治る 703 デフォルトの名無しさん [sage] Date:2008/06/27(金) 15:42:37 ID: Be: 世界的な流れからすれば確実にRubyよりPythonだろうなぁ。 PythonはGoogleやYouTubeにも使われてるからねぇ。 詳しくは、 http://ja.wikipedia.org/wiki/Python 704 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:06:27 ID: Be: Rubyはここ数年でヒットした言語だが、Pythonはそれ以前からある 流れというなら、むしろ今まではPythonが主流で そこにRubyが食い込めるか?という構図 705 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:09:18 ID: Be: >>703 >RubyよりPythonだろうなぁ。 ちゃんと比較して言ってくれ 706 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:10:51 ID: Be: ここはVSスレじゃねーんだよ消えろドアフォ 707 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:17:10 ID: Be: 何熱くなってんだコイツ 頭悪そう 708 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:30:31 ID: Be: Rubyは信者がキモイ 709 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:36:02 ID: Be: >>705 こういうのとかじゃない? http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html 710 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:41:20 ID: Be: >>708 おまえがキモイ 711 デフォルトの名無しさん [sage] Date:2008/06/28(土) 01:38:47 ID: Be: きれいなコードを書く人はどの言語でもそれなりに書いているような。 そういう人って何をマスターしてるんだろうね。 712 デフォルトの名無しさん [sage] Date:2008/06/28(土) 01:53:12 ID: Be: 整理整頓 713 デフォルトの名無しさん [sage] Date:2008/06/28(土) 01:54:14 ID: Be: 真っ先に挙げるとすれば、 『「不吉なコード」を避ける嗅覚と習慣』だろうね。 以下私見 こいつは多分、何かをマスターした事の成果じゃなく、 何かに苦しめられた経験の積み上げだ。 714 デフォルトの名無しさん [sage] Date:2008/06/28(土) 02:09:31 ID: Be: Schemeを知っている人は 他の言語でも書くのが上手いという話は聞いたことがある Smalltalkを知っている人はクラス設計が~というのも(歴史的な理由もあるのかもしれないが) 715 デフォルトの名無しさん [sage] Date:2008/06/28(土) 02:39:25 ID: Be: あくまで俺の印象という括弧付きだけど、 会社のCOBOLerが書いた別言語(うちではC#)は、 ロジックは綺麗に書いてる印象がある。 フレームワークを理解していないし、余り積極的に理解しようともしないから 車輪の再発明をしている部分があるけど。 逆に.NETから入った新人は主処理は綺麗にまとめているが、 呼び出しているメソッドは、結構ぐちゃぐちゃになってる。 あと、基本的に富豪プログラミング。 716 デフォルトの名無しさん [sage] Date:2008/06/28(土) 04:03:03 ID: Be: ただいま、Cの言語を習っている初心者です。 マニュアルどおりにHello Cまでは出来ました。(*^_^*) 応用として こんにちわ C と作ってみたいのですが どのようにしたらよろしいでしょうか 717 デフォルトの名無しさん [sage] Date:2008/06/28(土) 04:08:37 ID: Be: >>716 何のことを言っているのかわからんが、 たぶん、「Hello」の部分を「こんにちわ」に変えるだけ。 718 デフォルトの名無しさん [sage] Date:2008/06/28(土) 04:09:39 ID: Be: そのようにしたらよろしいのではないでしょうか。 もしそのまま試した折に、コンパイラにご否定為さられたので ありますれば、どのように上手く行かなかったのか、お伺い したいと存じますわ。 わたくしたちもまた、コンパイラの情報を元にコーディング しているのでありますれば、ひと際あなた様のご体験を参考に 言ノ葉を選ばせていただけませばせれば(^o^**) 719 デフォルトの名無しさん [sage] Date:2008/06/28(土) 04:14:04 ID: Be: >>718 その前に、適切なスレへの誘導ですわ。 720 デフォルトの名無しさん [sage] Date:2008/06/28(土) 07:55:04 ID: Be: >>716の質問を見て考えたが、 初めてふれるプログラミング言語は日常使用している自然言語の文字列を 普通に使えることが有益なのではあるまいか。 721 デフォルトの名無しさん [sage] Date:2008/06/28(土) 08:03:08 ID: Be: ナンチャッテCプログラマによるヤラセじゃないのか? だいたい、本物の初心者なら2chのプログラマ板に到達するはずもない。 722 デフォルトの名無しさん [sage] Date:2008/06/28(土) 08:03:53 ID: Be: あ、プログラマ板じゃなくてプログラム板だった。スマソ。 723 デフォルトの名無しさん [sage] Date:2008/06/28(土) 15:28:58 ID: Be: 富豪プログラミングって何ですか?
rimnetがシステムダウンしていた模様 → http://www.rim.or.jp/support/announce/2008/080627_01.html
・ようやく RD潜脳調査室のOP/EDのCDを購入。 実を言うとEDの方はどうしようかなあと悩んだんだけどw
・あと数日で期限切れになるAmazonギフトがあったので (リマインドメールが届いて思い出した。RTMに登録しておいて正解w)、 これを買ってみた → Amazon.co.jp: Working Effectively With Legacy Code: Michael C. Feathers: 洋書
・キラッ☆ してきました
わかる人だけわかってください(笑)
・ちゅるやさん二周年とか。 四冊目に期待。 うつらうららか
斉藤さんがメールで書いてたのこれか。 → 6/28 オープンセミナー@四国、会場変更
・四国とか九州(とか北海道とか)いったことないのだよね。 にんにん。 北は宮城(松島の辺り)、西は京都くらいまでか?
いずれも天下を取ることなく滅ぶ。ということですねw
2008-06-26 - IT戦記 # 後漢 * IE # 魏 * Safari # 呉 * Opera # 蜀 * Firefox
晋→ぷにる。とか(チョー適当に名前を挙げただけです)w
オブジェクト指向 -OKWave C++ではクラスがありますが、このクラスで「公開(public)」「非公開(private)」キーワード があります。クラスが変数を持つ場合、どういった変数を公開にしておき、どういった変数を非 公開にしておくべきでしょうか。 Setなんたら()、Getなんたら()というメンバ関数を大量につければ一応変数は全部privateで もできるようですが・・・。なんか非効率的な気がします。
例によって「船頭多くして…」のパターン。 しかしなあ、変数をprivateにしておいて全部に setter/getter を定義してまわるというのは お莫迦に過ぎるにしても、setter/getter の存在そのものを否定しちゃうのはどんなもんだろうか。C++の場合、 C++ Builder みたいな独自拡張された処理系を除けば 読み取りは自由にできるけど書き込みを直接するのは×ということができない(ですよね?)のだから なんからのチェックをするのであれば、特に setterは使わなければどうにもならないような 気がするんだけど。 ああ、もちろん、オブジェクトの内部構造を(setter/getter経由であっても)操作して ごにょごにょ…というのはどうよというのは別の問題。
オブジェクト指向 -OKWave 変数は極力privateにすべきです。 Set()やGet()はprivateの意味がかなり薄れます。 publicよりはましかも知れませんが。 classの意味の大きな部分にカプセル化という概 念があります。publicはカプセル化を崩します。 設計のあり方でprivateにしますが、privateにす ると、どうしても効率が悪くなる場合は、その時 点の設計力の限界と割り切ってpublicも致し方が 無いでしょう。基本方針は基本方針ですが、こだ わり続けるのは非効率でしょう。>Setなんたら()、Getなんたら()というメンバ関数を大量につければ つけてはいけません。そんなことをする位なら変数を公開した方がマシです。 >一応変数は全部privateでもできるようですが・・・。 オブジェクト指向というからには、オブジェクトとそのオブジェクトに対して可能な操作だけを 公開して下さい。がると申します。 んと…きちんとした「オブジェクト指向プログラミング」をするのであれば。 ・変数は全てprivate ・全ての変数にgetter、setterを作る。ただしそれがpublicなのかprotectedなのかはクラス次第 はほぼ鉄則だと思ってください。 ちなみに当然ではありますが「自分のclass内変数を触るときもgetter、setter経由」にしましょう。 後々の、保守メンテナンス性が根底から変わりますので。 アクセサ(getter、setter)を作成するのは。初めは非効率に思えるかも知れませんが、キャリア を積むと「作成しない方が非効率である」事がわかると思います。変数を基準に考えてるのではオブジェクト指向になりません。オブジェクトの中でどのような操 作が行われているかは、外からすれば気にしないで良いように設計するべきです。 オブジェクトが外に公開するのは、その操作(実装で言えばメンバ関数)です。どのような操作 をそのオブジェクトは提供するか、という視点で考えてみてください。 例えば複素数クラスであれば、 ・足し算可能 ・掛け算可能 ・コピー可能 ・偏角・絶対値取得 ・Re・Im取得 などを使えれば十分でしょう。このように、使用させる操作だけ公開しておけば、中の変数が (x,y)で管理されていたとしても(r,θ)で管理されていたとしても外から見れば関係ありません。 基本的には、内部の変数そのものは外からタッチさせないものです。
インクリメント演算子でのオブジェクト(変数)を評価する時期 -OKWave インクリメント演算子について以下のような例題を考えてみました。 #include<stdio.h> int main(void) { int at=0; if(at++) printf("True at=%d\n",at); else printf("False at=%d\n",at); return 0; } この時答えとしては Falsue at=1です。 これは、if文の制御式( )で at=0と判定しそのごat=1となるため、else文以降が実施されるためです。 atはメモリ上に配置されると思いますが、どの時点までat=0であり、 どの時点でat=1になると考えたら良いのでしょうか。 アセンブリの問題になると思いますが、宜しく願います。
インクリメント演算子でのオブジェクト(変数)を評価する時期 -OKWave ++、--はもともとPDP11系のアセンブラにあった書式です。 at = at++; は言語仕様上、全く問題ありません。 at = at = at; とか if(( at++ )||at) はやる人はいませんが、 問題なく実行可能です。 尚、最適化の度合いによっては更新時期が微妙に違うことが あります。20年くらい前のMSCにはこのバグがあって、苦労しました。
ある処理系でコンパイルできて実行できるということと、言語仕様としてどうなのか というのは別問題でしょう○| ̄|_
全角カタカナの正規表現 -OKWave if (preg_match('/[ァ-ヶー]+/', $value, $match )) { print ("$value"."はカタカナです。"."($match[0])"."<br />") } else { print ("$value"."はカタカナではない。<br />"); } という感じで全角カタカナにマッチさせる正規表現を使いたいのですが、このやり方だと「全角 カタカナを含んでいる…」という表現になってしまいます。ある文字列が「すべて全角カタカナ である」という正規表現を考えているのですが、なかなかうまくいきません。逆引きのサンプル なんかでもなかなか見つからなくて困っています。 同様に「すべて平仮名にマッチ!」というのにも応用できると思うのですが、なかなかうまく行きません。 是非、そのやり方やヒントをおしえてください。 マルチバイト対応なので[ぁ-ん]のような形で表記できます。またPerl互換(preg_match)で作 っているので、Perlに詳しい方も是非是非おしえてください。
preg_matchはmb_ereg とはちがって、シングルバイト文字かUTF-8のみの対応なのと UTF-8であるということを知らせるには正規表現パターンを与える文字列のフラグ部分に 'u'を付け加えておかないといけない。 回答者でもそれに触れてるのがいないんだけど、マッチングがうまくいかないってのは そのせいなのじゃないか?
全角カタカナの正規表現 -OKWave [ァ-ヶー]+ は文字コードによって片仮名の範囲がことなるので、あやしいですよこの回答への補足 文字コード変換済みでも駄目でしょうか?この回答へのお礼 すべの皆様のヒントで、やっとできました。 (ホントに、ちょっとモノを言ってくれる方々がいると考えるとわかるんですが…一人だとつらい…。。) いろいろやってみたあげく、 [^ア-ン][^ア-ンーヽヾ]という感じで「カタカナ以外」でマッチさせてみました。 ありがとうございます。
文字コードによってカタカナの範囲が異なる。って何が言いたいんだ? 半角カナと全角カナで違うってことか? でも質問にあるのは全角のを引っ掛けたいということだし、pregはUTF-8(のUnicode。 4.0あたりか?)しか喰わないし。
なんだこの流れ。
Lisp Scheme Part22 [bbs2chreader] 870 デフォルトの名無しさん [sage] Date:2008/06/26(木) 07:59:08 ID: Be: Gaucheでバグかなと思ったのあるけど聞ける雰囲気じゃないね Rubyより怖い 871 デフォルトの名無しさん [sage] Date:2008/06/26(木) 08:10:33 ID: Be: ああ、宗教的な何かがここに蔓延してることにしたいわけね。 大丈夫だよ。馬鹿は論理的に叩かれるけど、馬鹿じゃなければ叩かれない。 書いてみれば? 873 デフォルトの名無しさん [sage] Date:2008/06/26(木) 08:39:11 ID: Be: rubyってこわいの? 874 デフォルトの名無しさん [sage] Date:2008/06/26(木) 08:52:37 ID: Be: つ 落語&「rubyよりこわい」 875 デフォルトの名無しさん [sage] Date:2008/06/26(木) 09:13:10 ID: Be: >>870 別にネタや燃料の投下になってもいいじゃん! 876 デフォルトの名無しさん [sage] Date:2008/06/26(木) 12:41:57 ID: Be: バクだってあるさ にんげんだもの 877 デフォルトの名無しさん [sage] Date:2008/06/26(木) 16:18:00 ID: Be: ココのスレ見るとLisperさんが何をしてきてどう思われてるかが良くわかります。こういう印象です。 http://pc11.2ch.net/test/read.cgi/tech/1209441159/ 878 デフォルトの名無しさん [sage] Date:2008/06/26(木) 16:20:40 ID: Be: 粘着、こっちまで遠征かよw 879 デフォルトの名無しさん [sage] Date:2008/06/26(木) 19:58:10 ID: Be: >>871 ほとんど名指しされてるw 880 デフォルトの名無しさん [sage] Date:2008/06/27(金) 06:31:04 ID: Be: >>870 WiLiKiに書いたら? ちゃんと対応されるみたいだし 881 デフォルトの名無しさん [sage] Date:2008/06/27(金) 06:44:49 ID: Be: Rubyをプログラミング言語の基準にやめろ あれはあれで特殊。 RubyとGaucheとMosh、みんな違ってみんないい 882 デフォルトの名無しさん [sage] Date:2008/06/27(金) 06:50:14 ID: Be: ジャパニーズでおk 883 デフォルトの名無しさん [sage] Date:2008/06/27(金) 08:34:34 ID: Be: >>882 I cannot understand your words. "It is k in Japanese" What meaning is it? Please write in English. 884 デフォルトの名無しさん [sage] Date:2008/06/27(金) 11:02:25 ID: Be: コピペか? ひっでえ英語w 885 デフォルトの名無しさん [sage] Date:2008/06/27(金) 13:07:52 ID: Be: >>884 偶然だぞ 何言いたいかと申しますと「ジャパニーズでおk」という日本語では、外人さんに伝わるも のも伝わらないだろう、と言いたいわけです 日本語でやり取りしてるサイトなのだから外国人なぞ居ない、日本人しか居ないのだ、と思 い込んでいませんか? 日本人がYoutubeを使っているように、外国人も2chを使っている可能性があるのではないのです か? 何故その可能性を排除しますか? 母国語ではない言語を使うことに苦労しながらも、それでも私達とコミュニケーションをとろう としている(のかもしれない)人物に対して 「ジャパニーズでおk」という物言いをするのは良いことなのですか? コミュニケーションをとろうと努力している(のかもしれない)相手に対して、随分失礼な態度 ではないのでしょうか それとも、そんな振舞いをするのが日本人なのですか? 相手にけして通じない言葉を使って悦 に入る。それが日本人の性格なのですか? プログラミング言語のほとんどは日本以外の国で作られたものですから、日本人はその習得や 理解に多少なりとも苦労しているはずです ドキュメントの大多数は英語文献で公開され、英語が不得意な日本人であれば読むのも一苦労でしょう そのような苦痛をこの板に集う人々は自ら日々感じていながら、何故相手に通じない日本語を使うの ですか? 886 デフォルトの名無しさん [sage] Date:2008/06/27(金) 13:09:55 ID: Be: そして私は思いました >>881が日本人なら、私こそが失礼なことを言っています… 887 デフォルトの名無しさん [sage] Date:2008/06/27(金) 13:28:06 ID: Be: 886は外人さんなのな 2chはある意味、かなり高度な日本語(スラング的な意味で)が要求されるから もっと慣れてから書き込むべきです。 このBBSで長文を書き込むことと、必死になることは推奨されていません。 そしておそらく881は日本人です 888 デフォルトの名無しさん [sage] Date:2008/06/27(金) 14:00:40 ID: Be: おまえらの人種が何なのかなんて興味無いよw 889 デフォルトの名無しさん [sage] Date:2008/06/27(金) 14:35:56 ID: Be: おまえらここは言い争いの場にやめろ 890 デフォルトの名無しさん [sage] Date:2008/06/27(金) 15:24:25 ID: Be: >>888 おまえの興味なんて興味無いよw 891 デフォルトの名無しさん [sage] Date:2008/06/27(金) 15:25:16 ID: Be: >>890 おまえの興味なんて興味無いよw 以下再帰的なので略 892 デフォルトの名無しさん [sage] Date:2008/06/27(金) 15:30:14 ID: Be: ここは酷い名無し再帰スレです。 893 デフォルトの名無しさん [sage] Date:2008/06/27(金) 16:54:30 ID: Be: >>892 Yコンビネータ乙 894 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:08:39 ID: Be: 不動点ですが何か? 895 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:15:23 ID: Be: >>894 894 名前:デフォルトの名無しさん[sage] 投稿日:2008/06/27(金) 18:08:39 不動点ですが何か? 896 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:18:32 ID: Be: >>895 895 名前:デフォルトの名無しさん[sage] 投稿日:2008/06/27(金) 18:15:23 >>894 894 名前:デフォルトの名無しさん[sage] 投稿日:2008/06/27(金) 18:08:39 不動点ですが何か? 897 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:19:16 ID: Be: >>896 896 名前:デフォルトの名無しさん[sage] 投稿日:2008/06/27(金) 18:18:32 >>895 895 名前:デフォルトの名無しさん[sage] 投稿日:2008/06/27(金) 18:15:23 >>894 894 名前:デフォルトの名無しさん[sage] 投稿日:2008/06/27(金) 18:08:39 不動点ですが何か? 898 デフォルトの名無しさん [sage] Date:2008/06/27(金) 18:35:05 ID: Be: やめいw 899 デフォルトの名無しさん [sage] Date:2008/06/27(金) 19:05:20 ID: Be: 本当に再帰すんなw 900 デフォルトの名無しさん [sage] Date:2008/06/27(金) 19:15:21 ID: Be: ヌルポ 901 デフォルトの名無しさん [sage] Date:2008/06/27(金) 19:18:55 ID: Be: ガッ 902 デフォルトの名無しさん [sage] Date:2008/06/27(金) 19:26:11 ID: Be: 再帰を終わらせようと思ったのにガッされたお(´・ω・`) 903 デフォルトの名無しさん [sage] Date:2008/06/27(金) 19:48:48 ID: Be: >>902 つぎはcall/ccをかませよ。 904 デフォルトの名無しさん [sage] Date:2008/06/27(金) 20:46:10 ID: Be: pythonの内胞リストで感動してきた http://www.ibm.com/developerworks/jp/linux/library/l-prog3/ 要するにmapの拡張だと思うんだけどmapの拡張を柔軟にするって意味では lispのmacroも同じ? pythonの内胞リストと同じマクロって作れないの? 905 デフォルトの名無しさん [sage] Date:2008/06/27(金) 21:11:58 ID: Be: >>904 (use srfi-42) 906 デフォルトの名無しさん [sage] Date:2008/06/27(金) 21:13:46 ID: Be: リスト内包記法な 907 デフォルトの名無しさん [sage] Date:2008/06/27(金) 21:55:32 ID: Be: >>904 実用的なのは >>905 が書いてるsrfi-42だが、マクロでの実現法を 知りたいならここにあるlist-ofが参考になる。15行で内包表記を実現。 http://practical-scheme.net/wiliki/wiliki.cgi?Scheme%3a%e3%83%9e%e3%82%af%e3%83%ad%e3%81%ae%e5%8a%b9%e7%94%a8#H-b9epxs 908 デフォルトの名無しさん [sage] Date:2008/06/27(金) 21:57:15 ID: Be: 内包表記は複雑。あんなものは内包がいい。 909 デフォルトの名無しさん [sage] Date:2008/06/27(金) 22:05:00 ID: Be: うまいこと言うなあ 910 デフォルトの名無しさん [sage] Date:2008/06/27(金) 22:17:56 ID: Be: 尊敬します! 911 デフォルトの名無しさん [] Date:2008/06/27(金) 22:47:39 ID: Be: Lispに入門したいけどまだ戸惑ってる僕が質問します。 みなさんはLispを使って何をしていますか? ばかな質問だったら無視してください。 912 デフォルトの名無しさん [sage] Date:2008/06/27(金) 22:48:57 ID: Be: 仕事 913 デフォルトの名無しさん [] Date:2008/06/27(金) 22:54:47 ID: Be: >>912 すごっ、どんな分野なんですか? 914 デフォルトの名無しさん [sage] Date:2008/06/27(金) 22:58:31 ID: Be: ふつーに、ちょっとしたデータを作ったり、ソースとかドキュメントを加工したりするのに使ってるよ。 915 デフォルトの名無しさん [sage] Date:2008/06/27(金) 22:59:50 ID: Be: 912ではないが 設定ファイルのインタプリタとか シェルみたいにインタラクティブに何か操作する言語を作るとか 916 デフォルトの名無しさん [] Date:2008/06/27(金) 23:03:09 ID: Be: みんな実務に使ってるんですねぇ。 CG系の目的で使ってるひといませんか? 917 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:03:42 ID: Be: よほどのことが無いかぎり、プログラムは Lisp (私の場合はCommon Lisp)で書いている。 よほどのこと、というのは、 ・効率などをシビアに要求されて、他の言語でないとその要求を満たせない場合 ・他の言語を使えばおそろしく簡単に(たとえばライブラリを呼ぶだけ)済む場合 ・(顧客の指示など)社会的な理由でLispを使うことが許されない場合 918 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:04:32 ID: Be: >>916 レンダリング系は難しいかもしれないけど、モデリング系ではかなり使われてると思う 919 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:08:45 ID: Be: >>916 昔々Symbolicsというマシンがあってだなあ・・・ いや年寄りの独り言だ、忘れてくれ・・・ orz 920 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:10:04 ID: Be: 昔話禁止しようぜ 921 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:11:07 ID: Be: R5RSは忘れてR6RSにしようということですね。わかります。 922 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:16:24 ID: Be: >>916 例えばここ見てみるといいよ。 ttp://www.franz.com/success/customer_apps/animation_graphics/ 923 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:45:50 ID: Be: R6RSも忘れてERR5RSにしようということですね、わかります >>911 あなたは両手を使って何をしていますか? (もし手の不自由な方だったら申し訳ありません。意味を汲み取ってください。) 924 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:51:55 ID: Be: >>923 > あなたは両手を使って何をしていますか? 自慰 925 デフォルトの名無しさん [sage] Date:2008/06/27(金) 23:56:14 ID: Be: >>924 片手でやれ 926 デフォルトの名無しさん [] Date:2008/06/28(土) 01:19:54 ID: Be: >>923 すみません、意味を汲み取れませんでした。 今はタイピングしてますね。 927 デフォルトの名無しさん [sage] Date:2008/06/28(土) 01:32:39 ID: Be: 深い意味があるわけではありません。 なんか予想外の方向に展開してますが 日常生活の動作の多くに(無意識に)両手を使うように コンピュータを使う動作の多くに(無意識に、とまではまだ私はいきませんが)Lispを使うのです。 などと書きましたが未だに3分の1くらいはBシェルスクリプトにしてしまいます:-P 928 デフォルトの名無しさん [sage] Date:2008/06/28(土) 02:42:44 ID: Be: 春先辺りから変なのが常駐してるな。 929 デフォルトの名無しさん [sage] Date:2008/06/28(土) 03:09:44 ID: Be: だれかグレアムおじさんのArcを実装しようという方はおらんのかね 930 デフォルトの名無しさん [sage] Date:2008/06/28(土) 03:23:06 ID: Be: >>929 グレアムおじさん
と思ってぐぐって見ると「可動式ホーム柵」とかいう名称もあるようで。 → ホームドア-民鉄用語辞典-日本民営鉄道協会
ホームドア - Wikipedia ホームドアまたはスクリーンドアとは、プラットホームの線路に面する部分に設置される、可動式の開口部を 持った仕切りである。 ホームからの転落や列車との接触事故防止などを目的とした安全対策の一つである。なお「ホームドア」 は和製英語であり、英語では Platform screen door と呼ばれる。
ふにゃん。
図書館戦争。 ちょっとぐっときた台詞があった(どれかは内緒w)。 いい最終回でした。
Visual Studio で Ctrl + ] Visual Studio で Ctrl + ] で対応する括弧にジャンプできます。 便利ですね。 そして、これ region から endregion にも飛んでくれるんですね。(もちろん逆も) 対応する括弧は知ってたけど、region は知らんかった。
知らなかった>対応するカッコにジャンプ
考えてみりゃほとんどVSのIDE使わないからなあ(笑)
【RubyKaigi'08】詳細レポート : 多様化するRuby(続):CodeZine
【RubyKaigi'08】詳細レポート : 多様化するRuby(続):CodeZine MagLev MagLevについては、Smalltalkエバンジェリストのsumim氏による『MagLevについて調べてみた』が詳しい。
おお、すげえ>sumimさん
あ、この記事の編集者 artonさんなのか。
MSN相談箱 メールアドレスでメンバー認証 メールアドレスでメンバー認証 質問者:nerumako メンバーサイト構築にて質問です。 ユーザーから送られてきたメールのメールアドレスで、 メンバーであるか新規であるかを判断するプログラムをperlで作成したいと思っております。 まだperl初心者なのでもっと良い方法がないか考えたいのですが経験がないので考えが浅はかです。 何卒、ご意見または別の案などご教示頂けないでしょうか。 (メンバー数の想定は10万~100万 データベースは使いません) ※当初の考え ファイルに新規ユーザーのメールアドレスを追記 →ファイルをオープンして1行づつ検索 懸念:メンバー数が多くなればファイルをオープンするだけで結構なメモリを消費するのではないか、ループで1行づつ検索したらすごい負荷がかかるのではないか。 ※現時点の考え 新規ユーザーのメールアドレスをファイル名にしたファイルを作成(@マークなどは別の記号に変更) →ファイル検査演算子でファイルがあるかどうか判断 懸念:すごく速い気がするのですが、これって現実的なんでしょうか??動作はしますよ。 ただ現実問題、100万ファイルあるフォルダの中身を操作できるツールは存在しないでしょうね。 FTPなどで接続してもファイルリストの取得中にタイムアウトになると思います。 つまり、単純にダウンロードではバックアップするのは厳しいということです。 あと、ファイル1つ作るごとに、ファイルシステムが管理する情報が実際には発生します。権限、作成日、所有者などなど・・。 これらを100万ファイル分管理させたとなると、ファイルシステムのトラブルが発生する可能性も高まります。 ということで、「当初の考え」のほうをお勧めします。 ファイル内から該当する行を探すには、whileでテータの中身を1行ずつ読ませることでメモリの消費も一定ですみます。
この回答は正直どうかと。 確かにファイルエントリを使った手法(ってどっかで似たようなのを聞いたような?)に 問題がある(可能性がある)のを指摘するのは当然として、 十万件からのフラットなファイルを一行一行リニアにサーチさせるのも問題じゃないの? 線形探索だから、リスト中に対象のメールアドレスがある場合の「平均」の比較回数は 2 / n で、最小の十万件として5万がその値になると。 一行にアドレス一個として、その回数だけ
while (<$idfile>) {
...
}
をまわると? また、 一日とか一週間あたりでどれだけこの検査をするのかわからないけど 「メールアドレスが存在しない」ことがわかるには「ファイルを全部読みきらないとダメ」だから、 どれだけファイルを読み返せばいいのかと。
Perlだけじゃなくてプログラミングそのものも初心者であまり複雑なことができないとしてもだよ、 メールアドレスの頭数文字でブロックごとに分類してインデクスファイルも作って、 とかさせるべきじゃないの?
と思ったら同様の回答がついた模様。
ActiveState - The ActiveState Blog: PPM build servers are dead -- long live PPM!
ActiveState - The ActiveState Blog: PPM build servers are dead -- long live PPM! PPM build servers are dead -- long live PPM! Our PPM build server infrastructure has been very maintenance intensive; it needed some manual tweaking and fixing on a weekly basis. We finally couldn't stand doing it any longer and turned them off a couple of weeks ago. The PPM repositories are still there, but they're not being updated anymore. But fear not! We took the time saved from having to do all the build monitoring and fixing and started writing a new simplified build system that avoids many of the problems the old one runs into. More details can be found here.
んで
PPM build servers are dead -- long live PPM! :: ASPN Mail Archive :: ppm Our PPM build server infrastructure has been very maintenance intensive; it needed some manual tweaking and fixing on a weekly basis. We finally couldn't stand doing it any longer and turned them off a couple of weeks ago. The PPM repositories are still there, but they are not being updated anymore. But fear not! We took the time saved from having to do all the build monitoring and fixing and started writing a new simplified build system that avoids many of the problems the old one runs into. We have built test repositories for 32-bit ActivePerl 5.10 on Windows and Linux and would welcome any feedback from people willing to beta-test them. They are currently being hosted at: http://ppm.activestate.com/beta There you'll find additional information about configuring them as your default PPM4 repositories. It contains links to the build-status tables at the bottom (one per letter), e.g. http://ppm.activestate.com/beta/idx/W.html If you are a CPAN author then you will also want to check the status page listing all the modules from your CPAN directory, e.g. http://ppm.activestate.com/beta/author/GAAS.html We are interested in feedback, especially regarding: * Do you experience any problems with either the commandline or the GUI PPM client with these new repositories? * Do the modules installed from these repositories work properly on your system? Did they fetch all necessary prerequisites? * If you are a module author and your module did not build or test properly: do the build logs contain sufficient information to understand _why_ they were not being built? * Is there any information that you would like to see in the build status results? What is it, and what do you need it for? Please send your feedback to the PPM mailing list at mailto:ppm@[...].com or enter a bug report in our bug database (use "ActivePerl" product and "PPM_Server" component): http://bugs.activestate.com/enter_bug.cgi?product=ActivePerl Here are a couple of known issues that we are already aware of: * Some packages contain additional files that are not needed (and ignored) by the PPM client (HTML documentation, debugging symbols). This has already been fixed in the build system and all packages build during the last few days should already have these additional files stripped. * Modules bundled with ActivePerl use static linking for all non- standard additional libraries. E.g. Crypt-SSLeay does not require that libssl32.so or libssl32.dll is installed as well. This makes it easier to bundle these modules with packagers like PAR, PerlApp or Perl2exe, and also avoids putting additional DLLs on the PATH where they might conflict with different versions of the same DLLs from other applications. For all modules bundled by ActivePerl (and for some additional popular modules we have defined on our internal "watchlist") we want to make sure the PPM packages will also use statically linked libraries. This has not been done yet, so especially the Linux packages may include references to locally installed additional libraries (libz.so, libgd.so etc). * The layout of the build status information is preliminary and hasn't been reviewed by a web-designer yet. The ActivePerl Team
ふーん。
Microsoft .NET ILアセンブラ入門:CodeZine
Microsoft .NET ILアセンブラ入門:CodeZine ちなみに、0~8までの値の読み込みにはldc.i4.0~idc.i4.8 という専用の命令が割り当てられ ています。また、-1もldc.i4.m1という命令で読み込めます。これらの命令は、オペコードだけ で構成されるため、 idc.i4命令よりもサイズが小さく効率的です。通常、-1~8までの定数をス タックに読み込みたい場合は、これら専用の命令を使い、それ以外の値を読み込む場合にldc.i4 を使います。
へえ、68kみたいだな。>小さい値の読み込みに専用命令
って他のVMでも見たような気がするな(^^; (鳥頭モード)
RubyKaigi2008でも同様のネタがありましたが
コン基礎の教え方の宝庫(8) Javaプログラミングの指導は難しい:ITpro 私はこうやって教えています~難解な技術をわかりやすく教えるコツ~ 最近のIT企業の新人研修で採用されているプログラミング言語は、Javaが多いようです。かつ て主流だったC言語やVisual Basicと比べて、Javaは覚える言語構文が多い言語です。オブジェ クト指向のための言語構文もあります。私は、これまでに幾度となくJavaを指導してきましたが、 上手くいったと思ったことがありません。講座終了後に「こうすればよかった」と反省すること ばかりです。どのような反省点があったか紹介しましょう。 キー入力に時間がかかる (ry ところが、いざ新人さんにプログラムを打ち込ませてみると、とても時間がかかる人もいます。 最近の若者ですから、キーボードがまったく打てないという人はいませんが、10人のうち2~3人 ぐらいは、キー入力にとても時間がかかります。これでは、お手本どおりに打ち込むだけで精一 杯で、改造のアイディアを考える余裕などありません。講座終了後のアンケートには「プログラ ムを打ち込むだけで精一杯でした」「これまでの研修の中で一番疲れました」などと書かれてい ます。 それなら、たっぷり時間を取ればいいと思われるかもしれませんが、そうもいきません。新人 さんの中には、キーボード入力が得意な人もいるからです。得意な人は飽きてしまいます。どう したらよいでしょう。キーボード入力の得意・不得意でクラスを分けられるならよいのですが、 研修の予算や会場の都合上、そうもいきません。「早くできた人は、まだできてない人を手伝っ てください」と指示してきましたが、キー入力という作業は手伝えるものではありません。今後 は、飽きる人が出てしまうのは仕方ないことして、徹底的に時間を取るようにしてみようと思い ますが、上手くいくかなぁ。 プログラムの改造をやってくれない (ry オブジェクト指向は難しい (ry ひとおおりの研修が終わった後で、ある新人さんから「int型やdouble型の配列が作れるのは わかりますが、オブジェクトの配列が作れるのはなぜですか?」という質問を受けました。こん な質問をが出るのは、オブジェクト指向を奇妙なものと思わせてしまったからです。「オブジェ クトの配列の方が普通なのであって、ただの数値のint型やdouble型の配列の方が特殊なのだと 考えてください」と答えましたが、新人さんをよけいに混乱させてしまったようです。欲を出さ ずに、新人研修ではオブジェクト指向に深入りするのをやめておけばよかったと反省しています。 newしなくても使えるのですか? (ry newというのは、オブジェクトを生成する命令です。つまり、この新人さんにとって、クラス は必ずnewして使うものなのです(実際には、newが不要なクラスもあります)。「今回の研修で は、Javaのオブジェクト指向に関する言語構文は登場しません」と答えたのですが、それでは納 得してくれません。仕方なく、1時間ほど時間を割いて、オブジェクト指向を忘れてもらうため に「プログラミングは、自分の頭の中にある考えをソースコードに書き表す行為です。オブジェ クトが生成されると考えたなら、そうすればよいでしょう。ただし、Javaでは、他の考え、つま りオブジェクト指向でない考えでもプログラムを作れるのです」と説明しました。 やれやれ、これで大丈夫だろう。そう思って休み時間に新人さんと雑談していたら、またまた ショッキングな発言がありました。それは「Javaでプログラムを作るときって、クラス分けが難 しいですね」です。そんなこと、大規模なプログラムを作るときに考えることでしょう。欲を出 してあれこれ言語構文を教えるから、こういう混乱が生じるのです。それでは、どこまで指導す ればよいのでしょう。研修のゴールを明確にしていなかったことを反省しています。
POD と オブジェクトの二本立てになるのは壁になりやすいんですかねえ。 やっぱりSmalltalkで…?(笑)
mukakenさんは年間にしてどのくらいこの手のイベント(勉強会)に参加されているんだろう?
matthew carriere: Using select, reject, collect, inject and detect. I spend a lot of time convincing my friends to switch to a Mac. Some of my friends are also software developers so naturally, just when they think the evangelism has come to an end, I convince them to get on the Rails. However, learning Rails usually means learning Ruby for the first time as well. In this post I am going to address one of the issues I see for newcomers to Ruby. Looping. Looping in Ruby seems to be a process of evolution for newcomers to the language. Newcomers will always find their way to the for loop almost immediately and when confronted with iterating an array, the first choice will generally be a for..in:a = [1,2,3,4] for n in a puts n endThis works, but its not very... Ruby. The next stage of evolution will be using an iterator for the first time. So the for loop gets dropped all together and each is used. The Rubyist is born at this point:a.each do |n| puts n end
で、次のような例を(元記事には説明がそれぞれあります)。
a = [1,2,3,4]
a.select {|n| n > 2}
a = [1,2,3,4]
a.reject {|n| n > 2}
a = [1,2,3,4]
a.collect {|n| n*n}
a = [1,2,3,4]
a.inject {|acc,n| acc + n}
a = [1,2,3,4]
a.detect {|n| n == 3}
matthew carriere: Using select, reject, collect, inject and detect. So if your head is spinning at this point as to which iterator to use for when, then remember this: 1. Use select or reject if you need to select or reject items based on a condition. 2. Use collect if you need to build an array of the results from logic in the block. 3. Use inject if you need to accumulate, total, or concatenate array values together. 4. Use detect if you need to find an item in an array. By using these iterators you will be one step closer to mastering... Ruby-Fu.
false || not(true) のパースが通らない件 - まめめも なんかえらい無茶をしているような。 not は優先順位の偉く低い“!”なんで(しかもその適用結果は式じゃなくて文)、 そのままでは使いどころがないといえばないかもしれないけど (たぶんLarryも and と or があるから not を作ったんだろうし(forの修飾子扱いで前例あり))。
↑ 優先順位が低くなる %nonassoc modifier_if modifier_unless modifier_while modifier_until %left keyword_or keyword_and ← 'and' と 'or' %right keyword_not ← 'not' %nonassoc keyword_defined %right '=' tOP_ASGN %left modifier_rescue %right '?' ':' %nonassoc tDOT2 tDOT3 %left tOROP ← '||' %left tANDOP ← '&&' %nonassoc tCMP tEQ tEQQ tNEQ tMATCH tNMATCH %left '>' tGEQ '<' tLEQ %left '|' '^' ← bitwise な 'or' と 'xor' %left '&' ← bitwise な 'and' %left tLSHFT tRSHFT %left '+' '-' %left '*' '/' '%' %right tUMINUS_NUM tUMINUS %right tPOW %right '!' '~' tUPLUS ← '!' と '~' (論理的な not と bitwise な not) ↓ 優先順位が高くなる
んなわけで
false || not(true) のパースが通らない件 - まめめも RubyKaigi 2008 の増原先生の発表 (資料) で飛ばされた部分に、「false || not(true) のパースが失敗 してはまる」ということが書いてありました。全くその通りだと思います。訓練された Rubyist は無意識に not を避けてると思います。
false || not(true) というのは、false || ときて、さらに「式」がこなきゃいけないのに not(true)という「文」が来てしまったので パーザがぶーたれた。と。 つーか、上の優先順位の定義を見れば思いっきり優先順位が低いので not 1 でいいはずだけどなあ(1 を囲むカッコが不要)。
irb(main):001:0> not 1 => false irb(main):002:0> 1 => 1
や、odzさんはもうわかってることだとは思いますが。
latin-1 - odz buffer latin-1CommentsAdd Star* ref:http://d.hatena.ne.jp/whitypig/20080624/1214299509 ただ,ISO 8859-1 may already be seen as the de-facto standard ASCII replacement. という記述が 非常に気になる。その前も気になるけど。日本ははぶ? skeleton.el の件の1行 - GONE WITH THE MEDICINE単に ASCII 互換な 8-bit コード体系で利用する国が多いだけでは。Latin Alphabet を使う国は多いし。 まぁ、でも latin-1 もそろそろ消えるべきだと思うなぁ。
まあそうですね。純粋な。というとまたちと変な表現になってしまいますが、ASCIIだと á とか ç、ë のような文字が入っていないので、西欧や東欧では使うに使えないということで その辺のキャラクタ込みのキャラクタセットであるISO-8859-* (1から16まで)が決められていて それは下位の7bitの部分はASCIIそのままなので、“de-facto standard ASCII replacement” な扱いを受けるようになったと。8859-* のなかで1が特別扱い(?)なのは
Manpage of ISO_8859-16 完全な ISO 8859 アルファベットは以下のものを含んでいる: ISO 8859-1 西ヨーロッパの言語 (Latin-1) ISO 8859-2 中央・東ヨーロッパの言語 (Latin-2) ISO 8859-3 東南ヨーロッパやその他の言語 (Latin-3) ISO 8859-4 スカンジナビア/バルト語派の言語 (Latin-4) ISO 8859-5 ラテン/キリル文字 ISO 8859-6 ラテン/アラビア文字 ISO 8859-7 ラテン/ギリシャ文字 ISO 8859-8 ラテン/ヘブライ語 ISO 8859-9 トルコ語用に修正を行なった Latin-1 (Latin-5) ISO 8859-10 ラップ/ノルディック/エスキモーの言語 (Latin-6) ISO 8859-11 ラテン/タイ語 ISO 8859-13 バルト諸国の言語 (Latin-7) ISO 8859-14 ケルト語 (Latin-8) ISO 8859-15 西ヨーロッパの言語 (Latin-9) ISO 8859-16 ルーマニア語 (Latin-10)
のように、「声のでかい連中」の使ってるものだから :)
で、日本は ISO-8859-1 でアクセントつき文字を格納した空間に “半角カナ”を収めたコードを決めて(JIS X 0201 - Wikipedia)使ったのですが、 そこからの物語は果てしなく長く険しい道なので投げっぱなしジャーマンで終わる(笑)
追加分ここから
なんとッ。他と比べてから買うかどうか決めようと思ってたのだが。
日本でも絶版になるような古い本をこうやって公開してくれないもんか喃。
Computerworld - The A-Z of Programming Languages: C++
Computerworld - The A-Z of Programming Languages: C++ Computerworld is undertaking a series of investigations into the most widely-used programming languages. Previously we have spoken to Alfred v. Aho of AWK fame, S. Tucker Taft on the Ada 1995 and 2005 revisions, Microsoft about its server-side script engine ASP, and Chet Ramey about his experience maintaining Bash. In this interview, we chat to Bjarne Stroustrup of C++ fame about the design and development of C++, garbage collection and the role of facial hair in successful programming languages. Stroustrup is currently the College of Engineering Chair and Computer Science Professor at Texas A&M University, and is an AT&T labs fellow.
あら、前の回でAho博士へのインタビューとな?
まあ「麻雀新撰組」なんつーのもあったしな。
ぽけギコでム板をチェックしていたら、FORTRANスレの未読数が77になっててちょっとにんまり(笑)
Firefox3でもCPUパワー莫迦喰い現象が発生しているところがある?
とある Java Appletを使ったページにアクセスしたらFirefoxが丸ごと固まる。 それなりに知られている現象らしいがびびった。 でもJREは該当のバージョンじゃないんだけどなあ。
おお sumim さんがネタを拾ってくれた。ありがとうございます。 翔泳社のどなたがあのチャートを作ったのかは存じませんが、 結構「濃そうな」方がいそうですよね(笑)
何はなくともまずはドキュメントを見る(U*ixみたいに ./configure とはいかないので)。 良い子のみんなは、U*ixでもイキナリ ./configure してはいけません :-)
On Windows, see PCbuild/readme.txt.
ふむ。
Building Python using VC++ 9.0
------------------------------
This directory is used to build Python for Win32 and x64 platforms, e.g.
Windows 2000, XP, Vista and Windows Server 2008. In order to build 32-bit
debug and release executables, Microsoft Visual C++ 2008 Express Edition is
required at the very least. In order to build 64-bit debug and release
executables, Visual Studio 2008 Standard Edition is required at the very
least. In order to build all of the above, as well as generate release builds
that make use of Profile Guided Optimisation (PG0), Visual Studio 2008
Professional Edition is required at the very least. The official Python
releases are built with this version of Visual Studio.
For other Windows platforms and compilers, see ../PC/readme.txt.
All you need to do is open the workspace "pcbuild.sln" in Visual Studio,
select the desired combination of configuration and platform and eventually
build the solution. Unless you are going to debug a problem in the core or
you are going to create an optimized build you want to select "Release" as
configuration.
(ry
NOTE:
You probably don't want to build most of the other subprojects, unless
you're building an entire Python distribution from scratch, or
specifically making changes to the subsystems they implement, or are
running a Python core buildbot test slave; see SUBPROJECTS below)
When using the Debug setting, the output files have a _d added to
their name: python30_d.dll, python_d.exe, parser_d.pyd, and so on. Both
the build and rt batch files accept a -d option for debug builds.
The 32bit builds end up in the solution folder PCbuild while the x64 builds
land in the amd64 subfolder. The PGI and PGO builds for profile guided
optimization end up in their own folders, too.
Legacy support
--------------
You can find build directories for older versions of Visual Studio and
Visual C++ in the PC directory.
The legacy build directories are no longer
actively maintained and may not work out of the box.
PC/VC6/
Visual C++ 6.0
PC/VS7.1/
Visual Studio 2003 (7.1)
PCbuild8/
Visual Studio 2005 (8.0)
(ry
ということで、PC/VS7.1/ の下を見てみると
2006/08/25 18:26 477 amd64_ml64.bat 2007/06/13 01:08 249 build_ssl.bat 2007/12/31 23:59 6,554 build_ssl.py 2008/01/01 01:18 7,277 bz2.vcproj 2006/04/16 03:06 237 db.build 2002/10/12 03:25 966 field3.py 2006/05/22 17:48 58,806 installer.bmp 2008/01/01 23:42 2,837 make_buildinfo.c 2006/03/10 03:49 3,005 make_buildinfo.vcproj 2008/01/01 01:18 3,755 make_versioninfo.vcproj 2007/06/11 06:01 19,505 pcbuild.sln 2008/01/01 01:18 7,310 pyexpat.vcproj 2006/04/16 03:06 633 python.build 2008/05/25 16:45 18,665 python.iss 2008/01/01 01:18 7,186 python.vcproj 2008/05/25 16:45 79,808 python20.wse 2008/06/13 07:27 19,528 pythoncore.vcproj 2008/01/01 01:18 6,803 pythonw.vcproj 2006/08/18 14:10 17,371 readme.txt 2003/04/26 09:53 597 rmpyc.py 2008/06/04 22:06 1,557 rt.bat 2008/01/01 01:18 6,840 select.vcproj 2008/01/01 01:18 6,595 unicodedata.vcproj 2001/08/05 13:12 9,764 Uninstal.wse 2008/01/01 01:18 2,899 w9xpopen.vcproj 2008/01/01 01:18 6,711 winsound.vcproj 2008/01/01 01:18 7,178 _bsddb.vcproj 2008/01/01 01:18 8,517 _ctypes.vcproj 2008/01/01 01:18 6,391 _ctypes_test.vcproj 2008/01/01 01:18 7,526 _elementtree.vcproj 2008/01/01 01:18 6,729 _msi.vcproj 2008/01/01 01:18 6,704 _socket.vcproj 2008/01/01 01:18 7,856 _sqlite3.vcproj 2008/01/01 23:42 1,381 _ssl.mak 2008/01/01 01:18 2,290 _ssl.vcproj 2008/01/01 01:18 6,563 _testcapi.vcproj 2008/01/01 01:18 7,314 _tkinter.vcproj
こんな感じ。 いきなりフルビルドもあれなので、名前がそれっぽい python か pythoncore というプロジェクト(ソリューションにぶら下がっている一つ一つのビルド要素。みたいなもの) を試してみることにする。
最新の更新が今年1だから、ひょっとして行けるか? と思い、F5でビルドすると…
(略) structmember.c stringobject.c c1 : fatal error C1083: ソース ファイルを開けません。'\work\src\Python-3.0b1\Objects\stringobject.c': No such file or directory sliceobject.c (略) _localemodule.c json.c c1 : fatal error C1083: ソース ファイルを開けません。'\work\src\Python-3.0b1\Modules\json.c': No such file or directory _heapqmodule.c (略)
と、エラーが二つ(この他に警告が何箇所か)。 Objectディレクトリを見てみると、確かに stringobject.c というファイルはない。 ということでプロジェクトから削除。 jsonの方は json.c というのはなかったが _json.c というのがあった。 そこでプロジェクトに登録されているのを変えようとしたが… 一回削除しないといけないんだっけ? としばらく操作に悩む。
リンクしています... ライブラリ .\./python30_d.lib とオブジェクト .\./python30_d.exp を作成中 tokenizer.obj : error LNK2019: 未解決の外部シンボル _PyByteArray_FromStringAndSize が関数 _error_ret で参照されました。 unicodeobject.obj : error LNK2001: 外部シンボル "_PyByteArray_FromStringAndSize" は未解決です。 zipimport.obj : error LNK2001: 外部シンボル "_PyByteArray_FromStringAndSize" は未解決です。 zlibmodule.obj : error LNK2019: 未解決の外部シンボル _PyByteArray_FromStringAndSize が関数 _PyZlib_compress で参照されました。 winreg.obj : error LNK2001: 外部シンボル "_PyByteArray_FromStringAndSize" は未解決です。 memoryobject.obj : error LNK2001: 外部シンボル "_PyByteArray_FromStringAndSize" は未解決です。 (略) zipimport.obj : error LNK2001: 外部シンボル "_PyByteArray_Size" は未解決です。 pythonrun.obj : error LNK2019: 未解決の外部シンボル _PyByteArray_Init が関数 _Py_InitializeEx で参照されました。 pythonrun.obj : error LNK2019: 未解決の外部シンボル _PyByteArray_Fini が関数 _Py_Finalize で参照されました。 ./python30_d.dll : fatal error LNK1120: 外部参照 8 が未解決です。
Objectsの下を見ると、bytearrayobject.c というのがあって これがプロジェクトに登録されていない状態なので登録する。 んで、リビルド。
リンクしています... ライブラリ .\./python30_d.lib とオブジェクト .\./python30_d.exp を作成中 結果 ビルドログは XXXXX に保存されました。 pythoncore - エラー 0、警告 5
今度は通った模様。 このプロジェクトでは(デバッグバージョンの)インタプリタコアの .dll しか作らないので、 それを使う実行ファイル python.exe (のデバッグバージョン python_d.exe)を作成する プロジェクトを実行する。 問題なく終了。
C:\tmp\src\Python-3.0b1\PC\VS7.1>python_d Python 3.0b1 (r30b1:64395, Jun 24 2008, 21:22:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>>
おお。
たぶん続かない。
おや、終了したらなんか出てきたぞ(デバッグ用のなにかか?)
>>> ^Z [42106 refs] [28881 refs]
ところでPythonのメンテナの皆さんはこの .sln ファイルとか .vcprojファイルは 手作業でいじってんだろうか? XMLファイルだし自動生成できそうな気がしないでもないけど。
Acme::NabeAtzz - One, Two, さーん - search.cpan.org
Acme::NabeAtzz - One, Two, さーん - search.cpan.org NAME Acme::NabeAtzz - One, Two, さーん SYNOPSIS use Acme::NabeAtzz; write your perl code DESCRIPTION ^ Acme::NabeAtzz is so crazy Japanese comedian AUTHOR Kazuhiro Osawa SEE ALSO opnames.h REPOSITORY svn co http://svn.coderepos.org/share/lang/perl/Acme-NabeAtzz/trunk Acme-NabeAtzz Acme::NabeAtzz is Subversion repository is hosted at http://coderepos.org/share/. patches and collaborators are welcome. LICENSE ^ This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
ExpertMouse5 - 神様なんて信じない僕らのために ■[misc]ExpertMouse5CommentsAdd Star id:minekoaさんのに惹かれて中古のExpertMouse5を買ってしまった。orz... しかし、最高の操球感です。 すげえぜ、トラックボール!!!!美しい・・、本当に美しいデザインのトラックボールです。 猫のトラックボールルーム ~Kensington Expert Mouse 5~
魔操球 なんつて。 元が古いですね○| ̄|_
前文? の部分が歯欠けだけどいいや。
Download the Builder.com Ten Commandments of Egoless Programming Takeaway: In a team-based development environment, egoless programming is a necessity. Download our Ten Commandments in tablet format as a reminder to keep your ego separate from your code. チームを組んで開発を行う環境では、エゴレスプログラミング(egoless programming)は必要不可欠なものです。 わたし達の使っている十戒を tablet formatにまとめたものをダウンロードして あなたのエゴとあなたのコードとを分け続けておくことを忘れないようにしてください。 Part state of mind and part QA philosophy, the term "Egoless programming" was coined by one of my favorite authors, Jerry Weinberg, back in 1971 in his highly influential book, The Psychology of Computer Programming. Weinberg was describing a development environment that involved heavy use of peer technical reviews. He used the term to describe the mindset that programmers developed after working in this environment for a time. “エゴレスプログラミング”(egoless programming)という言葉は、 わたしの好きな作家の一人である Jerry Weinberg によって coined されたもので 1971年の The Psychology of Computer Programming (邦題 プログラミングの心理学 プログラミングの心理学―または、ハイテクノロジーの人間学 25周年記念版:) に掲載されています。 Weinberg は The basic idea behind Weinberg's philosophy was that a system of formal peer reviews effectively multiplied the number of eyes looking for logic problems, poor algorithm choices, or even syntax. These extra eyes could catch nascent bugs much earlier in the development cycle than traditional testing could, resulting in shorter project completion times and lower defect counts in live systems. For developers to accept this system, of course, they had to set their egos aside. Weinbergの哲学に隠された基本的な考え方というのは、 formal peer review を使ったシステムというものが 論理的な問題だとか、まずいアルゴリズムの選択、はたまた構文の間違いを探す 目玉の数を効率的に倍増するというものです。 この増えた目玉はは極く初期のバグ(nascent bugs)を 伝統的なテスト手法よりも開発サイクルの早くに捕捉することを可能にします。 その結果としてプロジェクトの completion times は短く、 稼動しているシステムの欠点をより小さなものにします。 開発者がこのシステムを受け入れるためには、もちろんのことですが 彼らが自分たちのエゴというものを脇に置かなければなりません。 Popular peer reviews Does that sound familiar to you? It should. The idea of formal peer code reviews has figured in a number of development methodologies (or "fads," for the more jaded among our audience) and has been getting more popular recently. Extreme Programming, with its trademark two-developers-per-machine standard, could be viewed simply as a peer-review facilitation strategy. Likewise, the open-source community development process, which has historically been successful in producing high-quality, low-defect software, could be seen as one giant peer review. 形式的なピアコードレビュー (formal peer code reviews) の考えというのは 数ある開発手法の中の一つと見なされていて、近年になってより一層 ポピュラーなものとなってきているものです。 Extreme Programming はピアレビューの facilitation 戦略を単純にしたものと 見ることができます。 オープンソースコミュニティでの開発プロセス Obviously, thin-skinned developers (and some would argue there is no other kind) would be at a disadvantage when working in an environment where constructive criticism is handed out so freely. Programming, like writing or creating art, is a very personal endeavor, and, like artists, some of us just can't stomach it when someone else disparages our work. The Ten Commandments 十戒 What we need is a set of rules or guidelines to help developers keep themselves (their egos, actually) separate from their code. Hence our Ten Commandments for Egoless Programming, which you can also download in handy "stone tablet" format: わたしたちに必要なのは、デベロッパー自身が自分たちと自分たちの書いたコードとを分けて おきつづけることのできるルールやガイドラインです。 故に、エゴレスプログラミングのための十戒を 1. Understand and accept that you will make mistakes. あなた自身も間違いを犯すということを理解し受け入れなさい。 The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on. 肝腎なことは、間違いを早期に製品に紛れ込まないうちに見つけ出すということです。 幸いなることにJPLでロケットの guidance ソフトウェアを開発している一部の例外を除き わたし達はわたし達の産業界に致命的な影響を及ぼすような間違いを犯すことは まずありません。故にわたし達は学ぶことができるのであるし、また学ぶべきであり、 他者の失敗を(責めるのではなく)笑い飛ばし、そしてその対処に取り組むべきなのです。 2. You are not your code. あなたの書いたコードはあなた自身ではありません。 Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered. レビューで肝腎なことは問題を見つけ出すことであることを忘れないでください。 そして問題は見つかるものです。 ある問題が見逃されたときに、それを個人の問題に帰するものとはしないでください。 3. No matter how much "karate" you know, someone else will always know more. あなたがどれだけ“karate”を知っているかということは問題ではありません。 Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed. あなたよりも知っているという他の誰かが常に存在しているのです。 (あなたよりも“karate”を知っているという)そのような人はあなたが求めれば あなたに新しい何かを教えてくれるかもしれません。 他者からの入力を求め、受け入れなさい。 特にあなたがそれを自分には必要でないと思っているときに。 4. Don't rewrite code without consultation. 相談抜きにコードの書き直し(rewrite)をしてはいけません。 There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer. “fixing code”(コードの修正)と “rewriting code”(コードの書き直し)の間には 明確な境界線があります。その違いを知り、lone enforer のようにはならないように コードレビューで使ったフレームワークの内側で行われたスタイルに関する変更を追いかけましょう。 5. Treat people who know less than you with respect, deference, and patience. あなたよりも知識の少ない人々に対して、respect (敬意) と deference (尊重) とpatience (忍耐) を 持って接しなさい。 Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience. 技術畑にいないけれども開発者たちを束ねているような人たちは往々にして、 わたしたちが prima donnas at best and crybabies at worst (なんかの比喩? 良くてプリマドンナ、悪くて泣き虫?) であるという意見を一般的にはもっているものなのです。 このステレオタイプを怒りと苛立ちとで補強しないようにしてください。 6. The only constant in the world is change. この世界の中の 'constant' ("定数"ではない?) だけが変わります。 Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought. 変化に対してオープンでいて、変化を笑顔で受け止めてください。 一部の深刻な不便をもたらすような戦うべきそれではない、 あなたの要求に対する変化やあなたの使っているプラットフォームの変化、 あるいは新しい挑戦としてのツールの変化に注意してください。 7. The only true authority stems from knowledge, not from position. 本当のauthority (権威?)というものは知識からくるものであって地位からではありません。 Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge. 知識が authority を生じ、authority が respectを生みます。 ですからあなたがエゴレス環境において respect を得たいと思うのなら、知識を深めなさい。 8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes 自らの信じるもののために戦いなさい。しかし喜びを持って敗北を受け入れなさい。 your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry. あなたの考えることが覆されることや却下されることががありうることを理解しなさい。 仮にあなたのほうが実は正しかったということがわかったとしても、復讐したり、 “だから云ったじゃないか”(I told you so)といった言葉を吐いてはいけません。 また、惜しくも使われることなく消えたアイデアに固執しすぎてはいけません。 9. Don't be "the guy in the room." “The guy in the room”になってはいけません。 Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment. 表に出るのはコーラを買いに行くときだけで、暗いオフィスでコーディングをするばかりの 野郎になってはいけません。The guy in the room は out of touch で out of sight で out of controlで オープンな collaborative environment に居場所がありません。 10. Critique code instead of people—be kind to the coder, not to the code. その人がどのようなコーダー(coder)であるかについてではなく、コードそのものを批評すること。 As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc. 可能な限り常に肯定的なコメントをして、コードを改良することを目指しなさい。 コメントはローカル標準や、プログラムの仕様、パフォーマンスの向上などなどに関連させること。 Download the “stone tablet” version of the Ten Commandments of Egoless Programming. Everything old is new again? Those members who have been with us since our humble beginning as TechRepublic's Developer Republic may remember a shorter version of these Ten Commandments. This new Builder.com version has been updated with each commandment's amplifying text, which was missing from the original version. Enjoy.
例によって例のごとく。
正規表現についての入門記事なんですが、引っかかるところが一箇所だけ。 一応 Perl と JavaScriptのそれをベースに解説するという断りがあるので いいっちゃいいんですけど、記事に末尾にあるカンペ(cheat sheet)なんかにも 正規表現ならどれもこういうものだと受け取れなくもないのでちょっと気になる。 まあPOSIX BRE/ERE ? なにそれ、オイシイの? って扱いもうなずけなくもないんだけど、 ちょっとひっかかったのは選択(altanative '|' )の動作の解説で
abc|abcdef|abcdefghi
のような選択があった場合は常に左側のものが優先されてそれが最長かどうかは 関係ないという解説があるのだけど、これ、詳説正規表現にも解説があったはずだけど 正規表現エンジンが DFA だとか(詳説正規表現で言うところの)POSIX NFAだと どのようにならべても最長のものを選択するはず。 実際、GNU grep でもこういう動作をする。
>echo abcdefghijklm | d:\cygwin\bin\grep -E -o -e "abc|abcdef|abcdefghi" abcdefghi >d:\cygwin\bin\grep --ver grep (GNU grep) 2.5.1 Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Ruby (1.9ね)では有効になってないし、現時点でいじるオプションもなかったと思うけど 鬼車もこのように動作させるフラグを持っている。
ついでにいうと sed も同じ。 まあ本来 POSIX では sed の正規表現は選択を持ってないのだけどね。
>echo abcdefghi | sed -e "s/abc\|abcd\|abcde\|abcdef/XXXXXX/" XXXXXXghi
おっとこいつもあった。
>type substtest.php
<?php
$str = 'abcdefghijklmn';
$newstr = ereg_replace('abc|abcdef|abcdefg', 'XXXXXX', $str);
echo $newstr;
>php substtest.php
XXXXXXhijklmn
preg* と mb_ereg* は多分違う(Perlと同じ)。
アルファギークと学生の討論会 - 速報 - ひがやすを blog _ 2008/06/24 12:45 予定調和で終わるんじゃね?けっきょく金と権力もってて、一生プログラ ミングなんて知らないで済むオッサンたちには、逆らえないようにできてるんだよ。それを確認 するためだけのために、ショボイ男ドモで集まってどうしようというのか?という気がしないで もない。
本名を見てひっくり返りました。
Engineer25 すべてを楽しむ若きスーパーエンジニア達 第4回 cho45氏- ウェブキャリア 川井: なるほど。それこそ深層心理の世界に入り込まないといけないんで、甲殻機動隊とかマ トリックスの世界ですね。
コラッw >甲殻 (正しくは「攻殻機動隊」)
【日本Ruby会議2008】「Rubyは技術者が集まり世界を変える“梁山泊”に」---まつもと氏:ITpro たぶん日本で広まっているイメージ (ってわたしも日本以外でどうだか知りませんけど)で梁山泊って使ったんでしょうけど、 水滸伝を読んだ人って少ないんですかねえ? 北方謙三の水滸伝は結構売れてるらしいですが。 そもそもどういう連中が梁山泊に集まったかというと
梁山泊 - Wikipedia 梁山泊近辺に横行した反抗者の中でも、北宋末期の12世紀初頭に河北で蜂起し山東一帯で10郡を 制圧した宋江の反乱軍は猛威をふるった。14世紀の元の時代に編纂された『宋史』には「宋江、 京東を寇す」「(宋)江、三十六人を以て斉・魏を横行し、官軍の数万に敢えて抗する者なし」 とある。まもなく宋江の反乱は鎮圧されるが、やがてこの史実をもとに、梁山泊に宋江以下36人 のアウトローたちが立てこもる物語が生み出され、明の初め頃に、梁山泊に集う108人のアウト ローたちを主人公とする小説『水滸伝』へとまとめられた。
で、物語の終盤はどうなるかというと
水滸伝 - Wikipedia 『水滸伝』の原本 中国の通俗小説は「回」と呼ばれる講談の一話に相当するまとまりからなるが、現存する版本か らの考察では百回構成が最も古い形とされる。容与堂本では、梁山泊に百八人の豪傑が集うまで を描いた七十一回と、梁山泊と朝廷の奸臣たちが派遣した官軍との戦いを描く十回、百八人が朝 廷の招安を受けて、北方の契丹人の王朝遼と戦う九回、江南で宋江たちと同じように方臘の乱を 起こしていた方臘を官軍として討伐する中で梁山泊集団が壊滅してゆく過程を描いた十回に分か れる。 水滸伝が人気を博するようになると、16世紀頃に最後の方臘戦十回の前に、百回本では叛徒とし て名前が登場するのみの田虎、王慶の反乱軍を鎮圧するそれぞれ十回が付け加えられた百二十回 からなる版が生まれた。これを百二十回本と呼び、もともとの百回構成の版を百回本と呼ぶ。
確かわたしの高校生時代だったと思うのですが、友人が水滸伝を評して 「あれはなんのかんの言って役人に丸め込まれてこき使われた挙句に犬死する連中の話だ」 と。なんぼなんでもこれは酷すぎる言い方だとは思うのですが、まあハッピーエンドの類ではないと。
さらに云えば頭目の宋江にしてからがこういう評価もあると (ま、小説中のお話ですが)。
宋江 - Wikipedia 小説中の宋江は「器と人徳、面倒見の良さ以外に取り柄が無い」「目を付けた人間を仲間にする ためならどんな手段も使う」「腐敗した朝廷に帰順してその走狗と成り果て、多くの好漢、さら には自身の身も滅ぼした」との評価もされ、主人公であるにも関らず読者の人気のあまり高くな い人物である。梁山泊の好漢達の多くは、現状の宋朝廷の腐敗政治に恨みを持つものや、支配層 とは相容れない社会の底辺の人々も多く、自由を求める人物が多かったため、宋江の生真面目な までの現体制への忠誠心と著しく乖離しているように見える。しかし好漢たちの梁山泊入りには 様々な動機があり、元は善良な市民であるという宋江の道徳観があり、朝廷帰順という大方針も 宋江なりに好漢達の行く末を案じての決断であったようでもある。どんな人物でも受け入れる広 い度量を持つ宋江がいたからこそ梁山泊はあれだけの大勢力が築かれたともいえよう。
まあどうでもいい戯れ言です ;-)
ベイスターズのあまりの惨状に、プレイボーイが特集記事を組んだらしいw。 大ちゃんが監督のときもやったっけか?
東スポ。 小橋~ぃw
はじめてのにき(2008-06-23) _ VMとか http://natu.txt-nifty.com/natsutan/2008/06/post_d6a1_2.html 演算の対象、つまり即値じゃないオペランドが どこにあるか、でスタックマシンとレジスタマ シンは 呼び分けてるのかなぁと思ってた。 だからたぶんだいたいのリアル CPU はレジスタマ シンじゃないかなぁとか。 MAXQ とかはメモリマシンとか呼んであげたい感じなんだろうか。 http://japan.maxim-ic.com/products/microcontrollers/maxq.cfm あとなんか IA64 のレジスタスタックの方が もっとスタックスタックしてる気がするような。
IA-64は入り口(ってナニ?)付近しか知らないのでちとぐぐってみる。
IA-64 - Wikipedia レジスタ IA-64アーキテクチャは、128本の64ビット整数レジスタ(r0~r127)と128本の82ビット浮動小 数点レジスタ(f0~f127)という非常に多くのレジスタを定義している。 整数レジスタ 128本の64ビット整数レジスタ(r0~r127)の内、汎用レジスタとしてはr0~r31の32本が使われ る(r0は、ゼロレジスタで読み出すと常に 0 を返し、書き込むと例外が発生する)。 残りの96 本(r32~r127)はレジスタスタックエンジン (Register Stack Engine; RSE) を使ったレジス タローテーションという手法で管理され、プロシージャ呼び出し間で名前が変更される可能性が ある。これは多くのRISCプロセッサに見られるレジスタ・ウィンドウを洗練させたもので、AMD Am29000のオーバーラップウィンドウサイズを変更可能なレジスタ・ウィンドウとの類似性が指摘 されるが、IA-64ではプレディケーションと組み合わせることで、ループを自動的に展開して実 行することができる。
NAKAMURA Minoru's Diary (2008年5月) IA-64 は汎用レジスタが 128 本あるが、 r32 から r127 までの 96 本はスタック汎用レジスタ と呼ばれ、 関数呼び出しの・復帰にあわせて自動的に回転するようになっている。 物理レジス タから溢れたスタック汎用レジスタは レジスタ・スタックと呼ばれるメモリ領域に書き出され るのだが、 その時 r32 番にあたるレジスタの退避先になる領域をしめしているのが ar.bsp レ ジスタだ。
Wikipediaの方の記述に名前が出てきているけど、確かにぱっと見 AMD am29000シリーズに 似た機能がありますね。「プレディケーション」てのがよくわからないけど、「自動」云々 てあるから、レジスタ群→メモリとかメモリ→レジスタ群への退避と復帰について あまり気にしないでいいってことなんかな。確か、おぼえているところでは am29000シリーズだと この辺の操作はプログラマ(つかコンパイラ)が手作業でやらないといけなかった。 とはいえサンプルのルーチンがAMDから公開されてたと思うけど。
こんなのもひっかかったり。 コンパイル方法、コード生成方法、スタックレジスタ使用方法、コンパイラ、これらを実現するプログラム及び記憶媒体
Parrot: Parrot Hackathon and Workshop at YAPC::NA 2008 Sunday, June 22, 2008 Parrot Hackathon and Workshop at YAPC::NA 2008 Many parrot committers attended the recent YAPC:NA; we scheduled a pre-conference hackathon that turned out to be very effective. Thanks to the conference hosts for keeping us floating in caffeine and snacks. More than the closed tickets and committed code, the face to face time with the other committers is always a plus. Working with someone online is very different than a face to face meeting, and can lay the groundwork for future collaboration efforts. Jim Keenan drove a workshop at the conference, a new format that provides an extended, freeform timeslot. Jim used the workshop to get everyone there to build both parrot and Rakudo. We were able to get most of the folks there building on their respective platforms. For those who did encounter difficulties, we were able to get some bug reports (and some fixes), and even some patches from those new to the project. (Packy++ and Deven++) I even got someone potentially interested in partcl (Tcl on Parrot) out of the workshop, a bonus I was not expecting. (Shane++). Hopefully we can recreate some of this success at YAPC::EU, and definitely next year at YAPC::NA '09. See you then!
ビルドしたパッケージをほかのマシンに持っていってインストールしても 動かない現象はどうにかならんのか喃。 インストーラ込みでビルドしているし抜けてるDLLとかもないと思うんだけどなあ。 いっぺんソースにもぐらないとダメか○| ̄|_
Rubyにワクワク感以上に求めるもの - ひがやすを blog → Rubyは10年前のJava - @IT
Rubyにワクワク感以上に求めるもの - ひがやすを blog またRubyを仕事で使うメリットとして 「アジャイル開発がしやすい、プロトタイピングが容易」 「学習曲線が早い」ことを挙げた。 Railsがあるので、プロトタイピングはやりやすいと思います。アジャイル開発は、チームのマ インドの問題なので、言語は関係ないよね。 「学習曲線が早い」というのは、賛成できないなぁ。
ちと字が違うのが気になりますが、元はこれですかね
Rubyは10年前のJava - @IT これに対しRubyの場合は「アジャイルというか、動くものを比較的速く作り、顧客に見せることが できる」(最首氏)。Rubyの場合、キャッチアップが非常に速くできる学習曲線の速さも魅力だと 述べた。
学習曲線の傾きが大きい/小さいとか急だとか緩いとかいう表現なら理解できるんですが、 「速い」って? まあ習熟するのが早いということなんでしょうけど、 こういう言い間違い(か?)はスゲー気になります。 ちょっと前の「泥のように」とか(これはいい間違いの類ではないみたいですが)。
上司や先輩にその手の突っ込みいれて不興を買ったのは何度となく :)
Archived Message - CIA.vc Commit Message Author: usa Project: ruby Revision: 17506 Changed Lines: 3 Win32 experimental branch for using Unicode version API. Modified Files * branches o win32-unicode-testAdded
こっちのブランチを追いかけるべきだらふか。
【ニュース】アルファギークと学生の討論会が開催される見込み 経由で
アルファギークと学生の討論会 - 速報 - ひがやすを blog 日にちは、9月上旬の土日(たぶん9/6以外)。200名くらい入る場所で検討中とのことです。興味 のある方は、予定を空けておいてください。
200かあ。受付開始数秒で満席になりそうだな。 そうするとたぶん勝てない(なにに?)
Perlについての質問箱 35箱目 655 デフォルトの名無しさん [sage] Date:2008/06/23(月) 20:20:32 ID: Be: activeperlのダウンロードなんだけど、 参考にしているページでは、 5.8系と 5.6系とあって、 ほとんどのサーバーでは5.6系に対応しているので 5.6系をダウンロードしてください、 5.8系では対応してなくて動かない可能性があります、 と書いてあるのだが、実際activestateのページにいってみると、 なんと、5.6系は消えてしまって、 5.1系と、 5.8系の二つしか残っていないのだ。 この場合、どちらをダウンロードすればいいのだ? 656 デフォルトの名無しさん [sage] Date:2008/06/23(月) 20:33:40 ID: Be: >>655 5.1じゃなくて5.10な。とりあえず5.8で問題ない。 658 デフォルトの名無しさん [] Date:2008/06/23(月) 21:15:08 ID: Be: >>655 まず、その「参考にしているページ」とやらは参考にするな。 日本のサーバー屋は一時期Perl5.6同梱のLinuxを大量に設置したから、リプレースするのが面倒 でそういう戯言を言う奴が多い。 Perlは基本的に(PHPと違って)バージョンアップによる互換性問題は少ない方だが、5.6系だけは 鬼門というのが一般常識。 特にUNICODE関係※は痛いから、おとなしく5.8以降(今なら5.10)を使うべし。5.6を使うくらい なら、まだ5.005の方がまし。 それと、いまだに5.6を入れてるサーバー屋がいたら相手にしないこと。 ※5.6の段階ではUNICODEとマルチスレッドは「実験的実装」とちゃんとアナウンスがあったから、 5.6でUNICODEを使った奴がお馬鹿さんとも言う。 659 デフォルトの名無しさん [sage] Date:2008/06/23(月) 22:02:12 ID: Be: >>658 世間知らず 660 デフォルトの名無しさん [sage] Date:2008/06/23(月) 22:08:12 ID: Be: >>658 >5.8以降(今なら5.10)を使うべし え?どっち? 661 デフォルトの名無しさん [sage] Date:2008/06/23(月) 22:15:35 ID: Be: 安定動作なら5.8のが良いってDLページにかいてあるじゃん 662 デフォルトの名無しさん [sage] Date:2008/06/23(月) 22:17:39 ID: Be: >>660 5.6がベストってことだよ 663 デフォルトの名無しさん [sage] Date:2008/06/23(月) 22:18:52 ID: Be: 混乱してきたww 664 デフォルトの名無しさん [sage] Date:2008/06/23(月) 22:23:30 ID: Be: >>655 用途は知らんが今からActivePerl使うなら5.8以降でないと色々ツライ目に合うかもしれん。 5.6系以前は問題外だ。 5.10は使いたいモジュールのPPMが無かったりすると手間取るからな。 665 デフォルトの名無しさん [sage] Date:2008/06/23(月) 22:28:46 ID: Be: >>662 いまどき5.6なんて言ってるととほほでK.NTになっちまうぞ?
C++0x 3 947 デフォルトの名無しさん [sage] Date:2008/06/20(金) 23:52:39 ID: Be: .NETのStringって 非変更型の関数しかないけど なんか理由あるの? 948 デフォルトの名無しさん [sage] Date:2008/06/21(土) 00:05:17 ID: Be: >>947 immutableだから。 949 デフォルトの名無しさん [sage] Date:2008/06/21(土) 00:06:03 ID: Be: immutableの方が何かと都合がいいから 950 デフォルトの名無しさん [sage] Date:2008/06/21(土) 00:15:24 ID: Be: C++でいうと boost::shared_ptr<string>でしか使えないわけだから 何かの拍子に書き換えられるとヤバイのかな。 stringでコピーして共有するか選ばなきゃいけないわけだ。 951 デフォルトの名無しさん [sage] Date:2008/06/21(土) 01:00:08 ID: Be: 効率より安全性を採用したわけね。 952 デフォルトの名無しさん [sage] Date:2008/06/21(土) 01:19:26 ID: Be: いやむしろ効率を重視してる。 immutableなコンテナはmutableにするための仕組みが不要だから高速化できる。 .Netのimmutable containerがそうだと断言はできないが、少なくともCocoaのFoundationはそう。 953 デフォルトの名無しさん [sage] Date:2008/06/21(土) 01:26:43 ID: Be: .NETはJIT前提だからね。immutableであることが判ってると、実行時にもいろんな最適化ができる。 954 デフォルトの名無しさん [sage] Date:2008/06/21(土) 01:28:38 ID: Be: ちょっとした処理が効率化されても コピーが発生するのは致命的じゃないか? メモリ確保も発生する訳で。 955 デフォルトの名無しさん [sage] Date:2008/06/21(土) 01:33:47 ID: Be: >>954 使いどころによる。mutableでも変更したら結局コピーやメモリ確保が発生する。 immutable containerの生成時は(それが他のコンテナに基づくものなら) 内部データの参照カウンタを増やすだけかもしれない。 956 デフォルトの名無しさん [sage] Date:2008/06/21(土) 01:40:04 ID: Be: >>954 .NETでは頻繁に書き換える場合はStringBuilderというものを使う 957 デフォルトの名無しさん [sage] Date:2008/06/21(土) 01:43:01 ID: Be: boost::shared_ptr<string const> で immutable な string のできあがり? 958 デフォルトの名無しさん [sage] Date:2008/06/21(土) 01:45:24 ID: Be: なるほど。 使い分けてんのね。 959 デフォルトの名無しさん [sage] Date:2008/06/21(土) 10:10:53 ID: Be: D言語も2.0からimmutableになってたような 960 デフォルトの名無しさん [sage] Date:2008/06/21(土) 13:33:27 ID: Be: Dはinvariantとconstとmutableを使い分けられる変態言語 961 デフォルトの名無しさん [sage] Date:2008/06/21(土) 14:42:03 ID: Be: invariantって長いよね
推薦図書/必読書のためのスレッド 40 596 デフォルトの名無しさん [] Date:2008/06/23(月) 08:07:23 ID: Be: JAVA言語 これ理解してたら バカにされない本教えて 597 デフォルトの名無しさん [sage] Date:2008/06/23(月) 08:55:00 ID: Be: Java言語 598 デフォルトの名無しさん [sage] Date:2008/06/23(月) 09:02:26 ID: Be: >>596 Java Language Specification Java Virtual Machine Specification 英語のちょっと古めのならタダで読める。 600 デフォルトの名無しさん [sage] Date:2008/06/23(月) 10:23:32 ID: Be: >>596 SCJP Sun Certified Programmer for Java 5 (Exam 310-055) 資格取れば馬鹿にはされんだろw
関数型言語ML(SML, OCaml, etc.), Part 5 461 デフォルトの名無しさん [sage] Date:2008/06/23(月) 12:22:57 ID: Be: [1;2;3;4]を入力すると[1;3;6;10]を返す関数sigmaを書いたんですが sigma関数の箇所、もっと効率的なやり方があるような気がしてむずがゆい感じがしてます。 何かアドバイスいただけないでしょうか let iota n = List.init n ((+)1) in let sum lst= List.fold_left (+) 0 lst in let rec take n lst = match n with 0 -> [] | 1 -> [List.hd lst] | _ -> (List.hd lst)::take (n-1) (List.tl lst) in let sigma lst = List.rev (List.fold_left (fun x y->sum (take y lst)::x) [] (iota (List.length lst))) in sigma [1;2;3;4;5;6];; 462 デフォルトの名無しさん [sage] Date:2008/06/23(月) 13:13:09 ID: Be: 累積変数で、これまでの和を持ち運ぶ 463 デフォルトの名無しさん [sage] Date:2008/06/23(月) 14:45:07 ID: Be: ありがとう。こんな感じですかね (途中まで同じ) let sigma lst = let accum = ref [] in List.rev (List.fold_left (fun x y-> accum:=y::!accum; sum !accum::x) [] (iota (List.length lst))) in sigma [1;2;3;4;5;6];; 464 デフォルトの名無しさん [] Date:2008/06/23(月) 15:38:22 ID: Be: えー。「ここまでの結果」を「引数で」持ちまわるんだよ。再帰終了するところでその引数をそのまま返す。 465 デフォルトの名無しさん [sage] Date:2008/06/23(月) 15:59:00 ID: Be: んー、持ち回る引数がfoldの中なので、プログラム全体の形、結構変わりますよね? こういった変換は慣れていないので、ちょっと時間がかかりそうです 466 デフォルトの名無しさん [sage] Date:2008/06/23(月) 17:53:21 ID: Be: iotaとかsumとかtakeとかを使わないで、さらにfoldにこだわらなくて、かつ再帰を使っていいなら こんなのはどうっすかね? let sigma l = let rec sigma' cur r = function | [] -> List.rev r | x::xs -> let next = cur + x in sigma' next (next :: r) xs in sigma' 0 [] l # sigma [];; - : int list = [] # sigma [1;2;3;4;5;6];; - : int list = [1; 3; 6; 10; 15; 21] foldとかを使ったもっとElegante"~{エレガンテ}~"な方法を希望ならスマソ。 467 デフォルトの名無しさん [sage] Date:2008/06/23(月) 20:17:29 ID: Be: こんな感じ。 reverse $ snd $ foldl (\(a,xs) b -> let x = a + b in (x,x:xs)) (0,[]) Haskellの構文を使ってるがMLでも同様のはず。 468 デフォルトの名無しさん [sage] Date:2008/06/23(月) 20:21:41 ID: Be: pairにする必要ないんじゃ… tail $ reverse $ foldl (\a b -> (head a + b):a) [0] 469 デフォルトの名無しさん [sage] Date:2008/06/23(月) 20:37:13 ID: Be: >>468 おお、こういうのがノータイムで出てくるようになりたいわ。 470 デフォルトの名無しさん [sage] Date:2008/06/23(月) 21:44:56 ID: Be: let sigma lst = let rec sum lst = match lst with | [] -> [] | car :: cdr -> (List.fold_left (+) 0 lst) :: (sum cdr) in List.rev (sum (List.rev lst));; こんなんどうでっしゃろ? 471 デフォルトの名無しさん [sage] Date:2008/06/23(月) 21:48:14 ID: Be: >>467-468 おまいらHaskell大好きだなwwwww 472 デフォルトの名無しさん [sage] Date:2008/06/23(月) 22:44:06 ID: Be: MLの構文を知らずにこのスレを覗いてる奴が結構居ると予想 473 デフォルトの名無しさん [] Date:2008/06/23(月) 22:46:14 ID: Be: 関数の中ですぐmatchするのってfunctionで書き直しちゃいたいんだけど。 474 デフォルトの名無しさん [sage] Date:2008/06/23(月) 23:08:55 ID: Be: let sigma l = let rec aux store = function | [] -> [] | x::xs -> x+store :: aux (x+store) xs in aux 0 l これでok。末尾再帰じゃないけど。な。 475 デフォルトの名無しさん [sage] Date:2008/06/23(月) 23:31:25 ID: Be: うおお、皆さんありがとう! いろんなやり方があって勉強になります 476 デフォルトの名無しさん [sage] Date:2008/06/23(月) 23:39:06 ID: Be: let ($) g f x = g (f x) let sigma = (fun s -> rev $ fold_left (fun ys x -> s := x + !s; !s::ys) []) (ref 0) 477 デフォルトの名無しさん [sage] Date:2008/06/23(月) 23:43:15 ID: Be: let (@@) f x = f x let sigma l = (fun s -> rev @@ fold_left (fun ys x -> s := x + !s; !s :: ys) [] l) @@ ref 0 478 デフォルトの名無しさん [sage] Date:2008/06/23(月) 23:47:55 ID: Be: let sigma = tl $ rev $ fold_left (fun ys x -> hd ys+x :: ys) [0]
うは、まるで理解できねえw
Ruby 1.8.6-p230/1.8.7 broke your app? Ruby Enterprise Edition to the rescue! « Phusion Corporate Blog Ruby Enterprise Edition to the rescue We released Ruby Enterprise Edition 1.8.6-20080621 yesterday, which is based on Ruby 1.8.6-p230. This breaks some apps. Today we backported the security patches to Ruby 1.8.6-p111, and made a special Ruby Enterprise Edition release based on that. This release: * doesn’t break your apps since it’s based on p111. Frédéric is happily running it on his production servers right now. * doesn’t suffer from the security vulnerabilities. * includes the usual Ruby Enterprise Edition features, such as reduced memory usage and improved performance. * comes with an easy-to-install source tarball (which includes an installer). * comes with an Ubuntu 8.04 package. For convenience, this packages bundle many common gems so that you don’t have to (re)install them manually. Multiple Rails versions are included. The full gem list is:
バカが征く on Rails 2008年06月23日 そうそう。そばにebanさんもいて。ebanさんで前から 疑問だったのがエディタの選択。日記の ほうには Emacsのこともviのことも書かれてて、ebanさんの エディタの選択は、自分にとって 長年の謎の1つだった。 で、これも尋ねてみると、『メインはviだけど、たまに Emacsも使う』みたいな答えだったと思 う。実際、 ebanさんのノートPCでもツールバーつきのEmacsが立ち 上がってたように思う。
ebanさんがvi (vim)使いだってのはどこかで明らかになってませんでしたっけ? マスタークラスの vi使いは無条件で尊敬に値すると思っているので覚えてるんですが。 あ、大学時代に vi のキーバインドにひーこらいいながら卒業研究をやっていた悪夢がよみがえってきた(笑)
tmtm日記 懇親会 * 去年料理がすぐなくなったって文句が多かったから今年は増やしたのに、大量に余ってる じゃねーか! と角谷さんが吠えてた。
なんと(笑) むずかしいやねえ。 かくたにさんのなかのひとももたいへんだ
phinload Ruby会議2日目 さて、Ruby会議全体を見てあまり誰も言ってなさそうなことを書けといったら、やはりこれが第 一印象というのは、 Rubyでキメたいのなら英語は必須 みたいな? できればマニュアル読めるとかいうのではなくて、会話レベルで。 これは他の言語でもそうだと思うのだが、過去の paper とか見て(Ruby的には温故知新と言って いるようだ)参考にするというプロセスが必然になってきて、それが最近だとインターネットの 影響もあるのだと思うが、読むだけじゃなくてコミュニケーションできる所までないとキツそうな、 そういう印象。
土曜のRuby会議のどれを見ればいいか 金曜のセッションでは「文法が難しい」という話が飛び出した。文法というのはプログラミング 言語の中では最も簡単な話であって、これが難しいということは、何もできないというのと殆ど 同じだと思うのだが、最近のプログラマーのレベルが一体どこに行ってしまったのかというのも 気になっていて、さらに、そういうレベルの人達相手にどんな話をすればプログラム書いてくれ るか、という話も期待したい訳だ。 昨日は質問しようかと思ったが結局歩くのも面倒だし黙っていたのだが、Ruby の既存のコード を見ていると、どうもオブジェクト指向とは違った方向に行っているような気がするのだが、気 のせいだろうか、というのを誰かに質問してみたかったのである。
一度実物を拝んでみたい、
そういう意味では大学のメジャー過程を経営にしてマイナー過程を情報科学にするのはいい選択 かもしれない。
それ、わし(いちおー経営学部卒w)
…Theoさま? 想像してたのと違う~~ッ(笑)
にょろーん。
新刊情報をrssで配信しているところを新しくみつけて、 中身をつらつらと眺めていたところ20日付けの発売予定にこんな本があったのを発見しました。 むう。昨日今日は本屋に行ってないから見落としてたわいw オンライン書店ビーケーワン:コンパイラ入門 構文解析の原理とlex/yacc,C言語による実装 Computer Science Library 9 あれ、でも出版社のデータだと25日発売になってる。
株式会社サイエンス社 株式会社新世社 株式会社数理工学社Computer Science Library 9 「コンパイラ入門」 ~ 構文解析の原理とlex/yacc,C言語による実装 ~ 山下義行(佐賀大学教授) 著 定価:2,310円(本体2,200円+税) 発行:サイエンス社 発行日:2008-06-25 ISBN 978-4-7819-1205-9 / A5判/224頁 <内容詳細> 多くの例題を平明で丁寧に解説し,全体を通じて簡単な二種類のプログラミング言語に対するインタプリタ, コンパイラを実際にC言語で開発する.最新の研究開発状況に即した内容のコラムも随所に盛り込んだ入門書. <目次> 第1章 プログラミング言語 1.1 プログラミング言語の役割 1.2 プログラミング言語の種類と歴史 1.3 プログラミング言語処理系 第1章の章末問題 第2章 コンパイラの全体構成 2.1 コンパイラの処理の概要 2.2 フロントエンド 2.3 バックエンド 2.4 本書で例題とするプログラミング言語 第2章の章末問題 第3章 字句解析 3.1 トークン 3.2 正則表現と有限状態オートマトン 第3章の章末問題 第4章 字句解析器生成系lex 4.1 lex記述 4.2 lex記述のコンパイルと実行 第4章の章末問題 第5章 構文解析の準備 5.1 文脈自由文法 5.2 導出 5.3 構文木と曖昧性 5.4 拡大文法とEoFトークン 5.5 構文解析手法の条件 第5章の章末問題 第6章 下向き構文解析 6.1 解析例 6.2 Director集合 6.3 構文解析アルゴリズム:空規則を含まない場合 6.4 構文解析アルゴリズム:空規則を含む場合 6.5 繰り返し計算 6.6 LL(1)文法 6.7 文法変換 6.8 下向き構文解析プログラムのコンパイルと実行 第6章の章末問題 第7章 上向き構文解析 7.1 解析例 7.2 LR(0)構文解析 7.3 SLR構文解析 7.4 LR(1)構文解析 7.5 LALR(1)構文解析 第7章の章末問題 第8章 構文解析器生成系yacc 8.1 SL1の文法 8.2 yacc記述 8.3 yacc記述のコンパイルと実行 8.4 yacc記述のデバッグ 第8章の章末問題 第9章 抽象構文木の構築 9.1 構文解析以後の処理 9.2 抽象構文木の仕様 9.3 SL0のための下向き構文解析による抽象構文木の構築 9.4 SL1のための上向き構文解析による抽象構文木の構築 第9章の章末問題 第10章 中間木の構築 10.1 記号表の設計 10.2 抽象構文木を走査する関数 10.3 抽象構文木の上の意味エラーチェック 10.4 データ型の埋め込み 第10章の章末問題 第11章 インタプリタとコンパイラ 11.1 インタプリタの作成 11.2 コンパイラの作成 11.3 コード最適化 11.4 本書で触れなかった事柄 第11章の章末問題 あとがき 索引
第8章とか第9章のあたりは役に立つ人もいるんじゃないでしょうか。 yaccの入力のデバッグって結構大変だしw 以前にもこの説明をしていた本はあったと思いますが、 見かけたらチェックしてみやう。
Amazonさんだと7/3発売予定だ。 どーなってるの?w Amazon.co.jp: コンパイラ入門: 山下 義行: 本
んで、なつたんさん向け情報その2。
Pyhton を使って160行でコンパイラを書く。 まあだいぶ機能を絞ったものですけど。
Fun with Languages : Weblog Python: Writing a Compiler and Interpreter in 160 lines of code I started experimenting with Python a few weeks ago. As a learning project I set myself the task of writing a compiler and interpreter for a simple 'while' language. I was very please with the result. Writing Python is like a dream. The work flow goes like this: think of the problem you want to solve, try a solution in the top level eval loop, if doesn't work, try something else, if it works, put it in your module. With the built in lists, tuples, and dictionaries, thought turns into code with a minimum of friction. All I can say is WOW! The language I implemented is very simple: stmtlist := (statement)* statement := 'if' condition stmtlist ['else' stmtlist] 'endif' | 'while' condition stmtlist 'endwhile' | label '=' expression | 'print' expression condition := expression ('=='|'!=') expression expression := term ('+'|'-' term)* term := label|digit Now here is the code. For a lexer I just split the input file into a list of tokens (see parseFile()). I used a tuple to hold the current token (format is: token, yytext, yyval). I used lists of lists to hold the parse tree (see comments in doStatementList()). To evaluate I just do a depth first walk of the parse tree (see execStatementList()). #****************** Lexer ************************ tokenlist = [] currtoken = ("", "", 0) keywords = set(["while", "endwhile", "if", "else", "endif", "print", "=", "==", "!=", "+", "-"]) symboltable = dict() def nextToken(): global currtoken, symboltable if(len(tokenlist) > 0): s = tokenlist.pop(0) if s in keywords: currtoken = (s, "", 0) elif s.isdigit(): currtoken = ("digit", "", int(s)) elif s.isalnum(): symboltable[s] = 0 currtoken = ("label", s, 0) else: print "syntax error: " + s else: currtoken = ("", "", 0) def consume(expected): if currtoken[0] == expected: nextToken() else: print "expected " + expected + " not found" #****************** Parser ************************ def parseFile(filename): inputfile = open(filename, "r") inputstring = inputfile.read() global tokenlist tokenlist = inputstring.split() nextToken() return doStatementList() def doStatementList(): stmts = [] newstmt = [] while currtoken[0] in ["while", "if", "print", "label"]: if currtoken[0] == "while": # ["while", [condition], [statementlist]] consume("while") newstmt = ["while"] newstmt.append(doCondition()) newstmt.append(doStatementList()) consume("endwhile") elif currtoken[0] == "if": # ["if", [condition], [then part], [else part]] consume("if") newstmt = ["if"] newstmt.append(doCondition()) newstmt.append(doStatementList()) if currtoken[0] == "else": consume("else") newstmt.append(doStatementList()) consume("endif") elif currtoken[0] == "print": # ["print", [expression]] consume("print") newstmt = ["print"] newstmt.append(doExpression()) elif currtoken[0] == "label": # ["=", [expression], [expression]] label = [currtoken[1]] nextToken() consume("=") newstmt = ["="] newstmt.append(label) newstmt.append(doExpression()) else: print "invalid statement: " + currtoken[0] stmts.append(newstmt) return stmts def doCondition(): exp = doExpression() # ["==|!=", [left side], [right side]] if currtoken[0] in ["==", "!="]: retval = [currtoken[0]] retval.append(exp) nextToken() retval.append(doExpression()) else: print "expected == or != not found" return retval def doExpression(): term = doTerm() # carry the term in case there's no +|- exp = term # ["+|-", [left side], [right side]] while currtoken[0] in ["+", "-"]: exp = [currtoken[0]] nextToken() exp.append(term) exp.append(doExpression()) return exp def doTerm(): if currtoken[0] == "label": retval = currtoken[1] nextToken() elif currtoken[0] == "digit": retval = currtoken[2] nextToken() return [retval] #****************** Interpreter ************************ stack = [] def execStatementList(pgm): for stmt in pgm: execStatement(stmt) def execStatement(stmt): if stmt[0] == "while": execCondition(stmt[1]) while stack.pop(): execStatementList(stmt[2]) execCondition(stmt[1]) elif stmt[0] == "if": execCondition(stmt[1]) if stack.pop(): execStatementList(stmt[2]) elif len(stmt) == 4: execStatementList(stmt[3]) elif stmt[0] == "=": execExpression(stmt[2]) symboltable[stmt[1][0]] = stack.pop() elif stmt[0] == "print": execExpression(stmt[1]) print "output:" + str(stack.pop()) else: print "invalid statement" def execCondition(cond): execExpression(cond[1]) execExpression(cond[2]) if cond[0] == "==": stack.append(stack.pop() == stack.pop()) elif cond[0] == "!=": stack.append(stack.pop() != stack.pop()) def execExpression(exp): if len(exp) == 3: execExpression(exp[1]) execExpression(exp[2]) if exp[0] == "+": stack.append(stack.pop() + stack.pop()) else: stack.append(stack.pop() - stack.pop()) else: if type(exp[0]) == int: stack.append(exp[0]) else: stack.append(symboltable[exp[0]])
redditのコメントから幾つか拾ってみる。
programming: Zed Shaw's Rundown of The Big Ruby Vulnerabilities So, Zed dumps just the diffs, singles out every one that involves a length or a terminator, and then says "look I think this could be a buffer overflow!". Some of his diffs are read-only operations. Another deals with 2-4 character strings going into a MAXPATHLEN buffer. Or, how about this gem: "Seems like there’s some changes here to determine correct stack direction on the native CPU. Why, that could be a stack smash exploit in the making!" Yeah, Zed, because they're writing an exploit for the overflow in the interpreter. The irony here is that the fix commits are labelled with the CVE number. They aren't hard to find, Zed."Look at me, I want to be important!"So, because I don't have a big mouth I am not allowed to post my opinion? Come on. Zed is an awesome guy, but he sometimes is a publicity whore.Looks like his contributing days are long gone. He is in the "nelson mode" now. Standing on the sidelines and yelling "ha ha" every time anybody trips. Shame really.Everybody knows this is not true because Ruby is made using the black arts. Essentially all scripting languages are the same spell, you just sub in a pearl, snake, or gem stone for one ingredient. He needs to chant the spell magicdiff from Oriellys The Black Art of Programing to see the real difference.
ううむ。なんともいろいろな反応。
Win32API質問箱 Build67 [bbs2chreader] 447 デフォルトの名無しさん [] Date:2008/06/22(日) 14:48:26 ID: Be: (3+2.5)/4-3*2 みたいな文章を計算するAPI教えてください 448 デフォルトの名無しさん [sage] Date:2008/06/22(日) 14:51:44 ID: Be: 電卓相手にコピペでもしてろ 449 デフォルトの名無しさん [sage] Date:2008/06/22(日) 14:55:51 ID: Be: んなもんない。以上。 450 デフォルトの名無しさん [sage] Date:2008/06/22(日) 14:59:30 ID: Be: 448が以外ないい答えかも 451 デフォルトの名無しさん [sage] Date:2008/06/22(日) 15:06:11 ID: Be: >>447 宿題スレへどうそ。 なお、この手の問題は頻出です。 452 デフォルトの名無しさん [sage] Date:2008/06/22(日) 16:07:41 ID: Be: 宿題スレへ行ってもそんなAPIはないと言われないだろうか 453 デフォルトの名無しさん [sage] Date:2008/06/22(日) 16:39:06 ID: Be: bison/flex 使うと意外と簡単に作れるぜ 454 デフォルトの名無しさん [sage] Date:2008/06/22(日) 16:40:27 ID: Be: もうboost::spiritでよくね? 455 デフォルトの名無しさん [sage] Date:2008/06/22(日) 16:56:37 ID: Be: またboost厨か 456 デフォルトの名無しさん [sage] Date:2008/06/22(日) 17:00:08 ID: Be: boost::spiritはコンパイルで死ねる
calc.exe にキーストロークを送って…とか(笑)
C言語を完全に駆逐するためには 434 デフォルトの名無しさん [sage] Date:2008/06/18(水) 15:55:05 ID: Be: C 言語のように構造体メンバのアクセス制限のない言語を使って複数人で開発するのは難しく ないですか? 以下の開発方法しか思いつかないのですが。 - 構造体オブジェクトへのアクセスは必ずその構造体用の関数を経由するように周知徹底する - 構造体定義を利用者から隠してメンバへのアクセスを不可能し、ヒープからオブジェクトを 生成する関数を用意する - 構造体の文書を整備し、定義に変更があったらその構造体を使っている場所を点検し直す インライン関数があれば最初の方法が現実的かな。 435 デフォルトの名無しさん [sage] Date:2008/06/18(水) 16:40:50 ID: Be: - 一度定めた構造体の定義に対して互換性がなくなるような変更をしない 436 デフォルトの名無しさん [sage] Date:2008/06/18(水) 18:13:08 ID: Be: >>435 それはpointみたいに非常に単純なものでない限りは 現実問題としては無理なので、 opaqueな型にしてしかもメンバにmagic number仕込むとかやったほうがいいな 437 デフォルトの名無しさん [sage] Date:2008/06/18(水) 19:18:44 ID: Be: 何か無理やりOOをやりたいのか?C++じゃないんだが。 438 デフォルトの名無しさん [sage] Date:2008/06/18(水) 20:03:38 ID: Be: >>434 拡張子をだなcppに変えて(ry 439 デフォルトの名無しさん [sage] Date:2008/06/18(水) 20:44:55 ID: Be: >>437 OO まではいかないけど抽象データ型を使うとプログラムの変更に強くなるし楽だと思う。 C の標準ライブラリでは FILE ぐらいしか思いつかないけど、Windows ではよくハンドルを 使っているようです。C の場合整数のハンドルより構造体のポインタを使ったほうが型安全 でいいかもしれませんね。 コンテナのようにある程度複雑の構造だと抽象データ型じゃないとつらいんじゃないかな。 440 デフォルトの名無しさん [sage] Date:2008/06/18(水) 23:57:02 ID: Be: >>434 むしろOO的には、一番目と二番目を徹底すべきじゃないのか? C++であっても。 441 デフォルトの名無しさん [sage] Date:2008/06/19(木) 00:38:02 ID: Be: >>439 いや、構造体をクラスに見立ててOOしたいんだろ? じゃなきゃ、>>434の1行目のようなアクセス制限が云々なんて前提が出てくるとは思えない。 Cのパラダイムを無視して、突然こんな前提で設計しろと言われたらオレは難色示すね。 というわけでお前の考え方では、複数人での開発は難しくなるだろう。 これまで培われたコンセンサスに乗っ取った構造体の使い方をすればいい。 無理してオレ流OOルールを持ち出せば、上で叩かれているC++のローカルルールと同じ問題になると思うがね。 お前はCのパラダイムを無理やりOOに当てはめて解釈しようとしてるんじゃないのか? ああ、それと今オレがCで書いているシステムは、ヒープ割り当てができないようになってて、 スタックは1Kしか使えないんだがどうするんだい? オレ流OOルールをもうひとつ追加するのか?RAMも16Kに減らされそうなんだが。 442 デフォルトの名無しさん [sage] Date:2008/06/19(木) 00:45:25 ID: Be: RAMが16Kbyteもあるなんて贅沢だw
Prologでまったり Part3 [bbs2chreader] 251 デフォルトの名無しさん [sage] Date:2008/06/16(月) 05:36:33 ID: Be: Ubuntu7.1 で Progol4_4 をmakeするとエラーに なるのですが、なにかご存知の方、 コメントをください。 # sudo sh expand.sh ・・・解凍して展開・・・ gcc -O2 -c -o command.o command.c command.c: In function 'c_interp': command.c:55: error: 代入として無効な左辺値です とメッセージがでます。 252 デフォルトの名無しさん [sage] Date:2008/06/16(月) 06:53:04 ID: Be: command.c:55: error: 代入として無効な左辺値だってことがなぜ伝わらないのか 253 デフォルトの名無しさん [sage] Date:2008/06/16(月) 07:07:11 ID: Be: >>252 それは、判るのですが、どうすればいいのでしょうか? 254 デフォルトの名無しさん [sage] Date:2008/06/16(月) 14:24:24 ID: Be: 左辺値をキャストしちゃダメなんだそうで。 http://c-faq.com/ptrs/castincr.html http://www.kouno.jp/home/c_faq/c4.html#5 > キャスト は変換演算子であって、それは右辺値を生みだすと定義されている。 > 右辺値であるとするなら、代入することも++で足し算することもでき ないことになる > (pccから派生したコンパイラやgccの拡張機能が上の ような式を受け付けることは例外である)。 書き直す(左辺値用のマクロを用意する?)のが正しいと思うけれど、 gccのオプションをいじればどうにかなるのかも、なんて思ったりして。 255 デフォルトの名無しさん [sage] Date:2008/06/16(月) 14:28:15 ID: Be: いや、なんか適当にポインタを取ったりすればいいのかもしれない。適当。 256 デフォルトの名無しさん [sage] Date:2008/06/16(月) 16:01:28 ID: Be: しったかぶってただけでしたw 257 デフォルトの名無しさん [sage] Date:2008/06/16(月) 17:02:57 ID: Be: >>251 http://gcc.gnu.org/ml/gcc-help/2007-05/msg00082.html この人の場合、どうやら古いgccでコンパイルしなおしたらしい。 pagaddedって何かわかんないけど 258 デフォルトの名無しさん [sage] Date:2008/06/16(月) 17:45:24 ID: Be: そんなことも知らないと見下されてるわけか。バカにされたもんだな。 そういうことを聞いてるんじゃないってことがなぜ伝わらないのか。 情報があるなら教えて欲しい、それだけだ。 259 デフォルトの名無しさん [sage] Date:2008/06/16(月) 17:54:17 ID: Be: > By the way, I'm running the latest version of gcc on a Sunblade 100 workstation. だからpkgadd(ed)、かな 260 デフォルトの名無しさん [sage] Date:2008/06/16(月) 20:42:27 ID: Be: command.c > CTYPE(cclause)=pdot0; progol.h > typedef int BOOL, INT; > typedef long int LONG; > typedef double DOUBLE; > typedef char *STRING; > typedef char *POINTER; : > #define I_GET(i) ((i)->obj) : > #define CTYPE(c) ((LONG)I_GET(F_ELEM(2l,(c)))) : > struct item { : > POINTER obj; 世の中間違ってる 261 デフォルトの名無しさん [sage] Date:2008/06/16(月) 20:51:16 ID: Be: > #define CTYPE(c) ((LONG)I_GET(F_ELEM(2l,(c)))) #define CTYPE(c) (*(LONG *)&I_GET(F_ELEM(2l,(c)))) こんなんできたっけ 269 251 [sage] Date:2008/06/17(火) 02:59:52 ID: Be: 皆さんの示唆によりまして、 めでたく、Progolの起動まで漕ぎ着けました。 ひとまず、ありがとうございます。 ひとまずというのは、 >>261 はその通り直したのですが、同様にエラーのでた (LONG) を「なんか適当にポインタを取ったり」という感じで コメントアウトしてしまったらうまく行った、ということです。 それでは、問題があるかもしれないから、今日 (LONG)を生かす方法を試みます。 271 デフォルトの名無しさん [sage] Date:2008/06/17(火) 04:37:35 ID: Be: >>261です http://piza.2ch.net/tech/kako/968/968727266.html >1 名前: 厨房エログラマ 投稿日: 2000/09/12(火) 11:54 > unsigned long a = 0xcccccccc; > (unsigned char)a = 0xff; > このようなコードをみました。 > VC++で試したところ、拡張子CPPではエラーになりましたが、 > 拡張子Cでは問題なく通り、aの値は 0xccccccff になりました。 > この代入はC言語の規則上では正しいのでしょうか? >10 名前: >8 投稿日: 2000/09/13(水) 08:15 > ANSIでは(unsigned char)aは左辺値じゃないから代入文の左辺に > は置けない。これはANSIでは「処理系依存」ではない。 > > この記述ができるコンパイラはANSIに従っていない。このため > VC6も-ZaでこのMS拡張仕様を無効にする手段を用意している。 > > gccではコンパイルできるが結果は0xccccccffでなく > 0x000000ffになる。同様に-ansi -pedanticをつけて厳格に > ANSIに準拠させるとエラーとなる。 > > 言語仕様を(暗記せよとはいわないが)調べるぐらいしたら sizeof(LONG) == sizeof(POINTER) という仮定がされている、という仮定をしてしまった気がするとです
この問題も定期的に出てくるような。 まあ新たに書かれているコードで代入の左辺をキャストしているのは ほぼないとは思うけど(皆無といえないところがちょっとアレ)。
sumimさんは当然チェック済みだろうなあ。
昨日のZedのblogにも登場した ackについて。
変数宣言で型推論を利用するかしないか。
なに来週のマクロスF、3:30amからの放送って(TBS) ○| ̄|_
NMIが来ました○| ̄|_
ZSFA -- The Big Ruby Vulnerabilities Wanna know what all the Ruby vulnerabilities are? Or at least have a fun look at how to search through code for clues? It's a blast. Rubyの脆弱性のすべてを知りたくはないか? あるいはどうやってコードから手がかりを探し出すのか見てみたいとは思わないか? それは blast だぜ I believe in full disclosure because I think people should know what they're getting. You see my friends, when you see a vulnerability announced and you don't know what causes it, you are actually the last person to hear about it. Before you get this defect hidden in a massive batch of patches, the Ruby team has already told people way more important than you. People running Big Important IT™ like Twitter. Just like everything else in this world, the people with money get to know what's going on, and you and me just get to take it up the ass and wait to be handed scraps of information. オレは、人は自分が入手したものがなんなのかを知っておくべきだと考えているンで すべてを明らかにする。 あー朋友、キミがある脆弱性についてのアナウンスを目にしてそれがどういったことなのか わからなかったときには、キミはそれを聞いた最後の人間だということだ。 山ほどのパッチの中に隠れている欠陥をキミが理解するよりも前に、Ruby teamは キミよりも重要な人たちに対して説明をすでにしているんだ。 Twitterのような、大規模で重要なものを使っている人たちにね。 この世界におけるお約束のように、金を持った連中というのは何がどうなっているかを知る。 一方でキミやオレなんかは 手の加えられた情報のスクラップをお待ち申し上げるというわけだ。 Well, my Ruby friends, I am on your side. That's why I'm going to show you how to educate yourself about the quality of Ruby. Yes, you too can look deep into Satan's anus and get a full glimpse of Ruby's true glory. うん、わが良き友よ、オレはキミの味方だ。 そしてそれこそが、オレがキミにキミ自身をRubyの質というものに関して どのように教育するのかということを教えようとしている理由なんだ。 サタンの×××の奥の奥をのぞき見て、真のRubyの栄光というものに気がつくことだろう。 I will be using the following tools to take you on a tour of the many buffer overflows and path attacks discovered in Ruby and hidden from you. To follow along, you'll need these wonderful tools: 以下にあげるツールを使って、多くのバッファオーバーフローとRubyが防御しておらず キミから見えないようにされているパスアタックをお目に掛けよう。 自分でも同じことをするつもりならイカしたこんなツールが必要だ。 * Vim’s gvimdiff * ack * diff I know this sounds like the tools of an Evil Hacker™, but trust me, despite today’s FISA Bill Vote you will not go to jail for using these tools to find vulnerabilities. これらのツールが邪悪なハッカーの持ち物のように思われるかもしれない。 でもオレを信じてほしい。今現在の FISA Bill Voteにも関わらず、こういったツールを脆弱なところを発見するために 使うことでム所送りにはならない。 Getting The Source ソースを入手する The vulnerability mentions Ruby patch-level 229 is vulnerable, but you can't find Ruby 1.8.6 p229 at the Ruby FTP You’ll have to get Ruby 1.8.6 p114 and compare it with Ruby 1.8.6 p230 but that won't be hard because I've done some detective work! 脆弱性について言及している Ruby patch-level 229 は脆弱ではあるが、 キミはRuby FTP サイトで Ruby 1.8.6 p229 を見つけることができない。 だから、Ruby 1.8.6 p114 を入手してそれを Ruby 1.8.6 p230と比較する必要が あるんだが、そんなに難しいことじゃあない。オレが detective workをちょっとばかし もうやってるからな! You see my friends, Ruby 1.8.7 came out and had a ton of “enhancements” to it. Things like everything returning an Enumerator. It was glorious and made JRuby, Rubinius, and IronRuby so happy. MagLev wasn't phased I hear. Anyway, those changes were also in Ruby 1.9. Now, I did the hard work of analyzing the diffs between 1.8.7 and 1.9 to figure out what is common based on the announced 1.8.7 change sets, and then used that information to analyze the 1.8.6 versions. This helped me narrow it down to a set of changes by user shyouhei” in the month of 2008-06. 友よ。Ruby 1.8.7 がリリースされていて、それにはたくさんの“拡張”(enhancements)が 施されている。たとえばすべてが Enumerator を返すようなヤツだ。 それはスバラしいことで、JRuby, Rubinius, IronRuby もハッピーだ。 MagLevもそうするとはオレは聞いてないんだけど。 いずれにしてもだ。こういった変更は Ruby 1.9でも行われている。 さて、オレはここで1.8.7でアナウンスされていた変更点の common base を調べるために 1.8.7 と 1.9 の間の変更を調査するという hard work をやった。そうしてから 1.8.6を調査するためにその情報を使ったんだ。 First thing I did was crack open the two Ruby tar.bz2 archives and run this nice diff command in a big terminal window: 最初にオレがやったことは、二つの Ruby tar.bz2 を開いて、次のようなナイスな diff コマンドをでっかいターミナルウィンドウで実行することだった diff -x ".txt" -x "\." -x "[A-Z]" -x ".rb" \ --suppress-common-lines -ry ruby-1.8.6-p114 ruby-1.8.6-p230 | less This command gives you a nice side-by-side compare between those two versions of Ruby. Now doing this you can right away see that array.c had some trouble: このコマンドで、Rubyの二つのバージョンの間の比較をサイドバイサイド形式で得ることができる。 んで、これをやってみると array.c にちょっとした問題があるのを発見できるだろう。 22a23 > #define ARY_MAX_SIZE (LONG_MAX / sizeof(VALUE)) Uh oh! I smell a buffer overflow! I feel like a nature show host. “And now, the elusive Bufferius Overflowius Maximinus will show its mating stripes, hopefully attracting a fellow Shellcodiant Incomprehensivisti for a mating session and produce wonderful little remote executions.” Tasty. うほっ、バッファオーバーフローのにおいがプンプンするぜぇー #なんかローマ人の人名っぽくして何か書いているようだが良くわからん Now, we know this is all being updated by shyouhei this month, so if we use ack we can get a good guide to the world of Ruby Security Monkey Patch Profiteering. Watch and learn: $ ack -o "Date: 2008-06-[0-9][0-9]" ruby-1.8.6-p230 ruby-1.8.6-p230/array.c 6:Date: 2008-06-20 ruby-1.8.6-p230/bignum.c 6:Date: 2008-06-15 ruby-1.8.6-p230/class.c 6:Date: 2008-06-15 ruby-1.8.6-p230/defines.h 6:Date: 2008-06-15 ruby-1.8.6-p230/dln.c 6:Date: 2008-06-15 ruby-1.8.6-p230/eval.c 6:Date: 2008-06-16 ruby-1.8.6-p230/ext/iconv/iconv.c 7:Date: 2008-06-15 ruby-1.8.6-p230/ext/socket/socket.c 6:Date: 2008-06-08 ruby-1.8.6-p230/ext/syck/rubyext.c 6:Date: 2008-06-15 ruby-1.8.6-p230/ext/win32ole/win32ole.c 15:Date: 2008-06-08 ruby-1.8.6-p230/file.c 6:Date: 2008-06-18 ruby-1.8.6-p230/gc.c 6:Date: 2008-06-15 ruby-1.8.6-p230/intern.h 6:Date: 2008-06-20 ruby-1.8.6-p230/io.c 6:Date: 2008-06-13 ruby-1.8.6-p230/lib/irb.rb 5:Date: 2008-06-13 ruby-1.8.6-p230/marshal.c 6:Date: 2008-06-18 ruby-1.8.6-p230/misc/ruby-mode.el 5:Date: 2008-06-15 ruby-1.8.6-p230/numeric.c 6:Date: 2008-06-15 ruby-1.8.6-p230/object.c 6:Date: 2008-06-18 ruby-1.8.6-p230/process.c 6:Date: 2008-06-15 ruby-1.8.6-p230/signal.c 6:Date: 2008-06-15 ruby-1.8.6-p230/sprintf.c 6:Date: 2008-06-20 ruby-1.8.6-p230/string.c 6:Date: 2008-06-20 ruby-1.8.6-p230/struct.c 6:Date: 2008-06-15 ruby-1.8.6-p230/time.c 6:Date: 2008-06-15 ruby-1.8.6-p230/util.c 6:Date: 2008-06-15 Ah, sneaky guy. Now, did shyouhei make all of these changes? $ ack "shyouhei" (ack -l "Date: 2008-06-[0-9][0-9]" ruby-1.8.6-p230 ) | wc -l 25 $ ack -o "Date: 2008-06-[0-9][0-9]" ruby-1.8.6-p230 | wc -l 26 Pretty close! This is a good way to narrow down what we have to search through and now we can turn to good old gvimdiff to check this out. #いや、そりゃ卜部さんがメンテナだからだろ?(^^; NOTE: Another thing to notice is that many of these files haven't been changed in close to a year or more. If you suddenly see one user change a bunch of files in the space of a few days that haven't changed in a long time, well those are probably the big changes you need to look for. 注意:もうひとつの注意点。これらのファイルは一年以上にわたって何の変更もされていなかった ファイルだ。もしキミが、長いこと変更が加えてこられなかった複数のファイルに対して短期間の 間にあるユーザーが複数の変更をしたのを発見したら、それはたぶん、 キミがよおく注意してみておく必要がある大きな変更だ。 Enter Diff Goodies If you're a vim user then gvimdiff should be very fun. If you're not a vim user then use whatever visual diff you have to check out these spots in the source I'll show you. We'll just go through each file, and I'll point out the fun lines you should look at. They could be defects, they could just be cruft or merged in fixes to hide things. But, the experience will be illuminating. キミがvimを使っているのなら、gvimdiff がすげー役に立ってくれるだろう。 不幸にしてキミが vimユーザーでないのなら、ソースコードの中で注目すべきところを 強調してくれるような visual な diff を使ってほしい。 オレたちはそれぞれのファイルを見ていって、キミが見るべき興味深い行をオレが 指摘する。それは欠陥かもしれないし、単なる cruft or merged in fixes to hide things かもしれない。 I use fish for my shell, so this little bit of code will give you a nice walk through the code: オレはシェルに fish を使っている。だからコードをざっとなめて行くのにはこのようにすればいい。 for f in (ack -l "Date: 2008-06-[0-9][0-9]" ruby-1.8.6-p230 | sed -e s/ruby-1.8.6-p230//) gvimdiff -f ruby-1.8.6-p114$f ruby-1.8.6-p230$f end array.c array.c の場合 First off, we have these awesome lines of code in the p114 version: 123: if (len > 0 && len * sizeof(VALUE) <= len) { ... 296: if (len > 0 && len * (long)sizeof(VALUE) <= len) { ... 370: if (new_capa * (long)sizeof(VALUE) <= new_capa) { ... 2381: if (LONG_MAX/len < RARRAY(ary)->len) { ... Which are replaced with in the p230 version: p230バージョンでは次のように置き換えられている 124: if (len > ARY_MAX_SIZE) { ... 297: if (len > ARY_MAX_SIZE) { ... 373: if (new_capa >= ARY_MAX_SIZE - idx) { 374: new_capa = (ARY_MAX_SIZE - idx) / 2; ... 2388: if (ARY_MAX_SIZE/len < RARRAY(ary)->len) { ... It would seem that you can give the Array type a bad length that can overflow the backing buffer for it. Array has always been a giant piece of shit, being the cause of the Array shift bug that caused memory leaks and was actually fixed by Eric Mahurin one year earlier. Oh well, they have a VM now. これはbacking buffer をオーバーフローさせる可能性がある長さが不正なArrayを渡すことが できるように思える。Array は常に giant piee of shit を持っているが、それは メモリーリークを引き起こしていたが一年ほど前に Eric Mahurin が実際に修正した Arrayのshiftバグの元だ。 There also seems to be more complicated fixes withing array.c related to recursive equality tests, but I’ll assume that's not a security defect and just noise. It sure look important though (from the p230): array.c にはほかにも再帰的に等価性を検査するための複雑な修正が加えられているようだ。 しかし、オレはそれがセキュリティ上の欠陥ではなく単なるノイズであると仮定する。 static VALUE rb_ary_eql(ary1, ary2) VALUE ary1, ary2; { if (ary1 == ary2) return Qtrue; if (TYPE(ary2) != T_ARRAY) return Qfalse; if (RARRAY(ary1)->len != RARRAY(ary2)->len) return Qfalse; if (rb_inspecting_p(ary1)) return Qfalse; return rb_protect_inspect(recursive_eql, ary1, ary2); } Who the hell still uses K&R style anyway? Lame. #いや、そうは云っても1.8まではK&Rスタイルを使うということになってるわけで bignum.c I’m gonna speed this up since there's a whole lot of files, and I'll probably just stop after I get tired of exposing all the potential defects. Bignum seems to have a few of these size and buffer related defects as well. There seems to be a slight change in the check for BIGZEROP (bottom half is p230): BIGZEROPに対する検査において修正があるようだ *************** *** 38,40 **** ! #define BIGZEROP(x) (RBIGNUM(x)->len == 0 || (RBIGNUM(x)->len == 1 && BDIGITS(x)[0] == 0)) === 38,54 ===- ! #define BIGZEROP(x) (RBIGNUM(x)->len == 0 || \ ! (BDIGITS(x)[0] == 0 && \ ! (RBIGNUM(x)->len == 1 || bigzero_p(x)))) ! ! static int bigzero_p(VALUE); ! static int ! bigzero_p(x) ! VALUE x; ! { ! long i; ! for (i = 0; i < RBIGNUM(x)->len; ++i) { ! if (BDIGITS(x)[i]) return 0; ! } ! return 1; ! } Well, now that's a lot more complex for sure. I guess it was important to know that every single digit in the Bignum is actually 0 rather than just the first one. But, not quite sure that's a security defect. Let's look at the next one though (p230 on the bottom): ふむ。ずいぶんと複雑になってるな。実際には0であるBignumに対して最初の一桁だけを 検査するのではなくてすべての桁を調べているのが重要な気がする。 とはいえそれがセキュリティ上の欠陥かどうかは自信がない。 次を見るとしよう *************** *** 448,450 **** while (*++str == '0'); ! if (!*str) --str; } === 462,464 ===- while (*++str == '0'); ! if (!(c = *str) || ISSPACE(c)) --str; ! } Getting closer, looks like bignum didn't compensate for a space in the string it was reading, which leads to this nice change: bignum は読んできた文字列の空間の調整をしてなかったようだな。 んでこれがこんなナイスな変更につながって行くわけか *** 654,655 **** === 668,672 ===- } + if (i >= LONG_MAX/SIZEOF_BDIGITS/CHAR_BIT) { + rb_raise(rb_eRangeError, "bignum too big to convert into `string'"); + } j = SIZEOF_BDIGITS*CHAR_BIT*i; Well, as many people have said, I'm a total scrub and can't code for shit, so I don't really know what's going on here. I'll let you figure out why they'd suddenly care about a Bignum being too big for a string. うん。多くの人間がそう思うように、オレも total scrub で can't code for shit だから、 オレにはなぜこんなことをする様になったのかの本当の理由はわからない。 オレがキミに伝えるのは、なぜか彼らが突如として Bignum がでかすぎる文字列か どうかを気に掛けるようになったってことだ。 dln.c This is a fun one, since the defects were reported by an Apple employee, so we see some changes that could be specific to the Mac OSX platform. In this file there's a chunk of code that's just moved around related to the Mac's weird ass filesystem: *************** *** 1774,1795 **** - #ifndef __MACOS__ - if (stat(fbuf, &st) == 0) { - if (exe_flag == 0) return fbuf; - /* looking for executable */ - if (!S_ISDIR(st.st_mode) && eaccess(fbuf, X_OK) == 0) - return fbuf; - } - #else - if (mac_fullpath = _macruby_exist_file_in_libdir_as_posix_name(fbuf)) { - if (exe_flag == 0) return mac_fullpath; - /* looking for executable */ - if (stat(mac_fullpath, &st) == 0) { - if (!S_ISDIR(st.st_mode) && eaccess(mac_fullpath, X_OK) == 0) - return mac_fullpath; - } - } - #endif But, the real kick is a change to the list of allowed extensions during the operation of the dln_find_1 function: #if defined(DOSISH) if (exe_flag) { ! static const char *extension[] = { #if defined(MSDOS) === 1774,1778 ===- #if defined(DOSISH) if (exe_flag) { ! static const char extension[][5] = { #if defined(MSDOS) Oh, I smell another buffer overflow. If you look at that extension array you’ll see that it contains a set of extensions, the change is to set the max size of these so that they are fixed to a max of 5. That’s a size change which is used in: *** 1810,1812 **** ! for (j = 0; extension[j]; j++) { if (fspace < strlen(extension[j])) { === 1792,1794 ===- ! for (j = 0; j < sizeof(extension) / sizeof(extension[0]); j++) { if (fspace < strlen(extension[j])) { *************** *** 1827,1828 **** === 1809,1811 ===- } + goto next; } Nice, so the change was to stop traversing this list of extensions on Windows until you hit a NULL and instead rely on a fixed sized array, and then a goto to a “next:” label that seemed to not be included in the p114 version. I’m betting that goto is pretty significant, and that the size change in the array is just a precaution. eval.c and class.c At first when I was looking at the changes to these two files they just seemed like fixes to Ruby's meta programming “magic” (Jazz hands! You gotta put the jazz hands out when you say “meta programming” in Ruby). Then I got to taking a closer look, and I saw this addition to the eval.c file: *** 1295,1298 **** } ! if (tail) { warn_print2(tail, elen-len-1); } === 1301,1305 ===- } ! if (tail && elen>len+1) { warn_print2(tail, elen-len-1); + if (einfo[elen-1] != '\n') warn_print2("\n", 1); } Another length ending change by adding a test to check the elen as well as the tail, which means these files could have a serious vulnerability about how the symbol table in Ruby is used to attach new nodes to Ruby classes. That's just my first look, but someone who knows Ruby's internals better should check this out. This could mean some really big hacks and possibly injecting Ruby into the interpreter remotely if it's one of the defects. もうひとつの長さの終端をtail と同様に elen に対する検査を追加することで変更している。 Ruby のクラスに新しいノードを attach するために使われている(Ruby中の)シンボルテーブルの 扱い方に関して深刻な脆弱性を、これらのファイルが抱えているかもしれないということだ。 これはオレの第一印象だけど、Rubyの内部についてもっとよく知っている誰かが きちんとこれをチェックしておくべきだろう。これが意味しているのは、 何か欠陥があったときに本当の大掛かりなハックがあってインタープリタを外から操作するために コードを送るこめるかもしれないという可能性があるということだ。 iconv.c There's just a tiny little change starting on line 426 of p230's iconv.c file to ensure that the length isn't greater than the slen. This could mean another buffer overflow from reading files via iconv. win32ole.c In several of the other files there's changes of this kind too: *** 2105,2107 **** /* retry to call args by value */ ! if(op.dp.cArgs > cNamedArgs) { for(i = cNamedArgs; i < op.dp.cArgs; i++) { === 2105,2107 ===- /* retry to call args by value */ ! if(op.dp.cArgs >= cNamedArgs) { Where, in addition to fixing up range checks, there will be a change from a < or > to be a <= or >= test instead. This is also a common fix for buffer overflow defects. But I doubt some dude from Apple told them to fix this windows OLE file. Hell, I don't even think Microsoft would look at OLE these days. file.c Alright, there’s a lot of changes in this file related to directory and file names on DOSISH platforms, and NTFS. A lot of these changes replace the use of strrchr with alternative code. Yes, ruby uses strrchr, probably one of the most evil fucking cunt functions in the history of the str… family. When you code, you can use this simple regex to look for bad things: egrep '[^_.>a-zA-Z0-9](str(n?cpy|n?cat|xfrm|n?dup|str|pbrk|tok|_)|stpn?cpy|r?index[^.]|a?sn?printf|byte_)' *.c Try it out on the Ruby source, it’ll find tons of potential places where strings might be used wrong. In file.c it looks like the changes are all about getting the paths right on NTFS or Windows specifically, and then in general getting the path analysis correct. I’m tired but this basically looks like a series of path traversal and potentially buffer overflows from paths. Since file.c is used all over, this means many web servers could be vulnerable to path traversal or even just buffer overflows from simple web requests. gc.c Ah, my favorite file in all of Ruby. The GC. We're old friends. I remember fondly trolling through its horrid festering pile of shit looking for a memory leak in Mongrel with no success. That’s because the leak was actually in array and not gc, since you know I tend to find my memory leaks in the array operations of a garbage collected language. Now, most of this doesn’t seem like a security vulnerability, but one very curious change caught my eye about the stack: *** 440,447 **** # endif ! static VALUE * ! stack_end_address(void) { ! return (VALUE *)__builtin_frame_address(0); } ! # define SET_STACK_END VALUE *stack_end = stack_end_address() # else === 443,451 ===- # endif ! static void ! stack_end_address(VALUE **stack_end_p) { ! VALUE stack_end; ! *stack_end_p = &stack_end; } ! # define SET_STACK_END VALUE *stack_end; stack_end_address(&stack_end) Seems like there’s some changes here to determine correct stack direction on the native CPU. Why, that could be a stack smash exploit in the making! Oh nice, those are super hot to work with since, when the function returns, you can run your code. Not sure how you’d exploit it in the GC though. io.c My runner up for greatest Ruby source file ever. In this file none of the changes seem all that big of a deal, but in rb_open_file there’s a bit of string messing with the path. Could potentially be a place to exploit files that get opened. Combined with all the changes in file.c for path analysis this is a good guess. All of the changes are along these lines: *************** *** 4404,4406 **** filename = rb_ary_shift(rb_argv); ! fn = StringValuePtr(filename); if (strlen(fn) == 1 && fn[0] == '-') { === 4407,4409 ===- filename = rb_ary_shift(rb_argv); ! fn = StringValueCStr(filename); if (strlen(fn) == 1 && fn[0] == '-') { *************** *** 5065,5067 **** rb_str_modify(v); ! arg[i] = (unsigned long)RSTRING(v)->ptr; } === 5068,5070 ===- rb_str_modify(v); ! arg[i] = (unsigned long)StringValueCStr(v); } Where access to pointers is changed to a CStr. This could just be fixings for 1.8.7 to get rid of the use of RBSTRING everywhere. But, hidden in here could be a defect related to the changes in file.c. process.c This file has a few changes related to the arguments passed to forked processes, another classic vector of attack. The changes look more like a clean-up than a defect fix, so I’ll assume they aren’t for any security fixes. Do a search for “ proc_exec_args” to see for yourself. Read The Code To Your Software キミの使うソフトウェアのコードを読め Hopefully going through all this Ruby code to see what's changed in these security fixes will get you motivated to start reading your software's code. I try to glance through at least the biggest files to see what the quality is in general. Generally, the way the Ruby and Rails teams have handled security isn't so hot. They do this hiding fixes thing as if it stops people from figuring out what happened, but it took me a total of 20 minutes to find a lot of the defects already. This practice doesn't work, and its only purpose is really to hide shame. 一般論として、Ruby と Rails のそれぞれの開発チームはセキュリティの取り扱いについて 熱心であるとはいえない。彼らは修正点を、そうすれば詮索する人がいなくなるだろうと 見ないしているかのように隠しているけれども、オレはせいぜいが20分ほどで数多くの 欠陥を探し出して見せた。この practice は work していないし、そうすることの目的は 単に恥を隠すだけのことだ。 But, I say own it. When I find defects, I own them. I fucked up. There's no shame in that. Fucking step up, be a man about it, admit you're an idiot, and fix the shit. Hiding it and convincing everyone that everything is just fine will only work for so long. 欠陥を隠して、すべて大丈夫なんだと皆を説得することは only work for so long なことだ。 Where's The Remote Execution? Looking at these in total, I see them mostly as just general buffer overflow defects, signed integer problems, and path traversal problems. However, the file that gives me the most concern is the changes to eval.c and class.c. These seem to be protections against code being added in weird ways to the Ruby classes. If that's true, the real defect could be that you can easily just hand a simple string to some Rails application and it'll run your Ruby. これらの修正をまとめてみてみると、修正のほとんどが一般的なバッファオーバーフローだったり 符号つき整数の問題だったり、パストラバーサル (path traversal)問題だった。 しかし、オレの関心を最もひきつけたのは修正が行われたファイルは、eval.c と class.c だ。 その修正は Ruby のクラスに対して不正なやり方でコードを追加しようとすることに対する、 防御のように思えた。もしその推測が正しければ、本当の欠陥とは、 なんらかのRailsアプリケーションに対してキミが単純な文字列を間単に放り込むことができて、 それによって制御権を得てしまう可能性があるということかもしれない。 I guess we'll find out after the Ruby guys passively aggressively kill me for looking at their open source and …. telling people things. #gkbr
programming: Zed Shaw's Rundown of The Big Ruby Vulnerabilities 任意のコードが実行される脆弱性について
22日追加 Riding Rails: Multiple Ruby security vulnerabilities
June 2008 Ruby Security Advisory: A Summary Matasano Chargen » Updates on Drew Yao’s Terrible Ruby VulnerabilitiesRiding Rails: Multiple Ruby security vulnerabilities # Uggedal on 21 Jun 10:37: If you’re not one of those that feel vulnerabilities need to be kept secret, have a look at Zed’s look at the changes made in these latest versions. # Vladimir Sizikov on 21 Jun 17:01: Eivind, Zed actually performed lots of non-needed work, comparing the snapshots, while there is a nice svn and git log of all the changes, much better documenting why changes were made and what has been changed. There is no conspiracy here, and nothing is really was hidden. Everything is in the public repositories.
Matasano Chargen » Updates on Drew Yao’s Terrible Ruby VulnerabilitiesNobu Nakada June 21st, 2008 9:21 pm Very sorry, fixed it.
一つ前へ
2008年6月(中旬)
一つ後へ
2008年7月(上旬)
メールの宛先はこちら