(defmacro for-all (x op xs)
`(remove-if-not #'(lambda (y) (,op y x)) xs))

(append
(qsort (for-all x < xs))
(list x)
(qsort (for-all x >= xs)))))))


Permutation

(defun remove-first (n nums)
(remove n nums :count 1))

(defun permutation (nums)
(permute-sorted-list (sort nums #'<) '()))


書裡面提到 LISP 擁有許多最近新語言開始導入的 feature，而 LISP 也擁有一些其他語言沒有的功能。像我主要是被 LISP 的 macro 吸引（比 C 的 macro 強大多了。可以先把他想像成是 return 程式碼的 function，而且是在 compile 前先展開。），所以開始看 <<Practical Common Lisp>> 一書。目前為止，大家比較熟悉的語言中，我只有在 Perl 6 裡面看到 (http://en.wikipedia.org/wiki/Perl_6#Macros)。

大部分的人對 LISP 的印象就是一堆噁心的括號，寫個加法都要用 (+ 1 2) 這種前置式來敘述，實在是不符合人類的直覺。而 LISP 整個程式碼都是這樣 — 由一堆 “list” 所組成。(* (+ 1 2) (+ 3 4)) 有一個 list，第一個元素是 * 這個 “function”，第二、三個是另外兩個 list。類似這樣的語法，在定義 function、if、while 等等都一樣。

但這之前隱含了一件事實：LISP 本身的程式碼，就是一個資料結構! 所以 LISP 的 macro 做的事情就是生出程式碼的資料結構，我覺得這就比 Perl 6 的 macro 那種 template 的方式優雅多了。不過，這個優點是建立在令人卻步的括號海上的…

接下來，po 幾個我的 LISP 練習 XD

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/opensolaris/uts/common/fs/zfs/arc.c

version 1.4 調了一些參數試圖緩和 memory 用光的情形…

剛才 rafan 貼了一段 message 給我

Change type of kmem_used() and kmem_size() functions to uint64_t, so it
doesn’t overflow in arc.c in this check:

if (kmem_used() > (kmem_size() * 4) / 5)
return (1);

With this bug ZFS almost doesn’t cache.

Only 32bit machines are affected that have vm.kmem_size set to values >=1GB.

src/sys/compat/opensolaris/kern/opensolaris_kmem.c#rev1.3，還有 diff。

搞笑 XD

重點提要：

1. 同一個 channel 不要接超過三組 RAID
2. 同一個 channel 不要接不同廠牌的 RAID
3. SCSI 線跟 terminator 是消耗品

接 RAID 的機器是跑 FreeBSD 7.0-PRERELEASE。一開始發現異常，是 zfs 說他寫進去的資料跟讀出來的 checksum 不一樣，於是就爆了三個 zfs 的 partition。接在同一個 SCSI channel 的 RAID 共有四台，三台 proware 跟一台 festora(?)，zfs 叫有 error 的是其中兩台 proware，所以我們懷疑是 RAID 本身有問題。

後來找了 proware 的工程師來幫我檢查 RAID，他說我們接四組 RAID 太多了… 小時候學到的 SCSI device 不就是要用串的嗎，可是沒想到四組就算太多 orz 而且最好不要把不同廠牌的 RAID 接在一起… 因為訊號可能會互相干擾 @@ （我以為這應該有標準，可是看起來接在一起的確不太好…）

於是我們把四台 RAID 分到兩張 scsi 卡上（之前因為某些原因沒這麼做），其中一個 channel 是一組 proware + 一組 festora。然後今天下午一直發現 zfs 又開始抱怨了… 一個月前這麼接還沒事的耶 orz 真是 ooxx 現在改成三組 proware 接同一張 scsi card，另一組自己接一張，zfs 就不叫了。

(%&$#@!*(%!#@^!)

直到昨天，我收到一封恐嚇^H^H警告信，說明 query return 回來的 offset 不能超過 4000，換句話說頂多拿到 4000 筆左右的結果。API 的文件沒提到這件事，query 傳回來的 status 也都是正常 …

還好我抓得夠暴力(?)，不然如果沒收到這封信，之後學校的實驗就可能是錯的了

Greetings!
We have noticed that the api key 72157602728288126
registered to you is sending very large offset queries to
us.
example (offset=16893165)
Can you please check your usage and reconsider using these
high offsets? They are heavy/costly queries that tax our
backends.

Also to note: the search backend currently will not return
any results greater than offset 4000.

If you could limit the max offset to below 4000, we would
greatly appreciate it (and not have to disable the key -
not because we want to, but because our backends can’t take
very much of it).

Thanks!
- Flickr Team

首頁: http://musedoma.museum/
所有 second level 的列表: http://index.museum/

Wikipedia 的 Top level domain list

Mapplet 也是一樣，因為 mapplet 也可以用 gadget 的 API。

也許 Google 正在辦的比賽會有更多的 idea 跑出來。

裡面還有幾張地圖是國民政府來台之後，跟美國合作，偷偷由中華民國飛行員開美國的偵察機 (好像叫 U2?)，飛到大陸那邊去照的數十(百?)萬張地圖。而且解析度還滿高的，不知道有沒有比 google earth 清楚。之前國家不允許這種東西展出，所以現在應該是剛出來見世人吧。

他們用了相當多 google earth 跟 map 來作 demo 平台，加上 multi-touch 的桌椅組 (MITSUBISHI 的 DiamondTouch) 配合 google earth 做簡單的平移、旋轉、跟縮放。

還有 google map 上古今地圖對照，可以看你家幾十年前或一百年前是農田還是什麼的。我們有清楚看到台北市的市民大道以前是鐵路，還有基隆河截彎取直前後的樣子。

其中我覺得最酷的是一個 3D 瑩幕 (他們買來的)。他是一個特殊的瑩幕 “直接”接上顯示卡，畫面上的 3D (OpenGL, DirectX) 就直接變成立體 (當然視角很有限)。身為 CMLab graphics 組的，當然要知道原理啦。我猜他應該是去讀 z-buffer! z-buffer 是顯示卡上記錄瑩幕上每一個 pixel “深度 (離眼睛的距離)” 的記憶體，3D 的程式通常會用到。於是有了景深，這個瑩幕就可以對左右眼射去不一樣的光線 (坐在椅子上)，看起來就有立體的感覺!

另一個也很酷的是 3D 印表機 (只展出影片跟成品 不過印表機本身不是他們做的)。他是在一塊板子上一層一層塗上粉，要留下的地方的粉上膠、不留的不上。一層一層塗完之後把粉倒掉，剩下的就是那些有上膠的部分。3D 的模型就這麼印出來了!

這一個下午真是不虛此行! 下禮拜一之前，如果大家有空，可以去看一看 地點在中研院圖書館。