公開的手寫辨識程式跟實作資訊

最近在思考一些有趣的事情:中文的部首/字/詞是分別對應到英文的字母/字/詞。不知道中文詞的平均筆劃經過頻率統計加權後的結果會不會比英文詞小？(因為資訊傳達是以詞作單位，而不僅是以字作單位的任意組合)是的話，這到是半理論證明"中文輸入不會比英文慢": 所謂正體中文會妨礙科學進步的論調只是那些不深思熟慮的傢伙不經證明的夸夸之詞。我為什麼直覺這樣推斷？因為直覺上中文字形的的熵(entrop)平均值應該比英文字形的大。假如我的假說成立的話，以手寫來說，中文輸入會比英文快。

我的確是有在著手一些關連到中文的語料問題，這些是解決很多事的關鍵性基礎研究。不過對大多數的人而言，最重要的問題反倒是: 能不能有公開的手寫辨識程式?關於這點，目前看到公開的手寫辨識程式跟實作資訊有:

Palatis 寫了 Chrasis，似乎可以用滑鼠輸入。今年６月 的時候我曾試著在Mandriva 2007.1上編譯看看，但還不成功，後來忙就先擱著。

jserv 寫了這一篇從Chrasis 談手寫辨識引擎在移動裝置的機會，有提到一些相關的問題

歪林 (superylam@netcape.net)為了掌心雷跟百變小蒙恬寫了X Windows手寫板驅程程序及輸入法

根據網路上的說法，蒙恬筆豪華版(LLC 504)隨附的數位手寫版(型號FT-0405-U02)，是由知名數位繪圖板廠商Wacom代工。而Linux 在wacom 的支援好像還不錯。臺灣的繪圖板就不知道。

繪圖板蠻貴的，我連每天要用的老舊交通工具都沒錢去修，一時沒辦法負擔得起這種昂貴的玩具。那天要是弄得到不管是臺灣或Wacom的繪圖板時，再來試試看把歪林跟Palatis的成果整合在一起。就看誰要先借我手寫版來開發了。

gnome 桌面上的"位置"如何設定

gnome 桌面上的"位置"如何設定

1.0 版 十月 25, 2007
2.0 版 Mar 17, 2008

Mandriva 最早是追隨 debian 的menu架構，後來逐漸轉移到XDG Menu System標準。2008有個工具在處理這些。不過我還沒找到在Mandriva 2007.1 上是如何處理這些。當時每次開gnome-terminal 都跑到~/Desktop 下。有點煩。反正現在升級了就不用管了。

Mandriva 2007.x

~/.mdk-folders
下面有幾個聯結
documents
download
music
pictures
video
就是相對應
"文件"
"下載"
"音樂"
"圖片"
"影像"
的位置

還有相對應的翻譯檔
documents-mdk.desktop
download-mdk.desktop
music-mdk.desktop
pictures-mdk.desktop
video-mdk.desktop

比如說我不喜歡桌面上的"下載"位置是指到 ~/Download/
想搬到 ~/Documents/Download/

我就執行
代碼:
rm ~/.mdk-folders/download
ln -s ~/Documents/Download ~/.mdk-folders/download

然後用utf8的編輯器如gedit 修改 ~/.mdk-folders/download-mdk.desktop裡的
代碼:
URL=file:///root/Download

改成
代碼:
URL=file:///root/Documents/Download

然後重新登入
(註: 用2007.1 當時，只登出/登入 gnome 我的雙螢幕左半桌面會怪怪的 系統重新啟動後就沒事)

Mandriva 2008

MDV2008 現在不用 ~/.mdk-folders了，新版遵從XDG 的式樣。如使用者名稱是加菲貓，那在
/home/加菲貓/.config
下面有 user-dirs
跟
user-dirs locale
為保險起見，我用能判別編碼的編輯器來編輯
user-dirs locale 指定了locale 是
zh_TW
在~/.config/下的user-dirs.dirs檔裡面有幾個聯結，指定了桌面預設檔案夾名稱
XDG_DESKTOP_DIR="$HOME/桌面"
XDG_DOWNLOAD_DIR="$HOME/下載"
XDG_DOCUMENTS_DIR="$HOME/文件"
XDG_MUSIC_DIR="$HOME/音樂"
XDG_PICTURES_DIR="$HOME/圖片"
XDG_VIDEOS_DIR="$HOME/影片"

就是桌面位址相對應的
"桌面"
"文件"
"下載"
"音樂"
"圖片"
"影片"

我相信對應的英文檔名是
Desktop
Doucments
Download
Music
Pictures
Video
不過不太確定了

假如是在 utf-8 編碼， 對應
文件
下載
音樂
圖片
影片
這些位址檔名的逸出字元表示是
file:///home/加菲貓/%E6%96%87%E4%BB%B6
file:///home/加菲貓/%E4%B8%8B%E8%BC%89
file:///home/加菲貓/%E9%9F%B3%E6%A8%82
file:///home/加菲貓/%E5%9C%96%E7%89%87
file:///home/加菲貓/%E5%BD%B1%E7%89%87

假如是在 big5 編碼， 對應檔名的逸出字元表示是
file:///home/加菲貓/%A4%E5%A5%F3
file:///home/加菲貓/%A4U%B8%FC
file:///home/加菲貓/%AD%B5%BC%D6
file:///home/加菲貓/%B9%CF%A4%F9
file:///home/加菲貓/%BCv%A4%F9

(這使用者名稱加菲貓要換成對應的英文)

怎樣查utf8 中文的逸出字元

看到一堆逸出字元怎麼查誰是誰？後來發現一個方便的方式：用python

我在gnome-terminal 下用zh_TW.UTF-8的locale執行python，直接把字串輸入，就會傳回字串utf8編碼

$ python
Python 2.5.1 (r251:54863, Jan 14 2008, 13:07:32)
[GCC 4.2.2 20070909 (prerelease) (4.2.2-0.RC.1mdv2008.0)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> '桌面'
'\xe6\xa1\x8c\xe9\x9d\xa2'
>>> '下載'
'\xe4\xb8\x8b\xe8\xbc\x89'
>>> '文件'
'\xe6\x96\x87\xe4\xbb\xb6'
>>> '音樂'
'\xe9\x9f\xb3\xe6\xa8\x82'
>>> '圖片'
'\xe5\x9c\x96\xe7\x89\x87'
>>> '影片'
'\xe5\xbd\xb1\xe7\x89\x87'

假如是 big5 編碼，改用zh_TW 的locale執行 python

在Nautilus/gnome 下加入更多的捷徑

當然常用的位置不只這些，系統已在~/.gtk-bookmarks下預設了幾個，如2007時的
代碼:
file:///home/加菲貓/.mdk-folders/video-mdk.desktop

我們也可以自己加，如
代碼:
file:///home/data

在gnome 的檔案管理系統會用最底層的目錄名作為名稱顯示萬一不同目錄最底層的目錄卻同名的話，還可以用別名，如
代碼:
file:///mnt/win_e/data wine_e_data

不過一但加入更多的位置捷徑，文件/下載/音樂/圖片/影片這幾個就會從位置的頂層，移到叫"書籤"的下一層位置裡

延伸閱讀

用 convmv 來轉檔名編碼

關於轉移到XDG Menu System，這一篇有一些參考價值
http://wiki.mandriva.com/en/Development/Howto/MenuMigrationToXDG

附錄：

(註: 下面這篇本來名為"mandriva 2006 調校 "發表在CLE
http://cle.linux.org.tw/forum/viewtopic.php?p=2916&sid=b8971dc6c482b78f9ebdc05efdfa0069
不過那邊有人見不得人好，自己一點牛肉都端不出來，卻愛批評別人的燒餅會掉芝麻。還會不時偷看我的文章然後在網路上亂罵人，所以我就懶的過去修改了。時間久了就會自然證明孰是孰非。這只是作檔案存檔，不過gtk 跟更新的部分還是有效的)

有圖有真相

Google 正體中文搜尋 "Mandriva xdg" 這篇文章當時排行第一，現在還是前幾名(不過其他的不是我寫的，就是其他不相干的資訊)。其實我當時就有存檔，只不過跟大眾證明事實，並不比事實本身重要，所以沒有第一時間就拿出來，而是到改版把文章改的更好時才拿出來。那些只會亂批評別人的人，除了會第一時間跳出來罵人，口水一地外，長期看下來，什麼實質東西都沒有。努力工作時間寶貴，我不會隨這種人的污衊起舞，因為事實勝於雄辯。

想瞭解這些人的惡形惡狀，請參考垃圾堆1

用Emacs 開發C 程式

Version 1.1

(Oct 21: 1.0版)
(Nov.12 1.1版: xcscope 的深入討論獨立出來自成一節)

最近被學校猛操 C 程式開發，我覺得開發C 除錯的時間要比lisp長很多，非得找方便的開發除錯環境來幫忙不可。理論上我可以用eclispe或anjuta 這種大傢伙來開發，但我一邊開發除錯還要一邊作別的事，那些不是很方便。最好的選擇還是找能跟emacs 搭配的工具。

目前在emacs上裝了
ecb
xcscope
xrefactory (xref-1.6.10)
覺得工作起來順手多了。這三個各司其職:
ecb 比較接近快速的瀏覽 source code 整體本身
靜態的呼叫範圍相關問題用xcscope查
跟編譯比較接近的相關問題用xref
三者都跟emacs 的source buffer 緊密結合

除了這三者外，還有一些其他的工具，其中cbrowser好像很久沒更新。SimpleCallTree 我弄不出來，作者勸我用比較正式的工具代替。

Code Crusader 5.2.1 是商業程式。demo有兩種，一種是限制使用時間，另一種是限制最多開啟5 個檔案跟5 個視窗但還要註冊。我不是很喜歡。

Doxymacs等於是Doxygen + {X}Emacs。我根本沒時間好好弄文件，就先擱著。

還有一些不熟的地方，等日後弄通了再整理出來。參見CategoryProgrammerUtils

ecb

結合gdb, outline-mode...這些說起來話長，先放一張圖片供參考。下面會再提到。可以看到在History 視窗裡某些檔案icon 從綠點變成橘點，表示下面這些檔更動過
hmm.cpp
Point.h
其他沒有綠點/橘點的檔案(如chineseNL.txtP)，是其他正在編輯但不相干這個工作目錄的。但在目錄視窗裡可以看到Makefile 被動過，所以在這會從綠點變成橘點，但不是emacs 弄的，所以不出現在History 視窗。

xcscope

跟著cscope 有個 xcscope ，提供cscope 支援，可以讓搜尋變數的過程更簡便。附圖可以看到xcscope 把搜尋viterbi 這個符號的兩個結果同時在%cscope%裡顯示

關於xcsope 的深入討論獨立出來，參見第三部分:xcscope整合。

XreFactory

XreFactory(下面簡稱xref)是 www.xref-tech.com 的產品。其中 c/java 是免費使用。現在是1.6.10版。
C/C++ 版現在是2.0.13版，只有八天合法試用期，過了就該買license。
參見http://www.emacswiki.org/cgi-bin/emacs-en/XreFactory

xrefactory 可以列出沒有用到的變數。當編譯時出現問題時，假如選擇查看 log 檔，*xref-log* 視窗會列出有問題的行。如同 cscope，這時用鼠標移到其中想要跳過去查看的那一行，按滑鼠中鍵或左鍵，主程式視窗列表就會跳到對應的那一行。

XreFactory會在~/下產生 .xrefrc

每次建立一個新project 時會產生一個以
[子目錄]
開頭的區塊，裡面可以設定 編譯的選項。我自己是把 make debug 放進去，在
Makefile 註明 gcc -g 好產生符號表供dgb使用。

三者整合使用

這兩者分別控制獨立相對應的主程式列表視窗。

假如螢幕夠大，建議開兩個frame ，其中一個執行 ecb ，一個不要執行 ecb。因為 xref切frame成左右兩個視窗，建議在沒有執行 ecb的frame執行xref 動作。在有執行 ecb的frame 下切到*cscope* 的 buffer執行cscope 動作

寫好直接在 emacs主選單下選 compile。
編完直接在 emacs主選單下選 tool -> debugger(GDB)

以我手上這個程式為例，跑到最後出現
Program received signal SIGSEGV, Segmentation fault.
0x00002b4736238eab in fclose () from /lib64/libc.so.6
(gdb) where
#0 0x00002b4736238eab in fclose () from /lib64/libc.so.6
#1 0x00000000004016d6 in main (argc=1, argv=0x7fff74d3e1a8) at test.c:488
(gdb)
所以就知道程式死在第488行附近

GCC 最佳翻譯徵求懸賞

在我的"現代中央處理器的C 整數長度"blog 文刊出後，蒙 jserv 立即回應參考 "理解 64-bit Programming Model 一文後，才發現了zonble 之前竟然blog了 本日金句：LongLong Long is Too Long」這篇妙文。我決定來個最佳翻譯徵求懸賞，共襄盛舉:

請中文翻譯 mjhsieh 當初碰到這一段gcc 編譯錯誤:
"test.c:22: error: `long long long' is too long for GCC"

原則上要詩/技(geek)意雙全為佳。

我會找幾位自由軟體社群中對文藝有涉獵的朋友作評判，有可能的話還會請一位
詩畫俱佳的藝術家前輩作評判。比賽截止日期暫定 2008 詩人節，我記得我手頭
上還有一本全新鹿橋寫的"人子"躺在某處箱子裡。要是找不到的話，至少會有一本 Linux的書作為獎品。

願意加碼提供獎品，或有其他促進更大參與層面主意的朋友，也請不吝賜教。



我先拋磚引玉:

測試點兮二二行, 編譯錯誤兮信息:
"長兮長兮長整兮、過長兮於姬兮兮"

(註: 行也可讀成 "行"走的音)

現代中央處理器的C 整數長度

最近要寫一些C程式處理大筆資料，有點擔心會整數溢位。
寫了個C程式試了下，發現很有意思的事

在AMD CPU 32bit Athlon gcc 4.1.2 傳回
bytes: char:1, int:4, long:4, unsign:4, unsign long:4, long long: 8

AMD 64bit Athlon gcc 4.1.2 傳回
bytes: char:1, int:4, long:8, unsign:4, unsign long:8, long long: 8

Sun Ultra sprac III (64 bit CPU) gcc 3.4.4 傳回
bytes: char:1, int:4, long:4, unsign:4, unsign long:4, long long: 8

看起來Sun 這版gcc 還停在 32 bit

其實一般應用 32 bit signed 整數(-2,147,483,648 到 2,147,483,647)已經蠻夠了。要省空間就用 short int 或 char


short int (2)
-32,768 to 32,767
(K& R 說是 -32,767)

unsigned int (4)
0 to 4,294,967,295

int (4)
-2,147,483,648 to 2,147,483,647
(K& R 說是 -2,147,483,647)

char (1)
256 character values

float (4)
1.2e-38 to 3.4e38

double (8)
2.2e-308 to 1.8e308