[#30995] [Bug #3523] win32 exception c0000029 on exit using fibers — B Kelly <redmine@...>

Bug #3523: win32 exception c0000029 on exit using fibers

19 messages 2010/07/02

[#31100] [rubysoc] Queue C-extension patch to come — Ricardo Panaggio <panaggio.ricardo@...>

Hello,

26 messages 2010/07/07
[#31148] Re: [rubysoc] Queue C-extension patch to come — Roger Pack <rogerdpack2@...> 2010/07/09

> As this it my first patch to Ruby, I don't know where to begin with.

[#31320] Re: [rubysoc] Queue C-extension patch to come — Ricardo Panaggio <panaggio.ricardo@...> 2010/07/16

Sorry for leaving this thread for so long. I've tried to finish the

[#31322] Re: [rubysoc] Queue C-extension patch to come — Aaron Patterson <aaron@...> 2010/07/16

On Sat, Jul 17, 2010 at 06:55:35AM +0900, Ricardo Panaggio wrote:

[#31324] Re: [rubysoc] Queue C-extension patch to come — Caleb Clausen <vikkous@...> 2010/07/17

NB: I am Ricardo's mentor for this project.

[#31331] Re: [rubysoc] Queue C-extension patch to come — Benoit Daloze <eregontp@...> 2010/07/17

On 17 July 2010 06:00, Caleb Clausen <vikkous@gmail.com> wrote:

[#31332] Re: [rubysoc] Queue C-extension patch to come — Caleb Clausen <vikkous@...> 2010/07/17

On 7/17/10, Benoit Daloze <eregontp@gmail.com> wrote:

[#31138] Why is there no standard way of creating a String from a char *? — Nikolai Weibull <now@...>

Hi!

14 messages 2010/07/08
[#31146] Re: Why is there no standard way of creating a String from a char *? — Urabe Shyouhei <shyouhei@...> 2010/07/09

(2010/07/09 7:04), Nikolai Weibull wrote:

[#31149] Re: Why is there no standard way of creating a String from a char *? — Nikolai Weibull <now@...> 2010/07/09

On Fri, Jul 9, 2010 at 06:20, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#31150] Re: Why is there no standard way of creating a String from a char *? — Urabe Shyouhei <shyouhei@...> 2010/07/09

(2010/07/09 18:28), Nikolai Weibull wrote:

[#31217] [Bug #3562] regression in respond_to? — Aaron Patterson <redmine@...>

Bug #3562: regression in respond_to?

14 messages 2010/07/12

[#31269] [Bug #3566] memory leak when spawning+joining Threads in a loop — Eric Wong <redmine@...>

Bug #3566: memory leak when spawning+joining Threads in a loop

14 messages 2010/07/13

[#31399] [Backport #3595] Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string — Dreamcat Four <redmine@...>

Backport #3595: Theres no encoding to differentiate a stream of Binary data from an 8-Bit ASCII string

17 messages 2010/07/21

[#31459] [Bug #3607] [trunk/r28731] Gem.path has disappeared? — Ollivier Robert <redmine@...>

Bug #3607: [trunk/r28731] Gem.path has disappeared?

22 messages 2010/07/23

[#31519] [Bug #3622] Net::HTTP does not wait to send request body with Expect: 100-continue — Eric Hodel <redmine@...>

Bug #3622: Net::HTTP does not wait to send request body with Expect: 100-continue

9 messages 2010/07/28

[ruby-core:31078] Re: [Bug #3140] gem activation has changed between 1.8 and 1.9

From: James Tucker <jftucker@...>
Date: 2010-07-06 10:46:10 UTC
List: ruby-core #31078
On 6 Jul 2010, at 11:38, Run Paint Run Run wrote:

> Issue #3140 has been updated by Run Paint Run Run.
> 
> 
>> I don't agree, this is forcing people to add require 'rubygems' to their code,
>> which is unacceptable as well. Introducing broken semantics into the core
>> language will add support load to rubygems, bundler, debian, rails, and a
>> bunch of other places. 
> 
> We're talking at cross purposes. Prior to 1.9, people already had to add `require 'rubygems'` to their code before requiring a gem. Therefore, given that 1.9.2 will be the first viable 1.9 release, the compulsion is precisely the same as before: on 1.8 and 1.9.2 users will be "forced" to `require 'rubygems'` before loading a gem under traditional semantics. Nothing has changed in this regard.

But users are no longer forced to require rubygems, instead they will hit bugs, and then, due to the nature of most users, they will add those lines to their code, when in reality, it would be better if they use $RUBYOPT or the like. This means that pain is added to their workflow, that is all. It also means (and I'll put good money on this) that a lot of people will backlash and do exactly as you suggest, and actually add `require 'rubygems'` to their runtime code, which is a bad practice.

>> There is more than can be done in this direction... [deletia]
> 
> Which is also what I said. Nobody is suggesting that the current patch is anything approaching ideal. If your proposal meets the myriad requirements, then it will indeed be a welcome replacement.

Can someone summarise those requirements so I can make sure I don't miss any?

In This Thread