Emacs ESS：Eval 区域与 source()
我喜欢 Emacs ESS 组合。我喜欢将代码行、函数、区域和缓冲区发送到命令行进行评估，而无需使用鼠标。
但是，我注意到 Emacs 中的 Eval Function 命令比简单地运行 source("fns.R") 慢得多，其中 fns.R< /code> 是包含我要评估的函数的文件。
为什么会这样呢？
I love the Emacs ESS combination. I love sending lines, functions, regions, and buffers of code to the command line for evaluation without using the mouse.
However, I've noticed that the Eval Function command in Emacs is much slower than simply running source("fns.R"), where fns.R is the file that contains the function I want to evaluate.
Why is this the case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为 ess list 上的人们可以为您提供更好的答案。但如果你无形中评估，处理速度就会快得多。尝试将其放入您的 .emacs 文件中：
I think the folks at ess list have better answers for you. But if you evaluate invisibly, the processing is much much faster. Try putting this in your .emacs file:
我只是猜测，但是当你说
source("fns.R")时，你根本不涉及 Emacs/ESS，计算时间只是 R 吞入文件的时间并消化它——可能很少，而Eval Function将一个区域传递给 Emacs 解释器，Emacs 解释器必须将其发送（可能是逐行）到 R然后以分段方式消化它。这会使第二种方法变慢。
然而，从长远来看，谁在乎呢？我经常发送整个缓冲区或大区域，这可能需要一秒钟的大部分时间？我仍然认为——正如你所说——（丰富的）编辑器和底层语言以这种方式交互的能力是非常强大的。
感谢 Emacs 黑客和 ESS 团队。
I am just guessing but when you say
source("fns.R")you are not involving Emacs/ESS at all and the computing time is just the time R takes to slurp in the file and to digest it -- probably very little, whereasEval Functionpasses a region to the Emacs interpreter which has to send it (presumably line-by-line) to the R engine which then digests it in piecemeal fashion.and that would make the second approach slower.
Yet, in the grand scheme of things, who cares? I often send entire buffers or large regions, and that takes maybe a large part of a second? I still think---just as you say---that the ability for the (rich) editor and the underlying language to interact that way is something extremely powerful.
Kudos to the Emacs hackers and the ESS team.
如果你想执行你的整个缓冲区 - 如果你在 Unix/Linux 中，你也可以用 shebang 开始你的脚本：
并使你的文件可执行
（我记得读过 Google 喜欢他们的 r 脚本以 .R 结尾，但是哦好吧...），你可以这样执行它：
并且，使用参数
（我实际上用它来从 Matlab 系统调用调用 R 函数），并且在你的 R 文件中你可以用来
获取 arg1 和 arg2。您也可以不使用 shebang:
等等。对于 Windows，我记得它是
或类似的东西......我确实注意到通过 ESS 运行命令时有一点延迟（尽管我非常喜欢 ESS 非常），所以当我知道我想运行整个缓冲区 我有时会在 R 脚本下方的窗口中启动 shell（R 缓冲区通常驻留在其中）并使用上面的技巧。
您也可以使用
- 与直接在 R 或 R 缓冲区中运行 'source("myscript.r")' 相比，使用这些方法的好处是您可以从一个清晰的工作空间开始（尽管您应该小心您的.Rprofile 不会被加载，除非您在 'myscript.r' 中显式调用 'source("~/.Rscript")'），这样您就可以确保您的脚本是独立的（它调用正确的库，您的词法-作用域函数不会引用全局空间中您忘记删除的非预期变量，等等）。
If you wanted to execute your whole buffer - if you are in Unix/Linux, you can also start off your script with a shebang:
And make your file executable
(I recall reading Google likes their r scripts to end in .R but oh well...) and you can execute it this way:
And, with arguments,
(which I have actually used to invoke an R function from a Matlab system call) and in your R file you might use
to get arg1 and arg2. You can also do without the shebang:
and so on. With Windows I recall it was
or something to that effect... I did notice a little delay when running commands through ESS (though I do love ESS dearly) so when I know I want to run the the whole buffer I sometimes start a shell in a window below the R script (where the R buffer would normally reside) and use the tricks above.
You can also use
as well - the benefit of using these methods over running 'source("myscript.r")' directly in R or an R buffer is that you are starting out with a clear workspace (though you should be careful that your .Rprofile will not be loaded unless you call 'source("~/.Rscript")' explicitly in 'myscript.r') so you can be sure that your script is self-contained (it calls the proper libraries, your lexically-scoped functions aren't referencing unintended variables in the global space that you forgot to remove, and so on).