Is this meant for public consumption yet?

[dgutov]

Is this meant for public consumption yet?

[dgutov]

Hi,

Yes, I think it is. As far as I know, at least a few people aside from me are using it successfully.

Here is the stracktrace after starting inf-ruby and loading in the project code:

I'll try it with Rubinius, but if you puzzle out what the problem is here first, be sure to let me know. The warning about TCPServer Error: Address already in use shows up with MRI too, but only once, and it doesn't seem to impact anything.

but I couldn't get it to work with MRI and 1.9.3 either.

It definitely should work with that version. What were your problems with it? The same?

I noticed there was no .rvmrc in your robe folder, so I suppose another source of issues lies in the interaction between robe, inf-ruby and rvm.el.

I don't see how .rvmrc could be used. The Ruby part of Robe is not an application, it's a library loaded from LOAD_PATH, so at no point .rvmrc will be picked up. I'm using it along with rvm.el just fine.

As an aside how do you manage the load path for inf-ruby to add the current project? Do you manually $:.unshift "/path/to/lib"? I wrote a small helper function do this, but it felt pretty backwards.

At this point you either have a Rails application, which you load with rinari-console, or you have a small script or assortment of files, and you load each of them manually with ruby-load-file (C-c C-l).

For gem or library development, you should be able to write a wrapper for run-ruby that would call irb with appropriate -I argument. At least, that's one option. If you have a suggestion how I can support this case better in Robe, let me know.

If you think it's possible to get Robe to work with Rubinius, I'd be interested in helping with that.

Yes, please go ahead. I'll answer any questions about the code you have.

I'm vaguely planning to use Ripper, which is absent from Rbx, to implement type inference, etc, but at this point the incompatibilities should be small. For example, from reading method_location code, which pry uses, Rubinius seems to have a compatible Method#source_location implementation, which is not the case with JRuby.

[expez]

Thanks for getting back to me so soon.

I don't see how .rvmrc could be used. The Ruby part of Robe is not an application, it's a library loaded from PATH, so at no point .rvmrc will be picked up. I'm using it along with rvm.el just fine.

What I meant was that since there was no .rvmrc in your robe project, perhaps you didn't use rvm.el and therefore this might cause issues you had not encountered. This was what was tripping me up. Even though I had started an inf-ruby process manually using MRI, rvm.el would keep messing with path due to the rvmrc. When I changed the .rvmrc to use MRI, robe worked just fine.

Without running (require 'ac-robe) the auto-completion didn't work. I'm not sure if autoload directives work on consts like ac-source-robe. Not a huge deal, but I figured the autoload directives indicated that the package manager should take care of loading everything.

[dgutov]

It's good to know you got it working. I'll take that to also mean I shouldn't expect Rubinius-related contributions anytime soon. :)

I figured the autoload directives indicated that the package manager should take care of loading everything

That should be true, as long as you're installing with package.el (not via el-get or simple git checkout). Here's what I see in the auto-generated robe-autoloads.el:

(autoload 'robe-ac-available "robe-ac" "\
Return t if `robe-mode' completions are available, otherwise nil.

\(fn)" nil nil)

(defconst ac-source-robe '((available . robe-ac-available) (candidates . robe-ac-candidates) (document . robe-ac-doc) (symbol . "r")) "\
`auto-complete' completion source for Ruby using `robe-mode'.")

If that didn't work without additional require, I figure @purcell would have already complained by now.

[expez]

I'll take that to also mean I shouldn't expect Rubinius-related contributions anytime soon. :)

I would like to add support for Rubinius; I think Rubinius is awesome. But, I only recently starting messing with Ruby and after taking a look at the code base I think this might currently be more than I can handle.

[dgutov]

Ok, that's no problem.

[purcell]

@dgutov Indeed, the following config works for me using just the autoloads, ie. no (require 'robe):

(add-hook 'ruby-mode-hook 'robe-mode)
(add-hook 'robe-mode-hook
          (lambda ()
            (add-to-list 'ac-sources 'ac-source-robe)
            (setq completion-at-point-functions '(auto-complete))))

[dgutov]

@expez I've fixed a small problem with Rubinius' Socket::Foreign, and it more or less works, as long as you set RBXOPT to -X19. I haven't seen the stack trace you've posted in the issue description, but some tests still fail, most of them related to documentation.

Unfortunately, it's like 30 times slower than MRI in the "full search" case (making that kind of operation take ~0.4s even without any additional gems loaded), so eldoc makes editing sluggish. Probably because of the slow ObjectSpace.each_object. I'll see what I can do, maybe ActiveSupport::DescendantsTracker could be a good solution.

[expez]

Cool! I think Rubinius is pretty great and would love to see it get more widely used. Proper tool support certainly helps in that regard 👍