15570-18422

15360-15979 subjects 15746-33947

IRHG -  Completed Graphs for GC -- Does anyone disagree with the content of these charts.
15570 [ceo@ha th rn] ...

IRHG -- OOPS Mistake -- Figure 2 goes from Integer to Class Numeric (IE Missing Class Integer)
15571 [ceo@ha th rn] I Will Fix figure two by adding  Class Integer between the

IRHG - Updated Charts for reachable objects (GC documentation
15572 [ceo@ha th rn] ...

Where should shared rdocs be installed?
15578 [transfire@gm] Under a normal installation of a ruby library/program --eg. using
15581 [transfire@gm] /usr/share/doc/{name}/rdoc/

RDoc .document not picking up README
15582 [transfire@gm] Have a little trouble with rdoc using .document file. My .document
15583 [vjoel@pa h. ] Does it work if you reference the files explicitly on the command line?
15584 [transfire@gm] Yes. It does. In my build script, I ended up reading in and parsing

Ruby M17N meeting summary
15585 [duerst@it ao] This is a rough translation of the Japanese meeting summary
+ 15586 [james@gr yp ] Thank you for providing this.
| + 15587 [decoux@mo lo] vgs% ./ruby -e 'p "abcdabcd".gsub(/./, "a" => 1, "b" => 2, "c" => 3)'
| | 15588 [james@gr yp ] I see.  So this translates matches.  Neat.
| + 15598 [naruse@ai em] Only two requirement were discussed.  We are still considering what
+ 15592 [dan-ml@da 42] Thank you very much, these are interesting news to hear about.
| 15601 [naruse@ai em] /ä|å|.../ may be slower than /&\w+;/.  String#gsub seems
+ 15593 [rich@in oe h] Will this include a load_relative to keep things balanced?
| 15605 [akr@fs j. rg] No.  Only require_relative is discussed and accepted.
+ 15633 [ezmobius@gm ] May I suggest we use a stripped down version of rack for the cgi.rb
  + 15635 [jeremy@bi sw] Seconded, though I wish Rack would use a more Rubyish API than
  | 15649 [transfire@gm] I think it's only a good idea if API is much improved. I've use Rack
  | 15651 [ezmobius@gm ] Agreed, I have some ideas for a better api that I am implementing in
  + 15636 [luislavena@g] Even Ruby build isn't as "opinionated software" as is Rails, I second

Different stacktraces in 1.8 and 1.9
15589 [vsizikov@gm ] I'm writing some regression tests for JRuby, to make sure we provide
15590 [nobu@ru y- a] This would be an irb issue.
+ 15591 [matz@ru y- a] Check in please.
+ 15603 [vsizikov@gm ] Thank you very much for the quick response and the fix!
  15604 [decoux@mo lo] Look at vm_send_optimize() in vm_insnhelper.c

Re: [Spam] Ruby M17N meeting summary
15595 [ggarra@ad an] Is this a good idea at all?  Often times, libraries need to be modified
+ 15606 [akr@fs j. rg] I think require_relative should be used in a library or
+ 15608 [hramrach@ce ] You would have to copy (or symlink) the whole library then, not just a
  15609 [radek.bulat@] TXkgZmF2b3JpdGUgaXMgcmVxdWlyZV9yZWxhdGl2ZS4gVGhhbmtzIGZvdCB0aGF0IGNoYW5nZSEK
  15648 [hramrach@ce ] So if I understand this correctly ruby stores the full path to the

possible bug in regexp lexing
15596 [ryand-ruby@z] 501 % irb
+ 15597 [ryand-ruby@z] I should add that I've tested this both on 1_8 and trunk.
| 15599 [matz@ru y- a] Can you commit?  Can you?
| 15623 [ryand-ruby@z] I can, but I'd like to figure out the problems from Tanaka's email
+ 15600 [akr@fs j. rg] Not good idea.
  15602 [akr@fs j. rg] % ./miniruby -e 'p %r(\))'
  + 15624 [ryand-ruby@z] thanks... I'll look into these problems and try to find a compromise.
  | 15627 [rick.denatal] I think that Akira-san brought up a subtle point, which might have
  | 15629 [akr@fs j. rg] If two syntax have same semantics, we can change one to
  + 15625 [nobu@ru y- a] I think it ambiguous, whether it means an escaped terminator or
    15628 [akr@fs j. rg] We need to define two syntax to three semantics
    15631 [nobu@ru y- a] Am I missing any meta characters?
    15642 [akr@fs j. rg] "^", "$".
    15644 [ryand-ruby@z] Tanaka has a good point... Matz? Should we just escape em all?
    15647 [akr@fs j. rg] Isn't it the current behavior?
    15657 [akr@fs j. rg] (c != '\\' || c != term) is same as
    15663 [ryand-ruby@z] Right... that was what I was confused by, and I read the intent as

(none)
15610 [dblack@ru yp] I'm trying to get a fix on thread behavior in 1.9 vs. 1.8.6, and the

Re: threads at end of programs in 1.8/1.9
15611 [dblack@ru yp] Whoops, no subject line -- I'm adding one.
15613 [matz@ru y- a] The pthread context switching is far more complex than the green
15614 [dblack@ru yp] OK -- I just wanted to be sure I was interpreting it correctly.
15616 [mental@ry ia] I think it sort of falls under the general rule where if you want two

Stange error when using profile.rb on Ruby 1.9
15612 [tony@me io .] ...
15618 [tony@me io .] ...

Re:
15615 [ruby@r8 .o g] Was order of execution in Thread ever guaranteed? The output, for instance,
15617 [dblack@ru yp] i don't think it was guaranteed but I was seeing patterns of results

IRHG - In GC -- What is difference between Dyna_Vars and Local_Vars?
15619 [ceo@ha th rn] In GC -- What is difference between Dyna_Vars and Local_Vars?
15620 [matz@ru y- a] Yes, even though they are categorized by same local variables in the

IRHG -- One more quick question - When are FRAMES Generated?
15621 [ceo@ha th rn] One more quick question - When are FRAMES Generated?
15622 [matz@ru y- a] When you see PUSH_FRAME in eval.c

Readline and Revision 15546
15626 [luislavena@g] * ext/readline/readline.c (readline_event): prevent polling. based on

embedding ruby | marking and sweeping wrapped structs
15630 [met@ub rs at] All,
15632 [vjoel@pa h. ] It's actually the other way around: marked objects are _not_ freed. They
15634 [met@ub rs at] =20

Options for String#encode
15637 [duerst@it ao] I just commited a very first implementation of using a hash for
+ 15638 [duerst@it ao] I should have added that quite some of the options below were
+ 15639 [naruse@ai em] Suffix "ncr" felt too short.  :dec_charref and :dec_charref seems better.
+ 15640 [dave@pr gp o] I'm getting slightly concerned about the intellectual surface area of
| 15643 [naruse@ai em] Even if no options, all functions which those options will help are
+ 15641 [gwtmp01@ma .] Instead of a :block option, simply yield to the block if it is given.
+ 15645 [naruse@ai em] First of all, String#encode should be a simple API.  For complex uses,

defining a method with attached data
15656 [pbrannan@at ] For various reasons, I need to be able to attached some piece of data to

purpose of macros in node.h
15658 [pbrannan@at ] #define NODE_METHOD NODE_METHOD

[PATCH] Re: defining a method with attached data
15659 [pbrannan@at ] Attached is a patch to add this feature directly into YARV without a
15661 [pbrannan@at ] And another one for the Ruby 1.8 branch.
15662 [pbrannan@at ] Oops, forgot the attachment.
15758 [nobu@ru y- a] I guess that feature could be achieved with rb_proc_new() and
15761 [pbrannan@at ] 1. In 1.8, procs cannot take a block parameter

mkmf.rb - warning: empty expression
15660 [pbrannan@at ] [pbrannan@zaphod md]$ cat extconf.rb

Gems running aground on multibyte char
15667 [dblack@ru yp] I'm doing lazy evaluation of this problem -- meaning, if anyone spots
15670 [ryand-ruby@z] ...
+ 15671 [nobu@ru y- a] In 1.9, input encoding is defaulted to US-ASCII, therefore
| 15674 [halostatue@g] I'm releasing an updated version soon in any case (to just fix this
| 15677 [nobu@ru y- a] Use magic comments.
| 15681 [drbrain@se m] There is a problem with backwards compatibility, I think.
| 15695 [naruse@ai em] The encoding of YAML file is UTF-8 or UTF-16 by the yaml spec.
| + 15699 [mumismo@gm i] ...
| | 15700 [naruse@ai em] On UCS Normalization, that's reasonable.
| + 18388 [mame@ts .n .] ===================================================================
|   18422 [drbrain@se m] I have added myself a note to fix this in RubyGems 1.3.
+ 15676 [dblack@ru yp] I don't exactly why it's pointing at the ' but I'm pretty sure it's

File.flock in ruby 1.9.0
15672 [cheempz@gm i] I'm having trouble getting File.flock to work in non-blocking mode, in
15673 [decoux@mo lo] The problem is that 1.8.6 test if LOCK_NB was given, or if ruby has only
15795 [cheempz@gm i] A follow-up, for ruby 1.9.0 (2008-03-01 revision 0) [i686-linux].
15796 [decoux@mo lo] I can't reproduce it
15807 [nobu@ru y- a] It's the revision that I fixed the bug.  Thank you.
15820 [cheempz@gm i] Thank you both for working on such a wonderful language :)

Ruby does not support mkfifo
15675 [hongli@pl n9] Today I needed to call mkfifo() and found out that Ruby does not support
15875 [matz@ru y- a] (1) mknod and mkfifo are not ubiquitous.
+ 15876 [Daniel.Berge] =20
+ 15878 [hongli@pl n9] Actually, I am writing a deployment system for Ruby on Rails. And I'm

Re: [ANN] MacRuby
15678 [rick.denatal] Interesting stuff.
15679 [laurent.sans] True.
15680 [matz@ru y- a] I still think having dedicated syntax for Objective-C call is better
+ 15682 [rick.denatal] or
| 15685 [laurent.sans] You can do that right now with MacRuby.
+ 15683 [laurent.sans] I have been thinking about this too, but I personally believe that it
  + 15684 [matz@ru y- a] You can still map one-argument method to duck.foo(1) as it does now.
  | + 15686 [laurent.sans] Yes, but it won't be consistent with multiple-argument calls then.
  | + 15694 [ruby-ml@ki t] Actually, this would be a really great time to talk about trying to unify
  |   15697 [rick.denatal] Except, as I understand the discussion, here duck is a variable
  + 15687 [evan@fa li g] I thought about working up for Objective-C calling support via this
    + 15688 [rich@in oe h] O[duck foo:1, bar:2]
    | 15692 [rick.denatal] Or
    | 15693 [laurent.sans] The problems with these syntaxes are that it's hard to parse them, and
    | 15696 [rick.denatal] One thing that's yet to be mentioned is that the Ruby keyword
    + 15689 [laurent.sans] Your idea is surprising, but how would you do to override an Objective-C method?
      15690 [rich@in oe h] Oh right, duck.foo 1, bar: 2 ... not duck foo:1, bar:2 :-)
      15691 [laurent.sans] Yes you can put or remove spaces, parenthesis, etc...

Ruby 1.9.0-1 snapshot released
15701 [matz@ru y- a] I just released released 1.9.0-1 at <ftp://ftp.ruby-lang.org/pub/ruby/1.9/>.

Proc#curry doesn't work on func which produces func
15704 [godfat@gm il] Proc#curry doesn't work on function which produces function,
+ 15716 [decoux@mo lo] Well another possibility is that when curry() is called the first time
+ 15721 [mame@ts .n .] I want to say it's bug.  Please don't blame Proc#curry ;)
  15722 [decoux@mo lo] It's really difficult to make this ?
  15723 [mame@ts .n .] Are you saying about [ruby-core:15716] ?
  15724 [decoux@mo lo] yes,
  15725 [mame@ts .n .] Aha, I didn't know what Symbol#to_proc is.  It is indeed a
  15744 [ser@ge ma e-] charset="iso-8859-1"

Schedule for the 1.8.7 release
15707 [knu@iD em ns] After seeing Ruby 1.9.0-1 released earlier today, I, as the release
+ 15745 [pbrannan@at ] Would it be possible to add the patch from [ruby-core:15662]?  I have a
| + 15749 [knu@iD em ns] You need to give a convincing example or two out of "a lot" to show
| | 15764 [pbrannan@at ] 1. In Rice (http://rice.rubyforge.org) we attach data to a function so
| + 15752 [Daniel.Berge] Do you think that could eventually be used for method annotations in a
|   15765 [pbrannan@at ] This particular implementation could not be used for general method
+ 15750 [rocky.bernst] ...
| 15753 [Daniel.Berge] What patch was that?
| 15755 [rocky.bernst] ...
+ 15971 [knu@iD em ns] We have two more days before the feature (list) freeze.
  + 15972 [rocky.bernst] ...
  | 16003 [knu@iD em ns] It has been handled, thanks.
  + 16004 [knu@iD em ns] We will be working on backporting the features that are currently on
    + 16006 [decoux@mo lo] Well, there is [ruby-core:15833] Module#dup give something strange.
    + 16117 [knu@iD em ns] As I have not been able to spend time for Ruby the last couple of
    | 16312 [knu@iD em ns] Sorry for the delay again, but it will require some more time for me
    | 16331 [david@da id ] Are all the methods (Object.tap, Proc.curry, Symbol.to_proc and so on)
    | 16377 [knu@iD em ns] Sorry for replying too late,
    | 16383 [knu@iD em ns] I have finally done most of the backporting tasks.  Yes, finally.
    + 16144 [jan.svitok@g] Basically this prevents reusing Net::POP objects - once it obtains
      16145 [matz@ru y- a] Done.  Thank you.

capitalize and downcase
15709 [transfire@gm] I've always wondered why String#capitalize downcases the whole string
+ 15712 [rick.denatal] Rick DeNatale
| 15714 [transfire@gm] Yes, thanks.
| 15718 [jim.cropcho@] ...
+ 15731 [matz@ru y- a] I consider the behavior of "capitalize" to be "make the first letter
  15792 [meta@po ox c] The Oxford American Dictionary says

Ruby 1.9.0-1 repacked (Re: Ruby 1.9.0-1 snapshot released)
15710 [matz@ru y- a] I am awfully sorry.  I made a last minute bug in the packaging

bootstrap/test_knownbug.rb
15711 [decoux@mo lo] I think that it's useless to add [ruby-core:15551] in test_knownbug.rb
15719 [decoux@mo lo] I've forgotten to say : [ruby-bug:17846] for qtruby is just a call to
15720 [decoux@mo lo] it's                       [ruby-bug:17946]

Ruby String hash key overflow when converting to Fixnum.
15713 [pluskid@gm i] It is said the issue will be automatically post
15715 [nobu@ru y- a] Then, shouldn't all results be in the Fixnum range?
+ 15717 [pluskid@gm i] Yeah, a more complete solution.
+ 15732 [matz@ru y- a] Could you check in?

openssl, zlib1 on windows
15726 [masoom.shaik] ...
15727 [luislavena@g] To build the zlib and openssl extensions you needa have the proper
15738 [masoom.shaik] ...

Question on build process - skipping unsupported extensions
15728 [djberg96@gm ] When building Ruby from source, how does it know to skip over extensions
+ 15729 [usa@ga ba ec] Normally, win32ole will never be built on non-Windows platforms.
| 15733 [djberg96@gm ] Right, but how do I do it without having to be explicit? I'm trying to
| 15734 [nobu@ru y- a] In extconf.rb, you can check the target platform or necessary
| 15743 [djberg96@gm ] Oh, silly me, now that I look at win32ole it checks for windows.h or it
+ 15730 [phlip2005@gm] That's what automake's configure is for. Enter ./configure --help, then look in

Copy-on-write friendly garbage collector
15740 [hongli@pl n9] I've written patch which makes Ruby's garbage collector copy-on-write
+ 15741 [dan-ml@da 42] AFAIK, the 1.9 garbage collector has always been COW-friendly.
+ 15742 [matz@ru y- a] Here's the patch against the latest trunk (r15675).  It's still 8-10%
  + 15773 [ggarra@ad an] Matz,
  + 15824 [hongli@pl n9] It's good to know that the patch isn't in limbo. :) But what is
  | 15826 [pbrannan@at ] If what Matz says is true, that it's 8-10% slower than the current
  | 15827 [hongli@pl n9] I've looked for ways to optimize it, but the bitfield implementation
  | 15828 [vjoel@pa h. ] And 4 extra bytes per object will use more cache, so it's not clear
  + 15829 [dan-ml@da 42] Matz, what do you consider would be an acceptable tradeoff in speed for
    + 15830 [dan-ml@da 42] ...
    | + 15831 [dan-ml@da 42] ...
    | | 15832 [matz@ru y- a] Binary search is a preparation for making heap segment size smaller
    | + 15873 [hongli@pl n9] ...
    |   + 15874 [matz@ru y- a] I will merge the patch into my personal repository.  Thank you.
    |   + 15879 [dan-ml@da 42] Thank you. I also looked at find_position_in_bitfield() but I assumed
    |   | 15881 [hongli@pl n9] My patch is against 1.8, which doesn't have sorted heaps.
    |   + 15913 [hongli@pl n9] ...
    + 15882 [hongli@pl n9] Yes, I'd like to know this as well. What would be an acceptable
    + 15892 [hongli@pl n9] More optimization updates. I'm currently working on pluggable mark table
    | 15893 [dan-ml@da 42] So the GC method could be dynamically changed to cow-friendly just
    | 15897 [hongli@pl n9] Actually, I'm thinking about requiring the script call "GC.cow_friendly
    | + 15898 [meinrad.rech] the name cow_friendly could be misinterpreted by some cow boys ^^. how
    | + 15900 [djberg96@gm ] I recommend against this. Most people are simply not going to know
    |   15902 [hongli@pl n9] ...
    |   15904 [vjoel@pa h. ] I can certainly see a need for this as an _option_, even if it does cost 5%.
    + 15963 [hongli@pl n9] Sorry for mentioning this again, but it has been almost a week since my
      15964 [matz@ru y- a] It works on my machine.  But since it slows down Ruby a bit, we
      15965 [hongli@pl n9] - Standard Ruby: 13.600 seconds
      15966 [matz@ru y- a] I feel this one is bit too simple.  Since GC behavior heavily depends
      + 15967 [hongli@pl n9] It loads Ruby on Rails (2.0.2), then runs garbage collection in a child
      + 15969 [vjoel@pa h. ] Very artificial: [ruby-talk:186561]
threads.html
top