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.
···
--
Posted via http://www.ruby-forum.com/.
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
http://rdoc.rubyforge.org/RDoc/RI/Store.html
···
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.
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 May 6, 1:17 pm, Intransition <transf...@gmail.com> 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.
Thomas Sawyer 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
···
--
Posted via http://www.ruby-forum.com/\.
Last I checked fastri no longer worked.
···
On May 6, 3:45 am, Brian Candler <b.cand...@pobox.com> 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 May 6, 2010, at 00:45 , Brian Candler wrote:
Have you looked at fastri?
Don't know how it works internally, but it's a lot faster than the 1.8
ri.
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
···
On Fri, May 7, 2010 at 5:25 PM, Gavin Sinclair <gsinclair@gmail.com> 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.ri's knowledge is static and shallow; the potential exists for it to
be dynamic and deep. Or something.
Eric Hodel 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).
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, 5:25 am, Gavin Sinclair <gsincl...@gmail.com> 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.
thanks for the tip. just upgraded now.
best regards -botp
···
On Sat, May 8, 2010 at 5:02 AM, Roger Pack <rogerpack2005@gmail.com> wrote:
NB that ri speed has much improved with more recent versions of rdoc..
You're told which gem the method comes from using RDoc 2.5:
$ ri String
[...]
(from ruby core)
[...]
Instance methods:
%
···
On May 7, 2010, at 02:25, Gavin Sinclair wrote:
On May 6, 1:17 pm, Intransition <transf...@gmail.com> 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.
*
+
[...]
(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.
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 Fri, May 7, 2010 at 1:42 AM, Intransition <transfire@gmail.com> wrote:
On May 6, 3:45 am, Brian Candler <b.cand...@pobox.com> 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.
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<TAB>' or 'String#g<TAB><TAB>'
···
On May 7, 2010, at 12:47, Joel VanderWerf wrote:
Eric Hodel 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).
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 May 6, 2010, at 19:00, botp wrote:
On Fri, May 7, 2010 at 1:42 AM, Intransition <transfire@gmail.com> wrote:
On May 6, 3:45 am, Brian Candler <b.cand...@pobox.com> 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
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 Tue, May 11, 2010 at 7:19 AM, Eric Hodel <drbrain@segment7.net> 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)
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'
···
On May 10, 2010, at 17:48, botp wrote:
On Tue, May 11, 2010 at 7:19 AM, Eric Hodel <drbrain@segment7.net> wrote: