JRuby 想跑得快,要预热和修改 JVM 参数,并且开 invoke dynamic, 没 JVM 调优知识的话很难达到比较优化的速度。另外平台是 Mac, Mac 上 CRuby 必须最快...
可以,不过没什么用。
CC=`which clang` CXX=`which clang++` ./configure --prefix=$HOME/.rbenv/versions/2.1.0 --with-openssl-dir=/usr/local/opt/openssl --with-readline-dir=/usr/local/opt/readline
(如果没有 homebrew 装的 openssl, 就把 --with-openssl-dir 那项去掉)
然后检查下 Makefile 是否把 CC 设对了,然后 make install
搞定
从头安装的话
CC=`which clang` CXX=`which clang++` rbenv install -k -v 2.1.0
rbenv
brew upgrade readline openssl
brew upgrade ruby-build --HEAD
rbenv install -k -v 2.1.0
大概是带了隐藏字符,看看 rows.keys.first.chars.to_a
吧。
一个可能是因为表格数据加了 BOM
data = Hash.[] CSV.parse("\xEF\xBB\xBFname\nfoo").transpose
# => {"name"=>"foo"}
data['name']
# => nil
为什么会加 BOM 呢?大概是因为要让 excel 能打开 utf-8 编码文件 http://ruby-china.org/topics/16376 ...
#2 楼 @xhj6 不管几个变量,放在一个 hash 中 to_json, 页面上最多就一个 script 标签一个变量... 页面传非默认的设置就好了,重复的逻辑和默认值写在分离的 coffee/js 文件中啊,还有 $.extend 这种便利的工具。提不出来逻辑的时候想想 function as value 就能提出来了。
按页面载入 js 也有两种,大部分情况下 js 是静态的编译时就定好了的,加个 js 按需加载的工具就可以了,根本就没 rails 什么事。小部分情况是通过用户输入生成 js, 我整过一个解析用户创建的 excel 公式然后编译成 js 函数做计算的,也只需要一个 script 标签一个变量...
99.9% 情况下动态的都是数据,逻辑都是固定的,分清楚了代码就不会丑。
其实还有很多 DYLD_ 打头的变量,man dyld
就知道了
DYLD 是用来控制系统 .dylib 函数查找的
由于安全考虑,这些环境变量在 setuid/setgid 调用后就会失效并且打印出你说的提示。你可以去掉 setuid/setgid 的调用 (sudo 就用了 setuid), 或者执行 script 之前把上面环境变量都设空。
向页面传递变量很稀有,直接 to_json 放 script tag 就好了
script
| xxx = #{{ data.to_json }}
唯一要注意的是 json 里可能包含 '</script>'
标签,所以设置里加上
ActiveSupport.escape_html_entities_in_json = true
就安全了。
传递代码的情况就更稀有了... 就为了一两个 case 加个 gem 感觉不值得...
@reyesyang 不用这么麻烦,完全无需转码,给 csv 文件加个 BOM 就可以了
csv_data = "\xEF\xBB\xBF#{csv_data}"
常见静态语言都带有一定的动态能力 (如 C++ 的运行时多态), 但一些要求严格的代码库,如 OpenJDK 会要求多态都在编译时决定好。
但是总有一些人想混淆弱类型和动态类型 (因为他们主张的静态类型没动态类型好听,但强类型比弱类型好听)...
静态分析做推断有两种极端:一种是什么都不丢保持精度 -- 很容易类型闭包信息爆炸内存溢出,另一种是降低精度用比较粗泛的类型去描述复杂类型运算的结果 -- 很容易什么效果都没有。现在的分析都是在这两种极端中找平衡。
开发人员一个 github issues 就够了...
把大妈炒币团赶回来以后,体恤到她们积聚的多余能量无处发泄,特发行马币让她们炒...
大妈炒币团大炒马币 -- 更无法直视了...
#71 楼 @bhuztez PySonar 实在是太素了,就是个简单的 Abstract Interpretation 做类型计算,加个扫栈去环,parser 直接调用的 Jython 都不用写,真没感受到是什么惊天动地的创举... 但如果加上考虑真实世界是有 thread 和 continuation 这两种平行栈和树状栈的状况,那点代码就不够使了... 而且这种东西设计时先把类型运算的公理列出来吧 (老子从来不看 ICFP 论文集!), 但 PySonar 只能从代码中看做了什么 (还是 Java 的一下就没胃口了)... M$ 研究人员写过利用自动化定理证明来生成 reduction rule 集合的 (把 intel 手册输进去以后就能获得无敌编译器了), 显然 PySonar 没到那个程度。
动态语言做静态分析的可多了,SBCL, Cython, Groovy, Mirah, Diamond-backed Ruby... 各有它们的优缺点。例如 SBCL 就是分析得了就是一条龙,分析不了的就是一条虫。但这些东西都做了巨多的工作,design decision 中也考虑到了各种各样扭曲的 case, 和玩具不是一个层次的...
归根是 eventmachine C++ 写的问题太多...
第二题由于候选不多,按前 2 字母分组就够了,吃内存还小点
反机器最有效还是 pow 表单