[#65451] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
ko1@atdot.net wrote:
Eric Wong <normalperson@yhbt.net> wrote:
Eric Wong <normalperson@yhbt.net> wrote:
On 2014/10/09 11:04, Eric Wong wrote:
SASADA Koichi <ko1@atdot.net> wrote:
[#65453] [ruby-trunk - Feature #10328] [PATCH] make OPT_SUPPORT_JOKE a proper VM option — ko1@...
Issue #10328 has been updated by Koichi Sasada.
[#65559] is there a name for this? — Xavier Noria <fxn@...>
When describing stuff about constants (working in their guide), you often
On 2014/10/09 20:41, Xavier Noria wrote:
On Thu, Oct 9, 2014 at 1:59 PM, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
[#65566] [ruby-trunk - Feature #10351] [Open] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been reported by Shyouhei Urabe.
[#65741] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race — Nobuyoshi Nakada <nobu@...>
On 2014/10/16 10:10, normal@ruby-lang.org wrote:
Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
2014-10-16 12:48 GMT+09:00 Eric Wong <normalperson@yhbt.net>:
[#65753] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
[#65818] [ruby-trunk - Feature #10351] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been updated by Shyouhei Urabe.
[ruby-core:65639] Re: [ruby-trunk - Feature #10225] [PATCH] *math.c: New method Math.normcdf
On Oct 11, 2014, at 11:18 PM, mail@tanakakazuki.com wrote: > Sorry for my late. It's hard to say but.. ruby-gsl doesn't look good enough. I agree that ruby-gsl has its shortcomings. GSL is a fairly large library that provides lots of functionality. Exposing all that functionality to Ruby is no small task. Another issue is memory management; I don't think GSL provides a way to hook into its memory allocation so that creates some issues. > And I suppose we'd better to make such a library from scratch. > > (Actually I start to make other library(called Numrb) > > Aside from that, I believe that providing such a feature "as standard" is really important in terms of reliability. I think I prefer a sort of middle ground. I'd like some sort of "standard", built-in way of dealing with multidimensional numerical arrays. I do not think we need to include loads of functionality out of the box, but it would be nice to have a standard multidimensional numerical array data type that different Ruby extensions could be created around. IMHO, this would provide a nice modular approach so that things can evolve with a finer granularity. It would somewhat decouple the numerical algorithms from the underlying data structures as well as provide for better interoperability between the different extensions that use multidimensional numerical arrays. > And we can make people we couldn't reach so far have interest in Ruby. It's always nice to broaden the appeal of Ruby!