[ruby-core:84647] [Ruby trunk Feature#14276] Ruby core debugger API

Issue #14276 has been updated by deivid (David Rodr鱈guez).


Hi! So there are two different proposals here. Regarding the first one:

> Defining core Debug API namespace where we would create the minimal interface for ruby core debug functionality (Not sure if only cruby or a broader API adopted and designed in collaboration with the other ruby implementations).

It's already there! A bit of context:

* MRI 1.8 debugger, called `ruby-debug`, needed to hack into core sources extensively, and that caused the debugger to be broken in MRI 1.9.

* As a result, a fork called `debugger` was reworked to hack again into MRI 1.9 sources, and brought debugging support for MRI 1.9.

* `ruby-core` realized that this was an undesirable situation and implemented the TracePoint and the Debug Inspector APIs for debuggers (and other tools) to use. They were released with MRI 2.0 and, of course, broke `debugger`.

* `byebug` was then born using these APIs and the situation has been quite stable since. Initial MRI releases (2.0, 2.1, 2.2) surfaced several bugs in the APIs that were gradually fixed and backported. As of 2.3.0 there were no more outstanding bugs in the APIs that I know of.

* It is true that MRI 2.5.0 caused some breakage in `byebug` but it was nothing like the old times where the debugger wouldn't even compile. In this case, only a specific method calculating the potential breakpoint locations needed to [be patched](https://github.com/deivid-rodriguez/byebug/pull/397/files). There was also some intentional changes in the APIs done for performance reasons.

So, I'd say we're fine since ruby has had a stable debugger for 5 major releases now. :)

----------------------------------------
Feature #14276: Ruby core debugger API
https://bugs.ruby-lang.org/issues/14276#change-69223

* Author: dsferreira (Daniel Ferreira)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
I would like to propose the creation of a ruby core minimal API for a Debugger.

Historically we have been relying on gems as providers of debug functionality.
This has caused problems with debugger APIs being broken and the debugger gems being outdated by ruby releases.
This happened in the transitions from 1.8.* to 1.9.* and 1.9.* to 2.**

Currently ruby community relies mostly on *byebug* gem (+ pry) for debugging purposes.

Recently a new bug [14226](https://bugs.ruby-lang.org/issues/14226) was raised due to changes in ruby internals that broke *byebug*.

I consider that the debugger should be a core part of a language like ruby.
Developing production code without an available debugger is not very manageable.

For this reason I believe we should have a way of guaranteeing that each ruby release will not break the debugger.

Also having full control of the debugger API is very convenient for future purposes.
This way third party entities can rely on it to develop productivity tools.

I see two ways we can accomplish this:

- Defining core Debug API namespace where we would create the minimal interface for ruby core debug functionality (Not sure if only cruby or a broader API adopted and designed in collaboration with the other ruby implementations).
- Creating debug gem in standard lib with the same purpose. Having the guarantee that the unit tests will run for every ruby release.

The main goal in my mind would be to have a bare minimum (TDD?) development environment available upon ruby installation
with each bare minimum API providing the base functionality to allow the development of full fledged solutions capable of rivaling with the best solutions in the market.
For that goal I would include here for consideration the same approach for other functionalities such as:
* Coverage
* Documentation
* Benchmarks
* Tests
* Performance
* Linter
* ?

I believe we have currently a good situation with regards to:
- Documentation (Rdoc)
- Tests (Minitest)

Why not try to replicate those examples for the remaining areas?
Are documentation and tests so much different from the rest?

If we succeeded to do that we could present ruby to the new comer with a simpler development environment easing the entry level.
We could put simple documentation in ruby-lang.org to show how to achieve a professional development workflow with ruby with no fuss.

A full TDD environment available upon installation it is a great marketing headline in my perspective.

Just to finalise.
The goal here is not to have ruby core replacing the existing gems.
The goal is to give a clear path for these gems while allowing others to develop even further in top of a sound base
without worries regarding future support on the APIs being used.





-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>