11945-18230 subjects 12294-12791

[PATCH] XMLRPC::ModRubyServer
12087 [cwailes2@ui ] ...

Possible Zlib Bug
12092 [jed.hurt@gm ] I posted to core as I assumed that this would be the mailing list with
+ 12101 [jed.hurt@gm ] Should I go ahead and post this question to the general list as well?
+ 12106 [jed.hurt@gm ] It was a bonehead error. String#slice!(0..8) consumes the first 9

Next 1.8.6 on Sept. 22
12096 [shyouhei@ru ] We're planning to release 1.8.6 fixes on Sept. 22(Sat).  If you find
+ 12097 [rocky.bernst] ...
| + 12098 [celtic@sa ry] Please note the fixed link;
| + 12102 [shyouhei@ru ] No there isn't.  It is quite possible that we include it for 1.8.7.
|   + 12105 [rocky.bernst] ...
|   + 12109 [znmeb@ce ma ] Given that 1.9 seems to be on track for a release towards the end of
|     + 12110 [wilsonb@gm i] 1.8.x will continue to need bugfix releases for quite some time after
|     | 12111 [znmeb@ce ma ] Yes ... bug fixes but no new features. You're one of the Rubinius
|     | 12116 [wilsonb@gm i] We would be honored to implement any new behavior that happened to
|     | 12123 [charles.nutt] Speaking for JRuby, we've already implemented some of Ruby 1.9's
|     + 12122 [charles.nutt] Isn't 1.9 still officially a development branch? I wouldn't expect
|       12131 [znmeb@ce ma ] Well ... I wasn't proposing abandoning 1.8, just stopping at 1.8.6, with
|       12151 [zimbatm@or e] Regarding threads, there is some scheduling problem that could be
+ 12099 [sylvain.joye] ...
| 12103 [shyouhei@ru ] I see no serious problem on your patch.  I've forwarded your post to
| + 12114 [nobu@ru y- a] I agree that function should be removed.  However, it revives
| | 12226 [sylvain.joye] I completely agree on that. assert_no_survivors() is IMO only triggered
| | 12229 [nobu@ru y- a] Do you consider the assertions would fail even when it isn't
| + 12170 [sylvain.joye] ...
| + 12188 [shyouhei@ru ] Accepted.  Thank you for the report.
+ 12100 [sylvain.joye] - #11497: patch to track object allocation
| 12104 [shyouhei@ru ] earlier 1.8.6 is already in maintenance mode.  1.8.6 feature has
+ 12107 [stephen.bann] ...
+ 12108 [onepoint@st ] ...
+ 12172 [flori@ni e. ] Florian Frank
+ 12189 [murphy@ru yc] This shows up sometimes in Rails' development logging...I hope it can
+ 12208 [wilsonb@gm i] Is there any chance this could be included, or have I missed the window?
+ 12209 [sylvain.joye] ...

Is this expected behavior?
12118 [james@gr yp ] As part of TextMate's development process we have an application on a
+ 12119 [david@da id ] I can't explain why this behavior is the way it is, but it is expected.
+ 12121 [wilsonb@gm i] As a hack-around, you could make a .rb file that simply contains
+ 12125 [nobu@ru y- a] What's the platform?
  + 12126 [james@gr yp ] Mac OS X.
  + 12153 [matz@ru y- a] It should be added in the list of options allowed.  I will.

Thread unsafe code in TestCase
12120 [charles.nutt] I was browsing TestCase debugging JRuby today and came across some code

integer range literals in conditionals with -e option
12124 [david@da id ] Here's a question for experts whose memories go back to vrsion 1.6 or
12132 [nobu@ru y- a] It's not a comparison with range object, but comparisons with
12135 [david@da id ] My opinion is that if this feature has been broken for two years and no

Super broken in aliased method in a module
12127 [calamitates@] module M
12128 [charles.nutt] I reported a similar issue with Object#method, see message [rubycore:11600]

Re: Encodings and String Literals
12129 [murphy@ru yc] That's a very original idea, although a bit strange. It actually looks
12137 [david@da id ] I believe that that is exactly how 1.9 currently works.  IIRC, I began

Use cases for $SAFE levels 2 & 3?
12139 [david@da id ] I believe that I understand $SAFE levels 1 and 4.  Level 1 is good for
12150 [matz@ru y- a] They are mere intermediates between levels 1 and 4 without any

Strange ripper bug
12140 [sir_raorn@im] Sometimes, ripper can't parse valid code (trunk from yesterday).

Blocks passed to constructors - is this behavior by design?
12143 [jflam@mi ro ] class Foo
12144 [myrtactle@gm] ...
12145 [charles.nutt] puts Foo.new { break 42 }
12148 [jflam@mi ro ] Yes, we figured this out shortly after this mail was in flight (of course) so it is somewhat strange behavior but it doesn't require us to special case which was what we were worried about.

autoloading Fiber
12146 [david@da id ] In order to use the new Fiber class in 1.9, we have to require 'fiber'.
12147 [charles.nutt] I'd recommend against making Fiber autoload, since some implementations
12149 [david@da id ] I'm not trying to suggest that autoloading the fiber library is a good

[PATCH] Strange ripper bug
12154 [k.shutemov@g] =20
12157 [k.shutemov@g] =20
12158 [matz@ru y- a] Comma separation suggest splat in the hash expression, which does not
12159 [k.shutemov@g] It break backward compatibility. Any ideas how to fix it?
12160 [matz@ru y- a] We plan to create migration tool after we see 1.9 stable.  Or if
+ 12161 [ceo@ha th rn] Before jumping into the deep end  -- What would be required?
+ 12162 [k.shutemov@g] Please, comment patch in the attachment.
| 12195 [k.shutemov@g] Any comments?
+ 12164 [drbrain@se m] I think Ruby2Ruby is your migration tool.

[PATCH] parse.y compilation error
12155 [k.shutemov@g] gcc -g -O2  -I. -I.ext/include/x86_64-linux -I./include -I.  -DRUBY_EXPORT =

require runs files with $SAFE=0
12156 [david@da id ] I've never seen this documented anywhere, but I just discovered, while

[PATCH] Improving XML-RPC Errors
12163 [james@gr yp ] ...
12169 [djberg96@gm ] Looks good to me. I vote to include.

Wrapped loads and Module::nesting
12166 [david@da id ] When I call load with a second argument of true, the file is loaded into
12168 [david@da id ] The patch below fixes Module.nesting so that it behaves in 1.9 like it
12631 [david@da id ] Has anyone had a chance to take a look at this patch and my rationale

[PATCH] Improving XML-RPC ModRuby support
12173 [cwailes2@ui ] ...
12174 [Daniel.Berge] I'm not familiar with XML-RPC in the context of mod_ruby, but these
12175 [cwailes2@ui ] To address the first issue, the methods 'michael.add' and 'michael.div' are only used in the documentation.  When I changed the way that the library interfaced with ModRuby I also updated the documentation to reflect this and tried to use the same examples that were used in the rest of the library.  It is kind of hard to find in the diff, but there is a =begin at the top.
+ 12176 [cwailes2@ui ] ...
| 12178 [Daniel.Berge] Wouldn't checking for an arity of 1 be a problem since any method with a
| 12179 [cwailes2@ui ] Nope, you are correct.  It should check for obj.arity == -2.  In my hurry to fix the previous issue I let that sneak in there.
+ 12177 [Daniel.Berge] Whoops, misread that. Disregard.

Misleading error message with URI::InvalidURIError
12184 [bianster@gm ] ...
12186 [drbrain@se m] " http" is not a valid URI scheme, and "org " is not a valid TLD.  I
12187 [wilsonb@gm i] It would be nice if the error message called 'inspect' on the string, though.

12185 [ramon.arnau@] ...

[PATCH] matrix.rb
12190 [S_Ueckert@we] This patch fixes a bug that prevented a vector from being multiplied
12191 [keiju@is it ] I'm a maintainer of matrix.rb.

R. :  Re: New array methods cycle, choice, shuffle (plus bug in cycle)
12193 [tad.bochan@b] Just a suggestion - I know this business of naming methods can be

Ruby's fnmatch vs fnmatch.h
12197 [Daniel.Berge] I'm just curious - what's the difference between fnmatch.h and the
12199 [wilsonb@gm i] Ruby implements its own version in order to be able to support ** patterns.

Re: Digest Articles 12186-12187 (1/1) (ruby-core ML)
12198 [bianster@gm ] ...

class variables and singleton classes
12200 [drbrain@se m] Class variables in singleton classes are separate from class
+ 12206 [david@da id ] Eric,
| 12210 [drbrain@se m] My concern is not how widespread this behavior is, its that defining
| 12211 [david@da id ] Eric,
| 13349 [david@da id ] I'm reviving a thread from September.
+ 12207 [dblack@ru yp] What's most odd to me is that it appears to matter whether you use the
+ 13354 [matz@ru y- a] It now works as 1.8.  Try newer one.

how about actors implemented in ruby-core itself
12201 [gethemant@gm] I am relatively new to Ruby, so pardon me If i say something stupid.
+ 12202 [sroberts@un ] Don't know anything about python, but Fibers are coroutines, this
| + 12203 [yemi@we df s] I think that the Io programming language was one to have a simple actor
| + 12204 [yemi@we df s] I am sorry, I did not give links.
+ 12205 [wilsonb@gm i] Rubinius has Actor (implemented by MenTaLguY) as a core class. If ruby
  + 12212 [gethemant@gm] Yes, I think I saw that somewhere on rubinius website or something.
  + 12213 [ko1@at ot ne] Can I read spec or examples of Actor?
    + 12214 [wilsonb@gm i] There aren't any particularly good ones yet, but I will write some this week.
    | 12216 [garbagecat10] ...
    + 12215 [mental@ry ia] Actor.current # => actor
      12217 [mental@ry ia] One additional note -- every ruby thread has an actor
      12219 [mailing.mr@g] I implemented something similar using DRb, it's slower, but you can

encoding concept confusion
12218 [duerst@it ao] Making a few extremely simple tests, I discovered some conflicting

`ri Kernel#open` Bug
12220 [james@gr yp ] $ ri -T Kernel#open
+ 12221 [drbrain@se m] Please file a bug.
| 12222 [james@gr yp ] func=detail&aid=14146&group_id=426&atid=1698
| 12223 [jim@fr ez .o] You can specify the path for ri to search to get access to the
+ 12224 [rick.denatal] More than one method matched your request. You can refine

Can we move fri into the standard library? (was Re: `ri Kernel#open` Bug)
12225 [james@gr yp ] This might be good time to discuss when we could consider moving
12227 [drbrain@se m] A daemon does not fix ri, it is orthogonal to this problem.
12228 [james@gr yp ] fastri does not have to run off a daemon.  You can build an index for

returning from an iteration loop in an extension
12230 [pbrannan@at ] def foo(container)

Wrong return value with []=
12231 [mneumann@nt ] class Symbol
+ 12232 [james@gr yp ] This is a feature.  Ruby always returns the right side of all
| 12234 [mneumann@nt ] Ah, okay. Agreed :)
+ 12233 [myrtactle@gm] ...

Compiler warnings and test failures with latest SVN Ruby 1.9
12235 [znmeb@ce ma ] ...
12236 [matz@ru y- a] Test failures in test_knownbug.rb are bugs already known.  Warnings in

Latest benchmarks
12237 [znmeb@ce ma ] ...
12238 [ko1@at ot ne] 1. Results of vm[12]_* benchmarks should be subtracted
+ 12239 [znmeb@ce ma ] Well ... I'm putting together a benchmark suite, including the ones in
+ 12240 [murphy@ru yc] and removed the misleading "Average speedup".
  12241 [murphy@ru yc] oh no. I'm stupid. ignore this ^_^'
  12242 [brent@mb ri ] Ed,
  12243 [znmeb@ce ma ] I can get it -- haven't done so yet. Once I get the last benchmark in

next method and for loop
12244 [david@da id ] With the introduction of external iterators and the python-like next

12245 [tony@cl ck a] ...

Bug in REXML 3.1.7 - NameError: undefined local variable or method 'transitive' in document.rb, line number 187
12246 [martin.simba] just wanted to drop a message to let you know that there is a bug in
12258 [ser@ge ma e-] charset="utf-8"

Fibers as semi-coroutines enabled by default
12247 [david@da id ] I've been following fibers with interest and just noticed that ko1
+ 12265 [ko1@at ot ne] Thank you for summarise about Fiber.  I think also "Fiber#transfer
| + 12271 [david@da id ] That's exciting to hear.  Will you be doing this in time for 1.9.1?
| + 12275 [mental@ry ia] It could be a good idea, as long as you're careful to keep things
| | 12276 [ko1@at ot ne] I think Fiber/Coroutine should be synchronous.  After all, it's
| | + 12277 [david@da id ] Let me see if I understand: you are NOT introducing any new mechanism
| | + 12279 [mental@ry ia] Channels can be asynchronous even if the implementation of "process"
| + 12278 [tony@cl ck a] ...
+ 12282 [charles.nutt] Correct on both counts. Of course, currently Fiber is implemented in

arbitrary Unicode characters in identifiers?
12248 [david@da id ] ...
+ 12249 [wilsonb@gm i] Oh man I hope this isn't a bug. That is really cool.
| + 12250 [rick.denatal] Yeah, you could cross ruby with other languages and come up with
| + 12251 [murphy@ru yc] No, it's a feature. It works even with Ruby 1.8, and I guess it always
|   12253 [wilsonb@gm i] Haha! Now we can finally have Kernel#褦 so we can implement Hello,
+ 12254 [matz@ru y- a] * it's difficult to read if users do not have proper font handling
| 12256 [david@da id ] Thanks for the clarification.  I understand all the good reasons for not
| 12262 [duerst@it ao] I don't think there are any plans for character type analysis any time
+ 12259 [ser@ge ma e-] charset="utf-8"
+ 12261 [duerst@it ao] unicodeindents.rb:3: identifier x is not valid to set
  + 12263 [murphy@ru yc] I got this error, too, until I updated to latest Ruby 1.9. maybe that
  + 12266 [matz@ru y- a] You will get this unless encoding of the file and that of specified by

Array#-, &, |, uniq don't use ==
12255 [murphy@ru yc] x = Object.new
+ 12260 [matz@ru y- a] It's a feature, to reduce complexity order from O(m^n) to O(mn).
| 12267 [ mfp@ac .o g] Shouldn't that be O(mn) and O(m+n)?
| 12268 [matz@ru y- a] Exactly.  I have accidentally disclosed my math inability.
| 12270 [meinrad.rech] nobody is perfect :)
+ 12370 [rick.denatal] Actually, some of these surprise me, since although x might == every

Re: Bug in BigDecimal#round ?
12264 [jan.svitok@g] reported as #14271

1.8.6 on windows: issues with IO and Threads
12272 [luislavena@g] t = Thread.new {
12273 [dooby@d1 .k ] It's happening but you're not seeing the buffered output.
12274 [dooby@d1 .k ] Sorry, that's not the answer you were looking for.

send! doesn't protected methods / Delegator
12280 [murphy@ru yc] I wonder why the new send! (and __send!) call private methods, but not
12281 [matz@ru y- a] No, I will fix.

Unary plus and literals
12283 [david@ma da ] when looking at the parse.y code in Ruby 1.8.5, I noticed following
12300 [matz@ru y- a] This is not a bug, misfeature at most, but this "optimization" will be

gc.c -- possible logic error?
12284 [hgs@dm .a .u] which I've been able to reproduce for various data structures.
+ 12285 [matz@ru y- a] It's not uncommon among C programs to use signed int for positive only
| 12287 [hgs@dm .a .u] OK, though with machines having memory at about 3 GB these days,
| 12290 [hgs@dm .a .u] Done this.  All ruby tests pass OK, but it doesn't solve the memory
+ 12286 [mental@ry ia] The collector is conservative with respect to the C stack -- should
| + 12288 [hgs@dm .a .u] Thanks, I'll try to look at this a bit later.  Shouldn't the C stack
| | 12289 [mental@ry ia] Yes.  I'm just suggesting that it's possible for some unrelated
| | + 12291 [hgs@dm .a .u] Oh, I see.  I can't see a way to test if that is happening.
| | + 12292 [mental@ry ia] Once you get to this point, you may simply want to instrument the
| |   12293 [vjoel@pa h. ] Dunno if this is going to help, but here's a patch for several old
| + 12296 [matz@ru y- a] In addition, Ruby keeps heap region for future usage unless heap
+ 12301 [akr@fs j. rg] I think OpenStruct needs much more memory than Hash.
| 12302 [akr@fs j. rg] Oops.  T_VALUES doesn't use malloc.
+ 12325 [sylvain.joye] One problem another related with Ruby's memory allocation is that the heap
| 12326 [hgs@dm .a .u] I tried the patch below.  It works in so far as it doesn't break
+ 12329 [akr@fs j. rg] I measured the example by valgrind --tool=massif.
| 12331 [hgs@dm .a .u] Thank you for this.  I don't have valgrind on this Solaris machine.
| 12332 [akr@fs j. rg] valgrind works only on Linux.
| 12334 [hgs@dm .a .u] I promptly looked that up, and discovered that. Oh well. Thank you.
| + 12339 [Daniel.Berge] There's dbx and libumem. Do they help?
| | 12356 [hgs@dm .a .u] I seem to have a recent enough solaris for this, given
| + 12342 [drbrain@se m] The mem_inspect gem is a similar tool that outputs a PNG.  It needs a
|   12357 [hgs@dm .a .u] brains hgs 33 %> setenv RUBY /scratch/hgs/local/bin/ruby
|   12368 [drbrain@se m] Wow, the repo is completely missing it every other time I search for it.
|   + 12369 [hgs@dm .a .u] Thank you.  I'm not sure when I'll get back into this problem, but I'll
|   + 12384 [hgs@dm .a .u] brains hgs 100 %> cd mem_inspect-1.0.0/
|     + 12386 [hgs@dm .a .u] OK, I've managed that.  The results could do with some interpretation.
|     + 12394 [drbrain@se m] Ha! I didn't think it predated the SVN switchover.
+ 12333 [sylvain.joye] I have a hugely strange behaviour here ...
| 12335 [hgs@dm .a .u] Interesting. But any "dirt" will still be on the bottom of the stack,
| 12336 [brent@mb ri ] Hugh,
| + 12337 [hgs@dm .a .u] Those are not mine.  My patches were posted earlier, and
| + 12353 [sylvain.joye] It is simply tracking the count of objects on the heap which are allocated. No
+ 12354 [sylvain.joye] I think I found the explanation of (parts of) the problem
  12355 [hgs@dm .a .u] 9639         Data_Get_Struct(body, struct BLOCK, block);
  + 12358 [hgs@dm .a .u] I experimented with this, freeing data->scope and data->dyna_vars in
  + 12360 [vjoel@pa h. ] Mark and free are not symmetric. Mark is for objects referred to by self
    12361 [hgs@dm .a .u] Thanks, that confirms the results of my experiment which failed, and ties