12294-12791 subjects 12776-13999

StringIO is not IO?
12618 [h.lai@ch ll ] According to irb,
+ 12619 [eric.mahurin] Since StringIO doesn't use IO to base its implementation, it is not an IO.
| + 12622 [h.lai@ch ll ] Well, some of my code can write its output to a file (specified by a
| | + 12625 [evan@fa li g] StringIO is not a subclass of IO because it doesn't share anything
| | + 12626 [sroberts@un ] So does RexML. You see same symptoms when you use open-uri, and then try
| | + 12627 [eric.mahurin] I suggest that you either use another way to figure out how you should
| |   12630 [hramrach@ce ] I also hit this particular case. The question "Is it an IO or a
| + 12624 [Daniel.Berge] This is actually the one case where duck typing burned me. In the
+ 12621 [eric.mahurin] BTW, I asked this same question when I found StringIO.  The answer

Behaviour of String Objects - Why Not "Each" for Characters and Enumerable?
12623 [ed.odanow@wo] I am now a little bit confused. It was 100% understandable for me, that method
12628 [david@da id ] Wolfgang,

file encoding comments and a patch to parse.y
12629 [david@da id ] ...
12650 [nobu@ru y- a] Indeed.  Thank you.
12663 [david@da id ] I see.  My mistake.  Are you anticipating uses of magic comment other
12668 [nobu@ru y- a] The latter.  Is it overkill?

Defining unicode methods
12632 [djberg96@gm ] Ruby 1.8.6
12634 [duerst@it ao] did you try 7. 7 ?
12654 [djberg96@gm ] Right, ok, makes sense. I'd have to modify parse.y to make it work the
12655 [murphy@ru yc] I don't know...is the lex even capable of parsing unicode? if it is, you
12658 [duerst@it ao] The long-time right way would be to split non-ASCII characters into
12680 [murphy@ru yc] you mean, if we want to have user-defined operators? maybe it would make

Proc.yield method
12636 [david@da id ] Here's another question about 1.9 that I'd like to get nailed down so I

New lambda -> syntax
12638 [david@da id ] Just one more Ruby 1.9 question for now and I'll quit for tonight...

test problem after compiling
12639 [duerst@it ao] duerst@Tanzawa /cygdrive/d/ruby/trunk

minor rdoc patch to encoding.c
12664 [david@da id ] ...

Another encoding.c patch
12665 [david@da id ] ...
12667 [drbrain@se m] I'm not sure, but I think marshal_dump and marshal_load are now the
12669 [nobu@ru y- a] Encodings are multiton, but marshal_load have to reinitialize a

encoding.c bug
12666 [david@da id ] ...

Bug in Numeric#divmod
12670 [dirk.traulse] I submitted the following bug report to
+ 12671 [shyouhei@ru ] Perhaps the patch attached to [ruby-dev:28609] helps?
| 12672 [dirk.traulse] I'm sorry, I'm not able to read japanese, so I don't know what the
+ 12673 [znmeb@ce ma ] Gosh ... just when I was getting all smug and complacent, I wandered
+ 12674 [johan556@gm ] The following line in "flodivmod" in "numeric.c" is currently expected
  12678 [dirk.traulse] static void

Minor Array.shuffle patch
12676 [david@da id ] ...

documentation patch for enum.c
12679 [david@da id ] ...

Unicode: Progress?
12681 [murphy@ru yc] The methods that should change the letter case (upcase, downcase,
+ 12682 [ed.odanow@wo] I want to extend the question - are these methods now implemented with respect
| 12684 [matz@ru y- a] pect=20
| 12689 [ed.odanow@wo] I think it will be a good idea to have these functionalities as add on
| 12690 [now@bi wi se] respect
| 12734 [duerst@it ao] The additional data you need to 'upgrade' from case folding to case
+ 12683 [matz@ru y- a] Unfortunately, String case conversion will only work for ASCII region,
  + 12685 [now@bi wi se] My library will do that.  My library is based in part on the code in
  + 12686 [murphy@ru yc] Where would it not be available, for example? Would it be possible to
    + 12687 [matz@ru y- a] Oniguruma does case normalization.  Case conversion both way is more
    | 12699 [nobu@ru y- a] How about this patch?
    | 12700 [murphy@ru yc] works for me. great! it uses Oniguruma's encoding functions, right?
    | 12704 [nobu@ru y- a] Yes.
    | 12786 [duerst@it ao] In UTF-8, there are no bytes with value 0xff and 0xfe.
    | 12796 [nobu@ru y- a] utf8_code_to_mbclen().
    | 12809 [duerst@it ao] Yes, I saw this. When I looked at the log, I got confused again,
    + 12688 [now@bi wi se] This should depend on things like the LANG and LC_* environment

retry: revised 1.9 http patch
12693 [hgs@dm .a .u] I'm reposting this because I've had little response to this version
13098 [aaron@te de ] Is this patch going to make it in?  I would definitely find it useful.
13100 [rogerpack200] ...
13101 [hgs@dm .a .u] If you don't have zlib, then you don't have Rubygems.  ISTR this is
+ 13102 [rogerpack200] ...
| 13115 [aaron@te de ] I would tend to agree.
+ 13150 [nakahiro@sa ] I don't understand this.  Is this true?
  13154 [halostatue@g] The zlib extension for Ruby. It's assumed to be part of the Ruby
  13172 [nakahiro@sa ] I don't use a term "stdlib" or "standard library" (cf.
  13173 [halostatue@g] Yes, I think it should fail. The chances of zlib not being present in
  13176 [hgs@dm .a .u] Interesting.  Rubygems pretty much depends on this at the moment, and

New Rails plugin 'Liftoff' is available.
12695 [nbitspoken@c] Summary
12698 [now@bi wi se] Wrong list.  Please post such announcements to ruby-talk@ruby-lang.org.

Range.first is incompatible with Enumerable.first
12697 [david@da id ] The new Enumerable.first method is a generalization of Array.first to
+ 12701 [rick.denatal] FWIW
| 12702 [david@da id ] But it will work in the sense that it will be consistent with the each
| 12708 [rick.denatal] Correct, it was more of an observation than an objection.
+ 12740 [matz@ru y- a] Indeed.
  + 12741 [murphy@ru yc] I think Range#begin and #end should stay as they are, since - together
  | 12746 [rick.denatal] I took Matz's question as whether or not Range#begin and Range#end
  + 12747 [david@da id ] I agree with murphy and Rick that begin and end should be left as-is.
    12748 [matz@ru y- a] I see.
    12752 [david@da id ] Please let me know if I am making a nuisance of myself, or offer any
    12756 [matz@ru y- a] I know.  I have been addictive for more than 10 years. ;-)

Long encoding names with -K and bad error message
12703 [david@da id ] So now I can write -Kutf-8 on the command line instead of the more
12709 [nobu@ru y- a] It's for the backward compatibility's sake.
12711 [david@da id ] I suspect that is the right thing to do.  It just seems strange that
12722 [david@da id ] ...
12735 [duerst@it ao] I'm not sure why we would want to use "coding" at the top of the
12737 [david@da id ] * parse.y: encoding specifier should work if the line matches
+ 12744 [nobu@ru y- a] Emacs doesn't take care of a variable `encoding', but only
+ 12800 [duerst@it ao] "coding" is the shortest allowed form. Actually, one could use
  12811 [duerst@it ao] Well, thinking this over, the fact that we use #encoding

A couple of bugs?
12705 [jflam@mi ro ] (x =3D 1, puts(x), x)
12706 [gavin.kistne] class E
12707 [marcel@ve ni] At first glance I agree it looks like a bug but it's consistant behavior with
12713 [Tomas.Matous] Well, that's interesting. Then this seems to be the only assignment that ha=
+ 12714 [gavin.kistne] A =3D Class.new
| 12715 [Tomas.Matous] So do you say that the name of the anonymous class is baked when I ask for =
| 12718 [charles.nutt] We support the dynamic assignment of name to class on first const
| 12725 [mboeh@de pe ] =20
+ 12719 [charles.nutt] It would not be directly possible for Class.new to assign a constant in
  12720 [Tomas.Matous] I don't think Class.new should create a new constant. I think it would be m=
  + 12721 [david@da id ] It's actually pretty random. I have no clue what's going on there.
  + 12726 [charles.nutt] I agree it would be a nice addition to the API. At the moment, it would

enum.c patch: fixes Enumerable.cycle and rdoc bugs
12710 [david@da id ] ...
12749 [matz@ru y- a] I will merge the RDoc updates.  Thank you.
12753 [david@da id ] I thought that since the internal array was private to the
12755 [matz@ru y- a] ObjectSpace.  Even though its possibility is fairly low, it's better
12762 [nobu@ru y- a] Why not set the klass to 0?
12788 [matz@ru y- a] Indeed.  Thank you.

Re: [OT] Re: Should *most* memory be release back to the system?
12750 [znmeb@ce ma ] Is this worth making part of the standard Ruby build on Linux?
12751 [mental@ry ia] The downside is that using mmap for every allocation can result in

Improving 'syntax error, unexpected $end, expecting kEND'?
12754 [hgs@dm .a .u] I've had a look at this, but can't see how to do it: When I get
+ 12845 [pbrannan@at ] IMO this is a pretty cryptic message.  It gets easier to diagnose the
| + 12877 [hramrach@ce ] Yes, but the fact that you have unclosed class Foo hints quite a bit
| + 12880 [rick.denatal] Way back in my college days (I'm amazed that my senility hasn't
|   12882 [hgs@dm .a .u] [class Foo;def foo;while true;end;return 42;end;1+2]
+ 12886 [david@da id ] syntax error, unexpected "end-of-file", expecting "end"
  + 12892 [duerst@it ao] This looks extremely helpful, in particular for (relative) beginners.
  | 12893 [david@da id ] Thanks for filling these in Martin.  I worry that this is such a simple
  | 12924 [duerst@it ao] I'm sorry, but I should have compiled these earlier.
  | 12946 [robin@ni or ] - Only Bison understands the syntax with the descriptive name in quotes.
  | 12947 [nobu@ru y- a] Sorry, I've missed it.
  | 12956 [david@da id ] ...
  | 12969 [robin@ni or ] Thanks Nobu, that's good news.
  | 12974 [david@da id ] Yes, the spaces are preserved.
  | 12975 [david@da id ] ...
  + 12976 [nobu@ru y- a] Which version of bison do you use?  Bison 2.3 seems to strip
    12977 [david@da id ] I've got bison 2.0 by default on my Fedora Core 4 system.  See my most

Re: Unicode: Progress??
12757 [brent@mb ri ] Please do consider making unicode dynamically loadable.
12765 [now@bi wi se] That's for Oniguruma.  But yes, unicode should probably be loaded through
12772 [vincent.isam] I understand some people would like Ruby to use less memory. However,
12779 [brent@mb ri ] Actually, upon further reflection, I realized that Linux and must
12780 [brent@mb ri ] This post was really poorly formatted and contained a couple typos.
12781 [vincent.isam] The well supported encodings will probably be UTF-8, Shift-JIS, EUC-JP

12758 [david@da id ] 1) Why do the -K, -E, and --encoding options set primary_encoding, but a
12763 [nobu@ru y- a] Thank you, fixed now.  There was remained old code.
+ 12802 [ed.odanow@wo] What is a "magic coding comment"? - Is it a *nix-specific thing?
| 12803 [nobu@ru y- a] a=20
| 12804 [ed.odanow@wo] This is a good idea, but in addition it might be fine to specify the general
| 12808 [nobu@ru y- a] ral=20
| 12818 [ed.odanow@wo] We have Iconv for doing the job. In the example "abc" the text is encoded by the
| + 12820 [hramrach@ce ] No, these are comments that tell the editor what encoding it should
| | 12823 [ed.odanow@wo] Doesn't this mean, that Ruby has in case of my sources (SciTE) only can decide
| | 12824 [nobu@ru y- a] y the
| | + 12826 [ed.odanow@wo] Unfortunately my knowledge about "EUC-JP" and "Shift_JIS" is best expressed by
| | | + 12839 [ed.odanow@wo] I made some tests with UFT-8, option "-Ku", option "-Ka" and both types of magic
| | | | 12842 [david@da id ] Yes, there are.
| | | | + 12843 [ed.odanow@wo] Thank you very much :-))
| | | | + 12878 [dirk.traulse] So the vim modeline
| | | | | + 12879 [ed.odanow@wo] I made a first test with the result, that it will not be recognized. If there is
| | | | | + 12884 [david@da id ] Correct. Ruby follows Python in this.  See
| | | | + 12881 [hramrach@ce ] Yes, this is true. The -K option also specifies the way standard input
| | | + 12873 [duerst@it ao] There isn't. In a Japanese context, and with a reasonably long
| | |   12875 [ed.odanow@wo] I'm preparing several tests now. There will be nearly all combinations of
| | + 12889 [ed.odanow@wo] I really don't understand what effects the primary encoding has on IO. The first
| + 12869 [duerst@it ao] This isn't sure. For some methods, it may be very easy to validate
+ 12805 [hramrach@ce ] Is that really OK that the comment sets IO encoding? You need to set
  12806 [ed.odanow@wo] A standard system encoding doesn't always exist. I'm using Windows (2000 and
  12807 [hramrach@ce ] yes, I am not saying that the user should not be able to specify

Reading UTF-8 Data contains BOM
12759 [ed.odanow@wo] ...
+ 12760 [ed.odanow@wo] Oops - the attachments are not available via
+ 12761 [ed.odanow@wo] additional questions did arise during my first experiments.

SystemStackError 1.8.6 (stack only 25 frames)
12764 [danj@3s el c] I am trying to resolve a SystemStackError that seems to be the result
12822 [danj@3s el c] I am following up on this topic. Hopefully in the future someone in

\u escapes in string literals: proof of concept implementation
12767 [david@da id ] ...
12769 [nobu@ru y- a] For raw byte data, you can use \x.
+ 12782 [david@da id ] ...
| + 12784 [david@da id ] ...
| + 12831 [matz@ru y- a] I'd happy to merge the third patch, once I've been convinced by option
|   12841 [david@da id ] Are you happy with \u escapes in Regexp literals?  Note that the \u is
|   12862 [duerst@it ao] This may be a somewhat controversial proposal, but while we are
|   12864 [david@da id ] I believe that Java's version of UTF-8 encodes surrogate pairs as two
|   + 12870 [duerst@it ao] This may have been the case for some older (read: by now, really old)
|   | 12872 [david@da id ] Its not UTF-8.  Sun calls it "Modified UTF-8" and it is used internally
|   | 12936 [matz@ru y- a] Actually I hate counting digits.  When I am forced to put sufficient
|   | + 12943 [david@da id ] I've been meaning to ask you about the 8 digits.  Unicode only uses 6
|   | | 12962 [duerst@it ao] As for \U, I think we should stay with the forms we have currently,
|   | + 12980 [david@da id ] In a related matter, Should String.inspect be modified to support \u
|   |   + 13026 [duerst@it ao] You mean when the string is UTF-8, but the primary encoding isn't?
|   |   + 13028 [nobu@ru y- a] \x for other encodings?  It means rb_encoding has to know which
|   |     13032 [david@da id ] Hmm.  I assumed that it would be the inspect method that generated the
|   |     13034 [nobu@ru y- a] Instead, how about to use \x for all encodings, with making
|   |     + 13035 [david@da id ] So if the string encoding is different from the primary encoding, and
|   |     + 13082 [duerst@it ao] Please don't. If you really want, you might use \x{...} for a big-
|   |     | 13231 [nobu@ru y- a] representation but is a "number"'.
|   |     | + 13233 [david@da id ] So the \x escape identifies the codepoint, but not the encoding. Its
|   |     | + 13234 [duerst@it ao] Can you explain how you got these numbers?
|   |     |   13247 [matz@ru y- a] Perhaps JIS 0208 KU for higher byte, and TEN for lower byte, in other
|   |     |   + 13251 [david@da id ] I'd be happy to work on this, using Nobu's patch as a staring place, but
|   |     |   | 13253 [nobu@ru y- a] Thank you.  Please do it.
|   |     |   | + 13264 [david@da id ] ...
|   |     |   | + 13276 [gwtmp01@ma .] I'm just an interested observer of all the M17N work but might
|   |     |   + 13275 [david@da id ] I have checked this in, along with tests in test/ruby/test_unicode_escape.rb
|   |     |     13280 [matz@ru y- a] I don't think I follow the discussion how\x{} behave.  \x{1234} to be
|   |     |     13281 [david@da id ] I believe that is what Nobu is proposing.  That is actually how my first
|   |     |     13282 [matz@ru y- a] OK, let us leave this, until someone really need it.
|   |     + 13092 [hramrach@ce ] No, please don't do that. How do you tell what you are looking at
|   + 12922 [nobu@ru y- a] That's garbage.
|     12923 [david@da id ] That's the option I liked best; I just didn't figure out how to handle
|     12927 [nobu@ru y- a] But it didn't work enough.
|     12930 [duerst@it ao] This would mean that for UTF-8, \x{ABCD} and \u{ABCD} would
|     12934 [david@da id ] I don't like the fact that this proposed new \x{} escape has different
+ 12799 [duerst@it ao] Thanks a lot for working on this. I'm not familar enough with parse.y
  12814 [david@da id ] ...
  + 12821 [hramrach@ce ] I guess you could eval them. That should not kill the interpreter and
  + 12858 [duerst@it ao] Glad they were of use.