[#33640] [Ruby 1.9-Bug#4136][Open] Enumerable#reject should not inherit the receiver's instance variables — Hiro Asari <redmine@...>

Bug #4136: Enumerable#reject should not inherit the receiver's instance variables

10 messages 2010/12/08

[#33667] [Ruby 1.9-Bug#4149][Open] Documentation submission: syslog standard library — mathew murphy <redmine@...>

Bug #4149: Documentation submission: syslog standard library

11 messages 2010/12/10

[#33683] [feature:trunk] Enumerable#categorize — Tanaka Akira <akr@...>

Hi.

14 messages 2010/12/12
[#33684] Re: [feature:trunk] Enumerable#categorize — "Martin J. Dst" <duerst@...> 2010/12/12

[#33687] Towards a standardized AST for Ruby code — Magnus Holm <judofyr@...>

Hey folks,

23 messages 2010/12/12
[#33688] Re: Towards a standardized AST for Ruby code — Charles Oliver Nutter <headius@...> 2010/12/12

On Sun, Dec 12, 2010 at 9:55 AM, Magnus Holm <judofyr@gmail.com> wrote:

[#33689] Re: Towards a standardized AST for Ruby code — "Haase, Konstantin" <Konstantin.Haase@...> 2010/12/12

On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:

[#33763] [Ruby 1.9-Bug#4168][Open] WeakRef is unsafe to use in Ruby 1.9 — Brian Durand <redmine@...>

Bug #4168: WeakRef is unsafe to use in Ruby 1.9

43 messages 2010/12/17

[#33815] trunk warnflags build issue with curb 0.7.9? — Jon <jon.forums@...>

As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.

11 messages 2010/12/22

[#33833] Ruby 1.9.2 is going to be released — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2010/12/23

[#33846] [Ruby 1.9-Feature#4197][Open] Improvement of the benchmark library — Benoit Daloze <redmine@...>

Feature #4197: Improvement of the benchmark library

15 messages 2010/12/23

[#33910] [Ruby 1.9-Feature#4211][Open] Converting the Ruby and C API documentation to YARD syntax — Loren Segal <redmine@...>

Feature #4211: Converting the Ruby and C API documentation to YARD syntax

10 messages 2010/12/26

[#33923] [Ruby 1.9-Bug#4214][Open] Fiddle::WINDOWS == false on Windows — Jon Forums <redmine@...>

Bug #4214: Fiddle::WINDOWS == false on Windows

15 messages 2010/12/27

[ruby-core:33700] Re: Towards a standardized AST for Ruby code

From: Rocky Bernstein <rockyb@...>
Date: 2010-12-13 00:34:30 UTC
List: ruby-core #33700
On Sun, Dec 12, 2010 at 7:09 PM, Ryan Davis <ryand-ruby@zenspider.com>wrote:

>
> On Dec 12, 2010, at 08:54 , Haase, Konstantin wrote:
>
> > On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:
> >
> >> The only down side at the moment is that RubyParser does not support
> >> 1.9 syntax.
> >
> > Also, such a parser cannot be used to inspect a live system (accessing
> the AST for a method or closure, for instance) unless it would be possible
> to access the source code of those (as in JavaScript). Therefore it cannot
> be used for say partial evaluation in a live system (pypy does this for
> generating extremely fast code).
>
> I have asked until I was blue in the face for 1.9 to be extended w/
> optional live AST access. It would make really powerful tools available to
> all rubyists across 1.8 and 1.9. Despite this desirable fact, it has been
> rejected time and time again.
>

I have been using ("maintaining" is probably too strong a word) a patched
version of Ruby 1.9.2 which supports debugging better. I haven't done this
yet, but I will probably  keep the AST around precisely because folks have
requested for it, and to be able to use MRI 1.8 tools that currently work on
ASTs.

Given the way things are right now, it is my belief that it is very
difficult to have one version of Ruby YARV 1.9.x that both performs
extremely well, is flexible in implementation choices, yet has all of the
"live" introspection facilities one might have say in a Smalltalk system.
 Having two interpreters based on the same code base, while not ideal or
easy, seems to me at least more doable.

On  the other hand, I do believe that in the rubinius implementation it is
possible to have one interpreter/system which suits both competing needs of
performance and live introspection. I believe this because in a sense
rubinius *is* already two implementations: a Ruby interpreter plus a JIT for
it.


> I've gotten rather lame responses on why it is undesirable (usually
> memory--which seems moot if the AST is only available given a cmdline flag
> or other opt-in only option).
>
> I've since given up asking and left it to others to ask. (Like at rubyconf
> 2010's "ask matz" session--thank you!)
>
>
>

In This Thread