[Nitro] RDog ping

James Britt james.britt at gmail.com
Mon Jun 26 18:41:38 EDT 2006

Andrew Thompson wrote:

> ...
> I'm not convinced we need YAML at all, why not pass the data to Og? Then
> we can cleanly only get the information we need, rather then sucking big
> YAML files into RAM.
> Anyway, I know I said I'd try to knock the rdog generator into shape,
> but I've been far too busy to have the energy to touch it. I apologise
> but I'm not sure when I will have a chance to attack it...

Well, so far, I've hacked up ruedoc to output a single yaml file for 
each source file.  Each file nows what source it came from.

I've mocked out og'ed classed for each fundamental object (file, class, 
module, method, constant, some others maybe) that map t the structure of 
the yaml.

Then some simple code that reads in a yaml file and creates the object 
hierarchy (which in turn populates the database).

There is no longer a single giant YAML file, and my thinking is that 
having a data file for each source file makes it easier to add in 
arbitrary code (e.g., from gems or other 3rd-party libs) without 
overwriting current data.  Then you can always tell if a method is 
defined in a the original class or added by the inclusion of another 
file.  (The next release of rubygems is, I think, to have an option to 
add data to ri.  Curious to see this.)

I did this in a series of steps as I became familiar with rdoc and a bit 
more familiar with Og.  So this is not the results of some master plan, 
but the current state of some exploring.  But what I like is that each 
part is simple, and adding/modifying content is also simple.

The question that's in my head now is how to best represent the data for 
queries.  Loading data happens rarely; querying is the whole point. 
Would some in-memory structure be faster than using MySql or Sqlite (or 
some other more or less conventional relational DB)?  Am I getting into 
premature optimization?

I'd really like to end up with something that can be easily installed on 
  a desktop and used in place of ri while running faster and not 
consuming vast resources.  Basically, ri as a local (Web) service with a 
CLI client as well.

James Britt

"Blanket statements are over-rated"

More information about the Nitro-general mailing list