[#68137] improve semantics of manpages — "Anthony J. Bentley" <anthony@...>
Hi,
1 message
2015/02/17
[#68144] Re: Future of test suites for Ruby — Anthony Crumley <anthony.crumley@...>
FYI...
4 messages
2015/02/17
[#68343] [Ruby trunk - Bug #10916] [Open] What the Ruby? SegFault? — ruby@...
Issue #10916 has been reported by why do i need this acct just to create a bug report.
5 messages
2015/02/27
[#68373] Re: [Ruby trunk - Bug #10916] [Open] What the Ruby? SegFault?
— "Martin J. Dürst" <duerst@...>
2015/03/02
> * Author: why do i need this acct just to create a bug report
[#68358] [Ruby trunk - Bug #10902] require("enumerator") scans LOAD_PATH 2x on every invocation — ruby@...1.net
Issue #10902 has been updated by Aman Gupta.
3 messages
2015/02/28
[ruby-core:68189] Re: [Ruby trunk - Feature #10869] [Open] Add support for option to pre-compile Ruby files
From:
Eric Wong <normalperson@...>
Date:
2015-02-19 21:39:48 UTC
List:
ruby-core #68189
I profiled startup time a bit last year and much of it was in the parser and malloc; so having this should be a win. I've pondered having something like a self-managing cache in $HOME. It would be similar to what ccache uses for caching gcc output, but for Ruby iseqs. I've used ccache for over a decade it's never failed me. Since 2.2 fixed iseq dumping/loading, we're closer to being able to support this. We'll need to be careful and correctly invalidate the cache on any internal ABI changes, of course, and I don't want us to be stuck on an old/stable ABI for a cache. I don't think this will make distributing most Ruby apps any easier (because C extensions are usually the biggest problem)