Merge pull request #141 from olafmeneses/fix-documentation-typos

Fix minor typos in documentation

Author: javipalanca

docs/agents.rst

@@ -75,7 +75,7 @@ As you know, messages are the basis of every MAS. They are the centre of the who
 in which MAS are based. So it is very important to understand which facilities are present in SPADE to work with
 agent messages.
 
-First and foremost, threre is a ``Message`` class. This class is ``spade.message.Message`` and you can instantiate it to
+First and foremost, there is a ``Message`` class. This class is ``spade.message.Message`` and you can instantiate it to
 create new messages to work with. The class provides a method to introduce metadata into messages, this is useful for
 using the fields present in standard FIPA-ACL Messages. When a message is ready to be sent, it can be passed on to the
 send() method of the behaviour, which will trigger the internal communication process to actually send it to its

docs/behaviours.rst

@@ -235,7 +235,7 @@ and, of course, use the ``send`` and ``receive`` coroutines to be able to intera
 
 Transitions in a ``FSMBehaviour`` define from which state to which state it is allowed to transit. A ``State`` defines
 its transit to another state by using the ``set_next_state`` method in its ``run`` coroutine.
-By using the ``set_next_state`` method a state dinamically expresses to which state it transits when it finishes. After
+By using the ``set_next_state`` method a state dynamically expresses to which state it transits when it finishes. After
 running a state, the FSM reads this *next_state* value and, if the transition is valid, it transits to that state.
 
 .. warning:: If the transition is not registered it raises a ``NotValidTransition`` exception and the FSM behaviour is
@@ -291,7 +291,7 @@ transit to::
             print("I'm at state three (final state)")
             msg = await self.receive(timeout=5)
             print(f"State Three received message {msg.body}")
-            # no final state is setted, since this is a final state
+            # no final state is set, since this is a final state
 
 
     class FSMAgent(Agent):

docs/usage.rst

@@ -125,8 +125,8 @@ the following output
 And that's it! We have built our first SPADE Agent in 6 lines of code. Easy, isn't it? Of course, this is a very very
 dumb agent that does nothing, but it serves well as a starting point to understand the logics behind SPADE.
 
-.. note:: A SPADE agent is an asyncronous agent. That means that all the code to run an agent must be executed in an
-    asyncronous loop. This is done by the ``spade.run()`` function. This function receives a coroutine as a parameter
+.. note:: A SPADE agent is an asynchronous agent. That means that all the code to run an agent must be executed in an
+    asynchronous loop. This is done by the ``spade.run()`` function. This function receives a coroutine as a parameter
     and runs it in an async loop. In our example, the ``main()`` coroutine is the one that is run in the loop.
 
 .. note:: If you need to run a set of agents in parallel you can use the ``spade.start_agents(agent_list)`` function. This function

docs/web.rst

@@ -35,7 +35,7 @@ click the behaviour's name to see more information about it as in the next image
   :alt: SPADE behaviour page
 
 In this page you can check some important information about the behaviour such as its mailbox, the template with which
-it was registered, wether if it is killed or not or its exit code. Also, each type of behaviour may show any information
+it was registered, whether it is killed or not or its exit code. Also, each type of behaviour may show any information
 related with its internal data, e.g. in the previous image you can see that the behaviour is an FSMBehaviour and the
 interface shows the current state where the FSM is and an image with the structure of the FSM.
 Finally, you can also check all the messages that have been sent or received from/to this behaviour in the chat box.