[#15359] Timeout::Error — Jeremy Thurgood <jerith@...>

Good day,

41 messages 2008/02/05
[#15366] Re: Timeout::Error — Eric Hodel <drbrain@...7.net> 2008/02/06

On Feb 5, 2008, at 06:20 AM, Jeremy Thurgood wrote:

[#15370] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Eric Hodel wrote:

[#15373] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15374] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Nobuyoshi Nakada wrote:

[#15412] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15413] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/07

Nobuyoshi Nakada wrote:

[#15414] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15360] reopen: can't change access mode from "w+" to "w"? — Sam Ruby <rubys@...>

I ran 'rake test' on test/spec [1], using

16 messages 2008/02/05
[#15369] Re: reopen: can't change access mode from "w+" to "w"? — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15389] STDIN encoding differs from default source file encoding — Dave Thomas <dave@...>

This seems strange:

21 messages 2008/02/06
[#15392] Re: STDIN encoding differs from default source file encoding — Yukihiro Matsumoto <matz@...> 2008/02/06

Hi,

[#15481] very bad character performance on ruby1.9 — "Eric Mahurin" <eric.mahurin@...>

I'd like to bring up the issue of how characters are represented in

16 messages 2008/02/10

[#15528] Test::Unit maintainer — Kouhei Sutou <kou@...>

Hi Nathaniel, Ryan,

22 messages 2008/02/13

[#15551] Proc#curry — ts <decoux@...>

21 messages 2008/02/14
[#15557] Re: [1.9] Proc#curry — David Flanagan <david@...> 2008/02/15

ts wrote:

[#15558] Re: [1.9] Proc#curry — Yukihiro Matsumoto <matz@...> 2008/02/15

Hi,

[#15560] Re: Proc#curry — Trans <transfire@...> 2008/02/15

[#15585] Ruby M17N meeting summary — Martin Duerst <duerst@...>

This is a rough translation of the Japanese meeting summary

19 messages 2008/02/18

[#15596] possible bug in regexp lexing — Ryan Davis <ryand-ruby@...>

current:

17 messages 2008/02/19

[#15678] Re: [ANN] MacRuby — "Rick DeNatale" <rick.denatale@...>

On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:

18 messages 2008/02/28
[#15679] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#15680] Re: [ANN] MacRuby — Yukihiro Matsumoto <matz@...> 2008/02/28

Hi,

[#15683] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Re: gem versioning patch doesn't seem to have been applied to HEAD

From: Richard Kilmer <rich@...>
Date: 2008-02-19 05:23:32 UTC
List: ruby-core #15594
On Feb 8, 2008, at 12:39 AM, ara howard wrote:

>
> On Feb 6, 2008, at 11:08 AM, Dave Thomas wrote:
>
>> A while back, I believe that Rich Kilmer created a patch to gems in  
>> 1.9 that fixed the following:
>>
>> dave[RUBY3/Book 12:05:12] gem list builder
>>
>> *** LOCAL GEMS ***
>>
>> builder (2.1.2, 0.1.1)
>>
>> dave[RUBY3/Book 12:05:16] irb
>> irb(main):001:0> $:.grep /builder/
>> => ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/lib"]
>> irb(main):002:0> gem 'builder', '< 1.0'
>> => true
>> irb(main):003:0> $:.grep /builder/
>> => ["/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-2.1.2/ 
>> lib", "/usr/local/rubybook/lib/ruby/gems/1.9.0/gems/builder-0.1.1/ 
>> lib"]
>>
>>
>> (The 0.1.1 gem is in the include path _after_ the default, so it  
>> won't get loaded by a subsequent require)
>>
>>
>>
>>
>> Dave
>
> i didn't see the patch, but i've had fits with this a few times and  
> spoke with eric about it.  the load path is backwards for sure.  a  
> larger problem, imho, is that gems is loading libraries by  
> manipulating the global load path.  am i the only one that thinks  
> this is evil?  just randomly throwing the load path of a gem into  
> the global path seems fraught with peril to me...

The require/load hack in RubyGems before modified the global load path  
when you loaded a gem.  What this is basically saying is that the  
highest version gem _IS_ part of your load path (again, this is what  
the require/load hack did).  We now just do this explicitly and  
efficiently  up front so we don't have to override require and load  
which was much more evil IMHO.  We now also don't need to load much of  
rubygems  until you explicitly load a Gem of a different version (say  
and earlier version) then it faults in the full gem support.  You can  
always disable it with ruby --disable-gems :-)

-rich

>
>
> on a related note though, and fix will break old code that was using  
> versioning since the load path will end up completely different -  
> it's rather sticky....
>
> a @ http://codeforpeople.com/
> --
> we can deny everything, except that we have the possibility of being  
> better. simply reflect on that.
> h.h. the 14th dalai lama
>
>
>
>


In This Thread

Prev Next