lucille development blog » Blog Archive » LLVM および自動最適化の勉強会を開きたいなと考えています
(追記: LLVM 勉強会,やります) LLVM の勉強会、また自動最適化の勉強会みたいなのを開こうかなぁと考えています. LLVM 勉強会 LLVM については、まずはなんだかみんなまだよく知らないようだしちょっと誤解しているみたいなので, これを機会にしっかりと知るといいんじゃないかな、というのがある。 (ただ、私は LLVM コミッタとかではなくて、外野にいる一ユーザです) 加えて、私としては自動最適化ともからんでくるけど実行時最適化(JIT, partial evaluation)を 自分のプログラムに取り入れたいときに LLVM コンパイラインフラがすでにある物としては practical で十分な feature を持っているので使っていこうかなと思っていて、 そのためにそこらへんをもう少しよく知って共有したいから. 次に自動最適化の勉強会. もう手作業で最適化の時代
ソフトウェア工学とは何か
ソフトウェア設計とは何か？ （原文： What Is Software Design?） by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は，Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 本記事では，オブジェクト指向プログラミング言語の代表として C++ を挙げていますが，これは本記事が執筆された当時，一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java，Delphi，C# といったオブジェクト指向言語が利用可能となっていますが，そんな今でさえこの記事は古さを感じないものとなっており，ソフトウェア開発の本質，現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W.
akihiro kamijo: AS3 の論理積と論理和
最近質問を受けたので見てみたら Flash のヘルプドキュメントが古いのに気づいたので今日はこの話題です。（LiveDocs の AS3 リファレンス は最新です） さて、まず下の例を考えてみます。 var foo:Boolean = true; var bar:Object = {}; trace(foo && bar); // 論理積 : 出力は [object Object] trace(foo || bar); // 論理和 : 出力は true 論理積と論理和の結果は、演算子の左側の式 （この場合は foo） の値で決定されます。ごく単純化すると、ルールは 論理積 (&&) : 左側の式が false なら左側の式の値、true なら右側の式の値 論理和 (||) : 左側の式が true なら左側の式の値、false なら右側の式の値 です。つまり、実際に論理演算が行われている
ちょっと草植えときますね型言語 Grass
_, ._ （ ・ω・） んも〜 ○=｛=｝〇, |:::::::::＼, ', ´ ､､､､し ､､､((（.＠）ｗｖｗｗＷＷｗｖｗｗＷｗｗｖｗｗｗｗＷＷＷｗｗＷｗ ｗＷＷＷＷＷＷｗｗｗｗＷｗｗｖｗＷＷｗＷｗｗｖｗＷＷＷ 作ってみたｗｗｗｗｗ とりあえず公開ｗｗｗｗｗｗｗっうぇ 日本語版はてきとーです．きっと英語版のほうが詳しいです． 実装 インタプリタ Interpreter written in Standard ML (accept US-ASCII only) by UENO Katsuhiro Interpreter written in Ruby by UENO Katsuhiro Interpreter written in ニコスクリプト Interpreter written in Prolog by zick Interpreter written in Java b
「作っては壊す」過程があってこそ良いものが作れる
iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが
新卒で入社して一年
大手電機メーカーのSEとして就職して一年。 うちの職場は、なんというか、生ぬるい。 もちろん仕事がないかといえばそういう訳でもなく、 毎日20時21時まで残業するのが当たり前。 でもそれほど切羽詰っているわけでもないから、 定時に帰っても特に問題ないし、皆ちょこちょこと有給で休みを取る。 一日に何度か職場のあちこちで雑談タイムが繰り広げられていて、 朝から晩までバリバリ仕事、という空気でもない。 そして今年は一年目だから給料は300万ちょっとだけど 来年からは600万くらいに跳ね上がる。 はっきりいって、楽にお金を稼ぐという点では非常に恵まれた環境だと思う。 良くも悪くも平均的な人が多く、職場の人間関係も穏やかそのもの。 このままなんとなく過ごせば、きっと10年後には貯金の額もすごいことになる。 でも、ここにいる限り、スキルの向上はあまり期待できそうにない。 同僚はクルマやらマイホームやら
Cocoa アプリで Cover Flow を使う方法 - d.hetima
SafariStand 3.0L159 で History Flow なる履歴閲覧機能を付けたわけですが、コアである Cover Flow の部分。ゼロから作ったわけではありません。こんなもん作る気になれませんw作れませんww。システムにこっそり用意されていました。その名は「IKImageFlowView」。ImageKit.framework に定義されています。これは Quartz.framework のサブ framework なので、使用するには Quartz.framework をリンクします。 基本的な使用法は IKImageBrowserView と似ています。delegate と datasource があり、IKImageBrowserItem Protocol に合致するオブジェクトを渡してコンテンツを作ります。 nib に NSView を配置してカスタムクラスを「I
ヨーロッパ圏にXNAゲームを配布するときの注意 - ABAの日誌
Mazer Mayhem 0.12 (http://www.asahi-net.or.jp/~cs8k-cyu/xna/mm/index.html) バグフィックスのみ。でも結構重要なもの。一部の国で動かなかったそうだ。おそらくヨーロッパ圏あたり。 XNAというか.NETでは小数点の扱いを自動的に各国の流儀に合わせてしまうらしく、ヨーロッパ圏の一部の国で動かすとfloat.Parseで小数点がカンマを使うものと考えてパースしてしまう。なのでドットを前提として書いてあるコードではfloatのパースに失敗してしまう。 以下のようなコードを使えば日本でも再現はできる。 System.Globalization.NumberFormatInfo nfi = new System.Globalization.CultureInfo("fr-FR", false).NumberFormat; floa
自分の経験の枠組みは自分で変えられるか？ - アンカテ
例によってメタな方向に話を広げようと思うんだけど、Ruby VS PHP論争の背後には「自分の経験の枠組みは自分で変えられる」という発想の有無という問題があるのではないだろうか。 そう思ったきっかけはこれ。 影響力のある人 - L'eclat des jours(2008-01-31) artonさんは、Matzにっき(2008-01-29)のコメント欄にあった、「影響力の大きい人が発言してるので怒ってます」という一言レスに着目して、興味深い考察をしている。 影響力のある人ってのは、つまり権威ってことなんだし、自分で吟味しない人は常に一定の割合でいて（そうでなければ、世の中に権威という存在はありえないわけだが、実際、存在している）その人たちに影響を与える。 ってことは、権威がある人は、だめなものはだめ（良いものは良い）、と言うべきですね。 私も全くその通りだと思ったけど、冒頭のように考えて
Structure and Interpretation of Computer Programs
Wizard Book n. Hal Abelson's, Jerry Sussman's and Julie Sussman's Structure and Interpretation of Computer Programs (MIT Press, 1984; ISBN 0-262-01077-1), an excellent computer science text used in introductory courses at MIT. So called because of the wizard on the jacket. One of the bibles of the LISP/Scheme world. Also, less commonly, known as the Purple Book. from The New Hacker's Dictionary, 2
perl - There's more than one way to duck-type : 404 Blog Not Found
2007年06月14日00:15 カテゴリLightweight Languages perl - There's more than one way to duck-type 違う部分もあるので、そこを補足。 rubyco（るびこ）の日記 - Duck Typingは大規模プロジェクトでも大丈夫か？ 考えてみたらPerlも同じか。Perlの場合、ContextがDuck Typingの代わりをつとめることが多い。 例えば、文字列を数値として扱う時に、rubyでは "1".to_i + "2".to_i と、明示的にto_iで型変換しなければならないのに対し、Perlでは "1" + "2" が3になる。状況、すなわちcontextに応じて、自動で型変換がなされるからだ。初心者に好かれ、中級者に嫌われ、上級者がやみつきになるのがこのcontext drivenという考えかただ。 なぜ初心者
Duck Typingは大規模プロジェクトでも大丈夫か？ - rubyco（るびこ）の日記
整数として処理したければ、オブジェクトがto_iという振る舞いを持っていることを期待してなんでもとにかくto_iしてしまうのがDuck Typingなのかなと思いました。 Duck Typing? - 18 til i die (another phase) なるほど、そうですね。 そういえば、Duck Typingでは「メソッド名がグローバル」になりますね…。ふと思ったのですが「大規模プロジェクトでメソッド名がコンフリクトしてDuck Typingが破綻する」という可能性はあるでしょうか？ ＞ 識者のみなさま。 # おお、スケーラビリティの話題じゃん。 想定解答： (0) この問いかけ自体が無意味。なぜなら…（誰かがここを埋める） (1) 大規模プロジェクトでもDuck Typingは破綻しない。なぜなら…（誰かがここを埋める） (2) 大規模プロジェクトでDuck Typingは破綻す
数学的帰納法で完全なテストを行えるか？
以前、完全なテストは不可能だ という稿を書いたのですが、これに対して 反論しているページ を見つけたので考察しておきます。 反論の骨子 該当ページの文章が短いので全文引用となってしまいますが、法的な引用の要件を満たせると思うので引用します。 思うに、それは論理学でいうところの帰納法で解決できるのではなかろうか。 完全なテストは不可能だ: さて、プログラムの話に戻ります。intの引数を2個とる場合、その組み合わせは1600京ほどに なるということを先の稿で述べました。 そして、バグが「ある」ことを証明する場合、バグの例をひとつ探し出せばよいのに対し、 バグが「ない」ことを証明するにはこの1600京のパターンすべてを網羅して検査し、 全て正常に動いたということを提示しなければなりません。 数学でも、全ての数を計算したわけではないのに成立している定理は山ほどある。というかそうでないものの方が少な
K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
感想: イベントVs.スレッドをhigh-conccurencyサーバを対象に して真面目に考え直してみた論文。
Rob von Behren, Jeremy Condit and Eric Brewer (UCB) Why Events Are A Bad Idea (for high-concurrency servers) Proceedings of HotOS 03, May 2003. 感想: イベントVs.スレッドをhigh-conccurencyサーバを対象に して真面目に考え直してみた論文。 Abstract イベントモデルは high-concurrency システムでは良いとされて きたが、それは間違いだ! (筆者らの信じるところによれば) イベントの良い点(高い並列性、低いオーバヘッド、シンプルな 並列モデル)などはスレッドでも達成できる。さらに、スレッドの 方がよりシンプルで自然なモデルでプログラムを書ける。 スレッドの弱さは本質的なものではなくスレッドパッケージの実装
Ringo's Weblog: 知識の量が質に変化する瞬間
プライバシーポリシー | サイトポリシー | 商標 | フィード | サイトマップ Copyright© 2000-2007 Community Engine Inc. All rights reserved.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp：本： リファクタリング―プログラムの体質改善テクニックObject Technology Series
Amazon.co.jp： Essential ActionScript 3.0 (Essential): Colin Moock: 洋書
https://www.flashdevelop.org/community/
