[#36034] [Backport92 - Backport #4651][Open] Bus Error using continuation on x86_64-darwin11.0.0 (Lion) — Erik Michaels-Ober <sferik@...>

17 messages 2011/05/07

[#36058] draft schedule of Ruby 1.9.3 — "Yuki Sonoda (Yugui)" <yugui@...>

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

18 messages 2011/05/09

[#36131] Re: [ruby-cvs:38172] Ruby:r30989 (trunk): * include/ruby/win32.h: define WIN32 if neither _WIN64 nor WIN32 defined. it forces to use push/pop for pack(4) pragma. — "Yuki Sonoda (Yugui)" <yugui@...>

Hi arton,

7 messages 2011/05/12

[#36156] [Ruby 1.9 - Bug #4683][Open] [PATCH] io.c: copy_stream execute interrupts and retry — Eric Wong <normalperson@...>

11 messages 2011/05/12

[#36316] [Ruby 1.9 - Bug #4731][Open] ruby -S irb fails with mingw/msys vanilla builds — Roger Pack <rogerpack2005@...>

12 messages 2011/05/18

[#36329] [Ruby 1.9 - Bug #4738][Open] gem install fails with "Encoding::ConverterNotFoundError" on windows 7 greek — Ilias Lazaridis <ilias@...>

11 messages 2011/05/19

[#36390] [Ruby 1.9 - Feature #4766][Open] Range#bsearch — Yusuke Endoh <mame@...>

23 messages 2011/05/22

[#36406] 1.8.7 release next month — Urabe Shyouhei <shyouhei@...>

Hello core people,

18 messages 2011/05/23
[#36414] Re: 1.8.7 release next month — Luis Lavena <luislavena@...> 2011/05/23

2011/5/23 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#36487] Re: 1.8.7 release next month — Urabe Shyouhei <shyouhei@...> 2011/05/26

Hi Luis,

[#36488] Re: 1.8.7 release next month — Hidetoshi NAGAI <nagai@...> 2011/05/26

From: Urabe Shyouhei <shyouhei@ruby-lang.org>

[#36496] Re: 1.8.7 release next month — Hidetoshi NAGAI <nagai@...> 2011/05/26

From: Hidetoshi NAGAI <nagai@ai.kyutech.ac.jp>

[#36712] Re: 1.8.7 release next month — Urabe Shyouhei <shyouhei@...> 2011/06/03

Ping Luis, how's it going?

[#36748] Re: 1.8.7 release next month — Luis Lavena <luislavena@...> 2011/06/05

On Fri, Jun 3, 2011 at 5:18 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#36434] [Ruby 1.9 - Feature #4774][Open] User Friendly Handling of "Encoding::ConverterNotFoundError" — Lazaridis Ilias <ilias@...>

11 messages 2011/05/24

[#36447] [Ruby 1.9 - Bug #4777][Open] Ruby 1.9.2-p180 ignoring INT, TERM, and QUIT until it receives CONT — Nathan Sobo <nathansobo@...>

10 messages 2011/05/25

[#36559] [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Tom Wardrop <tom@...>

48 messages 2011/05/30
[#36560] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Yukihiro Matsumoto <matz@...> 2011/05/30

Hi,

[#36571] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Anurag Priyam <anurag08priyam@...> 2011/05/30

> Iff 'key': 'value'} means {:key => 'value'} I have no objection.

[#36573] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Yukihiro Matsumoto <matz@...> 2011/05/30

Hi,

[#36578] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Cezary <cezary.baginski@...> 2011/05/30

On Mon, May 30, 2011 at 04:21:32PM +0900, Yukihiro Matsumoto wrote:

[#36580] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2011/05/30

Em 30-05-2011 07:58, Cezary escreveu:

[#36581] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Michael Edgar <adgar@...> 2011/05/30

Since :"#{abc}" is allowed in Ruby, I imagine that any such substitute syntax would preserve that property.

[#36587] Re: [Ruby 1.9 - Feature #4801][Open] Shorthand Hash Syntax for Strings — Cezary <cezary.baginski@...> 2011/05/30

On Mon, May 30, 2011 at 09:05:04PM +0900, Michael Edgar wrote:

[ruby-core:36597] Re: [Ruby 1.9 - Bug #3924] Performance bug (in require?)

From: Xavier Shay <xavier-list@...>
Date: 2011-05-30 22:00:35 UTC
List: ruby-core #36597

On 30/05/11 11:55 PM, Yusuke ENDOH wrote:
> Hello,
>
> 2011/5/30 Xavier Shay<xavier-list@rhnh.net>:
>>> - Please try to minimize a patch.
>>>    - It would be good to use the existing code as possible as you can.
>> I realise this would be ideal, but I can't figure out how it works, or whether it would be compatible with the new algorithm.
>
> Indeed, load.c is very complex, but I believe that this is because
> load.c is an accumulation of bad know-hows in the long history.
> So we should not throw it away without understanding, I think.
This is a fair point. Perhaps a good first step would be trying to 
refactor it with better variable and method names so that the intent of 
the code can reveal itself.

>
>
>>> - It is slightly disturbing to define a new class with Array inherited.
>>>    Is it really needed?  Is there no alternative approach?
>> I agree and wish there was a good alternative. Unfortunately this is necessary because $LOADED_FEATURES is treated like an array by much existing code (particularly tests), but we need it as a case-insensitive hash for the new algorithm. Perhaps the hash could be exposed directly as a class (like CaseInsensitiveHash), but this means more code, is potentially more complicated, and means we are really changing the type of $LOADED_FEATURES. Thoughts?
>
> Aha, I understand why the inheritance is used.  It is to hook the
> array modification, right?
correct

> It is an impossible approach because some extension library can
> modify $LOADED_FEATURES directly by rb_ary_push.
> I found amalgalite to do so actually:
>
> http://www.google.com/codesearch/p?hl=ja#MyfZfO3_1cw/ext/amalgalite/amalgalite3_requires_bootstrap.c&q=LOADED_FEATURES%20lang:c%20rb_ary_push&l=151
>
>> rb_ary_push( rb_gv_get( "$LOADED_FEATURES" ), require_name );
>
It seems that amalgalite is the only extension to do this in that 
search. While I realise that doesn't cover everything, it seems the 
impact is perhaps small? Would it be possible to instead work with the 
maintainer to fix, and publicize this change. It seems and odd API to be 
supporting.

Xavier

In This Thread