[#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:31076] Re: [Bug #3140] gem activation has changed between 1.8 and 1.9

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

> Issue #3140 has been updated by Run Paint Run Run.
> 
> 
>> @runpaint I don't think it does, since comment 17 does a simple require without requiring
>> rubygems or using the #gem command.
> 
> I misspoke. I meant that if it is preceded with `require 'rubygems'` it works as it should. IOW, the 1.8, and arguably correct, behaviour is available by explicitly requiring 'rubygems', meaning that scripts that work under 1.8 will behave in the same fashion under 1.9. Under 1.9, fans of brevity can omit `require 'rubygems'` if willing to accept the altered semantics. This is an uneasy compromise from any angle, but does at least retain backward compatibility.

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. This is totally unfair in light of it basically being a poor approach at optimisation-by-replacement rather than optimisation by profiling and fixing the core problems. See my optimisations of rubygems (which at the moment the most significant impact is a hack to allow not loading plugins). There is more than can be done in this direction, and in my opinion gem_prelude should never have been created instead of doing these optimisations on core. To completely violate semantics and pass issues frequently down to users, and to suggest that they should then fix these issues by invoking bad practices is totally ridiculous, I really can't bring myself to respond to this kind of comment more lightly.

The situation is unacceptable, and its continuation is irresponsible.

> ----------------------------------------
> http://redmine.ruby-lang.org/issues/show/3140
> 
> ----------------------------------------
> http://redmine.ruby-lang.org
> 


In This Thread