grapevine-devel — Mailing list for Grapevine developers

Re: [Grapevine-devel] Animal example now works

[Anthony J. <aj...@cl...>]

Steve,

Event based has the advantage of having explicit state - it's easy to 
see what the state is.  An event model also uses less memory.

A thread based model uses more memory (I don't know how much memory a 
thread uses).  I think that a thread based approach would work well 
enough.  There are problems with deadlocks, etc.

The main reasons I think we should use threads are:

1.  Thread based code is easier to write (than learning a new language, 
or event model).
2.  Thread based code is easier to read (for new developers).
3.  CPU time is not what we're short of - developer time is.
4.  The documentation requirement is **a lot less** than writing our own 
language.

However, you want to use an inference engine so that's what we will do. 
 This will make it easier to port later and I hope that it's all going 
to work OK.  I don't really agree that it's going to be the most 
expedient way to get to our goal (I impatiently want to get this working 
ASAP) but I accept your decision.

TTFN

TJ

Stephen Blackheath wrote:

>Tony,
>
>Ah...  You need to look inside my head to understand why I think this is such 
>a good idea.
>
>It's possibly a little hard to explain, but I'll try...
>
>I've already explained the advantages because the code can be mobile (in a 
>similar way to Java).  But there are good reasons for the language itself.
>
>Think about the problems of writing code for any application that handles TCP 
>connections (as this code will).  The way I see it, there are two 
>fundamentally different approaches (I think they can correctly be called 
>'paradigms'), and most applications will use a bit of both:
>
>  * Threaded:  All state relating to the connection (which can be very 
>complex when you have to do any parsing) is contained in a thread.  The 
>thread lasts for as long as the connection does.
>- Advantages: The code simple to write, because maintaining state is not a 
>chore.
>- Disadvantages: It doesn't scale well, because if the application gets busy, 
>or the connections are of a long duration, then there are a lot of threads 
>consuming a lot of memory.
>
>  * Event-driven:  Each event executes in a short period of time - i.e. no 
>blocking is allowed.  At the commencement of each event, state must be 
>retrieved from memory/disk.  An event then typically makes changes to the 
>state of the system before returning.
>- Advantage: Efficient management of resources, because when an event isn't 
>firing, its state is "on ice" - i.e. you can efficiently cache it to disk, 
>etc.  You also completely avoid all the problems of threading - race 
>conditions, deadlocks, etc, etc.
>- Disadvantage: The code involves a lot of looking things up in hash tables 
>and generally mucking about with state.
>
>A typical web application uses both of these:  An HTTP request is itself an 
>event.  When it starts, you have no state, and you have to retrieve it based 
>on tokens sent in the request.  But the processing of the event is itself 
>thread-based.  If the thread has to request something from a database or 
>legacy system, then it blocks.
>
>As you know, as much as I like threads (and I do), I have a strong preference 
>for the event-driven model.  I am aware that this makes me a little unusual.  
>Everybody else thinks I am a masochist.  But I like it, because the logic is 
>more "pure".  In some ways, threads tie you down and make you think linearly. 
> When you have a complex application with a lot of things going on, you need 
>a lot of threads.  For example, cleaning up unused resources, and handling 
>timing-related things like re-sending requests which haven't had a response.  
>These two things are often done with threads.  But the second thing starts to 
>get complex with threads, and becomes easier in the event-driven model.
>
>In most code people avoid the problem of re-sending requests by simply 
>relying on TCP.  This won't necessarily work for our application, because it 
>works unusually as far as TCP traffic is concerned:  In a normal TCP 
>application, you're talking to ONE remote host, and that's the host you have 
>to talk to.  Your job isn't done until you've talked to that host.  That's 
>the thought-process behind the design of TCP.  In our application, however, 
>if a node isn't responding, we are better off talking to another node that 
>is.  And that means we'll need to write extra logic that isn't going to be 
>handed to us by the operating system.  Think about how difficult it is to 
>write that kind of code in threaded C++.  The thread paradigm is just too 
>'linear'.
>
>What this language (the language is called 'Raisen' for the moment) does in 
>theory is to take the chore out of the event-driven paradigm.  And writing 
>this stuff in C++ is definitely a chore.
>
>And think about this:  We won't need to write any code to serialize a billion 
>different data structures so they can be sent between nodes.  All we do is 
>output facts as XML, optionally bzip2 and encrypt them, and send them.  (Or, 
>put them through a style sheet so they turn into HTML - this system will 
>actually need a user interface too.)
>
>My next plan is to illustrate the concept by writing some code in Raisen that 
>services an HTTP request.  That's a good example, I think, because it's a 
>basic building block of the Grapevine.
>
>I think we'll also find that the 'domains' concept provides a considerably 
>better security model than Java when we eventually get to sandboxing (which 
>we are definitely not going to do right now).  The problem with Java is that 
>for one package to talk to another, it has to make certain methods public.  
>This means that absolutely every package must be meticulously hardened 
>against attack by untrusted code.  (So, untrusted code can't run in the same 
>VM as third-party code, because the former may exploit security holes in the 
>latter).  With domains in Raisen, things are more precisely specified than 
>just 'public'.
>
>I'm sure the language will have its frustrations, too.  The biggest of which 
>will be that we'll periodically find that it just can't *do* something.  In 
>those situations, we can write that something in C++ and provide a Raisen 
>interface for it.  Remember that it isn't really intended to be a 
>general-purpose language - it's just for this application.
>
>-- And another advantage of this language:  It'll make the Java, Python, 
>PlayStation, WinCE, Palm Pilot, etc, ports of Grapevine easy to write, and 
>there won't be any risk of this leading to Grapevine nodes that don't have 
>the correct logic.  (That was a big problem for Gnutella early on.)
>
>
>Steve
>
>On Friday 05 October 2001 02:48, Anthony Jones wrote:
>
>>Steve,
>>
>>Cool. I understand now.  The big question is - what do we use this for?
>>
>>TJ
>>
>>Stephen Blackheath wrote:
>>
>>>Tony,
>>>
>>>Here's what it all means:
>>>
>>>The facts are describing the attributes of a collection of nine animals.
>>>
>>>The rules are saying "Find me a large cat, a small cat, a dog
>>>with medium hair, and a dog with long hair, all four animals being of the
>>>same colour, where the cats have the same hair length and the dogs are the
>>>same size."
>>>
>>>Out of the nine animals, there is one collection of four animals that
>>>meets this constraint:
>>>
>>> <animal colour="calico" hair="short" size="small" type="cat"/>
>>> <animal colour="calico" hair="medium" size="medium" type="dog"/>
>>> <animal colour="calico" hair="short" size="large" type="cat"/>
>>> <animal colour="calico" hair="long" size="medium" type="dog"/>
>>>
>>>If there were more than one solution, then the rule would fire more than
>>>once.
>>>
>>>The 'a1 == ' , 'a2 == ', etc... bind the matched animals to variables
>>>which can be used later, and so do the [C] [S] and [H].  These variables
>>>can be used anywhere before the rule's semicolon.  So, you could add
>>>commands to the rule that make use of the variables C, S, H, a1, a2, a3
>>>and a4.
>>>
>>>For example, you could add this onto the end of the rules:
>>>
>>> ...rules...,
>>> print "the animals are all coloured "+C;
>>>
>>>
>>>Steve
>>>
>>>On Thursday 04 October 2001 01:28, Anthony Jones wrote:
>>>
>>>>Cool.  It looks like it works.  It doesn't make any sense to me though. 
>>>>I don't know what it's trying to achieve.
>>>>
>>>...
>>>
>>>>><grapevine>
>>>>>
>>>>><demo.animal>
>>>>>
>>>>>  <rules>
>>>>>    a1 == <animal type="cat" colour="[C]" size="small" hair="[H]"/>,
>>>>>    a2 == <animal type="dog" colour="[C]" size="[S]" hair="medium"/>,
>>>>>    a3 == <animal type="cat" colour="[C]" size="large" hair="[H]"/>,
>>>>>    a4 == <animal type="dog" colour="[C]" size="[S]" hair="long"/>;
>>>>>  </rules>
>>>>>
>>>>>  <facts>
>>>>>    <animal type="cat" colour="yellow" size="large"  hair="short"/>
>>>>>    <animal type="cat" colour="calico" size="large"  hair="short"/>
>>>>>    <animal type="cat" colour="calico" size="small"  hair="short"/>
>>>>>    <animal type="dog" colour="brown"  size="medium" hair="long"/>
>>>>>    <animal type="cat" colour="brown"  size="small"  hair="medium"/>
>>>>>    <animal type="dog" colour="brown"  size="small"  hair="short"/>
>>>>>    <animal type="dog" colour="calico" size="medium" hair="medium"/>
>>>>>    <animal type="dog" colour="brown"  size="large"  hair="medium"/>
>>>>>    <animal type="dog" colour="calico" size="medium" hair="long"/>
>>>>>  </facts>
>>>>></demo.animal>
>>>>></grapevine>
>>>>>
>>>.
>>>
>>_______________________________________________
>>Grapevine-devel mailing list
>>Gra...@li...
>>https://lists.sourceforge.net/lists/listinfo/grapevine-devel
>>
>
>

Re: [Grapevine-devel] Animal example now works

[Stephen B. <st...@bl...>]

Tony,

Ah...  You need to look inside my head to understand why I think this is such 
a good idea.

It's possibly a little hard to explain, but I'll try...

I've already explained the advantages because the code can be mobile (in a 
similar way to Java).  But there are good reasons for the language itself.

Think about the problems of writing code for any application that handles TCP 
connections (as this code will).  The way I see it, there are two 
fundamentally different approaches (I think they can correctly be called 
'paradigms'), and most applications will use a bit of both:

  * Threaded:  All state relating to the connection (which can be very 
complex when you have to do any parsing) is contained in a thread.  The 
thread lasts for as long as the connection does.
- Advantages: The code simple to write, because maintaining state is not a 
chore.
- Disadvantages: It doesn't scale well, because if the application gets busy, 
or the connections are of a long duration, then there are a lot of threads 
consuming a lot of memory.

  * Event-driven:  Each event executes in a short period of time - i.e. no 
blocking is allowed.  At the commencement of each event, state must be 
retrieved from memory/disk.  An event then typically makes changes to the 
state of the system before returning.
- Advantage: Efficient management of resources, because when an event isn't 
firing, its state is "on ice" - i.e. you can efficiently cache it to disk, 
etc.  You also completely avoid all the problems of threading - race 
conditions, deadlocks, etc, etc.
- Disadvantage: The code involves a lot of looking things up in hash tables 
and generally mucking about with state.

A typical web application uses both of these:  An HTTP request is itself an 
event.  When it starts, you have no state, and you have to retrieve it based 
on tokens sent in the request.  But the processing of the event is itself 
thread-based.  If the thread has to request something from a database or 
legacy system, then it blocks.

As you know, as much as I like threads (and I do), I have a strong preference 
for the event-driven model.  I am aware that this makes me a little unusual.  
Everybody else thinks I am a masochist.  But I like it, because the logic is 
more "pure".  In some ways, threads tie you down and make you think linearly. 
 When you have a complex application with a lot of things going on, you need 
a lot of threads.  For example, cleaning up unused resources, and handling 
timing-related things like re-sending requests which haven't had a response.  
These two things are often done with threads.  But the second thing starts to 
get complex with threads, and becomes easier in the event-driven model.

In most code people avoid the problem of re-sending requests by simply 
relying on TCP.  This won't necessarily work for our application, because it 
works unusually as far as TCP traffic is concerned:  In a normal TCP 
application, you're talking to ONE remote host, and that's the host you have 
to talk to.  Your job isn't done until you've talked to that host.  That's 
the thought-process behind the design of TCP.  In our application, however, 
if a node isn't responding, we are better off talking to another node that 
is.  And that means we'll need to write extra logic that isn't going to be 
handed to us by the operating system.  Think about how difficult it is to 
write that kind of code in threaded C++.  The thread paradigm is just too 
'linear'.

What this language (the language is called 'Raisen' for the moment) does in 
theory is to take the chore out of the event-driven paradigm.  And writing 
this stuff in C++ is definitely a chore.

And think about this:  We won't need to write any code to serialize a billion 
different data structures so they can be sent between nodes.  All we do is 
output facts as XML, optionally bzip2 and encrypt them, and send them.  (Or, 
put them through a style sheet so they turn into HTML - this system will 
actually need a user interface too.)

My next plan is to illustrate the concept by writing some code in Raisen that 
services an HTTP request.  That's a good example, I think, because it's a 
basic building block of the Grapevine.

I think we'll also find that the 'domains' concept provides a considerably 
better security model than Java when we eventually get to sandboxing (which 
we are definitely not going to do right now).  The problem with Java is that 
for one package to talk to another, it has to make certain methods public.  
This means that absolutely every package must be meticulously hardened 
against attack by untrusted code.  (So, untrusted code can't run in the same 
VM as third-party code, because the former may exploit security holes in the 
latter).  With domains in Raisen, things are more precisely specified than 
just 'public'.

I'm sure the language will have its frustrations, too.  The biggest of which 
will be that we'll periodically find that it just can't *do* something.  In 
those situations, we can write that something in C++ and provide a Raisen 
interface for it.  Remember that it isn't really intended to be a 
general-purpose language - it's just for this application.

-- And another advantage of this language:  It'll make the Java, Python, 
PlayStation, WinCE, Palm Pilot, etc, ports of Grapevine easy to write, and 
there won't be any risk of this leading to Grapevine nodes that don't have 
the correct logic.  (That was a big problem for Gnutella early on.)


Steve

On Friday 05 October 2001 02:48, Anthony Jones wrote:
> Steve,
>
> Cool. I understand now.  The big question is - what do we use this for?
>
> TJ
>
> Stephen Blackheath wrote:
> >Tony,
> >
> >Here's what it all means:
> >
> >The facts are describing the attributes of a collection of nine animals.
> >
> >The rules are saying "Find me a large cat, a small cat, a dog
> >with medium hair, and a dog with long hair, all four animals being of the
> >same colour, where the cats have the same hair length and the dogs are the
> >same size."
> >
> >Out of the nine animals, there is one collection of four animals that
> > meets this constraint:
> >
> >  <animal colour="calico" hair="short" size="small" type="cat"/>
> >  <animal colour="calico" hair="medium" size="medium" type="dog"/>
> >  <animal colour="calico" hair="short" size="large" type="cat"/>
> >  <animal colour="calico" hair="long" size="medium" type="dog"/>
> >
> >If there were more than one solution, then the rule would fire more than
> > once.
> >
> >The 'a1 == ' , 'a2 == ', etc... bind the matched animals to variables
> > which can be used later, and so do the [C] [S] and [H].  These variables
> > can be used anywhere before the rule's semicolon.  So, you could add
> > commands to the rule that make use of the variables C, S, H, a1, a2, a3
> > and a4.
> >
> >For example, you could add this onto the end of the rules:
> >
> >  ...rules...,
> >  print "the animals are all coloured "+C;
> >
> >
> >Steve
> >
> >On Thursday 04 October 2001 01:28, Anthony Jones wrote:
> >>Cool.  It looks like it works.  It doesn't make any sense to me though. 
> >> I don't know what it's trying to achieve.
> >
> >...
> >
> >>><grapevine>
> >>>
> >>> <demo.animal>
> >>>
> >>>   <rules>
> >>>     a1 == <animal type="cat" colour="[C]" size="small" hair="[H]"/>,
> >>>     a2 == <animal type="dog" colour="[C]" size="[S]" hair="medium"/>,
> >>>     a3 == <animal type="cat" colour="[C]" size="large" hair="[H]"/>,
> >>>     a4 == <animal type="dog" colour="[C]" size="[S]" hair="long"/>;
> >>>   </rules>
> >>>
> >>>   <facts>
> >>>     <animal type="cat" colour="yellow" size="large"  hair="short"/>
> >>>     <animal type="cat" colour="calico" size="large"  hair="short"/>
> >>>     <animal type="cat" colour="calico" size="small"  hair="short"/>
> >>>     <animal type="dog" colour="brown"  size="medium" hair="long"/>
> >>>     <animal type="cat" colour="brown"  size="small"  hair="medium"/>
> >>>     <animal type="dog" colour="brown"  size="small"  hair="short"/>
> >>>     <animal type="dog" colour="calico" size="medium" hair="medium"/>
> >>>     <animal type="dog" colour="brown"  size="large"  hair="medium"/>
> >>>     <animal type="dog" colour="calico" size="medium" hair="long"/>
> >>>   </facts>
> >>> </demo.animal>
> >>></grapevine>
> >
> >.
>
> _______________________________________________
> Grapevine-devel mailing list
> Gra...@li...
> https://lists.sourceforge.net/lists/listinfo/grapevine-devel

Re: [Grapevine-devel] Animal example now works

[Anthony J. <aj...@cl...>]

Steve,

Cool. I understand now.  The big question is - what do we use this for?

TJ

Stephen Blackheath wrote:

>Tony,
>
>Here's what it all means:
>
>The facts are describing the attributes of a collection of nine animals.
>
>The rules are saying "Find me a large cat, a small cat, a dog 
>with medium hair, and a dog with long hair, all four animals being of the 
>same colour, where the cats have the same hair length and the dogs are the 
>same size."
>
>Out of the nine animals, there is one collection of four animals that meets 
>this constraint:
>
>  <animal colour="calico" hair="short" size="small" type="cat"/>
>  <animal colour="calico" hair="medium" size="medium" type="dog"/>
>  <animal colour="calico" hair="short" size="large" type="cat"/>
>  <animal colour="calico" hair="long" size="medium" type="dog"/>
>
>If there were more than one solution, then the rule would fire more than once.
>
>The 'a1 == ' , 'a2 == ', etc... bind the matched animals to variables which 
>can be used later, and so do the [C] [S] and [H].  These variables can be 
>used anywhere before the rule's semicolon.  So, you could add commands to the 
>rule that make use of the variables C, S, H, a1, a2, a3 and a4.
>
>For example, you could add this onto the end of the rules:
>
>  ...rules...,
>  print "the animals are all coloured "+C;
>
>
>Steve
>
>On Thursday 04 October 2001 01:28, Anthony Jones wrote:
>
>>Cool.  It looks like it works.  It doesn't make any sense to me though.  I
>>don't know what it's trying to achieve.
>>
>...
>
>>><grapevine>
>>>
>>> <demo.animal>
>>>
>>>   <rules>
>>>     a1 == <animal type="cat" colour="[C]" size="small" hair="[H]"/>,
>>>     a2 == <animal type="dog" colour="[C]" size="[S]" hair="medium"/>,
>>>     a3 == <animal type="cat" colour="[C]" size="large" hair="[H]"/>,
>>>     a4 == <animal type="dog" colour="[C]" size="[S]" hair="long"/>;
>>>   </rules>
>>>
>>>   <facts>
>>>     <animal type="cat" colour="yellow" size="large"  hair="short"/>
>>>     <animal type="cat" colour="calico" size="large"  hair="short"/>
>>>     <animal type="cat" colour="calico" size="small"  hair="short"/>
>>>     <animal type="dog" colour="brown"  size="medium" hair="long"/>
>>>     <animal type="cat" colour="brown"  size="small"  hair="medium"/>
>>>     <animal type="dog" colour="brown"  size="small"  hair="short"/>
>>>     <animal type="dog" colour="calico" size="medium" hair="medium"/>
>>>     <animal type="dog" colour="brown"  size="large"  hair="medium"/>
>>>     <animal type="dog" colour="calico" size="medium" hair="long"/>
>>>   </facts>
>>> </demo.animal>
>>></grapevine>
>>>
>
>.
>

Re: [Grapevine-devel] Animal example now works

[Stephen B. <st...@bl...>]

Tony,

Here's what it all means:

The facts are describing the attributes of a collection of nine animals.

The rules are saying "Find me a large cat, a small cat, a dog 
with medium hair, and a dog with long hair, all four animals being of the 
same colour, where the cats have the same hair length and the dogs are the 
same size."

Out of the nine animals, there is one collection of four animals that meets 
this constraint:

  <animal colour="calico" hair="short" size="small" type="cat"/>
  <animal colour="calico" hair="medium" size="medium" type="dog"/>
  <animal colour="calico" hair="short" size="large" type="cat"/>
  <animal colour="calico" hair="long" size="medium" type="dog"/>

If there were more than one solution, then the rule would fire more than once.

The 'a1 == ' , 'a2 == ', etc... bind the matched animals to variables which 
can be used later, and so do the [C] [S] and [H].  These variables can be 
used anywhere before the rule's semicolon.  So, you could add commands to the 
rule that make use of the variables C, S, H, a1, a2, a3 and a4.

For example, you could add this onto the end of the rules:

  ...rules...,
  print "the animals are all coloured "+C;


Steve

On Thursday 04 October 2001 01:28, Anthony Jones wrote:
> Cool.  It looks like it works.  It doesn't make any sense to me though.  I
> don't know what it's trying to achieve.
...
> ><grapevine>
> >
> >  <demo.animal>
> >
> >    <rules>
> >      a1 == <animal type="cat" colour="[C]" size="small" hair="[H]"/>,
> >      a2 == <animal type="dog" colour="[C]" size="[S]" hair="medium"/>,
> >      a3 == <animal type="cat" colour="[C]" size="large" hair="[H]"/>,
> >      a4 == <animal type="dog" colour="[C]" size="[S]" hair="long"/>;
> >    </rules>
> >
> >    <facts>
> >      <animal type="cat" colour="yellow" size="large"  hair="short"/>
> >      <animal type="cat" colour="calico" size="large"  hair="short"/>
> >      <animal type="cat" colour="calico" size="small"  hair="short"/>
> >      <animal type="dog" colour="brown"  size="medium" hair="long"/>
> >      <animal type="cat" colour="brown"  size="small"  hair="medium"/>
> >      <animal type="dog" colour="brown"  size="small"  hair="short"/>
> >      <animal type="dog" colour="calico" size="medium" hair="medium"/>
> >      <animal type="dog" colour="brown"  size="large"  hair="medium"/>
> >      <animal type="dog" colour="calico" size="medium" hair="long"/>
> >    </facts>
> >  </demo.animal>
> ></grapevine>

Re: [Grapevine-devel] Animal example now works

[Anthony J. <aj...@cl...>]

Steve,

Cool.  It looks like it works.  It doesn't make any sense to me though.  I don't
know what it's trying to achieve.

TJ


>Everyone,
>
>The animal example now works.  Here's the input:
>
><?xml version="1.0"?>
><!-- $Id: animal.xml,v 1.1 2001/10/03 10:55:11 blackh Exp $ -->
> 
><grapevine>
> 
>  <demo.animal>
> 
>    <rules>
>      a1 == <animal type="cat" colour="[C]" size="small" hair="[H]"/>,
>      a2 == <animal type="dog" colour="[C]" size="[S]" hair="medium"/>,
>      a3 == <animal type="cat" colour="[C]" size="large" hair="[H]"/>,
>      a4 == <animal type="dog" colour="[C]" size="[S]" hair="long"/>;
>    </rules>
> 
>    <facts>
>      <animal type="cat" colour="yellow" size="large"  hair="short"/>
>      <animal type="cat" colour="calico" size="large"  hair="short"/>
>      <animal type="cat" colour="calico" size="small"  hair="short"/>
>      <animal type="dog" colour="brown"  size="medium" hair="long"/>
>      <animal type="cat" colour="brown"  size="small"  hair="medium"/>
>      <animal type="dog" colour="brown"  size="small"  hair="short"/>
>      <animal type="dog" colour="calico" size="medium" hair="medium"/>
>      <animal type="dog" colour="brown"  size="large"  hair="medium"/>
>      <animal type="dog" colour="calico" size="medium" hair="long"/>
>    </facts>
>  </demo.animal>
></grapevine>
>
>
>And here's the output:
>
>a1==<animal colour="[1]" hair="[2]" size="small" type="cat"/>,
>----------------------------------------
>  ## match <animal colour="[1]" hair="[2]" size="small" type="cat"/>
>  ## ref [0]
>  ## bind
>----------------------------------------
>a2==<animal colour="[1]" hair="medium" size="[4]" type="dog"/>,
>----------------------------------------
>  ## match <animal colour="[1]" hair="medium" size="[4]" type="dog"/>
>  ## ref [3]
>  ## bind
>----------------------------------------
>a3==<animal colour="[1]" hair="[2]" size="large" type="cat"/>,
>----------------------------------------
>  ## match <animal colour="[1]" hair="[2]" size="large" type="cat"/>
>  ## ref [5]
>  ## bind
>----------------------------------------
>a4==<animal colour="[1]" hair="long" size="[4]" type="dog"/>;
>----------------------------------------
>  ## match <animal colour="[1]" hair="long" size="[4]" type="dog"/>
>  ## ref [6]
>  ## bind
>----------------------------------------
>
>OPTIMIZED CODE
>  ## match [0] == <animal colour="[1]" hair="[2]" size="small" type="cat"/>

>  ## match [3] == <animal colour="[1]" hair="medium" size="[4]" type="dog"/>

>  ## match [5] == <animal colour="[1]" hair="[2]" size="large" type="cat"/>

>  ## match [6] == <animal colour="[1]" hair="long" size="[4]" type="dog"/>

>
>** RULE FIRED **
>  [0] = <animal colour="calico" hair="short" size="small" type="cat"/>
>  [1] = calico
>  [2] = short
>  [3] = <animal colour="calico" hair="medium" size="medium" type="dog"/>
>  [4] = medium
>  [5] = <animal colour="calico" hair="short" size="large" type="cat"/>
>  [6] = <animal colour="calico" hair="long" size="medium" type="dog"/>
> 
>Success.
>
>_______________________________________________
>Grapevine-devel mailing list
>Gra...@li...
>https://lists.sourceforge.net/lists/listinfo/grapevine-devel
>
>

Re: [Grapevine-devel] Animal example now works

[Anthony J. <aj...@cl...>]

Steve,

Cool.  It looks like it works.  It doesn't make any sense to me though.  I don't
know what it's trying to achieve.

TJ


>Everyone,
>
>The animal example now works.  Here's the input:
>
><?xml version="1.0"?>
><!-- $Id: animal.xml,v 1.1 2001/10/03 10:55:11 blackh Exp $ -->
> 
><grapevine>
> 
>  <demo.animal>
> 
>    <rules>
>      a1 == <animal type="cat" colour="[C]" size="small" hair="[H]"/>,
>      a2 == <animal type="dog" colour="[C]" size="[S]" hair="medium"/>,
>      a3 == <animal type="cat" colour="[C]" size="large" hair="[H]"/>,
>      a4 == <animal type="dog" colour="[C]" size="[S]" hair="long"/>;
>    </rules>
> 
>    <facts>
>      <animal type="cat" colour="yellow" size="large"  hair="short"/>
>      <animal type="cat" colour="calico" size="large"  hair="short"/>
>      <animal type="cat" colour="calico" size="small"  hair="short"/>
>      <animal type="dog" colour="brown"  size="medium" hair="long"/>
>      <animal type="cat" colour="brown"  size="small"  hair="medium"/>
>      <animal type="dog" colour="brown"  size="small"  hair="short"/>
>      <animal type="dog" colour="calico" size="medium" hair="medium"/>
>      <animal type="dog" colour="brown"  size="large"  hair="medium"/>
>      <animal type="dog" colour="calico" size="medium" hair="long"/>
>    </facts>
>  </demo.animal>
></grapevine>
>
>
>And here's the output:
>
>a1==<animal colour="[1]" hair="[2]" size="small" type="cat"/>,
>----------------------------------------
>  ## match <animal colour="[1]" hair="[2]" size="small" type="cat"/>
>  ## ref [0]
>  ## bind
>----------------------------------------
>a2==<animal colour="[1]" hair="medium" size="[4]" type="dog"/>,
>----------------------------------------
>  ## match <animal colour="[1]" hair="medium" size="[4]" type="dog"/>
>  ## ref [3]
>  ## bind
>----------------------------------------
>a3==<animal colour="[1]" hair="[2]" size="large" type="cat"/>,
>----------------------------------------
>  ## match <animal colour="[1]" hair="[2]" size="large" type="cat"/>
>  ## ref [5]
>  ## bind
>----------------------------------------
>a4==<animal colour="[1]" hair="long" size="[4]" type="dog"/>;
>----------------------------------------
>  ## match <animal colour="[1]" hair="long" size="[4]" type="dog"/>
>  ## ref [6]
>  ## bind
>----------------------------------------
>
>OPTIMIZED CODE
>  ## match [0] == <animal colour="[1]" hair="[2]" size="small" type="cat"/>

>  ## match [3] == <animal colour="[1]" hair="medium" size="[4]" type="dog"/>

>  ## match [5] == <animal colour="[1]" hair="[2]" size="large" type="cat"/>

>  ## match [6] == <animal colour="[1]" hair="long" size="[4]" type="dog"/>

>
>** RULE FIRED **
>  [0] = <animal colour="calico" hair="short" size="small" type="cat"/>
>  [1] = calico
>  [2] = short
>  [3] = <animal colour="calico" hair="medium" size="medium" type="dog"/>
>  [4] = medium
>  [5] = <animal colour="calico" hair="short" size="large" type="cat"/>
>  [6] = <animal colour="calico" hair="long" size="medium" type="dog"/>
> 
>Success.
>
>_______________________________________________
>Grapevine-devel mailing list
>Gra...@li...
>https://lists.sourceforge.net/lists/listinfo/grapevine-devel
>
>

[Grapevine-devel] Animal example now works

[Stephen B. <st...@bl...>]

Everyone,

The animal example now works.  Here's the input:

<?xml version="1.0"?>
<!-- $Id: animal.xml,v 1.1 2001/10/03 10:55:11 blackh Exp $ -->
 
<grapevine>
 
  <demo.animal>
 
    <rules>
      a1 == <animal type="cat" colour="[C]" size="small" hair="[H]"/>,
      a2 == <animal type="dog" colour="[C]" size="[S]" hair="medium"/>,
      a3 == <animal type="cat" colour="[C]" size="large" hair="[H]"/>,
      a4 == <animal type="dog" colour="[C]" size="[S]" hair="long"/>;
    </rules>
 
    <facts>
      <animal type="cat" colour="yellow" size="large"  hair="short"/>
      <animal type="cat" colour="calico" size="large"  hair="short"/>
      <animal type="cat" colour="calico" size="small"  hair="short"/>
      <animal type="dog" colour="brown"  size="medium" hair="long"/>
      <animal type="cat" colour="brown"  size="small"  hair="medium"/>
      <animal type="dog" colour="brown"  size="small"  hair="short"/>
      <animal type="dog" colour="calico" size="medium" hair="medium"/>
      <animal type="dog" colour="brown"  size="large"  hair="medium"/>
      <animal type="dog" colour="calico" size="medium" hair="long"/>
    </facts>
  </demo.animal>
</grapevine>


And here's the output:

a1==<animal colour="[1]" hair="[2]" size="small" type="cat"/>,
----------------------------------------
  ## match <animal colour="[1]" hair="[2]" size="small" type="cat"/>
  ## ref [0]
  ## bind
----------------------------------------
a2==<animal colour="[1]" hair="medium" size="[4]" type="dog"/>,
----------------------------------------
  ## match <animal colour="[1]" hair="medium" size="[4]" type="dog"/>
  ## ref [3]
  ## bind
----------------------------------------
a3==<animal colour="[1]" hair="[2]" size="large" type="cat"/>,
----------------------------------------
  ## match <animal colour="[1]" hair="[2]" size="large" type="cat"/>
  ## ref [5]
  ## bind
----------------------------------------
a4==<animal colour="[1]" hair="long" size="[4]" type="dog"/>;
----------------------------------------
  ## match <animal colour="[1]" hair="long" size="[4]" type="dog"/>
  ## ref [6]
  ## bind
----------------------------------------

OPTIMIZED CODE
  ## match [0] == <animal colour="[1]" hair="[2]" size="small" type="cat"/>
  ## match [3] == <animal colour="[1]" hair="medium" size="[4]" type="dog"/>
  ## match [5] == <animal colour="[1]" hair="[2]" size="large" type="cat"/>
  ## match [6] == <animal colour="[1]" hair="long" size="[4]" type="dog"/>

** RULE FIRED **
  [0] = <animal colour="calico" hair="short" size="small" type="cat"/>
  [1] = calico
  [2] = short
  [3] = <animal colour="calico" hair="medium" size="medium" type="dog"/>
  [4] = medium
  [5] = <animal colour="calico" hair="short" size="large" type="cat"/>
  [6] = <animal colour="calico" hair="long" size="medium" type="dog"/>
 
Success.

[Grapevine-devel] Today's progress - the idea of 'domains'

[Stephen B. <st...@bl...>]

Hi everyone,

Today's effort was inventing and implementing a new idea called 'domains' in 
the inference engine, as well as getting further with the parser and 
optimizer.

'Domains' are like namespaces or packages in Java.  Rules and facts are 
defined within them.  There are also access controls that are the reverse of 
Java.  That it, you have to list who your friends (in the C++ sense) are.  
Inside an <access> tag, a domain lists the other domains which have read 
and/or write access to it.  The purpose of this is to get good encapsulation.

Let's say you're writing the code in a server that makes nice HTML pages.  
You will want to send and receive HTTP connections.  To do this, you 'call' 
the functionality in a domain that has the purpose of writing data in and out 
of an HTTP connection.  The domain might look like this:

  <sys.io.httpConn>
    <access>
      <sys.servlet.engine>RW</sys.servlet.engine>
    </access>

      <!-- rules go here -->

  </sys.io.httpConn>

You will want to write a string to it.  To do that, this is the code that you 
would add to the rule you're writing:

assert
  <sys.io.httpConn.write connId="7">...data...</sys.io.httpConn.write>;

Expressing it the following way would have the same meaning

  <sys>
    <io>
      <httpConn>
        <write connId="7">...data...</write>
      </httpConn>
    </io>
  </sys>

That rule would then trigger rules inside <sys.io.httpConn/>.  For example:

    <!-- The 'description' tag is just there for the halibut.
      It has no other function than to supply extra useful
      information that might be useful later.
      That's the beauty of XML.  -->
  <sys.io.httpConn description="HTTP connection">
    <access>
      <sys.servlet.engine>RW</sys.servlet.engine>
    </access>

    <rules>

        <!-- Note that unqualified tag names have an implied domain
            of 'sys.io.httpConn', so the tag below is equivalent to
            <sys.io.httpConn:write> ... -->
      <write connId="[connId]">,

             <!-- If we have got headers to be output -->
        <headers connId="[connId]">[text]</headers>

          <!-- OK, let's try writing the code that dumps your HTTP
            header out the socket...  This would call on the 'sys.io.socket'
            domain to do a socket write. -->
        assert
          <sys.out.socket.write connId="[connId]"/>
            [text]
          </sys.out.socket.write>;

    </rules>

    <facts>
      <said who="Noam Chomsky">
        "Freedom without opportunity is a devil's gift."
      </said>
    </facts>

  </sys.io.httpConn>

So it actually looks quite a lot like a class with methods.

We probably need private facts.  How about this as a way to do it...

  ** a 'public' declaration that declares certain initial fact tags as being 
public, e.g.

  <sys.io.httpConn description="HTTP connection">
    <access>
      <sys.servlet.engine>RW</sys.servlet.engine>
    </access>

    <public>
      <read/>
      <write/>
    </public>

      <!- ... -->

  </sys.io.httpConn>


--------
ORWELLIAN FUTURE

Obviously if your local machine does not know what the code is for a certain 
domain, it can just hash it into a Grapevine key and fetch the XML for it off 
Grapevine, compile the rules, and then execute them locally (sandboxed 
Java-applet-style).  That downloaded XML might act as a proxy to some remote 
on-line service.  The power of this technology is potentially fairly awesome.

But before we get there, we have to painstakingly wire up the little brain 
that will make the Grapevine network hang together.


Steve

[Grapevine-devel] Re: Grapevine progress

[Stephen B. <st...@bl...>]

Tony,

The inference engines I know about are

  - CLIPS  <-- hateful syntax, but otherwise would be OK
  - Prolog (e.g. Ciao prolog)
  - Jess (in Java)  <-- commercial licence
  - Venus  <-- similar to CLIPS I think

The only objective reason not to use one of the above is that they aren't 
XML-oriented.  I realize we don't *need* this thing to process XML, but I 
think it will pay dividends in the future.

Subjective reasons include
  - I prefer CLIPS, but I can't abide the syntax.
  - All of the above are 3 MB beasts.

Here's another reason in favour of using an inference engine:
  - In the early stages of deployment it'll make it easier to avoid the 
problem that Gnutella had where there were lots of different versions out 
there.  The code will be able to load new versions of the logic without being 
re-installed.

I'm not quite as good at using other people's code as I should be.  (But then 
probably everyone has that problem.)  However, I think the inference engine 
itself isn't going to be tooooo much work, but we'll see in the next day or 
so.

At least I'm finally using STL now.


Steve

On Monday 01 October 2001 19:18, you wrote:
> Steve,
>
> Just thought I'd ask.  I trust your judgement.  I am just weary of
> "creating another language".  I think that overall this makes applications
> harder to debug and less accessible to developers.
>
> I assume that you've already looked for existing inference engines?  I
> wouldn't want to duplicate development and debugging unless it is
> necessary.
>
> I also agree that there are many parts to the project that can be done by
> other developers.  I'm going to work on the roadmap either today or
> tomorrow to try to help the project look like it has direction.
>
> TTFN
>
> TJ
>
> >Tony,
> >
> >Good question.  And, I hadn't thought about accessibility to developers.
> >
> >Yes, it probably will be more difficult from that point of view.
> >
> >However, I have thought about whether this will make the job easier
> > overall,
> >
> >and I believe it will.  Here are my reasons
> >
> >- I've thought about the logic and how it can be expressed, and I've tried
> >
> >writing a whole lot of logic in it (see paper1/doc/language-example1.xml).
>
> I
>
> >think this language will make the logic easier to write.  And, there's
> > going
> >
> >to be a LOT of logic in this thing with all the reputation strategies and
> > so
> >
> >on.
> >- I know that I'm not far off having the engine written, and that was what
>
> I
>
> >saw as the biggest obstacle.
> >
> >Although I'm fairly convinced, I'm prepared to treat this as an
> > experiment.
> >
> >If it fails, I'll just take the inference engine and release it as an
> >inference engine.  I promise to keep my mind open.
> >
> >So I'll just ask you to bear with me for now - we can ask this question
> >again once I've written the engine and we've had a chance to play with it
> > a
> >
> >bit.  I'm expecting to have it basically working tomorrow.
> >
> >Also, don't forget - there's a lot of code that has to be written in
> > addition
> >
> >to the logic and logic engine, including I/O, geometry, encryption, data
> >storage, and HTTP-based user interface.  So, there's plenty for other
> >developers to do.
> >
> >
> >Steve

[Grapevine-devel] Re: Grapevine progress

[Stephen B. <st...@bl...>]

On Monday 01 October 2001 18:47, you wrote:
> Steve,
>
> I have a question here:
>
> Are you sure you know what you're doing?  I'm playing the role of Tony the
> conservative here.  Can you please explain to me why you're doing it this
> way and how this makes the problem simpler?  I'm looking at it and asking
> myself if this is going to make the project less accessible to developers.
>
> TJ

Tony,

Good question.  And, I hadn't thought about accessibility to developers.  
Yes, it probably will be more difficult from that point of view.

However, I have thought about whether this will make the job easier overall, 
and I believe it will.  Here are my reasons

- I've thought about the logic and how it can be expressed, and I've tried 
writing a whole lot of logic in it (see paper1/doc/language-example1.xml). I 
think this language will make the logic easier to write.  And, there's going 
to be a LOT of logic in this thing with all the reputation strategies and so 
on.
- I know that I'm not far off having the engine written, and that was what I 
saw as the biggest obstacle.

Although I'm fairly convinced, I'm prepared to treat this as an experiment.  
If it fails, I'll just take the inference engine and release it as an 
inference engine.  I promise to keep my mind open.

So I'll just ask you to bear with me for now - we can ask this question 
again once I've written the engine and we've had a chance to play with it a 
bit.  I'm expecting to have it basically working tomorrow.

Also, don't forget - there's a lot of code that has to be written in addition 
to the logic and logic engine, including I/O, geometry, encryption, data 
storage, and HTTP-based user interface.  So, there's plenty for other 
developers to do.


Steve

[Grapevine-devel] cvs: CVSROOT / loginfo

[rossta <gra...@li...>]

rossta		Sun Sep 30 15:11:56 2001 EDT

  Modified files:              
    /CVSROOT	loginfo 
  Log:
  
  
Index: CVSROOT/loginfo
diff -u CVSROOT/loginfo:1.2 CVSROOT/loginfo:1.3
--- CVSROOT/loginfo:1.2	Sun Sep 30 11:11:00 2001
+++ CVSROOT/loginfo	Sun Sep 30 15:11:55 2001
@@ -1,5 +1,5 @@
 #
-#ident	"@(#)cvs/examples:$Name:  $:$Id: loginfo,v 1.2 2001/09/30 18:11:00 rossta Exp $"
+#ident	"@(#)cvs/examples:$Name:  $:$Id: loginfo,v 1.3 2001/09/30 22:11:55 rossta Exp $"
 #
 # The "loginfo" file is used to control where "cvs commit" log information
 # is sent.  The first entry on a line is a regular expression which is tested
@@ -42,6 +42,6 @@
 
 # change this to gra...@li... when list is up
 
-DEFAULT	$CVSROOT/CVSROOT/loginfo.pl gra...@li... $USER %{sVv}
+DEFAULT	$CVSROOT/CVSROOT/loginfo.pl gra...@li... $USER %{sVv}
 
 #ALL $CVSROOT/CVSROOT/dolog.pl -r /repository bon...@pa... 

[Grapevine-devel] Overview of what's going on

[Stephen B. <st...@bl...>]

All,

CVS:
There are some UML diagrams in the paper1/doc directory (in ArgoUML).  paper1 
also contains a couple of Java prototypes.  There's the really early 
prototype that basically proves that the concept works (paper1/sim).  There's 
the N-dimensional wedge program in paper1/geometry.  paper1/images contains 
website-related stuff.  paper1/engine contains a prototype of the Rete 
algorithm written in Java.

And, the inference engine in proto1/ actually runs, but isn't finished yet 
and hasn't got a parser yet.

---
I've decided to take a radical approach to implementing the Grapevine.

I'm writing an XML-based inference engine, and the bulk of the application 
will be written in the inference engine's language.  (This also has the 
advantage that it makes my dream of remote agents that much closer: Just add 
sandboxing.)

I've spent the last two days solidly writing code, and I've implemented the 
basic Rete algorithm on a structure that resembles XML in C++.

Rete is a fast pattern-matching algorithm that works when you have a small 
number of rules and a large amount of data (just like we got).

I'm completely public now (not that anyone has looked), so you'll find 
*everything* in the SourceForge project.  http://grapevine.sourceforge.net/  
The aforementioned code is in proto1/ in cvs.

OK, here's a brief intro to the language (which needs a name).

Firstly, it looks a bit like Prolog, but works more like CLIPS.  I decided 
against coding the language in XML tags, because that makes it very hard to 
read.  The way I have decided, facts look like XML, and logic looks like 
prolog, so there is a clear distinction between them.

Firstly, facts look like XML.  For example this fact says that a message was 
received from a remote node requesting a file.

  <received>
    <from><node loc="fe73e7af12889fa"></from>
    <request ref="839fea99be90">
      <key chk="9348234980f990"/>
    </request>
  </received>

And this fact might mean that we have the file stored:

  <file>
    <key chk="9348234980f990"/>
    <content-type>public/html</content-type>
    <data>9348234980f9909348234980f9909348234980f9...</data>
  </file>

Now let's write the logic that retrieves this file:

    <!-- if we got a request for [chk] -->
  recv=<recv ref="[yourRef]"><request><key chk="[chk]"/></request></recv>,
    <!-- and if we've got a file with a matching key -->
  file=<file><key chk="[chk]"/>/></file>,
    <!-- then clear the request out of the knowledge base -->
  retract recv,
    <!-- reply to sender with data -->
  assert
    <send ref="[yourRef]">
      [recv/to]
      [file/data]
    </send>;

Now I expect you're asking yourselves what the fuck this means.

Well, ...

A rule is a list of patterns/statements separated by commas, and terminated 
by a semicolon.

PIeces of XML are patterns that are matched against the knowledge base.

There are 4 ways to bind variables:
  1. By putting 'var=' before something, e.g. recv=<recv/> means that when 
you reference 'recv' in future, it'll refer to the fact that was found out of 
the knowledge base.
  2. You can do the same *inside* a pattern, but it has to be surrounded by 
square brackets, e.g.  <recv>[req=]<request/></recv> means that from there 
on, 'req' will refer to the <request> tag inside the fact.
  3. You can bind variables in an attribute value by putting the variable 
name in square brackets, e.g.  <recv ref="[yourRef]"/>
  4. Similarly, variable name inside [ ] binds to the text inside an XML tag, 
e.g. <file><data>[data]</data></file> 

'assert' and 'retract' add and remove facts from the knowledge base 
respectively.  There can be any number of other 'procedural-style' commands 
in case we need to do I/O, etc.  There's no point in the rule where you stop 
matching patterns and you start executing commands - you can mix them.

There will also be if-then-else as follows:

  {
    <!-- if and then -->
  ||

    <!-- else -->
  }

When you put expressions inside square brackets, they're evaluated.  You can 
use '/' to navigate the XML tree (and # for attributes), e.g. file.key#chk 
refers to <file><key chk="**this**"/>

You can also bind a variable to an expression, e.g. 
requestKeyHash=recv/req/key#chk


Steve

[Grapevine-devel] cvs: proto1 / README

[rossta <gra...@li...>]

rossta		Sun Sep 30 12:39:35 2001 EDT

  Modified files:              
    /proto1	README 
  Log:
  
  
Index: proto1/README
diff -u proto1/README:1.3 proto1/README:1.4
--- proto1/README:1.3	Sun Sep 30 12:38:13 2001
+++ proto1/README	Sun Sep 30 12:39:35 2001
@@ -1,4 +1,4 @@
-$Id: README,v 1.3 2001/09/30 19:38:13 rossta Exp $
+$Id: README,v 1.4 2001/09/30 19:39:35 rossta Exp $
 
 You will need to install the xerces library in order to compile grapevine.
 
@@ -20,11 +20,16 @@
 
 % ./a
 
-to run autoconf/automake and ./configure
+to run autoconf/automake and ./configure.
 
-then, type:
+Then type:
 
 % make
 
+to build grapevine.
+
 After that, you only need to run ./a if you change Makefile.am or configure.in.
 
+To run grapevine, type:
+
+% grapevine

[Grapevine-devel] cvs: proto1 / README

[rossta <gra...@li...>]

rossta		Sun Sep 30 12:38:13 2001 EDT

  Modified files:              
    /proto1	README 
  Log:
  
  
Index: proto1/README
diff -u proto1/README:1.2 proto1/README:1.3
--- proto1/README:1.2	Sun Sep 30 12:16:07 2001
+++ proto1/README	Sun Sep 30 12:38:13 2001
@@ -1,4 +1,4 @@
-$Id: README,v 1.2 2001/09/30 19:16:07 rossta Exp $
+$Id: README,v 1.3 2001/09/30 19:38:13 rossta Exp $
 
 You will need to install the xerces library in order to compile grapevine.
 
@@ -15,3 +15,16 @@
 http://xml.apache.org/xerces-c/build.html.
 
 I couldn't find cvs access to the source, but I didn't look too hard.
+
+Once you have xerces installed, type:
+
+% ./a
+
+to run autoconf/automake and ./configure
+
+then, type:
+
+% make
+
+After that, you only need to run ./a if you change Makefile.am or configure.in.
+

[Grapevine-devel] cvs: CVSROOT / loginfo.pl

[rossta <gra...@li...>]

rossta		Sun Sep 30 12:17:51 2001 EDT

  Modified files:              
    /CVSROOT	loginfo.pl 
  Log:
  Fixed type
  
Index: CVSROOT/loginfo.pl
diff -u CVSROOT/loginfo.pl:1.1 CVSROOT/loginfo.pl:1.2
--- CVSROOT/loginfo.pl:1.1	Sun Sep 30 11:11:00 2001
+++ CVSROOT/loginfo.pl	Sun Sep 30 12:17:51 2001
@@ -17,7 +17,7 @@
 $SIG{PIPE} = 'IGNORE';
 
 my $last_file  = "/var/tmp/grapevine-cvs-lastdir"; # "/var/cvs/lastdir";
-my $summary    = "/var/tmp/grapevine-cvs-summary"; "/var/cvs/summary";
+my $summary    = "/var/tmp/grapevine-cvs-summary"; #"/var/cvs/summary";
 my $smtpserver = "127.0.0.1";
 my $smtpport   = 25;
 my $cvs        = "/usr/bin/cvs";

[Grapevine-devel] cvs: proto1 / .cvsignore

[rossta <gra...@li...>]

rossta		Sun Sep 30 12:17:31 2001 EDT

  Added files:                 
    /proto1	.cvsignore 
  Log:
  Added .cvsignore
  

Index: proto1/.cvsignore
+++ proto1/.cvsignore
# $Id: .cvsignore,v 1.1 2001/09/30 19:17:31 rossta Exp $

deps
config.cache
config.log
config.status
configure
grapevine
Makefile
Makefile.in

[Grapevine-devel] cvs: proto1 / Engine.cpp Engine.h Fact.cpp Fact.h FactListener.h Makefile.am Object.cpp Object.h Operation.cpp Operation.h README Rule.cpp Rule.h RuleListener.h a configure.in grapevine.cpp utils.h

[rossta <gra...@li...>]

rossta		Sun Sep 30 12:16:07 2001 EDT

  Modified files:              
    /proto1	Engine.cpp Engine.h Fact.cpp Fact.h FactListener.h 
           	Makefile.am Object.cpp Object.h Operation.cpp Operation.h 
           	README Rule.cpp Rule.h RuleListener.h a configure.in 
           	grapevine.cpp utils.h 
  Log:
  Added $Id$ to all files, added build instructions to README
  

[Grapevine-devel] cvs: CVSROOT / modules

[rossta <gra...@li...>]

rossta		Sun Sep 30 11:12:24 2001 EDT

  Modified files:              
    /CVSROOT	modules 
  Log:
  Testing new email commits system
  
Index: CVSROOT/modules
diff -u CVSROOT/modules:1.2 CVSROOT/modules:1.3
--- CVSROOT/modules:1.2	Sun Sep 30 11:11:00 2001
+++ CVSROOT/modules	Sun Sep 30 11:12:24 2001
@@ -1,7 +1,7 @@
 #
 # The CVS Modules File
 #
-#ident	"@(#)cvs/examples:$Name:  $:$Id: modules,v 1.2 2001/09/30 18:11:00 rossta Exp $"
+#ident	"@(#)cvs/examples:$Name:  $:$Id: modules,v 1.3 2001/09/30 18:12:24 rossta Exp $"
 #
 # Three different line formats are valid:
 #	key	-a    aliases...
@@ -31,5 +31,5 @@
 # Convenient aliases
 #world		-a .
 
-# Modules to be seen by Bonsai
-#php4 php4
+# testing new commit email system
+#grapevine grapevine