1/07/2008

ludy 0.0.9 released

其實後來的更新幾乎都是亂寫了,這次的更新也差不了太多。大抵上就是增加個 C++ TR1 style 的 bind... 用起來的味道大概是這樣:(如果熟 C++ TR1/boost bind 的話,一眼就知道了)

assert_equal [9,8,7], ([1,2,3].map &(lambda{|lhs, rhs| lhs-rhs}.bind 10, :_1))
assert_equal [3,2,1], (lambda{|a,b,c| [a,b,c]}.bind :_3, :_2, :_1)[1,2,3]
assert_equal [1,9,3], (lambda{|a,b,c| [a,b,c]}.bind :_1, 9, :_3)[1,2,3]
assert_equal [9,2,3], (lambda{|a,b,c| [a,b,c]}.bind 9)[2,3]
assert_equal [9,4,2], (lambda{|a,b,c| [a,b,c]}.bind 9, :_3)[2,3,4]

不過我總覺得 ludy 應該可以繼續走下去才對。所以我想在下次做一次 major update, 版本號大概就是 0.1.0 吧。會做的改變大概如下:

1. 整理 project directory structure, 現在根本就是亂七八糟。我想大概會用 gem bones 去做吧。其實我是比較 prefer hoe, 但是 bones 的 rake task 有 namespace 比較漂亮... 如果 hoe 會更新到使用 namespace 的話,我再 switch 過去。現階段,我想 bones 是個不錯的選擇。

使用這種東西的好處,當然就是不用去設計 directory structure... 而且自己寫 gemspec 老實說也真的是滿麻煩的,bones 和 hoe 都有 rake task 幫我 build gem 檔,甚至還有 publish, 多方便。

2. 思索 puzzle_generator 的未來。其實他跟 ludy 一點關係都沒有,只是我為了使用 svn server 所以才把他加到 ludy 上的。到底 puzzle_generator 應該分出來,還是在 ludy 中找到一個位子?分出來的話,又該分去哪裡?

3. ruby 1.9 compatibility, 我剛剛稍微測試了一下,有幾個比較髒的東西在 ruby 1.9 是跑不起來的。這個應該要想辦法修掉,ruby 1.9 很棒的。除了效能好很多以外,多了很多我想要很久的功能,能早點轉過去就早點。可惜的是 1.9 問題還很多,而且很多 gem 沒辦法在上面跑,所以 1.8 還是必備的。現階段會讓 1.8 和 1.9 都相容,等 1.9 夠穩了,就不會考慮支援 1.8 了。

4. require path 的麻煩問題。去看看 facets, 他們對於 require path 大概也很頭痛吧。從 2.0.0 就整個把 require path 翻修過,結果還有大 bug, 害我完全沒辦法用。果然很快就推出 2.0.1 了...。還是 2.0.1 ~ 2.0.2 的階段,我忘了。反正就是很可笑的狀況,名稱衝突之類的。bug 期間我是暫時 monkey patch.

再看看 rubygems, 一開始有個 require_gem. 而我,卻也弄了個 require_ludy. 沒辦法,因為很難寫一個在任何情況下都有效的 require, 所以才搞出那種東西。但是現在我覺得,還是應該多為 user 想想,畢竟連 rubygems 都捨棄 require_gem, 我也不該繼續使用 require_ludy 才對。

無奈這真的是個很大的問題,可能勢必得做得不要那麼 general 吧?大致問題如下:
a. 使用 gem install 時可以正常 require.
b. 把東西全部 copy 到 project path 時, 讓 -I 可以 work.

其實簡單地說,就是希望不要 gem install 也可以輕鬆放到專案中使用。不過也許得放棄這個要求吧?因為實際在寫時,就會發現很多問題都跟這有關。如果能「假設」gem 一定有安裝起來的話,很多考量就可以不用做了。

事實上,不需要安裝 gem 也能 work, 對於開發也很有用。因為我可以改改程式就測試最新的結果,而不必自己裝一份。所以,還是再看看吧。還是希望能有好方法。

5. unit testing. 既然是 unit testing, 當然就要有能夠分開 test 的動作。我希望可以 ruby test/tc_bind.rb, 也可以 rake test 測試所有的 unit test. 之前因為沒在用 rake, 我自己寫了個 ts_ludy.rb, 大概就是做這件事。所以 ruby test/ts_ludy.rb 就可以跑所有的測試。

而我發現,如果照 unit test 原先的設計,把所有東西都 require 起來再跑,執行效能會變得很爛很爛。原因我不是很清楚... 所以後來我改變作法,變成一個個去跑每個 unit test, 然後把輸出結果蒐集起來,再報告出去。這樣的好處就是跑得速度真的快太多了,好幾倍的差別。缺點當然就是,這樣做挺詭異的...

所以關於 testing 的部份,也還需要再整理一下。大致就是希望能單獨跑也能一起跑。另一方面,我要求 testing 所使用的 lib 應該要是相對路徑下的,而不是 gem 上的。理由同 require path 上面的描述。

其實對於 require path 和 unit testing 的部份,我花了不少功夫,不過成果其實還滿差的。當時看是沒什麼感覺,現在看覺得實在很醜。

6. 去掉 shebang, 那很蠢。(那時候對 shell 太不熟了)

7. ludy_ext.rb
這東西,本來是想放各個沒在 Ludy module 下的東西,不過這樣成長太噁心了。應該學學 facets, 一個 method 一個檔才對。所以這部份也要切開,整理一下。

8. 整合之前為了 shooting-cubes 做的一些 rake task, 還有 erb meta-programming 的一些相關 method. 這個,和 puzzle_generator 一樣好像有點尷尬,不太屬於 ludy 的範疇。
不過在整個 ludy 東西還很少的狀況下,我希望盡量整合一些 lib.

9. 儘快整合 multi, 那個 multi-method 的 lib. 我在想,我可能自己實作一份,就不要直接把他吃進來。multi 是 MIT license, 我想我直接吃進來應該沒問題,只是整個感覺就很怪,而且他的程式有些部份我不太滿意,所以也許我自己做一份還是比較好,這樣也不用想怎麼合併。

如果確實做出來了,那大概就只留一份 NOTICE 或感謝之類的,就不保留原本的 require path 了。不然,我真的覺得那樣很醜,像是分裂的個體似的。

10. 修改一些文字說明,包含 README, CHANGES, description 之類的。現在的格式已經有點接近亂寫了。另一方面,也希望稍微修改一下 rubyforge 上的 release 結構。

11. 撰寫 rdoc, 完全沒 doc 其實也有點奇怪...

*

所有的 source code 都採用 Apache License 2.0, 希望下次的更新可以涵蓋以上幾點。

btw, bind 實作只有 13 行(含註解)

安裝:
gem install ludy

取得所有程式:
svn checkout http://ludy.rubyforge.org/svn/
or
svk mirror http://ludy.rubyforge.org/svn/ //mirror/ludy

沒有留言: