[#24648] [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Run Paint Run Run <redmine@...>
Bug #1852: Enumerable's #hash Raises ArgumentError When Recursive Values are Present
In article <4a73e51b5a4f9_138119f2a982704e@redmine.ruby-lang.org>,
> Is it valuable to implement such function?
In article <67e307490908010125r6fa76654pa8e2224f714588fc@mail.gmail.com>,
> * several real applications are found
In article <67e307490908012245x3bf3be81oc7f060c2569ad4ab@mail.gmail.com>,
>>> * several real applications are found
[#24650] [Bug #1853] Cannot make constants using upper-case extended characters? — Brian Candler <redmine@...>
Bug #1853: Cannot make constants using upper-case extended characters?
[#24666] request: include more headers/source in installations? — Roger Pack <rogerdpack@...>
Background:
[#24673] [Feature #1857] install *.h and *.inc — Roger Pack <redmine@...>
Feature #1857: install *.h and *.inc
Issue #1857 has been updated by Mark Moseley.
Issue #1857 has been updated by Jason Roelofs.
Hi,
Issue #1857 has been updated by Mark Moseley.
[#24675] Include Order — James Gray <james@...>
I was surprised to find that:
[#24747] [Bug #1881] [PATCH] Build Documentation for Kernel#gem and Gem — Run Paint Run Run <redmine@...>
Bug #1881: [PATCH] Build Documentation for Kernel#gem and Gem
[#24775] [Feature #1889] Teach Onigurma Unicode 5.0 Character Properties — Run Paint Run Run <redmine@...>
Feature #1889: Teach Onigurma Unicode 5.0 Character Properties
Issue #1889 has been updated by Yui NARUSE.
Hi,
> |First, we should decide supporting Unicode version.
[#24786] [Bug #1893] Recursive Enumerable#join is surprising — Jeremy Kemper <redmine@...>
Bug #1893: Recursive Enumerable#join is surprising
Issue #1893 has been updated by Yusuke Endoh.
Hi,
Hi,
Hi,
Hi,
Hi,
Hi,
Hi,
[#24791] [Bug #1898] Method#== for Methods with the Same Body — Run Paint Run Run <redmine@...>
Bug #1898: Method#== for Methods with the Same Body
[#24793] [Feature #1900] Suggestion: Encoding#ascii_compatible? — Brian Candler <redmine@...>
Feature #1900: Suggestion: Encoding#ascii_compatible?
[#24824] 1.9 gem env is far slower than on 1.8? — Roger Pack <rogerdpack@...>
Currently when I run "gem env" on a windows machine
[#24854] embedding ruby 1.9 frustration — Rolando Abarca <funkaster@...>
Hello,
> I'm getting really frustrated, because there's almost no documentation
> Perhaps try using only rb_thread_blocking_region()?
[#24862] [Bug #1925] Division of negative numbers — Roswitha Rissner <redmine@...>
Bug #1925: Division of negative numbers
[#24885] IDEA: Shortcut syntax for binary strings? — Gregory Brown <gregory.t.brown@...>
Hey folks,
On Aug 12, 2009, at 2:55 PM, Gary Wright wrote:
On Wed, Aug 12, 2009 at 4:53 PM, James Gray<james@grayproductions.net> wrote:
[#24921] regparse.c - patch to fix memory leak — Ralf Junker <ralfjunker@...>
There are several memory leaks in regparse.c. They all relate to incomplete pattern branches, where a branch node is not freed when branch parsing is aborted. I discovered this by successively shortening all patterns in my test suite (which is not in Ruby, nor in C, unfortunately) down to zero length.
[#24923] [Bug #1939] Ripper doesn't handle local variables — Magnus Holm <redmine@...>
Bug #1939: Ripper doesn't handle local variables
[#24927] [Bug #1940] Segmentation fault on TestFiber#test_many_fibers_with_threads (make check) — Luis Lavena <redmine@...>
Bug #1940: Segmentation fault on TestFiber#test_many_fibers_with_threads (make check)
[#24982] [Feature #1961] Kernel#__dir__ — Yutaka HARA <redmine@...>
Feature #1961: Kernel#__dir__
Wouldn't it be a little confusing to remember that __FILE__ is uppercase and
Hi,
Issue #1961 has been updated by Roger Pack.
On 23.03.10 19:10, Roger Pack wrote:
Perhaps __FILE__ should not be a raw String object, but rather a CurrentFile object. It could have a #to_str to return the normal String so it can be used like normal, but can provide methods like #dir, where __FILE__.dir == File.dirname(__FILE__).
This is nice but would not be backward compatible with code that
On 3/24/10, Charles Oliver Nutter <headius@headius.com> wrote:
Actually, I proposed that it be a String subclass, so it actually
[#24989] [Bug #1964] Compile Issue on Solaris 10 — Brian Toal <redmine@...>
Bug #1964: Compile Issue on Solaris 10
[#25010] [Bug #1972] Changing ENV['TZ'] of a running process should change behavior of Time — Shri Borde <redmine@...>
Bug #1972: Changing ENV['TZ'] of a running process should change behavior of Time
[#25025] [Backport #1975] Backport Dir.mktmpdir — Kirk Haines <redmine@...>
Backport #1975: Backport Dir.mktmpdir
In article <4a8e914c6160_2100affe60043c6@redmine.ruby-lang.org>,
On Fri, Aug 21, 2009 at 8:17 PM, Tanaka Akira<akr@fsij.org> wrote:
In article <f4cd26df0908240817s68a6835ie65d942bbd3b95be@mail.gmail.com>,
[#25027] [Bug #1978] fixed crash in lib/logger.rb from dependency on svn keywork expansion — Stephen Bannasch <redmine@...>
Bug #1978: fixed crash in lib/logger.rb from dependency on svn keywork expansion
[#25032] [Bug #1979] parser confused by local variable assignment — caleb clausen <redmine@...>
Bug #1979: parser confused by local variable assignment
[#25039] [Bug #1982] Kernel.load(..., true) --> scope problem — Johan Holmberg <redmine@...>
Bug #1982: Kernel.load(..., true) --> scope problem
[#25041] Proposal: Simpler block format — Yehuda Katz <wycats@...>
I'd like to propose that we add the following syntax for procs in Ruby:
On Aug 22, 2009, at 7:04 PM, Yehuda Katz wrote:
Yehuda Katz wrote:
On Sat, Aug 22, 2009 at 7:38 PM, Caleb Clausen <caleb@inforadical.net>wrote:
Yehuda Katz wrote:
On Sun, Aug 23, 2009 at 2:00 PM, Caleb Clausen <caleb@inforadical.net>wrote:
Hi,
On Sun, Aug 23, 2009 at 3:33 PM, Yukihiro Matsumoto <matz@ruby-lang.org>wrote:
On Aug 23, 2009, at 15:58, Yehuda Katz wrote:
Hi --
Hi,
Hi,
Hi everyone,
On Sun, Aug 23, 2009 at 4:53 PM, David A. Black <dblack@rubypal.com> wrote:
[#25086] [Bug #1991] ruby should use twolevel namespace on OS X — Michal Suchanek <redmine@...>
Bug #1991: ruby should use twolevel namespace on OS X
Issue #1991 has been updated by Shyouhei Urabe.
Hi,
[#25131] [Feature #1999] Improved Tempfile — Hongli Lai <redmine@...>
Feature #1999: Improved Tempfile
[#25139] Patch writer's guide to submit — Yukihiro Matsumoto <matz@...>
Hi,
Reducing the submitters' frustration by reducing the delay for
[#25143] Is this an intentional change in 1.9? — Rick DeNatale <rick.denatale@...>
This came up on the ruby lang forum.
Hi,
On Wed, Aug 26, 2009 at 7:25 PM, Yukihiro Matsumoto<matz@ruby-lang.org> wrote:
[#25151] [Bug #2003] respond_to? not working 1.9.1p243 OSX — Adam Salter <redmine@...>
Bug #2003: respond_to? not working 1.9.1p243 OSX
[#25181] RegOOps: An Object-Oriented Approach to Pattern Matching — Run Paint Run Run <runrun@...>
Regexps in Ruby can feel like a jagged edge to the otherwise smooth
[#25191] [Feature #2012] Set event_flags on thread creation if hook exists — Mark Moseley <redmine@...>
Feature #2012: Set event_flags on thread creation if hook exists
[#25200] [Bug #2018] [irb] BasicObject.new doesn't have an inspect — Daniel Bovensiepen <redmine@...>
Bug #2018: [irb] BasicObject.new doesn't have an inspect
[#25208] Module#prepend and Array#prepend — Yehuda Katz <wycats@...>
Matz,
Yehuda Katz wrote:
On Sun, Aug 30, 2009 at 10:09 PM, Joel VanderWerf
Hi,
[#25210] [Feature #2022] Patch for ruby-1.8.6 and openssl-1.0 — Jeroen van Meeuwen <redmine@...>
Feature #2022: Patch for ruby-1.8.6 and openssl-1.0
[#25217] [Bug #2025] problem with pthread handling on non NPTL platform — Petr Salinger <redmine@...>
Bug #2025: problem with pthread handling on non NPTL platform
[#25220] [Bug #2026] String encodings are not supported by most of IO on Linux — Vit Ondruch <redmine@...>
Bug #2026: String encodings are not supported by most of IO on Linux
Issue #2026 has been updated by Yui NARUSE.
2009/9/1 Yui NARUSE <redmine@ruby-lang.org>:
[ruby-core:25112] Re: Proposal: Simpler block format
Abstracting from the syntax details, I think some streamlining like the
one below would be highly beneficial to Ruby.
It's very difficult to understand why in Ruby, with its great
streamlined design (e.g. "everything is an object", "everything is an
expression"), when it comes to "chunks of code with parameters", there
is such a mess. In something like Perl, the current
proc/block/lambda/method stuff might be called "great design". By Ruby
stanards, it's definitely not.
[in an earlier mail, Matz wrote:]
> The def keyword is to define a method. I assume your def {} proposal
> is to declare an anonymous procedure object, which is NOT a method at
> all. For me, the difference is big enough to reject the proposal.
What about the def keyword for methods on the main object? These, by
virtue of the 'main object trick', are technically methods (i.e. chunks
of code with a self). But the way they are used, in at least 99% of the
cases, and the way many people (including myself) think about them is as
procedure objects (i.e. chunks of code without a self). So we already
have a case where the above difference pretty much exists but the syntax
is the same. What essentially remains is the difference between "has a
name" and "anonymous", which is easy to handle in an uniform way for
both humans and computers.
Regards, Martin.
On 2009/08/24 14:48, Yehuda Katz wrote:
> Essentially, we currently have two semantic constructs: method-style and
> block-style. I am suggesting that we take the literals of each style and use
> them as literals whenever those semantics are expected.
> my_method { block_semantics }
>
> In this case, { block } is the literal for block-semantics. I am suggesting
> that we extend the use of this literal to the other case where
> block-semantics are used: Procs.
>
> my_method({ still_block_semantics })
>
> Similarly:
>
> def method_name() method_semantics end
>
> In this case, def is the literal for method-semantics. I am suggesting that
> we extend the use of this literal to the other case where method-semantics
> are used: Lambdas.
>
> name = def { still_method_semantics }
>
> As you can see, by using the same literals for equivalent constructs, we
> simplify the problem in the mind of the programmer. When he sees "def" he
> knows that method semantics are to be used, and required arguments are
> required, return will return from the block, and yield will yield to the
> block. When he sees bare {} he knows that block semantics are used, all
> arguments are optional, return will return from enclosing "def", and yield
> will yield to block passed into enclosing "def".
>
> This will always be true, no matter if lambda is being used, proc is being
> used, method is being used, or block is being used.
>
> -- Yehuda
>
> On Sun, Aug 23, 2009 at 9:36 PM, Evan Phoenix<evan@fallingsnow.net> wrote:
>
>> Hi everyone,
>>
>> I know that one of the original reasons for having -> was because it
>> allowed for default arguments. Since that has since been fixed for || args,
>> what about simply moving where the arguments for -> are?
>>
>> Rather than:
>>
>> ->(a,b) { a + b }
>>
>> you have:
>>
>> ->{ |a,b| a + b }
>>
>> I find that quite a bit easier to read, and it's syntax everyone is used
>> to. In addition, it removes the case that I find incredibly hard to read:
>>
>> -> a, b { a + b }
>>
>> For defaults, from:
>>
>> -> a = 1 { a + 3 }
>>
>> to:
>>
>> ->{ |a=1| a + 3 }
>>
>> Seems like it would be fine to allow space between -> and { as it is now as
>> well:
>>
>> -> { |a,b| a + b }
>>
>> I think of this as sort of a middle ground between the current ->
>> implementation and the bare {} implementation. It unifies the idea of a
>> separate identifier with syntax that all ruby programmers are accustom to
>> today.
>>
>> - Evan
>>
>>
>>
>> On Aug 23, 2009, at 9:21 PM, Yukihiro Matsumoto wrote:
>>
>> Hi,
>>> In message "Re: [ruby-core:25068] Re: Proposal: Simpler block format"
>>> on Mon, 24 Aug 2009 13:03:53 +0900, brian ford<brixen@gmail.com>
>>> writes:
>>>
>>> |Could we add def {} and see by usage which prevails? Or take a
>>> |world-wide vote (perhaps weighted by number of lines of Ruby code
>>> |written by the voter)?
>>>
>>> The def keyword is to define a method. I assume your def {} proposal
>>> is to declare an anonymous procedure object, which is NOT a method at
>>> all. For me, the difference is big enough to reject the proposal.
>>>
>>> matz.
>>>
>>>
>>>
>>
>
>
--
#-# Martin J. Dst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp