#19 楼 @luikore 没有啊

#17 楼 @luikore 明显没有，就是直接 switch 的，上面不就贴代码了

#15 楼 @luikore POP 其实挺快的。虽然是 stack-based，但是每个函数运行期的 frame 里都有一个预先分配好的 stack，也就是说通常情况 (目前情况) 下，你可以理解为 stack 就是一个 C 数组。所以，POP 其实拖慢不了多少的。

#define BASIC_POP()       (*--stack_pointer)
#define POP()                  BASIC_POP()

#13 楼 @luikore

别的没有，刚好就COMPARE_OP，BINARY_ADD和BINARY_SUBTRACT这三个 inline 了 int 的，对于现在这个情形应该一样才对啊。

Python 没用 threading 是会慢一点，但是 Ruby 的速度快了一倍啊，不是换个 threading 就能达到的吧。

case BINARY_ADD:
    w = POP();
    v = TOP();
    if (PyInt_CheckExact(v) && PyInt_CheckExact(w)) {
        /* INLINE: int + int */
        register long a, b, i;
        a = PyInt_AS_LONG(v);
        b = PyInt_AS_LONG(w);
        /* cast to avoid undefined behaviour
           on overflow */
        i = (long)((unsigned long)a + b);
        if ((i^a) < 0 && (i^b) < 0)
            goto slow_add;
        x = PyInt_FromLong(i);
    }
    else if (PyString_CheckExact(v) &&
             PyString_CheckExact(w)) {
        x = string_concatenate(v, w, f, next_instr);
        /* string_concatenate consumed the ref to v */
        goto skip_decref_vx;
    }
    else {
      slow_add:
        x = PyNumber_Add(v, w);
    }
    Py_DECREF(v);
  skip_decref_vx:
    Py_DECREF(w);
    SET_TOP(x);
    if (x != NULL) continue;
    break;

#11 楼 @luikore

太假了，send改成opt_lt，opt_minus和opt_plus竟然从和 Python 速度一样变成比 Python 快一倍

可是 Python 现在默认生成的指令也是类似的，对应的是COMPARE_OP，BINARY_ADD，BINARY_SUBTRACT，而不是先载入 operator 再CALL_FUNCTION

我觉得原因在其他地方。

#5 楼 @jjym 怎么看关掉前后生成的指令有何不同？

$ ruby fib.rb 
       user     system      total        real
 14930352
  2.240000   0.000000   2.240000 (  2.240812)
$ python2 fib.py 
14930352
4.98553395271
$ python3 fib.py 
14930352
7.37453122099987
$ pypy fib.py 
14930352
1.59528398514

体积好大

#11 楼 @swachian 可惜漏洞出在 OGNL...

#3 楼 @hooopo Struts 之前都有好几波远程执行命令了，就和 Rails 3 的时候好几波 SQL 注入一样...估计这地方有设计缺陷，再挖掘一下可能还可以来个一两波

Java 其实是动态语言，Java 的运行期和动态语言真没啥差别，但是编译器却要假装成静态语言的样子。(刚才没想到还有 gcj 这种实现)

Struts 不安全不代表 Rails 就安全

看 struts 的 version notes

http://struts.apache.org/release/2.3.x/docs/version-notes-23141.html

OGNL eval expressions has been disabled by default.

http://struts.apache.org/development/2.x/docs/version-notes-23142.html

OGNL evaluation for included URL parameters has been dropped

http://struts.apache.org/development/2.x/docs/version-notes-23143.html

Whitelisting of actions' names was introduced and double evaluation of OGNL expression was removed.

果然都是出在 OGNL 里的。OGNL 难道还不是动态语言？

http://commons.apache.org/proper/commons-ognl/index.html

这个地方之前就被爆出好几次远程执行漏洞的，比如

http://blog.o0o.nu/2012/01/cve-2011-3923-yet-another-struts2.html

@hooopo 可以继续深入挖掘一下，Struts 2 就只能淘汰掉 OGNL 了

不是很早之前就有的么

效果到底是什么？

我还以为是客户端 ..

Python 算不算坑爹

cat xxx.txt | iconv -f gbk -t utf8

#61 楼 @zjlovezj 可以都是哑巴的...

烧 CPU 啊啊啊啊啊啊啊啊

https://www.varnish-cache.org/docs/trunk/phk/http20.html

又是一个不认识vanilla的

#42 楼 @blacktulip 没有就没有吧。本来就是开玩笑的。而且我自己已经把 SICP 4.4 的坑填了。

只是说代码托管的话，这个坑早就填了啊。我在 2010 年就能支持 git 和 hg 了，可能还有 bzr ... 当时最大的问题是想加进去的功能太多了，还真的都加进去了，结果代码就没法维护了。基础太差就是这么悲剧。

#40 楼 @blacktulip 看大家都积极推出 git 平台，我就不打算填坑了，呵呵

太棒了又一个 git ...

#25 楼 @ptmagic 我是说写代码的时间，不是运行时间。语法层面的处理其实都还算简单的。语义层面的不匹配才是真花时间的地方。

#21 楼 @ptmagic parser 和 AST 变换什么的只是处理语法层面的代码花的时间 只占一小部分 。后端代码生成将花掉你 90% 的时间，另外，运行期支持库也要花掉你另外 90% 的时间。

#22 楼 @luikore 参考 SICP，整个程序的语义都变成 lazy，自己琢磨去...

#19 楼 @ptmagic 但一般人也就只能写写Hello, world! ...

#16 楼 @luikore 你回的那个就是错的

#13 楼 @luikore 对了，lazy 的坑你还没填呢

#11 楼 @luikore 应该是除了 parse 和 AST，都有很深的水