[#33640] [Ruby 1.9-Bug#4136][Open] Enumerable#reject should not inherit the receiver's instance variables — Hiro Asari <redmine@...>

Bug #4136: Enumerable#reject should not inherit the receiver's instance variables

10 messages 2010/12/08

[#33667] [Ruby 1.9-Bug#4149][Open] Documentation submission: syslog standard library — mathew murphy <redmine@...>

Bug #4149: Documentation submission: syslog standard library

11 messages 2010/12/10

[#33683] [feature:trunk] Enumerable#categorize — Tanaka Akira <akr@...>

Hi.

14 messages 2010/12/12
[#33684] Re: [feature:trunk] Enumerable#categorize — "Martin J. Dst" <duerst@...> 2010/12/12

[#33687] Towards a standardized AST for Ruby code — Magnus Holm <judofyr@...>

Hey folks,

23 messages 2010/12/12
[#33688] Re: Towards a standardized AST for Ruby code — Charles Oliver Nutter <headius@...> 2010/12/12

On Sun, Dec 12, 2010 at 9:55 AM, Magnus Holm <judofyr@gmail.com> wrote:

[#33689] Re: Towards a standardized AST for Ruby code — "Haase, Konstantin" <Konstantin.Haase@...> 2010/12/12

On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:

[#33763] [Ruby 1.9-Bug#4168][Open] WeakRef is unsafe to use in Ruby 1.9 — Brian Durand <redmine@...>

Bug #4168: WeakRef is unsafe to use in Ruby 1.9

43 messages 2010/12/17

[#33815] trunk warnflags build issue with curb 0.7.9? — Jon <jon.forums@...>

As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.

11 messages 2010/12/22

[#33833] Ruby 1.9.2 is going to be released — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2010/12/23

[#33846] [Ruby 1.9-Feature#4197][Open] Improvement of the benchmark library — Benoit Daloze <redmine@...>

Feature #4197: Improvement of the benchmark library

15 messages 2010/12/23

[#33910] [Ruby 1.9-Feature#4211][Open] Converting the Ruby and C API documentation to YARD syntax — Loren Segal <redmine@...>

Feature #4211: Converting the Ruby and C API documentation to YARD syntax

10 messages 2010/12/26

[#33923] [Ruby 1.9-Bug#4214][Open] Fiddle::WINDOWS == false on Windows — Jon Forums <redmine@...>

Bug #4214: Fiddle::WINDOWS == false on Windows

15 messages 2010/12/27

[ruby-core:33758] Re: Proposal: IPAddress in the standard library

From: Simone Carletti <weppos@...>
Date: 2010-12-17 13:59:58 UTC
List: ruby-core #33758
I'm really interested in this topic.

I the last couple of years I had to deal with IP manipulation several times,
especially for the Whois ( http://www.ruby-whois.org ) and Net::DNS gems.

I had the chance to give IPAddress a try in the past,
and I really enjoyed it. The current IPAddr implementation doesn't expose
some very useful methods,
such as the ability to validate an IP Address on-the-fly
without instantiating an IPAddr object,
and I often had to rely on hacks or cut&paste to accomplish this.

Also, IPAddr has a couple of weird bugs when you have to work with IP ranges
(thanks to Marco for helping me spotting them out in the past ;) ).

I'm really curious to know if the Ruby would consider this proposal.

-- Simone


On Thu, Dec 16, 2010 at 8:31 AM, Marco Ceresa <ceresa@gmail.com> wrote:

> Hello,
>
> IPAddress [1] is a library to manipulate IPv4 and IPv6 addresses. It
> has been written as a replacement for IPAddr, trying to fix some of
> its bugs, and at the same time extending its functionalities and
> offering a more powerful and flexible interface.
>
> Migrating from IPAddr to IPAddress is very easy, as most of the
> methods have the same name and same behaviour. Moreover, IPAddress is
> around 50% faster than IPAddr, and it's very well documented in each
> of its parts. The code is very clear, easy to read, to maintain and to
> extend, consisting mostly of one line methods.
>
> I've been in touch with the maintainer of IPAddr, Mr. Akinori MUSHA,
> asking him if he would consider IPAddress as a replacement, and he
> suggested me to write to -core.
>
> I think IPAddress is mature enough, so here is my proposal. Let me
> know what you think.
>
> Best regards,
> Marco
>
> [1] https://github.com/bluemonk/ipaddress
>
>

In This Thread