Victor’s Blog

Quick-sort


(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 只是一個普通的 functional language，所以之前都沒去接觸。但是在看完<<駭客與畫家>>之後，開始對 LISP 產生興趣。

書裡面提到 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

今天才發現我弄錯了，昨天那篇提到的只是不會 cache，不會導致 kmem_map too small。

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

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

i386 跑 zfs 很容易會遇到 kmem_map too small，然後 panic。（搞錯了，不是這個 patch，請看下一篇）

剛才 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

這一兩個學期來，實驗室買了幾台 RAID 來裝大家實驗用的資料。幾個禮拜前，file system 爆炸，我們損失了不少資料

重點提要：

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 就不叫了。

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

今天去故宮看到的 XD

我目前在學校有個 project 需要從 flickr 抓取大量資料，包括照片的 tag、owner 等 meta data。但是我發現我拿到的 data 怪怪的，一些常用的 tag 竟然只有幾百筆。我用的 API 是 flickr.photos.search，它可以接受很多條件，然後傳回符合的照片，其中有兩個條件是最早跟最晚的上傳時間。於是我只好把時間間隔縮小很多。

直到昨天，我收到一封恐嚇^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

太帥了，竟然有 .museum 這種 top level domain!

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

Wikipedia 的 Top level domain list