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

Sun Sep 9 06:28:55 EDT 2007

Guys,

I'm emailing between talks at the UK Python conference, so this will be
quick. Expect a bigger email later today or start of next week with
various diagrams and pseudo code for the graphmaster.

Put simply, I agree with all the points you make Mauro. Just to clarify
specifics:

* Test suite: the ProgramD tests are probably the best place to start.
I've just been in a Python talk about crafting and writing a test suite
that reflects a concrete specification so will use the good advice I got
in there to start this task. I agree with you Mauro, it woudl be a good
community resource to provide this.

* Rake: IIRC, apart from on Debian based distros (where Ruby is cut into
smaller packages) the Ruby package for Windows, Mac OSX and other
distros includes Rake. As we're a Ruby project we might as well use it
as we'll be certain it will be there (whereas shell script won't for
Windows users - assuming we still agree on cross-platform as a "feature").

* Rubyfy: The great thing about conferences is that O'Reilly always have
a stand with 33% discount. I'm going to have to confess that I've been
buying more Ruby than Python books :-)

Thanks for your comments about our imminent arrival. This is no.3 for us
so we almost know what we're doing. To be honest, the worst thing is the
waiting for Mary to "pop". The alleged due date is 19th Sept but (as I'm
sure you know) a baby can be full-term and arrive two weeks either side
of this date - and if this one is like our other two, it'll be a
fortnight late. :-( Interesting times ahead... :-)

Best wishes,

Nicholas

mauro at cicio.org wrote:
> 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
>>
>>     
>
>   