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