Graph Cut Image Segmentation with A Center ( Star Shape Prior )
在找某種 Tool 的過程中發現這個有趣的工具: Segmentation Graph Cut
它事實上是這篇 Paper 內容的實作:
Olga Veksler, "Star Shape Prior for Graph-Cut Image Segmentation," European Conference on Computer Vision, pp.454-467, 2008
雖然 Google Code 頁面上沒有明寫, 不過猜 Project Owner 就是作者本人. 因為 Tool 裡面包含的 Samples 跟 Paper 內容的範例圖都一樣, 同時如果你從 SVN 上 Check-out, 而不是只抓 Binary 的話, 會發現 Repository 裡面還有兩篇相關的 Paper PDF, 如果不是自己有版權, 應該不至於敢直接放到 Repository 裡面吧.
Anyway, 這篇 Paper 跟這個 Tool 的重點很單純, 就是要把所謂的 Star Shape 加到利用 Graph Cut 作 Image Segmentation 的方法中. 至於所謂的 Star Shape, 採用 Paper 中的定義:
A star shape is defined with respect to a center point c. An object has a star shape if for any point p inside the object, all points on the straight line between the center c and p also lie inside the object.
如果用圖來舉例解釋的話, 大概是像下面的 (a) 不管怎樣裡面的任一點都可以做為 Center C, (b) 只有部分的點可以做為 Center C, 因為有些點無法讓 P 的條件符合, (c) 不管哪裡都不存在 Center C 可以讓 P 的條件符合.
其中 (a) (b) 的情況都符合 Star Shape 的定義.
工具的 Binary Release 本身需要 Visual Studio 2008 的一些 Libraries, 我在 Windows 7 沒法安裝, 直接從 SVN 抓下來 SRC, 裡面有 C++ Code ( 尚不清楚實際用途 ) 跟作為 GUI 的 Python Code. 直接利用 GUI.py 執行極可.
請注意會需要 wxPython 跟 Psyco, 沒有的話會要安裝才能繼續執行.
工具目的單純所以容易操作. 載入圖片後利用滑鼠在圖片上指定 C 跟 P. 左鍵 Click 兩下會出現藍色點是 C, 一下的話會出現黃色點是 P.
我本來以為會以 P 作為切割邊線的決定條件的, 但看來不是這樣, 像上圖那樣標記, 最後還是會抓到整朵花 (右下的紅框是結果, 是我額外貼上去的, 工具本身是會呼叫你的看圖程式去開結果圖). 但是如果舉個極端一點的例子, 像是這樣:
基本上還是會割到 Boundary 為止, 我猜跟裡面用到的 Graph Cut 演算法有關. 不過我的 Image Processing 只有到基本的傅立葉程度 = = , 這個就沒法猜了.
當然 Title 寫 With A Center 是有理由的...
在一般的情況下, 只要標記上 C, 不用 P 也是可以抓到, 像是這樣:
而且運算時間算是蠻快的, 扣掉開啟看圖程式的時間, 可以直接把結果接到工具畫面輸出的話, 應該是幾乎到無感的程度吧.
很有趣, 改天有空再來從 Python GUI 研究看看是不是可以直接使用裡面的 Kernel Function, 接到別的程式上.
Know both Design Abstraction and Implementation Detail ever Resourceful
為了取這個標題, 還特地去查某句成語的英文一般都怎麼說 XD
昨天在處理實驗室 MoinMoin Wiki 出現的一個奇怪的問題. 某個特定頁面只要進行瀏覽, 就會導致 MoinMoin 整個 Crash, 一點 Process 也不留. 自然, 直覺就是該頁面內容有什麼奇怪的東西, 或是內容在磁碟上有毀損, 導致 MoinMoin 讀到該頁面內容就會出現 Exception 而掛掉.
但是在想要近一步去檢視該頁內容是, 猛然發現, 其實我不知道 MoinMoin 是怎樣處理 Page Data 的. 我既不知道 Page Data I/O 的部份在哪, 也不知道 Page Data 平常是保存在哪.
本來, 閉著眼睛也可以大概畫出一般 Wiki System 的 Architectural Design Abstraction, 主要的 Components 有哪些, 各自的責任也清楚. 但是單知道這些對我現在要解決問題幫助卻不是很大.
作為一個在唸 Ph.D. Program 的 Programmer, 這樣的事情真的是很不應該的, 但是還是發生了, 因此特別寫下這個標題--雖然別人看來可以摸不著頭緒--來警惕一下自己.
幸好簡單查一下 MoinMoin 的資料, 馬上就看到 MoinMoin 在 Data 的保存上十分簡單, 直接利用現成的 File System 作儲存而已. 這樣一來馬上補足了在 Data Repository 部份的一些細節, 也就一下子找到 Page Data.
MoinMoin 的 Page Data 存放在 /data/pages/ 中 ( 實驗室的資料比較敏感, 以下用電機系網路服務使用手冊 Wiki 作例子 ),
每個頁面直接用 Relative Page Path 作為 Directory Name, 其中 "/" 以及 "-" 之類的就用特殊符號取代, 像是 (2f) 跟 (2d).
在每個頁面的 Directory 之下, 有幾個主要的檔案跟資料夾, 名稱一看就很清楚, 不一一加註, 只舉頁面內容來說, current 檔案紀錄目前的版本, 而 revisions 資料夾裡面存有所有的歷史頁面資料. 因此實際的頁面資料是存在 revisions 資料夾裡的, 把每個頁面 cat 出來就很清楚了.
從這點也可以看出來, 其實大量頻繁的網頁修改, 在 MoinMoin 系統中是很吃硬碟資源的.
知道 MoinMoin 資料存放的細節後就更有趣了.
目前手上有些給實驗室用的小東西, 過去不是很清楚要怎樣把其輸出直接送到實驗室的 MoinMoin Wiki, 這樣一來其實可以直接在 File System Level 作手腳. 繞過 MoinMoin 本身, 直接輸出到 Data Repository 中, 只要內容格式符合 MoinMoin 語法, 跟 Revision History 等 Meta-data 有正確的填寫, 就能夠被 MoinMoin 讀取, 出現在 Wiki 頁面系統上了.
Know both Design Abstraction and Implementation Detail ever Resourceful.
我要把這句印出來貼在座位旁 :p
How Matplotlib and NetworkX Work Together : A Case Study on Figure Instances
最初是因為以下的 Code 讓我對這個問題有興趣. 這段簡單的程式碼 Matplotlib 以及 NetworkX 來合作畫圖. 其中 NetworkX 負責 Graph Model 的建立, 而 Matplotlib 則負責 Figure 繪圖的部份.
最後繪出的圖, 如同程式碼所指定的位置, 畫出三個圓點.
而我覺得程式碼有趣的地方在於, 細看程式碼, matplotlib.pyplot 只有在 line 6, 以及 line 20 被使用, 期間 line 9 到 line 18 都是 networkx 的運作.
而, 在此 Script 中, networkx 跟 matplotlib.pyplot 表面上是沒有任何互動的, 沒有任何 Message Passing 或是 Object Communication 出現. 如果單單依照此 Script 中的 Program Logic 作 Program Slicing, 或許就會被乾脆地切成兩個 Program Slices 了.
不過想當然爾, 既然最後可以順利地畫出圖來, 這兩部份的程式碼肯定在背後有進行某種 Communication, 否則不可能在 networkx 中建好 Graph Model, 在 matplotlib.pyplot 中就知道要畫出甚麼樣的 Figure.
經過漫長的 Code Tracing, 大致上可以把 Dependency Graph 整理如下圖 :
其中比較關鍵的是 Matplotlib 在 Figure Management 上, 允許同時間有數個 Figure Instances 存在, 而目前要畫在哪個 Figure Instance 上, 則視乎目前哪個 Figure 被設定為 Activated.
在 plt.figure() 中 ( 事實上為 matplotlib.pyplot.figure() ), 可以透過參數 num ( 可參考 Online Document, 即 Figure Instance Identity ) 指定要 activate 那一個 Figure Instance, 如果 Instance 不存在, 則會產生一個新的 Instance.
而在綠色的流程中 ( 即程式碼 line 9 到 line 18 ), networkx 在 nx.draw_networkx_nodes 進行中會透過 matplotlib.pylab.gca 取得目前為 Activated 的 Figure Instance 其 ax object ( 座標軸物件 ), 之後透過 ax 把要畫出來的 nodes 加進去.
最後 plt.show() 透過 matplotlib.backend_gtk 把圖畫出來.
這 Matplotlib 中的 Figure Instance 取用機制大體上是為什麼原本的 Code Script 中, 在乍看之下 networkx 跟 matplotlib.pyplot 沒有 Communication, 但是還是可以把圖畫出來的主要原因.
Operating NS3 with Python
最近可能會要很奇怪地使用 NS2 來作一些 Simulation, 雖然還不是很確定需不需要使用, 最近趁空未雨綢繆一下.
但, 說真的 NS2 雖然大量地被 Network Research 人員使用, 也有很多已高度開發的模組, 但是一來我需要的使用方式其實不是模擬傳統的 Network, 二來不熟悉的大量程式碼真是看不下去. 所以其實我早早就把目標鎖定在 NS3.
NS3 的基本中文介紹在 morechr 的 blog 很早就寫了, 不過一年半來中文的資料也沒增加多少, 想來 NS2 就足夠現在的研究人員使用了吧, 況且 NS3 的重點擺在完全地利用 Script 來操控, 許多需要利用到 Pointer 的模組應該短時間內也很難轉移. NS3 架構概圖 ( 取自 NS3 Official Site ) :
但是對我來說, NS3 看起來似乎比 NS2 易用多了. 主要的操作介面已經提供 Python Binding, 也有實驗性的 PyViz 模組. 光是安裝時一個 $> python build.py 就感覺很爽快 : p
在 Tutorial 上, 我覺得 NS3 官方的 Tutorials 跟 Overview 投影片都很難讓我這初次接觸的人看懂, 倒是 G. Carneiro 的這份投影片(PDF 檔案) 我覺得做的不錯, 搭配 NS3 的 example/tutorial/first.py 程式碼, 一下子就可以了解個大概.
PyViz 模組最近的 ChangeLog 看的不是很明白, 照 changeset 5973 的訊息, 應該是已經 merge 到 NS 3.7.1 了才是. 但是實際下載 NS 3.7.1 看起來是沒有包含 PyViz 的, 所以或許他的意思是在 http://code.nsnam.org/gjc/ns-3.7-pyviz/ 底下 merge 了 NS 3.7.1 , 一番嘗試最後還是使用 Mercurial 複製了一份 http://code.nsnam.org/gjc/ns-3.7-pyviz/ 下來. ( 請跟 ns-allinone 分開 )
在 PyViz 的網站說明中, 提到要再跟最新的 NS3 作 merge 的動作. 不過因為 clone 下來的 ns-3.7-pyviz 已經被開發人員進行過 merge 了, 就不需要再做一次.
使用 PyViz 還需要額外安裝許多模組, 除了基本的 Graphviz 之外, 還有 PyViz 頁面中提到的 pygraphviz, kiwi ... 等等. Ubuntu 的使用者安裝似乎比較方便, 可憐的 Mandriva 使用者 ( 而且還是 MDV 2008 = = ) 就直接乖乖自己安裝吧.
其中
- pygraphviz 可以利用 easy_install 從 pypi 安裝,
- python-kiwi 直接從 Package Manager 找出來裝 ( 不要直接找 Kiwi 來裝, 不一樣的東西 <= 犯錯的笨蛋 ), python-kiwi / Kiwi framework 是連接 GTK+ 的套件
- PyGoocanvas 也沒辦法從 pypi 安裝, 但是手動安裝要補充的套件太多, 相當麻煩, 最後我選擇從 MDV Package Manager 裝比較舊版本 0.9.0 的套件 ( 目前最新為 0.14 ), 反正這是 GTK+ 跟 GooCanvas 的 Binding Package, 從 Package Manager 裝可能還比較安全
- python-gnome2 也是從 Package Manager 裝, 但是在 MDV 裡面似乎是叫做 gnome-python 套件
- python-gnomedesktop 我猜測是等同於 MDV 裡的 gnome-python-desktop 套件
- python-rsvg 在 MDV 底下真的找不到東西裝了, 猜測是裝在 pycairo 裡, 這之前透過 Package Manager 裝過了
- 最後記得到 pybindgen 抓取 1.14.0 版本 ( ns-3.7-pyviz 需求 ), 解壓縮到 ns-3.7-pyviz 底下
接著在 ns-3.7-pyviz 底下執行 :
$> ./waf configure --with-pybindgen=./pybindgen-1.14.0
$> ./waf --pyrun examples/flowmon/wifi-olsr-flowmon.py
首次執行因為要重新 build 整個 ns-3.7-pyviz 所以要跑一段時間. 最後還是出現幾個小問題,
- 缺少 libgraphviz.so.4 , 因為我的 MDV 2008 裡面只有裝 libgraphviz3 , 所以又更新了 libgraphviz4 .
- 找不到 gnomedesktop module, 此模組不知道為什麼被藏在 gnome-python-applet 套件裡, 同樣從 Package Manager 裝上
再重新跑一次:
$> ./waf --pyrun examples/flowmon/wifi-olsr-flowmon.py
這樣一番折騰 ( 所謂的 Dependency Hell 阿 ) 終於把 PyViz 跑起來了.
左下角有一個 Advanced 延伸調整選單可以展開, 右下角有 Snapshot, Shell, 以及 Simulate 命令. Snaphot 可以擷取目前截圖存成 PDF 檔案, Shell 可以開啟動態 Manipulation Command Line, 在 PyViz 的說明中有提到. Simulate 就是開始進行 Simulation 的命令.
以下是進行中的畫面, 懶得錄下來放到 Youtube, 截圖就好 XD
可以調整 Zoom 以及速度, 方便檢視 Simulation 可能出錯的地方.
初步的嘗試大概到此為止, 花了不少時間跟功夫, 不過至少有成功執行. 通常這樣的嘗試超過一半的機會最後是不了了之的 : p
利用 Twiddla 遠距討論 Design Diagram
Twiddla 是一個免費的電子白板服務, 之前為了跟在美國的學長討論 Paper 上的 Architecture 圖, 其實在 Survey 時有注意到, 但是當時以為只是普通的畫圖用電子白板, 鑑於畫起 Design Diagram 實在太累, 加上動作過快會讓網頁上的 JavaScript 陷入暴走狀態, 把整個 Browser 鎖死, 因此後來沒考慮使用 Twiddla.
今天看到 Library Views 圖書館觀點 的一篇介紹文章, 才發現原來 Twiddla 可以開啟特定的網頁網址, 在上面進行文字或畫圖註解討論. 這樣一來問題就好處理多了, 可以先把要討論的 Design Diagram 放到一個可以取用的 Web Server 下, 然後再利用 Twiddla 去開該檔案的網址, 就可以當作底圖進行討論, 畫註解等等.
在技術面上, Twiddla 有利用 Scribd 的 iPaper 的服務, 把許多不同的檔案格式轉成 Flash, 因此可能可以直接開啟, 然後在上面討論. 嘗試了幾個不同的常用 File Format, 像是 Python Source Code 會被當作普通的純文字檔轉成 Flash, Block 會亂掉, 沒辦法好好看 Code. 而 PDF File 可以開, 但是非常 lag, 相對來說 OpenOffice 檔案倒是還好.
這樣 Twiddla 加上 SkyPe 以及各種 IM Software, 基本上就可以是窮人版的 Web Meeting Solution 摟 :)
Borland's New Tools : TeamDemand, TeamFocus, and TeamAnalytics, to Make SDP More Transparent
Borland 今天正式公佈了三個預計於秋季釋出( release ? 販售吧 :p )的新工具. 詳細情況可以參考 Computer World 的這篇新聞 : Borland adds tools aimed at making application development more transparent.
三個 Tools 分別為 :
- TeamDemand : 這個是三個 Tools 裡我覺得最沒想到的. 企圖把 User Requirements 連結到 Development Tasks 以及 Development Process, 想要提供 Business Users ( Customers ) 一個可以即時 ( Real-time ) 獲知目前進度的溝通管道. 我認為這要做得到其實不難, 但要做的好不容易. 簡單的來說, 能夠讓 User 根據 Requirement 隨時輸入 Test Cases 其實就成功一半了, 接下來只要自動找到相對的進度作 Testing 就是另一半, 不過這之間都還隱藏許多問題.
- TeamFocus : 看來應該是用來連結 Developers 使用的 Tools, 彙整相關的 Information, 產生開發過程中的相關 Reports. 預計可以大幅降低 Developers 需要花時間在整理 Intermediate Report 的時間.
- TeamAnalytics : 根據 Project 內部可以獲得的各種 Information, 結合在特定 Domain 下適用的不同 Metrics 組合, 量測出 Project 目前的狀態, 對於不佳的情況可以事先給予 Warning. 尚不知內部怎樣管理 Metrics,不過如果是用類似 GQM 方法的話, 應該可以想像 Goal 沒有達到預期就是一種 Warning 了.
Borland 真是 IDE 界的巨人阿~~
PositLog : 隨意擺放內容的網頁製作系統
PositLog 有別於一般 CMS 系統的地方在於, 他把所有內容, 可能是文字或是圖片, 或是自己隨手亂畫的東西, 都放在網頁上包成一個一個的物件, 使得你可以任意拖拉放置到任何一個位置. 相對於重視版模設計跟 Widget 安插的其他 CMS 系統, PositLog 更加強調利用對於內容的置放來展現個人的風格.
在頁面的右下角, PositLog 提供了一個縮小的 Page Map Overview 以及可以用來調整 Scale 的 ScrollBar, 類似 Google Map 之類的 Ajax 程式也常出現之類的工具.
Page Map Overview 對於 PositLog 來說這是一個必要的設計, 因為在 PositLog 的哲學之下, 個人的網頁內容可能不若一般的網頁來的有閱讀的規則性, 這時候 Page Map Overview 可以讓訪客有一目了然的感覺, 降低整個網頁的複雜感.
ScrollBar 可以用來調整網頁的大小, 這對於希望在瀏覽時動態放大局部的訪客來說應該是很便利的功能.
PositLog 的安裝非常簡單, 下載之後在 document 資料夾內有非常詳細的說明. 在系統需求上, PositLog 只需要
- Web Hosting Server, 例如 Apache.
- Perl 5.8+, 一般的系統應該都很容易安裝, 或是已經有內建了
如果懶得裝想直接試試看, 也可以直接在 PositLog 主網頁右下角找到 SandBox 連結. 目前提供 Rich 模式, Simple 模式, 以及測試中的 Wiki 模式. 以 Rich 模式為例, 可以很容易的選擇任何一個物件進行拖曳 (Drag) 移動以及編輯, 同時上方的 toolbar 也可以用來改變這個物件的一些 attributes.
雖然不能說 PositLog 是全新的想法, 而是把過去的兩項很多人想要的 features ( 內容隨意擺置以及簡易放大縮小 ) 結合起來作為主打, 但是的確過去市面上也少見類似的產品. 在這兩項 features 之上, 將有可能發展出許多有趣的應用.
舉例來說, 有許就會有人利用 PositLog 做出一個網頁版的 FreeMind. 利用 FreeMind 製作 MindMap 的缺點在於幾乎只能編寫文字, 同時當整個 MindMap 很大時, 無法快速的看到 Map 全貌, 無法放大縮小 MindMap 等等. 商業化的 MindMap 製作工具對於這些缺點有比較好的改進, 但是仍不夠自由. 試想想如果利用 PositLog 做出網頁版的 MindMap 工具, 對於以上的問題會有比較好的解決, 同時還能夠較為方便地進行多人編輯.
期待在不久的將來就可以看到很多基於 PositLog 衍生出的 OSS 計畫 :)
The Commentator : Personalized Comment Decorator
Cenqua : The Commentator 是一個有趣的想法, 但是看他說明的時候請注意到網頁最下方, 有一行小小的字寫著 : "Promotion running only for April 1".
先假設有這樣的一個 tool 好了, 根據網頁上的文宣, 其實 The Commentator 主打的並非 automatic commentating, 而是 personalized automatic commentating. 在加上 comment 時, 是可以根據你個人的 commentating 習慣, 來產生 "看起來" 是你手動打出的 comments.
換句話說, 其實 The Commentator 是一個 Personalized Comment Decorator, 其前端還需要具有一個 Comment Add-on Suggester 來找出在程式碼的哪個部份會需要加上何種 comments, 形成一個 unified comments, 然後再利用 Personalized Comment Decorator 來對於該 comment 加上潤飾. 而 Personalized Comment Decorator 的潤飾其實是一種 view 的轉換.
Cenqua : The Commentator 並不全然是不可行的, 甚至在 code generation tool 越來越多, programming phase 正在邁向 fully automation 的同時, 這樣的 commentating tool 或許會變成在 maintenance phase 相當關鍵的產品也說不定.
SmartSVN and SVNKit ( JavaSVN )
今天因為學弟的 TortoiseSVN 在 Windows 上遇到了 Windows 千奇百怪錯誤訊息 之一的 "沒有錯誤發生" ( "No Error Occurred" ) 訊息, 不管怎麼處理移除重新安裝都無法使用, 我就幫忙找了是否有其他的 Subversion Client 軟體.
之前在 Windows 上用 TortoiseSVN, 在 Mandriva 下直接用 command line 都習慣了, 也就沒有想到去找其他的 Subversion Client Software 試用. 結果一找發現其實還不少, 只是都不如 TortoiseSVN 成熟以及容易使用, 只有幾個例外, 像是 eSVN 以及 SmartSVN. 因為學弟要在 Windows 上用, SmartSVN 採用 Java 開發, 安裝上會比較容易, 因此最後是採用 SmartSVN.
SmartSVN 分為 Foundation version, Professional version, 以及 Enterprise version. 在他的 downloads 可以下載的安裝檔案內其實就包含了 Foundation version 以及 Professional version, 但是 Professional version 的使用有限制時間的樣子, 而且需要向 SmartSVN 要求免費的 evaluation license. 如果只是一般的 svn check out, import, add, update 等等動作, Foundation 版本就足夠了.
SmartSVN 採用 SVNKit (JavaSVN) 作為 SVN library, 可以在 SVNKit 網頁下方看到使用 SVNKit 的相關計畫還真是不少, 除了 SmartSVN 還有需多著名的 IDE 也都有採用. 實驗室有些小計畫事實上跟 version control 多少有點關係, 之前好像都是透過 PySVN 處理, 有機會應該比較一下兩者的差異.
可以看到 SmartSVN 的畫面設計很簡潔清楚, 所有目前 working directory 的檔案會被列出來, 可以跟 TortoiseSVN 一樣直接對於檔案作各種 svn 動作處理. 同時 working directory 內的所有變動都會即時反應在檔案列表上. 檔案列表的各項欄位也很清楚地告訴你該檔案目前的狀態.
左下角是前幾次的動作歷史紀錄, 剛剛作過的所有動作都一目了然. 右下角是 Transaction 資訊,
會以每一次的 commit 為單位紀錄 transactions, 並且把過去的 transactions 都列出.
Transactions 的紀錄可以利用上面 toolbar 的 Transaction 項目進行整理, 分為 Raw, Week, Calendar, Author, 等方式, 更容易找到紀錄.
同時也提供對於檔案的 base - working copy 比較功能, 但是針對不同語言的程式碼似乎沒有 syntax highlight coloring 是比較可惜的一點.
SmartSVN 的其他進階好用功能都要在 Professional 本版以上才支援, 像是可以把版本變化作圖形化呈現的 Revision Tree 功能, 以及比起 TortoiseSVN 要強上許多的 Conflict Solver 功能, 甚至是可以知道特定檔案目前在其他 local copy 狀態的 Remote State 功能. 這些功能的基本說明跟圖示可以在 SmartSVN whitepaper 文件內看到.
Conflict Solver 所使用的 Three-Way-Merge 看起來應該是引入一個仲裁者的角色, 先將引起 Conflict 的兩端對於特定檔案的改變都 merge 在一起, 然後仲裁者 (也就是使用者) 利用比較視窗決定應該怎樣處理, 然後利用 SmartSVN 的簡易編輯器立即處理 Conflict.
Remote State 則是一個相當有趣的想法, 之前在其他的 version control tools 上好像沒有看到類似的想法. Remote State 讓使用者團隊在問題即將發生之前, 就藉由讓團隊成員看到文件的目前狀態, 以避免成員之間出現因為不知道彼此在作的動作而產生 Conflict. 這個想法搭配一些 project management tool 以及 instance message software 應該可以在 software implementation 以及 maintenance 階段產生更有效率的合作.
Python-based Parser Generator & ANTLR Python
前一陣子有需要利用 Parser Generator 產生 Python-based Parser,
用來 parsing Java source, 因此就做了一點 survey.
不過出乎意料的, 找不到幾個好用的工具, 大致上 Python Parser SIG [1]
裡列出的都嘗試過了, 有些雖然可以用, 但是沒有人寫好 Java grammer,
要自己寫實在有點麻煩. 有些則是看起來不錯, 也有 Java grammer, 但是卻
無法成功使用, 例如 PyBison [2].
附帶一提如果有人想嘗試 PyBison 的話, 記得裝 PyBison 時要先裝 :
sudo apt-get install python-dev
sudo apt-get install build-essential
最後我是採用有名的 ANTLR [3], 它的 Python Interface 雖然還在發展中,
但是勉強是可以用了, 小 bug 自己改一下就好.
我使用的流程如下, 提供參考(以 MS 環境為例) :
1. 首先到官方網站下載 ANTLR 3, URL : http://www.antlr.org/
2. 解壓縮到特定資料夾, 例如 C:\antlr-3.0\
3. 設定 CLASSPATH, 讓 C:\antlr-3.0\lib\ 底下的所有 .jar 檔案都在
CLASSPATH 設定內, 可以參考這裡的說明進行 :
http://www.antlr.org/wiki/pages/viewpage.action?pageId=728
4. 到 C:\antlr-3.0\runtime\Python 底下進行 python runtime 安裝, 請參考 :
http://www.antlr.org/wiki/display/ANTLR3/Python+runtime
5. 到 ANTLR 網站上下載 Java grammer file :
http://www.antlr.org/grammar/list
嘗試產生 Python-based Java parser, 請參考 :
http://www.antlr.org/wiki/display/ANTLR3/Antlr3PythonTarget
6. 上述網頁上的 Java 1.5 grammer files 有很多個, 如果是使用 Terence Parr
的 grammer file (我是用這個), 則需要對於產生出來的 JavaLexer.py 以及
JavaParser.py 作一點修改. 此修改為在按照上面網頁執行 parsing 的過程中,
會出現語法上的錯誤, 請把錯誤的部分, 從 Java 語法改為 Python 語法即可.
如果有需要對產生的 Parser 作修改的話, 可以參考 ANTLR Python API Doc. :
http://www.antlr.org/api/Python/index.html
References
[1] Python Parser SIG, URL : http://wiki.python.org/moin/LanguageParsing
[2] PyBison, URL : http://wiki.python.org/moin/PyBison
[3] ANTLR Python, URL : http://www.antlr.org/
Floor Planner
看到一個好玩的網站 : FloorPlanner , 可以用來幫你規劃家裡的各樓層擺設, 有商業版軟體, 但是也可以註冊他的免費帳號, 可以試用線上版 (使用 Flash 製作). 註冊只要使用 emial 帳號跟設一個自己的密碼, 門檻很低.
進去後可以 create 自己的一個新的 project, 或是開啟別人的來看, 結果我開了其中一個名為 container 的規劃圖, 共兩個樓層 :
而且他也把 tag system 用在分類大家的規劃圖, 所以使用線上系統的人, 就可以共同快速地分享自己不同空間的設計.
使用設計上相當直覺, 以 Drag&Drop 為操作基礎, 分為三個控制 menu, 一個是 (1) 新增房間, 門, 窗, 註解等等 global constructs 的 menu, 一個是 (2) 新增各種家俱的 library menu, 下拉式選單內有各種 library, 另外一個是 (4) navigation menu, 就是左移右移放大縮小啦, 另外 (3) 的編輯部分也是很容易操作, 直接用滑鼠拉空間範圍, 換顏色等等, 搭配 library menu, 很快就能作出很漂亮的設計.
以 Software Product 的角度來看, 真是一個很吸引人使用的 Software :)
CVSGrab
看名字就知道 CVSGrab 是用來抓取 CVS 資料用的. 不過 CVSGrab 並非一般利用 pserver 與 CVS server 作 communication 的 CVS client, 而是透過 CVS web interface, 去讀取 CSV server 內的資料.
之所以這樣做是因為, 往往要 access 某個 project 的 CVS server 時, 卻發現被網路上的某個 firewall 擋住了 pserver, 不見得是刻意檔的, 可能是公司只有開放 http port 之類的, 因此就無法利用走 pserver protocol 的 CVS client 去讀取 CVS 資料. 而 CVSGrab 利用 http, 透過各種 CVS web interface (例如 ViewCVS or CVSWeb, ViewCVS 現在叫 ViewVC 了, 因為也支援 SVN 了 ) 去抓取 CSV 上的資料, 來解決這樣的問題.
不過這樣的話, 我倒覺得名字應該叫做 WebCVSGrab 或是 CVSWebGrab 比較適切 :p