Ruby not using all configuration keys? about dap-buddy.nvim HOT 19 CLOSED

Hi @brandoncc ! Your configuration is fine (small tip: you don't need to specify path to rdebug if you use useBundler). I've check and it works. And you are right! The configuration keys are filtered out. I've never noticed that, because I was passing configuration directly to nvim-dap.

@pocco81 I think this check is unnecessary: https://github.com/Pocco81/DAPInstall.nvim/blob/main/lua/dap-install/init.lua#L41

I don't see any reason why we shouldn't allow users to pass anything they want to dap configure. Actually, I would suggest replacing these iterations over settings keys with the tbl_extend for example.

And I'm still thinking about adding some more sample configurations or maybe a wiki page? There are like three different ways to setup dap to work with ruby code. For single scripts, rails and rspec.

Or maybe the rails one should be default?

from dap-buddy.nvim.

Interesting, I'll try that as well. I'll report back on both.

from dap-buddy.nvim.

No worries. However, I think I'll still add the ruby debugger anyways 👍. Thanks for trying! I appreciate that.

from dap-buddy.nvim.

I agree. :) I will just point one thing.

elseif (opt == "configurations") then
  if (dbg.config[opt][1][inner_opt] ~= nil) then -- not nil
    dbg.config[opt][1][inner_opt] = config[opt][1][inner_opt]
  end
else

So there is this condition: if (dbg.config[opt][1][inner_opt] ~= nil) which means that if the default config don't have this value defined then nothing will be assigned to it. Based on your message i think you wanted if (config[opt][1][inner_opt] ~= nil) and now it won't overwrite default settings with nils. But this line is actually unnecessary, because in lua if table has key with value nil then it is like it doesn't exist.

For example, this piece of code will print 2 not 3.

count = 0
for k,v in pairs({a = 1, b = nil, c = 3}) do
    count = count + 1
end
print(count) -- 2

from dap-buddy.nvim.

Thanks for the update. It really seems like you are reimplementing tbl_extend, but if you are more comfortable with your implementation that will most likely work fine. Seems like a reasonable solution to me 🙂

Edit: Actually I think you are reimplementing tbl_deep_extend.

from dap-buddy.nvim.

I'm so blind, I knew about tbl_extend but not about this one. tbl_deep_extend is exactly what I was implementing with that recursive function lol. Thanks @brandoncc!

from dap-buddy.nvim.

You fixed it :-) My original config posted above works great now:

dap_install.config('ruby_vsc_dbg', {
  configurations = {
    {
      name = "Run RSpec until the next failure";
      type = "ruby";
      request = "launch";
      cwd = "${workspaceFolder}";
      useBundler = true;
      pathToBundler = "/Users/brandoncc/.asdf/shims/bundle";
      pathToRDebugIDE = "/Users/brandoncc/.asdf/shims/rdebug-ide";
      showDebuggerOutput = true;
      program = "${workspaceFolder}/bin/rspec";
      args = { "--next-failure" };
    }
  }
})

It is very possible I can cut some of that out such as useBundler as mentioned above, but I'm stoked to have it working. Thanks!

from dap-buddy.nvim.

Hey! so the author of vscode-ruby himself, @rafcamlet, added this debugger through the PR #5. I must admit, I've never used it myself but since the code was clean and the project itself had 1k back then, I marked it as "Tested" (original comment).

He mentioned that:

Provided configuration is designed for working with simple scripts or small programs, but won't work with Rails applications - rails apps are the main commercial use of ruby. Maybe we should provide multiple configurations or some kind of help/instructions? Are such things outside the scope of this plugin?

So I assume that there are some other settings that must be tweaked externally for this debugger to work, and maybe that's the reason why ruby might not using all configuration keys. With the help of @rafcamlet, I think we could make a full integration with debuggers outside of nvim-dap's scope to be installed and handled through DAPInstall.nvim, because for now, as he mentioned:

I've never seen multiple default configs (in dap or vimspector wikis).

from dap-buddy.nvim.

@pocco81 thanks for the response. I'd be happy to pitch in where I can to make this happen. I'd love to be able to debug my rspec tests (that is what I'm trying to do here). Here is a SO post about it. I really don't think it would be that hard to get it working...but what do I know 😂

from dap-buddy.nvim.

Perhaps the official debugger supported by nvim-dap might work for you as well?

from dap-buddy.nvim.

That looks really promising, I will try that today and let you know. Thank you 👍

from dap-buddy.nvim.

I was looking at all the debug adapter protocols because according to nvim-dap's repo, they should all work and the ruby one is in the list, but not in their wiki! Which means that everything should technically work.

DAPInstall.nvim is just an installer that parses and passes whatever you pass to dap_install.config(<dbg>, <conf>) to nvim dap. Which means that IF some/all keys are not being passed properly then that means it's an nvim-dap issue. Maybe you could try installing and configuring it manually to discard it from being a DAPInstall.nvim issue?

from dap-buddy.nvim.

I give up, I'll just stick with pry/byebug because I don't understand how to use dap. Thanks for the help, sorry I don't want to continue trying to make it work.

from dap-buddy.nvim.

@pocco81 I think this check is unnecessary: https://github.com/Pocco81/DAPInstall.nvim/blob/main/lua/dap-install/init.lua#L41

I don't see any reason why we shouldn't allow users to pass anything they want to dap configure. Actually, I would suggest replacing these iterations over settings keys with the tbl_extend for example.

First of all, my bad! I thought every debugger had a adapters = {} and a configurations = {}, because that's what I saw in nvim-dap's wiki.

I don't think we need tbl_extend for this. So, what if users just passed the config directly to nvim-dap (as you said) but through DAPInstall? This would be useful for those that just want the defaults. In that way leaving it empty or nil would pass the default config. And of course for those that do pass a config it would get to nvim-dap directly.

This would save the iteration process. Furthermore, if users wanted to use the default config but only editing certain values, then they could pass a table with, let's say: default_config ={ some_key = "a value I want" }

Or maybe this last part not? What do you think @rafcamlet ?

And I'm still thinking about adding some more sample configurations or maybe a wiki page?

For DAPInstall.nvim? Yeah we could do that. But keep in mind that nvim-dap already has some sample configs over at their wiki. But still, seems like a great idea!

from dap-buddy.nvim.

I agree that it seems like tbl_extend might be a useful tool here. I don't think I've ever seen a tool where you modify the default config instead of providing a user config that just extends the author's default config.

I love to see the progress here, and am still happy to help where I can.

from dap-buddy.nvim.

Hello again! sorry for taking too long to come back to this, I was kind of busy. So, I've decided to implement kind of the same mechanism lspinstall.nvim has, which was also discussed above: there will be the default config that has what's needed for the debugger to work; and then user defined key and vals will be passed through the dap_install.config() func to replace/add them to the conf using tbl_deep_extend as suggested by @brandoncc.

This should fix #10 and make the code more readable.

Edit: removed my recursive func and added @brandoncc's suggestion.

from dap-buddy.nvim.

As discussed, here is the final implementation: 83dd152

However, I don't want to close the issue just yet. @brandoncc in the end did you try the ruby debugger mentioned in nvim-dap's wiki? If so, do you think it should also be added to DAPInstall.nvim?

from dap-buddy.nvim.

I actually only learned about deep extend yesterday too 😂 I did try the configuration you are referring to and it gave me a different issue that I don't remember, which frustrated me. I don't understand DAP well enough to figure it out, and I didn't (and still don't) have time to learn about DAP. That's why I gave up and went back to using pry.

I'll try your fix today and let you know if it makes any difference in my original issue.

Thanks for your time on this!

from dap-buddy.nvim.

I mean... I didn't do much, I just made the config more extensible and that's it hahah. The real MVP is the creator of nvim-dap! Maybe you should try opening an issue in his repo asking for help on how to configure x debugger.

For now I think I'm gonna merge that commit with main and close the issue :)

Edit: of course if something come up (ideas, bugs, etc) let me know and I'll reopen it to discuss about them 👍

from dap-buddy.nvim.