debug VS ruby

I've written Ruby for coming up on 20 years, so to be honest I haven't paid attention to what is written on that subject in recent years.

Bundler shouldn't be running inside a trap context, but you might be running into a situation where standard input/output from the actual process triggering your breakpoint has been redirected. In that case, ruby-debug[1] is a good option, as you attach to it from outside[2]. Basically, run "rdbg --open yourscript.rb" and then use rdbg -A from another terminal.

You use Pry remotely too[3] if you prefer.

[1] https://github.com/ruby/debug

[2] https://github.com/ruby/debug?tab=readme-ov-file#remote-debu...

[3] https://github.com/Mon-Ouie/pry-remote

what is ruby debug not able to do that you want it to do?

https://github.com/ruby/debug

a nice ide integrated experience:

https://code.visualstudio.com/docs/languages/ruby#_debugging...

https://github.com/ruby/vscode-rdbg

https://code.visualstudio.com/docs/editor/debugging

Execution is paused at the breakpoint (which has a little arrow pointing at it). You can then enter commands to the rdbg prompt to control the debugger. For a list of the different commands you can use, visit the documentation for the debug gem.

In 2017, I wrote a toy language called Goby[1] to learn how Ruby works. A few folks contributed quite a bit to it and one of them later referred me to my previous job (as a backend developer).

Fast-forward to 2021, I got interested in debugging tools so I started contributing to the then newly created Ruby debugger[2]. In less than a year I opened more than a hundred PRs and became the 2nd biggest contributor of it. And that eventually landed me a job to work on Ruby's development tools, like LSP servers, REPLs, and of course, the debugger :-)

[1] https://github.com/goby-lang/goby

[2] https://github.com/ruby/debug

Fun fact, Ruby as a single-threaded language is how most people experience it, but Ruby has a rich cooperative multitasking called Fibers that hopefully is getting more exposure, in amongst a bevy of competing implementations and other also-ran concurrency primitives (besides the usual contenders like Threads, Process fork, foreman that just runs several processes alongside one another...)

https://github.com/ruby/debug/issues/486#issuecomment-157531...

If you want to use debugging and multi-threaded or multi-fiber Ruby at once, you can! You just have to get a bit creative. I always refer back to this thread on the Ruby `debug` gem (though the advice applies to any other REPL you can use) about applying a Mutex. You can use the built-in Fiber.blocking to prevent other fibers from running at the same time as yours, or you can use a Mutex to just ensure that you don't hit the debugger multiple times in the same process IO that would mean you've got multiple REPLs all grappling for the StdIO at once.

For a long time Ruby dev who almost never did concurrency unless it was facilitated by the OS, or before being exposed to it directly in other languages like Go, the Ruby "super power" remains intact, it's just a bit more mysterious with the concurrency stuff added. Ruby has amazing diversity in its concurrency tools, which is a nice way of saying "the language authors decided not to pick a king concurrent runtime/winning gem whilst all of the competing implementations were all a bit nascent and un-fully-formed!"

I like the bruno/fiber-scheduler but it looks like it is not the winner. It should be easy to switch to another fibers implementation, I think async is the crown champion now, but I still haven't been motivated to switch - the fiber-scheduler that is named fiber-scheduler has been good enough for me, despite shortcomings!

Debuggers are powerful tools that allow you to step through your code line-by-line, inspecting variables and understanding the flow of execution. Using debuggers is a whole topic unto itself, and getting into the weeds with that would balloon the scope of this post. If you want more information on using them, I recommend reading the README for rdbg. This is the debugging solution for modern Ruby/Rails development. It's in Ruby's stdlib as of v3.1, and Rails 7+ apps include it in the Gemfile by default. I also recommend this section of the Rails guides for exploring how to use the debug gem with Rails applications.

Trace Inspector, a tool that displays Ruby trace logs with pretty UI while debugging in VS Code, has recently landed in debug.gem. debug.gem is a Ruby standard debugger library and the default debugger in Rails. Since debug.gem supports VS Code, you can debug Ruby programs in vscode-rdbg.

For newer versions of Rails (introduced in v7): Debug Gem

While pry is nice Ruby 2.6+ includes the debug gem in the standard library which avoids the need to install another dependency.

Have you tried ruby/debug's catch command? You can do catch Exception to achieve the same effect.

To create a new Rails app, you should have Ruby and Rails installed on your machine. You can find how to install Ruby on your local machine using the Ruby docs. You can install Rails by running the following command:

Ruby testing with RSpec

Not parent poster and do not have production YJIT experience. =)

My guess is that you would monitor `RubyVM::YJIT.runtime_stats[:code_region_size]` and/or `RubyVM::YJIT.runtime_stats[:code_gc_count]` so that you can get a feel for a reasonable value for your application, as well as know whether or not the "code GC" is running frequently.

https://github.com/ruby/ruby/blob/master/doc/yjit/yjit.md#pe...

Link to the commit

Part of the major userbase pull in GitHub revolves around hosting a considerable number of popular projects including Angular, React, Kubernetes, cpython, Ruby, tensorflow, and well even the software that powers this site Forem.

Hold option and click on the “collapse file” button in the Files view of a commit or pull request, and it will collapse all the files.

Select text in a comment, issue, or pull request description and press r—the selected text (including markdown formatting) will get pre-populated as a markdown block quote reply in the next comment box.

Add .patch or .diff to any pull request URL if you want to see a plain-text diff of the pull request (e.g. maybe you want to quickly `curl ... | git apply -` an unmerged pull request into a local copy of the repo without trying to add and fetch the git remote that the pull request is from).

There are lots of keyboard shortcuts. For example, / to jump to the file finder.

Not so much a secret but more like a hiding in plain sight: when looking at a commit GitHub will show you the earliest and latest tag (i.e. release) that includes the commit. For example, this commit[1] first appeared in v3_2_0_preview3.

[1]: https://github.com/ruby/ruby/commit/892f350a7db4d2cc99c5061d...

The title is misleading, just like other commenters mentioned. Just check how much indirection "rb_iv_get()" has to make (at the end, it will call [1], which isn't "a light" call). Now, check generated JIT code (in a blog post) for the same action where JIT knows how to shave off unnecessary indirection.

We are comparing apples and oranges here.

[1] https://github.com/ruby/ruby/blob/b635a66e957e4dd3fed83ef1d7...

I'm not sure why, but all the source values are listed here: https://github.com/ruby/ruby/blob/1cc700907d3ad3368272488a6f...

Maybe someone knowledgeable in the underpinnings of Ruby will explain why "class variable" was not hyphenated.