2012年8月21日 星期二

在 Mountain Lion 上編譯 libchewing

本文參考迷途小書僮的筆記 在 mac osx 10.7 下編譯 libchewing ,成功在 Mountain Lion 上編譯 libchewing。
步驟如下:
  1. 先去 github clone 一份乾淨的 source code 回來
    • git clone https://github.com/chewing/libchewing.git
  2. 安裝 xcode
  3. 安裝 homebrew : 依照首頁的指示安裝
  4. 安裝以下套件
    • brew install autoconf automake check libtool pkg-config
  5. 開始編譯
    • cd libchewing
    • ./autogen.sh
    • ./configure
    • make
    • sudo make install

2012年6月25日 星期一

Media Center + XBOX 360 心得

幾個月前買了 Xbox 360,玩了一陣子,就放在電視旁邊生灰塵。

今天心血來潮,把最近為了要玩 D3 而重灌的 Windows 串接到 360 上面,看看微軟所謂的「多媒體中心」會是長什麼樣子。畢竟最近微軟的產品,越來越多是受到 Xbox 的影響,如 Windows phone、以及即將出爐的 Windows 8,其介面都是參考 Xbox 360 的經驗的成果。

我的 OS 是 Windows 7 ,內建 Microsoft Media Center 的程式,因此串接過程還蠻簡單的。只要打開 Xbox,進入 Media Center ,就會出現一組序號,然後再輸入到 PC Media Center 中,就完成串接了。

雖然 XBox 本身只能播放若干格式的 WMV 檔案。但使用 Media Center 是沒有此限制的,也就是說 PC 播的出來,XBox 就能夠幫你播!

聽起來還蠻厲害的。那就實際來試試看吧......

測試的結論是:非常不穩定。

我用來測試的是一個 rmvb 影片 (1080p)、XBOX 的解析度設定為 720p、Windows 裝的是 K-lite Codec Full。
  1. 如果要對影片做「暫停」、「搜尋」,都有可能讓影片播放失敗,或者是我的 PC 就當掉了 (死機) 。
  2. 另外,在觀看影片時,如果畫面場景變動過快,畫面就會有馬賽克,解析度自動下降。等動作場面平靜以後,又恢復高畫質水準。
  3. 我的 PC 和 Xbox 都是直接吃無線網路,結果播出來斷斷續續。後來我把 Xbox 用實體網路線接上 AP,才能夠順暢播放。
  4. 按鍵操作不夠直覺。我還要千辛萬苦在網路上才找到搖桿操作播放器的使用說明。而且看了說明以後,才驚呼:靠,原來暫停在這裡!
最讓我無法忍受的應該是 1。只要稍微做任何播放的操作,如最基本的暫停,播放器就會死掉。馬賽克的問題也蠻嚴重的,或許是我的 CPU 不夠力,但好歹我也是第一代 i5,應該比一些人的電腦好一點。

我的使用經驗,應該是五顆星等級的非常痛苦。

不過我在這邊卻看到了更大的商機,只能說微軟浪費了自己大好的平台資源,這一兩年難怪會被 Google、Apple 打假的。

首先分析一下,微軟有哪些平台資源:
  1. 壟斷的 PC 桌面作業系統。
  2. 豐富的多媒體播放環境 (in Windows)。
  3. 和 Sony 平分天下、體感完勝的家用遊樂器 XBox。
  4. 最近努力振作的 Windows Phone。
  5. 最近想要搞的平板 Surface。
 微軟的強項:
  1. 把所有自己的產品綁在一起賣,所以你買 A,就要買 B。你買 Office ,就要買 Windows。雖然 Office 也有 Mac 版,但 Linux 肯定是不行的。
  2. 深厚的多媒體技術:
    1. 最廣泛使用的多媒體 API: DirectX (有很多專利)
    2. 自有的媒體播放格式:WMV / WMA (想必也有很多專利)
    3. 最先進的遠端桌面播放技術:RDP (這個應該也有專利)
    4. XBox 遊戲機。遊戲一直是多媒體的極致展現,多媒體應該已經是無庸置疑了。
微軟的機會:
  1. 我看到裡面有一個網路頻道,可以收看網路影片。其實應該增加許多影片來源,如 Youtube、或大陸一堆奇奇怪怪的視頻網站、或是機上盒業者如網樂通合作。這一部份就會成為收益的來源。而 XBox 其實就是一台萬能的機上盒。如果這部分沒做起來,就表示微軟搞不清楚這部分的平台費用該怎麼算。
  2. 當 XBox 和 Windows 的結合,就只是這樣而已,實在讓人有點失落。應該要不只是這樣。例如用最簡單的遠端桌面連線控制電腦,再加上 Kinect 操控介面,不是更屌更直覺嗎?
  3. 當這一切都結合起來以後,再加上 Windows Phone 或 Surface 各種不同的使用情境,就像 Gmail、Google Map 與 Android 間的關係。就如同要用 Google 的服務,就要用 Google 的親生兒子 Android 才會得到最完整的使用體驗這種感覺,這樣市場不就拉抬上來了?
我對這個多媒體平台有這麼多期望,但當我看到結果是這麼的糟糕,真是讓我失望到差點把 Windows 砍掉。但把 Windows 砍掉,打 D3 就不順了,所以我還是忍了下來...

微軟,加油好嗎?

2012年1月22日 星期日

C++: int 轉字串測試

輸出整數型別 (Integer) 或許是我們最常需要使用的功能之一。

網路上常見的建議為:
在 C 語言,我們常用 sprintf snprintf 來操作。
在 C++ ,我們可以使用 stringstream 來轉換。
另外,也可以使用 boost 來轉換。

這三種各有優缺點,在 The String Formatters of Manor Farm 一文中針對整數轉字串做了一個完整的分析。
在這裡,我們不考慮是否會發生緩衝區溢位的問題 (sprint),也不考慮程式碼是否容易辨別 (我們都把它包成一個函式)。那,到底誰最快呢?

在 boost 網站上有他們自己做的測試

不過我還是喜歡自己測,眼見為憑。
我寫了一支小程式 CastIntToStringTest.cc ,其中我將 snprintf 和 ostringstream 重新包裝成下列函式。

char *IntToPtr(int i)
{
  static char buf[50];
  snprintf(buf, sizeof(buf), "%d", i); 
  return buf;
}

string IntToString(int i)
{
  ostringstream oss;
  oss << i;
  return oss.str();
}
我的 g++ 版本為 gcc version 4.6.2 (Debian 4.6.2-12) OS 為 Debian sid (2012-1-22) 跑在 VirtualBox 上面 Host 為 Mac Mini Server (Core 2 Due 版),OS 為 Lion。 執行結果如下
hialan@debian:~$ ./CastIntToStringTest 
Test IntToPtr: 123456
Test IntToString: 123456
Test lexical_cast: 123456
Run 10000000 times.

IntToPtr: 2 secs.
IntToString: 11 secs.
lexical_cast<string>: 4 secs.
hialan@debian:~$

在官方做的測試中,int -> string 的轉換結果為
lexical_cast : 20
std::stringstream with construction : 121
std::stringstream without construction : 21
scanf/printf : 16

我想差距不大。假設官方的測試結果是 ok 的。

不過我的測試只針對單一型別做轉換。在嚴格條件下可以針對這類案例做最佳化。
但如果是要一般化的解決方案,我想用 lexical_cast 是不錯的選擇。程式碼精簡明確,又可套用在不同型別。
而且結果比 sringstream 好上太太太多了。

至於 sprintf ? 如果想要自己處理記憶體的話,可能是個好選擇。