[#15348] Expanding arrays in method calls - why the restriction? — mathew <meta@...>
I can do
[#15359] Timeout::Error — Jeremy Thurgood <jerith@...>
Good day,
On Feb 5, 2008, at 06:20 AM, Jeremy Thurgood wrote:
Eric Hodel wrote:
Hi,
Nobuyoshi Nakada wrote:
Hi,
Nobuyoshi Nakada wrote:
Hi,
Nobuyoshi Nakada wrote:
Joel VanderWerf wrote:
Jeremy Thurgood wrote:
Joel VanderWerf wrote:
Jeremy Thurgood wrote:
Hi,
Jeremy Thurgood wrote:
Jim Hranicky wrote:
Jeremy Thurgood wrote:
Charles Oliver Nutter wrote:
On Thu, 7 Feb 2008 09:37:57 +0900, Kurt Stephens <ks@kurtstephens.com> wrote:
[#15360] reopen: can't change access mode from "w+" to "w"? — Sam Ruby <rubys@...>
I ran 'rake test' on test/spec [1], using
Hi,
In article <20080206043831.7F10DE067F@mail.bc9.jp>,
Hi,
Yukihiro Matsumoto wrote:
In article <47AAE922.5020804@intertwingly.net>,
[#15375] weird behavior of belongs_to referencing a model with set_table_name : a bug? — "Yuri Leikind" <yuri.leikind@...>
Hello all,
[#15381] gem versioning patch doesn't seem to have been applied to HEAD — Dave Thomas <dave@...>
A while back, I believe that Rich Kilmer created a patch to gems in
[#15383] Have the rules for source file encoding changed? — Dave Thomas <dave@...>
Does the -E command line option no longer set source file encoding?
Ni,
[#15389] STDIN encoding differs from default source file encoding — Dave Thomas <dave@...>
This seems strange:
Dave Thomas wrote:
NARUSE, Yui wrote:
Hi,
Hi,
Hi,
Hi,
Hi,
[#15399] Non-blocking SSL handshake — "Tony Arcieri" <tony@...>
Hello. I'm attempting to use SSL within my Fiber-based Actor framework (
[#15400] string[0..-1] no longer uses copy on write — Daniel DeLorme <dan-ml@...42.com>
As the subject states, in 1.8 string[0..-1] used copy on write but in
[#15429] rdoc/irb incompatibilities? — "Chad Woolley" <thewoolleyman@...>
Hello,
On Feb 8, 2008, at 03:50 AM, Chad Woolley wrote:
[#15445] IRHG -- Dumping T-Nodes — Charles Thornton <ceo@...>
OK - Here is the problem
[#15464] Possibly a timeout related problem — Dave Thomas <dave@...>
Setting up a sleep seems to interfere with signal handlers. The
[#15465] Synced IO seems not to be thread-safe — Dave Thomas <dave@...>
Take the following code:
[#15475] where's a complete list of assignment shortcuts? += &= %= etc. — Phlip <phlip2005@...>
Ruby Core:
[#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
Hi,
On Feb 11, 2008 11:51 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
[#15496] Build failures - Revision 15428 — Sam Ruby <rubys@...>
This change caused many build failures for me.
[#15528] Test::Unit maintainer — Kouhei Sutou <kou@...>
Hi Nathaniel, Ryan,
<snip>
Hi Ryan,
Kouhei Sutou wrote:
[#15534] An Masgn of 1 — "Yehuda Katz" <wycats@...>
There's a weird case in Ruby that produces an masgn of a single argument,
[#15539] IRHG - Slow Child Working? — Charles Thornton <ceo@...>
For the life of me ,
[#15551] Proc#curry — ts <decoux@...>
ts wrote:
Hi,
Hi,
Yukihiro Matsumoto wrote:
[#15585] Ruby M17N meeting summary — Martin Duerst <duerst@...>
This is a rough translation of the Japanese meeting summary
On Feb 18, 2008, at 4:33 AM, Martin Duerst wrote:
Martin Duerst wrote:
On 19/02/2008, Gonzalo Garramu単o <ggarra@advancedsl.com.ar> wrote:
[#15589] Different stacktraces in 1.8 and 1.9 — "Vladimir Sizikov" <vsizikov@...>
Hi,
[#15596] possible bug in regexp lexing — Ryan Davis <ryand-ruby@...>
current:
In article <96106826-DFF4-4BFC-9938-3CB54F28F9F1@zenspider.com>,
In article <87wsp177pg.fsf@fsij.org>,
Hi,
In article <20080220125943.78CB3E0297@mail.bc9.jp>,
[#15610] — "David A. Black" <dblack@...>
Hi --
[#15630] embedding ruby | marking and sweeping wrapped structs — Matthew Metnetsky <met@...>
All,
[#15637] Options for String#encode — Martin Duerst <duerst@...>
I just commited a very first implementation of using a hash for
[#15656] defining a method with attached data — Paul Brannan <pbrannan@...>
For various reasons, I need to be able to attached some piece of data to
Attached is a patch to add this feature directly into YARV without a
On Tue, Feb 26, 2008 at 12:54:13AM +0900, Paul Brannan wrote:
[#15667] Gems running aground on multibyte char — "David A. Black" <dblack@...>
Hi --
Hi,
On Wed, Feb 27, 2008 at 1:03 AM, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:
Hi,
On Feb 27, 2008, at 18:27 PM, Nobuyoshi Nakada wrote:
[#15672] File.flock in ruby 1.9.0 — llin <cheempz@...>
Hello,
>>>>> "l" == llin <cheempz@gmail.com> writes:
[#15675] Ruby does not support mkfifo — Hongli Lai <hongli@...99.net>
Today I needed to call mkfifo() and found out that Ruby does not support
[#15678] Re: [ANN] MacRuby — "Rick DeNatale" <rick.denatale@...>
On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:
On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:
Hi,
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
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 > > > >