FastRI 0.1.0: faster, smarter RI docs for Ruby, DRb-enabled

On Tue, Nov 14, 2006 at 02:13:00AM +0900, Dominic S. wrote:

On 11/8/06, Mauricio F. [email protected] wrote:

FastRI is an alternative to the ri command-line tool. It is much faster,
and also allows you to offer RI lookup services over DRb. FastRI is smarter
than ri, and can find classes anywhere in the hierarchy without specifying
the “full path”. It also knows about gems, and can tell you e.g. which
extensions to a core class were added by a specific gem.

How do you get it to index ruby gems?

fastri-server searches “#{Gem.path}/doc/*/ri” for yaml files holding RI
documentation when it builds the index (the first time you run it and
when you
do fastri-server -b). These files are generated by RubyGems as you
install
the corresponding package (since 0.9.0).

Unlike ri, FastRI remembers in which gem a method/class/module was
defined.
This knowledge will soon be exposed to the end-user, allowing you to
know e.g.
which gems extend a given core class, or to get the extensions
introduced by a
gem.

How do you get it to index ruby gems?

thanks,
dom

:From Mauricio Julio Fernández Pradier

FastRI remembers in which gem a

method/class/module was defined.

This knowledge will soon be exposed to the end-user, allowing

you to know e.g. which gems extend a given core class, or to get the

extensions introduced by a gem.

+1 again for that.
thanks -botp

Mauricio F. - http://eigenclass.org - singular Ruby

Thanks,

I had to update my rubygems and then rebuild the fastri index and it is
now
working!

dom

I must be missing something.
My fastri founds much less documentation than ri.

Shell output follows:

piastrella:~$ fastri-server -b
Building index.
Indexed:

  • 7565 methods
  • 1316 classes/modules
    Needed 1.764042 seconds
    piastrella:~$ fastri-server
    Looking for Ring server…
    No Ring server found, starting my own.
    fastri-server 0.0.1 (FastRI 0.1.1) listening on druby://
    127.0.0.1:49772
    ACL:
    deny all
    allow 127.0.0.1
    ^Z
    1+ Stopped fastri-server
    piastrella:~$ bg
    1+ fastri-server &
    piastrella:~$ fri find|wc -l
    3
    piastrella:~$ ri find|wc -l
    53
    piastrella:~$ uname -a
    Darwin piastrella.local 8.8.0 Darwin Kernel Version 8.8.0: Fri
    Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power
    Macintosh powerpc
    piastrella:~$ ruby -v
    ruby 1.8.5 (2006-08-25) [powerpc-darwin8.8.0]

I’m using Mac OS X 10.4.8.
Both fastri and ruby should be up to date.

Could it be because Mac OS X has a broken installation of ruby by
default, and it’s usually installed a new version in /usr/local as
1 says? It’s even suggested by Apple itself ([2]).
Maybe fastri is confused about where to look.
I’ve just read other response in this thread, but I couldn’t find
anything like this: am I the only Mac user who tried fastri within
this mailing list?

Anyway, how do I fix this? :slight_smile:

ruby_rails_lighttpd_mysql_tiger
[2]: http://developer.apple.com/tools/rubyonrails.html

On Tue, Nov 14, 2006 at 06:26:15PM +0900, Gabriele M. wrote:

Needed 1.764042 seconds
[…]
piastrella:~$ fri find|wc -l
3
piastrella:~$ ri find|wc -l
53

There are a couple explanations for this. From most to least important:

(1)
FastRI’s search strategy is more sophisticated than ri’s and it will try
several methods successively, yielding the results as soon as there’s a
match
(if it’s unique, you get the description, otherwise a disambiguation
message).

$ fri -h
Usage: fri [options]
-s, --bind ADDR Bind to ADDR for incoming DRb
connections.
(default: 127.0.0.1)
-O, --order ORDER Specify lookup order.
(default: eEnNpPxX)
Uppercase: case-indep.
e:exact n:nested p:partial
(completion)
x:nested and partial
a:match method name anywhere
–show-matches Only show matching entries.
-S, --full-text Perform full-text search.
[…]

The default search strategy is eEnNpPxX, which means that it will try in
this
order
(a) exact matches
(b) “nested matching”: Foo#bar -> ActiveBar::Foo#bar &
ActiveAction::Baz::Foo#bar
© partial matching: Foo#bar -> Foo#bar_whatever & Foo#bartender
(d) partial + nested: Foo#bar -> ActiveFoo::Foo#bartz &
A::b::Foo#bart_foo

When you do fri find, since there’s no exact match, by default fri will
fall
back to “nested matching”, yielding all methods named “find” under any
class/module:

$ fri find
------------------------------------------------------ Multiple choices:

 ActiveRecord::Base.find, Daemons::Monitor.find, Enumerable#find,
 Find#find, Pathname#find, Rinda::TupleBag#find, TagModule#find

By contrast, ri will return any methods matching /find/ (e.g. both
Foo#do_find_foo and Bar#find_dsad) when it doesn’t find an exact match.

fri’s search strategy can be specified with the -O option. You can make
it
behave more like ri with -O aA:

$ fri -O aA find
------------------------------------------------------ Multiple choices:

 ActionController::TestProcess#find_all_tag,
 ActionController::TestProcess#find_tag,

[…]
TestAutotest#util_find_files_to_test,
TestSexp#test_find_and_replace_all, URI::Generic#find_proxy,
[…]
WSDL::XMLSchema::ComplexType#find_element_by_name,
XSD::NamedElements#find_name

$ fri -O aA find --show-matches | wc -l
95

(2) ri doesn’t handle multiple versions of a gem correctly

$ ri -T ActiveRecord::Base::find
More than one method matched your request. You can refine
your search by asking for information on one of:

 ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
 ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
 ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
 ActiveRecord::Base::validate_find_options,
 ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
 ActiveRecord::Base::validate_find_options,
 ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
 ActiveRecord::Base::validate_find_options,
 ActiveRecord::Base::find, ActiveRecord::Base::find_by_sql,
 ActiveRecord::Base::validate_find_options

vs.

$ fri Base.find
----------------------------------------------- ActiveRecord::Base::find
ActiveRecord::Base::find(*args)

[…]

So there are probably many repeated entries in your ri find|wc -l

Could it be because Mac OS X has a broken installation of ruby by
default, and it’s usually installed a new version in /usr/local as
[1] says? It’s even suggested by Apple itself ([2]).
Maybe fastri is confused about where to look.

I believe that wasn’t the case (FastRI looks for RI docs in the same
dirs as
ri anyway), since:

piastrella:~$ fastri-server -b
Building index.
Indexed:

  • 7565 methods
  • 1316 classes/modules

You can get the full list of instance methods known to FastRI with

$ fri --show-matches “#”

Here “#” matches any instance method; in order to get all singleton
(class/module) methods, you’d do
$ fri --show-matches ::

And to get both,

$ fri --show-matches .

On 15/nov/06, at 00:02, Mauricio F. wrote:

disambiguation message).

[…]
(2) ri doesn’t handle multiple versions of a gem correctly

Thank you for your detailed answer.
The latter one was actually the case: I had many duplicated gems;
‘gem cleanup’, ‘gem rdoc -all’, ‘fastri-server -b’ did the job.
Now everything works :slight_smile:

Thank you!