11576-13175

11367-12635 subjects 11673-12545

^ Array#delete is destructive, String#delete isn't
11576 [florgro gmai] Array has #- for non-destructively removing elements and #delete for
11578 [matz ruby-la] I have no plan to rename String#delete right now.  Strings are
11581 [florgro gmai] Hm, is there a reason against adding String#- as a new name?
+ 11582 [dan-ml dan42] If anything should change, shouldn't it be the other way around? Like
+ 11583 [vjoel path.b] One reason: String#delete can take more than one argument.

^ [PATCH] Problem with ruby 1.8.6-p36 (and p39) on Tiger
11584 [vincent.isam] I investigated more and the function that blocks is

^ Array#values_at bug?
11585 [jflam micros] a =3D [1,2,3,4]
11591 [zhangyuanyi ] Array is a built-in class in MRI, and is implemented by C. You can
11605 [jflam micros] But
11608 [dblack rubyp] The slippery slope :-)  I admit I'm a compatability fan, even for
11610 [charles.nutt] I know it's going to be tempting to fix things that feel inconsistent

^ Is it possible to detect thread switches?
11586 [cfis savagex] This is a cryptographically signed message in MIME format.
+ 11587 [sylvain.joye] For the interested people, see
+ 11589 [laurent.sans] upon specific threading events, in order to properly save and restore

^ Timeout doesn't work correctly under windows when executing complex regexp.
11588 [zhangyuanyi ] To repeat the problem, just execute the below code(I've run it with
11590 [nobu ruby-la] regex.c doesn't include rubysig.h but defines CHECK_INTS in
11592 [zhangyuanyi ] I've found it, interrupt seems be prohibited by default.
11594 [nobu ruby-la] yes.  I guess regex.c should use rubysig.h as well as others.

^ Data_Wrap_Struct for T_CLASS
11593 [vvlad vvlad.] I need to keep some information about some states for a class. This
11595 [nobu ruby-la] Data_Wrap_Struct is specific to T_DATA, but can not be applied

^ Bug in CGI::unescapeHTML?
11596 [esad.talks e] I think there's a bug in CGI::unescapeHTML. Or am I doing something wrong?

^ Optimizing Symbol#to_proc
11597 [murphy rubyc] Greetings to the list!
11598 [sylvain.joye] I don't what the "old Ruby version" was, but I tried to implement mine and
+ 11601 [nobu ruby-la] VM would optimize the block code.
| 11606 [sylvain.joye] What do you mean by that ? It replaces x.send(self) by x.#{send} ?
+ 11607 [murphy rubyc] Yes. Your version doesn't handle multiple arguments like the Ruby 1.9

^ Add args to Singleton instance method?
11599 [ceich62 gmai] I would like to pass args to the initialize method of a class that uses the
11604 [transfire gm] I doesn't make sense to have a singleton object to have state. maybe
11638 [transfire gm] No word. I believe that implementation of Multiton is sound enough,

^ Bug in Kernel#method objects that call super?
11600 [charles.nutt] This seems very wrong to me. Calling through a method object should
+ 11602 [wilsonb gmai] Please please please let this be a bug.
+ 11603 [calamitates ] It's probably a bug. The attached patch seems to fix this. Patch is
+ 11621 [ryand-ruby z] This doesn't seem like a bug to me at all, and seems like it'll
| 11622 [charles.nutt] Having super be dynamic breaks encapsulation in a bunch of ways. Of
| 11624 [charles.nutt] And if you want a dynamic super...you're probably better off explicitly
+ 11634 [charles.nutt] For what it's worth, this appears to work the correct way in 1.9 (always

^ GetoptLong w/ DSL
11609 [transfire gm] Thought I'd share this little piece of code. It provides the option of
11612 [nobu ruby-la] In general, I'd be against hidden instance_eval.
11613 [transfire gm] class DSL
11616 [nobu ruby-la] You can't change the object which is the subject of instance
11617 [transfire gm] what?
+ 11619 [transfire gm] i.e. I don't understand what you mean. Could you explain more?
+ 11620 [nobu ruby-la] @flags = [:help, :h]
  11623 [transfire gm] Ah, I see. Yea, one would just have to know that it's an instance_eval

^ Import gem to Ruby 1.9
11611 [ko1 atdot.ne] Matz plans to import gem into Ruby 1.9.  Does anyone has any
+ 11614 [transfire gm] I think it would be nice to have a way to provide version control for
| 11618 [chneukirchen] +1.
+ 11615 [murphy rubyc] I'm all for it! it will be another Top 10 reason to switch to 1.9. The
| 11626 [drbrain segm] What would it do?  If you don't install any gems, nothing happens.
| 11627 [vincent.isam] If the --disable-rubygems option would be given to configure, the
+ 11625 [drbrain segm] RubyGems uses many features of Ruby, so 1.9's libraries need to be
  + 11631 [tmorgan99 gm] Is this feature planned for the near term?
  | 11639 [drbrain segm] Its in the bug tracker.  RubyGems also wants to be in -core, but
  + 11727 [nakahiro sar] Are you and RubyGems maintainers negative to include RubyGems in
    + 11728 [transfire gm] Unbundle Yaml and Webrick? Are you kidding? Those are bread and butter!
    | + 11730 [james graypr] Yeah, that would be a pretty drastic change.
    | | + 11731 [vincent.isam] import JSON library.
    | | + 11733 [ryand-ruby z] 505 % head -1 version.h
    | + 11734 [ryand-ruby z] So? Installing them via gems changes it how? This would allow them to
    |   11736 [transfire gm] I understand what you are saying but there is an important
    |   11745 [shyouhei rub] Not useful? I don't think so ... Tk is the only GUI framework that comes with Ruby.
    |   11746 [transfire gm] "enough" is the keyword in what I said. Obviously it is useful to
    |   11748 [shyouhei rub] Dedicated GUI... I've never been happy with Smalltalk's.  There are good reasons why
    |   11749 [transfire gm] But it's not likely that you'd use Webrick for a commercial app
    + 11735 [ryand-ruby z] No, I don't think we are. We just have that one feature that we
    | 11779 [chad chadfow] I strongly agree that unbundling a lot of the built in standard libs
    + 11738 [drbrain segm] No, we'd really, really like RubyGems to be in core, but I'd really,
      11752 [nakahiro sar] Thanks for your comments, TRANS, Ryan and Eric.  Good to know you all
      + 11780 [chad chadfow] A built-in require hook would be excellent.  I'm sure I'm going to
      | + 11781 [ryand-ruby z] YAML is just used for the gem index and could be dropped in favor of
      | + 11782 [drbrain segm] On the RubyGems list (or maybe just with Chad) moving everything
      | + 11786 [transfire gm] No at all. That's actually what I've been advocating. But rather than
      |   11788 [drbrain segm] This isn't what Chad is saying.  We're going to add code to call back
      |   11790 [transfire gm] What isn't he saying? He's talking about having RubyGems requiring built-in.
      |   + 11791 [ryand-ruby z] No, he's talking about having the -r flag invoke "require" via
      |   + 11792 [drbrain segm] I already deleted it.  It took me about two minutes to write, though.
      |     11793 [transfire gm] Wow Eric, that was quite an inspective reply. You should thank God
      + 11783 [drbrain segm] Right now gems come before SITEDIR and after RUBYLIBDIR, and this
      | 11784 [nobu ruby-la] You are confused.  SITEDIR comes before RUBYLIBDIR.
      | 11787 [drbrain segm] Yes, sorry, I meant 'ruby -I' and 'RUBYLIB=... ruby' paths.  These
      + 11785 [matz ruby-la] I'm OK for making it bundled if they can make it before the deadline
      + 11794 [nakahiro sar] Thanks all for your discussions.  I updated the list with your comments
        + 11803 [drbrain segm] binary/platform gem support is not absolutely necessary for 1.9.1.
        | + 11806 [nakahiro sar] This mail is for the topic '4. What $LOAD_PATH order should be?'
        | | 11810 [drbrain segm] The work of adding the gem's require_paths to $LOAD_PATH happens in
        | | 11817 [nakahiro sar] Doh.  Sorry for bothering you.  I updated rubygems with
        | | 11818 [drbrain segm] Yes.  Not everybody will need RubyGems.  For example many Rails
        | + 11807 [nakahiro sar] This mail is for the topic
        |   + 11808 [drbrain segm] Oh! I understand now.  I agree with you.  There is no need to merge a
        |   + 11809 [shugo ruby-l] It sounds good to provide 'rather official' repository at
        |     + 11811 [drbrain segm] Also, an index needs to be built when a gem is uploaded.  (Or a cron
        |     + 11812 [ryand-ruby z] YES
        |       11847 [halostatue g] Also, all gems on www.ruby-lang.org should be signed. IMO.
        + 11819 [nakahiro sar] This mail is for the topic
        | 11844 [zimbatm oree] Here is a small script to check the number of loaded classes before and
        | 11845 [evan falling] charset=US-ASCII;
        | 11846 [drbrain segm] $ grep -A4 2007-08-01 ChangeLog
        + 11820 [nakahiro sar] Updated the list.
          12323 [nakahiro sar] It's October, the deadline.  We need to go ahead.
          12330 [drbrain segm] The platform-specific gem handling feature is done, barring potential
          12637 [drbrain segm] I am ready to import RubyGems into trunk.
          + 12641 [duerst it.ao] I haven't read the whole thread in detail, but one of the latest
          + 12642 [matz ruby-la] We are discussing how we call rubygems after the merge.  Possible
            + 12643 [nakahiro sar] I needed to confirm the sense of core team about (c) first.  Sorry not
            | + 12645 [drbrain segm] Please see my notes in [ruby-core:12644].  If RubyGems itself makes
            | | 12652 [nakahiro sar] Definitely.  I want to make sure what they call 'tiny library only for
            | | + 12653 [cdcarter gma] How about something as simple as a 'gem' method defined in Kernel by
            | | | 12657 [drbrain segm] I think the goal is to make Kernel#require do what you mean when your
            | | | 12675 [brent mbari.] Our  embedded Ruby application runs on an ARM processor
            | | | 12677 [luislavena g] I agree that RubyGems is good to be "bundled" with Ruby, but shouldn't
            | | + 12656 [drbrain segm] Ok.  Please keep me up to date on this.  If 0.9.4.5 is not good
            | |   12691 [nakahiro sar] Following is my opinion about enabling rubygems by default.  I posted it
            | |   + 12712 [drbrain segm] We've found that making RubyGems work with other package systems
            | |   | + 12717 [l.g.chin gma] Since there seems to be some confusion, here's a re-translation of
            | |   | | 12729 [charles.nutt] I agree wholeheartedly with this part. A better require/plugin mechanism
            | |   | | + 12730 [chad chadfow] On Oct 17, 2007, at 1:28 PM, Charles Oliver Nutter <charles.nutter@sun.com
            | |   | | + 12731 [drbrain segm] You mean like the one in r13580 mentioned in [ruby-core:13232]?
            | |   | |   12732 [charles.nutt] - Charlie
            | |   | |   12733 [charles.nutt] Sorry, that was Hiroshi talking about Nobu...
            | |   | |   12736 [drbrain segm] I think they went with r13580 instead...
            | |   | |   12738 [evan falling] Thats only one part of the solution though. Everything that wants to
            | |   | |   12742 [charles.nutt] ...and frequently breaking everyone else's hook in the process.
            | |   | |   + 12770 [nakahiro sar] I think there's a consensus about the need.  Nobu's idea is here;
            | |   | |   | + 12777 [charles.nutt] What would find_file look like?
            | |   | |   | + 12783 [akr fsij.org] I think it is good feature.
            | |   | |   + 12801 [why ruby-lan] I thought I'd also mention that the aliasing of `require` is a big
            | |   | |     12829 [nakahiro sar] I don't know freakyfreaky well but how do you flash a new interpreter
            | |   | |     12844 [why ruby-lan] Well, in freakyfreaky's C extension, there's a method called
            | |   | + 12774 [nakahiro sar] On ruby-dev list, Ruby package maintainers are discussing what can be
            | |   | | 12775 [mrueckert su] like debian/redhat packagers? the discussion is in japanese most likely
            | |   | | 12828 [nakahiro sar] Please do so here.  Rubygems-developers ML is good I think.  knu from
            | |   | + 12813 [nakahiro sar] I happened to notice this...
            | |   |   12815 [akr fsij.org] I re-read the IRC session.
            | |   + 12724 [mrueckert su] with the standard ruby directory layout you can share the tree via nfs
            | |     + 12727 [drbrain segm] Could you file a feature request in the RubyGems tracker?
            | |     + 12743 [nobu ruby-la] Strongly agreed.
            | |       12745 [charles.nutt] This also affects JRuby when sharing a gem dir.
            | + 12766 [akr fsij.org] I don't expect version control by default.  It's the feature
            |   12768 [nakahiro sar] Good to hear your opinion.  We ML people heard that you 4 guys 'decided'
            |   12771 [akr fsij.org] Oh, I didn't know that.  Thank you for the information.
            |   12792 [nakahiro sar] No.  It should be enough for that purpose.  Usually gemspec writers do
            |   12798 [akr fsij.org] If nobu's proposal [ruby-core:12770] is accepted, the loader
            |   + 12810 [nakahiro sar] Quick reply for the point about gemloader.rb.
            |   + 12827 [nakahiro sar] Can be.  But it is less related to the original topic, isn't it?
            |     12852 [akr fsij.org] I'm not sure what you want.  However you can use any
            |     12853 [nakahiro sar] It means;
            |     12854 [akr fsij.org] What's advantage over mine?
            |     12857 [nakahiro sar] 2 points.  Your proposal and mine above both enables RubyGems' version
            |     12896 [akr fsij.org] In the IRC session, drbrain said that separating Kernel.gem
            |     12914 [nakahiro sar] Good.  Now #2 is not the problem.
            |     + 12916 [akr fsij.org] The maintenance problem is too important to ignore.
            |     | 12917 [nakahiro sar] to go, RubyGems team will adopt it.  If RubyGem team won't adopt it, it
            |     | + 12918 [nakahiro sar] Oh I forgot to mention.  I don't have any other channel than here to
            |     | + 12935 [akr fsij.org] I see.  The maintenance problem exists until RubyGems
            |     | | + 12949 [akr fsij.org] On second thought, disable-rubygems-loader.rb may be
            |     | | + 12989 [nakahiro sar] Sure.  And your LoadError fallback has the same issue.  The hack should
            |     | |   13010 [akr fsij.org] I maintain it.  So my tiny RubyGems loader has no such issue.
            |     | |   13023 [nakahiro sar] Oh, I didn't think you maintain it.  But let's wait for what RubyGems
            |     | |   13072 [akr fsij.org] RubyGems developers can choose to maintain or not.  I don't
            |     | |   + 13077 [nakahiro sar] I think that RubyGems team possibly does not like this kind of logic
            |     | |   | 13146 [akr fsij.org] The logic is not identical.  RubyGems itself (and yours) is
            |     | |   | 13151 [nakahiro sar] Agreed.
            |     | |   | 13152 [james graypr] I can't speak for everyone, but I've very much enjoyed reading this
            |     | |   | 13174 [nakahiro sar] I don't have enough vocabularies on this kind of... non ruby related
            |     | |   | 13175 [james graypr] There is no hurry.  We can talk about it whenever you like.  I'll be
            |     | |   + 13081 [nakahiro sar] By the way, my proposal is, from the very beginning of this thread,
            |     | + 13011 [akr fsij.org] I talked to ko1.  He is surprised that you think he is a
            |     |   13024 [nakahiro sar] What the point he is surprised with?
            |     |   + 13074 [akr fsij.org] I think he doesn't think he is a member of "core team".
            |     |   | 13079 [nakahiro sar] He's not one of a decision maker of MRI & YARV?  It should be true for
            |     |   + 13169 [drbrain segm] For English-speaking rubyists, "core team" is matz + other frequent
            |     + 13168 [drbrain segm] It could.  I have considered speeding up RubyGems' require, since it
            + 12644 [drbrain segm] I would like to do (b), but (a) is acceptable to me.  I think it is
              + 12646 [murphy rubyc] don't forget performance (interpreter startup time)...on my machine,
              | 12647 [drbrain segm] The following times a representative of the steady state after the OS
              + 12716 [charles.nutt] My only concern with (b) is that it changes the semantics of require

^ Question about String#intern, $SAFE level
11628 [djberg96 gma] if(OBJ_TAINTED(str) && rb_safe_level() >= 1 && !rb_sym_interned_p(str))
11629 [nobu ruby-la] You have created the symbol here.
11630 [djberg96 gma] Whoops! Thanks.

^ Change to pretty-print hash (PP.pp_hash) so keys appear in sorted order
11632 [rocky.bernst] The attached change causes pretty-printing of a hash to show the keys in
11633 [akr fsij.org] pp.rb in Ruby 1.9 sorts hash keys already.

^ to_str conversions and exceptions
11635 [jflam micros] Does Ruby use respond_to? to test for the existence of a to_str method in m=
+ 11636 [charles.nutt] Yes, it does, though I don't believe there's a definitive list of places
+ 11637 [florgro gmai] You will actually need to be careful though. You actually need to call
  11640 [jflam micros] Yep, we'll be calling respond_to? so that folks who override that method will get the behavior that they expect.

^ Re: Proposal: runtime-modifying Kernel methods should be keywords
11642 [marcel verni] I certainly have little influence in this matter, and your appeal is really
+ 11643 [matz ruby-la] I'd like to hear opinions from others, especially from other core
| + 11652 [evanwebb gma] I'm in complete agreement with Charles on this. In fact, the rubinius
| + 11656 [evan falling] I'm in complete agreement with Charles on this. In fact, the rubinius
+ 11644 [charles.nutt] Even this fits well into the proposal. If there were instead keywords to
| 11645 [charles.nutt] Another obvious candidate comes to mind: Kernel#binding.
| 11646 [matz ruby-la] String#gsub ?
| + 11647 [charles.nutt] gsub needs access to internal structures (namely, the in-memory
| | + 11648 [jlam iunknow] +1
| | | + 11649 [w.kelly qut.] Our experience in implementing Ruby.NET has been that much inefficiency
| | | + 11653 [charles.nutt] I'm thinking about and have partially implemented an almost identical
| | | + 11659 [transfire gm] I think 'eval' is a clear choice for keyword. But I'm curious, how
| | | | 11667 [charles.nutt] The tricky part of eval is the implicit binding. If eval always required
| | | | 11670 [james graypr] You lost me here.  module_function works like public/protected/
| | | | 11677 [charles.nutt] Ok, looks like ri is lying then, implying that at least a symbol is
| | | | 11679 [ryand-ruby z] set_method_visibility(module, argc, argv, NOEX_PRIVATE);
| | | + 11664 [florgro gmai] This seems very similar to the optimizations you are using for JS.NET.
| | + 11650 [nobu ruby-la] gsub sets $_ in the caller's scope.
| | | + 11654 [charles.nutt] That's true...and certainly complicates the question. We're again
| | | + 11655 [nobu ruby-la] Sorry, it sets $~, the methods set $_ are IO's methods, #each,
| | | | 11657 [charles.nutt] Evan made a good point on IRC...perhaps both $_ and $~ should be treated
| | | + 11658 [james graypr] Which is probably another feature of questionable value.  I know it's
| | |   + 11660 [hgs dmu.ac.u] <brainstorming purpose="provoke better, more practical ideas">
| | |   | 11661 [james graypr] You could override them to add behavior to them though, right?
| | |   | 11668 [charles.nutt] But you can't.
| | |   + 12133 [murphy rubyc] Is it? I've scanned my local gems, and 29 of 34 use $0-9 somewhere. For
| | |     + 12134 [charles.nutt] I managed to find a way around the $_ and $~ variables being "sudden"
| | |     + 12136 [james graypr] I wasn't speaking of the $0-9 regular expression variables.  Please
| | |       + 12138 [murphy rubyc] I'm sorry! Please ignore my previous comment.
| | |       + 12141 [ mfp acm.org] As nobu said already, gsub actually sets $~, which underlies $0 and friends.
| | |         12142 [james graypr] And just to be clear, I was speaking only of $_ as being a default
| | + 11651 [matz ruby-la] It updates caller's $1 etc.
| | + 11662 [florgro gmai] On Jul 13, 8:55 am, Charles Oliver Nutter <charles.nut...@sun.com>
| |   11666 [charles.nutt] No, I used to think Binding.of_caller was a good idea, but I see a
| + 11674 [steven lumos] Even if everything mentioned became keywords, wouldn't you still have
|   11676 [charles.nutt] I'm not sure how C extensions work, but you could conceivably do it with
+ 11671 [ryand-ruby z] I second this.
| 11681 [charles.nutt] The languages you list either use keywords or expose runtime structures
| + 11682 [calamitates ] Hotspot supports dynamic deoptimization. This enables optimistic
| | + 11701 [jflam micros] Not sure what you mean by this - are you saying that the call site method caches did not improve perf at all in a modified version of Ruby?
| | | + 11707 [charles.nutt] I imagine he means that since Ruby already has method caches in other
| | | | 11711 [calamitates ] I was commenting on the comment. What you are doing is still a bit
| | | + 11710 [calamitates ] Yes and no. Ruby already has a built-in cache. It is a single table,
| | + 11709 [charles.nutt] Ruby's execution model isn't all that much different from the JVM's with
| |   11714 [calamitates ] I was going to reply to this In a detailed manner, but I'm not. (I
| |   11716 [charles.nutt] Feel free to contribute :) I wouldn't mind a few more eyes on the
| |   11718 [calamitates ] Like you said, there are only so many hours in a day, and there are
| + 11719 [nicksieger g] So why not take this argument the other way and work towards defining those
| + 11737 [ryand-ruby z] None of the languages I list use keywords (at least, as we're using
|   + 11739 [brent mbari.] Just a follow up to on the idea of disallowing the
|   | 11740 [charles.nutt] It potentially would require that, and there's also the complication
|   | 11742 [calamitates ] Can you explain this? The way I see this, the piece of code that does
|   | 11743 [jflam micros] What do you do about a method that was changed via eval that is already compiled and partially executed on your return call stack?
|   | 11747 [calamitates ] I was talking about the detection part only (seems I need to work on
|   + 11741 [charles.nutt] I think you're theorizing here about what optimizations are possible in
|     11744 [ryand-ruby z] Wow this is getting frustrating.
|     11750 [calamitates ] I think there are two concepts here that you both are mixing up. One
|     11751 [charles.nutt] I can agree with this...I certainly don't seek the restrictive aspects
|     11753 [calamitates ] I just realized that a %e construct has no obvious way of specifying a
+ 11690 [cdcarter gma] I agree here.  Also, I would like to note that Ruby seems to be moving
threads.html
top