[#9382] the sign of a number is omitted when squaring it. -2**2 vs (-2)**2 — <noreply@...>

Bugs item #6468, was opened at 2006-11-03 17:25

9 messages 2006/11/03

[#9385] merge YARV into Ruby — SASADA Koichi <ko1@...>

Hi,

42 messages 2006/11/04
[#9405] Re: merge YARV into Ruby — "Kirill Shutemov" <k.shutemov@...> 2006/11/06

On 11/4/06, SASADA Koichi <ko1@atdot.net> wrote:

[#9406] Re: merge YARV into Ruby — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2006/11/06

On Monday 06 November 2006 16:01, Kirill Shutemov wrote:

[#9417] Re: merge YARV into Ruby — Sean Russell <ser@...> 2006/11/06

On Monday 06 November 2006 10:15, Sylvain Joyeux wrote:

[#9428] Re: merge YARV into Ruby — "Kirill Shutemov" <k.shutemov@...> 2006/11/06

On 11/6/06, Sean Russell <ser@germane-software.com> wrote:

[#9402] fast mutexes for 1.8? — MenTaLguY <mental@...>

Many people have been using Thread.critical for locking because Ruby

24 messages 2006/11/06

[#9450] Bikeshed: No more Symbol < String? — Kornelius Kalnbach <murphy@...>

Hi ruby-core!

21 messages 2006/11/07
[#9452] Re: Bikeshed: No more Symbol < String? — Yukihiro Matsumoto <matz@...> 2006/11/07

Hi,

[#9493] Future Plans for Ruby 1.8 Series — URABE Shyouhei <shyouhei@...>

This week Japanese rubyists were talking about the future of ruby_1_8

13 messages 2006/11/09

[#9515] External entropy pool for random number generator — "Kirill Shutemov" <k.shutemov@...>

In the attachment patch which allow to use external entropy pool for

13 messages 2006/11/11
[#9522] Re: External entropy pool for random number generator — "Nobuyoshi Nakada" <nobu@...> 2006/11/13

Hi,

[#9554] Ruby 1.[89].\d+ and beyond. — Hugh Sasse <hgs@...>

I've been thinking about how version numbers are restricting what we can do.

30 messages 2006/11/16
[#9561] Re: Ruby 1.[89].\d+ and beyond. — Eric Hodel <drbrain@...7.net> 2006/11/16

[#9563] Re: Ruby 1.[89].\d+ and beyond. — Hugh Sasse <hgs@...> 2006/11/16

On Fri, 17 Nov 2006, Eric Hodel wrote:

[#9564] Re: Ruby 1.[89].\d+ and beyond. — Eric Hodel <drbrain@...7.net> 2006/11/16

On Nov 16, 2006, at 12:02 PM, Hugh Sasse wrote:

[#9571] Re: Ruby 1.[89].\d+ and beyond. — "Robert Dober" <robert.dober@...> 2006/11/19

On 11/16/06, Eric Hodel <drbrain@segment7.net> wrote:

[#9604] #ancestors never includes the singleton class (inconsistent) — <noreply@...>

Bugs item #6820, was opened at 2006-11-22 08:49

12 messages 2006/11/22
[#9618] Re: [ ruby-Bugs-6820 ] #ancestors never includes the singleton class (inconsistent) — Yukihiro Matsumoto <matz@...> 2006/11/25

Hi,

[#9629] Re: [ ruby-Bugs-6820 ] #ancestors never includes the singleton class (inconsistent) — Sylvain Joyeux <sylvain.joyeux@...4x.org> 2006/11/27

> It is supposed to. Singleton classes (or eigenclasses, if you want to

Re: fast mutexes for 1.8?

From: Hugh Sasse <hgs@...>
Date: 2006-11-06 18:08:39 UTC
List: ruby-core #9424
On Tue, 7 Nov 2006, MenTaLguY wrote:

> On Mon, 2006-11-06 at 23:17 +0900, Hugh Sasse wrote:
> > On Mon, 6 Nov 2006, MenTaLguY wrote:
> > 
> > > Many people have been using Thread.critical for locking because Ruby
> > > 1.8's Mutex is relatively slow.  Since 1.9 will not have
> > > Thread.critical, I think it would be good to optimize Mutex in 1.8 so
> > > people can become accustomed to using it today.
> > 
> > Agreed.  But ruby-1.8.5/lib/thread.rb contains the definition of Mutex
> > and it uses Thread.critical extensively....
> 
> That's okay for 1.8.  1.9 (YARV) will have to have its own

OK, I thought you wanted to avoid that particularly.
> implementation anyway.
> 
> > This has puzzled me for a while, but I don't know enough about this. It
> > seems to me that this means two instances of Mutex will interact horribly
> > even when the intent of the programmer is that they are independent.
> > I couldn't think of a better way to do it though, so I mean no disrepect
> > by this observation.
> 
> Thread.critical (or rb_thread_critical, if you're coming from C-land) is
> the only way to do things atomically in Ruby.  Mutex just dips into a
> critical section briefly to protect the owner and wait list variables
> when it works with them; it doesn't hold on to Thread.critical for the
> duration of the lock.

I was wondering if there was a way to make the critical sections truly
independent, so one doesn't block the others, but I've never found
real time programming that easy myself, so I'm not up to speed on this
area.  Or to put it another way, can we steal from Ada, Modula, Coral,
...?  Is this an opportunity to improve the concurrency model, essentially?

Probably opening a can of sandworms
[http://en.wikipedia.org/wiki/Sandworm_%28Dune%29].
> 
> -mental
> 
        Hugh

In This Thread