9725-9948 subjects 10135-11186
Re: ruby 1.9.0 /home/yuesefa/project/ruby/import/import.rb:6:in `new': failed to allocate memory (NoMemoryError) from /home/yuesefa/project/ruby/import/import.rb:6:in `block in <main>' from /home/yuesefa/project/ruby/import/import.rb:4:in `times' fro
9947 [yuesefa@gm i] ...
sandbox 0.4 (r115) with a new patch
9949 [why@ru y- an] Okay, here's the latest release of the freaky freaky sandbox.
+ 9950 [nobu@ru y- a] The tarball seems not to contain patch directory.
| 9951 [why@ru y- an] Okay, fixed. Thankyou, Nobu!
+ 9967 [andre@di ir ] Is it possible to have access to a constant from a module defined
9970 [why@ru y- an] Sandbox#import copies only classes. I should add some options for
9971 [andre@di ir ] s.eval "p M.method_missing(:const_get, :FOO)"
Re: Error when trying to build trunk
9954 [nobu@ru y- a] lex.c is broken, probably is empty.
+ 9956 [nicolas.desp] I've got the same problem and it is empty localy. Somehow, all its
+ 9957 [nobu@ru y- a] Correct lex.c is in SVN, but it can be created from keywords file with
rb_cProc and rb_cBinding defined twice in trunk
9958 [vincent.isam] ...
9979 [ko1@at ot ne] Thank you. I'll fix it.
[ ruby-Bugs-7974 ] anonymous classes share single alloc function
9959 [noreply@ru y] Bugs item #7974, was opened at 2007-01-18 13:28
9962 [nobu@ru y- a] rb_class_new() creates a Class instance merely, without corresponding
9968 [mental@ry ia] Thanks! I guess this means that calling rb_singleton_class() on the
9975 [nobu@ru y- a] Yes, it should make the code work.
Scoping and locating definitions
9960 [jos@ca no k.] require 'lib'
+ 9963 [drbrain@se m] Currently you can't.
| 9965 [jos@ca no k.] Right. I think it's important that the language supports this though.
+ 9964 [pit@ca it in] Jos, using this library
9966 [jos@ca no k.] Thanks Pit, I'll have a look and will report back.
9972 [jos@ca no k.] After looking at this I'm not sure how this helps me. Can you give an example
+ 9974 [nicolas.desp] Maybe, you can copy the Process class to ProcessOriginal and then
| + 9977 [jos@ca no k.] Well, it's not there there is no workaround (I called it AProcess) but I
| + 9980 [sroberts@un ] Process = Class.new # Causes a warning, as well it should, but you
| 9983 [jos@ca no k.] Personally I think that's ugly. Except for some primitive classes I shouldn't
+ 9982 [pit@ca it in] require "import-module"
9984 [jos@ca no k.] [great example snipped]
9985 [pit@ca it in] Jos, just out of curiosity, could you show us (or me via private mail,
9986 [jos@ca no k.] Pit, I'm really sorry but I'm not well-versed enough in Python to be able to
9987 [terry@li eo ] I'm that colleague. I'm not the world's best Python expert either,
9989 [nightphotos@] As you pointed out, this is a trade off between having a powerful
9990 [jos@ca no k.] A typical example (correct me if I'm wrong) would be for somebody to override
[ ruby-Bugs-7989 ] signal 4, Illegal instruction.
9961 [noreply@ru y] Bugs item #7989, was opened at 19/01/2007 01:41
Allowing Unicode in the grammar?
9969 [Daniel.Berge] One of the things Fortress allows you to do is use Unicode in the language itself. For example, instead of '==', you use '¡Ô'(U+2261). For those unable or unwilling to use that, Fortress also provides a macro equivalent such as 'EQ'.
9973 [now@bi wi se] (Yeah, sorry, I'm not Matz, but I just couldn't help myself.)
9988 [djberg96@gm ] No problem. I suppose I should have opened this question up to everyone.
compiling on AIX using IBM compiler
9976 [foskey@op us] I am compiling ruby on aix to play with puppet control system.
How to help ruby 1.9 ?
9978 [vincent.four] I am wondering: how can we help development of Ruby 1.9 and YARV ? I
10031 [ko1@at ot ne] No information there. Summarize BUGs (narrow down repeatable code) is
[ ruby-Bugs-8026 ] YAML fails to parse its own input
9981 [noreply@ru y] Bugs item #8026, was opened at 2007-01-20 18:44
[ ruby-Bugs-8050 ] SystemStackError thrown if ruby_init is called on a longer stack than other ruby functions
9991 [noreply@ru y] Bugs item #8050, was opened at 2007-01-22 13:29
[ ruby-Bugs-8055 ] Error in Socket sample code
9992 [noreply@ru y] Bugs item #8055, was opened at 2007-01-21 22:46
9993 [matz@ru y- a] Fixed in the trunk. Should be applied to 1.8 anytime later.
[ ruby-Bugs-8058 ] debug.rb: setting breakpoints using Class.method or Class:method doesn't work
9994 [noreply@ru y] Bugs item #8058, was opened at 2007-01-21 22:38
[ ruby-Patches-8062 ] Added documentation for Hash about how it uses eql? and hash methods for the keys
9995 [noreply@ru y] Patches item #8062, was opened at 2007-01-22 12:41
new method dispatch rule (matz' proposal)
9996 [ko1@at ot ne] This post is translation of [ruby-dev:30107], a new method dispatch rule
+ 9997 [binary42@gm ] The combination of 1 and 2 effectively gives private methods a
| 9999 [matz@ru y- a] We will not have function_missing, since public methods are searched
+ 9998 [matz@ru y- a] Thank you.
+ 10000 [charles.nutt] It's late for me here, so I have just brief comments below...
| 10001 [matz@ru y- a] Yes.
| 10009 [charles.nutt] But for calls that could result in both private and public methods being
| 10023 [matz@ru y- a] For functional style call, yes. The increasing costs are
| 10026 [charles.nutt] I believe that Rule 4 itself is good and correct, and it mimics how
| 10028 [matz@ru y- a] Rule 4 without rule 3, ... hmm. That means you cannot override any
+ 10002 [dan-ml@da 42] class A
10003 [matz@ru y- a] No. Private methods do not have separate namespace, so the second foo
+ 10004 [james@gr yp ] That seems like a positive change to me.
| 10005 [hgs@dm .a .u] Interesting. Doesn't this mean more care will be needed to develop
| 10006 [matz@ru y- a] I don't think so. Polymorphism wouldn't happen for private methods by
| + 10007 [shugo@ru y- ] I worry this change breaks Open Closed Principle....
| | 10010 [matz@ru y- a] If compatibility weigh most. Adding more visibility may cause
| | + 10011 [now@bi wi se] Tuesday, 23 January, 2007: The day "final" was introduced in Ruby. It
| | + 10012 [Daniel.Berge] How about 'final'? I mean, if a final class is one that can't be
| | + 10013 [marcel@ve ni] To keep the 'p' theme going: petrified ;)
| | + 10036 [shugo@ru y- ] How about `internal' or `sealed'?
| | + 10041 [paulo.koch@g] How about hidden?
| | + 10042 [matz@ru y- a] Others suggested 'final'. But if we adapt rule 4 without rule 3,
| | 10045 [evan@fa li g] To go with the p names, I was thinking personal. The methods we're
| + 10008 [hgs@dm .a .u] Aha! I see what you mean now. For B to 'know' that bar must be
+ 10017 [dan-ml@da 42] Ok, if private methods are not in a separate namespace, what happens here?
10018 [matz@ru y- a] Can I suppose B inherits A?
+ 10020 [evan@fa li g] I wanted to chime in with my feelings on this. I personally dislike
| + 10022 [matz@ru y- a] The point is that, as Ruby grows, the requirement for managing name
| | 10030 [dan-ml@da 42] class MessageQueue
| | 10033 [matz@ru y- a] This is very rare case that
| | 10046 [evan@fa li g] Ok, but where to you warn about it? If the answer is at runtime, then
| | 10047 [matz@ru y- a] I was thinking runtime, in slower traversing search. There's no
| + 10025 [charles.nutt] I agree here as well. Setting simpler logic for dispatching should be
| 10029 [nicksieger@g] ...
+ 10024 [dan-ml@da 42] So private and public methods *do* have different namespaces, in
10027 [matz@ru y- a] Yes.
10048 [evan@fa li g] The more this discussion goes on, the more I worry that Joe Q Public
+ 10049 [zdennis@mk e] This is similar to how Java treats private methods.
+ 10054 [matz@ru y- a] (a) my original proposal
+ 10056 [joshua@re er] Could you also summarize the intent behind these schemes? Rules are
| 10057 [matz@ru y- a] The point is that, as Ruby grows, the requirement for managing name
| 10063 [Daniel.Berge] If naming conflicts really are a concern as Ruby grows, then we need to
+ 10059 [sroberts@un ] A < B < C
| 10062 [evan@fa li g] I specified 'defining class' but it should have been 'defining class/
+ 10060 [evan@fa li g] (3) Ordinary style calls will skip any private methods.
10065 [charles.nutt] I think Evan and I actually have proposed the same thing in roundabout
+ 10069 [matz@ru y- a] There are some code that override methods that are called via
+ 10071 [dblack@wo bl] Is that specifically the goal? I'm not a Java programmer (I come at
10078 [charles.nutt] Maybe not matz's goal, but it's the visibility model that makes the most
[Patch] fix mkconfig.rb for autoconf 2.61a
10016 [mrueckert@su] the patch fixes building with autoconf 2.61a.
stable branch policy & schedule for 1.8.6
10019 [knu@iD em ns] Core developers,
+ 10021 [charles.nutt] I am not a core developer, but I am a JRuby developer. The schedule and
| + 10032 [vjoel@pa h. ] rbtree, as long as we're voting for core inclusions.
| | + 10035 [drbrain@se m] Who uses this?
| | | + 10038 [james@gr yp ] The standard set library will make use of it if it is present.
| | | | 10043 [vjoel@pa h. ] How will it help the Set library?
| | | | 10044 [vjoel@pa h. ] Sorry, I see it now. SortedSet uses rbtree if it's available. I was
| | | | 10052 [hgs@dm .a .u] So why don't we have heaps in the core, then? They are good for
| | | + 10039 [sroberts@un ] a_hash.keys.sort.each do |k|
| | | + 10051 [sylvain.joye] I wrapped std::set in my own library. Fast set operations (union,
| | | + 10053 [chneukirchen] I used it in some of my code, and would use it a lot more if it wasn't
| | + 10055 [knu@iD em ns] Since the subject line has 1.8.6 in it, let me make it clear: for 1.8,
| | + 10058 [mental@ry ia] fastthread is also different in that it isn't a new library, but a re-implementation of an existing one (thread.rb). The patch for 1.8 would simply replace much of thread.rb with a "require 'thread.so'" that implemented the same classes.
| | + 10073 [mental@ry ia] 426&atid=3D1700
| | 10082 [knu@iD em ns] Thanks, I'll take a good look at it. In addition to the patch, do you
| | 10128 [mental@ry ia] No, only some unit tests which attempt to test the basic properties of
| | 10191 [knu@iD em ns] Sorry for the delay.
| | + 10192 [james@gr yp ] I think you have a very good plan.
| | + 10211 [why@ru y- an] knu, you are doing a terrific job.
| + 10034 [mental@ry ia] First I must prepare a patch against ruby_1_8 to submit for inclusion.
+ 10109 [mrueckert@su] please consider the patch from
| + 10110 [knu@iD em ns] OK, thanks for the reminder.
| + 10152 [knu@iD em ns] Nobu committed a fix for ruby_1_8 a couple days ago, and I've just
| 10166 [mrueckert@su] i will recheck with 2.61a.
+ 10141 [dharple@ge e] Will 1.8.6 be able to run why's [Sandbox extension] without any
+ 10144 [charles.nutt] Sandbox would be nice. We already support the Sandbox API in JRuby
+ 10148 [why@ru y- an] Most of my patches are kosher, but I have one patch which could be
[ ruby-Patches-8127 ] ftp.rb raises an error that is not an FTPError on certain error conditions
10040 [noreply@ru y] Patches item #8127, was opened at 2007-01-24 21:05
[ ruby-Patches-8134 ] Sony Playstation Portable Support
10050 [noreply@ru y] Patches item #8134, was opened at 2007-01-25 08:19
fastthread (Was: Re: stable branch policy & schedule for 1.8.6)
10061 [mental@ry ia] Actually, guys, let's defer further discussion of fastthread inclusion until I've got the patch ready and submitted to the Ruby patch tracker. We can't ask Akinori to make a decision on something that doesn't exist in its final form yet.
[ ruby-Bugs-8153 ] [BUG] unknown dvar (args)
10064 [noreply@ru y] Bugs item #8153, was opened at 2007-01-25 21:36
[ ruby-Bugs-8156 ] class variables and inheritance
10066 [noreply@ru y] Bugs item #8156, was opened at 2007-01-25 15:05
10067 [matz@ru y- a] It's no bug. In 1.8 class variables are shared among subclasses.
10083 [escii@ho ma ] How about instance variables, Are they shared among subclasses, and will
10084 [dblack@wo bl] Instance variables belong to instances. They have no concept of class
10105 [matz@ru y- a] No, ;-)
Re: Method Dispatch (was Adding methods to String, but only in my own Module?)
10068 [gwtmp01@ma .] ruby-core: this was originally just a response to Jos, but it has some
+ 10070 [matz@ru y- a] Keiju Ishitsuka, who named Ruby 14 years ago, once developed a library
| 10075 [matz@ru y- a] It's available from
| 10080 [gavin@re in ] alternative proposals for syntax names and whatnot...what
+ 10074 [jos@ca no k.] Well put, thank you Gary.
[ ruby-Patches-8168 ] improved C implementation of thread.rb ("fastthread")
10072 [noreply@ru y] Patches item #8168, was opened at 2007-01-25 23:03
[ ruby-Bugs-8174 ] Strange behaviour of iterator variable inside eval
10076 [noreply@ru y] Bugs item #8174, was opened at 2007-01-26 14:50
10081 [matz@ru y- a] It surely is a bug. I will fix it very soon.
10077 [tomuhs@gm il] ...
Array Expansion Stack Level Too Deep
10079 [zdennis@mk e] I haven't looked into this yet, but came across this in a weird edge case where array expansion causes system stack error,.
Collaborative Ruby Language Specification
10085 [jflam@mi ro ] I thought I'd throw out some suggestions about creating a formal specificat=
+ 10086 [now@bi wi se] ? Ruby's not being developed by Microsoft, so why would their "rules
| + 10087 [phurley@gm i] If Microsoft wants to pay a smart (and nice) guy like John to work on
| | 10090 [now@bi wi se] I'm obviously a stupid (and unpleasant) guy unlike John, but what list
| + 10091 [now@bi wi se] I guess the "here" threw me, but that shouldn't come as a surprise
| + 10093 [dblack@wo bl] All the Rubys out there should run the same things with the same
| + 10111 [ceo@ha th rn] Dear Core Colleagues,
+ 10094 [dblack@wo bl] I'm not sure what there is to be non-neutral about :-)
| 10095 [jflam@mi ro ] Here's the problem: there are going to be multiple implementations of Ruby in the wild. And for those who run in other VMs, there will be compatibility problems. It's up to the spec to make determinations about what are 'important' incompatibilities vs. 'unimportant' incompatibilities. For example, which Ruby C libraries will be deemed to be 'unimportant' and not something that must be ported to a 3rd party VM in order for that language to be called 'Ruby'.
| 10096 [dblack@wo bl] If it's a matter of the applicability of the name Ruby, then Matz is
| 10097 [dblack@wo bl] I should add: I'm not unwilling for Ruby Central to get involved in
| 10099 [jflam@mi ro ] I'm sorry - I didn't mean that Ruby Central would make final technical decisions - that's clearly Matz's job. However, there are lots of administrative and sponsorship issues where it makes sense for a neutral organization to drive it. Witness the Python Software Foundation and how they drive their process.
| 10106 [dblack@wo bl] I think that's right, if you mean things like ISO certification (or
+ 10098 [jflam@mi ro ] YARV, Rubinius, jRuby and (I think) CLR people were all represented.
| 10103 [charles.nutt] Knowing Ryan it's probably a pretty liberal license. Also see the tests
+ 10102 [charles.nutt] I hope such a spec would be developed "in the open" from the beginning,
+ 10107 [charles.nutt] Porting...delicious porting.
+ 10108 [charles.nutt] - Yes, ideally all "pure Ruby" apps should run, provided they don't use
| 10112 [eustaquioran] I was checking some CLR opinions and - correct me please if I'm wrong - seems
| 10113 [now@bi wi se] As far as I understood it, a big reason for removing contiuations is
| 10115 [binary42@gm ] Continuations are not being "removed." At least the removal hasn't
| + 10116 [jflam@mi ro ] On the CLR front (and I'm pretty sure on the JVM front as well) continuations pose a very major problem for implementers. It's a difficult problem to solve while preserving decent performance characteristics. And the approaches that have been attempted in the past (like exploiting the exception facilities of the runtime) don't hold forth the promise of future performance improvements.
| | + 10117 [dblack@wo bl] Well, as a community of people giving advice and feedback to the
| | | 10119 [eustaquioran] I fully agree with you.
| | + 10121 [gwtmp01@ma .] Do you have any pointers to resources (papers, blog entries, source
| | 10145 [charles.nutt] The latter. The JVM and CLR do not provide any way to manipulate the
| | + 10150 [gwtmp01@ma .] Interesting. I was going to suggest that maybe you could use threads
| | | 10153 [charles.nutt] Well, I'm not suggesting that Ruby itself should be held back by other
| | + 10154 [charles.nutt] I would never suggest such a thing. There are already features in C Ruby
| + 10122 [eustaquioran] * Ruby 1.9.1 will not have continuation, since they have lowest
+ 10118 [jflam@mi ro ] It's absolutely my intent to make sure that any spec is developed in the open. Believe me when I say that I'm seriously constrained in terms of what I can do outside of Microsoft vs. inside. It's *much* easier to get stuff done inside the company vs. getting stuff done outside. So for me, it's a lot more interesting writing code vs. meeting with lawyers :)
+ 10120 [eustaquioran] And what is the opinion of your employer about the Ruby license? I'm curious
+ 10124 [now@bi wi se] I just want to know: Am I in everyones kill-file by now? I mentioned
+ 10133 [eustaquioran] I fully agree with you.
| 10134 [eustaquioran] And what is the opinion of your employer about the Ruby license? I'm curious
+ 10146 [charles.nutt] You can have all the credit for pointing it out first. However since
[ ruby-Patches-8309 ] add usage of uri.userinfo to open-uri.rb
10114 [noreply@ru y] Patches item #8309, was opened at 2007-01-30 15:25
10131 [matz@ru y- a] According to RFC3986, supporting userinfo in URI is dangerous, so that
+ 10132 [paulo.koch@g] Shouldn't that be, at least, a warning or something?
| 10137 [matz@ru y- a] open-uri raises error for URI with userinfo when you use Ruby 1.9 or
| 10139 [sroberts@un ] The comments in the RFC refer fairly specifically to the dangers of
| 10143 [matz@ru y- a] Of course both of them are unsafe. It's not easy to persuade akr (the
| 10175 [shyouhei@ru ] It's not a matter of his personality. Don't shift the blame onto akr.
| 10176 [matz@ru y- a] It's not my intention to blame him. I have no reason to do so. I
| + 10177 [shyouhei@ru ] Because it's marked "deprecated" in RFC3986. No use of this field
| | 10179 [sroberts@un ] It means that the library cannot interoperate with legacy systems.
| + 10180 [james@gr yp ] I've actually wished for it a couple of times and I wish it was
| + 10181 [paul@sp na l] +1 (its ruby - not java - be satisfied - not surprised)
| + 10182 [shyouhei@ru ] Excuse me if you've already noticed; it's just FYI. Open-uri's open
| + 10183 [sroberts@un ] Whats really great about open-uri, is that it allows a description of a
| + 10184 [james@gr yp ] I'm very glad you pointed this out. I didn't know this and I'm
+ 10136 [paul@sp na l] i understand the problems mentioned at rfc3986 with respect to
[ ruby-Patches-8317 ] [PATCH] block_given? and yield incorrect within rb_iterate()
10125 [noreply@ru y] Patches item #8317, was opened at 2007-01-30 18:21
[OT] Re: Collaborative Ruby Language Specification
10126 [pit@ca it in] Nikolai, you're still in my heart^h^h^h^h^hinbox :-)
10127 [now@bi wi se] Good; thanks!
ruby 1.8.4 core dumps on SIGINT with lots of threads
10129 [sroberts@un ] multi-threaded ruby process. Doesn't always happen, but semi-regularly.
Is 'bad write retry' a bug in the openssl extension?
10130 [sroberts@un ] I am seeing this in a process that has a number of threads writing to a