Victor’s Blog

我目前在學校有個 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

maintain 多台 debian 機器的設定檔很麻煩，所以我寫了一個 package 來做這件事。

下載之後，目錄裡面會有個 ROOT 目錄，直接對應到你系統上的 /。直接把設定檔放進去，就像裡面的 ROOT/etc/hosts 那樣。然後 make，就會生出 our-conf.deb 了

Our-Conf

最近 ptt 推出「用 WiFly 免費連上 ptt/ptt2」的服務，詳細內容請見活動網頁。

不過如果只能連 ptt 好像很不方便。於是我就想到可以 ip over ptt XD （當然，我用不到所以也不會寫 :p）

首先，除了用 wifly 的電腦，外面也事先要跑隻 daemon 來轉送封包。它們要做的事是連上 ptt，進 chatroom （水球會 lag，又會掉），把對方送來的 packet 往下（e.g. tcp）送。這樣就可以用 wifly 隨意上網了 XD

不只是這樣，因為 daemon 裡面外面（wifly 的裡面外面）透過 chatroom 連在一起，是對等的，所以裡面還可以跑 server 喔。當然前提是外面必須能把 packet 丟到 wifly 發的 ip。

如果上面的 idea 能成真，就可以做出一台 router 來做這些事 XD 真是邪惡…

實驗室最近要買 computational farm，於是我第一次要 survey 中信局的機器。不看還好，看了才發現表格大的那麼可怕，要用人眼從裡面找東西…不但費時，又容易出錯。於是就寫了一支程式來幫我過濾我不需要的訊息。

目前 online 的版本在 http://victor.csie.org/ctoc/。雖然寫得不是很漂亮，但是我自己用起來還滿 ok 的。歡迎有需要的人來當白老鼠^H^H^H試用，應該可以減少大家不少時間。

看到開根號倒數 (InvSqrt(), 1 / sqrt(x)) 速算法，這真是太棒了。寫了一段 code 測試，跑 1..1000000000 出來的時間，1 / sqrtf(i) 出來平均大約是 9 秒多一點，而 InvSqrt() 是接近 3 秒。至於數值的精確度，我對 1 .. MAX 每個值丟給兩個方法看他們的差，發現數字越大越準，而 InvSqrt() 出來的值「略小於」1 / sqrtf(x)。

Let f1 = 1 / sqrtf(x), f2 = InvSqrt(x)
這個表第一欄是 MAX，第二欄是 \sigma_{1..MAX}(f1 - f2)，第三欄是把第二欄 sigma 裡面的值取絕對值，第四欄是平均誤差。

1000000000: 8.0000000000 8.0000000000 0.0000000800
10000000: 5.7150559425 5.7150559425 0.0000005715
1000000: 1.8854961395 1.8854961395 0.0000018855
100000: 0.5647696257 0.5647696257 0.0000056478
10000: 0.1864424646 0.1864424646 0.0000186461


另外，這是多次 (f1 - f2) / f1 跟平均值：

1000000: 944.7488403320 0.0009447498
100000: 85.7057800293 0.0008570664
10000: 9.4323215485 0.0009433264
1000: 0.9615601301 0.0009625227


1/1000 以下的相對誤差，看起還不賴呀。以後應該會用得著 XD

我工作時通常會 ssh 連回宿舍的電腦的 screen。有時候，例如收信(我用 mutt)收到有附圖檔時，我都得先另存下來再 scp/firefox 去開來看 。因為有 screen 的關係，所以就算用 ssh -X 也沒辦法開。不過當然也可以再開個 terminal 連一個新的 ssh -X。

於是想來惡搞一下，這樣就可以輕鬆地按 enter 開 mutt 的圖檔了 :p

(screen 裡面舊的窗當然還是不能用)

–

在下列檔案加入..

.xinitrc:

echo $DISPLAY > /tmp/display
chmod 600 /tmp/display

.bash_profile:

if [ "$DISPLAY" ]; then
  echo $DISPLAY > /tmp/display
  chmod 600 /tmp/display
else
  rm -f /tmp/display
fi

.bashrc:

if [ "$PS1" ]; then
  if [ -e /tmp/display ] && [ "$TERM" = "screen" ]; then
    export DISPLAY=`cat /tmp/display`
  fi
fi

My gallery (version 1.5) is running in ML_mode = 2 (which is to detect browser’s Accept-Language for i18n), with it’s locale = zh_TW.utf8 and zh_TW aliased to zh_TW.utf8. But when visit the page, the content will correctly be UTF-8, whereas the “charset” of the HTTP header is Big5. This is my patch, but I’m not sure it’s the correct solution. This is the full bug report.

I found that an easy/small program can make g++ 3.3 unhappy, but 3.4 (and after) feels good.

#include

int main(void)
{
    std::basic_string ustr;
    ustr.append(ustr);
    return 0;
}

But after the bug report, they tell me 3.3 branch has been closed.

But why I feel really bad is when I tried to remove gcc-3.3 and g++3.3 from my box, I found the many things depend on them. It’s really sad that I have to let this bug living in my box