那 ng-value 呢？

#9 楼 @dongqs 是的可以调整去掉一部分，例如这样：

def nums n, sum, lb, ub
  if n * ub < sum or n * lb > sum
    return
  end

  if n == 1
    return [sum]
  end

  # edge sum, we have (1/2)**(n-1) chance to continue
  if n * ub == sum or n * lb == sum
    return if rand(2) == 0
  end

  loop do
    x = rand lb..ub
    res = nums n - 1, sum - x, lb, ub
    if res
      return res << x
    end
  end
end

Dynamic Programming

def nums n, sum, lb, ub
  if n * ub < sum or n * lb > sum
    return
  end
  if n == 1
    return [sum]
  end
  loop do
    x = rand lb..ub
    res = nums n - 1, sum - x, lb, ub
    if res
      return res << x
    end
  end
end

nums 10, 80, 4, 13

#19 楼 @rasefon 对啊，这不是一个功能的另一种写法，而是增加了一个新功能，而且可以替代掉常见的不好的做法

注：别看译文

#17 楼 @rasefon 这个不是语法糖，而且背后的算法不一样，比 sort 然后 take 的执行效率高

rails installer 有 ruby-2.1.5 的了

#14 楼 @lmorenbit news 很详细了 https://github.com/ruby/ruby/blob/v2_2_0/NEWS

#12 楼 @bhuztez 现在几乎都不用 32 位机器了，看 64 位的结果啊 http://benchmarksgame.alioth.debian.org/u64/compare.php?lang=yarv&lang2=php 而且那个 pidigits 的 Ruby 实现本来就有很大问题。而且类似这些 benchmark 的循环套循环代码在做网站中不还都是用 C 库搞的...

#10 楼 @bhuztez 你看的是哪个？我来告诉你什么回事

#7 楼 @bhuztez 寄存器机那个是先把 call 参数准备好，放到连续的寄存器里，指令指定第一个参数的寄存器号，有几个参数，然后执行的时候把参数拷贝到 stack frame 中去，和栈机把参数压栈，然后执行的时候移动一下参数没有什么本质不同。寄存器机那个参数也和压栈一样需要顺序连续放置，需要一些 mov 指令调整，而且 mov 指令还要加个寄存器号比 push 命令多一个操作数。

最终出来的寄存器机 stack frame layout 和栈机没什么不同

#5 楼 @bhuztez -_- zend 运行时就是个呵呵吧... register 机在函数调用上还是得和 stack 机一样压栈，所以很多地方区别也没这么大。register 机字节码必然比 stack 机占空间多是公认的经验，因为很多连续运算的"中间数", 就是和栈高度吻合的，其中的 push/pop 指令会少很多，然后字节码占空间就大幅减小了。register 机设计得比较好可以只多 25% 左右，如果你有设计巧妙的 register 机指令集使得字节码可以小到和栈机差不多，求共享。

利用 OOO 是 LuaJIT 的解释器的汇编实现里有考虑减少指令之间的 bubble 的考虑 (还有先 decode 下条指令再 jump 也是这个目的)

最近这个站的广告文略多啊

推荐一本书，在 google 流行之前就把大部分搜索引擎的问题讲好了：

Managing gigabytes- compressing and indexing documents and images 1999

关于 tokenize, 可以考虑下这些正则字符组：

\p{Word} unicode 中可以构成成词的字符，不限于 a-z0-9 \p{Space} 匹配各种奇葩空格字符

由于一个英文词词经常有 endash 和非 endash 的构成方式，所以在分词之前要考虑 "fourty-four" 和 "fourtyfour" 的等价性不要一下子都把 "-" 去掉了

字符串预处理也有很多要注意的，以下几个 Ruby 方法可以简化很多处理：

• String#scrub 去掉 unicode 中不合法的字符
• String#unicode_normalize 把组合字变成单一字符
• Kconv.kconv string, 'utf-8'.freeze 把半角 kana 转换成全角 kana (在古远的时代，为了让日文字符和英文字符可以用等宽字体排版显示，就出现了半角 kana 这种东西，但现在已经不推荐使用了)

另外在不同语言中，downcase 也有细微区别，最好按照当前 locale 处理 downcase

UnicodeUtils.downcase string, I18n.locale

unicode_normalize 是解决各种 accent 的不同编码方式造成的混乱的，以前德国同事在输入姓名拼音时就出现过这个问题... 例如 ü 既可以用 u 加两点头 (\u0308) 表示，又可以用单个 unicode 字符表示，前一种表示方式是两个 unicode char, 但只显示一个字符，在网页排版上容易造成坑 (甚至还出现过 Chrome 莫名其妙把整个 div 都丢了的奇怪事情). normalize 以后统一用一个 unicode 字符表示就好了。

鲜为人知的是，有个正则表达式字符组 \X 也是对付这个问题的 (它匹配 1 个 grapheme 也就是字素，1 个子素可以是 1 个或多个 unicode 字符，但在人眼看来是 1 个字符). 以前要准确计算字符串的逻辑长度是这么写：

"au\u0308c".scan(/\X/).count

现在可以这么写

"au\u0308c".unicode_normalize.size

itself 的作用是添加了一直都缺失的 identity function, id function 有什么用？可以参考这个回答: http://stackoverflow.com/questions/3136338/uses-for-haskell-id-function

而且现在可以把 group_by{|x| x } 写成 group_by &:itself 了。

#3 楼 @bhuztez 呃，register based VM 字节码占内存多。如果像 MRuby 那样用压缩的字节码跑 register based VM, 那执行每个指令都要经历一个 decode 过程，会产生不少消耗。现在完全用 C 实现的 Ruby VM 是很难像 Lua 那样利用乱序执行特性达到比较高执行效率的。

register based VM 的 register 是虚拟寄存器，在物理寄存器分配上也不一定有优势... stack based VM 也有很多利用物理寄存器技巧，例如把 stack 顶部 (经常 push pop 的内容) spill 到物理寄存器上，Ruby 源代码里改编译参数也能 enable 这个优化，只是实测没什么速度变化...

#1 楼 @googya 因为你用的 pry-doc, 那个还没有加 2.2 的文档

2.2 有这么一行：

if (!NIL_P(num))
    return nmin_run(obj, num, 1, 0);

蛋疼... 等价于这样写：

def track_for stat
  send *stat
end

#11 楼 @larrylv 好吧，对于我来说屁大的事加个 gem 加一层 middleware 牵连无辜 action 才是个痛点...

#9 楼 @larrylv warden 就是把 current_user 放那里的啦，rack 的 spec 都说应用程序可以随便改了，而且 rack 很小心的把 rack 相关的 key 都写成 "rack.xxx" 了。global 当然是 environment 的一部分，进程 global 不就是用 ENV[] 访问吗？

#5 楼 @luffycn 直接读 wiki 的 repo 就可以了。项目名.wiki.git

#7 楼 @larrylv 不不，它的作用就是让用户去放 request 范围内的 "global" variable 的...

真的 global 有全局变量和常量，范围限定的 "global" 还有 thread 范围放 Thread.current fiber 范围放 Fiber.current session 范围放 session browser 范围放 cookie

#2 楼 @luffycn wiki 的 CRUD 其实都是 git 操作，不需要 API 吧

#5 楼 @larrylv model 层大部分情况是不需要它的，真需要加个方法参数或者实例变量传进去就好了...

#3 楼 @larrylv 看下实现就知道丢 request.env 是多么好的选择... 那个东西加了个 rack middleware 完了还 clear 一遍 store, 何必啊...

方案一，看不懂来问就对了，对团队成员有好处

方案二增加了一层嵌套调用，还悄悄污染了方法命名空间，万一 include module 的 class 或者别的 module 也定义了 request_send 你就 debug 去吧

别用 request_store, 直接丢 request.env 就好了

还有一个错误：thin 不是基于 thread 的

方便你做 客户端，订阅工具，统计，搜索，自动化工具 等等

例如

• 跟踪奥巴马的动态
• CI 某个分支 build 出错，可以通知 github 让它显示个红叉
• 提交到某个分支就自动发布
• ...

很有可能是文件名大小写不对...

这种情况你应该用 .round 不用 .to_i