http://blog.gmane.org/gmane.comp.lang.ruby.core hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.ruby.core/19508 Please don't assume that this was on purpose. With that much going on, things can easily be lost. Please try again resending the patch, or even better (now that it exists) use redmine. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst< at >it.aoyama.ac.jp Martin Duerst 2008-12-02T01:21:05 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19507 I know what you mean. My own small patches (just to fix compatibility for uClibc(*)) were also ignored. This is what I meant when I said "not find much interest": of course the user base is hugely interested in the development of the robust 1.8 code. I'm just unconvinced that the ruby core developers are. Even now that ruby 1.9 is supposedly no longer a moving target, I certainly have no plans to move to it in any production environment. I just don't want the pain of all those broken libraries and frameworks. Maybe in a year or two. Regards, Brian. (*) I'm interested in resource-limited platforms too. ruby 1.8 installs fine on OpenWrt boxes with 4MB of flash, if you trim the standard libraries a bit. Brian Candler 2008-12-01T21:56:17 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19506 I would like to second that. 1.8.7 patches would be very interesting indeed. -Stephen Stephen Sykes 2008-12-01T20:53:25 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19505 Brian, gcc optimizes the big switch in rb_eval() into a dispatch table both before and after my factoring of it into separate node handling functions. I realize that the Ruby world has moved on, which is why I'm not going to bother with more work on this until at least a couple folks commit to testing it. The 1.8 series is similar enough to 1.6.8 that I know I could create a patch patch for it in a few days. If that tested well, I might consider trying it with 1.9, but I suspect that would be a lot more effort. If 1.9 is using the same GC and gcc as 1.8, then I would expect that it would benefit from this patch. However, that remains to be proven. Also, 1.9 and its "standard libs" have gotten so large that they simply won't fit on my target (embedded ARM linux) machines. The 1.8 core is really not that much bigger than 1.9, I'd just have to strip away most of its new "standard" libs. Does anyone know the current status of "Atomic Ruby?" As Paul as already pointed out, Matz and Koichi kept callcc in v1.9 Ruby via some very amazing code hardwired into the VM. It is made accessible after require "continuation". I've traced the reliability issues with continuations to the fact that the GC object mark function for them is incorrect, and posted a patch to fix this in v1.8.6 about a year ago. That fix was never implemented so continuations continue to have a bad wrap. My own experience is with them since than is quite good. However, Paul Brannan told me that he has had trouble with them due to their incompatibility with some of the non-standard libraries with which his application links. (Something about call backs, if I recall correctly) In any case, Continuations are more general than Fibers. Fibers can be implemented in terms of continuations quite readily, but Continuations cannot be implemented in terms of Fibers. - brent Brian Candler wrote: Brent Roman 2008-12-01T19:47:46 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19504 On Dec 1, 2008, at 1:29 AM, Brian Candler wrote: Actually I think you will find a *ton* of interest in this for the 1.8.* branch. There are thousands of production apps that are not going to move to 1.9 anytime soon and any improvements to 1.8.* thread and callcc handling like this would be very welcome. Thanks Ezra Zygmuntowicz ez< at >engineyard.com Ezra Zygmuntowicz 2008-12-01T19:12:56 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19503 Brent- I would love to see a version of these patches against 1.8.6 or 1.8.7. I can test them on a few hundred servers to see what kind of resource consumption these changes have in larger deployments. Awesome work on this. I'm very interetsed in testing this for you. You can contact me off list if you like or if you want servers to use to test this on. Thanks Ezra Zygmuntowicz ez< at >engineyard.com On Nov 30, 2008, at 11:34 AM, Brent Roman wrote: Ezra Zygmuntowicz 2008-12-01T19:11:01 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19502 Bug #806: Net::Protocol#rbuf_fill is slow http://redmine.ruby-lang.org/issues/show/806 Author: Aaron Patterson Status: Open, Priority: Normal Category: lib Net::Protocol#rbuf_fill is slow. We can take advantage of io.read_nonblock and IO.select to deal with timeouts. I've attached a patch. ---------------------------------------- http://redmine.ruby-lang.org Aaron Patterson 2008-12-01T18:22:32 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19501 Hi everyone, While working on some specs, we found out that autoload (Kernel#autoload and Module#autoload) internally call rb_require() directly to pull the file in. This of course means that if Kernel#require has been changed (for instance by rubygems) that the changed logic won't be run. My question is if it's intentional that autoload bypasses Kernel#require. If not, autoload should probably use rb_funcall() to keep everything consistent. This obviously also effects Rubinius, as our autoload just calls Kernel#require directly. Thanks! - Evan Phoenix Evan Phoenix 2008-12-01T17:54:36 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19500 Bug #805: Ruby 1.9.1 preview 2 : build failure on OpenSolaris http://redmine.ruby-lang.org/issues/show/805 Author: Dae San Hwang Status: Open, Priority: High I got the following error while building 1.9.1 preview 2 on OpenSolaris 5.11 snv_98. (1.9.1 preview 1 was built fine on OpenSolaris.) It was configured with the following: ./configure --build=x86_64-sun-solaris10 --prefix=/usr/local CFLAGS="-m64" LDFLAGS="-m64" -- compiling curses make[1]: Entering directory `/usr/local/src/ruby-1.9.1-preview2/ext/curses' gcc -I. -I../../.ext/include/x86_64-solaris10 -I../.././include -I../.././ext/curses -DRUBY_EXTCONF_H=\"extconf.h\" -fPIC -m64 -O2 -g -Wall -Wno-parentheses -o curses.o -c curses.c curses.c:419:18: macro "ISPRINT" requires 2 arguments, but only 1 given curses.c: In function `curses_getch': curses.c:419: error: `ISPRINT' undeclared (first use in this function) curses.c:419: error: (Each undeclared identifier is reported only once curses.c:419: error: for each function it appears in.) curses.c:1113:18: macro "ISPRINT" requires 2 arguments, but only 1 given curses.c: In function `window_getch': curses.c:1113: error: `ISPRINT' undeclared (first use in this function) make[1]: *** [curses.o] Error 1 make[1]: Leaving directory `/usr/local/src/ruby-1.9.1-preview2/ext/curses' make: *** [exts] Error 1 ---------------------------------------- http://redmine.ruby-lang.org Dae San Hwang 2008-12-01T16:50:41 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19499 Bug #804: Ruby 1.9.1 preview 2 : make test failure http://redmine.ruby-lang.org/issues/show/804 Author: Philippe Lucas Status: Open, Priority: Normal Version built on Fedora core 2 x686 with gcc 4.0.2 in a sub directory (UNIX) of the main ruby source with ./configure --prefix=/h/phil/DEV/RUBY/ruby-191pv2 --enable-shared --enable-install-doc --enable-pthread --with-mantype=man ./ruby -v => ruby 1.9.1 (2008-12-01 revision 20438) [i686-linux] Note that : ruby -v => ruby 1.8.7 (2008-05-31 patchlevel 0) [i686-linux] In the announce message of this release, i read : == Improvements * You can "make test" without installing ruby. So make test gives this error : test_flip.rb /h/phil/DEV/RUBY/ruby-1.9.1-preview2/UNIX/ruby: error while loading shared libraries: libruby.so.1.9: cannot open shared object file: No such file or directory which is not very suprising !. Regards. ---------------------------------------- http://redmine.ruby-lang.org Philippe Lucas 2008-12-01T15:44:35 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19498 Ruby 1.9.1 Preview 2 has been released. This is a preview release of Ruby 1.9, which will be the first stable version of Ruby 1.9 series. If you encounter a bug or a problem, please let us know it via the official issue tracking system (http://redmine.ruby-lang.org ). == Location * ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-preview2.tar.bz2 SIZE: 6148131 bytes MD5: 62126475998ede5318c1bc82c40d5f48 SHA256: 2c419dc325c6a75fb7b961496c0dd54f2729e6e01730589c4fb06e34ddd7a7cc * ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-preview2.tar.gz SIZE: 7375483 bytes MD5: 7699b9e54c53b16640d40a213588e704 SHA256: dd737d26212d68c26ecb4d6e2ed180a0d7d5e27fb7bd2c819935494daa1cf50b * ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-preview2.zip SIZE: 8612618 bytes MD5: d3ae200280b75801bfc5c090d3592577 SHA256: 96b6a2745b64f03ffbd5da97f93a2676365e3900cb8f6bf820f47739ef8d3fa9 == Improvements * supports 21 new character encodings. * works better with RubyGems. * handles SEGV better when system stack overflows. * fixed a bit of regexp imcompatiblity to Perl5 and old Ruby. * many bugs in Time#strftime and Date#strftime fixed. * process termination got faster. * allows long style options in RUBYOPT. * You can "make test" without installing ruby. * You can derive a class from Fiber correctly. * many bugs fixed. == Release schedule Current Status: * Language features are effectively "frozen". * But we could not finish multilingualization tasks for standard libraries. For example, irb does not recognize magic comments. * So changes to some of standard libraries continue. * irb * erb * cgi * ... Schedule: * 25 Dec, 2008: Ruby 1.9.1 release candidate * 25 Jan, 2009: Ruby 1.9.1 Thanks Yugui (Yuki Sonoda 2008-12-01T13:25:50 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19497 1.9 does have callcc (require 'continuation'). It's probably not good to use it, though. Paul Paul Brannan 2008-12-01T12:25:04 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19496 Did you replace the whole switch statement with a dispatch table? That sounds like a sensible thing to do anyway. OTOH, if this is for ruby 1.8.x, I'm afraid you may not find much interest in such changes while the focus is all on 1.9. Perhaps worth checking how 1.9's bytecode interpreter stacks up under the same conditions? OTOH, 1.9 doesn't have callcc anyway, so maybe your application code would need a lot of restructuring to use Fiber instead. I don't know if it's possible to implement callcc in terms of Fiber. Regards, Brian. Brian Candler 2008-12-01T09:29:00 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19495 As Park Heesob brought up on win32utils-devel, SEH on 64-bit Windows is table based instead of stack based. From MSDN: "One of the constraints for the x64 compiler is to have no inline assembler support. This means that functions that cannot be written in C or C++ will either have to be written as subroutines or as intrinsic functions supported by the compiler. Certain functions are performance sensitive while others are not. Performance-sensitive functions should be implemented as intrinsic functions. In general, this will be the same list of intrinsic functions implemented for ALPHA and the Itanium but will include x64 specific functions as well." http://msdn.microsoft.com/en-us/library/wbk4z78b.aspx So, I guess we must compile in 32-bit mode on Windows. :( Regards, Dan Daniel Berger 2008-12-01T05:47:25 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19494 Hi, At Sun, 30 Nov 2008 22:42:36 +0900, Daniel Berger wrote in [ruby-core:20176]: VC seems to define _M_AMD64 on amd64 instead of _M_IX86, but I'm not sure about AMD64 instruction set and if Windows on it saves the exception list in the same place. Do you have any idea? Nobuyoshi Nakada 2008-12-01T03:40:46 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19493 Issue #791 has been updated by Nobuyoshi Nakada. Status changed from Open to Closed % Done changed from 0 to 100 Applied in changeset r20432. ---------------------------------------- http://redmine.ruby-lang.org/issues/show/791 ---------------------------------------- http://redmine.ruby-lang.org Nobuyoshi Nakada 2008-12-01T03:01:44 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19492 Hi, In message "Re: [ruby-core:20124] Re: Again: Questions about Fiber behaviour" on Thu, 27 Nov 2008 00:36:07 +0900, Florian Gilcher <flo< at >andersground.net> writes: |Wonado: | |http://www.ruby-forum.com/topic/171434 |http://www.ruby-forum.com/topic/171397 | |(Both reported as bugs now) Both are bugs, and the former is fixed in the trunk. |Myself: |http://www.ruby-forum.com/topic/171596 We welcome the documentation fix proposals. matz. Yukihiro Matsumoto 2008-12-01T00:27:43 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19491 Hi, In message "Re: [ruby-core:20167] Re: \Z? in regular expression in 1.9.1" on Sun, 30 Nov 2008 04:17:22 +0900, Brian Candler <B.Candler< at >pobox.com> writes: |That's gotta be a bug, and is potentially dangerous: | |irb(main):001:0> puts "phooey" if /a/.match("bcde") |=> nil |irb(main):002:0> puts "phooey" if /a\Z?/.match("bcde") |phooey |=> nil Aargh, I will fix somehow. Maybe by making it strict again. Sorry anyway. matz. Yukihiro Matsumoto 2008-11-30T23:26:06 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19490 Roger, I already responded in detail to this bug: http://rubyforge.org/tracker/?func=detail&atid=1698&aid=7896&group_id=426 I just bang on Ruby 1.6.8 for our robotics application. You seem to already be doing a lot of excellent Ruby testing with current versions. If I spent a couple days developing these two patches for Ruby 1.8.7, would you be willing to run regression tests against them and to report the results here? I think the small stack clearing patch should improve the GC behavior, but, by itself, it will likely slow down some apps due to its having to clear large areas of stack. I'd expect to see that slow down mitigated by the larger patch that would refactor rb_eval() and thereby keep the stack smaller. The combined patches will likely be large, so I'll just post links to them here. Would anyone else be willing to test them? ... Particularly those who have large apps, and/or apps that use multiple threads or continuations that seem to leak memory? - brent P.S. I use gcc 3.4.5 for generating code for our embedded ARM targets. The older compiler generates fewer stack temporaries than the newer ones. Don't rush to update :-) P.P.S. The way GC is currently invoked causes it to occur when that stack is already near its maximum depth. This patch tries to make GC normally occur is part of CHECK_INTS, when the stack tends to be shallower. At that point, clearing the stack can be much more effective. Roger Pack wrote: Brent Roman 2008-11-30T19:34:12 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19489 Brian, Thanks for the very clear demo program to illustrate the problem. Is there anyone who can run look at the assembler code generated for this demo by a recent Microsoft or Intel 'C' compiler? In any case, I doubt that the gcc maintainers would consider this behavior a bug. It's been with them from before v3.3.5. They've known about it for many years. They view it is an limitation of their register optimization techniques and are more concerned about speeding up the code than shrinking its stack footprint. However, for us, larger stacks = slower code due to stack copying and the conservative GC. The "ugly union" solution would not be sufficient because much of the stack is occupied by compiler generated temporaries that have no representation in the 'C' input source. I did consider such wholesale code changes, but resisted because they would have been, as you say, quite ugly and difficult to maintain. What I did come up with was not ugly at all. Factor the unwieldy switch statement of rb_eval() into separate functions to handle each node type and clear the stack at a few opportune times. rb_eval() becomes smaller and more likely to be optimized. I buried the stack clearing into macros that already exist. - brent Brian Candler wrote: Brent Roman 2008-11-30T19:06:26 http://permalink.gmane.org/gmane.comp.lang.ruby.core/19488 Sure. All I meant was, given the original regexp example /\n(\.\/)?(.*spec\.rb):[\d]+:\Z?/ it's most likely unintended that this should match a string which doesn't have a colon after the digit. irb(main):001:0> /\n(\.\/)?(.*spec\.rb):[\d]+:\Z?/ =~ "\nxspec.rb:5" => 0 B. Brian Candler 2008-11-30T13:46:26 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.ruby.core