15746-33947

15570-18422 subjects 15980-16545

Am I misinterpreting the new keyword arguments to IO.foreach and friends?
15746 [dave@pr gp o] IO.foreach("testfile", mode: "rb", encoding: "ascii-8bit") do
15747 [naruse@ai em] fixed it at r15682.
+ 15748 [dave@pr gp o] Many thanks.
+ 15763 [dave@pr gp o] It looks as if we also ned to cover the open_args: case--does the same
  15766 [naruse@ai em] Oh, sorry.  I fixed line 5930 at r15685.

How should I document Kernel.exit?
15751 [dave@pr gp o] In 1.8, the following code
+ 15757 [matz@ru y- a] No, it should work as 1.8; thank you for reporting.
+ 15769 [matz@ru y- a] I get it.  No bug in finalizer.
  15777 [dave@pr gp o] Aarrgh... Subtle.  Thank you.

local_variables and bindings
15754 [dave@pr gp o] Still a-documenting... :)
15770 [decoux@mo lo] I don't know if it's the expected behavior but for me it was always a known

embedding Ruby 1.9.0 inside pthread
15756 [sunaku@gm il] I am using ruby 1.9.0 (2007-12-25 revision 14709) [i686-linux].
15759 [nobu@ru y- a] You can't call ruby_init() in child threads.
15760 [matz@ru y- a] Because GC needs to know system stack address, that is only taken from
+ 15762 [sunaku@gm il] Ah!  Thank you, both, for the explanation.
| + 15767 [sunaku@gm il] The solution was to use ruby_options() to load the hello.rb file
| | 15771 [nobu@ru y- a] Because you pass wrong argument.  The second argument is a
| | 15794 [sunaku@gm il] Thanks for the explanations.
| + 15772 [hongli@pl n9] You are unlocking a mutex, which was locked by another thread. This is a
|   15793 [sunaku@gm il] You are correct.
|   15797 [hongli@pl n9] This is better, but now your program has a racing condition. Suppose the
|   15895 [sunaku@gm il] Thanks for the correction.  Below is the revised (and more complex)
|   15896 [sunaku@gm il] Whoops, the example had some redundant statements (in the Ruby
+ 15768 [marc-oliver.] This makes it difficult to embed ruby in component framework =

onenine.rb
15774 [transfire@gm] For the next version of Facets I broke out all the methods now
15790 [duerst@it ao] A very minor suggestion: onenine is difficult to read. What about one_nine ?

next(n), succ(n) ?
15775 [transfire@gm] Can anyone see any reason against adding an optional parameter to
+ 15776 [transfire@gm] Ah, don't mind the use of #next here  --I'd be using an "hidden" alias
+ 15903 [transfire@gm] No one has any thoughts on this whatsoever?
  + 15905 [yemi@we df s] That form for Integer is not good as it is not consistent with the form
  + 15906 [chris@po ta ] Could you elaborate on how this is an optimization? This functionality
    15908 [transfire@gm] Yes, that's close. #succ's main use is with Range. Range#step, for

Named captures and regular captures
15778 [dave@pr gp o] It seems that once you have a named capture in a regular expression,
+ 15779 [naruse@ai em] Yes, expected.
| 15780 [dave@pr gp o] Thank you.
+ 15781 [ceo@ha th rn] My God Dave -- Did not know you were that old!
  15782 [dave@pr gp o] Childhood???

Adding startup and shutdown to Test::Unit
15783 [Daniel.Berge] Here are two patches that add startup and shutdown methods to
+ 15784 [Daniel.Berge] Hm, something's goofy. I just noticed that instance variables aren't
| + 15798 [phlip2005@gm] That behavior is by design. The "test isolation" ideal implies you shouldn't
| + 15799 [pbrannan@at ] class MyTest < Test::Unit::TestCase
|   + 15800 [phlip2005@gm] class TestSuite
|   | 15812 [pbrannan@at ] No, that's a class.  It's not instantiated, so you can run any of the
|   | 15813 [phlip2005@gm] Just don't call it a "case" - I suspect some do. Here's Google's first hit for
|   | 15818 [ryand-ruby@z] no, you don't. It is still just a TestCase class... look at test/unit/
|   + 15801 [Daniel.Berge] I can live with that for variables, but it won't cut it for other one
+ 15785 [phlip2005@gm] Will they call around -n test_case if you name just one case, or a range of cases?
| 15786 [Daniel.Berge] I'm afraid I don't follow. They are called once per test suite. The -n
| 15787 [phlip2005@gm] I suspect you are right; I'm just asking standard QA "attack" style questions.
+ 15788 [farrel.lifso] Would it not be better to have a startup and shutdown method for each
  15789 [Daniel.Berge] This is where Nathaniel's terminology gets confusing. It is actually
  15791 [phlip2005@gm] The JUnit (IIRC) trick is a suite inherits a case - the Composite Design Pattern

Just wondering about mod_freeze()
15802 [dave@pr gp o] static VALUE
15803 [matz@ru y- a] Ah, probably.  I will try.

Ruby 1.9.0-1 snapshot released
33947 [matz@ru y- a] I just released released 1.9.0-1 at <ftp://ftp.ruby-lang.org/pub/ruby/1.9/>.
+ 15702 [drbrain@se m] For the next 1.9.0 snapshot, can we get a heads-up on the ruby-core
| 15703 [matz@ru y- a] In the near future, we will prepare RedMine tracker for the core
+ 15706 [shiba@ma l2 ] I'm just curious about what's the substantial difference between 1.9.0-1 and
+ 15708 [dblack@ru yp] I couldn't get it to compile until I changed the revision number in
+ 15735 [k.shutemov@g] Why?
| 15736 [matz@ru y- a] Since 1.9.0 is not stable yet, binary API might change before 1.9.1.
| 15737 [k.shutemov@g] Will it changed back when API become stable? It's not very suitable
| 15739 [matz@ru y- a] Yes, it will be 1.9 when 1.9.1 released.
+ 15806 [matz@ru y- a] なんでこんなにずれてポストされるんだ?

Bugs overview
15805 [jan.svitok@g] I went through some bugs.

Defect for the signal usage of SIGVTALRM in Ruby 1.9 implementation
15808 [chirag80bece] ...
15811 [matz@ru y- a] 1.9 still uses SIGVTALRM for context switching.

defect for the signal usage of SIGINT in Ruby 1.9 implementation
15809 [chirag80bece] ...
15819 [nobu@ru y- a] It would be true, when embedded, but might not be true

IRHG -- Untranslated Header:  =?windows-1252?Q?=3Ch3=3E=3F=3F=3F?= =?windows-1252?Q?=3F=3F=3F=3F=3C/h3=3E?=
15810 [ceo@ha th rn] Need Translation of "<h3>???????</h3>" for IRHG.

[Patch] Improved documentation for mkmf
15814 [hongli@pl n9] ...

IRHG -- Another Attempt to Send Japanese Header!
15815 [ceo@ha th rn] ...
+ 15816 [matz@ru y- a] It's "finalizer".
+ 15817 [laurent.sans] fa i na ra i za -> finalizer

PATCH: mknod and mkfifo support [Was: Ruby does not support mkfifo]
15822 [hongli@pl n9] ...
15823 [hongli@pl n9] ...

[1.9] irb
15825 [decoux@mo lo] To see the problem, you must use a "fresh" installation of ruby

Module#dup
15833 [decoux@mo lo] The example came from [ruby-talk:293497] and because I've not seen it in

Re: IRHG -- Untranslated Header: <h3>???????</h3>
15834 [wilsonb@gm i] You mean "Finalizer"? (ファイナライザ)
15854 [ceo@ha th rn] Yes - Thanks to all that responded!

[RFC] TimeoutError in core, timeouts for ConditionVariable#wait
15835 [mental@ry ia] I've been reworking JRuby's stdlib to improve performance and fix
+ 15836 [mental@ry ia] Meant TimeoutError, of course.
+ 15843 [nobu@ru y- a] Sounds nice.
  + 15844 [mental@ry ia] Could you please explain in more detail?
  + 15868 [mental@ry ia] Even if my initial patch was rejected, I'm still interested in doing

Correct procedure for patch review?
15837 [hongli@pl n9] I've submitted patches several days ago, but there have been no
+ 15841 [duerst@it ao] I think you have done the right thing by sending patches to this list.
| 15845 [hongli@pl n9] Alright, thanks for the explanation. This clears things up a lot. :)
+ 15842 [nobu@ru y- a] Sorry.  I was examining it but hadn't have enough time last
  15846 [hongli@pl n9] No need to apologize. In fact, after reading Martin Duerst's email I

Bug in Fixnum#& with respect to coercion into a bignum
15838 [d.bussink@gm] During some testing with IPv6 stuff, I've found a bug in the handling
+ 15839 [d.bussink@gm] I've found that this issue also applies to Fixnum#[]
+ 15840 [nobu@ru y- a] Thank you for the report.
  15859 [matz@ru y- a] Could you check in?

[PATCH] timeouts for ConditionVariable#wait
15847 [mental@ry ia] Since this first change seems to be uncontroversial, I've attached a
15851 [nobu@ru y- a] Mutex#sleep is not guaranteed that it exits in the specified
15852 [mental@ry ia] It is correct and intended.
+ 15853 [mental@ry ia] To avoid confusion, I do want to be clear that my goal with this patch
+ 15858 [mental@ry ia] Nobu,

What's the current state of * and/or to_a?
15848 [dblack@ru yp] ruby 1.9.0 (2008-02-26 revision 15615) [i686-darwin9.2.0]
15849 [mental@ry ia] I believe the splat operator is based on Array(), not #to_a directly.
15850 [dblack@ru yp] Thanks -- that makes sense.

Ruby 1.8.6 trace return line numbers wrong
15855 [rocky.bernst] ...
15864 [nobu@ru y- a] It yielded the first line of the method.  Although it's
+ 15869 [rocky.bernst] ...
+ 15872 [matz@ru y- a] Can you check in, along with the NODE_BMETHOD change?

Ruby on GPU
15856 [mumismo@gm i] ...
+ 15857 [jameskilton@] I think you're misunderstanding what PyGPU does. PyGPU is simply a
+ 15989 [grabber@gm i] ...

Webrick directory traversal exploit on UNIX
15860 [jos@ca no k.] DSecRG Advisory #DSECRG-08-026 aka -018 describes a remote directory traversal
+ 15861 [shyouhei@ru ] First of all, thank you very much for reporting this.  We will fix this
| + 15863 [ryand-ruby@z] I sent Jos here. I figured that was fine because the issue IS public
| + 15866 [jos@ca no k.] I'm so sorry. It's a false alarm. The reason we were confused was because a
| + 15867 [jos@ca no k.] I will certainly do so. Thank you for the address.
+ 15862 [wilsonb@gm i] The securityfocus link above appears to say that ONLY DOS-like systems
  15865 [jos@ca no k.] No, it was my mistake. The application that tripped the Nessus alarm used to

Sparc architecture optimizations
15871 [Thomas.Enebo] Not sure if he has contacted any core devs about this so I thought I
15959 [Prashant.Sri] Miriam and Darryl are in the compiler team at Sun - I gave their

Ruby1.9 Bug Report #18790
15877 [robert.dober] I have done my best to avoid any doubles, but I just could not find

Ruby 1.8.6 binding value after "if" expression evaluation
15880 [rocky.bernst] ...
15883 [yemi@we df s] ...
15884 [rocky.bernst] ...
15889 [rocky.bernst] ...
15890 [rocky.bernst] ...
15891 [rocky.bernst] ...

IRHG - GC and threads
15885 [ceo@ha th rn] OK Guys,
15888 [matz@ru y- a] No, it marks all threads.

IRHG - GC and Threads - one more question
15886 [ceo@ha th rn] GC runs a  system level - right!

IRHG - Abort Threads?
15887 [ceo@ha th rn] Why is rb_gc_abort_threads() run at the completion of marking?
15894 [matz@ru y- a] rb_gc_abort_threads() terminates unmarked (thus unused) threads.  I

IRHG - Proc End Objects
15899 [ceo@ha th rn] I have not dived into EVAL.C as of yet

Re: embedding Ruby 1.9.0 inside pthread - full example
15901 [sunaku@gm il] ...

Range#member? semantics seem wrong
15907 [dave@pr gp o] Range#member? has been changed so that it the start and end of the
+ 15935 [david@da id ] Actually your sample code also returns true in both 1.8 (at least 1.8.6)
| 15946 [dave@pr gp o] Checking, I agree. I wonder if this is a change since an earlier 1.8.
| 15951 [david@da id ] IIRC, there was a long ruby-core thread about the name of the cover?
| 15952 [dave@pr gp o] I think cover? is fine. But I feel member? is wrong, as it evokes set
+ 15944 [pbrannan@at ] The ChangeLog comment for this change is a little cryptic but references the

RARRAY_PTR
15909 [laurent.sans] Currently, ruby.h defines RARRAY_PTR as a macro to access the internal
+ 15910 [nobu@ru y- a] You mean it has no boundary check?
| 15911 [laurent.sans] Yes, but also this macro assumes that RArray is implemented with a
+ 15912 [matz@ru y- a] How about officially declaring RARRAY_PTR() is read-only?  In fact, it
  15914 [laurent.sans] I have been thinking about this, RARRAY_PTR could return a const
  15916 [evan@fa li g] I second this idea. In fact, Laurent and I have discussed this kind of

Patch for ruby-mode.el: Use run-mode-hooks instead of run-hooks
15915 [pluskid@gm i] ...
15921 [nobu@ru y- a] Major modes should not use this function directly to run their mode
15941 [pluskid@gm i] Yeah! In fact, I encounter this problem when writing the

Ruby 1.9 (trunk) crashes when running RubyGems and Rake
15917 [hongli@pl n9] The end of both backtraces refer to a Mutex#synchronize call.
15919 [nobu@ru y- a] The method is defined in prelude.rb, therefore it must not a
15922 [hongli@pl n9] /home/hongli/Projects/ruby/install-1.9/lib/ruby/1.9.0/rubygems.rb
15923 [pbrannan@at ] I think this is fastthread.
15925 [hongli@pl n9] I didn't install any additional libraries. I ran 'rake' straight after I
15926 [decoux@mo lo] This was from a "fresh" installation ?
15929 [hongli@pl n9] Yes.

[PATCH] make sure version numbers can be determined
15918 [laurent.sans] Someone reported me an installation problem, while installing MacRuby.
15920 [nobu@ru y- a] Thank you, committed with unsetting GREP_OPTIONS.

IRHG -- Depreciated Methods add_finalizer and remove_finalizer Problems
15924 [ceo@ha th rn] The depreciated methods

how to create a block with a block parameter in C?
15927 [pbrannan@at ] irb(main):002:0> class Foo; define_method(:foo) { |x, &b| p x, b }; end
+ 15928 [decoux@mo lo] Not sure, but probably not with your version.
| 15930 [pbrannan@at ] Are you implying that another version might?  I'm using latest svn trunk.
| 15931 [decoux@mo lo] yes, but I don't like it
+ 17143 [ko1@at ot ne] sorry for late response.
  18404 [pbrannan@at ] Ditto.
  18430 [nobu@ru y- a] Although I can't get your point, but this would equal to your
  18440 [pbrannan@at ] This creates a method, not a block.  The original example used

Bug in Thread.set_trace_func
15932 [dave@pr gp o] @@ -2904,7 +2904,7 @@

complex and rational
15933 [dave@pr gp o] Before I start doing the documentation for the PickAxe, could I just
15934 [matz@ru y- a] Unless something bad happens.
15943 [dave@pr gp o] I was wondering if perhaps you were eventually going to work it the
15945 [pbrannan@at ] Do you feel the same way about 'thread' and 'time'?
15949 [dave@pr gp o] Actually, yes, but I can live more easily with than than with complex

Are Depreciated Methods "add_final" & "remove_final" supposed to ACTUALLY WORK?
15936 [ceo@ha th rn] In  Working on IRHG Docs for GC the following
15937 [decoux@mo lo] no, no it work. It's just a little strange :-)
15939 [ceo@ha th rn] I should have been more clear!
15940 [decoux@mo lo] I know, why do you think that I've called ::call_finalizer  which
15942 [ceo@ha th rn] I Stand Corrected! -- OK seems reasonable!
15947 [matz@ru y- a] Additional note: it will be removed from 1.9.

Questions on Enumerator#skip_first and Enumerable#first
15938 [artem.vorozt] I asked in ruby-talk, but did not get answer.
15948 [james@gr yp ] ;)
15950 [artem.vorozt] 1)
15953 [artem.vorozt] I remember Matz talked about LazyArray's in  Ruby 2.0

REXML in patch 1.8.6 patch 111 and 1.9.0
15954 [will.sobel@g] ...
+ 15955 [jan.svitok@g] This is ruby bug #18567 [1], REXML ticket #115 [2].
+ 15956 [phlip2005@gm] Thanks. I have been waiting for y'all to catch that!

Two questions on Encoding#dummy
15957 [dave@pr gp o] ...
15958 [matz@ru y- a] Dummy encodings are placeholders for encodings that cannot be handled
15961 [dave@pr gp o] Thank you.

[PATCH] Dir#inspect
15960 [djberg96@gm ] There's a custom implementation for Dir#inspect in dir.c, but it isn't

update URI to reflect RFC 3986 ?
15962 [jeremy@hi eg] I've been using URI found one issue with URI that is similar to

IRHG - Input needed on alternative GC implementations
15968 [ceo@ha th rn] Dear Core,

[PATCH] fixing test/unit --name
15973 [laurent.sans] Currently, passing --name to test/unit from the command line is broken
15974 [ryand-ruby@z] Good catch. Applied. Thanks!
16062 [pbrannan@at ] I believe this is an alternate fix for bug#10520, which can now be

Bugs in REXML
15975 [federico.bui] I think the following behaviors of REXML can be considered as bugs but I
+ 15976 [federico.bui] d = REXML::Document.new("<root/>")
+ 15982 [meta@po ox c] As the REXML web page says,
  + 15984 [federico.bui] Fair enough, no fix for this then.
  + 15988 [duerst@it ao] No, sorry, not at all. The XML declaration is part of well-formedness,
    15994 [federico.bui] Also, while writing REXML's spec for Rubinius I've found some other
    15999 [rubys@in er ] Please don't take this as being ungrateful, but in order to prevent
    16000 [federico.bui] ...
threads.html
top