今天我發現 vim 現在有個叫 snipMate 的 plugin，做的比 snippetsEmu 好很多! 另外，snippetsEmu 也已經一年多沒更新了，snipMate 則比較活躍，也比較令人期待。不多說，直接看作者提供的 screencast 吧:

snipMate.vim Introductory Screencast from Michael Sanders on Vimeo.

除此之外，它的 snippet 還支援 backtick 跟 vim script:


snippet date
`system("date +%Y-%m-%d")`

snippet filename_foo
`filename()`


如果你用 Emacs，可以試試 gugod 提到的 yasnippet。

有一天走在路上看到 iPod shuffle，覺得他跟 Dororo 實在太像了 … 來合體吧!

下載網址: http://code.google.com/p/countmento/downloads/list
Project 網頁: http://code.google.com/p/countmento/

(別人都在寫 iPhone、Android，我還在寫 Java ME…)


(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