[#59462] [ruby-trunk - Bug #9342][Open] [PATCH] SizedQueue#clear does not notify waiting threads in Ruby 1.9.3 — "jsc (Justin Collins)" <redmine@...>

9 messages 2014/01/02

[#59466] [ruby-trunk - Bug #9343][Open] [PATCH] SizedQueue#max= wakes up waiters properly — "normalperson (Eric Wong)" <normalperson@...>

11 messages 2014/01/02

[#59498] [ruby-trunk - Bug #9352][Open] [BUG] rb_sys_fail_str(connect(2) for [fe80::1%lo0]:3000) - errno == 0 — "kain (Claudio Poli)" <claudio@...>

10 messages 2014/01/03

[#59516] [ruby-trunk - Bug #9356][Open] TCPSocket.new does not seem to handle INTR — "charliesome (Charlie Somerville)" <charliesome@...>

48 messages 2014/01/03

[#59538] [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — "shyouhei (Shyouhei Urabe)" <shyouhei@...>

33 messages 2014/01/03
[#59582] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — SASADA Koichi <ko1@...> 2014/01/06

Intersting challenge.

[#59541] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — Eric Wong <normalperson@...> 2014/01/04

Hi, I noticed a trivial typo in array.c, and it fails building struct.c

[#59583] [ruby-trunk - Bug #9367][Open] REXML::XmlDecl doesn't use user specified quotes — "bearmini (Takashi Oguma)" <bear.mini@...>

12 messages 2014/01/06

[#59642] [ruby-trunk - Bug #9384][Open] Segfault in ruby 2.1.0p0 — "cbliard (Christophe Bliard)" <christophe.bliard@...>

11 messages 2014/01/08

[#59791] About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...>

A while ago I created a proof-of-concept that I intended to use in my

16 messages 2014/01/15
[#59794] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/15

On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59808] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/16

Em 15-01-2014 19:42, Eric Hodel escreveu:

[#59810] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/16

On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59826] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/17

Em 16-01-2014 19:43, Eric Hodel escreveu:

[#59832] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/17

On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[ruby-core:60162] Re: [ruby-trunk - Bug #9456] Include bin/racc with ruby

From: David MacMahon <davidm@...>
Date: 2014-01-28 05:30:23 UTC
List: ruby-core #60162
I think a distinction needs to be made between the racc executable and the racc runtime library.  My understanding is that the racc executable (bin/racc) is needed to develop a racc-based parser for a given application.  Anyone who wants to use the application that contains the resultant parser needs the racc runtime library, but they don't need the racc executable.  Thus, including the racc runtime library in the Ruby standard library is a way to ensure that racc parsers will be usable by anyone with a basic Ruby environment.  Those who want to develop racc-based parsers will need the racc executable (and a suitable grammar file) to generate the parser, but those developers are more than capable of obtaining the racc executable (e.g. by installing the racc gem) for their own development environment.

Instead of asking for bin/racc to be included in the standard library, it make more sense (IMHO) to ask whether the racc runtime could be removed from the standard library so as not to favor one parser runtime library over another one.  For example, since the racc runtime is included in stdlib, why not also include the treetop runtime (if there is one) or any other "runtime" library in stdlib?  Where does line of reasoning end?

On the other hand, why even have a standard library if everything can be installed gems?  Where would that line of reasoning end?

My guess is that the racc runtime library has been "grandfathered in" since it has been part of stdlib for so long (since Ruby 1.6?).

Dave

On Jan 27, 2014, at 6:48 PM, e@zzak.io wrote:

> Issue #9456 has been updated by Zachary Scott.
> 
> 
>> Why gem is not enough?
> 
> For the same reason that the gem is included in stdlib, if we can't include the full functionality of the gem then it shouldn't be inclued in stdlib.
> 
> ----------------------------------------
> Bug #9456: Include bin/racc with ruby
> https://bugs.ruby-lang.org/issues/9456#change-44648
> 
> * Author: Zachary Scott
> * Status: Open
> * Priority: Normal
> * Assignee: Minero Aoki
> * Category: 
> * Target version: current: 2.2.0
> * ruby -v: 2.2.0dev
> * Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN
> ----------------------------------------
> As you [can see](https://github.com/ruby/ruby/tree/trunk/bin) we include executables for Rake, RDoc, ri, ERB, RubyGems, and Irb with Ruby.
> 
> We should also include Racc as an executable for Ruby.
> 
> This resolves an issue where libraries requiring Racc, and using the binary executable, must install the Racc gem in order to use bin/racc.
> 
> I'm fairly sure this change won't cause any issues, so I'd be happy to commit it.
> 
> 
> 
> -- 
> http://bugs.ruby-lang.org/

In This Thread

Prev Next