[#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

20 messages 2009/08/01
[#24649] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Tanaka Akira <akr@...> 2009/08/01

In article <4a73e51b5a4f9_138119f2a982704e@redmine.ruby-lang.org>,

[#24652] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Run Paint Run Run <runrun@...> 2009/08/01

> Is it valuable to implement such function?

[#24682] Re: [Bug #1852] Enumerable's #hash Raises ArgumentError When Recursive Values are Present — Tanaka Akira <akr@...> 2009/08/02

In article <67e307490908010125r6fa76654pa8e2224f714588fc@mail.gmail.com>,

[#24673] [Feature #1857] install *.h and *.inc — Roger Pack <redmine@...>

Feature #1857: install *.h and *.inc

21 messages 2009/08/01

[#24732] [Bug #1873] MatchData#[]: Omits All But Last Captures Corresponding to the Same Named Group — Run Paint Run Run <redmine@...>

Bug #1873: MatchData#[]: Omits All But Last Captures Corresponding to the Same Named Group

12 messages 2009/08/03

[#24775] [Feature #1889] Teach Onigurma Unicode 5.0 Character Properties — Run Paint Run Run <redmine@...>

Feature #1889: Teach Onigurma Unicode 5.0 Character Properties

30 messages 2009/08/05

[#24786] [Bug #1893] Recursive Enumerable#join is surprising — Jeremy Kemper <redmine@...>

Bug #1893: Recursive Enumerable#join is surprising

24 messages 2009/08/06
[#28422] [Bug #1893] Recursive Enumerable#join is surprising — Yusuke Endoh <redmine@...> 2010/03/02

Issue #1893 has been updated by Yusuke Endoh.

[#28438] Re: [Bug #1893] Recursive Enumerable#join is surprising — Yukihiro Matsumoto <matz@...> 2010/03/03

Hi,

[#24854] embedding ruby 1.9 frustration — Rolando Abarca <funkaster@...>

Hello,

12 messages 2009/08/10

[#24982] [Feature #1961] Kernel#__dir__ — Yutaka HARA <redmine@...>

Feature #1961: Kernel#__dir__

26 messages 2009/08/19
[#28898] [Feature #1961] Kernel#__dir__ — Roger Pack <redmine@...> 2010/03/23

Issue #1961 has been updated by Roger Pack.

[#28900] Re: [Feature #1961] Kernel#__dir__ — Kornelius Kalnbach <murphy@...> 2010/03/23

On 23.03.10 19:10, Roger Pack wrote:

[#25025] [Backport #1975] Backport Dir.mktmpdir — Kirk Haines <redmine@...>

Backport #1975: Backport Dir.mktmpdir

12 messages 2009/08/21

[#25041] Proposal: Simpler block format — Yehuda Katz <wycats@...>

I'd like to propose that we add the following syntax for procs in Ruby:

45 messages 2009/08/23
[#25046] Re: Proposal: Simpler block format — Caleb Clausen <caleb@...> 2009/08/23

Yehuda Katz wrote:

[#25049] Re: Proposal: Simpler block format — Yehuda Katz <wycats@...> 2009/08/23

On Sat, Aug 22, 2009 at 7:38 PM, Caleb Clausen <caleb@inforadical.net>wrote:

[#25058] Re: Proposal: Simpler block format — Yukihiro Matsumoto <matz@...> 2009/08/23

Hi,

[#25059] Re: Proposal: Simpler block format — Yehuda Katz <wycats@...> 2009/08/23

On Sun, Aug 23, 2009 at 3:33 PM, Yukihiro Matsumoto <matz@ruby-lang.org>wrote:

[#25063] Re: Proposal: Simpler block format — "David A. Black" <dblack@...> 2009/08/23

Hi --

[#25068] Re: Proposal: Simpler block format — brian ford <brixen@...> 2009/08/24

Hi,

[#25086] [Bug #1991] ruby should use twolevel namespace on OS X — Michal Suchanek <redmine@...>

Bug #1991: ruby should use twolevel namespace on OS X

12 messages 2009/08/24

[#25208] Module#prepend and Array#prepend — Yehuda Katz <wycats@...>

Matz,

23 messages 2009/08/30

[#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

15 messages 2009/08/30

[#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

18 messages 2009/08/31

[ruby-core:24855] [Bug #1921] Ripper Heredoc Parsing

From: Andy Keep <redmine@...>
Date: 2009-08-10 21:24:34 UTC
List: ruby-core #24855
Bug #1921: Ripper Heredoc Parsing
http://redmine.ruby-lang.org/issues/show/1921

Author: Andy Keep
Status: Open, Priority: Normal
Category: ext, Target version: 1.9.x
ruby -v: ruby 1.9.2dev (2009-08-08 trunk 24443) [i386-darwin9.7.0]

I'm using the Ripper parser extension in a project I'm working on for school, and I noticed that heredocs do not seem to process correctly.  What seems to be happening is that the scanner events are dispatched: heredoc_beg, then tstring_content, then heredoc_end, but at the parser level only the heredoc_end is coming back in the results.

To quickly demonstrate using Ripper's sexp generator:

$ irb -rripper
>> Ripper.sexp("<<-EOF\nThis is a\ntest of heredocs\nEOF")
=> [:program, [[:string_literal, [:string_content, [:heredoc_end, "EOF", [4, 0]]]]]]
>> Ripper.sexp_raw("<<-EOF\nThis is a\ntest of heredocs\nEOF")
=> [:program, [:stmts_add, [:stmts_new], [:string_literal, [:string_add, [:string_content], [:heredoc_end, "EOF", [4, 0]]]]]]

Here instead of the expected string content, "This is a\ntest of heredocs\n", we get [:heredoc_end, "EOF", [4, 0]] from the scanner.

While Ripper's sexp and sexp_raw do not seem to deliver the correct stuff, the correct scanner events are being fired off, so it is not just an issue of the scanner events begin incorrect or the content string being lost. I think the problem stems from the fact that the heredocs are handled within the lexer, and at the parser level only one value representing the string (or at least the final string) is expected, but the scanner is sending two final events.  First the tstring_content then the heredoc_end, both of which overwrite the yyval.  The right way to tackle this may be fundamentally change how heredocs are handled, but the simpler approach is to allow the heredoc_end to fire without it accidentally overwriting the yyval, since the parser is not expecting a heredoc value anyway.

I've included a patch to parse.y that basically adds a function called ripper_dispatch_ignored_scan_event, which mimics ripper_dispatch_scan_event, but does not update the yyval.  It then uses this to dispatch the heredoc_end event to avoid overwriting the tstring_content token.

With my patch:

$ irb -rripper
>> Ripper.sexp("t = <<-EOF\nThis is a\ntest of heredocs\nEOF")
=> [:program, [[:assign, [:var_field, [:ident, "t", [1, 0]]], [:string_literal, [:string_content, [:tstring_content, "This is a\ntest of heredocs\n", [2, 0]]]]]]]
>> Ripper.sexp_raw("t = <<-EOF\nThis is a\ntest of heredocs\nEOF")
=> [:program, [:stmts_add, [:stmts_new], [:assign, [:var_field, [:ident, "t", [1, 0]]], [:string_literal, [:string_add, [:string_content], [:tstring_content, "This is a\ntest of heredocs\n", [2, 0]]]]]]]


----------------------------------------
http://redmine.ruby-lang.org

In This Thread

Prev Next