From bdminton at gmail.com  Sun Sep  2 18:06:45 2007
From: bdminton at gmail.com (Benjamin Minton)
Date: Mon, 3 Sep 2007 08:06:45 +1000
Subject: [Aiml-programr-developers] Test Message Mailing List
Message-ID: <d27b1ab40709021506u19aafb0bxdf5386b7e632aa6f@mail.gmail.com>

Test Message Mailing List

-- 
B.D.Minton
Brisbane QLD AU
bdminton at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/aiml-programr-developers/attachments/20070903/75e0ba6c/attachment.html 

From ntoll at ntoll.org  Sun Sep  2 18:30:02 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 02 Sep 2007 23:30:02 +0100
Subject: [Aiml-programr-developers] First post summary...
Message-ID: <46DB396A.5080402@ntoll.org>

For the sake of completeness, the following is a summary of Mauro's
suggestions for modus operandi and the next steps:

<quote>

I would like to rework with you the whole project, I think it would be
much more fun than fixing the old one. Still, it is nice to have
something that works to play with.

I think that we should then proceed as follows:
1 - we select a small set of classes we consider "central"
2 - we discuss and rework them
2.1 - If possible we do not break programR, but this is not a priority
3 - priority is to have Unit/Functional  tests for the central classes

After a while, the old classes will all be integrated/obsolete.

I think that as first step, this should do.
We can use Dia for UML, but in a typical TestDrivenDevelopment, the
test remain central, not the design.
A good candidate as "central class" is graph_master.

</quote>

I would like to add that I think we should also have a clear
specification of the processes we intend to implement through the use of
use-cases, stories and the more formal activity diagrams. Like Mauro
(see above), I think reworking the whole project rather than fixing the
old one will be more fun and give us more scope for changing and
re-designing (where necessary) the library.

Best wishes,

Nicholas

From mauro at cicio.org  Thu Sep  6 16:37:10 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Thu, 6 Sep 2007 22:37:10 +0200
Subject: [Aiml-programr-developers] test
Message-ID: <c12c9d2d0709061337w6a2e887arace7ae576b06f409@mail.gmail.com>

Hi All

From mauro at cicio.org  Fri Sep  7 02:56:43 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Fri, 7 Sep 2007 08:56:43 +0200
Subject: [Aiml-programr-developers] Home site
Message-ID: <c12c9d2d0709062356h737b920j5ec5aac795013374@mail.gmail.com>

Hi there,

I usually have a slight sense of frustration when I see a projects
that does not have it's hown home page to show. Since we have one, it
would be good to have it linked from rubyforge. I am used to
SourceForge, where you get a ssh access, but I don't know how to set
the home page in RubyForge.
Do you have any idea? the link is:

 http://projects.dottorsi.com/programr

Ciao,
Mauro

From mauro at cicio.org  Fri Sep  7 04:00:08 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Fri, 7 Sep 2007 10:00:08 +0200
Subject: [Aiml-programr-developers] Items for the next release
Message-ID: <c12c9d2d0709070100o5e56afe0g1d5fdfbca848af2c@mail.gmail.com>

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

From ntoll at ntoll.org  Fri Sep  7 18:14:47 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Fri, 07 Sep 2007 23:14:47 +0100
Subject: [Aiml-programr-developers] Items for the next release
In-Reply-To: <c12c9d2d0709070100o5e56afe0g1d5fdfbca848af2c@mail.gmail.com>
References: <c12c9d2d0709070100o5e56afe0g1d5fdfbca848af2c@mail.gmail.com>
Message-ID: <46E1CD57.6000904@ntoll.org>

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
>
>   


From ntoll at ntoll.org  Fri Sep  7 18:21:15 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Fri, 07 Sep 2007 23:21:15 +0100
Subject: [Aiml-programr-developers] Home site
In-Reply-To: <c12c9d2d0709062356h737b920j5ec5aac795013374@mail.gmail.com>
References: <c12c9d2d0709062356h737b920j5ec5aac795013374@mail.gmail.com>
Message-ID: <46E1CEDB.2030004@ntoll.org>

Mauro,

Hmm... when you set up the project did you not get information regarding
access to web space at ruby-forge (according to the admin page it should
be in the */var/www/gforge-projects/aiml-programr directory).
Alternatively you can select the "Edit Public Info" link under the admin
tab and change the homepage URL. I'll leave it up to you to decide where
this should point. :-)

Nicholas
*
mauro at cicio.org wrote:
> Hi there,
>
> I usually have a slight sense of frustration when I see a projects
> that does not have it's hown home page to show. Since we have one, it
> would be good to have it linked from rubyforge. I am used to
> SourceForge, where you get a ssh access, but I don't know how to set
> the home page in RubyForge.
> Do you have any idea? the link is:
>
>  http://projects.dottorsi.com/programr
>
> Ciao,
> Mauro
> _______________________________________________
> Aiml-programr-developers mailing list
> Aiml-programr-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>
>   


From bdminton at gmail.com  Fri Sep  7 21:20:53 2007
From: bdminton at gmail.com (Benjamin Minton)
Date: Sat, 8 Sep 2007 11:20:53 +1000
Subject: [Aiml-programr-developers] Thoughts on programR AIML ver 1.0
Message-ID: <d27b1ab40709071820oda67a6dl33f4f115fc67ac03@mail.gmail.com>

High level diagramme:

Nick, when you get a chance can you please send me a copy of the diagrammee
as I would like to read through it and start to get a handle on the programR
work-flow process. Just confirm that you are using the Gnome package Dia for
these UML images.

Once I get a solid understanding of this, I could author a complete, precise
and complex document detailing exactly how this process occurs. The I will
make a simpler version to be included as part of the Userspace Tools &
Documents.

Tests:

I agree with this, on the concepts of good projects is good user
documentation and tests. There are many test models that we can use from the
Ruby codespace and in particular Ruby on Rails. I was wondering if we could
make programR into a Rails application also or just leave it as a standalone
package depedndent on the Ruby Librabries or even both..

Rake:

I like the concept of automation, certainly for testing/deployment but
recognise the value of developing a dual user fork, one for developers and
the other for users. As far as an interface, if we just code a GUI based on
another common well-supported Open Source library (Tcl/TK) that should allow
maximum cross system interoperability. I know that none of us like WIN
software but we will need to code for it in some capacity I think. Or
alternately, ProgramR is only going to be an application served by a
webserver. I think this is one of those key geography questions that you are
asking Nick. Maybe both then, a simple standalone version with all enclosed
libraries, documentation, tests etc that can run standalone and a full
developers version that runs via Apache or a Rails application.

Organisation:

I'd be happy to start write user Documentation, deployment instructions onto
*nix based systems, with perhaps a focus on Debian-based distributions. I
already have a monster HOWTO on installing/configuring RadiantCMS/Rails onto
a Debian Etch Server. Could also migrate that rather easily into an Ubuntu
specific HOWTO also.

I'd also be happy to run/report all tests as they get built and configure
some sort of benchmarking programme to report of direct shell enquiries to
the interpreter and via an interface (webserver/standalone).

Comments welcome!

Nick: congratulations on the impending child ... awesome!

Regards, Ben.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/aiml-programr-developers/attachments/20070908/4c60a4f0/attachment-0001.html 

From ntoll at ntoll.org  Sat Sep  8 01:52:15 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sat, 08 Sep 2007 06:52:15 +0100
Subject: [Aiml-programr-developers] Thoughts on programR AIML ver 1.0
In-Reply-To: <d27b1ab40709071820oda67a6dl33f4f115fc67ac03@mail.gmail.com>
References: <d27b1ab40709071820oda67a6dl33f4f115fc67ac03@mail.gmail.com>
Message-ID: <46E2388F.60209@ntoll.org>

Just a quick note,

Yes, I'm using Dia for UML diagrams. I'll probably embed them into an
OOo doc - in fact I'll add the files to subversion.

Speak to you soon,

Nicholas

Benjamin Minton wrote:
> High level diagramme:
>
> Nick, when you get a chance can you please send me a copy of the
> diagrammee as I would like to read through it and start to get a
> handle on the programR work-flow process. Just confirm that you are
> using the Gnome package Dia for these UML images.
>
> Once I get a solid understanding of this, I could author a complete,
> precise and complex document detailing exactly how this process
> occurs. The I will make a simpler version to be included as part of
> the Userspace Tools & Documents.
>
> Tests:
>
> I agree with this, on the concepts of good projects is good user
> documentation and tests. There are many test models that we can use
> from the Ruby codespace and in particular Ruby on Rails. I was
> wondering if we could make programR into a Rails application also or
> just leave it as a standalone package depedndent on the Ruby
> Librabries or even both..
>
> Rake:
>
> I like the concept of automation, certainly for testing/deployment but
> recognise the value of developing a dual user fork, one for developers
> and the other for users. As far as an interface, if we just code a GUI
> based on another common well-supported Open Source library (Tcl/TK)
> that should allow maximum cross system interoperability. I know that
> none of us like WIN software but we will need to code for it in some
> capacity I think. Or alternately, ProgramR is only going to be an
> application served by a webserver. I think this is one of those key
> geography questions that you are asking Nick. Maybe both then, a
> simple standalone version with all enclosed libraries, documentation,
> tests etc that can run standalone and a full developers version that
> runs via Apache or a Rails application.
>
> Organisation:
>
> I'd be happy to start write user Documentation, deployment
> instructions onto *nix based systems, with perhaps a focus on
> Debian-based distributions. I already have a monster HOWTO on
> installing/configuring RadiantCMS/Rails onto a Debian Etch Server.
> Could also migrate that rather easily into an Ubuntu specific HOWTO also.
>
> I'd also be happy to run/report all tests as they get built and
> configure some sort of benchmarking programme to report of direct
> shell enquiries to the interpreter and via an interface
> (webserver/standalone).
>
> Comments welcome!
>
> Nick: congratulations on the impending child ... awesome!
>
> Regards, Ben.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Aiml-programr-developers mailing list
> Aiml-programr-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>   


From bdminton at gmail.com  Sun Sep  9 01:30:36 2007
From: bdminton at gmail.com (Benjamin Minton)
Date: Sun, 9 Sep 2007 15:30:36 +1000
Subject: [Aiml-programr-developers] Test Email Only
Message-ID: <d27b1ab40709082230i205d8757m2a466e91f4e1b673@mail.gmail.com>

Test Email Only
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/aiml-programr-developers/attachments/20070909/bd87d561/attachment.html 

From ntoll at ntoll.org  Sun Sep  9 03:46:55 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 09 Sep 2007 08:46:55 +0100
Subject: [Aiml-programr-developers] e-mail problems?
In-Reply-To: <c12c9d2d0709081449r3387c6bpb3f4a4c62aaa816a@mail.gmail.com>
References: <c12c9d2d0709081449r3387c6bpb3f4a4c62aaa816a@mail.gmail.com>
Message-ID: <46E3A4EF.7040804@ntoll.org>

Yeah,

I sent on yesterday (8th Sept) and a couple the day before. I've also
cc'd the list with this email. Hope it gets through.

Nicholas

mauro at cicio.org wrote:
> Hi,
>
> I am not receiving mails from anybody. Have you sent anything to our
> programR in the last 3 days?
>
> Ciao,
> Mauro
>
>   


From mauro at cicio.org  Sun Sep  9 05:08:26 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Sun, 9 Sep 2007 11:08:26 +0200
Subject: [Aiml-programr-developers] Items for the next release
In-Reply-To: <46E1CD57.6000904@ntoll.org>
References: <c12c9d2d0709070100o5e56afe0g1d5fdfbca848af2c@mail.gmail.com>
	<46E1CD57.6000904@ntoll.org>
Message-ID: <c12c9d2d0709090208i2883d502oe88982a9f9d61967@mail.gmail.com>

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
>

From ntoll at ntoll.org  Sun Sep  9 06:28:55 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sun, 09 Sep 2007 11:28:55 +0100
Subject: [Aiml-programr-developers] Items for the next release
In-Reply-To: <c12c9d2d0709090208i2883d502oe88982a9f9d61967@mail.gmail.com>
References: <c12c9d2d0709070100o5e56afe0g1d5fdfbca848af2c@mail.gmail.com>	
	<46E1CD57.6000904@ntoll.org>
	<c12c9d2d0709090208i2883d502oe88982a9f9d61967@mail.gmail.com>
Message-ID: <46E3CAE7.4090009@ntoll.org>

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
>>
>>     
>
>   


From mauro at cicio.org  Sun Sep  9 08:38:02 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Sun, 9 Sep 2007 14:38:02 +0200
Subject: [Aiml-programr-developers] Thoughts on programR AIML ver 1.0
In-Reply-To: <d27b1ab40709071820oda67a6dl33f4f115fc67ac03@mail.gmail.com>
References: <d27b1ab40709071820oda67a6dl33f4f115fc67ac03@mail.gmail.com>
Message-ID: <c12c9d2d0709090538m63fbe6c8sd04f78f12e5be990@mail.gmail.com>

Hi,

I am trying to catchup with the mails I missed in the last days...
This answers Ben's one.

> Nick, when you get a chance can you please send me a copy of the diagrammee
> as I would like to read through it and start to get a handle on the programR
> work-flow process. Just confirm that you are using the Gnome package Dia for
> these UML images.


Right. I myself always used Dia, so I am happy with it. I believe that
in the meantime something else is out there for Ruby... is it true? I
remeber a few years ago I patched a ruby/dia module written by a
Russian guy (direct engeenirig). Is there anything for reverse
engeeniring? Not urgent at all, just curious. For programR, we can
live happly with DIaUml.

> Once I get a solid understanding of this, I could author a complete, precise
> and complex document detailing exactly how this process occurs.

Cool!

> The I will
> make a simpler version to be included as part of the Userspace Tools &
> Documents.

Even cooler!

> Tests:
>
> I agree with this, on the concepts of good projects is good user
> documentation and tests. There are many test models that we can use from the
> Ruby codespace and in particular Ruby on Rails. I was wondering if we could
> make programR into a Rails application also or just leave it as a standalone
> package depedndent on the Ruby Librabries or even both..

At the moment I am completely in the RoR world, so I defenitevily
would like to have programR as RoR plugin.
Considering that I am not interested in the Tk interface, I think we
can already have some assignments done :-)
Anyhow: we should look at the specification to:
- build a gem
- create a plugin
and based on those use a compatible dir structure.
Very likely the current one is already OK (almost).
I can take care of this aspects if you are not in a hurry to do it yourselves...
I created a couple of tasks and put myself as assignee, but I can
change this of course.
As soon as we have a clear idea on the list of tests, we can probably
put them in the task list as well, as single tasks. It can be a way to
help programR as soon as we have 30minutes: program a small test and
close a task.

> Rake:
>
> I like the concept of automation, certainly for testing/deployment but
> recognise the value of developing a dual user fork, one for developers and
> the other for users. As far as an interface, if we just code a GUI based on
> another common well-supported Open Source library (Tcl/TK) that should allow
> maximum cross system interoperability. I know that none of us like WIN
> software but we will need to code for it in some capacity I think. Or
> alternately, ProgramR is only going to be an application served by a
> webserver. I think this is one of those key geography questions that you are
> asking Nick. Maybe both then, a simple standalone version with all enclosed
> libraries, documentation, tests etc that can run standalone and a full
> developers version that runs via Apache or a Rails application.

I see programR as a library, but it should be more (it is not libraryR
after all :-))
I like the idea of the RoR plugin. Is anybody signing in for a Tk (or
similar) interface? I would just then different downloads: library
only, library+GUI, RoRplugin.

> Organisation:
>
> I'd be happy to start write user Documentation, deployment instructions onto
> *nix based systems, with perhaps a focus on Debian-based distributions. I
> already have a monster HOWTO on installing/configuring RadiantCMS/Rails onto
> a Debian Etch Server. Could also migrate that rather easily into an Ubuntu
> specific HOWTO also.
> I'd also be happy to run/report all tests as they get built and configure
> some sort of benchmarking programme to report of direct shell enquiries to
> the interpreter and via an interface (webserver/standalone).

Fine, it seems a lot of valuable work to be done.

Ciao,
Mauro

From ntoll at ntoll.org  Mon Sep 10 16:28:34 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 10 Sep 2007 21:28:34 +0100
Subject: [Aiml-programr-developers] Activity diagram,
	explanation of the Graphmaster etc... (long email)
Message-ID: <46E5A8F2.4020407@ntoll.org>

Guys,

As promised, I've included images (and source there-of) as attachments
to this email.

I strongly suggest you read the "formal" AIML specification found here:
http://www.alicebot.org/TR/2001/WD-aiml/

Once you've digested and understood this document then you've pretty
much got all the information you need and we will only (only?) have to
worry about implementation of the standard. The summary I've written
below is to be read as well as the standard and I hope it gives either a
good introduction before reading the standard or clarifies things.

Activity Diagram for a Request
---------------------------------------------------

(BotLifecycle.* - UML on the left, example text on right)

There are three broad steps in the life-cycle of a request to an AIML bot:

1. Normalization - prepare the raw input into a path to be fed into the
Graphmaster.
2. Query the Graphmaster - search for a <template> using the normalized
path as input.
3. Interpret / return the contents of the resulting <template> - output
something coherent and update any data-stores.

It is important to note that the Normalization process is very
English-centric. I'm assuming that different languages would be
best-normalized in different ways. As a result, it would be great if we
could implement the normalization process as some sort of work-flow
where steps could be re-arranged, added, removed and modified to the
requirements of the language of the bot (for example, certain languages
[such as French or German] might normalise by replacing accented
characters with their unaccented version). An additional consideration
is string encoding. Mauro: how good is Ruby's UTF16 support? It'd be
great if Ruby had something as simple as u"My UTF encoded string in
Python (notice the leading u)" to denote a UTF encoded string. I seem to
remember UTF support was a problem/pretty poor?

The querying of the graphmaster is explained below so I'll skip it here.
Suffice to say that this is one of the cleverest parts of the bot AND I
think the bog-standard graphmaster algorithm could be improved by making
it more capable (but I think we should concentrate on getting the plain
ol' graphmaster working properly before adding "features").

The interpretation of the XML contained within the <template> tag is
also clever but very easy to unit test as the specification is very
clear about how the tags are to work. As an aside... we can use the
<script> AIML tag to embed Ruby code into the <template> to be
interpreted at run-time. Cool eh?

Graphmaster
----------------------

(Graphmaster.* files [created with graphviz])

First of all, take a look at the picture.

Now, I did write a long and complicated explanation of the graphmaster
at this point. But when I checked it against the description in the AIML
standards document I discovered my version was so long and the standard
was so well written that I suggest you just skip to:
http://www.alicebot.org/TR/2001/WD-aiml/#section-pattern-expression-matching-behavior

It would be a good exercise to try to follow the route of the paths in
the picture of the simple graphmaster I've attached:

"Hello Mauro <that> * <topic> *"
"Hello Ben <that> Hi ALICE <topic> *"
"What is your favourite file <that> * <topic> *"
"I live in Italy <that> * <topic> *"

(Hint, the first two match the same route).

Put simply:

* Order of precedence is: "_", "word", "*".
* Match a route of child nodes (starting at root) until a <template> is
found (hint: you'll always find the path "* <that> * <topic> *").
* Interpret and pass back the template.

I'll write up the pseudo-code of Program#'s implementation (encapsulated
within the Node.cs class) in a later email (otherwise this email will go
on for pages).

Also, I'm planning the tests for ProgramR. I'll put my thoughts in
another email - again, so I don't end up clogging the list with emails
longer than "War and Peace" :-)

As always, comments, suggestions and criticism are most welcome, :-P

Best wishes,

Nicholas




 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: BotLifecycle.dia
Type: application/x-dia-diagram
Size: 2332 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/aiml-programr-developers/attachments/20070910/6931aa28/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BotLifecycle.jpeg
Type: image/jpeg
Size: 55020 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/aiml-programr-developers/attachments/20070910/6931aa28/attachment-0001.jpeg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Graphmaster.dot
Type: application/msword
Size: 2134 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/aiml-programr-developers/attachments/20070910/6931aa28/attachment-0001.dot 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Graphmaster.gif
Type: image/gif
Size: 22773 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/aiml-programr-developers/attachments/20070910/6931aa28/attachment-0001.gif 

From mauro at cicio.org  Tue Sep 11 02:42:45 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Tue, 11 Sep 2007 08:42:45 +0200
Subject: [Aiml-programr-developers] Activity diagram,
	explanation of the Graphmaster etc... (long email)
In-Reply-To: <46E5A8F2.4020407@ntoll.org>
References: <46E5A8F2.4020407@ntoll.org>
Message-ID: <c12c9d2d0709102342k7c178fa4uae4b145a0d3561be@mail.gmail.com>

Hi there,

Great work, I thinks it sums up pretty well and briefly the great
amount of docs of the ALICE group. I strongly suggest that you resist
the temptation to rewrite it all!!! ;-)
Of course the current version of pR is based on the same docs and the
same readings, so it _should_ work all right. Why "should" and not
"does"? Because it is very likely that in the hurry to have something
working for Tiresia, things became less and less AIML specification
compliant.

Programming is fun, so the sooner we start coding, the better.
A good test suite frees us from the need of a precise design.
Of course we should have a fairly good idea of what we want to do, but
I believe this is already there for the three of us.
If you think so to, we should find the quickest path to the coding :-)

My suggestion follows.

As you know, Ruby has a "duck typing": if you behave like a duck, you
are a duck!
If pR behaves like an AIML bot, than it is an AIML bot.
What I want to say with this?
One interesting, and fun, way to proceed is to look for tests that pR
doesn't pass and fix pR. When pR passes all the tests, we are done,
regardless how the internal are implemented (we have the duck!).

Of course though the process of *continous refactoring*, the internals
will also get better and better, and so the design.

Where to start from?

The following tags are said
(http://projects.dottorsi.com/ki/programr/pages/Features)
to be supported in pR and there ***should be tests proving it as well***...
        <category>
        <pattern>
        <template>
        <srai>
        <that>
        <uppercase>
        <system>
        <lowercase>
        <date>
        <size>
        <bot name="name"> (see notes)
        <get>
        <set>
        <think>
        <condition>
        <formal>
        <sentence>
        <random>
        <input>
        <gender>
        <star>
        <thatstar>
        <sr>
        <topic>
        <topicstar>
        <person>
        <person2>

Question: Is this true? Or are the tests too benevolent? How far is
this list from the complete one?

In this sense I believe that the most urgent thing to do is to design
and extend the test list.
Ideally, we want to have the list of tests in the task list and mark
them as done only when pR passes them.
"1 test = 1 task" is a nice way to split the work: anytime we have 30
minuets/1h, we just implement 1 or more tests. They are small enough
units in most cases.
Do you guys agree with the approach?

A question, Nicholas: would it make sense, as a start, just to dump
the list of tests of ProgramD?
What we need is not (necessary) the code, but, for each test:
- TestName
- Challange
- ExpectedReaction

If the ProgramD test suite is complete, than it would give us a great start.
If not, then let's begin with what we have...

In my experience, it has been much easier to go through the ALICE docs
while doing the tests (but I have implemented the first 10 or so
only).

UTF16 and Ruby: not a great thing, you are right.
You found a couple of my recipes on Ruby Cookbook
http://books.google.com/books?id=ANP-fUv3WTYC&dq=ruby+cookbook&pg=PP1&ots=FRREb0KCAR&sig=KOl8HuEws0Pgk8mShEDtwNABe3w&prev=http://www.google.com/search%3Fhl%3Den%26rls%3DGGGL,GGGL:2006-46,GGGL:en%26pwst%3D1%26sa%3DX%26oi%3Dspell%26resnum%3D0%26ct%3Dresult%26cd%3D1%26q%3Druby%2Bcookbook%26spell%3D1&sa=X&oi=print&ct=title
about it, but I am not sure there are gonna help...
I would rather work on the English version first, keeping in mind the
necessity to have modules which must be easy to rearrange (consider
that Tiresia is a project mainly for the Italian language!!!).

I look forward for your answer hoping to begin to code as soon as possible :-)

Ciao,
Mauro

On 10/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Guys,
>
> As promised, I've included images (and source there-of) as attachments
> to this email.
>
> I strongly suggest you read the "formal" AIML specification found here:
> http://www.alicebot.org/TR/2001/WD-aiml/
>
> Once you've digested and understood this document then you've pretty
> much got all the information you need and we will only (only?) have to
> worry about implementation of the standard. The summary I've written
> below is to be read as well as the standard and I hope it gives either a
> good introduction before reading the standard or clarifies things.
>
> Activity Diagram for a Request
> ---------------------------------------------------
>
> (BotLifecycle.* - UML on the left, example text on right)
>
> There are three broad steps in the life-cycle of a request to an AIML bot:
>
> 1. Normalization - prepare the raw input into a path to be fed into the
> Graphmaster.
> 2. Query the Graphmaster - search for a <template> using the normalized
> path as input.
> 3. Interpret / return the contents of the resulting <template> - output
> something coherent and update any data-stores.
>
> It is important to note that the Normalization process is very
> English-centric. I'm assuming that different languages would be
> best-normalized in different ways. As a result, it would be great if we
> could implement the normalization process as some sort of work-flow
> where steps could be re-arranged, added, removed and modified to the
> requirements of the language of the bot (for example, certain languages
> [such as French or German] might normalise by replacing accented
> characters with their unaccented version). An additional consideration
> is string encoding. Mauro: how good is Ruby's UTF16 support? It'd be
> great if Ruby had something as simple as u"My UTF encoded string in
> Python (notice the leading u)" to denote a UTF encoded string. I seem to
> remember UTF support was a problem/pretty poor?
>
> The querying of the graphmaster is explained below so I'll skip it here.
> Suffice to say that this is one of the cleverest parts of the bot AND I
> think the bog-standard graphmaster algorithm could be improved by making
> it more capable (but I think we should concentrate on getting the plain
> ol' graphmaster working properly before adding "features").
>
> The interpretation of the XML contained within the <template> tag is
> also clever but very easy to unit test as the specification is very
> clear about how the tags are to work. As an aside... we can use the
> <script> AIML tag to embed Ruby code into the <template> to be
> interpreted at run-time. Cool eh?
>
> Graphmaster
> ----------------------
>
> (Graphmaster.* files [created with graphviz])
>
> First of all, take a look at the picture.
>
> Now, I did write a long and complicated explanation of the graphmaster
> at this point. But when I checked it against the description in the AIML
> standards document I discovered my version was so long and the standard
> was so well written that I suggest you just skip to:
> http://www.alicebot.org/TR/2001/WD-aiml/#section-pattern-expression-matching-behavior
>
> It would be a good exercise to try to follow the route of the paths in
> the picture of the simple graphmaster I've attached:
>
> "Hello Mauro <that> * <topic> *"
> "Hello Ben <that> Hi ALICE <topic> *"
> "What is your favourite file <that> * <topic> *"
> "I live in Italy <that> * <topic> *"
>
> (Hint, the first two match the same route).
>
> Put simply:
>
> * Order of precedence is: "_", "word", "*".
> * Match a route of child nodes (starting at root) until a <template> is
> found (hint: you'll always find the path "* <that> * <topic> *").
> * Interpret and pass back the template.
>
> I'll write up the pseudo-code of Program#'s implementation (encapsulated
> within the Node.cs class) in a later email (otherwise this email will go
> on for pages).
>
> Also, I'm planning the tests for ProgramR. I'll put my thoughts in
> another email - again, so I don't end up clogging the list with emails
> longer than "War and Peace" :-)
>
> As always, comments, suggestions and criticism are most welcome, :-P
>
> Best wishes,
>
> Nicholas
>
>
>
>
>
>
>
> _______________________________________________
> Aiml-programr-developers mailing list
> Aiml-programr-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>
>
>

From ntoll at ntoll.org  Wed Sep 12 11:55:35 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Wed, 12 Sep 2007 16:55:35 +0100
Subject: [Aiml-programr-developers] Tests and Architecture
Message-ID: <46E80BF7.4010604@ntoll.org>

Guys,

What follows is a summary of my thoughts on testing prior to sitting 
down and writing them.

We're writing a library and as a result I'll define two sets of tests:

* UAT - that define the expected behaviour of the classes that we expect 
other developers to have to use to write their applications
* Unit Tests - that additionally encompass the expected behaviour of the 
wider classes / methods / areas of the library that we hope other 
developers will not have to use.

As a result I'll do two things:

1. Specify our "public" classes that third party developers should use 
to implement our library by means of example "use" cases written in code
2. Define the architecture behind these public classes so we can start 
to write unit tests.

It is important to remember that I intend to unit test as locally to the 
implementation of a method / class as possible. By this I mean that 
there will not be any tests against the high-level "bot" class for the 
"lower level" functionality of interpreting AIML tags (I'll test this 
against the appropriate class(es)).

So onto some example use cases (I'll formalise these into proper Ruby 
unit tests - the purpose of this email is to make public my testing 
strategy so you guys can shout if you disagree and we can then modify as 
needs be)...

I imagine a developer using our library should only have to deal with 
five classes:

1. Bot - that encapsulates an instance of a particular bot.
2. User - that encapsulates all the information about a particular user 
who is interacting with a "Bot"
3. Conversation - encapsulates and exchange between a particular "User" 
and a "Bot"
4. Request - encapsulates an single item of raw input from a "User" to a 
"Bot" as part of a "Conversation"
5 Response - encapsulates an item of output from a "Bot" to a "User" as 
part of a "Conversation".

If I were to make a comparison with web-development our classes would 
map like this:

Bot -> Website
User -> Client
Conversation -> Session
Request -> HTTP Request
Response -> HTML served back

I've done this on purpose as we intend to target Ruby on Rails as a 
potential platform. We could also piggy back on-top of other ruby 
enabled web technology (lighttp, apache etc) to provide a Bot server. 
Having such an easy mapping from the world of www to bots will make this 
simpler to carry out and easier for others to understand.

I'll UMLify these relationships when I get some time later this week.

Now onto a quick example of how I hope a developer might use these 
classes, an improvisation in Ruby :-)

<code>

myBot = Bot.new() # for default settings or:
myBot = Bot.new(path) # where path is to a config.yaml file setting up 
the bot to non default settings
myBot.ToYAML # bot's predicate list as YAML

# Attributes might include
myBot.Name # name of the bot
myBot.Botmaster # who the bot-master is
myBot.Size # number of categories in the graphmaster

# loading AIML
myBot.Learn(SomeRawAIML) # well formed obviously
myBot.Load("pathToAIMLFile(s)") # if an individual AIML file is 
specified the file is loaded, if a directory all AIML files within it.

# User class:

myUser = User.new("Unique id") # where Unique id might be something like 
a PK in a database so information can be retrieved.
myUser = User.new("Unique id", userconfig.yaml) # as above but with some 
yaml passed that includes user predicate table and / or conversation history
myUser["Name"] # how to reference the user's predicates
myUser.Conversations[0] # most recent conversation
myUser.ToYAML # predicate list etc as YAML

# Conversation:

c = Conversation.new(myUser, myBot) # create a new conversation session 
with the specified user and bot
c.Request[0] # the first thing said to the bot in this conversation
c.Response[0] # the first thing said to the user
c.StartedOn # Timestamp
c.TimeOut # a session timeout setting (any activity after this mount of 
time results in the session closing)
c.Close # close the session
c.Open # re-open a session
c.Open? # is the session open?

# Request
req = Request.new("Some raw input") # ctor
req.StartedOn # timestamp
req.Response # either nil or the response object that was returned
req.User # who made the request (or nil)
req.Bot # "who" made the response (or nil)
req.Conversation # the session context for the request (or nil)

# Response
res = Response.new(req) # ctor
res.to_s # the output from the bot
res.FinishedOn # Timestamp. res.FinishedOn - req.StartedOn = Duration of 
the request
res.Sentences[0] # First sentence of a multi-sentence response
res.User # User for whom the response is for
res.Bot # the Bot who created the response
res.Converstaion # the session context for the response

# sample session

myBot = Bot.new("config.yaml")

myUser = User.new("Default",someconfigYAML)

c = Conversation.new(myUser, myBot)

req = Request.new("Hi there!")
response = c.Speak(req)

return response.to_s
</code>

Nota Bene, the above code examples are off the top of my head and I'm 
not sure how Rubyesque they are... Comments and suggestions would be 
most welcome. :-)

Best wishes,

Nicholas

From mauro at cicio.org  Sat Sep 15 10:52:16 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Sat, 15 Sep 2007 16:52:16 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46E80BF7.4010604@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
Message-ID: <c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>

Hi,

Nicholas: thanks for the long mail!

Sorry for not answering as it deserves I am very busy at the moment.
This is just an ack to say that I am receiving and reading.

Just   a short note on the notation:
Bot -> Website
User -> Client
Conversation -> Session
Request -> HTTP Request
Response -> HTML served back

Is probably more precise to say:

Bot -> Webservice (which is what we can use to wrap pR)
User -> Webapplication
Conversation -> Session
Request -> HTTP Request
Response -> HTTP Response

The  Webapplication is a proxy for the WebClient (EndUser) and it can
be a Rails application or something like that.

I'll write more tomorrow I hope,

Ciao,
Mauro

On 12/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Guys,
>
> What follows is a summary of my thoughts on testing prior to sitting
> down and writing them.
>
> We're writing a library and as a result I'll define two sets of tests:
>
> * UAT - that define the expected behaviour of the classes that we expect
> other developers to have to use to write their applications
> * Unit Tests - that additionally encompass the expected behaviour of the
> wider classes / methods / areas of the library that we hope other
> developers will not have to use.
>
> As a result I'll do two things:
>
> 1. Specify our "public" classes that third party developers should use
> to implement our library by means of example "use" cases written in code
> 2. Define the architecture behind these public classes so we can start
> to write unit tests.
>
> It is important to remember that I intend to unit test as locally to the
> implementation of a method / class as possible. By this I mean that
> there will not be any tests against the high-level "bot" class for the
> "lower level" functionality of interpreting AIML tags (I'll test this
> against the appropriate class(es)).
>
> So onto some example use cases (I'll formalise these into proper Ruby
> unit tests - the purpose of this email is to make public my testing
> strategy so you guys can shout if you disagree and we can then modify as
> needs be)...
>
> I imagine a developer using our library should only have to deal with
> five classes:
>
> 1. Bot - that encapsulates an instance of a particular bot.
> 2. User - that encapsulates all the information about a particular user
> who is interacting with a "Bot"
> 3. Conversation - encapsulates and exchange between a particular "User"
> and a "Bot"
> 4. Request - encapsulates an single item of raw input from a "User" to a
> "Bot" as part of a "Conversation"
> 5 Response - encapsulates an item of output from a "Bot" to a "User" as
> part of a "Conversation".
>
> If I were to make a comparison with web-development our classes would
> map like this:
>
> Bot -> Website
> User -> Client
> Conversation -> Session
> Request -> HTTP Request
> Response -> HTML served back
>
> I've done this on purpose as we intend to target Ruby on Rails as a
> potential platform. We could also piggy back on-top of other ruby
> enabled web technology (lighttp, apache etc) to provide a Bot server.
> Having such an easy mapping from the world of www to bots will make this
> simpler to carry out and easier for others to understand.
>
> I'll UMLify these relationships when I get some time later this week.
>
> Now onto a quick example of how I hope a developer might use these
> classes, an improvisation in Ruby :-)
>
> <code>
>
> myBot = Bot.new() # for default settings or:
> myBot = Bot.new(path) # where path is to a config.yaml file setting up
> the bot to non default settings
> myBot.ToYAML # bot's predicate list as YAML
>
> # Attributes might include
> myBot.Name # name of the bot
> myBot.Botmaster # who the bot-master is
> myBot.Size # number of categories in the graphmaster
>
> # loading AIML
> myBot.Learn(SomeRawAIML) # well formed obviously
> myBot.Load("pathToAIMLFile(s)") # if an individual AIML file is
> specified the file is loaded, if a directory all AIML files within it.
>
> # User class:
>
> myUser = User.new("Unique id") # where Unique id might be something like
> a PK in a database so information can be retrieved.
> myUser = User.new("Unique id", userconfig.yaml) # as above but with some
> yaml passed that includes user predicate table and / or conversation history
> myUser["Name"] # how to reference the user's predicates
> myUser.Conversations[0] # most recent conversation
> myUser.ToYAML # predicate list etc as YAML
>
> # Conversation:
>
> c = Conversation.new(myUser, myBot) # create a new conversation session
> with the specified user and bot
> c.Request[0] # the first thing said to the bot in this conversation
> c.Response[0] # the first thing said to the user
> c.StartedOn # Timestamp
> c.TimeOut # a session timeout setting (any activity after this mount of
> time results in the session closing)
> c.Close # close the session
> c.Open # re-open a session
> c.Open? # is the session open?
>
> # Request
> req = Request.new("Some raw input") # ctor
> req.StartedOn # timestamp
> req.Response # either nil or the response object that was returned
> req.User # who made the request (or nil)
> req.Bot # "who" made the response (or nil)
> req.Conversation # the session context for the request (or nil)
>
> # Response
> res = Response.new(req) # ctor
> res.to_s # the output from the bot
> res.FinishedOn # Timestamp. res.FinishedOn - req.StartedOn = Duration of
> the request
> res.Sentences[0] # First sentence of a multi-sentence response
> res.User # User for whom the response is for
> res.Bot # the Bot who created the response
> res.Converstaion # the session context for the response
>
> # sample session
>
> myBot = Bot.new("config.yaml")
>
> myUser = User.new("Default",someconfigYAML)
>
> c = Conversation.new(myUser, myBot)
>
> req = Request.new("Hi there!")
> response = c.Speak(req)
>
> return response.to_s
> </code>
>
> Nota Bene, the above code examples are off the top of my head and I'm
> not sure how Rubyesque they are... Comments and suggestions would be
> most welcome. :-)
>
> Best wishes,
>
> Nicholas
> _______________________________________________
> Aiml-programr-developers mailing list
> Aiml-programr-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>

From ntoll at ntoll.org  Sat Sep 15 18:07:27 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Sat, 15 Sep 2007 23:07:27 +0100
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
Message-ID: <46EC579F.1030408@ntoll.org>

Hi Mauro,

Thanks for the quick email, just so you know how my thoughts are moving...

Re notation: to clear up the web-development analogy I'll try and
explain how I see the concepts mapped between the two domains (bots ->
web). Obviously analogies of these sorts are very much subjective,
imprecise (that's why they're an analogy), open to (mis)-interpretation
and (most importantly) depend on how "abstract" the people doing the
analogy are willing to go.

Anyway, here goes and please feel free to shoot this all down in flames,
I have a tough skin and positively welcome people telling me that I'm
wrong. To be honest, if we're to make this project easy to understand
for others we definitely need to make sure we're clear about how we
explain, conceptualise and define how it works! :-) Once again, I'm
thinking out loud here...

Put simply, I reckon the "Bot" class is like an add-on module for Apache
or some other web-server (e.g. PHP, modPython or ASP.NET) - or that's
how it should appear to developers: a plug-in client/server architecture
for natural language. The AIML set is like the HTML (static or
dynamically created) served by Apache/{PHP, Python, ASP.NET etc}. We
agree that the concepts of session, http request and http response map
onto our own conversation, request and response. If I understand you
correctly, our concept of "user" means the same as a "user" of a web
application - an encapsulation of all the appropriate information about
*ME* identified by a unique id - e.g. the id ntoll is my username at
del.icio.us (you'll see I've been bookmarking lots about Rake :-)... and
del.icio.us also store my email, password, real-name, tags, bundles and
friends... etc... etc... as part of my "user" profile in much the same
way that a bot instance will have to store a user's predicate list.

If the above is the case then I think we agree! If not, it'll be
interesting to discover the differences, find the reasons behind the
differences and move forward to a consensus.

Also, as I pointed out in my first email in this thread, the Ruby I was
writing was (literally) made up on the spot. I'm painfully aware that I
speak Ruby with a heavy C like accent (specifically C# at the moment) so
any style guidance would be most welcome. Having re-read it I think I'd
change the sample session so that the Bot implemented a method called
something like ReplyTo:

req= Request.new("Hi there", c)
response = myBot.ReplyTo(req)

Where obviously, "c" is the conversation instance, "myBot" is a bot
instance and the user is referenced within "c". Actually, my wife has
just been looking over my shoulder as I write this. She wanted me to
explain what it meant :-). I explained the above two lines of code in
plain English as, "I want the computer to create a new request called
"req" that contains the words "Hi there" as part of a conversation
called "c". Now give me a response from "myBot" to the request called
"req" (and obviously "c" has a user associated with it so the software
knows who to deliver it to)".

Anyway, its late and I have an appointment in the gym at 8am tomorrow...
:-)

Looking forward to hearing from and discussing this with you,

Nicholas

mauro at cicio.org wrote:
> Hi,
>
> Nicholas: thanks for the long mail!
>
> Sorry for not answering as it deserves I am very busy at the moment.
> This is just an ack to say that I am receiving and reading.
>
> Just   a short note on the notation:
> Bot -> Website
> User -> Client
> Conversation -> Session
> Request -> HTTP Request
> Response -> HTML served back
>
> Is probably more precise to say:
>
> Bot -> Webservice (which is what we can use to wrap pR)
> User -> Webapplication
> Conversation -> Session
> Request -> HTTP Request
> Response -> HTTP Response
>
> The  Webapplication is a proxy for the WebClient (EndUser) and it can
> be a Rails application or something like that.
>
> I'll write more tomorrow I hope,
>
> Ciao,
> Mauro
>
> On 12/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
>   
>> Guys,
>>
>> What follows is a summary of my thoughts on testing prior to sitting
>> down and writing them.
>>
>> We're writing a library and as a result I'll define two sets of tests:
>>
>> * UAT - that define the expected behaviour of the classes that we expect
>> other developers to have to use to write their applications
>> * Unit Tests - that additionally encompass the expected behaviour of the
>> wider classes / methods / areas of the library that we hope other
>> developers will not have to use.
>>
>> As a result I'll do two things:
>>
>> 1. Specify our "public" classes that third party developers should use
>> to implement our library by means of example "use" cases written in code
>> 2. Define the architecture behind these public classes so we can start
>> to write unit tests.
>>
>> It is important to remember that I intend to unit test as locally to the
>> implementation of a method / class as possible. By this I mean that
>> there will not be any tests against the high-level "bot" class for the
>> "lower level" functionality of interpreting AIML tags (I'll test this
>> against the appropriate class(es)).
>>
>> So onto some example use cases (I'll formalise these into proper Ruby
>> unit tests - the purpose of this email is to make public my testing
>> strategy so you guys can shout if you disagree and we can then modify as
>> needs be)...
>>
>> I imagine a developer using our library should only have to deal with
>> five classes:
>>
>> 1. Bot - that encapsulates an instance of a particular bot.
>> 2. User - that encapsulates all the information about a particular user
>> who is interacting with a "Bot"
>> 3. Conversation - encapsulates and exchange between a particular "User"
>> and a "Bot"
>> 4. Request - encapsulates an single item of raw input from a "User" to a
>> "Bot" as part of a "Conversation"
>> 5 Response - encapsulates an item of output from a "Bot" to a "User" as
>> part of a "Conversation".
>>
>> If I were to make a comparison with web-development our classes would
>> map like this:
>>
>> Bot -> Website
>> User -> Client
>> Conversation -> Session
>> Request -> HTTP Request
>> Response -> HTML served back
>>
>> I've done this on purpose as we intend to target Ruby on Rails as a
>> potential platform. We could also piggy back on-top of other ruby
>> enabled web technology (lighttp, apache etc) to provide a Bot server.
>> Having such an easy mapping from the world of www to bots will make this
>> simpler to carry out and easier for others to understand.
>>
>> I'll UMLify these relationships when I get some time later this week.
>>
>> Now onto a quick example of how I hope a developer might use these
>> classes, an improvisation in Ruby :-)
>>
>> <code>
>>
>> myBot = Bot.new() # for default settings or:
>> myBot = Bot.new(path) # where path is to a config.yaml file setting up
>> the bot to non default settings
>> myBot.ToYAML # bot's predicate list as YAML
>>
>> # Attributes might include
>> myBot.Name # name of the bot
>> myBot.Botmaster # who the bot-master is
>> myBot.Size # number of categories in the graphmaster
>>
>> # loading AIML
>> myBot.Learn(SomeRawAIML) # well formed obviously
>> myBot.Load("pathToAIMLFile(s)") # if an individual AIML file is
>> specified the file is loaded, if a directory all AIML files within it.
>>
>> # User class:
>>
>> myUser = User.new("Unique id") # where Unique id might be something like
>> a PK in a database so information can be retrieved.
>> myUser = User.new("Unique id", userconfig.yaml) # as above but with some
>> yaml passed that includes user predicate table and / or conversation history
>> myUser["Name"] # how to reference the user's predicates
>> myUser.Conversations[0] # most recent conversation
>> myUser.ToYAML # predicate list etc as YAML
>>
>> # Conversation:
>>
>> c = Conversation.new(myUser, myBot) # create a new conversation session
>> with the specified user and bot
>> c.Request[0] # the first thing said to the bot in this conversation
>> c.Response[0] # the first thing said to the user
>> c.StartedOn # Timestamp
>> c.TimeOut # a session timeout setting (any activity after this mount of
>> time results in the session closing)
>> c.Close # close the session
>> c.Open # re-open a session
>> c.Open? # is the session open?
>>
>> # Request
>> req = Request.new("Some raw input") # ctor
>> req.StartedOn # timestamp
>> req.Response # either nil or the response object that was returned
>> req.User # who made the request (or nil)
>> req.Bot # "who" made the response (or nil)
>> req.Conversation # the session context for the request (or nil)
>>
>> # Response
>> res = Response.new(req) # ctor
>> res.to_s # the output from the bot
>> res.FinishedOn # Timestamp. res.FinishedOn - req.StartedOn = Duration of
>> the request
>> res.Sentences[0] # First sentence of a multi-sentence response
>> res.User # User for whom the response is for
>> res.Bot # the Bot who created the response
>> res.Converstaion # the session context for the response
>>
>> # sample session
>>
>> myBot = Bot.new("config.yaml")
>>
>> myUser = User.new("Default",someconfigYAML)
>>
>> c = Conversation.new(myUser, myBot)
>>
>> req = Request.new("Hi there!")
>> response = c.Speak(req)
>>
>> return response.to_s
>> </code>
>>
>> Nota Bene, the above code examples are off the top of my head and I'm
>> not sure how Rubyesque they are... Comments and suggestions would be
>> most welcome. :-)
>>
>> Best wishes,
>>
>> Nicholas
>> _______________________________________________
>> Aiml-programr-developers mailing list
>> Aiml-programr-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>>
>>     
>
>   


From mauro at cicio.org  Sun Sep 16 12:21:14 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Sun, 16 Sep 2007 18:21:14 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46EC579F.1030408@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
	<46EC579F.1030408@ntoll.org>
Message-ID: <c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>

Hi Nicholas,

As promised, here I am with a longer answer.

> Re notation: to clear up the web-development analogy I'll try and
> explain how I see the concepts mapped between the two domains (bots ->
> web). Obviously analogies of these sorts are very much subjective,
> imprecise (that's why they're an analogy), open to (mis)-interpretation
> and (most importantly) depend on how "abstract" the people doing the
> analogy are willing to go.

Metaphores are very important to understand software.
I strongly welcome your analogy Web/programR. It is easy to understand
and very useful even outside the rails pluging scope.

Here it is:
> Bot -> Website
> User -> Client
> Conversation -> Session
> Request -> HTTP Request
> Response -> HTML served back

What you want to say is pretty clear to me, because I know what pR should be.

The reason why I would like a different wording s is that I see the
corrispondence to be between "HTTP Request"  and "HTTP Response", not
"HTTP Request"  and "HTML served back".
Do you agree on this?
In  a less obvious way, I also have a problem with the term "Website".
The "Website" refers to the content (collection of webpages), not to
the engine (i.e  Apache+JBoss) producing the content.

I believe that there is no major difference between what you want to
say and the way I put it down. I just want to avoid a misleading mix
between the content and the elaboration of the content.

I hope to have managed to clarify my point of view.


> I have a tough skin and positively welcome people telling me that I'm
> wrong.

Me too. Good to know ;-)

>To be honest, if we're to make this project easy to understand
> for others we definitely need to make sure we're clear about how we
> explain, conceptualise and define how it works! :-) Once again, I'm
> thinking out loud here...

Absolutely clear your intent. Mine is the same.

> Put simply, I reckon the "Bot" class is like an add-on module for Apache
> or some other web-server (e.g. PHP, modPython or ASP.NET) - or that's
> how it should appear to developers: a plug-in client/server architecture
> for natural language.

I agree. This is way the
Bot -> Website
should be more
Bot -> Webservice
ore something more "engine" and less "content".

> The AIML set is like the HTML (static or
> dynamically created) served by Apache/{PHP, Python, ASP.NET etc}. We
.> [...]
>
> If the above is the case then I think we agree! If not, it'll be
> interesting to discover the differences, find the reasons behind the
> differences and move forward to a consensus.

I hope I managed to clarify my concern.

> Also, as I pointed out in my first email in this thread, the Ruby I was
> writing was (literally) made up on the spot. I'm painfully aware that I
> speak Ruby with a heavy C like accent (specifically C# at the moment) so
> any style guidance would be most welcome.

Fine! I am very much into this kind of things.

To get on a more concrete ground, I tried to put down a very small
(but running) prototype that could help us in discussing
- Ruby coding style
- Naming/Metaphores
- key concepts and separation of concerns

If you guys find the time to run the program, read it, ask questions
and so on, I think it would help a lot.

The prog structure is:
|-- browser.rb
|-- lib
|   |-- comm
|   |   |-- bot_proxy.rb
|   |   |-- p_r_plugin.rb
|   |   |-- request.rb
|   |   |-- response.rb
|   |   |-- service.rb
|   |   `-- session_manager.rb
|   |-- program_r
|   |   `-- bot.rb
|   `-- rails
|       `-- session.rb
`-- webserver.rb
To run it just open 2 shells. In the first one run
$ ruby webserver.rb
in the other one
$ ruby browser.rb
On the browser side you should see a prompt: enter a word and enter
(you'll get back the reversed word)
Prerequisites: 'drb' (is it in the distribution?)

In the meantime I'll keep reading/answering the last long and
important mail of Nicholas.

Ciao,
Mauro


> mauro at cicio.org wrote:
> > Hi,
> >
> > Nicholas: thanks for the long mail!
> >
> > Sorry for not answering as it deserves I am very busy at the moment.
> > This is just an ack to say that I am receiving and reading.
> >
> > Just   a short note on the notation:
> > Bot -> Website
> > User -> Client
> > Conversation -> Session
> > Request -> HTTP Request
> > Response -> HTML served back
> >
> > Is probably more precise to say:
> >
> > Bot -> Webservice (which is what we can use to wrap pR)
> > User -> Webapplication
> > Conversation -> Session
> > Request -> HTTP Request
> > Response -> HTTP Response
> >
> > The  Webapplication is a proxy for the WebClient (EndUser) and it can
> > be a Rails application or something like that.
> >
> > I'll write more tomorrow I hope,
> >
> > Ciao,
> > Mauro
> >
> > On 12/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> >
> >> Guys,
> >>
> >> What follows is a summary of my thoughts on testing prior to sitting
> >> down and writing them.
> >>
> >> We're writing a library and as a result I'll define two sets of tests:
> >>
> >> * UAT - that define the expected behaviour of the classes that we expect
> >> other developers to have to use to write their applications
> >> * Unit Tests - that additionally encompass the expected behaviour of the
> >> wider classes / methods / areas of the library that we hope other
> >> developers will not have to use.
> >>
> >> As a result I'll do two things:
> >>
> >> 1. Specify our "public" classes that third party developers should use
> >> to implement our library by means of example "use" cases written in code
> >> 2. Define the architecture behind these public classes so we can start
> >> to write unit tests.
> >>
> >> It is important to remember that I intend to unit test as locally to the
> >> implementation of a method / class as possible. By this I mean that
> >> there will not be any tests against the high-level "bot" class for the
> >> "lower level" functionality of interpreting AIML tags (I'll test this
> >> against the appropriate class(es)).
> >>
> >> So onto some example use cases (I'll formalise these into proper Ruby
> >> unit tests - the purpose of this email is to make public my testing
> >> strategy so you guys can shout if you disagree and we can then modify as
> >> needs be)...
> >>
> >> I imagine a developer using our library should only have to deal with
> >> five classes:
> >>
> >> 1. Bot - that encapsulates an instance of a particular bot.
> >> 2. User - that encapsulates all the information about a particular user
> >> who is interacting with a "Bot"
> >> 3. Conversation - encapsulates and exchange between a particular "User"
> >> and a "Bot"
> >> 4. Request - encapsulates an single item of raw input from a "User" to a
> >> "Bot" as part of a "Conversation"
> >> 5 Response - encapsulates an item of output from a "Bot" to a "User" as
> >> part of a "Conversation".
> >>
> >> If I were to make a comparison with web-development our classes would
> >> map like this:
> >>
> >> Bot -> Website
> >> User -> Client
> >> Conversation -> Session
> >> Request -> HTTP Request
> >> Response -> HTML served back
> >>
> >> I've done this on purpose as we intend to target Ruby on Rails as a
> >> potential platform. We could also piggy back on-top of other ruby
> >> enabled web technology (lighttp, apache etc) to provide a Bot server.
> >> Having such an easy mapping from the world of www to bots will make this
> >> simpler to carry out and easier for others to understand.
> >>
> >> I'll UMLify these relationships when I get some time later this week.
> >>
> >> Now onto a quick example of how I hope a developer might use these
> >> classes, an improvisation in Ruby :-)
> >>
> >> <code>
> >>
> >> myBot = Bot.new() # for default settings or:
> >> myBot = Bot.new(path) # where path is to a config.yaml file setting up
> >> the bot to non default settings
> >> myBot.ToYAML # bot's predicate list as YAML
> >>
> >> # Attributes might include
> >> myBot.Name # name of the bot
> >> myBot.Botmaster # who the bot-master is
> >> myBot.Size # number of categories in the graphmaster
> >>
> >> # loading AIML
> >> myBot.Learn(SomeRawAIML) # well formed obviously
> >> myBot.Load("pathToAIMLFile(s)") # if an individual AIML file is
> >> specified the file is loaded, if a directory all AIML files within it.
> >>
> >> # User class:
> >>
> >> myUser = User.new("Unique id") # where Unique id might be something like
> >> a PK in a database so information can be retrieved.
> >> myUser = User.new("Unique id", userconfig.yaml) # as above but with some
> >> yaml passed that includes user predicate table and / or conversation history
> >> myUser["Name"] # how to reference the user's predicates
> >> myUser.Conversations[0] # most recent conversation
> >> myUser.ToYAML # predicate list etc as YAML
> >>
> >> # Conversation:
> >>
> >> c = Conversation.new(myUser, myBot) # create a new conversation session
> >> with the specified user and bot
> >> c.Request[0] # the first thing said to the bot in this conversation
> >> c.Response[0] # the first thing said to the user
> >> c.StartedOn # Timestamp
> >> c.TimeOut # a session timeout setting (any activity after this mount of
> >> time results in the session closing)
> >> c.Close # close the session
> >> c.Open # re-open a session
> >> c.Open? # is the session open?
> >>
> >> # Request
> >> req = Request.new("Some raw input") # ctor
> >> req.StartedOn # timestamp
> >> req.Response # either nil or the response object that was returned
> >> req.User # who made the request (or nil)
> >> req.Bot # "who" made the response (or nil)
> >> req.Conversation # the session context for the request (or nil)
> >>
> >> # Response
> >> res = Response.new(req) # ctor
> >> res.to_s # the output from the bot
> >> res.FinishedOn # Timestamp. res.FinishedOn - req.StartedOn = Duration of
> >> the request
> >> res.Sentences[0] # First sentence of a multi-sentence response
> >> res.User # User for whom the response is for
> >> res.Bot # the Bot who created the response
> >> res.Converstaion # the session context for the response
> >>
> >> # sample session
> >>
> >> myBot = Bot.new("config.yaml")
> >>
> >> myUser = User.new("Default",someconfigYAML)
> >>
> >> c = Conversation.new(myUser, myBot)
> >>
> >> req = Request.new("Hi there!")
> >> response = c.Speak(req)
> >>
> >> return response.to_s
> >> </code>
> >>
> >> Nota Bene, the above code examples are off the top of my head and I'm
> >> not sure how Rubyesque they are... Comments and suggestions would be
> >> most welcome. :-)
> >>
> >> Best wishes,
> >>
> >> Nicholas
> >> _______________________________________________
> >> Aiml-programr-developers mailing list
> >> Aiml-programr-developers at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
> >>
> >>
> >
> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pRcomm.tgz
Type: application/x-gzip
Size: 2169 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/aiml-programr-developers/attachments/20070916/b18bf871/attachment.tgz 

From mauro at cicio.org  Sun Sep 16 13:37:24 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Sun, 16 Sep 2007 19:37:24 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
	<46EC579F.1030408@ntoll.org>
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
Message-ID: <c12c9d2d0709161037o3ad95810sd53aedff5b3f492@mail.gmail.com>

Hi there,

I was thinking: do you think it would make sense to use the SVN
repository also for exchanging small protypes or code snippets like
the one I wrote today?
I mean: of course noin in aiml-programR/trunk, but in something like
aiml-programR/experiments

Ciao,
Mauro

From mauro at cicio.org  Sun Sep 16 15:19:46 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Sun, 16 Sep 2007 21:19:46 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46E80BF7.4010604@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
Message-ID: <c12c9d2d0709161219r1b5a6fdbo98a793705ea22cfb@mail.gmail.com>

Hi,

=================
This is a very long mail, a lot of topics...
Here you find an afterward written "resume".

I think it was very useful what Nicholas wrote, it points out that
what he has in mind is not only what the original pR wanted to be (a
simple request/answer library) but a BOT framework AIML enabled.

I like the idea and I think it is a good and natural evolution of pR.
Still, they are two separate things:
- a pure AIML answerer
- a framework  (in large part AIML independent).

I sign in to support both.
By far, my skills and interests are more in the framework area than in
the AIML one.
I think it essential to keep the two parts as distinct as possible.
Now it is your turn to shoot on all what I said.

I would suggest to split the answers to this mail: let's open 1 thread
per topic!
=================
here I try to answer to the not yet covered points of
 Nicholas' mail.

> We're writing a library and as a result I'll define two sets of tests:
>
> * UAT - that define the expected behaviour of the classes that we expect
> other developers to have to use to write their applications
> * Unit Tests - that additionally encompass the expected behaviour of the
> wider classes / methods / areas of the library that we hope other
> developers will not have to use.

Right. BTW, it looks to me like that the public interface of pR is
gonna be very simple (there are not too many things a BOT can do...).
Probably we will have something _like_
- configure
- start
- stop
- answer(challenge)

Probably a TestFacade would do...

> As a result I'll do two things:
>
> 1. Specify our "public" classes that third party developers should use
> to implement our library by means of example "use" cases written in code

"implement our library"
I assume this is a typo and you meant "use our library". If not, I
need more explanation.

> 2. Define the architecture behind these public classes so we can start
> to write unit tests.

I have difficulties to match the strategy you suggest with the
previously discussed one. We just wanted to

- see what pR is not yet doing
- show it with tests
- fix/add/refactorize until the program reaches the point we want.

If our goal is still this, the natural steps are:
- have a full set of challenge/responses testing the program Facade
  (i.e. not caring about the program  internals, i.e. black box testing)
- fix/add/refactorize
- _along_ the process write UnitTests

New UnitTests will be developed as
- new Units (classes or small set of classes) are necessary
- existing Units without existing test are to be modified

Defining the UnitTests in advance means having a strong commitment in
the early phase on the architectural/design decisions. It is possible,
but has little to do with TestFirst strategy.

As said: it might well be that your intention matches with what I just
wrote and I just missed your point.

> It is important to remember that I intend to unit test as locally to the
> implementation of a method / class as possible.

We agree here, of course.

> By this I mean that
> there will not be any tests against the high-level "bot" class for the
> "lower level" functionality of interpreting AIML tags (I'll test this
> against the appropriate class(es)).

Again I agree.

> So onto some example use cases (I'll formalise these into proper Ruby
> unit tests - the purpose of this email is to make public my testing
> strategy so you guys can shout if you disagree and we can then modify as
> needs be)...

I am shooting, I hope you appreciate it :-)

> I imagine a developer using our library should only have to deal with
> five classes:
>
> 1. Bot - that encapsulates an instance of a particular bot.
> 2. User - that encapsulates all the information about a particular user
> who is interacting with a "Bot"
> 3. Conversation - encapsulates and exchange between a particular "User"
> and a "Bot"
> 4. Request - encapsulates an single item of raw input from a "User" to a
> "Bot" as part of a "Conversation"
> 5 Response - encapsulates an item of output from a "Bot" to a "User" as
> part of a "Conversation".

The _smallest possible library_ that could be useful to a third party
is one offering:

@bot = Bot.new
@bot.configure('aiml_set')
response = @bot.respond_to(request)

where request.class == response.class == String

When you talk about  Request, Response, Conversation, User of course
you are mixing in much more in the game.

I believe that we need to have all of those, but that the library must
be modular enough to let the user to the most elementary thing I wrote
above.
Do we agree on this?

> [...already discussed analogy...]

> I'll UMLify these relationships when I get some time later this week.

Not necessary for me. If also Ben is clear with the relations between
Bot/User/Conversation/Req/Res you can save the UML time.
It might be more direct to use small prototypes (like the one I sent before).
We can UML the key aspects later, once we all agree on the parts
naming and on the prog aspects.
Of course if you feel more comfortable UMLing int, it wouldn't harm
sharing the result :-)

> Now onto a quick example of how I hope a developer might use these
> classes, an improvisation in Ruby :-)

Nice!

> <code>
>
> myBot = Bot.new() # for default settings or:
> myBot = Bot.new(path) # where path is to a config.yaml file setting up
> the bot to non default settings
> myBot.ToYAML # bot's predicate list as YAML
----------------------------------------------------
I cut the long story short and introduce my_both (instead of myBot).
If any of you want the long story, just ask.
----------------------------------------------------

It is probably a good idea to have
   my_both.configure(aiml_set)
or even
   my_both.configure(configuration)
where
  configuration = Configurator.new(:aiml_sets => [...], :master =>
'...', :name =>'...')

In this way it is easy to have the hot configuration.
This technique is used - among others - with chess engines: they do
not load all the info set as the game begins,  but they load the
modules as they are necessary. If there are only Kings Rooks and Pawns
left, the RooksEndgames is loaded.
We can think to use the same: e.g. if the user talks of food, we load
the 'recipies.aiml'.

> # Attributes might include
> myBot.Name # name of the bot
> myBot.Botmaster # who the bot-master is
> myBot.Size # number of categories in the graphmaster

all right. The notation is  my_bot.name.

> # loading AIML
> myBot.Learn(SomeRawAIML) # well formed obviously
> myBot.Load("pathToAIMLFile(s)") # if an individual AIML file is
> specified the file is loaded, if a directory all AIML files within it.

Fine, this answers (for the aiml part at least) to my point about hot
configuration.
BTW: the current pR should already act like that.

> # User class:
>
> myUser = User.new("Unique id") # where Unique id might be something like
> a PK in a database so information can be retrieved.
> myUser = User.new("Unique id", userconfig.yaml) # as above but with some
> yaml passed that includes user predicate table and / or conversation history
> myUser["Name"] # how to reference the user's predicates
> myUser.Conversations[0] # most recent conversation
> myUser.ToYAML # predicate list etc as YAML

Probably we want to have
PR::User.new
PR::User.new(:config => 'userconfig.yaml')
PR::User.save
PR::User.find(id)

In this way we offer a Active::Record compliant  PR::User.
In order not to introduce unwanted dependencies, we could use a
transient DB (marshal or YAML based).

I keep it short because this mail is already pretty long. Probably we
can depthen the topic.

> # Conversation:
>
> c = Conversation.new(myUser, myBot) # create a new conversation session
> with the specified user and bot

Maybe not strictly necessary. The bot and the bot configuration might
depend on the User. It might be enough to have c =
Conversation.new(my_user)

> c.Request[0] # the first thing said to the bot in this conversation
> c.Response[0] # the first thing said to the user
> c.StartedOn # Timestamp
> c.TimeOut # a session timeout setting (any activity after this mount of
> time results in the session closing)
> c.Close # close the session
> c.Open # re-open a session
> c.Open? # is the session open?

It might be better to call it Session. It is so spontaneous...

> [... other code ...]
> </code>

> Nota Bene, the above code examples are off the top of my head and I'm
> not sure how Rubyesque they are...

Not a problem! Important is to throw the basis.

> Comments and suggestions would be most welcome. :-)

Done! :-)

Your turn to shoot!

Mauro

From ntoll at ntoll.org  Mon Sep 17 04:07:00 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 17 Sep 2007 09:07:00 +0100
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <c12c9d2d0709161219r1b5a6fdbo98a793705ea22cfb@mail.gmail.com>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709161219r1b5a6fdbo98a793705ea22cfb@mail.gmail.com>
Message-ID: <46EE35A4.9090001@ntoll.org>

Guys,

See comments inline... :-)

mauro at cicio.org wrote:
> Hi,
>
> =================
> This is a very long mail, a lot of topics...
> Here you find an afterward written "resume".
>
> I think it was very useful what Nicholas wrote, it points out that
> what he has in mind is not only what the original pR wanted to be (a
> simple request/answer library) but a BOT framework AIML enabled.
>
> I like the idea and I think it is a good and natural evolution of pR.
> Still, they are two separate things:
> - a pure AIML answerer
> - a framework  (in large part AIML independent).
>
> I sign in to support both.
> By far, my skills and interests are more in the framework area than in
> the AIML one.
> I think it essential to keep the two parts as distinct as possible.
> Now it is your turn to shoot on all what I said.
>   
Totally agree, I also think that AIML answerer should come first before
the framework (but that we should have the framework in mind when
developing the answerer).
> I would suggest to split the answers to this mail: let's open 1 thread
> per topic!
>   
Agreed... In future I'll make sure my emails are more specific.
> =================
> here I try to answer to the not yet covered points of
>  Nicholas' mail.
>
>   
>> We're writing a library and as a result I'll define two sets of tests:
>>
>> * UAT - that define the expected behaviour of the classes that we expect
>> other developers to have to use to write their applications
>> * Unit Tests - that additionally encompass the expected behaviour of the
>> wider classes / methods / areas of the library that we hope other
>> developers will not have to use.
>>     
>
> Right. BTW, it looks to me like that the public interface of pR is
> gonna be very simple (there are not too many things a BOT can do...).
> Probably we will have something _like_
> - configure
> - start
> - stop
> - answer(challenge)
>
> Probably a TestFacade would do...
>
>   
Yes, totally agree... TestFacade is a good way of describing what I was
calling UAT. I'll use TestFacade from now on.
>> As a result I'll do two things:
>>
>> 1. Specify our "public" classes that third party developers should use
>> to implement our library by means of example "use" cases written in code
>>     
>
> "implement our library"
> I assume this is a typo and you meant "use our library". If not, I
> need more explanation.
>   
My lazy English / colloquialism - I meant what you assumed. Obviously
third parties use our library - we're going to implement it...
>   
>> 2. Define the architecture behind these public classes so we can start
>> to write unit tests.
>>     
>
> I have difficulties to match the strategy you suggest with the
> previously discussed one. We just wanted to
>
> - see what pR is not yet doing
> - show it with tests
> - fix/add/refactorize until the program reaches the point we want.
>
> If our goal is still this, the natural steps are:
> - have a full set of challenge/responses testing the program Facade
>   (i.e. not caring about the program  internals, i.e. black box testing)
> - fix/add/refactorize
> - _along_ the process write UnitTests
>
> New UnitTests will be developed as
> - new Units (classes or small set of classes) are necessary
> - existing Units without existing test are to be modified
>
> Defining the UnitTests in advance means having a strong commitment in
> the early phase on the architectural/design decisions. It is possible,
> but has little to do with TestFirst strategy.
>
> As said: it might well be that your intention matches with what I just
> wrote and I just missed your point.
>
>   
>> It is important to remember that I intend to unit test as locally to the
>> implementation of a method / class as possible.
>>     
>
> We agree here, of course.o 
>   
Mauro, I share your concerns about prematurely writing unit tests - we
need to stay as flexible as possible. What I had in mind was the
TestFacade mentioned earlier along with unit tests for *ONLY* those
known internals specified by the AIML standard - specifically tag
handlers and the Graphmaster algorithm. As we're testing locally it
would not be appropriate to place them as part of the test facade.

Also, I think my enthusiasm for my web->bot analogy was getting the
better of me at this point :-). Obviously we should follow our original
plan as stated above, I was definitely thinking of a framework at this
point in my email - something that can wait until the AIML responder is
sorted out.

<snip/>
> The _smallest possible library_ that could be useful to a third party
> is one offering:
>
> @bot = Bot.new
> @bot.configure('aiml_set')
> response = @bot.respond_to(request)
>
> where request.class == response.class == String
>
> When you talk about  Request, Response, Conversation, User of course
> you are mixing in much more in the game.
>
> I believe that we need to have all of those, but that the library must
> be modular enough to let the user to the most elementary thing I wrote
> above.
> Do we agree on this?
>   
Most definitely, the additional classes *might* be appropriate in a
larger framework but I definitely subscribe to Einstein's "as simple as
possible and no simpler" ethos and agree that the responder should be
developed in this way. However, I think you missed something out of your
example above:

@bot = Bot.new
@bot.configure('aiml_set')
response = @bot.respond_to(request, user_predicate_hash)

Where (I agree that) request.class == response.class = String and
user_predicate_hash.class == Hash

<snip/>
>> I'll UMLify these relationships when I get some time later this week.
>>     
>
> Not necessary for me. If also Ben is clear with the relations between
> Bot/User/Conversation/Req/Res you can save the UML time.
> It might be more direct to use small prototypes (like the one I sent before).
> We can UML the key aspects later, once we all agree on the parts
> naming and on the prog aspects.
> Of course if you feel more comfortable UMLing int, it wouldn't harm
> sharing the result :-)
>
>   
No need to create work for ourselves then. I'll skip the UML.

<snip/>
> ----------------------------------------------------
> I cut the long story short and introduce my_both (instead of myBot).
> If any of you want the long story, just ask.
> ----------------------------------------------------
>
> It is probably a good idea to have
>    my_both.configure(aiml_set)
> or even
>    my_both.configure(configuration)
> where
>   configuration = Configurator.new(:aiml_sets => [...], :master =>
> '...', :name =>'...')
>
> In this way it is easy to have the hot configuration.
> This technique is used - among others - with chess engines: they do
> not load all the info set as the game begins,  but they load the
> modules as they are necessary. If there are only Kings Rooks and Pawns
> left, the RooksEndgames is loaded.
> We can think to use the same: e.g. if the user talks of food, we load
> the 'recipies.aiml'.
>
>   
Hmmm... I like the idea of hot configuration but I'm not sure your
example quite works in a circular sort of a way: if the user talks of
food then we need to load recipes.aiml, but to identify that the user is
talking about food the recipes.aiml needs to be loaded already. Or
perhaps you mean that AIML files should be organised by "topic" and when
a topic is set by a template the appropriate file is loaded? Not sure
how you see this working, but I like the idea!
>> # Attributes might include
>> myBot.Name # name of the bot
>> myBot.Botmaster # who the bot-master is
>> myBot.Size # number of categories in the graphmaster
>>     
>
> all right. The notation is  my_bot.name.
>
>   
Actually, I'm having second thoughts on this. IIRC the AIML standard
states each bot should have its own predicate hash. Why not just have:

my_bot.predicates[:name]
my_bot.predicates[:botmaster]

etc... (keeping things simple and flexible here)
>> # loading AIML
>> myBot.Learn(SomeRawAIML) # well formed obviously
>> myBot.Load("pathToAIMLFile(s)") # if an individual AIML file is
>> specified the file is loaded, if a directory all AIML files within it.
>>     
>
> Fine, this answers (for the aiml part at least) to my point about hot
> configuration.
> BTW: the current pR should already act like that.
>
>   
The <learn/> tag in the AIML specification already defines this behaviour.
> Probably we want to have
> PR::User.new
> PR::User.new(:config => 'userconfig.yaml')
> PR::User.save
> PR::User.find(id)
>
> In this way we offer a Active::Record compliant  PR::User.
> In order not to introduce unwanted dependencies, we could use a
> transient DB (marshal or YAML based).
>
> I keep it short because this mail is already pretty long. Probably we
> can depthen the topic.
>
>   
Totally agree, I think we should make things, where appropriate,
Active::Record compliant for ease of use and familiarity. Although I
suspect this is more to do with the framework rather than AIML responder
which (as I pointed out above) only requires a user's predicate hash to
work.
>> # Conversation:
>>
>> c = Conversation.new(myUser, myBot) # create a new conversation session
>> with the specified user and bot
>>     
>
> Maybe not strictly necessary. The bot and the bot configuration might
> depend on the User. It might be enough to have c =
> Conversation.new(my_user)
>
>   
Again, something to be left for the framework. I passed both the user
and the bot to the constructor as it seemed natural to think of a
conversation between two entities, although I think you are correct in
that it isn't necessary.
>
> It might be better to call it Session. It is so spontaneous...
>
>   
Actually, I was having second thoughts about this too. "Session" is a
term that is clearly understood and defined within a client/server
context so we should use it.
>> Comments and suggestions would be most welcome. :-)
>>     
>
> Done! :-)
>   
:-)
> Your turn to shoot!
>
> Mauro
>
>   


From ntoll at ntoll.org  Mon Sep 17 04:49:27 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 17 Sep 2007 09:49:27 +0100
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <c12c9d2d0709161037o3ad95810sd53aedff5b3f492@mail.gmail.com>
References: <46E80BF7.4010604@ntoll.org>	
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>	
	<46EC579F.1030408@ntoll.org>	
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
	<c12c9d2d0709161037o3ad95810sd53aedff5b3f492@mail.gmail.com>
Message-ID: <46EE3F97.2090205@ntoll.org>

A good idea as it is important to store our experiments and examples
somewhere safe. How about in:

|-branches
| |----play
|      |-----Mauro
|      |-----Ben
|      |-----Nicholas
|
|- tags
|- trunk

And we use/organise our "/branches/play/username" areas as we see fit?

Nicholas

mauro at cicio.org wrote:
> Hi there,
>
> I was thinking: do you think it would make sense to use the SVN
> repository also for exchanging small protypes or code snippets like
> the one I wrote today?
> I mean: of course noin in aiml-programR/trunk, but in something like
> aiml-programR/experiments
>
> Ciao,
> Mauro
>
>   


From ntoll at ntoll.org  Mon Sep 17 05:54:56 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 17 Sep 2007 10:54:56 +0100
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
References: <46E80BF7.4010604@ntoll.org>	
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>	
	<46EC579F.1030408@ntoll.org>
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
Message-ID: <46EE4EF0.7060902@ntoll.org>

Mauro,

The code you describe in the following example doesn't work. I
definitely have both Rails and drb installed. When I run the command
"ruby webserver.rb" I get the following error:

webserver.rb:24:in `require': no such file to load -- comm/p_r_plugin
(LoadError)
        from webserver.rb:24

Obviously, the path is wrong. As a quick hack I just copied the
webserver.rb file into the lib directory and ran from there. However I
just got returned to the command prompt - upon investigation I notice
that webserver only contains class definitions, not any actual code to
instantiate and run a service. Is this correct?

When I run "browser.rb" I get the following errors:

./lib/comm/p_r_plugin.rb:24:in `readlines': No such file or directory -
/tmp/pr_bot_address (Errno::ENOENT)
        from ./lib/comm/p_r_plugin.rb:24:in `initialize'
        from ./lib/comm/p_r_plugin.rb:14:in `new'
        from ./lib/comm/p_r_plugin.rb:14:in `hanlde'
        from ./webserver.rb:18:in `get'
        from browser.rb:18:in `start'
        from browser.rb:23

Could you check that the code you sent us is correct? I'd love to get it
working at see what exactly is happening.

Best wishes,

Nicholas

 
>
> To get on a more concrete ground, I tried to put down a very small
> (but running) prototype that could help us in discussing
> - Ruby coding style
> - Naming/Metaphores
> - key concepts and separation of concerns
>
> If you guys find the time to run the program, read it, ask questions
> and so on, I think it would help a lot.
>
> The prog structure is:
> |-- browser.rb
> |-- lib
> |   |-- comm
> |   |   |-- bot_proxy.rb
> |   |   |-- p_r_plugin.rb
> |   |   |-- request.rb
> |   |   |-- response.rb
> |   |   |-- service.rb
> |   |   `-- session_manager.rb
> |   |-- program_r
> |   |   `-- bot.rb
> |   `-- rails
> |       `-- session.rb
> `-- webserver.rb
> To run it just open 2 shells. In the first one run
> $ ruby webserver.rb
> in the other one
> $ ruby browser.rb
> On the browser side you should see a prompt: enter a word and enter
> (you'll get back the reversed word)
> Prerequisites: 'drb' (is it in the distribution?)
>   

From ntoll at ntoll.org  Mon Sep 17 06:38:41 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 17 Sep 2007 11:38:41 +0100
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46EE3F97.2090205@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>		<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>		<46EC579F.1030408@ntoll.org>		<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>	<c12c9d2d0709161037o3ad95810sd53aedff5b3f492@mail.gmail.com>
	<46EE3F97.2090205@ntoll.org>
Message-ID: <46EE5931.4080807@ntoll.org>

Guys,

Have just committed the "play" area as described below

Nicholas

Nicholas H.Tollervey wrote:
> A good idea as it is important to store our experiments and examples
> somewhere safe. How about in:
>
> |-branches
> | |----play
> |      |-----Mauro
> |      |-----Ben
> |      |-----Nicholas
> |
> |- tags
> |- trunk
>
> And we use/organise our "/branches/play/username" areas as we see fit?
>
> Nicholas
>
> mauro at cicio.org wrote:
>   
>> Hi there,
>>
>> I was thinking: do you think it would make sense to use the SVN
>> repository also for exchanging small protypes or code snippets like
>> the one I wrote today?
>> I mean: of course noin in aiml-programR/trunk, but in something like
>> aiml-programR/experiments
>>
>> Ciao,
>> Mauro
>>
>>   
>>     
>
> _______________________________________________
> Aiml-programr-developers mailing list
> Aiml-programr-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>
>   


From mauro at cicio.org  Mon Sep 17 08:16:23 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Mon, 17 Sep 2007 14:16:23 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46EE35A4.9090001@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709161219r1b5a6fdbo98a793705ea22cfb@mail.gmail.com>
	<46EE35A4.9090001@ntoll.org>
Message-ID: <c12c9d2d0709170516n7bf1676j8223db3c8869b8dd@mail.gmail.com>

Hi,

In the following I cut all the points where we have a fuul agreement
and nothing open is left.


> > @bot = Bot.new
> > @bot.configure('aiml_set')
> > response = @bot.respond_to(request)
> >
> > where request.class == response.class == String
> >
> > When you talk about  Request, Response, Conversation, User of course
> > you are mixing in much more in the game.
> >
> > I believe that we need to have all of those, but that the library must
> > be modular enough to let the user to the most elementary thing I wrote
> > above.
> > Do we agree on this?
> >
> Most definitely, the additional classes *might* be appropriate in a
> larger framework but I definitely subscribe to Einstein's "as simple as
> possible and no simpler" ethos and agree that the responder should be
> developed in this way. However, I think you missed something out of your
> example above:
>
> @bot = Bot.new
> @bot.configure('aiml_set')
> response = @bot.respond_to(request, user_predicate_hash)
>
> Where (I agree that) request.class == response.class = String and
> user_predicate_hash.class == Hash

All right.


> No need to create work for ourselves then. I'll skip the UML.

Well, I don't know what Ben thinks about it, but yes, let's try to do
only what we really need to keep going now and, if things work out
well as it seems they are going to, then we can document for the
library users.

> Hmmm... I like the idea of hot configuration but I'm not sure your
> example quite works in a circular sort of a way: if the user talks of
> food then we need to load recipes.aiml, but to identify that the user is
> talking about food the recipes.aiml needs to be loaded already.

In chess of course it is easier than in natural language.
Still we can think of branches that are simply not complete.
AIML could give an answer like: "are we talking about food?" and based
on the user answer, the hot loading happens.

> Or perhaps you mean that AIML files should be organised by "topic" and when
> a topic is set by a template the appropriate file is loaded? Not sure
> how you see this working, but I like the idea!

What I had in mind is to have "master" files that have as response to
certain stimula the command "load a module".
The idea is not wuite clear in my mind, but I thought useful to share
it with you guys. Like for the framework, it is an idea I wouldlike to
keep in mind, but in background for the moment.

> >> # Attributes might include
> >> myBot.Name # name of the bot
> >> myBot.Botmaster # who the bot-master is
> >> myBot.Size # number of categories in the graphmaster
> >>
> >
> > all right. The notation is  my_bot.name.
> >
> >
> Actually, I'm having second thoughts on this. IIRC the AIML standard
> states each bot should have its own predicate hash. Why not just have:
>
> my_bot.predicates[:name]
> my_bot.predicates[:botmaster]
>
> etc... (keeping things simple and flexible here)

I see what you mean. Only "bad smell" (in the sense of Martin Fowler)
is that we are exposing the internal implementation (hash). It might
be better
my_bot.predicates(:botmaster)

> >
> The <learn/> tag in the AIML specification already defines this behaviour.
> > Probably we want to have
> > PR::User.new
> > PR::User.new(:config => 'userconfig.yaml')
> > PR::User.save
> > PR::User.find(id)
> >
> > In this way we offer a Active::Record compliant  PR::User.
> > In order not to introduce unwanted dependencies, we could use a
> > transient DB (marshal or YAML based).
> >
> > I keep it short because this mail is already pretty long. Probably we
> > can depthen the topic.
> >
> >
> Totally agree, I think we should make things, where appropriate,
> Active::Record compliant for ease of use and familiarity. Although I
> suspect this is more to do with the framework rather than AIML responder
> which (as I pointed out above) only requires a user's predicate hash to
> work.

Right, it has to do with the FW.

> >> # Conversation:
> >>
> >> c = Conversation.new(myUser, myBot) # create a new conversation session
> >> with the specified user and bot
> >>
> >
> > Maybe not strictly necessary. The bot and the bot configuration might
> > depend on the User. It might be enough to have c =
> > Conversation.new(my_user)
> >
> >
> Again, something to be left for the framework. I passed both the user
> and the bot to the constructor as it seemed natural to think of a
> conversation between two entities, although I think you are correct in
> that it isn't necessary.

FW, I agree again.

> > It might be better to call it Session. It is so spontaneous...
> >
> >
> Actually, I was having second thoughts about this too. "Session" is a
> term that is clearly understood and defined within a client/server
> context so we should use it.

Yes... In a framework I wrote some time ago I ended up calling it
"Dialog" and "DialogManager". It was not a good choice, I had to
explain it to each new team member and often I had to answer "what is
the difference with Session"?

Still, we probably want to use PR::Session to avoid clashing (PR is
just a proposal).


Ciao,
Mauro

From mauro at cicio.org  Mon Sep 17 08:17:22 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Mon, 17 Sep 2007 14:17:22 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46EE3F97.2090205@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
	<46EC579F.1030408@ntoll.org>
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
	<c12c9d2d0709161037o3ad95810sd53aedff5b3f492@mail.gmail.com>
	<46EE3F97.2090205@ntoll.org>
Message-ID: <c12c9d2d0709170517o303cf634h877390eb4ac3a948@mail.gmail.com>

Fine to me!

On 17/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> A good idea as it is important to store our experiments and examples
> somewhere safe. How about in:
>
> |-branches
> | |----play
> |      |-----Mauro
> |      |-----Ben
> |      |-----Nicholas
> |
> |- tags
> |- trunk
>
> And we use/organise our "/branches/play/username" areas as we see fit?
>
> Nicholas
>
> mauro at cicio.org wrote:
> > Hi there,
> >
> > I was thinking: do you think it would make sense to use the SVN
> > repository also for exchanging small protypes or code snippets like
> > the one I wrote today?
> > I mean: of course noin in aiml-programR/trunk, but in something like
> > aiml-programR/experiments
> >
> > Ciao,
> > Mauro
> >
> >
>
>

From mauro at cicio.org  Mon Sep 17 08:26:44 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Mon, 17 Sep 2007 14:26:44 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46EE4EF0.7060902@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
	<46EC579F.1030408@ntoll.org>
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
	<46EE4EF0.7060902@ntoll.org>
Message-ID: <c12c9d2d0709170526v7f0c2d5fp2d7b475e0d6a6838@mail.gmail.com>

Hi,

sorry, probably the webserver.rb is a wrapper that I left halfway... :-(

Please do the following:
1 - cd to the top level directory in both shells
$ cd $yourpath/pRcomm

2 - in first shell run
$ ruby lib/comm/service.rb

3 - in the second run
$ ruby browser.rb

Ciao,
Mauro

On 17/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Mauro,
>
> The code you describe in the following example doesn't work. I
> definitely have both Rails and drb installed. When I run the command
> "ruby webserver.rb" I get the following error:
>
> webserver.rb:24:in `require': no such file to load -- comm/p_r_plugin
> (LoadError)
>         from webserver.rb:24
>
> Obviously, the path is wrong. As a quick hack I just copied the
> webserver.rb file into the lib directory and ran from there. However I
> just got returned to the command prompt - upon investigation I notice
> that webserver only contains class definitions, not any actual code to
> instantiate and run a service. Is this correct?
>
> When I run "browser.rb" I get the following errors:
>
> ./lib/comm/p_r_plugin.rb:24:in `readlines': No such file or directory -
> /tmp/pr_bot_address (Errno::ENOENT)
>         from ./lib/comm/p_r_plugin.rb:24:in `initialize'
>         from ./lib/comm/p_r_plugin.rb:14:in `new'
>         from ./lib/comm/p_r_plugin.rb:14:in `hanlde'
>         from ./webserver.rb:18:in `get'
>         from browser.rb:18:in `start'
>         from browser.rb:23
>
> Could you check that the code you sent us is correct? I'd love to get it
> working at see what exactly is happening.
>
> Best wishes,
>
> Nicholas
>
>
> >
> > To get on a more concrete ground, I tried to put down a very small
> > (but running) prototype that could help us in discussing
> > - Ruby coding style
> > - Naming/Metaphores
> > - key concepts and separation of concerns
> >
> > If you guys find the time to run the program, read it, ask questions
> > and so on, I think it would help a lot.
> >
> > The prog structure is:
> > |-- browser.rb
> > |-- lib
> > |   |-- comm
> > |   |   |-- bot_proxy.rb
> > |   |   |-- p_r_plugin.rb
> > |   |   |-- request.rb
> > |   |   |-- response.rb
> > |   |   |-- service.rb
> > |   |   `-- session_manager.rb
> > |   |-- program_r
> > |   |   `-- bot.rb
> > |   `-- rails
> > |       `-- session.rb
> > `-- webserver.rb
> > To run it just open 2 shells. In the first one run
> > $ ruby webserver.rb
> > in the other one
> > $ ruby browser.rb
> > On the browser side you should see a prompt: enter a word and enter
> > (you'll get back the reversed word)
> > Prerequisites: 'drb' (is it in the distribution?)
> >
>

From mauro at cicio.org  Mon Sep 17 08:32:19 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Mon, 17 Sep 2007 14:32:19 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46EE5931.4080807@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
	<46EC579F.1030408@ntoll.org>
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
	<c12c9d2d0709161037o3ad95810sd53aedff5b3f492@mail.gmail.com>
	<46EE3F97.2090205@ntoll.org> <46EE5931.4080807@ntoll.org>
Message-ID: <c12c9d2d0709170532n27ebd72at4e87d1a2742acd2b@mail.gmail.com>

Fine,
I imported my fw_prototype at
var/svn/aiml-programr/branches/play/mauro/fw_prototype
"Prototype" is tooa big word for this small program, but it will
probably grow to deserve it! :-)

Mauro


On 17/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Guys,
>
> Have just committed the "play" area as described below
>
> Nicholas
>
> Nicholas H.Tollervey wrote:
> > A good idea as it is important to store our experiments and examples
> > somewhere safe. How about in:
> >
> > |-branches
> > | |----play
> > |      |-----Mauro
> > |      |-----Ben
> > |      |-----Nicholas
> > |
> > |- tags
> > |- trunk
> >
> > And we use/organise our "/branches/play/username" areas as we see fit?
> >
> > Nicholas
> >
> > mauro at cicio.org wrote:
> >
> >> Hi there,
> >>
> >> I was thinking: do you think it would make sense to use the SVN
> >> repository also for exchanging small protypes or code snippets like
> >> the one I wrote today?
> >> I mean: of course noin in aiml-programR/trunk, but in something like
> >> aiml-programR/experiments
> >>
> >> Ciao,
> >> Mauro
> >>
> >>
> >>
> >
> > _______________________________________________
> > Aiml-programr-developers mailing list
> > Aiml-programr-developers at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/aiml-programr-developers
> >
> >
>
>

From ntoll at ntoll.org  Mon Sep 17 11:11:18 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 17 Sep 2007 16:11:18 +0100
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <c12c9d2d0709170526v7f0c2d5fp2d7b475e0d6a6838@mail.gmail.com>
References: <46E80BF7.4010604@ntoll.org>	
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>	
	<46EC579F.1030408@ntoll.org>	
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>	
	<46EE4EF0.7060902@ntoll.org>
	<c12c9d2d0709170526v7f0c2d5fp2d7b475e0d6a6838@mail.gmail.com>
Message-ID: <46EE9916.8080603@ntoll.org>

Hi Mauro,

Still no luck with the code you sent. The server part now runs but when
the browser queries it I get the following:

$ ruby browser.rb
demo$ hello
(druby://127.0.0.1:7001) ./lib/comm/bot_proxy.rb:11:in `handle':
undefined method `to_yaml' for #<Response:0xb7c86718 @session_id=3,
@body="olleh"> (NoMethodError)
        from ./lib/comm/p_r_plugin.rb:28:in `handle'
        from ./lib/comm/p_r_plugin.rb:14:in `hanlde'
        from ./webserver.rb:18:in `get'
        from browser.rb:18:in `start'
        from browser.rb:23

As you can see, the thing seems to work up to returning the
Response.to_yaml method. I've looked in the code and there isn't one
defined. :-(

Is there something missing?

Best wishes,

Nicholas

From mauro at cicio.org  Mon Sep 17 14:57:14 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Mon, 17 Sep 2007 20:57:14 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46EE9916.8080603@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
	<46EC579F.1030408@ntoll.org>
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
	<46EE4EF0.7060902@ntoll.org>
	<c12c9d2d0709170526v7f0c2d5fp2d7b475e0d6a6838@mail.gmail.com>
	<46EE9916.8080603@ntoll.org>
Message-ID: <c12c9d2d0709171157y258c411ev5207623ceb0ac2a1@mail.gmail.com>

The to_yaml method is part of the standard library YAML module
(http://www.ruby-doc.org/stdlib/libdoc/yaml/rdoc/index.html).

Why is not working on my PC but not on yours?
I think that the explanation can be one of the following:
1 - ruby version (1.8.4)
2 - I have all the rails library in the path

One thing you might want to try is to include explicitely the YAML module:

class Response
  include YAML
  attr_reader :body, :session_id
  def initialize(body, session_id)
    @body, @session_id = body, session_id
  end
end

and if this giver problems, to require the lib:
require 'yaml'
class Response
...


I hope this will do...

Ciao,
Mauro


On 17/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Hi Mauro,
>
> Still no luck with the code you sent. The server part now runs but when
> the browser queries it I get the following:
>
> $ ruby browser.rb
> demo$ hello
> (druby://127.0.0.1:7001) ./lib/comm/bot_proxy.rb:11:in `handle':
> undefined method `to_yaml' for #<Response:0xb7c86718 @session_id=3,
> @body="olleh"> (NoMethodError)
>         from ./lib/comm/p_r_plugin.rb:28:in `handle'
>         from ./lib/comm/p_r_plugin.rb:14:in `hanlde'
>         from ./webserver.rb:18:in `get'
>         from browser.rb:18:in `start'
>         from browser.rb:23
>
> As you can see, the thing seems to work up to returning the
> Response.to_yaml method. I've looked in the code and there isn't one
> defined. :-(
>
> Is there something missing?
>
> Best wishes,
>
> Nicholas
>

From ntoll at ntoll.org  Mon Sep 17 15:19:13 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Mon, 17 Sep 2007 20:19:13 +0100
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <c12c9d2d0709171157y258c411ev5207623ceb0ac2a1@mail.gmail.com>
References: <46E80BF7.4010604@ntoll.org>	
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>	
	<46EC579F.1030408@ntoll.org>	
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>	
	<46EE4EF0.7060902@ntoll.org>	
	<c12c9d2d0709170526v7f0c2d5fp2d7b475e0d6a6838@mail.gmail.com>	
	<46EE9916.8080603@ntoll.org>
	<c12c9d2d0709171157y258c411ev5207623ceb0ac2a1@mail.gmail.com>
Message-ID: <46EED331.30805@ntoll.org>

Mauro,

Works a treat! Thanks for the help, I thought it might be something to
do with an un-referenced library but was unsure what/how.

Nicholas

mauro at cicio.org wrote:
> The to_yaml method is part of the standard library YAML module
> (http://www.ruby-doc.org/stdlib/libdoc/yaml/rdoc/index.html).
>
> Why is not working on my PC but not on yours?
> I think that the explanation can be one of the following:
> 1 - ruby version (1.8.4)
> 2 - I have all the rails library in the path
>
> One thing you might want to try is to include explicitely the YAML module:
>
> class Response
>   include YAML
>   attr_reader :body, :session_id
>   def initialize(body, session_id)
>     @body, @session_id = body, session_id
>   end
> end
>
> and if this giver problems, to require the lib:
> require 'yaml'
> class Response
> ...
>
>
> I hope this will do...
>
> Ciao,
> Mauro
>
>
> On 17/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
>   
>> Hi Mauro,
>>
>> Still no luck with the code you sent. The server part now runs but when
>> the browser queries it I get the following:
>>
>> $ ruby browser.rb
>> demo$ hello
>> (druby://127.0.0.1:7001) ./lib/comm/bot_proxy.rb:11:in `handle':
>> undefined method `to_yaml' for #<Response:0xb7c86718 @session_id=3,
>> @body="olleh"> (NoMethodError)
>>         from ./lib/comm/p_r_plugin.rb:28:in `handle'
>>         from ./lib/comm/p_r_plugin.rb:14:in `hanlde'
>>         from ./webserver.rb:18:in `get'
>>         from browser.rb:18:in `start'
>>         from browser.rb:23
>>
>> As you can see, the thing seems to work up to returning the
>> Response.to_yaml method. I've looked in the code and there isn't one
>> defined. :-(
>>
>> Is there something missing?
>>
>> Best wishes,
>>
>> Nicholas
>>
>>     
>
>   


From mauro at cicio.org  Mon Sep 17 15:24:51 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Mon, 17 Sep 2007 21:24:51 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46EED331.30805@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
	<46EC579F.1030408@ntoll.org>
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
	<46EE4EF0.7060902@ntoll.org>
	<c12c9d2d0709170526v7f0c2d5fp2d7b475e0d6a6838@mail.gmail.com>
	<46EE9916.8080603@ntoll.org>
	<c12c9d2d0709171157y258c411ev5207623ceb0ac2a1@mail.gmail.com>
	<46EED331.30805@ntoll.org>
Message-ID: <c12c9d2d0709171224p6330f1c9i92afb6a27d8aacaa@mail.gmail.com>

Great!

I believe it has to do with RoR. I know for sure that in RoR all the
objects have the to_yaml method, so I probably have a gem that adds
the method to the Object class.
Good to know: including it twice doesn't harm, not including might
bring a problem, so we just include :-)

Mauro
PS Ben, have you experimented the same issue?

On 17/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Mauro,
>
> Works a treat! Thanks for the help, I thought it might be something to
> do with an un-referenced library but was unsure what/how.
>
> Nicholas
>
> mauro at cicio.org wrote:
> > The to_yaml method is part of the standard library YAML module
> > (http://www.ruby-doc.org/stdlib/libdoc/yaml/rdoc/index.html).
> >
> > Why is not working on my PC but not on yours?
> > I think that the explanation can be one of the following:
> > 1 - ruby version (1.8.4)
> > 2 - I have all the rails library in the path
> >
> > One thing you might want to try is to include explicitely the YAML module:
> >
> > class Response
> >   include YAML
> >   attr_reader :body, :session_id
> >   def initialize(body, session_id)
> >     @body, @session_id = body, session_id
> >   end
> > end
> >
> > and if this giver problems, to require the lib:
> > require 'yaml'
> > class Response
> > ...
> >
> >
> > I hope this will do...
> >
> > Ciao,
> > Mauro
> >
> >
> > On 17/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> >
> >> Hi Mauro,
> >>
> >> Still no luck with the code you sent. The server part now runs but when
> >> the browser queries it I get the following:
> >>
> >> $ ruby browser.rb
> >> demo$ hello
> >> (druby://127.0.0.1:7001) ./lib/comm/bot_proxy.rb:11:in `handle':
> >> undefined method `to_yaml' for #<Response:0xb7c86718 @session_id=3,
> >> @body="olleh"> (NoMethodError)
> >>         from ./lib/comm/p_r_plugin.rb:28:in `handle'
> >>         from ./lib/comm/p_r_plugin.rb:14:in `hanlde'
> >>         from ./webserver.rb:18:in `get'
> >>         from browser.rb:18:in `start'
> >>         from browser.rb:23
> >>
> >> As you can see, the thing seems to work up to returning the
> >> Response.to_yaml method. I've looked in the code and there isn't one
> >> defined. :-(
> >>
> >> Is there something missing?
> >>
> >> Best wishes,
> >>
> >> Nicholas
> >>
> >>
> >
> >
>
>

From mauro at cicio.org  Tue Sep 18 03:26:01 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Tue, 18 Sep 2007 09:26:01 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <46EED331.30805@ntoll.org>
References: <46E80BF7.4010604@ntoll.org>
	<c12c9d2d0709150752x6aad505q648ec84f62f0a934@mail.gmail.com>
	<46EC579F.1030408@ntoll.org>
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
	<46EE4EF0.7060902@ntoll.org>
	<c12c9d2d0709170526v7f0c2d5fp2d7b475e0d6a6838@mail.gmail.com>
	<46EE9916.8080603@ntoll.org>
	<c12c9d2d0709171157y258c411ev5207623ceb0ac2a1@mail.gmail.com>
	<46EED331.30805@ntoll.org>
Message-ID: <c12c9d2d0709180026s544601f3l636b0b095493bda1@mail.gmail.com>

Hi,

Now that you guys have the smal example up and running, I think that
we can use it to get the names right.
The program has two porpouses: help us in finding names for things and
actually show a possible flow of control.
As you have probably seen by now, most of it is delegation.
I used several classes as "place holders" for the actors playing a
role in the FW game. For the sake of clarity, I have used names like
webserver, browser, Rails, Service and so on...
Besides, the program is also actually doing something: it is giving an
example of basic, but working, session management. It is  not too
difficult to make it a real session management subsystem.

Ciao,
Mauro
On 17/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> Mauro,
>
> Works a treat! Thanks for the help, I thought it might be something to
> do with an un-referenced library but was unsure what/how.
>
> Nicholas
>
> mauro at cicio.org wrote:
> > The to_yaml method is part of the standard library YAML module
> > (http://www.ruby-doc.org/stdlib/libdoc/yaml/rdoc/index.html).
> >
> > Why is not working on my PC but not on yours?
> > I think that the explanation can be one of the following:
> > 1 - ruby version (1.8.4)
> > 2 - I have all the rails library in the path
> >
> > One thing you might want to try is to include explicitely the YAML module:
> >
> > class Response
> >   include YAML
> >   attr_reader :body, :session_id
> >   def initialize(body, session_id)
> >     @body, @session_id = body, session_id
> >   end
> > end
> >
> > and if this giver problems, to require the lib:
> > require 'yaml'
> > class Response
> > ...
> >
> >
> > I hope this will do...
> >
> > Ciao,
> > Mauro
> >
> >
> > On 17/09/2007, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> >
> >> Hi Mauro,
> >>
> >> Still no luck with the code you sent. The server part now runs but when
> >> the browser queries it I get the following:
> >>
> >> $ ruby browser.rb
> >> demo$ hello
> >> (druby://127.0.0.1:7001) ./lib/comm/bot_proxy.rb:11:in `handle':
> >> undefined method `to_yaml' for #<Response:0xb7c86718 @session_id=3,
> >> @body="olleh"> (NoMethodError)
> >>         from ./lib/comm/p_r_plugin.rb:28:in `handle'
> >>         from ./lib/comm/p_r_plugin.rb:14:in `hanlde'
> >>         from ./webserver.rb:18:in `get'
> >>         from browser.rb:18:in `start'
> >>         from browser.rb:23
> >>
> >> As you can see, the thing seems to work up to returning the
> >> Response.to_yaml method. I've looked in the code and there isn't one
> >> defined. :-(
> >>
> >> Is there something missing?
> >>
> >> Best wishes,
> >>
> >> Nicholas
> >>
> >>
> >
> >
>
>

From mauro at cicio.org  Tue Sep 18 03:31:52 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Tue, 18 Sep 2007 09:31:52 +0200
Subject: [Aiml-programr-developers] Tests and Architecture
In-Reply-To: <d27b1ab40709180023l16e0c3cav9405074940ac289e@mail.gmail.com>
References: <46E80BF7.4010604@ntoll.org> <46EC579F.1030408@ntoll.org>
	<c12c9d2d0709160921ka60d61ja1facc3814800667@mail.gmail.com>
	<46EE4EF0.7060902@ntoll.org>
	<c12c9d2d0709170526v7f0c2d5fp2d7b475e0d6a6838@mail.gmail.com>
	<46EE9916.8080603@ntoll.org>
	<c12c9d2d0709171157y258c411ev5207623ceb0ac2a1@mail.gmail.com>
	<46EED331.30805@ntoll.org>
	<c12c9d2d0709171224p6330f1c9i92afb6a27d8aacaa@mail.gmail.com>
	<d27b1ab40709180023l16e0c3cav9405074940ac289e@mail.gmail.com>
Message-ID: <c12c9d2d0709180031o512b57dbje21964cd390ae8e9@mail.gmail.com>

Hi,

Ben says:
> it works great, kinda weird though to see your inputted text echoed in
> reverse ... but it works!

Yes, reversing the text is the easist way to simulate the Answerer.
Using a Reverser instead than an Answerer, we have two advantages:
1 - we make very clear that we are talking about a FW
2 - it is easier to test the framework as black box
2.1 - it suggests to plug in the FW a Doubler, an Uppercaser, ...

Ciao,
Mauro

From ntoll at ntoll.org  Tue Sep 18 14:19:00 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Tue, 18 Sep 2007 19:19:00 +0100
Subject: [Aiml-programr-developers] Choice of English Version for ProgramR
Message-ID: <46F01694.4060407@ntoll.org>

Ben,

First off, I'm posting this via the mailing list so we have a record of
the conversation. :-)

Yup, "Queen's" English is fine by me. No doubt we'll have to take an ax
to the code at some point and make sure color highlighting is turned on
in our editors but I'm sure the important thing is that AIML is language
neutral even if the break-away colonials eventually complain about
having to spell correctly. :-P

Bonzer!

Best wishes,

Nicholas

> Hi Nick,
>
> I asked Mauro before and I wanted to ask you, since you and I are both
the native English speakers.
>
> What version of English do we code ProgramR and it's documentation for?
>
> American English or English English?
>
> I would prefer English English as it was what I was educated with and
continue to use although if you have solid reasons for the other, please
explain and I'd be happy to change if required.
>
> Cheers, Ben.

From ntoll at ntoll.org  Tue Sep 18 19:01:53 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Wed, 19 Sep 2007 00:01:53 +0100
Subject: [Aiml-programr-developers] Rakefile added and Rubyforge website
	proposed
Message-ID: <46F058E1.8000008@ntoll.org>

Guys,

I've taken the Rakefile template in the Ruby Cookbook as my starting
point. In the trunk directory type "rake -T" to see what it can do.
Currently runs the unit tests for us and other funky things are
automated too (rdoc, gem, deployment to Rubyforge etc) although I've not
had time to thoroughly test it. I've also created a very simple static
web-page for the RubyForge website. Its in the "website" dir. Take a
look and let me know what you think..? Obviously, we can change things
like the content but I really like the photo I found on Flickr!

Comments and suggestions most welcome.

On my to-do list:

Add more comprehensive testing and documentation - especially around the
tag handling classes and graphmaster as per our plan. I'll also attempt
to translate the Program# graphmaster from C# into Ruby as an exercise
in compare and contrast and so I get to practice some Ruby from scratch
(this'll be in my "play" area).

Best wishes,

Nicholas

From ntoll at ntoll.org  Wed Sep 19 02:37:10 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Wed, 19 Sep 2007 07:37:10 +0100
Subject: [Aiml-programr-developers] Forgot to mention
Message-ID: <46F0C396.2090808@ntoll.org>

Guys,

Apologies, but I forgot to mention that you'll need to "gem install 
rubyforge" in order to get the deployment automation working. Also, I've 
intentionally not added the rdoc files to subversion as rake will 
automatically create them for you from the source code.

Best wishes,

Nicholas

From bdminton at gmail.com  Wed Sep 19 03:14:36 2007
From: bdminton at gmail.com (Benjamin Minton)
Date: Wed, 19 Sep 2007 17:14:36 +1000
Subject: [Aiml-programr-developers] Rakefile added and Rubyforge website
	proposed
In-Reply-To: <46F058E1.8000008@ntoll.org>
References: <46F058E1.8000008@ntoll.org>
Message-ID: <d27b1ab40709190014n5fc7b642j326e4d7e2e284d01@mail.gmail.com>

Hi Nick,

Good work, grabbed the Rubyforge gem, the latest trunk of programr, ran
'rake -T' ... all the test went fine. Also had a look at the /../website,
very neat, that is an excellent photo for the bot concept.

While you are doing these extra tasks as per below, is there anything I can
do?

Cheers, Ben.

On 9/19/07, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
>
> Guys,
>
> I've taken the Rakefile template in the Ruby Cookbook as my starting
> point. In the trunk directory type "rake -T" to see what it can do.
> Currently runs the unit tests for us and other funky things are
> automated too (rdoc, gem, deployment to Rubyforge etc) although I've not
> had time to thoroughly test it. I've also created a very simple static
> web-page for the RubyForge website. Its in the "website" dir. Take a
> look and let me know what you think..? Obviously, we can change things
> like the content but I really like the photo I found on Flickr!
>
> Comments and suggestions most welcome.
>
> On my to-do list:
>
> Add more comprehensive testing and documentation - especially around the
> tag handling classes and graphmaster as per our plan. I'll also attempt
> to translate the Program# graphmaster from C# into Ruby as an exercise
> in compare and contrast and so I get to practice some Ruby from scratch
> (this'll be in my "play" area).
>
> Best wishes,
>
> Nicholas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/aiml-programr-developers/attachments/20070919/70111bc0/attachment-0001.html 

From mauro at cicio.org  Wed Sep 19 15:14:55 2007
From: mauro at cicio.org (mauro at cicio.org)
Date: Wed, 19 Sep 2007 21:14:55 +0200
Subject: [Aiml-programr-developers] Rakefile added and Rubyforge website
	proposed
In-Reply-To: <d27b1ab40709190014n5fc7b642j326e4d7e2e284d01@mail.gmail.com>
References: <46F058E1.8000008@ntoll.org>
	<d27b1ab40709190014n5fc7b642j326e4d7e2e284d01@mail.gmail.com>
Message-ID: <c12c9d2d0709191214x2ef45a4bx10c27926d75814ee@mail.gmail.com>

Hi,

Sorry for the vacancy... I have been the whole day on the customer site.
About the website:
-  I think it is good to underline with a new WS that we are a new group.
Still I would like to have a round with Sara, Loris and Giorgio before
putting it on-line. I have not yet asked what they want to do about pR
(my fault!) and I don't want they to find a completely new site
without even knowing!
- the photo is great, we all agree!
- I personally like the modern and simple layout
- Logo: Sara, my girlfriend, is a web designer. I would like to ask
her to see if she can come out with something a bit more original. In
addition: I prefer programR over ProgramR, but No problem with the
latter if the two of you prefer so.

Ciao,
Mauro

PS Nicholas, Ben: have you had any time to look at the prototype?

On 19/09/2007, Benjamin Minton <bdminton at gmail.com> wrote:
> Hi Nick,
>
> Good work, grabbed the Rubyforge gem, the latest trunk of programr, ran
> 'rake -T' ... all the test went fine. Also had a look at the /../website,
> very neat, that is an excellent photo for the bot concept.
>
> While you are doing these extra tasks as per below, is there anything I can
> do?
>
> Cheers, Ben.
>
>
> On 9/19/07, Nicholas H.Tollervey < ntoll at ntoll.org> wrote:
> > Guys,
> >
> > I've taken the Rakefile template in the Ruby Cookbook as my starting
> > point. In the trunk directory type "rake -T" to see what it can do.
> > Currently runs the unit tests for us and other funky things are
> > automated too (rdoc, gem, deployment to Rubyforge etc) although I've not
> > had time to thoroughly test it. I've also created a very simple static
> > web-page for the RubyForge website. Its in the "website" dir. Take a
> > look and let me know what you think..? Obviously, we can change things
> > like the content but I really like the photo I found on Flickr!
> >
> > Comments and suggestions most welcome.
> >
> > On my to-do list:
> >
> > Add more comprehensive testing and documentation - especially around the
> > tag handling classes and graphmaster as per our plan. I'll also attempt
> > to translate the Program# graphmaster from C# into Ruby as an exercise
> > in compare and contrast and so I get to practice some Ruby from scratch
> > (this'll be in my "play" area).
> >
> > Best wishes,
> >
> > Nicholas
>
> _______________________________________________
> Aiml-programr-developers mailing list
> Aiml-programr-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/aiml-programr-developers
>
>

From ntoll at ntoll.org  Wed Sep 19 16:02:35 2007
From: ntoll at ntoll.org (Nicholas H.Tollervey)
Date: Wed, 19 Sep 2007 21:02:35 +0100
Subject: [Aiml-programr-developers] Rakefile added and Rubyforge website
 proposed
In-Reply-To: <c12c9d2d0709191214x2ef45a4bx10c27926d75814ee@mail.gmail.com>
References: <46F058E1.8000008@ntoll.org>	<d27b1ab40709190014n5fc7b642j326e4d7e2e284d01@mail.gmail.com>
	<c12c9d2d0709191214x2ef45a4bx10c27926d75814ee@mail.gmail.com>
Message-ID: <46F1805B.2020408@ntoll.org>

Guys,

Glad you both like the website. I certainly think "less is more" when it
comes to web design. Mauro, I think it a great idea if your girl-friend
can come up with a logo. It took me about 5 mins to come up with what we
have there (I actually quite like it), and you'll be pleased to know
that I decided to get rid of the "Web 2.0" gradients and reflections
:-P... that really did look funny.

I'm especially pleased about the photo, the robot on the end looks quite
a funny character, its a shame he isn't red to represent "Ruby".

I'm afraid I inadvertently uploaded the web page to Ruby-forge for a
short while whilst testing rake. I've since put it back to how it was.
However, you'll be pleased to know that:

rake rubyforge-setup

(done only once) and

rake publish-website

Will automate the whole process. It should be trivial to change our site
should Sarah, Loris and Giorgio not approve of the design and I
definitely think we need their input on this. Please feel free change as
you see fit.

I'll be submitting my rubified version of the graphmaster to my play
area in the coming days (assuming the baby hasn't arrived - today was
supposed to be the due date) and would appreciate stylistic feedback
:-). We can then do a the suggested compare and contrast against what we
already have. I'll also get the unit tests and documentation for the
AIML tag classes sorted too.

Best wishes,

Nicholas

mauro at cicio.org wrote:
> Hi,
>
> Sorry for the vacancy... I have been the whole day on the customer site.
> About the website:
> -  I think it is good to underline with a new WS that we are a new group.
> Still I would like to have a round with Sara, Loris and Giorgio before
> putting it on-line. I have not yet asked what they want to do about pR
> (my fault!) and I don't want they to find a completely new site
> without even knowing!
> - the photo is great, we all agree!
> - I personally like the modern and simple layout
> - Logo: Sara, my girlfriend, is a web designer. I would like to ask
> her to see if she can come out with something a bit more original. In
> addition: I prefer programR over ProgramR, but No problem with the
> latter if the two of you prefer so.
>
> Ciao,
> Mauro
>
> PS Nicholas, Ben: have you had any time to look at the prototype?
>
> On 19/09/2007, Benjamin Minton <bdminton at gmail.com> wrote:
>   
>> Hi Nick,
>>
>> Good work, grabbed the Rubyforge gem, the latest trunk of programr, ran
>> 'rake -T' ... all the test went fine. Also had a look at the /../website,
>> very neat, that is an excellent photo for the bot concept.
>>
>> While you are doing these extra tasks as per below, is there anything I can
>> do?
>>
>> Cheers, Ben.
>>
>>
>> On 9/19/07, Nicholas H.Tollervey < ntoll at ntoll.org> wrote:
>>     
>>> Guys,
>>>
>>> I've taken the Rakefile template in the Ruby Cookbook as my starting
>>> point. In the trunk directory type "rake -T" to see what it can do.
>>> Currently runs the unit tests for us and other funky things are
>>> automated too (rdoc, gem, deployment to Rubyforge etc) although I've not
>>> had time to thoroughly test it. I've also created a very simple static
>>> web-page for the RubyForge website. Its in the "website" dir. Take a
>>> look and let me know what you think..? Obviously, we can change things
>>> like the content but I really like the photo I found on Flickr!
>>>
>>> Comments and suggestions most welcome.
>>>
>>> On my to-do list:
>>>
>>> Add more comprehensive testing and documentation - especially around the
>>> tag handling classes and graphmaster as per our plan. I'll also attempt
>>> to translate the Program# graphmaster from C# into Ruby as an exercise
>>> in compare and contrast and so I get to practice some Ruby from scratch
>>> (this'll be in my "play" area).
>>>
>>> Best wishes,
>>>
>>> Nicholas
>>>       
>> _______________________________________________
>> 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
>
>