[Aiml-programr-developers] Items for the next release

[Nicholas H.Tollervey]

Guys,

First off, apologies for being off the radar for a few days...
"real-life" has imposed itself on my time - my wife is due with our
third child in a fortnight - so I've had lots to do (putting up nursery
related things, buying nappies etc...). However, I'm at a UK Python
developers conference this weekend and there are a number of hours free
in the schedule when I can do the things I've been meaning to do for
ProgramR.

They are:

1. Finish the high-level activity diagram and associated notes I started
on Wednesday. This explains the life cycle of a request to an AIML bot.
I'm including examples of how the input text is normalised and output
text generated (according to the AIML standard) so the various
activities associated with a request / response include concrete examples.
2. Write up how I did the graphmaster algorithm in Program#. We can use
this as a compare and contrast exercise with the current implementation.
My main concern is that I think in a C-like way and I'll need guidance
on how best to do stuff the Ruby way. :-) Something I'm looking forward to.
3. Start looking at / organising the unit tests. Program# has over 200
associated with it... the original ProgramD provides another set (my own
evolved from this set). I'll dig up the ProgramD unit tests from their
CVS site. There is no "official" test-set, although the AIML
specification is mostly good at being unambiguous when it comes to
handling the AIML tags, so we can use that as vade mecum.

Now, onto Mauro's email:

Rake seems to be an excellent tool for project automation - and I
certainly believe that we should automate as much as possible. However,
I agree that we should impose as few constraints on "regular" users. I
personally think we should concentrate on implementing a Ruby library
with Rake and unit tests and other things for developers and also create
a simple (and less encumbered - dependency wise) GUI (TK?) application
for non-devs who want to play. All this to come under the umbrella of
"ProgramR".

As I suggested above, I don't mind at all taking ownership of the unit
tests. This is, of course, only one of the tasks we should start before
actually coding. We should spend some time working out the basic
geography / organisation of the project so we meet our 1.0 goal of a
fully compliant AIML implementation in Ruby. I also agree with Mauro's
suggestion of having a fixed amount of features that we do as soon as we
can.

I'll post to this list (and possibly also to my blog) the work I
mentioned at the start of this email as and when it gets finished.

Ciao,

Nicholas
 
mauro at cicio.org wrote:
> The following in in brainstorming mode.
>
> = RAKE
> =====
> Nicholas, time ago, has suggested, among other things, to offer a rake
> interface to the tests.
> Even if the current ./bin/test is fine to me for the moment, I agree
> in saying that a rake would be much better choice considering that the
> amount of tests should be growing and we might want to group them in
> different orders.
> Still, I think that it would be better not to create unnecessary
> dependencies for our users.
> My opinion: yes to rake for the developer tasks, no user tasks rake based.
> What do you think?
> If you agree, I would put rake in the todo list with lower priority
> than, say, actually begin writing the tests.
>
> = TEST SET
> ========
> The supported features so far should be the ones in
> http://projects.dottorsi.com/ki/programr/pages/Features
> It might be that the list is not 100% up-to-date.
> I think that at the moment the one that knows the most of AIML among
> us is Nicholas, so I believe that he is the best fit to select an
> appropriate test set (of course if Nicholas likes the idea to have
> also this task).
> Do you have THE list of tests that we have to pass in order to
> consider programR compliant to the AIML standards? If you do, then I
> would consider as one of the highest priority tasks to have this list
> in our todo (on task per each item of the list).
>
> = GRAPHMASTER OR NOT GRAPHMASTER?
> ==========================
> On the "kernel" side, I have proposed to begin from the GRAPHMASTER.
> It should have some basic tests and it should be well understood
> before proceeding. We have to know how it works in order to understand
> how it can be improved to support all the AIML tags which are not yet
> supported.
> In a chat with Ben, it came out that this could be an interesting
> starting point for him as well.
>
> = OTHERS
> =======
> Like the Agile Developers say, we either have
> A - a fixed time frame and we do as much as we can
> or
> B - a fixed amount of features and we do them as soon as we can
>
> Just as a discussion base, I propose to work with B with the following features:
> - solid test/verification of the current supported TAGS
> - improved felxibility of the kernel
> - standardization of the delivery package (gem?)
>
> It is probably worh to repeat it: I am 100% in brainstorming mode.
>
> Ciao,
> Mauro
> _______________________________________________
> Aiml-programr-developers mailing list
> Aiml-programr-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>
>