[#31647] [Backport #3666] Backport of r26311 (Bug #2587) — Luis Lavena <redmine@...>

Backport #3666: Backport of r26311 (Bug #2587)

13 messages 2010/08/07

[#31666] [Bug #3677] unable to run certain gem binaries' in windows 7 — Roger Pack <redmine@...>

Bug #3677: unable to run certain gem binaries' in windows 7

10 messages 2010/08/10

[#31676] [Backport #3680] Splatting calls to_ary instead of to_a in some cases — Tomas Matousek <redmine@...>

Backport #3680: Splatting calls to_ary instead of to_a in some cases

10 messages 2010/08/11

[#31681] [Bug #3683] getgrnam on computer with NIS group (+)? — Rocky Bernstein <redmine@...>

Bug #3683: getgrnam on computer with NIS group (+)?

13 messages 2010/08/11

[#31843] Garbage Collection Question — Asher <asher@...>

This question is no doubt a function of my own lack of understanding, but I think that asking it will at least help some other folks see what's going on with the internals during garbage collection.

17 messages 2010/08/25
[#31861] Re: Garbage Collection Question — Roger Pack <rogerdpack2@...> 2010/08/26

> The question in short: when an object goes out of scope and has no

[#31862] Re: Garbage Collection Question — Asher <asher@...> 2010/08/26

Right - so how does a pointer ever get off the stack?

[#31873] Re: Garbage Collection Question — Kurt Stephens <ks@...> 2010/08/27

On 8/26/10 11:51 AM, Asher wrote:

[#31894] Re: Garbage Collection Question — Asher <asher@...> 2010/08/27

I very much appreciate the response, and this is helpful in describing the narrative, but it's still a few steps behind my question - but it may very well have clarified some points that help us get there.

[#31896] Re: Garbage Collection Question — Evan Phoenix <evan@...> 2010/08/27

You have introduced something called a "root node" without defining it. What do you mean by this?

[#31885] Avoiding $LOAD_PATH pollution — Eric Hodel <drbrain@...7.net>

Last year Nobu asked me to propose an API for adding an object to

21 messages 2010/08/27

[#31947] not use system for default encoding — Roger Pack <rogerdpack2@...>

It strikes me as a bit "scary" to use system locale settings to

19 messages 2010/08/30

[#31971] Change Ruby's License to BSDL + Ruby's dual license — "NARUSE, Yui" <naruse@...>

Ruby's License will change to BSDL + Ruby's dual license

16 messages 2010/08/31

[ruby-core:31596] RFC: Patches for Ruby 1.9 runtime for debuggers, profilers, and beyond

From: Rocky Bernstein <rockyb@...>
Date: 2010-08-02 15:16:28 UTC
List: ruby-core #31596
I'd like to offer for public review of some patches for the Ruby 1.9
run-time environment. The patches attempt to support better run-time
introspection, especially of VM instruction sequences, and execution
tracing; they promote better support for writing tools like debuggers or
profilers.

I use these changes to Ruby in an experimental C extension which provides a
runtime call-stack object (http://github.com/rocky/rb-threadframe). In turn,
that extension is used in an experimental debugger (
http://github.com/rocky/rbdbgr).

The patches come in 3 variations.

  1. A single patch file for the trunk (1.9.3),
http://github.com/rocky/rb-threadframe/blob/master/patches/ruby-trunk-combined.patch

  2. The above broken out into 14 individual patches. There are 15, but the
last one, 14-eval-iseq-name.patch is not currently used.

  3. A single patch file for 1.9.2 rc2. This is analogous to 1.

The patches are a bit too large to post here, but you can find them in the
threadframe project:
http://github.com/rocky/rb-threadframe/tree/master/patches. Each of the 14
separate patches has text at the beginning that describes what the patch
does.

A synopsis of the patches is given below.

0. Changes to allow a C extension to get access to some Ruby methods and
fields defined in vm_core.h.
1. Fixes rb_vm_get_sourceline() so it returns the correct line number when
the passed a VM PC with value 0.
2. Adds the ability to set tracing on or off per call frame.
3. Add more access to VM opcodes and finer control of VM disassembly.
4. Adds access to instruction sequences via  SCRIPT_ISEQS__ and ISEQS__.
This mechanism is similar to SCRIPT_LINES__
5. Allows an extension to create an RubyVM::InstructionSequence object from
an rb_seq_t pointer. Useful in adding Method#iseq and Proc#iseq
6. Adds the ability to get the number of parameters passed to a C function.
It is like "arity" but contains the *actual* number of parameters passed.
7. Support for fast breakpoints. Used in the experimental 1.9 debugger.
8. Provides a way to get the exception object in a trace hook on a "raise"
event callback.
9. Adds an optional trace masks trace hooks, and chaining trace hooks for
threads. Adjusts the location slightly in C-function callbacks for calls and
returns so they have access to the call stack. Allows a hook to change the
return value on a C return.
10. Changes the instruction-sequence name of the top-most instruction
sequence to something less generic, e.g.  <top /tmp/ruby-program.rb> vs.
<top (required)>
11. Adds RubyVM::InstructionSequence#arity and allows a C extension to
return binding thread- and control-frame parameters. Used in rb-threadframe
to provide RubyVM::ThreadFrame#binding.
12. Adds a new trace event mask to provide the ability to step VM
instructions
13. Keeps a trace hook which raises an exception in fielding a C return from
looping infinitely.

I look forward to hearing your comments and suggestions.

Thanks.

In This Thread

Prev Next