16896-17624

16623-17113 subjects 17116-30833

IRHG
16896 [ceo@ha th rn] Core,
16897 [jeremymcanal] Nothing.  As far as I can remember that syntax has worked.  It made me

Ruby 1.8.7-preview4 has been released
16898 [knu@iD em ns] Folks,
16952 [sunaku@gm il] Is the BasicObject class (from Ruby 1.9) planned to be back-ported to
16996 [knu@iD em ns] I'm afraid it is a bit too radical to change class hierarchy (or

Major performance degradation on trunk
16921 [vsizikov@gm ] Today's revision (r16615) brings Ruby, built from trunk, to a crawl
16924 [matz@ru y- a] It doesn't happen on me (Debian GNU/Linux kernel 2.6.24).  Any profile
16936 [robert.dober] An odd guess here, might this come from the environment, e.g. $RUBY_LIB?
16940 [matz@ru y- a] Usaku Nakamura found the problem and fixed.  Please try the latest.
16941 [vsizikov@gm ] Indeed, revision r16617 fixed the problem and Ruby's performance is

Re: [PATCH] block args w/ defaults (updated)
16943 [eric.mahurin] ...
+ 16944 [radek.bulat@] Q291bGQgeW91IHNlbmQgdGhpcyBwYXRjaCBhcyBhdHRhY2htZW50IHBsZWFzZT8gV2hlbiBJIGNv
| + 16958 [eric.mahurin] ...
| + 16959 [eric.mahurin] ...
+ 16963 [sunaku@gm il] => nil

Oniguruma and \p{Greek}
16945 [dave@pr gp o] # encoding: utf-8
+ 16965 [matz@ru y- a] It's kinda like missing feature.  Add /u prefix explicitly for work
+ 16966 [duerst@it ao] This used to work, but the last time I checked
  16968 [decoux@mo lo] I know nothing about this thing (encoding)
  + 16969 [matz@ru y- a] It worked as we designed.  But this case, we lost script encoding.
  | + 16973 [dave@pr gp o] Rather than using script encoding, perhaps a regular expression that's
  | | 16974 [matz@ru y- a] Basically, it already does.  But we needed to care about compilation
  | + 17025 [duerst@it ao] [written before Matz's additional answer]
  + 16978 [david@da id ] Guy,

Ruby 1.9 "exception reentered"
16951 [p.boekholt@g] I've made a module that embeds a Ruby interpreter into S-Lang
17133 [p.boekholt@g] I've found that when I use ruby_init_stack instead of Init_stack, it
17199 [p.boekholt@g] I've just checked out revision 17082 and now the error is back again??
17227 [p.boekholt@g] * include/ruby/intern.h (Init_stack): make to call ruby_init_stack.
17231 [nobu@ru y- a] It doesn't change ruby_init_stack(), but makes the function
17235 [p.boekholt@g] This is a mystery, because currently I'm not using Init_stack(). I'm
+ 17420 [p.boekholt@g] I've had time to do some debugging, it seems the only place in the
+ 17624 [p.boekholt@g] I've compiled Perl's Inline::Ruby module with edpratomo's patch to get

1.8.6, jemalloc, sock.close problem
16953 [cthompson@ne] In order to reduce the amount of memory that Ruby uses, we are trying to
+ 16962 [drbrain@se m] close(2) itself doesn't have EINVAL listed as one of its error
+ 16970 [rogerpack200] I used to catch Errno::EINVAL when using lots of open file descriptors
  + 16982 [drbrain@se m] If this is a similar problem, recompiling ruby may cause the problem
  | 16985 [drbrain@se m] Sorry, I meant to add without optimizations.
  + 17005 [hongli@pl n9] This sounds like an obvious case of double closing file descriptors.
    17053 [cthompson@ne] Anyone have a dtrace script (for OS X) that I could use to track socket
    17054 [nicksieger@g] "dtruss" comes with Leopard and should probably get you what you need.

ruby-mode.el copyright assignment
16955 [phil@ha el .] A few months ago there was discussion about moving Ruby's Emacs mode
17022 [nobu@ru y- a] Unfortunately, there were some other contributors, but some of
17023 [phil@ha el .] As I understand it this may not be too big of a problem as long as the
17024 [matz@ru y- a] If so, life is much easier.  Primary authors are me and Nobu, and we
+ 17205 [phil@ha el .] Sorry to keep bringing this up, but I asked Chong Yidong, and he has not
+ 17514 [phil@ha el .] There is a form involved for submitting ruby-mode.el into Emacs; if you

Fwd: patch
16972 [rogerpack200] Thanks for patching that!  rev. 16534 works great now in the 1.8.6 branch.

IRHG -- New Release - Chapter 08 Finished!
16976 [ceo@ha th rn] Core,

Array.nitems replacement?
16979 [david@da id ] Array.nitems has just been removed from 1.9, and as near as I can make
+ 16980 [david@da id ] ...
+ 16993 [knu@iD em ns] I didn't think there was a supporter for the method, since even Keiju
  + 16994 [meinrad.rech] ...
  + 16995 [now@bi wi se] Let me assure you, as a programmer that has to work with Microsoft
  + 16997 [haisenko@co ] Well, from the name I would expect "count" to count elements and return the
  + 17003 [david@da id ] I wouldn't call myself a "supporter" of nitems, though I'm a little
  | 17004 [knu@iD em ns] Array#nitems was extended to take a block, and soon later
  + 17006 [knu@iD em ns] I just changed Enumerable#count() to return the number of all elements

Bug in Method#to_proc on method with block
16983 [mikael@ho lu] I seem to have found a bug in Ruby 1.9. Method#to_proc doesn't seem to =20=
16988 [decoux@mo lo] Seems similar to [ruby-core:15551], well if you can make work

[PATCH] ZLIB for MSVC 8 - tar_input.rb
16984 [support@co x] ...
16986 [drbrain@se m] Why did you remove the workaround in tar_input.rb?  I don't see how
16989 [luislavena@g] Also, I'll like to add that I've seen the inflate issue only with
+ 17001 [drbrain@se m] In that case, I think it needs to stay in until the versions of one-
+ 17007 [support@co x] There is no need to remove the patch for older versions, the problem

unexpected return using define_method
17010 [pbrannan@at ] Is this a bug?
17012 [decoux@mo lo] yes and it's known (too lazy to search in ruby-bugs, sorry). More
17014 [pbrannan@at ] How should I expect 1.9 to work?
17015 [decoux@mo lo] Only matz know this and can respond : I don't know if some changes
17016 [knu@iD em ns] You can always look into bootstraptest/test_knownbug.rb for known
17017 [decoux@mo lo] Well I don't think that all known bugs are in this file, some
17018 [knu@iD em ns] True, and you can always ask ko1 to add a longstanding bug that's
17019 [decoux@mo lo] I'm not sure that he'll like it

nd_file no longer used?
17011 [pbrannan@at ] * compile.c, compile.h (ERROR_ARGS), parse.y (node_newnode, fixpos,

error when building 1.8.7 from source with --enable-shared
17026 [radek.bulat@] V2hlbiBJIHRyeSB0byBidWlsZCBydWJ5IGZyb20gYnJhbmNoIHJ1YnlfMV84IHdpdGggLS1lbmFi
17027 [radek.bulat@] VGhlIHNhbWUgZm9yIHNvdXJjZSBmcm9tIHRydW5rLgoKL3Vzci9iaW4vbGQ6IHJlZ2NvbXAubzog

Ruby 1.8.7 has been released
17028 [knu@iD em ns] Folks,

Re: [ruby-cvs:23967] Ruby:r16731: oops
17029 [knu@iD em ns] Please checkout the ruby_1_8_7 branch over again if you have one.

Bytecode handling (compilation) extensions to Ruby 1.9
17030 [ ono@ja a. l] Since 1.9 is YARV VM powered it is technically possible to dump &
17119 [ ono@ja a. l] Since there's no answer to my post :(, I just want to make sure that
+ 17120 [decoux@mo lo] Have you looked at VM::InstructionSequence#to_a,
+ 17121 [ko1@at ot ne] I missed your post.
  17122 [ ono@ja a. l] Ahh, there it is :) Thank you both for pointing me that out. I'll
  + 17123 [ ono@ja a. l] Just wanted to say thanks again, it works like a charm. I've reenabled
  | 17124 [ko1@at ot ne] If bytecode is only "leave", it will cause SEGV ("leave" instruction
  + 17125 [ko1@at ot ne] Evil person can make strange bytecodes.

enc/trans/japanese.c
17031 [support@co x] Line 13334 of enc/trans/japanese.c. struct to_SHIFT_JIS_EF_infos[7] has an
17032 [naruse@ai em] It is my miss that length of to_SHIFT_JIS_EF_infos must be 8 or UNDEF must be removed.

Ruby 1.8.7: ERB is broken
17033 [kirill@sh te] Loaded suite test_erb.rb
17042 [knu@iD em ns] Hmm, someone should have tested erb without strscan.
+ 17043 [knu@iD em ns] Seems this still leaves one failure.  I'll contact the author and be
+ 17044 [kirill@sh te] Yes.
  17046 [kirill@sh te] d.
  17396 [sdsykes@gm i] I notice that ERB is still broken in Ruby 1.8.7.
  17403 [nex342@gm il] I was under the impression that comments were never allowed in ERB. For
  17404 [sdsykes@gm i] OK, fair enough, thanks.

[PATH] Improve Class.allocate documentation
17034 [ramos.gaston] I readed class.allocate's documentation and I think that's
17035 [matz@ru y- a] The patch is too huge for space modification.  It seems actual change
17039 [ramos.gaston] sorry, I attached the new short patch.

Problem with NUM2INT
17036 [hsyl20@ya oo] ...
+ 17041 [nobu@ru y- a] I couldn't reproduce your result, with ffmpeg stuff commented
+ 17048 [decoux@mo lo] Read the warning given by the compiler and correct it.

Re : Problem with NUM2INT
17037 [hsyl20@ya oo] FYI, I just tried with 1.8.7 and got the same result.=0A=0ARegards,=0ASylva=

Ruby 1.8.7 slower than 1.8.6?
17038 [murphy@ru yc] thank you!

Ruby 1.8.7: DelegateClass#respond_to? missing second argument
17045 [jeremy@bi sw] ruby -v -rdelegate -e 'class Foo < DelegateClass(String); end;
17047 [knu@iD em ns] Thanks.  Trunk and ruby_1_8 have been patched, and ruby_1_8_7 will

Re : Problem with NUM2INT
17049 [hsyl20@ya oo] long and not rb_num2int but the result is the same).=0A=0A----- Message d'o=
17050 [decoux@mo lo] For me it say

Re : Problem with NUM2INT
17051 [hsyl20@ya oo] Thanks! It's strange but if I write:=0A#include <ruby.h>=0A#include <ffmpeg=

[Ruby 1.9 - Bug #26] (Open) [DOC] Typo in enumerator.c (Enumerator.new)
17052 [redmine@ru y] Issue #26 has been reported by Arnaud MEURET.

Set#map! vs. map
17055 [dblack@ru yp] => "ruby 1.9.0 (2008-06-03 revision 16244) [i686-darwin9.2.2]"
+ 17056 [matz@ru y- a] Do you want to make a new rule that map should return the object of
| + 17062 [dblack@ru yp] I wasn't thinking of a general rule, just wondering about the case of
| | + 17063 [matz@ru y- a] So, with making a general rule in your mind, what do you think?
| | | 17065 [dblack@ru yp] I don't think map and collect should become different from each other;
| | + 17068 [rick.denatal] ...
| + 17077 [martindemell] I'm personally a fan of #collect returning an array, and #map
+ 17057 [knu@iD em ns] Sounds reasonable, considering in addition that Array#map and
| 17060 [knu@iD em ns] Turns out it was wrong..  I'll back out the change.
| 17066 [dblack@ru yp] I believe you but I'm curious what you decided was wrong about it. Was
| 17071 [knu@iD em ns] It was my assumption that was wrong.  I thought Array#collect returns
| + 17072 [gwtmp01@ma .] If Array#map returns an array and Set#map returns a set, then
| | + 17074 [ara.t.howard] sensible.
| | + 17076 [vjoel@pa h. ] [1, 2, 3].map_as(Set) {|i| i+1}
| | + 17078 [dblack@ru yp] Possibly it should, but not because of Array#map or Set#map. There's
| |   + 17081 [martindemell] Hash#map gets tricky all by itself, too - is it
| |   | 17082 [dblack@ru yp] I should say that, in spite of my having raised the map/map! question
| |   + 17083 [david@da id ] I agree with those who have said that Set.map should return an array as
| |   + 17086 [jim.weirich@] For what it's worth, in Rake, a FileList#map (and other normally array
| + 17080 [dblack@ru yp] OK -- thanks, that makes sense.
+ 17058 [ara.t.howard] [:map!]
| 17064 [dblack@ru yp] I'm not sure what you mean. I didn't suggest there was no Set#map!
+ 17059 [mboeh@de pe ] =3D> #<Set: [1,2,3]>

[Ruby 1.9 - Bug #26] [DOC] Typo in enumerator.c (Enumerator.new)
17061 [redmine@ru y] Issue #26 has been updated by Akinori MUSHA.

Eval'ing 'yield' in 1.8 and 1.9
17067 [vsizikov@gm ] We're writing some new RubySpec tests for Kernel#eval, and I noticed
17070 [matz@ru y- a] It's intentional.  Actually 1.8 behavior is rather accidental.
17075 [vsizikov@gm ] Thanks! So, I'll remove the RubySpec test that enforces this 1.8
17079 [onepoint@st ] Pardon me, but is this really  a good idea?  What happens if different
17089 [vsizikov@gm ] I hear ya! But there is a very fine line between the tests for more or
17105 [onepoint@st ] Sure,  there's a trade-off  between the  concerns of  implementors and

Ruby on zLinux
17069 [eric.dickins] I posted this on the Ruby-Talk list with no success.
17091 [rogerpack200] I've had some luck with installing the mysql binary from source
17099 [eric.dickins] Thank you for the reply. There seems to be a bug in
17104 [charles.nutt] If you have access to Java on that machine, you may be able to run
17112 [eric.dickins] I'm sorry. I thought this is where one would

[PATH] Improve Class.allocate documentation
17073 [ramos.gaston] I readed class.allocate's documentation and I think that's
17096 [matz@ru y- a] Done.  Thank you!

Enumerable::Enumerator#with_memo
17084 [knu@iD em ns] Earlier today I added a new instance method named `with_memo' to
+ 17085 [david@da id ] What does the method do?  What's the use-case?  And can't new methods
| + 17087 [david@da id ] Also, how does Enumerator#with_memo differ from Enumerable#inject?
| + 17095 [knu@iD em ns] e.with_memo(obj) {|(*args), memo_obj| ... }
|   + 17100 [rick.denatal] ...
|   + 17102 [meinrad.rech] ...
|   | 17103 [meinrad.rech] ...
|   + 17107 [david@da id ] Thank you for this clarification.  This seems like a very useful (even
+ 17088 [nex342@gm il] If the method does what it sounds like (returns a new enumerator that
+ 17168 [david@da id ] I'd like to try to revive this thread, if I can.  This seems to me an
| + 17173 [jeremy@bi sw] I think with_memo is adequate. It's clear that it yields the argument
| | 17192 [martindemell] I like the -ing series of names, too. Maybe #accumulating, though
| | + 17193 [jftran@ru yf] reducing ?
| | + 17194 [david@da id ] Martin,
| |   + 17195 [martindemell] Why? It should initialize a to 0, mutate it with each pass due to the
| |   | 17197 [david@da id ] Numeric values are not mutable.  a += 1 assigns a new object to a.
| |   | 17201 [martindemell] Doh! That's a limitation of the method, then, since what we *really*
| |   | 17202 [meinrad.rech] ...
| |   + 17196 [david@da id ] To follow-up on my previous message, perhaps the name "with_constant" or
| |     17210 [dblack@ru yp] "constant" is already a pretty dedicated term, though. with_object
| |     + 17225 [david@da id ] I took the chaining examples over the top here on purpose.  I doubt
| |     | 17230 [dblack@ru yp] => ["a", "b", "c", "d", "e"]
| |     + 17233 [rick.denatal] ...
| |       17236 [dblack@ru yp] I know. It's not just the chaining I'm thinking of, but the whole
| + 17174 [knu@iD em ns] I thought up the name `with_memo' by analogy to with_index, adding a
| + 17176 [dblack@ru yp] The problem with "returning" is that it's in fairly wide use already
|   17191 [david@da id ] I kind of like this idea, but as implemented, this method is only on
|   17223 [rick.denatal] ...
|   17224 [dblack@ru yp] But each is designed and advertised and documented as something you
+ 17184 [meinrad.rech] ...
+ 17238 [knu@iD em ns] Thank you all for your voices!
  + 17239 [meinrad.rech] ...
  + 17240 [jeremy@bi sw] I think introduce is very good name.
  | 17241 [dblack@ru yp] Wouldn't the return value depend on the method you're chaining it to
  + 17242 [david@da id ] I like the succinctness, and it clearly says that a new object is being
    17264 [knu@iD em ns] I thought nobody expects, or should expect anything other than self to

(none)
17090 [hsyl20@ya oo] unsubscribe=0A=0A=0A__________________________________________________=0ADo=

[PATCH] Iconv#iconv(str, start, length) doesn't really convert str[start, length]
17092 [vincentlu@gm] ...
17093 [vincentlu@gm] Just found that the patch doesn't work well with the default value of
17094 [vincentlu@gm] ...
17097 [vsizikov@gm ] So, this is clearly a backwards-incompatible change, since all Ruby
+ 17101 [sunaku@gm il] That is why projects should use the RubyGems rational version
+ 17115 [vincentlu@gm] I Agree. That patch should have been created for 1.9 or later version
  17118 [vsizikov@gm ] 1. ruby_1_8_6 branch: old behavior, out of sync with docs
  17127 [nobu@ru y- a] Sorry, I forgot to commit.

(none)
17098 [jetbillwin@g] ...

r16747: This commit and comment are real?
17106 [luislavena@g] "Remove what have been backported to 1.8.7." just a change in trunk/doc/NEWS
17108 [jan.svitok@g] My guess: the NEWS file describes changes in 1.9 compared to 1.8. As
17109 [luislavena@g] Thank you for your reply Jano, that's the bad part of the feed
17110 [jan.svitok@g] I'm using ruby-changes@quickml.atdot.net mailing list (I guess: send

changed command order in inf-ruby.el
17111 [schulte.eric] When I generate errors in a *ruby* process buffer (in emacs using
+ 17114 [mailing-list] ...
| 17170 [schulte.eric] changed command order in inf-ruby.el
+ 17211 [nobu@ru y- a] It seems set with Emacs 22.2.1.  What's your version?
threads.html
top