昨天看到 Google Release Python 版的 GData client library(*1), 想起擺了一陣子的 blog 搬家程式。想想不如先把 code 丟出去給想用的人用，想到再來改寫成用 GData lib。
在 Google Code 開了一個新 project(*2) 把 code 丟進去。Google Code 用的 SCM 是 subversion 1.4.0, 也有提供 svnsync 把 repository sync 進去的功能，私人的 subversion 記錄可以直接匯進去，不用很蠢地 import/export。所以有些 projects 公布時就已經有成千上百版 revision, 多半是 sync 進去的吧。
*1: Google Data APIs Blog: Snakes on GData: Announcing the Python client library!
*2: blogger-copier
2007年3月29日 星期四
2007年2月24日 星期六
記憶體位址與鍵盤控制器的關係
IBM PC 的鍵盤控制器有一個通常稱為 Enable A20 Line 的功能，和記憶體位址有關。但是鍵盤怎麼會和記憶體扯上關係?
IBM PC 最初使用的 Intel 8086 和 8088 ，有 20 條定址訊號線(Address Lines)，所以可以定址到 1MByes 的空間。前面 640KB 對應到記憶體，後面 384KB 保留給 BIOS 和界面卡使用。這也就是 DOS 640KB 限制的由來。
808x 使用 Segment:Offset ，Segment shift 4 bits 的定址方式，來存取記憶體。例如 0100:2345 存取到記憶體 0x3345 的位置。於是一個 Segment 最大就是 0xffff, 也就是 64KB。這是早期程式寫作時陣列 64KB 限制的由來。
使用 Segment + Offset 的巧處在於它會 overflow。將 Segment selector 設為 0xffff, 理論上可以定址到最大 1MB+64KB-16bytes 的範圍。但是因為 808x 只有20條定址線，所以實際上存取到的記憶體是繞回最前面 64KB。有些程式利用這個方式，來存取最前面 64KB。
Intel 推出 80286 時，將位址線擴增到 24 條，可定址空間增加到 16 MB。但是上述的範例方式會定址到 1MB 後面的真實記憶體，而不是繞回去。而有許多程式用了這個技巧，一但定址空間增加了，反而不能正常運作。所以 IBM 需要有一個方式來找回舊的行為，保持向前相容。而又要能夠在需要時，切換回去使用 80286 的新功能。
IBM 選擇的方式是在 A20 ，也就是第21條位址線上增加一個 AND 邏輯閘，控制 CPU 送出的值要不要送到板子的其他的地方。如果 AND 的其中一個控制用的輸入是 0，不管 A20 是 0 或 1, 經過之後送到板子上的永遠為 0，而能用同樣的程式存取前面 64KB。
這個控制用的訊號要從哪邊來呢? IBM 「利用」了還有多餘接腳沒用到的鍵盤控制器，Intel 8042。送出一個特殊的命令給 8042，以控制這個輸出給 AND gate 的訊號。也就是說，8042 除了原本應該負責的鍵盤訊號處理，還多作了一個不屬於鍵盤控制器該作的事。
reference:
A20 - a pain from the past
A20 line From Wikipedia
The PS/2 Keyboard Interface 有 8042 的接腳參考
8042 Keyboard Controller (From IBM Technical Reference Manual)
IBM PC 最初使用的 Intel 8086 和 8088 ，有 20 條定址訊號線(Address Lines)，所以可以定址到 1MByes 的空間。前面 640KB 對應到記憶體，後面 384KB 保留給 BIOS 和界面卡使用。這也就是 DOS 640KB 限制的由來。
808x 使用 Segment:Offset ，Segment shift 4 bits 的定址方式，來存取記憶體。例如 0100:2345 存取到記憶體 0x3345 的位置。於是一個 Segment 最大就是 0xffff, 也就是 64KB。這是早期程式寫作時陣列 64KB 限制的由來。
使用 Segment + Offset 的巧處在於它會 overflow。將 Segment selector 設為 0xffff, 理論上可以定址到最大 1MB+64KB-16bytes 的範圍。但是因為 808x 只有20條定址線，所以實際上存取到的記憶體是繞回最前面 64KB。有些程式利用這個方式，來存取最前面 64KB。
Intel 推出 80286 時，將位址線擴增到 24 條，可定址空間增加到 16 MB。但是上述的範例方式會定址到 1MB 後面的真實記憶體，而不是繞回去。而有許多程式用了這個技巧，一但定址空間增加了，反而不能正常運作。所以 IBM 需要有一個方式來找回舊的行為，保持向前相容。而又要能夠在需要時，切換回去使用 80286 的新功能。
IBM 選擇的方式是在 A20 ，也就是第21條位址線上增加一個 AND 邏輯閘，控制 CPU 送出的值要不要送到板子的其他的地方。如果 AND 的其中一個控制用的輸入是 0，不管 A20 是 0 或 1, 經過之後送到板子上的永遠為 0，而能用同樣的程式存取前面 64KB。
這個控制用的訊號要從哪邊來呢? IBM 「利用」了還有多餘接腳沒用到的鍵盤控制器，Intel 8042。送出一個特殊的命令給 8042，以控制這個輸出給 AND gate 的訊號。也就是說，8042 除了原本應該負責的鍵盤訊號處理，還多作了一個不屬於鍵盤控制器該作的事。
reference:
A20 - a pain from the past
A20 line From Wikipedia
The PS/2 Keyboard Interface 有 8042 的接腳參考
8042 Keyboard Controller (From IBM Technical Reference Manual)
2007年1月19日 星期五
2007年1月4日 星期四
Writing CGI scripts in Python
Python Wiki article about CGI
Web Python Tutorial @codepoint A simple yet easy to understand Python CGI tutorial
基本上用 Python 寫 CGI 不難，CGI 本來就是能 print 到 stdout 的東西都能寫。:D Python 的一些 Library Module 簡化了一些CGI 會碰到的問題，包括
Web Python Tutorial @codepoint A simple yet easy to understand Python CGI tutorial
基本上用 Python 寫 CGI 不難，CGI 本來就是能 print 到 stdout 的東西都能寫。:D Python 的一些 Library Module 簡化了一些CGI 會碰到的問題，包括
- fieldstorage: 直接把 html form 的值轉換成 dict.
- cgitb: trace cgi 程式時的有用資訊。cgi 程式沒有 console 和 terminal, 通常較難用試誤的方式找出問題。
- Cookie: 簡化處理 http cookie
2006年12月10日 星期日
大蟒真是不錯
最近斷斷續續用 Python 寫程式存取自己在 blogger 的文章，對 Python 有一些感想。
最早之前用 Python 是在某個營隊裡接觸到的。那時按時間來算，Python 也才剛出生沒幾年。這樣想起來電腦的東西進展實在是很快，身處其中有時光飛逝的感覺。但那時只是用它的 string/list 的 posh/pop 在體會 stack 和 queue 的概念。至於為什麼要用這種語言來實驗，我也不曉得。最大可能是當初有個愛摸新奇玩意的怪胎，覺得這東西很好用很適合拿來教程式概念，就用了。
這次認真邊翻參考文件邊寫程式，才發覺 Python 不是之前想像的那麼簡單。首先它的精髓就不是在那 list 或 interpreter 式的語言特性，而是更好用的 OO 。在直譯式語言裡使用 OO, 會比在 C++ 這種混種編譯式語言裡要來得方便，光是要debug 程式就簡單多了。再加上語法嚴格得多，用縮排表示程式層級的方式，比起 C 的超自由語法要來得好懂得多。不容易有那種程式可以執行，人卻看不懂的情況發生；或者因為自由語法使得bug藏污納垢(比方不小心在 if() 或是 for() 後面多了一個分號)。
常和 Python 拿來對比的就是 Perl 了。Perl 相對之下哲學完全不同。Python 可說是為了好讀而設計，寫出來的程式會很嚴謹很清楚。Perl 卻是為了好寫而設計，同樣的功能可以寫出很多種完全不同的語法，再加上一堆很難看懂的operators keyword, 要寫得亂七八糟看不懂也很容易。Perl 因此在快速開發，尤其是文字處理方面頗有口碑。但我就是不喜歡這樣。如果程式寫後即丟，Perl 是很好的選擇，但大多數情況不是這樣，程式會需要維護、修改，還會交接給別人。這種情形下寫出看不懂的程式，無疑是找自己和別人麻煩。
但在簡單的作業上，語言特性並不是最重要，重點在於是不是有夠豐富的標準函式庫，讓初學者很快上手，不用花時間作些苦工。在這一點上Python 發展得夠久了，所以算是很充足。如果是當初摸到 Python 時就一頭栽下去，應該會很累很有收穫吧。所以這一次寫 Blogger 程式，也是幾天就可以弄出一個能動的雛形。相信 Perl 在這一點也是毫不遜色，才能擁有廣大的使用者基礎。
最早之前用 Python 是在某個營隊裡接觸到的。那時按時間來算，Python 也才剛出生沒幾年。這樣想起來電腦的東西進展實在是很快，身處其中有時光飛逝的感覺。但那時只是用它的 string/list 的 posh/pop 在體會 stack 和 queue 的概念。至於為什麼要用這種語言來實驗，我也不曉得。最大可能是當初有個愛摸新奇玩意的怪胎，覺得這東西很好用很適合拿來教程式概念，就用了。
這次認真邊翻參考文件邊寫程式，才發覺 Python 不是之前想像的那麼簡單。首先它的精髓就不是在那 list 或 interpreter 式的語言特性，而是更好用的 OO 。在直譯式語言裡使用 OO, 會比在 C++ 這種混種編譯式語言裡要來得方便，光是要debug 程式就簡單多了。再加上語法嚴格得多，用縮排表示程式層級的方式，比起 C 的超自由語法要來得好懂得多。不容易有那種程式可以執行，人卻看不懂的情況發生；或者因為自由語法使得bug藏污納垢(比方不小心在 if() 或是 for() 後面多了一個分號)。
常和 Python 拿來對比的就是 Perl 了。Perl 相對之下哲學完全不同。Python 可說是為了好讀而設計，寫出來的程式會很嚴謹很清楚。Perl 卻是為了好寫而設計，同樣的功能可以寫出很多種完全不同的語法，再加上一堆很難看懂的operators keyword, 要寫得亂七八糟看不懂也很容易。Perl 因此在快速開發，尤其是文字處理方面頗有口碑。但我就是不喜歡這樣。如果程式寫後即丟，Perl 是很好的選擇，但大多數情況不是這樣，程式會需要維護、修改，還會交接給別人。這種情形下寫出看不懂的程式，無疑是找自己和別人麻煩。
但在簡單的作業上，語言特性並不是最重要，重點在於是不是有夠豐富的標準函式庫，讓初學者很快上手，不用花時間作些苦工。在這一點上Python 發展得夠久了，所以算是很充足。如果是當初摸到 Python 時就一頭栽下去，應該會很累很有收穫吧。所以這一次寫 Blogger 程式，也是幾天就可以弄出一個能動的雛形。相信 Perl 在這一點也是毫不遜色，才能擁有廣大的使用者基礎。
2006年10月12日 星期四
flawfinder and other automated program checker
Flawfinder is a software scanning source codes for known security issues of programming . Looks like that it uses pattern matching to find potential bugs.
Written in Python.
Spotted when reading this: Using Google Code Search to Find Security Bugs.
Written in Python.
Spotted when reading this: Using Google Code Search to Find Security Bugs.
2006年9月10日 星期日
mkdep
mkdep 可算是 make 的輔助工具。
通常，我們在 Makefile 裡寫下 source code 和產生出來的 binary code 的依存規則。當然也有不是 binary code 的場合，比方說用 Makefile 來產生 doxygen 或 latex 文件。原則是，有個 source -> target 的依存性。
mkdep 就我個人的看法，是比較特化給 C 語言用的。它接受原本給 cc 的 CFLAGS 和 SRCS 參數，藉由偷看 cc 的參數，找出 .c 檔和 .h 檔的相依性。它作了一部份 cpp parse 原始檔的前置指令的工作，但不多動原始檔，而是將用到的 header files 記錄在 .depend 裡，提供給 make 作為編譯程式時的額外參考。
source -> target 的相依性，是比較顯而易見的。有什麼樣的原始碼，就產生出什麼樣的 binary code。但對於 header files 來說就不那麼明顯。對於只用到系統一般提供函式庫的場合，header files 可能是永遠不會變的，因此不太需要考慮到這個問題。但如果是同時在修改 header files, 或是它會常常更新，那麼有個程式自動找出它的相依性，就很重要了。當 header files 改變時自動重新編譯，不僅僅是像 Makefile 一樣自動檢查相依性，以減少編譯的時間而已，也能減少因為 header files 版本不同，而遇到的奇奇怪怪問題。尤其是在抽象化得比較完整的 case, header files 可能是一層包一層，讓追問題更加困難。
有經驗寫過或用過 Makefile (也就是使用 'make' 這個指令)的人都知道，如果Makefile 裡的相依性規則沒有寫好，有時會遇到明明某個原始檔更新了，卻沒有重新編譯，以致於程式跑不出想要的結果。如果Makefile 裡有定義 clean: 或 distclean: 這類的 targets, 整個重新編譯過也許可以解決，但這會多花許多重複編譯的時間，而且你還是不知道問題是誰造成的。
同樣的問題發生在更隱誨不明的 header files 時，就更麻煩了。因為最明確的 #include 是寫在 .c 檔裡，不是 Makefile 。哪一天別的小組或是供應商更新了他們提供給你的函式庫 header files, 而沒有提醒你時，你就等著遇到各種奇奇怪怪的問題了。
因為這是在 header files 會更新時，才能顯現出它的好處，一般只是用現成函式庫開發程式，或是只編譯一次原始碼，產出程式來用，而不管程式到底寫什麼， 或到底需要改什麼的人來說，比較體會不到。但在同時修改函式庫或 header files 的人，能利用它就會很方便地減少許多問題和重複編譯的時間。所以現在能想到比較明顯的例子，就是在 FreeBSD 或 Linux 編譯 kernel 時。
FreeBSD 編譯 kernel 的標準用法，是 make depend all install。 Linux 是 make dep image 。這 depend 或 dep target, 就是在執行 mkdep 。當然後來它們的編譯步驟又被包裝得更容易，也許第一眼看不到這些 make 指令，但跟著Makefile 追蹤下去就會發現。
通常，我們在 Makefile 裡寫下 source code 和產生出來的 binary code 的依存規則。當然也有不是 binary code 的場合，比方說用 Makefile 來產生 doxygen 或 latex 文件。原則是，有個 source -> target 的依存性。
mkdep 就我個人的看法，是比較特化給 C 語言用的。它接受原本給 cc 的 CFLAGS 和 SRCS 參數，藉由偷看 cc 的參數，找出 .c 檔和 .h 檔的相依性。它作了一部份 cpp parse 原始檔的前置指令的工作，但不多動原始檔，而是將用到的 header files 記錄在 .depend 裡，提供給 make 作為編譯程式時的額外參考。
source -> target 的相依性，是比較顯而易見的。有什麼樣的原始碼，就產生出什麼樣的 binary code。但對於 header files 來說就不那麼明顯。對於只用到系統一般提供函式庫的場合，header files 可能是永遠不會變的，因此不太需要考慮到這個問題。但如果是同時在修改 header files, 或是它會常常更新，那麼有個程式自動找出它的相依性，就很重要了。當 header files 改變時自動重新編譯，不僅僅是像 Makefile 一樣自動檢查相依性，以減少編譯的時間而已，也能減少因為 header files 版本不同，而遇到的奇奇怪怪問題。尤其是在抽象化得比較完整的 case, header files 可能是一層包一層，讓追問題更加困難。
有經驗寫過或用過 Makefile (也就是使用 'make' 這個指令)的人都知道，如果Makefile 裡的相依性規則沒有寫好，有時會遇到明明某個原始檔更新了，卻沒有重新編譯，以致於程式跑不出想要的結果。如果Makefile 裡有定義 clean: 或 distclean: 這類的 targets, 整個重新編譯過也許可以解決，但這會多花許多重複編譯的時間，而且你還是不知道問題是誰造成的。
同樣的問題發生在更隱誨不明的 header files 時，就更麻煩了。因為最明確的 #include 是寫在 .c 檔裡，不是 Makefile 。哪一天別的小組或是供應商更新了他們提供給你的函式庫 header files, 而沒有提醒你時，你就等著遇到各種奇奇怪怪的問題了。
因為這是在 header files 會更新時，才能顯現出它的好處，一般只是用現成函式庫開發程式，或是只編譯一次原始碼，產出程式來用，而不管程式到底寫什麼， 或到底需要改什麼的人來說，比較體會不到。但在同時修改函式庫或 header files 的人，能利用它就會很方便地減少許多問題和重複編譯的時間。所以現在能想到比較明顯的例子，就是在 FreeBSD 或 Linux 編譯 kernel 時。
FreeBSD 編譯 kernel 的標準用法，是 make depend all install。 Linux 是 make dep image 。這 depend 或 dep target, 就是在執行 mkdep 。當然後來它們的編譯步驟又被包裝得更容易，也許第一眼看不到這些 make 指令，但跟著Makefile 追蹤下去就會發現。
2006年8月18日 星期五
Why Expensive Bugs Are Cheap to Fix - O'Reilly ONLamp Blog
bugs are easily made. Fixing them may be easy. The price of fixing bugs in a product may be expensive. NOT fixing bugs in products is certainly costs a lot, both to earningness and reputation.
Why Expensive Bugs Are Cheap to Fix - O'Reilly ONLamp Blog
Why Expensive Bugs Are Cheap to Fix - O'Reilly ONLamp Blog
2005年2月23日 星期三
Mr. Grimes’ Farewell
Richard is stepping down from his post of commenting on all things .NET. In his farewell address, he looks back at some missteps in the development of .NET and offers words of warning about the future of the platform.
From Dr.Dobb's Journal
訂閱：
文章 (Atom)