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

Sun Sep 9 05:08:26 EDT 2007

Apologies to you and your wife for stealing you time right now!
Compliments for the newcomer!

In the following I try to find the concrete tasks to write in our list
and to see what I can do for the project in the next days.
If you need my help in other areas, please just say so.

* On your point 1: of course this is going to be very valuable!

- What I can do: not too much I am afraid, but given that I have been
designing for years, if you need me to review your design, just ask.
Your call.

* On your point 2: yes, I think comparing graphmasters of programR and
Program# is the best way for all of us to learn from our experiences.
If possible, I would suggest to prepare the ground by working on the
programR graphmaster in parallel. More concretely:
  a - Nicholas documents Program#'s graphmaster
  b - Ben and I document  programR's one.
(Ben, if you are still up to it, I would be glad to brainstorm, give
feedback and support your effort to study/document the graphmaster.
Just let me know.)
  c - Once we all know about the 2 experiences, we brainstorm on them
and, eventually, generate the programR 2 concept.
If it is OK for you, I think we can extract from the above concrete
tasks to be put in our task list.

- What I can do: as agreed wiith Ben, I'll support all his activity in
understanding/documenting GM. Ben's call.

* On your point 3
You say that there is not an "official" test-set. I believe that this
is a great service we can offer to the community: a well done and
complete test set with punctual references to the AIML documentation.
If we do a good job, other implementations could benefit from it (and
port our tests to their benefit)

- What I can do: help in coding the tests specified by Nick (may I use
Nick? I am a slow typer...)

Rake vs sh
---------------
To be clear: I am 100% for automation (being a linux user for 12 years :-))
I guess I consider "natural" to use the shell, not Rake. I see Rake as
something that creates an additional dependency for the end user that
is not a rubyst.
I think I have to review this position of mine because:
+ ruby is much more spread now than when I begun using it
+ rake is probably an accepted standard by now (is it part the ruby
distribution?)
+ the end user probably does not use neither sh nor rake
So, on my side, I welcome using rake for our tests if you prefer so.
Currently programR runs the tests from bin/test (we have seen that the
tests work fine).

- Rubify
-----------
Probably I am the one with the longest ruby experience and amount of
red books on this language. I would be glad to support you both in
making the R in programR as big as possible!!! (now is a bit to C
(loris) or Java (mauro))

Ciao,
Mauro
> 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
> >
> >
>
> _______________________________________________
> Aiml-programr-developers mailing list
> Aiml-programr-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>