P.Graham 著 ANSI Common LISP 練習問題解答
0. はじめに P.Graham 著 ANSI Common LISP （日本語訳） は優れた LISP の入門書です。この本には練習問題が載っていますが、解答は付いていないので、 解答案を書いてみました。その問題までに出てきた本文の内容を使って解いていますので （特に最初の章では）ぎこちない点があります。あまりにぎこちない場合は別解をつけました。 自信の無いところもあります。 間違いなどが見つかりましたら takafumi@shido.info までご連絡ください。 1. 目次 第2章 第3章 第4章 第5章 第6章 第7章 第8章 第9章 第10章 第11章 第12章 第13章 2. 第2章 "X => Y" は "X が評価されて Y になる”を表す。 5 => 5, 1 => 1, 3 => 3, and 7 => 7. (- 5 1) => 4 and (+ 3 7) => 10
Emacs による Lisp Hacking
SLIME の公式ページ から入手可能です．現在は ArmedBearCL, AllegroCL, CLISP , Corman Lisp, CMUCL, ECL, LispWorks, OpenMCL, SBCL, Scieneer Common Lisp といった処理系に対応．( Scheme48 に対応した SLIME48 もあります) 別プロセスで起動した lisp 処理系とソケット経由で通信する 関数の引数表示 シンボルの補完機能 ( **例：** ``m-v-b TAB => multiple-value-bind`` ) コマンド一発で HyperSpec が引ける コンパイラの note, warning, error をソース上で示してくれる（下線が引かれて，カーソルを合わせると詳細がでる） 親切なデバッガ（バックトレース上でカーソルを合せると詳細が表示されたりとか） 現
cl.pocari.org - Subversion で直前のコミットを取り消し，なおかつ Trac も同期する方法
Subversion で直前のコミットを取り消し，なおかつ Trac も同期する方法 2007-01-18-1: [Subversion][Trac] 勢い余ってコミットしたはいいけど，恥ずかしい間違いがあってコミットをなかったことにしたい場合の対処方法です． 対象のリポジトリ /svn/foo 現在のリビジョン 100 直前のリビジョン 99 対象の Trac 環境 /trac/foo 1. 取り消したいリポジトリをディレクトリごとバックアップする $ mv /svn/foo /svn/foo.bak 2. 同名のリポジトリを作成する $ svnadmin create /svn/foo 3. バックアップしたリポジトリから直前までのリビジョンをダンプして，新しく作ったリポジトリにロードする $ svnadmin dump -r 0:99 /svn/fo
The C10K problem
[Help save the best Linux news source on the web -- subscribe to Linux Weekly News!] It's time for web servers to handle ten thousand clients simultaneously, don't you think? After all, the web is a big place now. And computers are big, too. You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1200 or so. Let's see - at 20000 clients, that's 50KHz, 100Kbytes
Web2.0の先にあるC10K問題 ― ＠IT
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
最速配信研究会 - Web2.0とC10Kに関する数々の誤解
Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://user.ecc.u-tokyo.ac.jp/~t50473/onlispjhtml/index.html