[#53893] [ruby-trunk - Bug #8204][Open] ObjectSpace.each_object(Bignum) can generate Bignums that are to small to be Bignums — "Hanmac (Hans Mackowiak)" <hanmac@...>
[#53914] [ruby-trunk - Feature #8206][Open] Should Ruby core implement String#blank? — "sam.saffron (Sam Saffron)" <sam.saffron@...>
[#53922] [ruby-trunk - Bug #8208][Open] Raise cached exceptions for nonblocking IO to avoid allocation/stack-copying costs — "headius (Charles Nutter)" <headius@...>
"headius (Charles Nutter)" <headius@headius.com> wrote:
[#53950] [ruby-trunk - Bug #8211][Open] Performance regression of method calls — "dunric (David Unric)" <dunric29a@...>
[#53974] [ruby-trunk - Feature #8215][Open] Support accessing Fiber-locals and backtraces for a Fiber — "halorgium (Tim Carey-Smith)" <ruby-lang-bugs@...>
[#54023] [ruby-trunk - Feature #8223][Open] Make Matrix more omnivorous. — "boris_stitnicky (Boris Stitnicky)" <boris@...>
[#54031] Question about r39944 — Aaron Patterson <tenderlove@...>
Hi,
Even if test directory should be on the load path on test-all, you should
[#54095] [ruby-trunk - Feature #8237][Open] Logical method chaining via inferred receiver — "wardrop (Tom Wardrop)" <tom@...>
[#54175] [ruby-trunk - Bug #8254][Open] Ruby segfaults on second SystemStackError from parser — "charliesome (Charlie Somerville)" <charlie@...>
[#54185] [CommonRuby - Feature #8257][Open] Exception#cause to carry originating exception along with new one — "headius (Charles Nutter)" <headius@...>
(2013/04/12 1:40), headius (Charles Nutter) wrote:
On Sat, Apr 27, 2013 at 5:19 PM, SASADA Koichi <ko1@atdot.net> wrote:
[#54196] Encouraging use of CommonRuby — Charles Oliver Nutter <headius@...>
I think we need to do more to encourage the use of the CommonRuby
Hi,
On Thu, Apr 11, 2013 at 3:50 PM, Marc-Andre Lafortune
As far as I understand, what is CommonRuby and the process over CommonRuby
On Thu, Apr 11, 2013 at 11:25 PM, NARUSE, Yui <naruse@airemix.jp> wrote:
(2013/04/12 16:40), Charles Oliver Nutter wrote:
On Fri, Apr 12, 2013 at 8:08 AM, NARUSE, Yui <naruse@airemix.jp> wrote:
[#54201] Has ObjectSpace changed recently? — Dave Thomas <dave@...>
I just noticed that in 2.0, I see this:
[#54207] [CommonRuby - Feature #8258][Open] Dir#escape_glob — "steveklabnik (Steve Klabnik)" <steve@...>
[#54218] [CommonRuby - Feature #8259][Open] Atomic attributes accessors — "funny_falcon (Yura Sokolov)" <funny.falcon@...>
Issue #8259 has been updated by Charles Nutter.
I'm not sure if setting the attribute on the ivar is a good way to go.
[#54333] Requesting Commit Access — Aman Gupta <ruby@...1.net>
Hello ruby-core,
Hi,
[#54415] [ruby-trunk - Bug #8286][Open] Can't decode non-MIME Base64 — "adacosta (Alan Da Costa)" <alandacosta@...>
[#54459] [CommonRuby - Feature #8291][Open] Allow retrieving the root Fiber of a Thread — "halorgium (Tim Carey-Smith)" <ruby-lang@...>
[#54473] [Backport 200 - Backport #8299][Open] Minor error in float parsing — "bobjalex (Bob Alexander)" <bobjalex@...>
[#54509] [ruby-trunk - Bug #8310][Open] resque-web crashes with segfault on Ruby 2.0.0-p0 only, Resque 1.24.1, Redis 2.6.12 — "vaharoni (Amit Aharoni)" <amit.sites@...>
[#54559] [ruby-trunk - Feature #8321][Open] Ripper: I would like coordinates for keywords — "ericp (Eric Promislow)" <eric.promislow@...>
[#54606] Plan to the first 2.0.0 patchlevel release. — Tomoyuki Chikanaga <nagachika00@...>
Hello, Rubyists.
Hi,
Could you please backport the following:
[#54621] [ruby-trunk - Feature #8339][Open] Introducing Geneartional Garbage Collection for CRuby/MRI — "ko1 (Koichi Sasada)" <redmine@...>
(2013/04/28 9:23), authorNari (Narihiro Nakamura) wrote:
2013/4/28 SASADA Koichi <ko1@atdot.net>:
(2013/05/04 12:08), Narihiro Nakamura wrote:
2013/5/4 SASADA Koichi <ko1@atdot.net>:
(2013/05/06 11:50), Tanaka Akira wrote:
2013/5/6 SASADA Koichi <ko1@atdot.net>:
On Sat, Apr 27, 2013 at 8:19 PM, ko1 (Koichi Sasada)
(2013/04/28 21:40), Magnus Holm wrote:
(2013/04/28 23:34), SASADA Koichi wrote:
On Sun, Apr 28, 2013 at 6:07 PM, SASADA Koichi <ko1@atdot.net> wrote:
(2013/04/29 1:19), Magnus Holm wrote:
On Sun, Apr 28, 2013 at 6:29 PM, SASADA Koichi <ko1@atdot.net> wrote:
"ko1 (Koichi Sasada)" <redmine@ruby-lang.org> wrote:
[#54665] [ruby-trunk - Bug #8344][Open] Status of Psych and Syck — "Eregon (Benoit Daloze)" <redmine@...>
[ruby-core:54343] [CommonRuby - Feature #8096] introduce Time.current_timestamp
Issue #8096 has been updated by headius (Charles Nutter).
phluid61 (Matthew Kerwin) wrote:
> Actually since making the jruby branch, and based on some conversations here, I have changed the API of the gem (and the C implementation in master) to define a monotonic Time.timestamp method and a Time.now.to_i-equivalent wall-clock method, which I called Time.unix_timestamp because I couldn't think of a better name.
>
> My intention was to update the jruby branch to use System.nanoTime for Time.timestamp, which I've finally gotten around to doing, but I see there are still potentially some polytonic (is that even a word?) issues to resolve. Fortunately I've not yet set up my VM to build jruby/java-native gems, or verified my hopefully MRI-and-jruby compatible gemspec, so my java code won't be released into the wild for some time yet.
I could submit a PR for master that provides the same methods in a JRuby-compatible way, if you'd like.
> > * Do we want a single Time.timestamp method?
> > * If so, which timestamp is it?
> > * If not, how many representations of timestamp do we want? It seems to me that our timestamp and Time.now.to_i should probably be derived the same way.
>
> This discussion has already revealed, to me at least, that some people want a fast seconds-since-1969 method, and some people want a secure, high-precision monotonicically increasing value. I think the latter has the most merit, since there is currently no equivalent in Ruby; however both are legitimate requests.
Yes, those seem like the key points. The monotonicity guarantees of the latter are hard to meet, though...on any impl. it might have to be specified as "high-precision CPU-level timestamp, which will be monotonic on most systems (but this is not guaranteed)".
So we have:
* Time.timestamp: A ns-precision timestamp based on the fastest, most accurate timer possible on the current platform. Although not guaranteed, this value will be monotonic on most systems.
* Time.something_timestamp: A timestamp representing the number of seconds since the epoch.
I suggest epoch_timestamp for the latter.
Would this meet everyone's needs?
----------------------------------------
Feature #8096: introduce Time.current_timestamp
https://bugs.ruby-lang.org/issues/8096#change-38619
Author: vipulnsward (Vipul Amler)
Status: Feedback
Priority: Low
Assignee:
Category:
Target version:
=begin
A lot of scenarios and applications require the use of (({Time.now.to_i})) which is used as current_timestamp in systems.
The introduction of (({Time.current_timestamp})) {or something with similar with different name} would provide implicit integer timestamp instead of going from
(({Time.now})) -> time_object -> to_i -> integer timestamp value
So instead of
Time.now.to_i # Outputs => 1363274618
one could use
Time.current_timestamp # Outputs => 1363274618
=end
--
http://bugs.ruby-lang.org/