http://permalink.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/17269 Hi, On Fri, Jul 25, 2008 at 4:35 AM, Tanaka Akira <akr< at >fsij.org> wrote: 1. RubyGems uses it to invoke #{RUBY_ENGINE}.rb file with customizations, specific for particular implementation 2. Different implementations have different specifics, like JRuby can 'require' a JAR file and need different activerecord drivers, etc. There are also some JRuby-specific libraries that only make sens for JRuby, and the whole Java Integration layer. So, folks need to figure out when they run with JRuby and when they not. Initially, the following code was wildly used: if RUBY_PLATFORM =~ /java/ But this is fragile, and not 100% reliable (other implementations might have "java" in their platform too!). We also have JRuby-specific JRUBY_VERSION, so one might check that one. But, when the number of implementations grows, it gets less and less convenient to use implementation-specific means to detect the implementation. Hence, the proposal for that constant. So that the folks could easily and reliably detect the implementatio Vladimir Sizikov 2008-07-25T07:48:09 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17268 On Fri, Jul 25, 2008 at 4:53 AM, Laurent Sansonetti <laurent.sansonetti< at >gmail.com> wrote: It could just be "mri'. For version numbers, you could then inspect RUBY_VERSION, RUBY_PATCHLEVEL,, and Config::CONFIG as appropriate. Currently, JRuby's value is "jruby", and Rubinius' value is "rbx", strings. Thanks, --Vladimir Vladimir Sizikov 2008-07-25T07:39:32 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17267 Hi, In message "Re: [ruby-core:17954] Expand_path -- Proposal: An alternate method" on Fri, 25 Jul 2008 12:26:16 +0900, "C.E. Thornton" <admin< at >hawthorne-press.com> writes: |Shouldn't a program be able to expand ANY legitimate relative path |without worrying that some directory in a given tree contains a |dir '~name' where the name "just" happens to be a user on your system? | |I can see the point of 'expand_path' following the current convention, but |shouldn't there be a way to scan a directory tree without incurring errors |for legal directory names? | | It would follow these rules: | 1) ~current_user = /home/current_user | 2) Any other directory specification, whether prefixed with | a tilde or not would be interpreted literally. | | Suggested Method Names: expand_absolute() | absolute_path() If I were going to add a new method, that method should convert paths from relative to absolute, no user name expansion. matz. Yukihiro Matsumoto 2008-07-25T05:20:38 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17266 On Jul 24, 2008, at 9:53 PM, Daniel Luz wrote: Thanks Jeremy, Nobuyoshi and Daniel. Following Daniel's advice I've removed the two tests at least until there's some standarization on these issues. If you see any other problem please let us know. -- Federico Federico Builes 2008-07-25T03:40:07 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17265 HI, Not to belabor a point, But.... I see several use cases for a different path expansion method. Shouldn't a program be able to expand ANY legitimate relative path without worrying that some directory in a given tree contains a dir '~name' where the name "just" happens to be a user on your system? I can see the point of 'expand_path' following the current convention, but shouldn't there be a way to scan a directory tree without incurring errors for legal directory names? It would follow these rules: 1) ~current_user = /home/current_user 2) Any other directory specification, whether prefixed with a tilde or not would be interpreted literally. Suggested Method Names: expand_absolute() absolute_path() This method of this type would not produce errors for legitimate directory structures. Chuck T. C.E. Thornton 2008-07-25T03:26:16 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17264 On Thu, Jul 24, 2008 at 9:19 PM, Nobuyoshi Nakada <nobu< at >ruby-lang.org> wrote: You're right. Strictly speaking, the iconv library seems completely impossible to test, because there's not a single encoding which is guaranteed to exist across all implementations, much less behave consistently. So, when writing those specs, I tried to find a minimum of encodings which would be available on any implementation from the last couple years (the most common Unicode-related ones), and then tried to use the least common denominator I could find among some platforms (basically, whatever libraries were being used by the common Ruby distributions on Windows, OS X and Ubuntu). This, of course, could still fail on some implementations, so feel free to remove those problematic tests. Daniel Luz 2008-07-25T02:53:43 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17263 What would be the value if this constant, for 1.8 vs 1.9? Also, String or Symbol? Laurent Laurent Sansonetti 2008-07-25T02:53:00 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17262 On Jul 24, 2008, at 19:35 , Tanaka Akira wrote: not command name, but ruby "flavor": (mri) ruby, rubinius, jruby, etc. Ryan Davis 2008-07-25T02:46:39 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17261 In article <3454c9680807241200xf7cc766qb987905a3987bb78< at >mail.gmail.com>, "Vladimir Sizikov" <vsizikov< at >gmail.com> writes: What the usage of RUBY_ENGINE? I heard it is used to know command name at the IRC meeting. I think it is not good idea. Tanaka Akira 2008-07-25T02:35:30 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17260 I concur...it would be nice to get it out there and finally have an official variable to tell which "type" of Ruby implementation you're running on. And it's just one variable :) - Charlie Charles Oliver Nutter 2008-07-25T02:29:37 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17259 Hi, At Fri, 25 Jul 2008 08:17:27 +0900, Federico Builes wrote in [ruby-core:17947]: SUS defines nothing about the conversion detail, nor encoding names. Some implementation assign different encoding names for UTF's with/without BOM, but it's definitely implementation specific. I think the spec depends too much on particular platforms. Nobuyoshi Nakada 2008-07-25T00:19:41 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17258 Jeremy, On Jul 24, 2008, at 5:15 PM, Jeremy Henty wrote: From what I can see we're not the ones calling #<=>, it's being called in #to_a to sort the set: (< at >keys = < at >hash.keys).sort! unless < at >keys We're guarding it since as you said, no actions have been taken and we think that it's a plausible use case. I like the suggestion Arthur made on the ticket to undefine those methods for SortedSet if they're not going to be supported. It is a platform specific behavior but I'm not sure if it's an "OS bug" or if it's reproducible on all Linux systems besides Debian/ Ubuntu. Maybe we can get someone to take a look and let us know what to do about it? Having said that, I think these are minor issues that shouldn't stop the release of a new version, a lot of stuff has been fixed since the last official release. -- Federico Federico Builes 2008-07-24T23:17:27 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17257 To compare, with the latest ruby_1_8_6 branch I get the same Iconv errors that I reported above, but the SortedSet errors are gone. The relevant SortedSet tests are all guarded with 'ruby_bug "http://redmine.ruby-lang.org/projects/ruby-18/issues/show?id=117", "1.8.7.47" do ...', but if you check that URL it appears that no action has been taken. In other words, RubySpec seems to think that this is some bug that was fixed in 1.8.7.47 when in fact nothing has changed. Three of the four SortedSet errors are due to RubySpec calling SortedSet#<=> , which does not exist in either ruby_1_8_6 or ruby_1_8_7 . I don't know what is causing the Iconv errors. My Linux box is fairly aged, so it may be due to OS bugs (I've already had to disable some of the other tests for that reason). However, I've seen the same errors reported on this list, so it's not just me. Regards, Jeremy Henty Jeremy Henty 2008-07-24T22:15:37 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17256 I'm not sure what you mean by "OK", but I'm still getting errors with the latest ruby_1_8_7 branch and the latest RubySpec. (Log attached.) Regards, Jeremy Henty 1) Iconv#iconv when given nil resets the converter FAILED Expected "a\000" to equal "\376\377\000a" or "\377\376a\000" ./rubyspec/1.8/library/iconv/iconv_spec.rb:40 ./rubyspec/1.8/library/iconv/iconv_spec.rb:36:in `open' ./rubyspec/1.8/library/iconv/iconv_spec.rb:36 ./rubyspec/1.8/library/iconv/iconv_spec.rb:9 2) Iconv.iconv acts exactly as if invoking Iconv#iconv consecutively on the same converter FAILED Expected ["\377\376a\000", "b\000", "c\000", "", "d\000", "e\000"] to equal ["\376\377\000a", "\000b", "\000c", "", "\376\377\000d", "\000e"] or ["\377\376a\000", "b\000", "c\000", "", "\377\376d\000", "e\000"] ./rubyspec/1.8/library/iconv/iconv_spec.rb:131 ./rubyspec/1.8/library/iconv/iconv_spec.rb:97:in `all?' ./rubyspec/1.8/library/iconv/iconv_spec.rb:119 3) SortedSet#flatten_merge flattens the passed SortedSet and merges it in Jeremy Henty 2008-07-24T19:35:43 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17255 I'm trying to build SVN head on an openSUSE 11.0 AMD64 system. configure and make run fine until I hit the following problem: ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb -I. -rrbconfig ./tool/compile_prelude.rb ./prelude.rb ./enc/prelude.rb ./gem_prelude.rb prelude.c /home/cs/tmp/ruby/rbconfig.rb:173: [BUG] Stack consistency error (sp: 36, bp: 34) ruby 1.9.0 (2008-07-25 revision 18120) [x86_64-linux] Chris 2008-07-24T19:06:35 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17254 Hi, It was discussed in the past but as far as I can tell, there were no decision made, about the constant to specify the Ruby implementation. Now that Rubinius and JRuby define RUBY_ENGINE, and RubyGems also uses RUBY_ENGINE, maybe it's a good time to revisit the issue? It would be really nice if MRI would have that constant defined as well (and maybe to put this change into upcoming 1.8.6 and 1.8.7 maintenance releases)? Opinions? Thanks, --Vladimir Vladimir Sizikov 2008-07-24T18:54:09 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17253 When this ML thinks I should. Unlike Matz, I'm not a dictator. I do have powers to, for instance, put official tarballs on official places. And I was not democratically directly chosen. But that was because we have no democratic process to chose a person at my current position. My powers are based on your consensus. Whether we should have a release now is up to you. Urabe Shyouhei 2008-07-24T17:38:27 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17252 Hi, On Thu, Jul 24, 2008 at 5:51 PM, Nobuyoshi Nakada <nobu< at >ruby-lang.org> wrote: The 1.8.6 and 1.8.7 branches have been OK w.r.t. RubySpecs for a while now, and I don't have any objections for releases. Thanks for being responsive and listening to our concerns! Thanks, --Vladimir Vladimir Sizikov 2008-07-24T17:04:15 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17251 Hi, At Thu, 24 Jul 2008 19:51:49 +0900, Kurt Stephens wrote in [ruby-core:17939]: Vladimir and Charles stopped Shyouhei from releasing it due to failures of StringIO, but it seems to run well now. And the errors seemed since Mock#respond_to? didn't implement the optional argument. Nobuyoshi Nakada 2008-07-24T15:51:18 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17250 When will we see a new 1.8.6 release? Kurt Stephens Kurt Stephens 2008-07-24T10:51:49 http://permalink.gmane.org/gmane.comp.lang.ruby.core/17249 Issue #235 has been updated by Martin Dürst. I agree with Yui for the input encoding. The default for output should be UTF-8, however. An exception should be raised if the actual encoding and the declared encoding on input don't agree. An exception should not be raised if data from two or more input documents in different encodings is combined. ---------------------------------------- http://redmine.ruby-lang.org/issues/show/235 ---------------------------------------- http://redmine.ruby-lang.org Martin Dürst 2008-07-24T03:53:38 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.ruby.core