Dhaka-1.0.0 now with RDoc

Ruby
1

Three major changes with this release:

  1. A backwards-incompatible modification to Dhaka::Evaluator (hence the
    jump
    to 1.x.x - I just discovered the rational versioning system):
    When specifying evaluation rules, Evaluator#evaluate must now explicitly
    be
    called on child nodes. This is required to allow for the possibility of
    referring to syntax tree nodes while deferring evaluation (useful, say,
    if
    you wanted to implement something like functions). I’ve changed the
    examples
    at the project homepage accordingly. The code just looks marginally
    uglier.

  2. In response to requests, I’ve included a mini-language called
    Chittagong
    in the test suites. It’s no Ruby, but it has if-else statements and
    while-loops and other nice things, and is pretty illustrative about how
    to
    go about implementing something more complicated than the Ruby Q.
    examples. Many thanks to Henry (unfortunately I don’t know your full
    name)
    for pointing out the need for an example of this sort.

  3. Dhaka now has an RDoc. It’s a lot of work, but a pretty small API!
    Thanks
    to Gregory B. for requesting this. I hope it helps.

Mushfeq.

2

I forgot to mention that the RDoc is located at:

http://dhaka.rubyforge.org/doc/index.html

Mushfeq.

3

On 1/8/07, Mushfeq K. [email protected] wrote:

  1. Dhaka now has an RDoc. It’s a lot of work, but a pretty small API! Thanks
    to Gregory B. for requesting this. I hope it helps.

Hi Mushfeq. Thanks for mentioning me!

The RDoc is certainly helpful. It’d be great if you also included a
simple code example for some of the most important classes. The big
examples are awesome for showing the depth of your very cool work, but
it’s a little tough to figure out how to do small tasks.

I’m interested in getting hacking with Dhaka, so I’ll keep an eye on
the project for sure.

warm regards,
-greg

4

Hi,

I’ll start including more code in the RDocs. The most important classes

really the only important classes - are Grammar, Tokenizer and
Evaluator.
These are where the hacking occurs. While the test suites contain
several
examples of each class, they are admittedly complex. I’m strongly for
the
idea that good examples are the best kind of explanation, the simpler
the
better. If you have ideas for such examples, let me know.

Mushfeq.

5

On 1/9/07, Mushfeq K. [email protected] wrote:

Hi,

I’ll start including more code in the RDocs. The most important classes -
really the only important classes - are Grammar, Tokenizer and Evaluator.
These are where the hacking occurs. While the test suites contain several
examples of each class, they are admittedly complex. I’m strongly for the
idea that good examples are the best kind of explanation, the simpler the
better. If you have ideas for such examples, let me know.

Something like parsing CSV or JSON would be a great reference. Both
have fairly simple rules…
Thanks for pointing at these classes. What we tried to do in Ruport
(though it needs updating!) is have our readme display as the front of
the RDoc and do a quick description of the most important classes
right in the Readme, so people know right where to go.

Maybe that’d help make it easier for folks to find the relevant docs
in Dhaka as well.