Added entries to the blob

docs/blog.rst

@@ -68,8 +68,9 @@ To define a new concept
     def concept hello a as "hello" + a
 
 
-Note that the traditional quotes that would surround hello a are not necessary.
+Note that the traditional quotes that would surround 'hello' and 'a' are not necessary.
-In this example 'a' is a variable, as it appears as variable in the 'as' section
+In this example 'a' is a variable, as it appears as variable in the 'as' section (while hello
+appears as a string)
 
 So, you could call the concept by
 
@@ -101,6 +102,8 @@ As I said previously, I mimic how git_ versions its objects.
             modification date = <a date>
             digest = zzzzz
 
+    and so on...
+
 I always keep a reference to the last version of the object, so I can navigate through
 the versions using the :code:`parents` attribute of the object
 
@@ -150,13 +153,13 @@ For example, for the exercise called "The descent" you will find
     For each round of play :
         Reset the variables containing the index of the highest mountain and its height to 0
         For each mountain index (from 0 to 7 included) :
-            Read the height of the mountain (variable :code:`mountainH`) from stdin
+            Read the height of the mountain (variable 'mountainH') from stdin
             If it's higher than the highest known mountain, save its index and height
         Returns the index of the highest mountain on stdout
 
-It will be great if Sheerka is able to produce some code from these instructions.
+It will be great if Sheerka is able to produce some code from these instructions :-)
 
-Some words data persistence
+Some words on data persistence
 """""""""""""""""""""""""""""""""""""""""
 As I previously said (or not), the main difference between Sheerka and other languages,
 is that Sheerka has a memory of its (her ? :-) previous interactions with the users.
@@ -166,15 +169,15 @@ that, I think that the more Sheerka is used, the more easier it will be to use i
 
 So my first focus was to decide which database to use.
 
-There are tons od different databases already on the market. Unfortunately for me, I'm not
+There are tons of different databases already on the market. Unfortunately for me, I'm not
-a database expert. But, I already knew that I was not looking for a traditional
+a database expert. But, I already know that I was not looking for a traditional
 relational database (SGDB) as the structure will evolve and I didn't want to spend
 my time on redesigning the schemas and the constraints.
 
 As I was learning Python, it could have been a good idea to also start looking at an
 already existing NoSql database. I started to look at MongoDB, but I got lazy. I knew that
-the top feature was that management of the history (the way git does it), and it was not
+the top feature that I needed was that management of the history (the way git does it),
-provided by Mongo, or I didn't notice it in my first readings on the subject.
+and it was not provided by Mongo, or I didn't notice it in my first readings on the subject.
 
 So I decided to design and implement my own database.
 
@@ -190,10 +193,10 @@ What are the main design constraints?
     1. No adherence with the filesystem.
         We must not care about where the data are stored.
         The first implementation will be file based, but it has to be extensible.
-        The final target will be to have a decentralized persistence
+        The final target will be to have a decentralized persistence system
     2. CRUD operations are designed according to my needs
-        I don't want standard CRUD operations that will be tweaked.
+        I don't want standard CRUD operations that I will have tweak.
-        The direct consequence is that this library won't fit any other purpose
+        The direct consequence is that sdp won't fit any other purpose
     3. History management for State and other objects for free.
 
 
@@ -201,8 +204,10 @@ sdp, like many modern database systems, is a dictionary. A big list of key-value
 The key is a string, the value can be almost anything. Actually, for my needs, I guess
 that I only need strings, numbers and list (of strings and numbers :-)
 
-I need one level of categorization. That means that my objects can be group. The basic
+Json also provide, true, false and null. So I guess that I will also need them.
-signature to add a new element :code:`add(entry, obj)`.
+
+I need at least one level of categorization. That means that my objects can be grouped.
+The basic signature to add a new element :code:`add(entry, obj)`.
 
 with
 
@@ -211,18 +216,19 @@ with
     entry : is the group / category where I want to put the object
     object : object to persist
 
-With :code:`add("Concepts", "foo")` the database, let's call it **State** once for all, will be updated like this:
+With :code:`add("All_Concepts", "foo")` the database, let's call it **State** once for all, will be updated like this:
-
-.. code::python
-
-{"Concepts" : foo}
-
-If I want to have another entry, I don't want to care about what was previously done. I
-need the second call :code:`add("Concepts", "bar")` to produce
 
 .. code-block:: json
 
-{"Concepts" : ["foo", "bar"]}
+    {"All_Concepts" : "foo"}
+
+If I want to have another entry, I don't want to care about what was previously done. I
+need the second call :code:`add("All_Concepts", "bar")` to produce
+
+.. code-block:: json
+
+    {"All_Concepts" : ["foo", "bar"]}
+
 
 So we are no longer in the usual way of implementing a CRUD.
 
@@ -280,3 +286,100 @@ globals(), using pickle and load it back whenever needed.
 If it does not work as expected, I can find a way to save the commands a exec everything
 when needed. (first time, I exec import... second time I exec import + pp == and the last
 time I exec the three statements).
+
+2019-11-07
+**********
+
+Back on data persistence
+"""""""""""""""""""""""""
+Last time, I talked on how to add new entries in the **State**. I only need the name of
+the category, on the object. If I add several objects under the same entry,
+they don't override each other, they are kept as a list.
+
+.. code-block:: python
+
+    add("All_Concepts", "foo")
+    add("All_Concepts", "bar")
+
+will produce something like
+
+.. code-block:: json
+
+    {"All_Concepts" : ["foo", "bar"]}
+
+The reason behind this chose is that, in the human world, the same name can refer to
+several concepts. The first obvious cases are the synonyms. Same word, but different
+meaning. There are also some other case where the meaning of the world depend on the context.
+Rather than forcing the user to spend some time to find another way to express the concept,
+(as the name already exists), I prefer allow the storage under the same key.
+The choice of the correct item to use in the list will be done on execution.
+
+I also need sdp to manage the key of my object. So 'entry' will be used to group object,
+and the key will help to quick access to it.
+
+I don't want the signature :code:`add(entry, key, object)` because sometimes there is a key,
+but keys are not mandatory. So I keep the signature :code:`add(entry, object)`
+
+To manage the key, the object either is a key/value entry :code:`{key: value}` (Python dict) or
+has an attribute :code:`key`, or has a method :code:`get_key()`
+
+For example **Concepts** have a method :code:`get_key()`, so if the key of 'concept' is "foo",
+the code
+
+.. code-block:: python
+
+    add("All_Concepts", concept)
+
+will produce something like
+
+.. code-block:: python
+
+    {"All_Concepts" : {"foo" : concept}}
+
+If I add another concept (concept2) which has tke key "bar", I will have
+
+.. code-block:: python
+
+    {"All_Concepts" : {"foo" : concept, "bar": concept2}}
+
+and so on..
+
+So under the 'All_Concepts' group, I have a quick access to the concept "foo"
+
+Note that, if for some reason, I end up with several concepts this the same key, they will
+be just stack as list. I don't loose information.
+
+We will talk again about sdp later
+
+Status
+""""""
+As of today, I have a first implementation of several main functionalities of the system
+
+
+1. I have a good implementation of sdp
+    * When I say good, I talk about the coverage of the functionalities, not the efficiency of the code
+    * I can add object to the state
+    * The objects can be saved as reference (will be explained later)
+    * I manage events
+    * I manage history
+    * I manage several types of serialisation
+2. I have two parsers
+    * DefaultParser : to detect sheerka specific language (like def concept)
+    * PythonParser : to parse Python code.
+    * There are called for every new event.
+3. I have a first version of the evaluators
+    * These have piece of code that recognize a result and process it
+    * The current algo is not finished, but it works for simple cases
+    * I can create a new concept
+    * I can evaluate simple Python expression
+4. I don't have the printers, but it's ok, I just dump the result of  processing
+
+so I can type
+
+::
+
+    def concept hello name as "hello" + name
+    1 + 1
+    sheerka.test()
+
+I will now work on how to call an already defined concept.

tests/test_sheerka.py

@@ -119,7 +119,7 @@ def test_i_can_get_a_concept():
     pass
 
 
-def test_i_can_instanciate_a_concept():
+def test_i_can_instantiate_a_concept():
     """
     Test the new() functionnality
     make sure that some Concept are singleton (ex Sheerka, True, False)