What do others think of a creating a new ri tool which uses a SQLite
database for storage instead of flat files? I figure doing that would
make it easy to create dynamic documentation websites (using ones
favorite web framework), not to mention that the ri command line tool
should be pretty fast.
Have you looked at fastri?
Don’t know how it works internally, but it’s a lot faster than the 1.8
ri.
On May 6, 3:45 am, Brian C. [email protected] wrote:
Have you looked at fastri?
Don’t know how it works internally, but it’s a lot faster than the 1.8
ri.
Last I checked fastri no longer worked.
On May 6, 2010, at 00:45 , Brian C. wrote:
Have you looked at fastri?
Don’t know how it works internally, but it’s a lot faster than the 1.8
ri.
If you’re not on windows, then it isn’t (much) faster than ri (via the
rdoc rubygem).
If you’re on windows, then the directory traversal is much slower than
it should be. Easy fix tho… 
On Fri, May 7, 2010 at 1:42 AM, Intransition [email protected]
wrote:
On May 6, 3:45 am, Brian C. [email protected] wrote:
Have you looked at fastri?
Don’t know how it works internally, but it’s a lot faster than the 1.8
ri.Last I checked fastri no longer worked.
do it like this,
gem install fastri
gem install dakrone-fastri
works (very fast) in windows and *nix.
you may need to sudo in *nix though.
best regards -botp
On May 5, 2010, at 20:17, Intransition wrote:
What do others think of a creating a new ri tool which uses a SQLite
database for storage instead of flat files? I figure doing that would
make it easy to create dynamic documentation websites (using ones
favorite web framework), not to mention that the ri command line tool
should be pretty fast.
Go for it!
RDoc 2.5 features a much simpler ri data file generator that uses the ri
data storage class RDoc::RI::Store. It should be relatively easy to
adapt (probably subclass) RDoc::RI::Driver to use an alternate store.
Since RDoc ships with ruby core you’d need to convince them to add
sqlite to the core before something like this could be merged into RDoc
itself. Maybe you could use one of the built-in key-value store
databases like gdbm instead. There’s no reason to use a relation
database when RDoc::RI::Store only deals with sets of key-value pairs.
See:
http://rdoc.rubyforge.org/RDoc/Generator/RI.html#method-i-generate
On May 6, 1:17 pm, Intransition [email protected] wrote:
What do others think of a creating a new ri tool which uses a SQLite
database for storage instead of flat files? I figure doing that would
make it easy to create dynamic documentation websites (using ones
favorite web framework), not to mention that the ri command line tool
should be pretty fast.
I’ve thought of it many times, but would never personally undertake
such a project.
In addition to hoped-for speed, the motivating factor for me would be
deeper documentation knowledge.
For instance, if you do ‘ri String’ now, you are told about all String
methods from any library you have installed, as if they were all
available all the time. You’re not told what you have to “require” to
get access to the various methods.
ri’s knowledge is static and shallow; the potential exists for it to
be dynamic and deep. Or something.
I haven’t really looked at or used ri for some time now, so apologies
if my comments are outdated.
Gavin
On Fri, May 7, 2010 at 5:25 PM, Gavin S. [email protected]
wrote:
get access to the various methods.
ri’s knowledge is static and shallow; the potential exists for it to
be dynamic and deep. Or something.
maybe because the docs are just mined from the source. doc making
should be a community effort (just imagine translating it to different
langs)… maybe something like a collaborative wiki/git, wherein
downloading and updating is allowed using just the command line, eg
ring fetch/pull…
ring string.upcase (i like fastri’s case insensitivity and hash/dot
mxing)
ring string.upcase --remote (get doc from remote git hub)
ring here meaning ri nxt gen
best regards -botp
Eric H. wrote:
Since RDoc ships with ruby core you’d need to convince them to add
sqlite to the core before something like this could be merged into
RDoc itself. Maybe you could use one of the built-in key-value store
databases like gdbm instead. There’s no reason to use a relation
database when RDoc::RI::Store only deals with sets of key-value
pairs.
An rdb would give you prefix search (useful for completion).
Thomas S. wrote:
What do others think of a creating a new ri tool which uses a SQLite
database for storage instead of flat files? I figure doing that would
make it easy to create dynamic documentation websites (using ones
favorite web framework), not to mention that the ri command line tool
should be pretty fast.
NB that ri speed has much improved with more recent versions of rdoc…
-rp
On Sat, May 8, 2010 at 5:02 AM, Roger P. [email protected]
wrote:
NB that ri speed has much improved with more recent versions of rdoc…
thanks for the tip. just upgraded now.
best regards -botp
On May 7, 5:25 am, Gavin S. [email protected] wrote:
I’ve thought of it many times, but would never personally undertake
such a project.In addition to hoped-for speed, the motivating factor for me would be
deeper documentation knowledge.For instance, if you do ‘ri String’ now, you are told about all String
methods from any library you have installed, as if they were all
available all the time. You’re not told what you have to “require” to
get access to the various methods.
This has been my feeling as well.
I have started the project, but so far I only have it dumping the flat
data into the database. I’m not sure I am doing it in the right place
either. I need to consider what Eric has said and take that into
account. (Eric, thanks for the direction.)
On May 7, 2010, at 02:25, Gavin S. wrote:
In addition to hoped-for speed, the motivating factor for me would be
deeper documentation knowledge.For instance, if you do ‘ri String’ now, you are told about all String
methods from any library you have installed, as if they were all
available all the time. You’re not told what you have to “require” to
get access to the various methods.
You’re told which gem the method comes from using RDoc 2.5:
$ ri String
[…]
(from ruby core)
[…]
Instance methods:
%
*
+
[…]
(from gem builder-2.1.2)
[…]
Instance methods:
to_xs
[…]
ri’s knowledge is static and shallow; the potential exists for it to
be dynamic and deep. Or something.I haven’t really looked at or used ri for some time now, so apologies
if my comments are outdated.
I’ve heard from several people that RDoc 2.5’s ri output is much
improved. I didn’t really work that hard on making it better, though.
On May 6, 2010, at 19:00, botp wrote:
gem install fastri
gem install dakrone-fastri
That code is outdated.
RDoc uses Marshal data files now and fastri uses the old yaml files.
Maybe someday somebody will actually bother contributing improvements to
RDoc instead of letting them fall by the wayside every other year.
(hint, hint)
On Tue, May 11, 2010 at 7:19 AM, Eric H. [email protected]
wrote:
RDoc uses Marshal data files now and fastri uses the old yaml files.
Maybe someday somebody will actually bother contributing improvements to RDoc instead of letting them fall by the wayside every other year. (hint, hint)
Hi Eric,
i just updated rdoc to latest, and rebuilt all docs. yes, rdoc is a
lot better (faster & more comprehensive) now.
i’ve always thought (and i was terribly wrong) that rdoc is builtin in
ruby19 and that a simple gem update would rebuilt it… so there… a
terrible nuby error on my part…
thanks for rdoc
best regards -botp
On May 7, 2010, at 12:47, Joel VanderWerf wrote:
Eric H. wrote:
Since RDoc ships with ruby core you’d need to convince them to add
sqlite to the core before something like this could be merged into
RDoc itself. Maybe you could use one of the built-in key-value store
databases like gdbm instead. There’s no reason to use a relation
database when RDoc::RI::Store only deals with sets of key-value
pairs.An rdb would give you prefix search (useful for completion).
Not necessary as ri does completion out of its indexes:
$ ri String#gs
String#gs not found, maybe you meant:
String#gsub
String#gsub!
And the indexes are stored in a special “key” in each RDoc::RI::Store
“database”
Also try ri -i then type ‘String#gs’ or ‘String#g’
On May 10, 2010, at 17:48, botp wrote:
On Tue, May 11, 2010 at 7:19 AM, Eric H. [email protected] wrote:
RDoc uses Marshal data files now and fastri uses the old yaml files.
Maybe someday somebody will actually bother contributing improvements to RDoc instead of letting them fall by the wayside every other year. (hint, hint)i just updated rdoc to latest, and rebuilt all docs. yes, rdoc is a
lot better (faster & more comprehensive) now.
Thanks!
If you have any suggestions for further improvements I’d love to hear
them. The easiest place is on the bug tracker at rubyforge.
i’ve always thought (and i was terribly wrong) that rdoc is builtin in
ruby19 and that a simple gem update would rebuilt it… so there… a
terrible nuby error on my part…
The way RubyGems works you can use it to replace any part of the
standard library provided you call gem before require. The other big
library that uses this is soap4r like:
gem ‘soap4r’
require ‘soap4r’