kodjo/Sheerka-Old
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Added entries to the blob

Browse Source
This commit is contained in:
Kodjo Sossouvi
2019-11-07 18:50:48 +01:00
parent 448ebc696a
commit a636198222
2 changed files with 125 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/blog.rst
+124 -21
View File
@@ -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.
In this example 'a' is a variable, as it appears as variable in the 'as' section
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 (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
@@ -138,7 +141,7 @@ first time.
Rather than trying a standard formal approach, we went on the codingame_ web site. There
are some pro and cons to use this platform, specially for the very beginners, but
I like the visual output of the programs . It's really like coding a game !
I like the visual output of the programs. It's really like coding a game !
What I haven't noticed previously, is that (at least for the first programs), the solution
is given in human language.
@@ -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
a database expert. But, I already knew that I was not looking for a traditional
There are tons of different databases already on the market. Unfortunately for me, I'm not
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
provided by Mongo, or I didn't notice it in my first readings on the subject.
the top feature that I needed was that management of the history (the way git does it),
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.
The direct consequence is that this library won't fit any other purpose
I don't want standard CRUD operations that I will have tweak.
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
signature to add a new element :code:`add(entry, obj)`.
Json also provide, true, false and null. So I guess that I will also need them.
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
.. code-block:: json
{"Concepts" : foo}
{"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("Concepts", "bar")` to produce
need the second call :code:`add("All_Concepts", "bar")` to produce
.. code-block::json
.. code-block:: json
{"All_Concepts" : ["foo", "bar"]}
{"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.