Summarized using AI

Demystifying Ruby Debuggers: A Deep Dive into Internals

Dmitry Pogrebnoy • April 17, 2025 • Matsuyama, Ehime, Japan • Talk

In a presentation at RubyKaigi 2025, Dmitry Pogrebnoy explores the intricacies of Ruby debuggers, emphasizing their importance in modern development workflows, particularly as AI-generated code becomes more prevalent. The session is structured around five key queries covering the tools available for bug detection, the underlying technologies that drive Ruby debuggers, their internal workings, performance comparisons among them, and the unique features of the RubyMine debugger that enhance productivity.

Key Points Discussed:
- Importance of Debuggers: Debuggers are vital for Ruby developers, as they are used in approximately one in three runs, indicating their integration into the development cycle. The presentation begins with a simple bug example showing the necessity for effective debugging tools.
- Tools for Debugging: Dmitry examines traditional methods such as puts statements, advanced interactive consoles (like Pry), and the capabilities of Ruby's built-in debugger features that allow for deeper introspection and control when diagnosing issues.
- Core Technologies: The presentation highlights two fundamental technologies: TracePoint, which allows for executing code on specific runtime events, and Instruction Sequence, which offers insight into the lower-level compiled bytecode of Ruby methods.
- Internal workings of Debuggers: Different debuggers are analyzed, with Pybug being introduced first. Although it has comprehensive features, it struggles with performance issues due to the need for constant break point checks. The Debug gem, available in Ruby 2.6+ versions, overcomes these issues with enhanced trace point targeting, effectively streamlining performance.
- RubyMine Debugger: RubyMine is highlighted for its user-friendly design, allowing for one-click debugging of Rails applications while supporting multiple Ruby versions. It emphasizes productivity with features like smart stepping for method navigation and inline value hints that reduce cognitive load during debugging.

Conclusion:
The talk concludes with a comparison indicating that both RubyMine Debugger and Debug gem provide efficient debugging experiences, particularly in modern Ruby environments. Dmitry encourages developers to leverage RubyMine's user-friendly tools for a more productive debugging experience, underscoring the contemporary importance of mastering these debugging tools.

Demystifying Ruby Debuggers: A Deep Dive into Internals
Dmitry Pogrebnoy • Matsuyama, Ehime, Japan • Talk

Date: April 17, 2025
Published: May 27, 2025
Announced: unknown

RubyKaigi 2025

00:00:08.639 hello hello hello thank you for coming
00:00:12.559 my name is Mitrioi I'm a team leader of
00:00:15.599 rub mine team in thread brains and today
00:00:18.960 I will talk about ruby
00:00:20.840 debuggers so we use ruby debuggers quite
00:00:23.680 a lot in our daily working process and
00:00:26.160 we will use them even more because of
00:00:28.080 the code generated by AI I right so with
00:00:31.599 this pressure we need to know our tools
00:00:33.600 even better to stay
00:00:35.399 productive and in this talk I will cover
00:00:38.160 open source Ruby debuggers as well as
00:00:40.239 puby mind debugger I've been working on
00:00:42.879 rub mind debugger for several years and
00:00:45.360 today it's a chance for me to share my
00:00:47.200 experience and show you main concept of
00:00:49.520 ruby
00:00:50.520 debuggers so let's start uh in this talk
00:00:54.879 I will cover five questions first we
00:00:58.000 will take a look on the tools that we
00:00:59.680 have to find bugs in Ruby code after
00:01:03.640 that we will see what technologies power
00:01:06.640 Ruby
00:01:07.960 debuggers then I will show you how do
00:01:10.320 Ruby debuggers work
00:01:12.119 internally and at the next step we will
00:01:14.720 see which debugger is the most
00:01:17.479 performant and at the last part I will
00:01:21.119 take a chance to sh to show you three
00:01:23.280 main uh features of Ruby mind debugger
00:01:26.080 that will help you work more
00:01:27.600 productively
00:01:29.439 so let's start from the first question
00:01:31.680 and let's see what tools do we have to
00:01:34.880 find bugs in Ruby code and let's start
00:01:38.240 with a simple example so here we have a
00:01:40.799 method process that takes one argument
00:01:44.000 inside this method we check whether an
00:01:46.079 argument has two string or inspect
00:01:48.320 methods and if it's true then we print
00:01:50.960 element is printable otherwise we print
00:01:53.439 element is not
00:01:55.000 printable and here in the example we
00:01:57.600 have two calls at the bottom uh the
00:01:59.840 first call process of five prints
00:02:01.840 element is printable as it should but
00:02:04.880 the second call looks pretty suspicious
00:02:08.399 it prints element is printable but basic
00:02:11.680 object doesn't have to string or inspect
00:02:13.599 methods at
00:02:14.760 all and yep apparently there is a bug
00:02:18.560 here in this code
00:02:20.640 so let's think for a second and please
00:02:23.440 raise your hand if you know where the
00:02:25.120 problem
00:02:26.520 is don't worry I will not ask you about
00:02:28.879 that i will write answer on the next
00:02:31.239 slide if you know where the problem is
00:02:33.760 raise your
00:02:35.080 hand yep yep great so the real problem
00:02:39.840 is here this part goes as an argument to
00:02:43.840 the defined method and in this way our
00:02:46.879 method process print element is
00:02:48.879 printable regardless of the argument
00:02:51.120 even with
00:02:52.599 Neil yeah this is a problem we can fix
00:02:55.200 it just by adding a couple of
00:02:57.360 parentheses for the first for the first
00:02:59.680 part of the if condition and after that
00:03:02.800 our output will be correct
00:03:06.400 this is a pretty simple example right
00:03:09.040 with almost obvious
00:03:11.000 bug but what tools could we have could
00:03:15.200 be used to find real bugs in real Ruby
00:03:18.440 code and the first thing that comes in
00:03:21.280 mind is put statement right so we can
00:03:24.400 place several put statements here and
00:03:26.400 there in our code and they will give us
00:03:28.400 some hints about where the problem is or
00:03:30.799 what we need to do next to investigate
00:03:32.560 our problem
00:03:33.959 further at the same time we could use
00:03:36.560 puts debugger gem that makes our output
00:03:39.440 more distinguishable between each other
00:03:42.640 and also we could use awesome gem
00:03:44.720 awesome print gem that makes our output
00:03:48.080 more structured and easy to
00:03:50.840 read generally put statements are really
00:03:54.000 helpful but they're too basic and for
00:03:56.720 something more advanced uh we need a
00:03:58.720 more complicated uh tool and we have
00:04:01.920 this tool we have interactive
00:04:04.280 consoles uh in Ruby we have mainly Ruby
00:04:07.760 and Pry consoles as you know uh we still
00:04:10.640 need to modify our source code to make
00:04:12.480 them work uh we need to place a call to
00:04:14.799 a certain place in our code and here
00:04:18.239 this tool is more advanced test than
00:04:21.359 puts debugger and put statements but
00:04:24.479 they still lack of one important feature
00:04:26.560 the lack of execution control and the
00:04:28.639 lack of
00:04:29.800 stepping and the next
00:04:32.040 tool Ruby debugger has all necessary
00:04:35.680 features uh like stepping break points
00:04:39.199 context and frame introspection
00:04:41.120 everything we need and this tool is the
00:04:43.360 most advanced tool in Ruby ecosystem for
00:04:45.600 investigating bugs in Ruby
00:04:47.880 code but before we start with debuggers
00:04:50.720 let's ask
00:04:52.120 ourself how often do Ruby developers use
00:04:55.280 a
00:04:57.080 debugger and the answer is here on the
00:04:59.919 slide so every third run is a debug run
00:05:03.840 according our stats in Ruby mine it
00:05:07.120 means that pub debuggers at the crucial
00:05:09.919 part of our development processes and
00:05:12.560 that's why I'm here that's why I'm
00:05:14.080 talking about Ruby debuggers if we
00:05:16.560 become more productive with debuggers
00:05:18.400 then we become more productive in our
00:05:20.160 work every day
00:05:23.240 so let's move to the next step and let's
00:05:26.320 see what technologies power Ruby
00:05:29.479 debuggers the first technology is trace
00:05:32.840 point it was introduced long time ago in
00:05:35.759 2y 2.0 and it mainly provides an ability
00:05:38.639 to execute some specific code on a
00:05:40.800 certain event in your code at the
00:05:43.479 runtime it works almost everywhere it
00:05:46.479 works in threads it works in fibers but
00:05:49.199 it doesn't work in recctor yet
00:05:52.600 unfortunately and let me show you an
00:05:54.639 example how does it work so here we have
00:05:57.600 a method say hello and we have a trace
00:06:00.720 point targeted to call events at the
00:06:04.000 bottom we have a call of our method and
00:06:06.240 we have our output in comments so as you
00:06:09.039 can see first we have a message from the
00:06:10.800 trace point and only after that we have
00:06:13.120 a message from the method
00:06:16.039 itself having only trace point we can
00:06:19.199 even create probably the simplest
00:06:21.680 possible debugger in Ruby and this part
00:06:25.440 is the main difference from the previous
00:06:28.199 example so in this part we take an input
00:06:30.960 from the user and we try to evaluate it
00:06:33.520 and we print the results to the
00:06:36.440 console in this way we will be able to
00:06:38.880 introspect the context on each call
00:06:41.680 event it means that we will be able to
00:06:44.960 uh
00:06:45.720 debug like essentially every method
00:06:49.960 invocation and that's looks so simple
00:06:52.960 right so it's impossible to make it uh
00:06:55.280 that simple without trace point and
00:06:57.600 that's why trace point is a crucial
00:06:59.280 scene for any Ruby
00:07:01.720 debugger the next technology is proy
00:07:05.120 virtual machine instruction
00:07:07.720 sequence instruction sequence in short A
00:07:11.360 sec is essentially a representation of
00:07:14.080 compiled by code for Ruby virtual
00:07:16.199 machine it's tightly coupled to Ruby
00:07:18.639 version uh virtual machine and that's
00:07:21.680 why it depends on the Ruby
00:07:23.720 version uh and this technology mainly
00:07:28.560 provides an access to low-level
00:07:31.039 representation of your Ruby code so with
00:07:34.240 this technology you can modify your bite
00:07:36.479 code without touching the source code
00:07:38.720 and that way you can adjust behavior you
00:07:40.720 can increase performance of your
00:07:42.160 application and other opportunities
00:07:46.120 here and let me show you an example how
00:07:49.039 we can get instruction sequence of the
00:07:51.120 method in Ruby
00:07:52.840 code so here we have the same method say
00:07:55.840 hello with put statement and then we
00:07:58.560 take a method object from this method
00:08:01.440 and we pass that method object to
00:08:03.039 instruction sequence method at the end
00:08:05.919 we just call this method just to get
00:08:08.240 human readable representation of
00:08:10.000 instruction sequence and let's take a
00:08:13.440 look at the result
00:08:15.479 right
00:08:17.560 so here what we have we have several
00:08:20.400 lines several instructions and they're
00:08:23.039 pretty readable we can even read uh our
00:08:26.479 argument for our puts statement it's
00:08:29.120 hello Rubik 2025 that's great and there
00:08:33.279 is another one thing here uh these marks
00:08:37.120 uh these marks represent events that
00:08:38.959 will be emitted at the runtime at the
00:08:41.039 certain instruction and this is a way
00:08:43.760 how instruction sequence collaborates
00:08:45.680 with trace point trace point targets to
00:08:48.800 these uh events at the runtime and
00:08:51.440 that's how they work
00:08:54.200 together so that's it about technologies
00:08:57.600 we have trace point and instruction
00:09:01.000 sequence and next let's take a look at
00:09:03.839 how Ruby debuggers
00:09:05.959 work and I would like to start with
00:09:08.320 pybug debugger it's well-known debugger
00:09:11.279 it has all necessary features break
00:09:13.440 points stepping context introspection
00:09:15.839 everything that we need it default
00:09:18.160 debugger for old Ruby and old trails
00:09:20.240 versions u it still requires
00:09:22.800 modification to our source code to make
00:09:25.760 it work usually we need to also place a
00:09:28.720 call somewhere or configure our project
00:09:30.800 to make it work and by default there is
00:09:33.839 a command line interface for this tool
00:09:36.480 but you can fight a bit and configure VS
00:09:38.959 code plug-in to work with graphical user
00:09:42.839 interface this is the main highlights
00:09:45.680 but how does work
00:09:49.080 right and this is a simple model of bbug
00:09:53.120 debugger so all this code should be
00:09:55.279 invoked before the code that we are
00:09:58.160 going to
00:09:59.000 debug and at the top place we have two
00:10:02.240 lists list of break points and list of
00:10:04.320 trace points in the list of trace points
00:10:06.959 we have a trace point per per each event
00:10:09.680 type so one trace point for call event
00:10:12.160 one trace point for return event and so
00:10:15.079 on and each trace point our sensor is
00:10:18.640 the same they have the same body the
00:10:20.720 same code in each trace point we try to
00:10:23.519 find a break point at the certain place
00:10:25.920 where we are and if we find it then we
00:10:28.959 pass our control to the user otherwise
00:10:31.519 we just continue our execution without
00:10:33.760 any additional steps till the next
00:10:37.640 event this approach works it works
00:10:40.320 reliably it allow us to debug our code
00:10:43.279 but there is one issue so we do a lot of
00:10:46.880 unnecessary checks on the each event to
00:10:49.440 find our break points at the runtime and
00:10:52.320 that's the main problem because it leads
00:10:54.399 to performance
00:10:56.760 degradation and the next tool debug gem
00:11:00.880 overcome this performance issue but
00:11:02.880 before we start with debug gem uh let's
00:11:05.040 take a look at the main feature that
00:11:06.800 allows this debugger to overcome this
00:11:09.200 performance
00:11:10.440 issue and this feature is trace point
00:11:13.720 improvements respoint improvements were
00:11:16.079 introduced in Ruby 2.6 and it mainly
00:11:18.959 provides an ability to target our trace
00:11:21.839 point to a certain line or
00:11:24.680 even in that way we don't need to check
00:11:27.680 every event for a break point present uh
00:11:30.560 we can create a trace point and we can
00:11:33.519 target our trace point to a certain
00:11:35.519 place where we have a break point for
00:11:38.600 sure in this way we don't need to do any
00:11:41.519 unnecessary work and it's why it works
00:11:44.560 fast without any performance
00:11:47.480 overhead let me show you an example how
00:11:49.760 does it work just to illustrate this
00:11:51.760 feature and here we have two methods say
00:11:54.800 hello and say goodbye we have the same
00:11:56.880 trace point as before targeted to call
00:11:59.480 events and the difference is here so we
00:12:02.959 target our trace point
00:12:04.760 to the is of the first method and at the
00:12:08.639 bottom we can see that our trace point
00:12:10.399 was triggered only once for this first
00:12:12.480 method and was ignored for the second
00:12:14.519 one that's the main
00:12:18.040 feature well debug gem uses this
00:12:21.200 approach to overcome performance issue
00:12:23.839 and in fact this debugger doesn't have
00:12:25.920 any performance degradation and that's a
00:12:28.720 great achievement over by bug debugger
00:12:32.959 also this tool supports Ruby starting
00:12:35.360 from 2.7 and greater and it's mainly
00:12:38.320 because the fact that trace point
00:12:40.480 improvement wasn't ported to the
00:12:42.399 previous versions um so only modern Ruby
00:12:45.959 supported apart of that uh there is
00:12:50.160 there are several uh front ends for this
00:12:52.160 debugger you can use uh VS code you can
00:12:55.279 use Chrome so a couple options here and
00:12:59.360 the main scene that this debugger is
00:13:01.279 bundled in Ruby starting from
00:13:03.959 3.1 and that means that this is a
00:13:06.399 default option for debugging your code
00:13:09.120 uh in the modern Ruby especially if you
00:13:11.519 don't have any other tool like Ruby mind
00:13:14.920 debugger and that's it about open source
00:13:17.920 uh Ruby debuggers and let's take a look
00:13:20.720 what Ruby mind debugger could
00:13:23.639 offer first uh This debugger is bundled
00:13:26.959 in Ruby mine uh by default with
00:13:29.040 graphical user interface tailored for
00:13:31.040 developers productivity this debugger
00:13:33.760 provides seamless debugging experience
00:13:35.760 uh for example there is a feature that
00:13:37.680 you can launch this debugger without any
00:13:40.240 prior configuration just in one click
00:13:42.959 the ID that's great apart of that uh
00:13:47.040 this tool supports Ruby starting from
00:13:49.120 2.3 and greater so almost all possible
00:13:52.480 Ruby that your application could use are
00:13:55.240 supported and with all these supported
00:13:57.760 Ruby versions uh this debugger works
00:14:00.160 fast so it works fast even with old
00:14:03.720 Ruby and last touch here is that there
00:14:07.519 is an ability to attach this tool to any
00:14:09.680 Ruby process so you don't need to start
00:14:12.079 and launch a debugger right from the
00:14:13.760 start you can attach this tool to
00:14:16.320 already existing process when you really
00:14:18.639 need it to debug
00:14:21.920 that's the main highlights and yeah what
00:14:25.199 is like how is mind debugger
00:14:28.760 structured and this is a general
00:14:31.360 architecture of ruby mind debugger it
00:14:33.920 contains three
00:14:35.720 components so the first part is debugger
00:14:38.959 back end essentially it's the base gem
00:14:42.959 it's responsible for low-level scenes
00:14:45.360 like uh context and frame retrieving
00:14:48.560 manipulating with ISX and trace points
00:14:51.120 and that's mainly a C
00:14:53.880 extension then we have another component
00:14:56.720 debugger front end uh Ruby debug ID gem
00:15:01.760 this component is responsible for
00:15:03.440 connection between Ruby mine id and
00:15:05.440 debugger itself and for text
00:15:08.480 representation of Ruby values that will
00:15:10.639 be presented later in the Ruby mine uh
00:15:15.160 ID and the last part uh program ID
00:15:18.959 itself
00:15:20.440 uh this component is mainly about user
00:15:24.079 interface and developers productivity so
00:15:26.560 almost all fancy features targeted to
00:15:28.880 developers productivity located there
00:15:31.600 and that's how it works in
00:15:34.120 general so this is a general
00:15:36.399 architecture uh but the real
00:15:39.279 architecture looks a bit more
00:15:41.279 complicated
00:15:43.040 so instead of one branch of gems we have
00:15:45.920 two branches two
00:15:48.720 uh the first branch is targeted to call
00:15:51.360 uh to old Ruby and it uses old Ruby API
00:15:55.759 it contains several low-level hacks that
00:15:58.639 uh helps us achieve desired performance
00:16:01.519 and it's really hard to maintain and add
00:16:03.440 new features because of these
00:16:05.399 hacks so we decided to create another
00:16:08.720 branch for modern Ruby it uses modern
00:16:12.000 Ruby API it doesn't have any major hacks
00:16:16.160 behind and uh in that way we are able to
00:16:20.399 maintain and manage our debugger
00:16:25.560 easily so this it about debuggers
00:16:29.399 perform internals and let's figure out
00:16:33.440 which debugger is the most performant
00:16:37.120 to find this out I created a simple
00:16:41.079 experiment we have Fibonacci method with
00:16:44.160 a meaningless break point that we never
00:16:46.759 hit and we need a minimal breakpoint
00:16:49.600 just to measure how a break point could
00:16:51.920 affect our debugger
00:16:54.440 performance also in this experiment I
00:16:57.759 used 100 runs just to get our results
00:17:00.480 stable and reliable
00:17:02.959 and apart of that I used all latest
00:17:06.400 versions of Ruby debuggers available on
00:17:08.880 the date so we have two groups for old
00:17:12.160 Ruby and for modern Ruby and as you can
00:17:14.799 see remain debugger presents in both of
00:17:17.199 them but with different sets of uh gem
00:17:21.959 versions and yeah let's take a look at
00:17:24.319 the
00:17:27.079 results here they are first I would like
00:17:30.640 to highlight that by bug debugger works
00:17:33.120 slow it more than 20 25 times slower
00:17:36.960 than original run without any
00:17:40.440 debugger and at the same old Ruby Ruby
00:17:43.520 mind debugger works fast without any
00:17:45.520 visible performance issue and that means
00:17:48.720 that for the old Ruby we have only one
00:17:51.440 option to debug our code without
00:17:54.200 debugger with decradation
00:17:57.440 that's not really great because we have
00:17:59.039 only one option for that but we have a
00:18:02.080 better case for the modern Ruby in
00:18:04.720 modern Ruby we have debug gem and ruby
00:18:06.960 mind debugger they are both uh work fast
00:18:09.840 uh without any performance issue and in
00:18:12.559 modern Ruby we can choose uh what we
00:18:15.200 need to use for each particular
00:18:18.200 case so now we know that debug gem and
00:18:21.760 man debugger works fast and let's move
00:18:24.720 to the last part and let me show you
00:18:27.840 three unique features of Ruby mind
00:18:29.600 debugger that will help you work more
00:18:32.679 productively the first feature is debug
00:18:35.760 rails application in one
00:18:38.280 click suppose we have a rails
00:18:40.640 application it's really regular rails
00:18:43.200 application based on Puma server and
00:18:45.679 here on the screen we have a config file
00:18:49.120 for our Puma server um as you can see we
00:18:52.799 have uh five workers and
00:18:56.200 uh two threads right uh so in that way
00:19:00.840 we deal with multi- thread multiprocess
00:19:04.000 rails application and suppose we need to
00:19:06.799 debug this application uh suppose we we
00:19:09.440 need to debug our method home in our
00:19:11.440 controller pretty usual scene and first
00:19:15.840 step we need to do is to add a break
00:19:18.000 point by one click on the gutter here it
00:19:21.880 is and on after that all we need to
00:19:25.120 start our debugger is just one click on
00:19:27.600 the debug button in the IDE and that's
00:19:30.919 it after that debugger will start and we
00:19:34.160 will be able to hit our break point uh
00:19:36.720 and see this view so here we have list
00:19:40.000 of frames panel with variables and
00:19:42.240 values controls uh for navigation during
00:19:45.280 the debugging process execution console
00:19:47.919 and other
00:19:49.080 things and the feature is that we are
00:19:51.520 able to launch our debugger without any
00:19:54.480 prior configuration without dealing with
00:19:57.039 commands in terminal without modifying
00:19:59.600 our source code just in one click it
00:20:03.120 works out of the out of the box without
00:20:05.360 any prior configuration and it saves
00:20:07.440 your time on
00:20:10.200 that another feature is smart
00:20:13.960 stepping so suppose we have this example
00:20:17.360 this code we have a class my printer
00:20:19.760 with several printing methods and we
00:20:22.400 have a chain of calls at the
00:20:24.440 bottom so let's say we need to debug
00:20:26.880 this chain of calls uh so we put a break
00:20:29.600 point on this line uh we started our
00:20:32.000 debugger we stopped on this line and
00:20:34.159 here we are we need to debug uh this
00:20:36.799 line
00:20:38.400 so how we do it in Ruby
00:20:40.360 Mine ruby Mine debugger provides several
00:20:43.360 convenient actions for navigation during
00:20:45.679 the debugging process they called step
00:20:47.840 into step out and step
00:20:50.200 over and let's hear them so first let's
00:20:54.159 call step and remind provides us several
00:20:57.360 options where we can actually step into
00:21:00.880 and let's choose that second option and
00:21:02.960 let and let's step into our first method
00:21:05.440 in the class here we are uh then suppose
00:21:09.919 we investigated something here and we
00:21:13.039 would like to get back to our initial
00:21:15.679 line where we were at the beginning and
00:21:19.039 for that purpose uh yeah for that
00:21:21.280 purpose we can call uh step
00:21:24.039 out and here we are on the same on the
00:21:27.919 exactly the same line that's impossible
00:21:30.240 to achieve uh the same behavior with
00:21:32.400 chain of calls with other
00:21:34.360 debuggers after that we can uh repeat
00:21:37.440 our actions we can call step into
00:21:40.840 and now we have two options here let's
00:21:44.720 choose the first one and let's step into
00:21:46.720 our second method in the class
00:21:49.600 um suppose uh at that point we need to
00:21:53.039 uh investigate something in this method
00:21:55.679 uh in more details and we need to step
00:21:58.480 inside this method without going outside
00:22:00.799 and without going deeper in the calls uh
00:22:04.400 so for that purpose we can call step
00:22:06.400 over and in this way we can step into
00:22:08.880 inside the
00:22:10.760 method so last step is just to call step
00:22:14.320 out and get back to our initial line
00:22:17.360 where we were at the
00:22:19.000 beginning and that's how it works it
00:22:21.520 works reliably in simple cases it works
00:22:24.240 in complicated cases like chain of calls
00:22:27.200 and it saves your time on the navigation
00:22:29.039 during the debugging
00:22:32.039 process so and the last uh feature that
00:22:35.360 I would like to show you
00:22:36.919 today is inline debugger values
00:22:41.520 so suppose we need we have this example
00:22:44.240 this code we have a method uh filter
00:22:48.080 array that filters array in some way
00:22:50.720 doesn't matter right now and suppose we
00:22:53.520 need to debug this method we have a
00:22:55.280 break point on the line four and uh we
00:22:58.960 launch our debugger we stopped on this
00:23:01.039 line and here we
00:23:03.240 are in this view we have panel with
00:23:06.159 variables and values and usually during
00:23:09.600 the debugging process
00:23:11.200 We need to match variables in the editor
00:23:14.159 with values in this panel so we need to
00:23:17.120 go back and forth to make this kind of
00:23:19.280 map in our mind and it takes a lot of
00:23:22.240 resources to keep it
00:23:24.440 consistent and yeah that's not really
00:23:26.720 efficient way ruby mind provides a
00:23:29.679 better solution it provides these inline
00:23:32.559 hints right in the editor they show you
00:23:35.840 variables and values uh near the place
00:23:38.240 where variables are right in the editor
00:23:41.280 with this feature you don't need to go
00:23:42.720 back and forth you can see it right on
00:23:44.799 the place and it saves your mind
00:23:49.240 resources that's it about features that
00:23:52.320 I have today and let's
00:23:55.159 recap so first we discussed that uh
00:23:58.480 puberty debuggers mainly use trace point
00:24:01.039 and instruction sequence there are two
00:24:03.120 core technologies for any Ruby
00:24:06.120 debugger then we discussed that debug
00:24:08.720 gem works fast due to thoint
00:24:10.799 improvements and that's a great
00:24:12.400 achievement over play by bback
00:24:14.919 debugger and the last scene about ruby
00:24:17.679 mind debugger it works fast with all
00:24:20.400 supported Ruby versions it provides it
00:24:24.159 provides oneclick debugging experience
00:24:26.320 for rails application that saves your
00:24:28.240 time on the configuration
00:24:31.679 it streamlines the bugging experience
00:24:33.200 with smart stepping and helps you save
00:24:35.440 your time on the navigation during the
00:24:37.360 debugging process and the last thing
00:24:39.919 that uh it provides inline debugger
00:24:42.159 values that helps you debug with
00:24:44.080 pleasure and save your mind
00:24:47.000 resources so that's it uh please take
00:24:50.640 your phones and scan your square code to
00:24:52.799 try and remind debugger for free share
00:24:56.480 your feedback with me on LinkedIn and
00:24:58.640 also we have a boost on this conference
00:25:00.720 so contrast to talk about Ruby Rails and
00:25:04.799 Ruby min that's it thank you
Explore all talks recorded at RubyKaigi 2025
+66