[#10492] Ruby 1.8.6 preview3 has been released — "Akinori MUSHA" <knu@...>

Hi,

26 messages 2007/03/04
[#10500] Re: Ruby 1.8.6 preview3 has been released — Hugh Sasse <hgs@...> 2007/03/05

On Mon, 5 Mar 2007, Akinori MUSHA wrote:

[#10507] Dynamic Array#join with block — <noreply@...>

Patches item #9055, was opened at 2007-03-05 19:57

12 messages 2007/03/05
[#10520] Re: [ ruby-Patches-9055 ] Dynamic Array#join with block — Nobuyoshi Nakada <nobu@...> 2007/03/06

Hi,

[#10594] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org>

In ext/thread/thread.c, remove_one leaves the list in an inconsistent state.

15 messages 2007/03/14
[#10596] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 00:15:57 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10597] Re: [PATCH] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/14

> > The fix is in thread-mutex-remove_one.diff.

[#10598] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 01:19:04 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10599] Re: [PATCH] grave bug in 1.8.6's thread implementation — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/14

On Wednesday 14 March 2007 17:29, MenTaLguY wrote:

[#10600] Re: [PATCH] grave bug in 1.8.6's thread implementation — MenTaLguY <mental@...> 2007/03/14

On Thu, 15 Mar 2007 01:48:42 +0900, Sylvain Joyeux <sylvain.joyeux@m4x.org> wrote:

[#10615] Multiton in standard library — TRANS <transfire@...>

Hi--

16 messages 2007/03/15
[#10619] Re: Multiton in standard library — Tom Pollard <tomp@...> 2007/03/16

[#10620] Re: Multiton in standard library — TRANS <transfire@...> 2007/03/16

On 3/15/07, Tom Pollard <tomp@earthlink.net> wrote:

[#10646] Marshal.dump shouldn't complain about singletons if the _dump method is defined — <noreply@...>

Bugs item #9376, was opened at 2007-03-19 15:58

12 messages 2007/03/19
[#10647] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Urabe Shyouhei <shyouhei@...> 2007/03/19

noreply@rubyforge.org wrote:

[#10648] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2007/03/19

On Monday 19 March 2007 18:01, Urabe Shyouhei wrote:

[#10651] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — Yukihiro Matsumoto <matz@...> 2007/03/19

Hi,

[#10665] Re: [ ruby-Bugs-9376 ] Marshal.dump shouldn't complain about singletons if the _dump method is defined — "Chris Carter" <cdcarter@...> 2007/03/20

On 3/19/07, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

[#10712] Ruby Method Signatures (was Re: Multiton in standard library) — "Rick DeNatale" <rick.denatale@...>

On 3/19/07, TRANS <transfire@gmail.com> wrote:

10 messages 2007/03/21
[#10715] Re: Ruby Method Signatures (was Re: Multiton in standard library) — Jos Backus <jos@...> 2007/03/22

On 3/19/07, TRANS <transfire@gmail.com> wrote:

[#10798] Virtual classes and 'real' classes -- why? — "John Lam (CLR)" <jflam@...>

I was wondering if someone could help me understand why there's a parallel =

12 messages 2007/03/28
[#10799] Re: Virtual classes and 'real' classes -- why? — MenTaLguY <mental@...> 2007/03/28

On Thu, 29 Mar 2007 04:44:16 +0900, "John Lam (CLR)" <jflam@microsoft.com> wrote:

Re: Extensions to ipaddr.rb

From: Brian Candler <B.Candler@...>
Date: 2007-03-22 06:58:51 UTC
List: ruby-core #10727
Responding to several points at once:

>   "255.255.255.240".to_i => 255
> 
>   d = a & "255.255.255.240" => #<IPAddr: IPv4:0.0.0.123/255.255.255.255>
> 
> :-(

Hmm. I guess these operators could do IPAddr.new() on their RHS, unless RHS
is already an IPAddr. But arguably the above is simply undefined behaviour,
i.e. trying to combine an IPAddr with a string. I agree that using to_int
[or IPAddr.new] would give a more helpful error or more useful behaviour.

>  * IPAddr#<=>
>     addr1 = IPAddr.new("192.168.0.1")
>     addr2 = addr1.succ
>     puts addr1 <=> addr2              # => -1
>     puts addr1 <=> addr1              # => 0
>     puts addr2 <=> addr1              # => 1

Comparable is a nice idea. However note that this class also encapsulates
IPv4, IPv6, and IPv4-in-IPv6 addresses; you'd have to decide what to do when
comparing different ones.

OTOH, there is already an 'include?' method so the logic can be borrowed
from that. Then the include? operator could then be rewritten in terms of a
Range.

> class IPAddr
>   def entries
>     list = []
>     0.upto(~@mask_addr & IN4MASK) do |i|
>       list << IPAddr.new(_to_string(@addr + i))
>     end
>     list
>   end
> end
> 
> ip = IPAddr.new("192.168.5.0/28")
> ip.entries.each do |ip|
>   puts ip
> end

I would do it differently; give class IPAddr an 'each' method which yields
each of the values (perhaps delegating to Range#each), and then make it
Enumerable.

Otherwise, if you call 'entries' on a /48 IPv6 address you will generate an
intermediate array with 2^80 entries :-(

Now, arguably a Range might be better internal data structure than an address
plus mask, as both 'include?' and 'size' would be trivial. You could then do
   IPAddr.new("192.168.0.5", "192.168.0.13")
which might be useful. You could even subclass Range.

But I wasn't coming here to suggest a redesign of IPAddr - it works, and it
does *almost* what I want already. However, given a (say) /28 prefix, I need
to be able to find:

  - the base address + 1 (router IP)
  - the base address + 2 (dhcp start)
  - the end of the block - 2 (dhcp end)
  - the end of the block - 1 (broadcast)
  - the netmask

That's why I proposed those new methods, as there doesn't seem to be a
straightforward way to do it otherwise without digging directly in with
instance_eval.

Regards,

Brian.

In This Thread