typee-language / typee Goto Github PK

This has to be done according to the newly created document on Typee software design.

We are now ready to put in the repository the actual code of the Front-End Parser.
Let's do it!
Meanwhile, we SHOULD verify the actual code.
Furthermore, we SHOULD program tests - see related issue.

Let's start preparing HTML content for typee.ovh!

I'm the sole assignee to this issue.

Let's document the data structure of the Intermediate Code generated by the Scanner as the Input of the Parser.

Typee does still apear with the previous name.

To Reproduce
Can be found in all Python packages and Typee documentation

Expected behavior
Should appear as Typee

Screenshots
not applicable

Desktop (please complete the following information):
any OS

Smartphone (please complete the following information):
not applicable

Additional context
not applicable

A readme.md document should be created in the directory of the language specs.

This documentation is for the ones who would like to contribute or who would like to take a read to grammar and Typee files.
I'va assigned everyone here.
Go to team discussion to state that you are the task processor. We may create a dedicated branch, but just to test them since only one worker on the related .md file will not cause any merge conflict.

The README.md document has to be completed then uploaded

We failed to correctly describing the design of the Intermediate Code in the Typee S/W design document.
What is wrong is that we've not described the places where intermediate codes are used.
In one place, the Front-End, we use tokenized intermediate code and syntaxic intermediate code.
In another place, the Back-End, we use syntaxic intermediate code, which is named validated intermediate code once passed to the Back-End.
This task aims at correcting Typee S/W design document about intermediate codes design.

We're still lacking a general documentation on Typee software architecture design.
We HAVE to write it, right now!

Title is self explanatory...

• Current name for directory containing this specification is "Data/" -- should we rename it "Specs/" ?
• Should we commit successive versions of the specs, to get immediate acces to the sole last one ?
• Or should we provide a sub-directory names "Previous/" which will contain all previous specifications versions ?

We all are assigned this issue.
Go to the team discussion to state yourself as the processor of the task.
The one who takes this issue under consideration should comment his choices. As a first step, any of them will be considered as validated. We could then later go back to them.
We may create a dedicated branch for this issue, but just to test multiple branches opened at same time.

A few errors have been detected in this document: title is wrong! a class has been renamed since the delivering of the doc!
Should verify its indexing in main_index.
Should index it in Typee S/W design document.

This rule in not correctly written.

Writing the design document has lead to the modification of some classes.
These classes have now to conform to the design document.

Modify the README.md file at root of repository.

We all are assigned this issue.
Go to the team discussion to state yourself as the processor of the task.
We may create a dedicated branch for this issue, but just to test multiple branches opened at same time.

We still need to think about the Parser of the Typee Front-End.
Remember: it takes as input the Intermediate Code generated by the Scanner and it generates as output a Syntaxic Intermediate Code (which is an Input for the next stage of the Translator pipeline).

This documentation should at least contain:

• an explanation on the role of the Parser;
• a description of the manipulated data structure;
• a list and a description of every related Python module;
• a description of how things go on when syntaxic errors have been detected as well as when types static checking has failed;
• ... (please add here any missing item).

We should NOT upload any code module before we all agree and validate this very important document, since first tries to develop the Parser have proven that we were not yet ready to develop it in a satisfying manner.

The explanations on the design and the use of local tools are missing in Typee S/W design document. Let's add them!

Old notices have to be renewed, copyright is incorrect.

Install Eclipse Photon on a local machine,
Install PyDev plug-in,
Create a new Python project named Tyhon
Push configuration files .project and .pydevproject at root of repository

Ok, I'm the only assignee to this.
Everyone will then be able to clone the Eclipse project on their local machines.

In method _is_sep(), remove the long string and put it as a class attribute by constructing it via the already defined class constants.

Once the Front-End Parser code uploaded, we SHOULD code tests for its validation.
These tests have to be documented - see related other issue.
Then, let's code them in directory 'Tests/'.

We've failed to create this important issue. The Scanner software architecture has to be documented!
I'll do it.

Deliver all the stuff related to the tokenized code description - i.e. the intermediate code between scanner and parser.

At least minimalist documentation, in readme.md files.
I have assigned all of us.
Go to team discussion to state yourself as the task processor. Noone else should then be.

Rename related directory from _Global_Documentation/Typee_Software_Documentation to _Global_Documentation/Typee_Software_HTML_Documentation

This might not really be a bug, but we need to check if anything has to be fixed.
Work for branch #31 has been done on both branches #31 and #32.
I'm going to merge both and check if any issue raises then.
If fixes are needed, they will be done.
Then branches #31 and #32 might be deleted to be created again, with new IDs.

Who would like to create a new project for our Web site?
From this project, we'll manage HTML pages content and their history.

(no need for a new branch)

We have to test the Front-End Parser code.
Let's first document those tests. Then, the issue about the coding of these tests will be addressed.

This has to be done according to the new namings in Typee software design document.

Let's prepare all the Front-End Elaborator stuff.
This is a "long before needed task" issue.

This is a long term issue.
Let's use it every time we modify or correct Typee S/W design document.

It seems that modules __init.py__ still contain a few errors. Let's just correct them.
The same sounds true with modules templates in package src/local_tools.
Please correct.

Write documentation for the installation of a complete Eclipse Photon framework environment, installing PyDev plug-in also, Java and Anaconda 3.

This is for the usage of new contributors.

We all are assigned this issue.
Go to the team discussion to state yourself as the processor of the task.
We may create a dedicated branch for this issue, but just to test multiple branches opened at same time.

This means creating empty init.py" modules in corresponding directories :

src/BackEnd/
src/Commons/
src/FrontEnd/
src/local_tools/
src/Optimizer/
src/Tests/
src/Utils/

Do not forget to create also subdirectories

FrontEnd/Elaboration/
FrontEnd/IntermediateCode/
FrontEnd/Parser/
FrontEnd/Scanner/
Tests/Data/

We all are assigned this issue.
Go to the team discussion to state yourself as the processor of the task.
We may create a dedicated branch for this issue, but just to test multiple branches opened at same time.

pyYacd could be the tool used to automatically document Typee software.
Let's either create a directory for this and put related code in it or add a documentation file to explain how to get and use it.

We all are assigned this issue.
Go to the team discussion to state yourself as the processor of the task.
We may create a dedicated branch for this issue, but just to test multiple branches opened at same time.

Add the Scanner module(s) of the Typee Front-End plus all related testing stuff.

We have to ensure that Typee reads everywhere in place of its former name.

• create a dedicated directory for global documentation of the software;
• add first useful or available documentation in this directory

Classes associated with tokens have been renamed in documentation, to be more consistent.
It might be that the old names still appear in the Front-End Scanner source code.
Let's check, Kerm!

Deliver all the stuff related to the description of the intermediate code generated by the parser and before syntaxic validation.

Write a short documentation of the way we test the Front-End Scanner.
This should be used to augment tests and to automate them.

Is your feature request related to a problem? Please describe.
Testing the Front-End Scanner is done manually, with three scripts to be run. Can't we automate this process with a single script calling already developped code?

Describe the solution you'd like
Add a testing function in each of the Scanner_Tokens test scripts. Then create a new script which will sequentially call each of these functions.

Describe alternatives you've considered
n.a.

Additional context
n.a.

Some subsections 5.x still have to be completed in the Typee software design document. We should do it!

Deliver all the stuff related to the syntaxic code finally generated by the parser after its syntaxic pass and before its types infering-and-checking step.

This document is referenced in the Scanner documentation. We still have to write it.

These sub-directories relate to the sub-directories of Typee code source.

• Front-End;
• Back-End; and maybe
• Commons-Utils (to group together common stuff and utilities.

Add a readme.md file in each with very minimalist explanations.

It seems that the two first lines are mising in most of PyYadc modules.

Describe the bug
Former name of Typee still appears in some uploaded modules.

To Reproduce
n.a.

Expected behavior
Typee should appear instead.

Screenshots
n.a.

Desktop (please complete the following information):
This is in code, whatever the platform or the O.S.

Smartphone (please complete the following information):
This is in code, whatever the platform or the O.S.

Additional context
n.a.