[#30545] [Ann] Contribution wanted: identify tickets for 1.9.2 release — Yusuke ENDOH <mame@...>
Hi all --
[#30558] [Feature #3380] Minitest Runner Command — Thomas Sawyer <redmine@...>
Feature #3380: Minitest Runner Command
[#30592] [Bug #3392] Kernel.open Ignores :binmode Key in Opts Hash w.r.t Encoding — Run Paint Run Run <redmine@...>
Bug #3392: Kernel.open Ignores :binmode Key in Opts Hash w.r.t Encoding
[#30602] The `open` Methods and Their Many Arguments — Run Paint Run Run <runrun@...>
I'm documenting Kernel.open, and the related .open methods, for a book
[#30607] [Bug #3395] Ruby does not appear to build against openssl-1.0.0a — Rebecca Menessecc <redmine@...>
Bug #3395: Ruby does not appear to build against openssl-1.0.0a
[#30656] Promote RubyInstaller as better alternative in ruby-lang.org — Luis Lavena <luislavena@...>
Hello,
[#30672] [Bug #3411] Time.local 1916,5,1 #=> 1916-04-30 23:00:00 +0100 — Benoit Daloze <redmine@...>
Bug #3411: Time.local 1916,5,1 #=> 1916-04-30 23:00:00 +0100
Hi,
On Tue, Jun 8, 2010 at 2:58 PM, Benoit Daloze <redmine@ruby-lang.org> wrote:
[#30697] [Bug #3418] IO#putc Clobbers Multi-byte Characters — Run Paint Run Run <redmine@...>
Bug #3418: IO#putc Clobbers Multi-byte Characters
[#30707] [Bug #3420] Module#method calling <=> causes SystemStackError — Florian Aßmann <redmine@...>
Bug #3420: Module#method calling <=> causes SystemStackError
[#30722] [Feature #3424] Source code interaction. [new ideas for ruby 2] — Eloy Esp <redmine@...>
Feature #3424: Source code interaction. [new ideas for ruby 2]
[#30734] [Bug #3428] ri outputs ansi escape sequences even when stdout is not a tty — caleb clausen <redmine@...>
Bug #3428: ri outputs ansi escape sequences even when stdout is not a tty
[#30756] [Feature #3436] Spawn the timer thread lazily — Maximilian Gass <redmine@...>
Feature #3436: Spawn the timer thread lazily
Issue #3436 has been updated by Mark Somerville.
Hi,
(2010/10/08 15:12), Nobuyoshi Nakada wrote:
On Fri, Oct 08, 2010 at 11:12:47PM +0900, Nobuyoshi Nakada wrote:
On Sun, Oct 10, 2010 at 01:27:53AM +0900, Mark Somerville wrote:
On Sun, Oct 10, 2010 at 02:21:41AM +0900, Mark Somerville wrote:
[#30799] PATCH: ENV['key'] = non_string — Ryan Davis <ryand-ruby@...>
Can I commit this please? This drives me bonkers.
Hi,
[#30821] [Bug #3454] Segfault with syscall — Run Paint Run Run <redmine@...>
Bug #3454: Segfault with syscall
[#30855] requires in 1.9 are slower... — Roger Pack <rogerdpack2@...>
Hi all.
[#30882] Was 1.8.7-p299 announced here? — Luis Lavena <luislavena@...>
Hello, tried to look for the release notes or a link, just found the
[#30891] [Feature #3478] Excruciatingly slow pathname implementation — Stephen Touset <redmine@...>
Issue #3478 has been updated by Stephen Touset.
[#30913] String#rindex is faster with Regexps than with Strings? — Kornelius Kalnbach <murphy@...>
hi,
[#30917] [Bug #3487] fiddle pushes arguments in a wrong format — Yuki Sonoda <redmine@...>
Bug #3487: fiddle pushes arguments in a wrong format
On Sun, Jun 27, 2010 at 08:36:45PM +0900, Yuki Sonoda wrote:
[#30927] undefined reference to 'rb_encdb_declare'; ruby-1.9.2-preview3 64-bit on Windows — Chuck Remes <cremes.devlist@...>
[cross-posted to rubyinstaller ML]
On Sun, Jun 27, 2010 at 2:36 PM, Chuck Remes <cremes.devlist@mac.com> wrote:
[#30968] ironruby vs ruby — "C.E. Thornton" <admin@...>
Matz,
On Wed, Jun 30, 2010 at 6:25 AM, C.E. Thornton
Note that Antonio's benchmark compares 64bit IronRuby build against 32bit 1.8.7 MRI and thus favoring MRI.
[ruby-core:30922] Re: able to re-require $0
Hi,
Sorry to "dig up" this thread, but I changed my mind about it, and
intend to report this as a bug.
I think, however, it is better to speak here first.
On 22 January 2010 14:59, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
> Roger Pack wrote:
>>
>> Currently with 1.9.x you cannot "re-require" a file, even if you pass
>> it a different relative path.
>>
>> However, I did notice that you can "re-require" $0
>> ex:
>>
>> bad.rb:
>> require $0
>>
>> Is this a bug, then?
>> -r
>>
> [...]
> ... Ah, I get Roger's point now.
>
>
> bad.rb:
> equire $0
> :foo
>
> $ ruby19 ./bad.rb
> :foo
> :foo
>
> Yusuke ENDOH <mame@tsg.ne.jp>
So the problem is the "main" script is not "loaded" in $", and can
then cause large annoyance.
Of course, no one would probably ever "require {$0,__FILE__,name_of_this_file}"
But, for flexibility and other reasons, many people use something like:
Dir[File.join(File.dirname(__FILE__), "*.rb")].each { |f| require f }
or maybe
Dir[File.expand_path("../*.rb", __FILE__)].each { |f| require f }
This is clearly cleaner than sometimes dozens of requireS.
When you think it could require itself, you may think to add this:
Dir[File.expand_path("../*.rb", __FILE__)].each { |f| require f unless
f == __FILE__ }
But, if another script require this one, __FILE__ may not be absolute,
which obligate you to use:
Dir[File.expand_path("../*.rb", __FILE__)].each { |f| require f unless
File.identical?(f, __FILE__) }
Now, I think I all got you upset, because the wrapping becomes bad,
and this line is way too long for what it does.
(and in Java this is 0 characters, here in Ruby it is about 100 !)
Well, my script hierarchy is probably not the best,
and anyone could do better if he creates some directory and then use
Dir::[] which doe not include the file it is written in.
But, I believe using some scripts in the same directory is the first
and natural structure
when you just want to separate a little your code.
I also think we could do so much better with require_relative (though
it would not be compatible with 1.8).
Something in the lines of:
require_relative '*.rb'
require_relative 'dir/*.rb'
require_relative '**/*.rb'
This would be *really* nice, at least to me.
( The only disadvantage I see of loading 'dynamically' scripts is you
do not control the load order. But this is often not a problem, as all
the code in the methods are evaluated only when everything is loaded.
Only constants and code outside methods can cause some problems )
Do you share my thoughts?
P.S.: I just got the problem now, so please excuse me if I am speaking too hard.
Benoit Daloze