[ruby-core:56095] Re: Digest Articles 56091-56094 (2/2) (ruby-core ML)

unsubscribe


On Sat, Jul 20, 2013 at 11:04 AM, <[e-mail]> wrote:

>
>
> ---------- Forwarded message ----------
> From: "akr (Akira Tanaka)" <[e-mail]>
> To: [e-mail]
> Cc:
> Date: Sat, 20 Jul 2013 19:39:19 +0900
> Subject: [ruby-core:56092] [ruby-trunk - Feature #8658]
> Process.clock_gettime
>
> Issue #8658 has been updated by akr (Akira Tanaka).
>
> File clock_gettime-2.patch added
>
> kosaki (Motohiro KOSAKI) wrote:
> > First, Process.times() returns user time and system time and they are
> process  specific. But Process::CLOCK_MONOTONIC is not per-process time.
>
> Yes.  Users can choose any clock with Process.clock_gettime unlike other
> proposals (#8640, #8096).
>
> It seems many people use CLOCK_REALTIME to measure a time interval, though.
>
> > Second, Linux's CLOCK_MONOTONIC_RAW has the same behavior BSD's
> CLOCK_MONOTONIC. And, an application which measures a performance need to
> use CLOCK_MONOTONIC_RAW for avoiding ntp confusing. Then, we should do 1)
> exporse CLOCK_MONOTONIC_RAW or 2)
>  Process.clock_gettime(Process::CLOCK_MONOTONIC) uses  CLOCK_MONOTONIC_RAW
> internally.
>
> OS specific CLOCK_* constants can be defined.
> Since Process.clock_gettime is a primitive, exchange clk_id is not a good
> idea.
>
> > Third, using float is a good ruby convention. If we need to use inter
> (for precision and performance?), the method should have a precision
> explanation, likes get_time_nanosecond. I mean, ruby interpreter can't warn
> nor detect following mistake.
> >
> > a = foo # this is usec
> > b = bar # this is nsec
> > c = a + b
> >
> > then, we should warn by method name verbosely. IMHO.
>
> Hm.  It is acceptable as far as the exact result (number of nanoseconds)
> can be obtained.
>
> After thinking while, I find Process.clock_gettime(clk_id, unit).
> unit is an optional argument and :nanoseconds specifies the nanoseconds.
> This can help performance on ILP33 because :microseconds with
> CLOCK_PROCESS_CPUTIME_ID
> will not use Bignum until 1073 seconds after process start up.
>
> I updated the patch.
>
> ----------------------------------------
> Feature #8658: Process.clock_gettime
> https://bugs.ruby-lang.org/issues/8658#change-40590
>
> Author: akr (Akira Tanaka)
> Status: Open
> Priority: Normal
> Assignee:
> Category:
> Target version:
>
>
> How about adding a new method, Process.clock_gettime(clk_id) ?
>
> Recently there were two feature request for measuring time.
> Feature #8640 https://bugs.ruby-lang.org/issues/8640
> Feature #8096 https://bugs.ruby-lang.org/issues/8096
>
> It seems they are somewhat different.
>
> clock_gettime() function defined by POSIX is a good
> candidate for providing as a method.
> I think it can supports the both request.
>
> Also, it has less possible design choices than the requests
> because clock_gettime() is defined by POSIX.
> People familiar to POSIX can learn the method more easily.
>
> I wrote a patch to implement Process.clock_gettime.
> This method can be used as follows.
>
>   % ./ruby -e 'p Process.clock_gettime(Process::CLOCK_MONOTONIC)'
>   2701692957811563
>
> Several considerations:
>
> I implemented the method as a module function of Process.
> It is same as Process.times.
> I expect clock_gettime is used mainly for measuring
> time interval and wall clock time is not important.
> So I didn't use Time.
>
> The method returns a number of nanoseconds as an integer.
> It is not so unexpected if user knows clock_gettime() in POSIX.
>
> clock_gettime() returns it as struct timespec
> which contains two fields: tv_sec and tv_nsec.
>
> Although tv_sec is time_t, Time is not appropriate because
> the origin (zero) can be other than the Epoch.
> Actually CLOCK_MONOTONIC means elapsed time since
> the system start-up time on Linux.
>
> Also, I expect the result is subtracted in most case:
>   t1 = Process.clock_gettime(...)
>   ...
>   t2 = Process.clock_gettime(...)
>   t = t2 - t1
> So the result should be easy to subtract.
> An array such as [sec, nsec] is difficult to subtract.
>
> The result is an integer, not a float.
> IEEE 754 double is not enough to represent the result
> of clock_gettime(CLOCK_REALTIME).
> It contains 19 digits in decimal now but IEEE 754 double
> can represent only 15 digits.
>
> On LP64 systems, Fixnum can represent 2**62-1.
> So (2**62-1)/(365.25*24*60*60*1e9)=146.1 years are representable
> without object allocation.
>
> On ILP32 and LLP64 systems, Fixnum can represent 2**30-1.
> So (2**30-1)/1e9=1.07 seconds are representable
> without object allocation.
> This means Bignum allocations are mostly required except
> the origin is very recent.
>
> clock_gettime() is defined by POSIX.
> Linux, NetBSD, FreeBSD, OpenBSD has it, at least.
>
> If clock_gettime() is not available,
> an emulation layer for CLOCK_REALTIME is implementable
> using gettimeofday().
> (not implemented yet, though.)
>
> Any comments?
>
>
>
> --
> http://bugs.ruby-lang.org/
>
>
>
> ---------- Forwarded message ----------
> From: "mattconnolly (Matt Connolly)" <[e-mail]>
> To: [e-mail]
> Cc:
> Date: Sat, 20 Jul 2013 20:05:26 +0900
> Subject: [ruby-core:56093] [ruby-trunk - Bug #8660][Open]
> rb_thread_blocking_region deprecated, no alternative in ruby.h
>
> Issue #8660 has been reported by mattconnolly (Matt Connolly).
>
> ----------------------------------------
> Bug #8660: rb_thread_blocking_region deprecated, no alternative in ruby.h
> https://bugs.ruby-lang.org/issues/8660
>
> Author: mattconnolly (Matt Connolly)
> Status: Open
> Priority: Normal
> Assignee:
> Category:
> Target version:
> ruby -v: 2.0.0-p247
> Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN
>
>
> In "ruby/intern.h", the function declaration for
> `rb_thread_blocking_region` is deprecated. The comment says "Use
> rb_thread_call_without_gvl family instead", yet there are no functions from
> that family in the header that can be used by extensions.
>
> Should the method `rb_thread_call_without_gvl` be included in the header
> "ruby/intern.h" ?
>
>
> --
> http://bugs.ruby-lang.org/
>
>
>
> ---------- Forwarded message ----------
> From: "ThomasDickey (Thomas dickey)" <[e-mail]>
> To: [e-mail]
> Cc:
> Date: Sat, 20 Jul 2013 20:41:59 +0900
> Subject: [ruby-core:56094] [ruby-trunk - Bug #8659] Curses::Window#bkgdset
> does not handle color correctly
>
> Issue #8659 has been updated by ThomasDickey (Thomas dickey).
>
>
> agree: not just ncurses, but any implementation of SVr4 or X/Open curses
> will use >8 bits for chtype.
> 8-bit values were for BSD-curses, which is rarely used (essentially only
> for antique programs).
> ----------------------------------------
> Bug #8659: Curses::Window#bkgdset does not handle color correctly
> https://bugs.ruby-lang.org/issues/8659#change-40591
>
> Author: inferiorhumanorgans (Alex Zepeda)
> Status: Open
> Priority: Normal
> Assignee:
> Category: ext
> Target version:
> ruby -v: ruby 1.9.3p385 (2013-02-06 revision 39114) [x86_64-darwin12.2.1]
> Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN
>
>
> =begin
> Colors in curses are handled as high bits on a character.  Logically ORing
> a character with a color pair should allow bkgdset to configure a colored
> background.  This can be seen in the source for the Python curses module.
>  The Python function takes one or two arguments (color + character).  If
> there are two arguments they are ORed together and passed to curses as
> such.  Back in ruby land, with one argument it should be possible to
> specify a background color for the whole screen thusly:
>
>  # Define a color pair
>  Curses.init_pair(1, Curses::COLOR_GREEN, Curses::COLOR_BLUE)
>  # Set the screen background to blue
>  Curses.bkgdset(' '.ord | Curses.color_pair(1))
>
> The following:
>
>  #!/usr/bin/env ruby
>
>  require 'curses'
>
>  Curses.init_screen
>  Curses.start_color
>
>  Curses.init_pair(1, Curses::COLOR_YELLOW, Curses::COLOR_BLUE)
>  Curses.bkgdset('='.ord | Curses.color_pair(1))
>  Curses.clear
>  Curses.refresh
>
>  Curses.addstr('Press_any_key_to_continue')
>  Curses.getch
>
> Should fill the screen with equals signs (yellow on blue background), and
> prompt the user to press any key to continue.  With Ruby 1.9.3 this doesn't
> work.  The curses module assumes curses characters are one byte
> (typeof(chtype) == char).  Yet GNU ncurses defines the chtype data type as
> an unsigned integer (OSX 10.8) or an unsigned long (FreeBSD 9.1, RedHat
> 7.3).  The curses module defines a macro "NUM2CH" to convert from ruby
> objects to chtype objects.  At present NUM2CH is defined as NUM2CHR.
>  Instead NUM2CH should be defined as NUM2INT to allow for values > 255 (ex:
> character + color).
>
> =end
>
>
> --
> http://bugs.ruby-lang.org/
>
>
>