15360-15979

15182-15607 subjects 15570-18422

reopen: can't change access mode from "w+" to "w"?
15360 [rubys@in er ] I ran 'rake test' on test/spec [1], using
+ 15361 [matz@ru y- a] Possibly a bug.  Let me check it.
+ 15362 [ruby-ml@ki t] The error message is ambiguous at least. It means that for some reason,
| 15364 [ruby-ml@ki t] Blah, exactly the wrong angle of explanation and the "analysis" was
+ 15369 [nobu@ru y- a] Here, the mode of STDOUT was changed to "w+" by previos reopen,
  + 15378 [rubys@in er ] Understood.  It works with ruby 1.8.6 (2007-06-07 patchlevel 36)
  | 15408 [nobu@ru y- a] Sorry, it works only in 1.9.
  + 15406 [akr@fs j. rg] This patch makes the first reopen doesn't change to "w+".
    15410 [matz@ru y- a] Can you check it in?
    15415 [rubys@in er ] Is this the way that Ruby 1.9 is expected to behave, so test/spec needs
    15418 [akr@fs j. rg] Does test/spec read from STDOUT or STDERR?
    15419 [rubys@in er ] STDOUT
    + 15448 [rubys@in er ] I've opened a ticket on this issue
    + 15463 [akr@fs j. rg] It's bit surprising.
      15542 [matz@ru y- a] Can you commit the patch please?
      15547 [rubys@in er ] Thanks!

The open-uri problem is due to a change in instance_eval
15365 [dave@pr gp o] obj.extend Meta
15368 [nobu@ru y- a] I think it has been fixed in the repository.

weird behavior of belongs_to referencing a model with set_table_name : a bug?
15375 [yuri.leikind] ...
15376 [now@bi wi se] You really shouldn't have.  This list has absolutely nothing to do
15377 [yuri.leikind] ...

gem versioning patch doesn't seem to have been applied to HEAD
15381 [dave@pr gp o] A while back, I believe that Rich Kilmer created a patch to gems in
+ 15428 [ara.t.howard] i didn't see the patch, but i've had fits with this a few times and
| 15594 [rich@in oe h] The require/load hack in RubyGems before modified the global load path
+ 15469 [drbrain@se m] Try r15423.  Sorry it took so long.

Time#to_date not public?
15382 [transfire@gm] I may have brought this up before and it may already be changed, but
15417 [dan-ml@da 42] I remember that. Doing a bit of spelunking, it seems like in

Have the rules for source file encoding changed?
15383 [dave@pr gp o] Does the -E command line option no longer set source file encoding?
15384 [naruse@ai em] Ni,
15385 [dave@pr gp o] Forgive me being slow today--I've managed to catch the flu and I'm a
15387 [naruse@ai em] -E doesn't set "the encoding for source files".  We call this as "string
15388 [dave@pr gp o] If so, that's a change from a few weeks ago, where -E set the default  encoding for the source code for files that didn't have an explicit
15390 [naruse@ai em] Ahhh, yes, -E set string literal encoding in Ruby 1.9.0.0, and this was

STDIN encoding differs from default source file encoding
15389 [dave@pr gp o] #<Encoding:US-ASCII>
+ 15391 [naruse@ai em] This is spec.  STDIN encoding will be locale when no magic comment and
| 15450 [pbrannan@at ] Thank you for the table.  This makes a lot of sense.  What doesn't make
| + 15451 [matz@ru y- a] "\x81" =~ /foo/
| | 15453 [decoux@mo lo] vgs% locale charmap
| | 15454 [rubys@in er ] $ locale charmap
| | 15455 [decoux@mo lo] no, not really here it's script
| + 15452 [naruse@ai em] Default IO encoding follows Encoding.default_external. So this is
+ 15392 [matz@ru y- a] Not really.  The default external encoding honors your locale setting,
  15393 [dave@pr gp o] OK, that does make sense.. :) Thank you.
  15394 [matz@ru y- a] I feel sorry for that.
  15395 [matz@ru y- a] I mean they SHOULD.  The irb does not work as I (we) expected right now.
  15396 [dave@pr gp o] Ah, thanks for that. I was in the middle of an email about irb... :)
  15398 [matz@ru y- a] It should work if
  15402 [dave@pr gp o] Does that apply to strings containing characters > 127?
  15403 [matz@ru y- a] You've typed "\0x81" i.e. \0, x, 8, 1, four characters instead of one.
  15404 [dave@pr gp o] Oh, I'm having a bad day. More medicine is called for.  Sorry.
  15405 [matz@ru y- a] Get well soon.  Keep yourself warm, take nutritious food, and rest,
  15439 [mneumann@nt ] Couldn't the computer be medicine? ;-)
  15443 [matz@ru y- a] Not for me.  It's drug.
  15449 [mneumann@nt ] Lol. The common approach is to get ill to be allowed to take "medicine".

Non-blocking SSL handshake
15399 [tony@cl ck a] ...
15423 [tony@cl ck a] ...
15424 [mental@ry ia] I would favor this solution myself.
15425 [tony@cl ck a] ...

string[0..-1] no longer uses copy on write
15400 [dan-ml@da 42] As the subject states, in 1.8 string[0..-1] used copy on write but in
15407 [nobu@ru y- a] It works as expected, so may not be called a bug.
+ 15409 [matz@ru y- a] Could you commit?
+ 15416 [dan-ml@da 42] Thank you very much, the patch worked like a charm

Restartable Exceptions (was: Re: Timeout::Error)
15401 [duerst@it ao] Yes indeed. One place where they might help is for code conversion.
15459 [brent@mb ri ] I think a "restartable" Exception could be implemented by
15494 [ks@ku ts ep ] 1) take a block for the continuation,
15516 [nobu@ru y- a] File.open(file, mode) do | fh |

Making Ruby 2038 safe!
15420 [Daniel.Berge] I came across a custom 64 bit localtime implementation. Is this of

Non-local exits via throw/rescue: Re: Timeout::Error
15426 [ks@ku ts ep ] I need to return /something/ to a caller within a fixed time frame or
15437 [mental@ry ia] I do agree on this point.  I just think we need something more along
15460 [brent@mb ri ] MenTaLguY,

Possible bug with bignum.c
15427 [djberg96@gm ] Ruby 1.8.6 (SVN trunk)

rdoc/irb incompatibilities?
15429 [thewoolleyma] I'm new to this list, sorry if this has been covered.
15462 [drbrain@se m] It's a bug, and I don't know if I will fix it for 1.8.  I'll fix it
+ 15467 [thewoolleyma] Thanks.
| 15468 [drbrain@se m] It'll be the same code as in Ruby's trunk, but exposed to a wider
+ 15518 [thewoolleyma] * irb/rdoc bug shown in this thread
  15519 [drbrain@se m] Check the RDoc project on RubyForge.  So far I haven't looked into the
  15527 [thewoolleyma] There are several other open ones, not sure which ones are related to

The future of the 1.8.x branch
15433 [Daniel.Berge] Matz,
15442 [matz@ru y- a] 1.8 remains maintained, the lead maintainer is knu (Akinori Musha).

Instance variable implementation 1.8 vs. 1.9
15438 [rick.denatal] I've been reading the code for both 1.8 and 1.9, and I wanted to make
15441 [matz@ru y- a] Yes, it seems correct.

Your own if/else
15440 [mailing.mr@g] idea if it was replyied, anyway i wanted to share my idea how to make

IRHG -- Dumping T-Nodes
15445 [ceo@ha th rn] OK - Here is the problem
15446 [drbrain@se m] Look at the ParseTree gem.
15447 [ceo@ha th rn] I have been looking a 'rubynode' .
15456 [phlip2005@gm] Yep. For some, the tree is simply a transliteration of the input. 'if x then y
15457 [ceo@ha th rn] Thanks,

Possibly a timeout related problem
15464 [dave@pr gp o] Setting up a sleep seems to interfere with signal handlers. The
15474 [decoux@mo lo] Well, it seems that it's the opposite : sending a signal interfere with
15478 [dave@pr gp o] Yes, but in my case the signal handler never actually executes: the
15499 [decoux@mo lo] Can you try to compile thread.c with -DTHREAD_DEBUG=-1 ?
15502 [dave@pr gp o] Here's what I get

Synced IO seems not to be thread-safe
15465 [dave@pr gp o] STDOUT.sync = true
+ 15470 [pbrannan@at ] Does the problem go away, or is it not apparent without sync?  What
| 15477 [dave@pr gp o] I'm not sure what you're asking, but in a dozen or so runs, it doesn't
+ 15473 [nobu@ru y- a] What's your platform and the version of libc?
  15476 [dave@pr gp o] Sorry, I should have said. It's OS X 10.5.

Finer-grained Alternative to Ruby Safe Levels
15466 [ruby@r8 .o g] I couldn't locate any mention of this subject on the mailing lists or
15511 [matz@ru y- a] Because I'm unsure whether there was a specific reason to provide

where's a complete list of assignment shortcuts? += &= %= etc.
15475 [phlip2005@gm] Google only returns incidental hits for this topic (including the elusive table
15485 [ruby@r8 .o g] Why do you need a *list* of the operators? For that, a quick grep returns
15486 [phlip2005@gm] Because I'm writing a Ruby disassembler, RubyReflector, based on rubynode, which
15489 [drbrain@se m] Look at ParseTree's pt_testcase.rb, and ruby2ruby.

Ruby 1.9.0-1? Ruby 1.9.1? OneClickInstaller191? PickAxe 3?
15479 [ed.odanow@wo] Good Afternoon!
+ 15480 [luislavena@g] I cannot answer all your questions, so I'll jump directly to the ones
+ 15482 [dave@pr gp o] I'm working as fast as I can, but I'm probably about 50% done. Ruby =20
+ 15487 [znmeb@ce ma ] This may or may not be relevant, but I have successfully built and

very bad character performance on ruby1.9
15481 [eric.mahurin] ...
+ 15483 [vincent.isam] I'm surprised that the fastest parsing done in Ruby was with a
| 15490 [eric.mahurin] ...
+ 15488 [matthias@wa ] Eric,
| + 15493 [eric.mahurin] ...
| + 15498 [vincent.isam] Unicode is only one encoding among many. Contrary to other languages
| + 15501 [pbrannan@at ] Immediates have one of the the two lowermost bits set; anything else can
| + 15517 [duerst@it ao] The problem here is that Ruby deals with many other character encodings
+ 15497 [eric.mahurin] ...
+ 15503 [matz@ru y- a] I just checked in some performance tweaking.  The script run still
| 15507 [eric.mahurin] ...
| 15508 [radek.bulat@] SSBoYXZlIHNvbWV0aGluZyBzaW1pbGFyIHRvIHRoaXMgcHJvYmxlbS4KCiM9PT09PT09PQpyZXF1
| 15509 [dan-ml@da 42] What date is your build? On my 1-week-old build of rub y1.9 this was 2x
| 15523 [radek.bulat@] PiBXaGF0IGlzIHlvdXIgbG9jYWxlJ3MgZW5jb2Rpbmc/IFRoYXQgZ3BsLTIuMC50eHQgZmlsZSBj
+ 15579 [charles.nutt] Interesting benchmark; may I include it in JRuby's collection of benchmarks?
  15580 [eric.mahurin] ...

Another data point in the I/O strangeness on OS X
15491 [dave@pr gp o] I'm now also seeing premature EOF during calls to gets() when reading

Changes to Ripper
15492 [pedzsan@gm i] ...

Build failures - Revision 15428
15496 [rubys@in er ] This change caused many build failures for me.
+ 15510 [rubys@in er ] bin/ruby -e "require 'rexml/document'"
+ 15512 [naruse@ai em] This is incorrect and fixed at r15435.
  15514 [rubys@in er ] - Sam Ruby
  15515 [phlip2005@gm] Does "./ruby bin/gem install ..."work?
  15520 [rubys@in er ] $ ruby -v
  15521 [phlip2005@gm] k then that must be on me for leaving ruby in its folder, not installing it, and

Hola!!!!!!
15513 [alexandra.u.] ...

formal argument cannot be an instance variable
15522 [phlip2005@gm] Uh, guys, that can't possibly be a feature, right? Dropping an iter parameter
+ 15524 [rick.denatal] The change seems to be completely consistent with the new semantics
+ 15525 [dblack@ru yp] Block parameter semantics are no longer assignment-based. I'm a bit

Revision 15450 causes core dumps
15526 [rubys@in er ] Revision 15449 tests pass.

Test::Unit maintainer
15528 [kou@co mi ng] Is it right?
+ 15531 [Daniel.Berge] First, a skip method that I can use within the test cases, along the
| + 15552 [ryand-ruby@z] please file these as bugs/feature requests and make sure they're
| | 15553 [Daniel.Berge] Uh, what happened to the Feature Request tracker? It's gone.
| + 15576 [phlip2005@gm] Hmm. The test zealots around here (such as me) will tell you if a test fails you
|   15577 [thewoolleyma] Hehe, I love that.  So true.  The other case of skipping tests is
+ 15533 [phlip2005@gm] Me too. But...
| 15550 [Daniel.Berge] Regards,
+ 15646 [kou@co mi ng] Can I start to improve Test::Unit?
  + 15650 [phlip2005@gm] Per this thread's beginning, you should generally narrow Test::Unit by improving
  | 15652 [kou@co mi ng] class MyGenericTestCase < Test::Unit::TestCase
  | 15653 [phlip2005@gm] I suspect folks typically use 'super' there, right?
  | 15654 [kou@co mi ng] Do your test cases call super in setup? It's difficult to
  | 15655 [phlip2005@gm] I use Rails fixtures, and they bond with their test suites in some curious way I
  + 15664 [ryand-ruby@z] absolutely... how would you like to go about this?
    + 15665 [ryand-ruby@z] put your feature requests in there.
    + 15666 [kou@co mi ng] * Easy to extend. (I think this is the same as yours.)
      15870 [kou@co mi ng] It seems that you are too busy to maintain Test::Unit.
      15970 [ryand-ruby@z] You are absolutely right. I'm catching up with my backlog and burnout.
      15977 [kou@co mi ng] I've confirmed.
      15978 [ryand-ruby@z] preferably 2, as I'm planning on doing a doozy on trunk.
      15979 [kou@co mi ng] OK. I'll use 2.

NODE_NEWLINE > NODE_LAST
15529 [pbrannan@at ] NODE_LAST is 108 but NODE_NEWLINE is 128, because it is defined outside
15541 [matz@ru y- a] Yes, NODE_NEWLINE is a flag, not node type.  Maybe not a good name.
15548 [pbrannan@at ] Why not FL_NEWLINE?

Re: missing ruby_exec()
15530 [masoom.shaik] ...
15532 [nobu@ru y- a] ruby_exec_node()

An Masgn of 1
15534 [wycats@gm il] ...
+ 15535 [akr@fs j. rg] The difference is caused by lambda {} in Ruby 1.9.
+ 15536 [dan-ml@da 42] I was also confused by this behavior so I made a table of the
  15537 [akr@fs j. rg] Blocks are blocks.  It is neigher lambda nor multiple
  15543 [wycats@gm il] I understand the behavior, but I don't understand the *rationale* for
  15545 [akr@fs j. rg] As far as I know, it exists intentionally from the

IRHG -- When GC is processing T_NODES -- Do they follow the VID's
15538 [ceo@ha th rn] I have a question about T_NODE Processing in gc_mark_Children().

IRHG - Slow Child Working?
15539 [ceo@ha th rn] For the life of me ,
15540 [matz@ru y- a] Does the following rewrite make it clearer?
15546 [rick.denatal] Also, you want the break executed regardless of whether the if passed
15556 [matz@ru y- a] Yes, since there should be no object to be marked from the T_DATA when

nd_column for nd_line?
15544 [phlip2005@gm] I'm already usind nd_line, but getting the column of a node would be great too.
15549 [pbrannan@at ] AFAIK this is only known at compile-time.  Take a look at parser_yyerror

[1.9] Proc#curry
15551 [decoux@mo lo] Do I expect too much from Proc#curry ?
15557 [david@da id ] I can't comment on whether or not Guy has found a bug.
+ 15558 [matz@ru y- a] I consider this method (Proc#curry) to be trivial and should be
| 15705 [ser@ge ma e-] charset="iso-8859-1"
+ 15559 [ruby@r8 .o g] It is my understanding that a partial application is the reverse of

IRHG - When Tracing T_NODES in GC -- Does the object pointed to by 'vid' get traced??
15554 [ceo@ha th rn] OK,
15555 [matz@ru y- a] No, from GC point of view, nodes are mere objects to be traced.

Re: Proc#curry
15560 [transfire@gm] Is there a link where I can read about how this new function works?
15561 [matz@ru y- a] [ruby-dev:33676], if you don't mind seeing Japanese ;-)
+ 15562 [phlip2005@gm] Uh, how do we call that?
| 15563 [gregory.t.br] plus_five = proc { |x,y,z| x, y + z }.curry.call(2).call(3)
| + 15564 [james@gr yp ] Did you mean x + y + z there Greg?
| | 15565 [gregory.t.br] Yeah.  whoops.
| + 15566 [Thomas.Enebo] Also in some languages the 2 + 3 can be optimized to only happen once.
|   15567 [Thomas.Enebo] Ignore the question part of that...I have a minor head code today :)
+ 15568 [transfire@gm] Yep. I see.
| + 15569 [binary42@gm ] Isn't that partial application not currying per say (one could curry
| | 15573 [transfire@gm] I've also heard it called "partial currying". I'd rather have a
| | 15668 [transfire@gm] class Proc
| + 15575 [godfat@gm il] You might want to have a look at gem ludy for Proc#bind,
|   15669 [transfire@gm] I suspect you did not need the call to #curry there?
|   15698 [godfat@gm il] Yes, you're right. I forgot to fix my example there (it's just simply
+ 15574 [ed.odanow@wo] This is what I would expect from "currying" (or schnfinkeln). So I
threads.html
top