Thank you for the clarification.
God willing, I think this will be doable in the not-too-distant future in
the trepanning debugger, rbx-trepanning. Already you can do things like this
in the patched YARV debugger using the gdb-like "condition" command. (Also
in the YARV version, one can add conditions onto the end of a stepping
commands.)
Currently the breakpoint structure in the Rubinius debugger has a field for
storing a condition. But I don' t have any code right now for setting it or
testing it when a breakpoint is hit. The code to parse a breakpoint command
is at the stage where it is in need of rewriting. Some other commands that
refer to locations like the "list" command are also way too complex in how
they parse.
So fairly soon in the debugger I will be adding a PEG parser to be able to
first parse locations, such are used in specifying breakpoints. Later the
PEG grammar will handle better even more complex command jargon that you
seem to want:
break <location> if/unless <condition>
where
<location> could be
a method name and an optional line number or bytecode offset or
a file name and a line number
and <condition> is some sort Ruby expression.
So in sum, there is no technical reason why this can't happen; and it has
been in the road map. It's just SMOP -- small matter of programming.
On Sun, Feb 20, 2011 at 3:26 PM, Chuck Remes <[email protected]> wrote:
> On Feb 19, 2011, at 10:34 PM, Rocky Bernstein wrote:
>
>
>
> On Sat, Feb 19, 2011 at 10:03 PM, Chuck Remes <[email protected]>wrote:
>
>> 3. Add in the heap_dump (evanphx/heap_dump) functionality directly into
>> rbx console (or make it a plug-in or something). It would be great to be
>> able to write a command similar to this:
>>
>> console> heap.diff(Time.now, Time.now + 60)
>>
>> or
>>
>> console> now_anchor = Time.now
>> console> 5.times do
>> console> sleep 60
>> console> heap.diff(now_anchor, Time.now)
>> console> end
>>
>> to do heap diffs right in the console.
>>
>> 4. Extend the debugger so we can set breakpoint on stdlib or rbx internal
>> Ruby code that is *called by* a C extension.
>>
>
> I wasn't aware this wasn't possible. Can you come up with the simplest test
> case to try?
>
>
> Upon re-reading, I see that #4 is unclear. I *did* write it at midnight
> with a few whiskies in my system, so that's my excuse.
>
> Allow me to clarify.
>
> 4. Extend the debugger so that we can set conditional breakpoints on stdlib
> or internal Rubinius Ruby code. This would be useful for breaking on
> Array#insert when it is called from a C extension but *not break* there when
> called by other code. A small example may help illustrate.
>
> debug> break Array#insert if call_stack.include?("some function from a C
> extension")
>
> This example would *only* break on #insert when it's called from a C
> extension, but other calls from normal Ruby code would not trigger the
> break.
>
> I hope that is clearer. If not, perhaps I can try again (or the idea is
> half-baked to begin with).
>
The idea is not half-baked.
>
> cr
>
>
> --
> --- !ruby/object:MailingList
> name: rubinius-dev
> view: http://groups.google.com/group/rubinius-dev?hl=en
> post: [email protected]
> unsubscribe: [email protected]
>
--
--- !ruby/object:MailingList
name: rubinius-dev
view: http://groups.google.com/group/rubinius-dev?hl=en
post: [email protected]
unsubscribe: [email protected]
