3 ms·

You'll note the article doesn't mention method_missing even once, and in general method_missing is rarely used much in modern Ruby meta programming, for good re

by vidarh 3y ago

You'll note the article doesn't mention method_missing even once, and in general method_missing is rarely used much in modern Ruby meta programming, for good reason. Overally I just don't get this difficulty people have debugging Ruby, and to me it feels like there's just some fundamental disconnect where people insist on working with Ruby as if it is statically typed, and then get confused when they find it hard, instead of embracing the dynamism and message passing nature of it. In Ruby I usually work with a "dev mode" in my code that makes it trivial to drop to a repl (there's also ruby-debug which allows dropping to a repl "anywhere" but since you then run in a trap context it limits what you can do) and optionally reload code, which means I can poke and prod at every aspect of the runtime system whenever and wherever there's a problem, and can often write a fix, load it into the running system and retry the basic block that triggered the error to see if it fixed it. My editor is written in Ruby, and if something breaks, I get thrown into a pry prompt and can fix it that way and continue. Or I can exit, because since every method call is a message, DrB lets me trivially forward it over a socket, and so the actual text buffers sits safely in a different process (and if that throws an exception, I can debug that too, via the same mechanism, from the client, while it is still running) It might well be Elixir would be the better choice for how you think - I'm not trying to convince you Ruby works better for you. But I think a lot of people would be a lot happier with their Ruby experience if they actually explored what a more dynamic system makes possible. If you don't take advantage, there's really no point - in that case you're paying a performance cost for no gain and would be better off sticking to a static language. (Regarding refinements, in the years since I've found exactly one use for it - enabling torturously invasive monkey patching that'd be entirely unacceptable system-wide, and keep that firmly confined to inside a DSL - but that use is very much worthwhile)

john-aj 3y ago
>My editor is written in Ruby Which editor is that?
- vidarh 3y ago
  My own. It's not in a suitable state for others at the moment - it makes assumptions about e.g. running in a tiling window manager with support scripts tuned for it, and a few other things specific to my environment. I intent to clean that up at some point, but it's just not been a priority.
weatherlight 3y ago
Sidenote, What editor is it that you use that's written in Ruby? I <3 Ruby and really do lean into its dynamic nature, (it's also one of the reasons I love Elixir as well.)
- Tomte 3y ago
  Probably this: https://github.com/vidarh/re https://github.com/vidarh/re
  - mswiss825 3y ago
    That would make sense, it does match his username
  - vidarh 3y ago
    It is, with the caveat that the public version is probably broken for everyone but me (various dependencies on other tools on my system that need to be weeded out), and extremely out of date (the newest commits from 9 months ago). I do keep intending to bring it up to date, but there are a lot of things in there I want to change before I start pushing the newer changes... I wouldn't recommend anyone try to make that version work at this point.
danmur 3y ago
I prefer editors that don't break personally, don't need another thing to fix while I'm fixing things
- danmur 3y ago
  I like the downvotes, it makes me feel loved :P.
- quesera 3y ago
  Vidar is the developer of an editor, which is labelled "experimental". 'snark'.tr('nr', 'lc')
  - vidarh 3y ago
    It is very much experimental, though at this point I've been using it nearly exclusively for 6-7 years, I think, and I'm very happy with that. The "problem" mainly that it works well enough for me, and I've had little incentive to make it work at all for anyone else.... Though now that it runs in my own terminal, I'm thinking of unifying some of the buffer handling for both the editor and terminal and splitting that out as a gem, and once I've done that and rewritten some of the (currently rather inefficient) rendering and syntax highlighting code (the syntax highlighting uses Rouge, which is fine, but I have a mountain of things on top that I'm slowly cleaning up so they're reusable and somewhat performant) it'll start to approach usable for others...
- vidarh 3y ago
  I prefer an editor that works how I want it, and so I use my own editor because I found I spend less time tweaking my editor that way than I do trying to bend an "off the shelf" editor to my will (I started writing it when I realised my emacs config was more lines than it should take to write an editor). Sometimes it breaks. That's fine - I can fix it trivially. But because it's my own, I also put up with things in it I wouldn't otherwise, because I know how to work around it. I also get a level of pleasure from gradually taking more and more control of my own tools that I'd never want to give up.
revscat 3y ago
Let me ask you something: is there a good source on how to debug in Ruby? I keep running into issues when I dive into it outside of Rails. For example, yesterday I ran into an issue with bundler where a gem was failing to install and needed to step through the process. I set a binding.b in the gem’s extconf.rb, but when that breakpoint got hit the program just stopped without allowing input, I.e. there was no debug prompt presented. Is bundler running inside a trap context similar to what you mention above?
- vidarh 3y ago
  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 - just kept up on the tools. 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 https://github.com/ruby/debug [2] https://github.com/ruby/debug?tab=readme-ov-file#remote-debugging https://github.com/ruby/debug?tab=readme-ov-file#remote-debu... [3] https://github.com/Mon-Ouie/pry-remote https://github.com/Mon-Ouie/pry-remote
  - vidarh 3y ago
    To expand on this separately, this is roughly my process for debugging Ruby: * Add a "reload!" method that will reload the code. * Add a repl.rb file that loads the main app and throws you in a suitably configured irb or pry console, with a "reload!" method that'll reload the files you're running in (remember, `require`'s are only loaded once, so this can get tricky for projects that require's lots of things - you can pick a gem to handle this for you, but frankly I tend to find that I usually work on a small set of code at a time, and so I usually prefer to adjust what I want to reload semi-manually). * Be set up to do remote debugging if your code takes over stdin/stdout, but try to ensure the majority of your code doesn't, so you can play with it from the debugger before you relinquish control at the top level. Or add a way to have your app temporarily surrender control. E.g. my editor will give up control of the terminal to pry when I press ctrl+x, ctrl+p, and once on the Pry prompt I can access the entire editor state via $editor. * Add some gems to make formatting data from your objects nicer, like e.g. by current side-project brings in sequel_pretty_print (because I use Sequel rather than ActiveRecord), awesome_print and hirb-unicode. * While it's nice to be able to run throwaway lines in the REPL, I tend to copy things into methods very quickly, so I build up an array of tests and helpers *based directly on what I've done in the REPL. Overall most of the "magic" will come from learning the full set of capabilities pry (and irb is finally starting to catch up) and ruby-debug provides you. My goal tends to be that I shouldn't need to exit the REPL very often while debugging, so I can e.g. keep old objects around and compare state before/after a change, and not have to worry about the complexity.
krainboltgreene 3y ago
> You'll note the article doesn't mention method_missing even once, That's because `method_missing` isn't the subject of the post. Are you also going to point out that the blog post doesn't mention Eigenclasses or Jim Weirch? > and in general method_missing is rarely used much in modern Ruby meta programming, for good reason. You're just extremely wrong. > I'm not trying to convince you Ruby works better for you I've been doing Ruby for 15 years, I don't think you could.
- vidarh 3y ago
  > You're just extremely wrong. I am not, but given the extremely combative attitude of your comment while you've not provided any actual arguments, it's clear you're not interested in actually discussing the subject, but rather getting out aggression, so take care - I won't waste my time on any further conversations with you.

by vidarh 3y ago

john-aj 3y ago

>My editor is written in Ruby Which editor is that?

vidarh 3y ago
My own. It's not in a suitable state for others at the moment - it makes assumptions about e.g. running in a tiling window manager with support scripts tuned for it, and a few other things specific to my environment. I intent to clean that up at some point, but it's just not been a priority.

weatherlight 3y ago

Sidenote, What editor is it that you use that's written in Ruby? I <3 Ruby and really do lean into its dynamic nature, (it's also one of the reasons I love Elixir as well.)

Tomte 3y ago
Probably this: https://github.com/vidarh/re https://github.com/vidarh/re
- mswiss825 3y ago
  That would make sense, it does match his username
- vidarh 3y ago
  It is, with the caveat that the public version is probably broken for everyone but me (various dependencies on other tools on my system that need to be weeded out), and extremely out of date (the newest commits from 9 months ago). I do keep intending to bring it up to date, but there are a lot of things in there I want to change before I start pushing the newer changes... I wouldn't recommend anyone try to make that version work at this point.

danmur 3y ago

I prefer editors that don't break personally, don't need another thing to fix while I'm fixing things

danmur 3y ago
I like the downvotes, it makes me feel loved :P.
quesera 3y ago
Vidar is the developer of an editor, which is labelled "experimental". 'snark'.tr('nr', 'lc')
- vidarh 3y ago
  It is very much experimental, though at this point I've been using it nearly exclusively for 6-7 years, I think, and I'm very happy with that. The "problem" mainly that it works well enough for me, and I've had little incentive to make it work at all for anyone else.... Though now that it runs in my own terminal, I'm thinking of unifying some of the buffer handling for both the editor and terminal and splitting that out as a gem, and once I've done that and rewritten some of the (currently rather inefficient) rendering and syntax highlighting code (the syntax highlighting uses Rouge, which is fine, but I have a mountain of things on top that I'm slowly cleaning up so they're reusable and somewhat performant) it'll start to approach usable for others...
vidarh 3y ago
I prefer an editor that works how I want it, and so I use my own editor because I found I spend less time tweaking my editor that way than I do trying to bend an "off the shelf" editor to my will (I started writing it when I realised my emacs config was more lines than it should take to write an editor). Sometimes it breaks. That's fine - I can fix it trivially. But because it's my own, I also put up with things in it I wouldn't otherwise, because I know how to work around it. I also get a level of pleasure from gradually taking more and more control of my own tools that I'd never want to give up.

revscat 3y ago

Let me ask you something: is there a good source on how to debug in Ruby? I keep running into issues when I dive into it outside of Rails. For example, yesterday I ran into an issue with bundler where a gem was failing to install and needed to step through the process. I set a binding.b in the gem’s extconf.rb, but when that breakpoint got hit the program just stopped without allowing input, I.e. there was no debug prompt presented. Is bundler running inside a trap context similar to what you mention above?

vidarh 3y ago
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 - just kept up on the tools. 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 https://github.com/ruby/debug [2] https://github.com/ruby/debug?tab=readme-ov-file#remote-debugging https://github.com/ruby/debug?tab=readme-ov-file#remote-debu... [3] https://github.com/Mon-Ouie/pry-remote https://github.com/Mon-Ouie/pry-remote
- vidarh 3y ago
  To expand on this separately, this is roughly my process for debugging Ruby: * Add a "reload!" method that will reload the code. * Add a repl.rb file that loads the main app and throws you in a suitably configured irb or pry console, with a "reload!" method that'll reload the files you're running in (remember, `require`'s are only loaded once, so this can get tricky for projects that require's lots of things - you can pick a gem to handle this for you, but frankly I tend to find that I usually work on a small set of code at a time, and so I usually prefer to adjust what I want to reload semi-manually). * Be set up to do remote debugging if your code takes over stdin/stdout, but try to ensure the majority of your code doesn't, so you can play with it from the debugger before you relinquish control at the top level. Or add a way to have your app temporarily surrender control. E.g. my editor will give up control of the terminal to pry when I press ctrl+x, ctrl+p, and once on the Pry prompt I can access the entire editor state via $editor. * Add some gems to make formatting data from your objects nicer, like e.g. by current side-project brings in sequel_pretty_print (because I use Sequel rather than ActiveRecord), awesome_print and hirb-unicode. * While it's nice to be able to run throwaway lines in the REPL, I tend to copy things into methods very quickly, so I build up an array of tests and helpers *based directly on what I've done in the REPL. Overall most of the "magic" will come from learning the full set of capabilities pry (and irb is finally starting to catch up) and ruby-debug provides you. My goal tends to be that I shouldn't need to exit the REPL very often while debugging, so I can e.g. keep old objects around and compare state before/after a change, and not have to worry about the complexity.

krainboltgreene 3y ago

> You'll note the article doesn't mention method_missing even once, That's because `method_missing` isn't the subject of the post. Are you also going to point out that the blog post doesn't mention Eigenclasses or Jim Weirch? > and in general method_missing is rarely used much in modern Ruby meta programming, for good reason. You're just extremely wrong. > I'm not trying to convince you Ruby works better for you I've been doing Ruby for 15 years, I don't think you could.

vidarh 3y ago
> You're just extremely wrong. I am not, but given the extremely combative attitude of your comment while you've not provided any actual arguments, it's clear you're not interested in actually discussing the subject, but rather getting out aggression, so take care - I won't waste my time on any further conversations with you.