[#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:23647] Re: [Bug #1545] Patches for the Hash Documentation
Excerpts from message of Sun May 31 06:38:54 +0300 2009: > Bug #1545: Patches for the Hash Documentation > http://redmine.ruby-lang.org/issues/show/1545 > > Author: Run Paint Run Run > Status: Open, Priority: Normal > ruby -v: ruby 1.9.2dev (2009-05-28 trunk 23601) [i686-linux] > > I've attached a couple of patches against hash.c to fix minor documentation > typos. The 7th is an attempt to fix the verbiage regarding the ordering of > hashes which states "The order in which you traverse a hash by either key or > value may seem arbitrary, and will generally not be in the insertion order." > This contradicts the doc/NEWS-1.9.1 file which, correctly, explains "Hash > preserves order. It enumerates its elements in the order in which the keys are > inserted." I've tried to use the latter wording as much as possible in my > suggested modification. The wording should maybe *not* be changed? Even though I have no doubt that everyone and their mothers will rely on insertion order in the future, it is specified that it is implementation-specific behaviour. (In my mind, using it implies Hash being the wrong data structure, but that is naturally debatable.) Of course, if we view the RDoc as strictly applying to MRI only, it is fine to change...a small mention of possible unportability is OK in that case. But I am not sure if it is feasible to make that assumption. Eero -- Magic is insufficiently advanced technology.