[#23357] [Feature #1432] decrement and increment — Oleg Puchinin <redmine@...>
Feature #1432: decrement and increment
[#23372] [Bug #1438] dylib architecture error building 1.9.1-rc2 on osx10.5.6 — Matthew Moss <redmine@...>
Bug #1438: dylib architecture error building 1.9.1-rc2 on osx10.5.6
[#23402] [Bug #1448] [patch] Proper handling of recursive arrays — Marc-Andre Lafortune <redmine@...>
Bug #1448: [patch] Proper handling of recursive arrays
[#23449] Submit bugs against 1.9.1? — Robert Klemme <shortcutter@...>
Hi there,
[#23457] [Bug #1471] "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7 — John Carter <redmine@...>
Bug #1471: "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7
[#23464] [Feature #1473] Improvements on expect.rb — Luiz Angelo Daros de Luca <redmine@...>
Feature #1473: Improvements on expect.rb
[#23483] [Bug #1478] Ruby archive — Oleg Puchinin <redmine@...>
Bug #1478: Ruby archive
Issue #1478 has been updated by Luis Lavena.
Issue #1478 has been updated by Luis Lavena.
On Fri, Apr 2, 2010 at 17:13, Luis Lavena <redmine@ruby-lang.org> wrote:
> Thanks for your comment.
OK Hiroshi, I read some of the comments earlier in the thread that I
On 5/20/10, Jonathan Nielsen <jonathan@jmnet.us> wrote:
Hi,
(2010/05/22 19:58), Benoit Daloze wrote:
On 22 May 2010 18:40, Urabe Shyouhei wrote:
(2010/05/23 2:38), Benoit Daloze wrote:
On Sat, May 22, 2010 at 1:21 PM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
[#23491] [Bug #1482] Kernel.exec doesn't respect COMSPEC environment variable on Windows — Evgeniy Dolzhenko <redmine@...>
Bug #1482: Kernel.exec doesn't respect COMSPEC environment variable on Windows
[#23492] [Bug #1484] Ruby 1.8.6_p368 and Ruby 1.8.7_p160 have threading regressions — Hans de Graaff <redmine@...>
Bug #1484: Ruby 1.8.6_p368 and Ruby 1.8.7_p160 have threading regressions
[#23499] [Bug #1487] String#each_char must return self — Marc-Andre Lafortune <redmine@...>
Bug #1487: String#each_char must return self
Hi,
On Sat, 23 May 2009 10:20:50 +0900
[#23501] [Bug #1490] DateTime::civil fails with second=59 and fractional second > 0 — Paul Harris <redmine@...>
Bug #1490: DateTime::civil fails with second=59 and fractional second > 0
[#23505] [Bug #1494] tempfile#unlink may silently fail on windows — Nicholas Manning <redmine@...>
Bug #1494: tempfile#unlink may silently fail on windows
Issue #1494 has been updated by Shyouhei Urabe.
Issue #1494 has been updated by Hongli Lai.
[#23520] [Bug #1504] installed ri docu is not where ri actually searches when compiled with program-suffix — Yuki Sonoda <redmine@...>
Bug #1504: installed ri docu is not where ri actually searches when compiled with program-suffix
[#23538] [ANN] RubyKaigi2009: Commiter Invitation — SASADA Koichi <ko1@...>
Hi,
[#23543] a feature for ruby: Kernel#in? — Roger Pack <rogerdpack@...>
Following a discussion on ruby-talk of a few ideas for ruby[1],
Excerpts from rogerdpack's message of Mon May 25 07:41:36 +0300 2009:
> I am pretty opposed to adding #in?; however, it is currently
[#23572] [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork? — Hongli Lai <redmine@...>
Bug #1525: Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?
Issue #1525 has been updated by Eric Wong.
Issue #1525 has been updated by Vanja Bucic.
On Jul 21, 2009, at 9:06 PM, Vanja Bucic wrote:
Issue #1525 has been updated by Vanja Bucic.
Vanja Bucic wrote:
none < wrote:
Issue #1525 has been updated by Nobuyoshi Nakada.
In article <4b03c299d3778_4360404660a1be@redmine.ruby-lang.org>,
In article <87einw55ej.fsf@fsij.org>,
Tanaka Akira wrote:
[#23584] [Bug #1528] setlocale is not initialized causing problems when using iconv — Hans de Graaff <redmine@...>
Bug #1528: setlocale is not initialized causing problems when using iconv
[#23593] Defining #name= at the class level — Gregory Brown <gregory.t.brown@...>
Hi folks,
Hi,
Excerpts from Yukihiro Matsumoto's message of Fri May 29 01:21:19 +0300 2009:
Hi,
[#23595] Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...>
The RUBY_PLATFORM constant is documented in the latest Pickaxe as "The
On Thu, May 28, 2009 at 3:41 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
On Thu, May 28, 2009 at 2:52 PM, Luis Lavena <luislavena@gmail.com> wrote:
On Thu, May 28, 2009 at 7:08 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
On Thu, May 28, 2009 at 7:22 PM, Luis Lavena <luislavena@gmail.com> wrote:
> 1) The guy who wrote the gem fell into the trap of assuming that
Roger Pack wrote:
[#23614] [Bug #1535] Hash#merge! Inside Iterator Can Cause RuntimeError — Run Paint Run Run <redmine@...>
Bug #1535: Hash#merge! Inside Iterator Can Cause RuntimeError
[#23630] Expected Behaviour of Modifying an Iterator in the Block to Which it Yields? — Run Paint Run Run <runrun@...>
Hi,
[#23636] feature request: Directory.dir? — Roger Pack <rogerdpack@...>
For some reason it seems odd to have to do File.dir?
[#23639] [Bug #1541] mingw ssl: Errno::ENOTSOCK: An operation was attempted on something that is not a socket. — Roger Pack <redmine@...>
Bug #1541: mingw ssl: Errno::ENOTSOCK: An operation was attempted on something that is not a socket.
Issue #1541 has been updated by Roger Pack.
[#23644] [Bug #1545] Patches for the Hash Documentation — Run Paint Run Run <redmine@...>
Bug #1545: Patches for the Hash Documentation
Excerpts from message of Sun May 31 06:38:54 +0300 2009:
[#23646] Counterpart to File.extname — Martin DeMello <martindemello@...>
File.extname ought to have a complementary method that gets everything
On Sun, May 31, 2009 at 1:52 AM, Martin DeMello <martindemello@gmail.com> wrote:
On Mon, 1 Jun 2009 03:35:47 +0900
On Mon, Jun 1, 2009 at 6:11 AM, Michael Fellinger <m.fellinger@gmail.com> wrote:
[ruby-core:23602] Re: Meaning of RUBY_PLATFORM
On Thu, May 28, 2009 at 2:52 PM, Luis Lavena <luislavena@gmail.com> wrote: > On Thu, May 28, 2009 at 3:41 PM, Rick DeNatale <rick.denatale@gmail.com> wrote: >> The RUBY_PLATFORM constant is documented in the latest Pickaxe as "The >> identifier of the platform running this program." >> >> Actually it appears to actually be the identifier of the platform on >> which ruby was compiled. For example, I'm running a darwin ports >> version of Ruby installed back when this machine was running OS X 10.4 >> (Tiger), it has since been upgraded to Leopard 10.5.7 >> >> $ ruby -e'p RUBY_PLATFORM;p `uname -a`' >> "i686-darwin8.11.1" >> "Darwin Macintosh-3.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar >> 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386\n" >> >> Note the difference. >> > > On my case, RUBY_PLATFORM is reporting "universal-darwin-9.0' > > And Gem::Platform.local: > > #<Gem::Platform:0x9267c4 @cpu="universal", @os="darwin", @version="9"> > >> I just noticed this today when I tried out a new OS X specific gem >> which baled out when it tought I was running a back-level version of >> OS X. >> > > Unless there is a i386 or ppc code there (like you're compiling with > inline assembler or something) then RUBY_PLATFORM =~ /darwin/ should > be enough. > > Can you tell me which Gem? (just curious). The gem is autospec-mac which is looking at the version of OS X to determine if it has fsevent support. This isn't an issue of installing the gem, it is looking at runtime to determine if the service can be used, if so it then forks execution (with backticks) of a binary provided with the gem. This is an OS X only gem which allows autotest to be driven by file system events rather than having to poll the filesystem for changed files, it also adds working growl notifications. That gem was actually split into two gems autospec-fsevent and autospec-growl. the autospec-fsevent gem is now looking at not only the major version of OS X, but the minor one since the fsevent service seems to be there starting with 8.9. I opened a ticket with the gem author suggesting that he use `uname -a` rather than RUBY_PLATFORM to determine the OS version, since RUBY_PLATFORM is showing the version at the time that ruby was compiled/configured. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale