Seventh Week

In 7th week, we achieved following goals :


  1. Generated a type system in eclcc code so that we get accurate types for return type and parameters than those returned by heuristic signature breaking.
  2. Each Type is represented as type tree.
  3. To generate type system, we used a switch statement over type code of given type. For simple types, we simple used getECLType() for that type code.
  4. For complex types, we used their typename as attribute in type tree and recursed over any child type.
  5. For record type, we used queryOriginalName to get original name if record is previously defined and do not expand that record.
  6. Else we expand the record using expandRecordDefinition function.
  7. For function type, we generate its parameters types and return type to get correct type info.
  8. Type system to used to get return types of function, parameters types, field type in record and any definition that is not a function, scope, type, record or import.

Comments

Post a Comment

Popular posts from this blog

Fifth Week

In fifth week, we achieved following goals : Text Documentation was generated. XML Doc was read to get appropriate information for Text Documentation. Jinja2 library was used to generate Template. For Text Documentation, we limited all information display to 150 chars per line. The Definition was indented on basis of their level in the tree. We use textwrap library to heuristically break long sentences along word boundaries. Each folder was also given a pkg.toc.txt file, which contained bundle information and links to all files in that folder. Heuristic signature breaking was designed. The signature for definition was read and broken into return type, name and parameter string. The breaking occured along heuristic : break at first incidence of name in the sign that it not enclosed by brackets and ends in whitespace or '('. Then break at end of the name.
Read more

Eighth Week

In eighth week, we achieved following goals: Generate Links to any external Documentation for given ecl source tree. For example , if project A has IMPORT B.B1; stmt in some file and we have included path to B Code in eclcc using -I option, that we can also include path to documentation of B which will be linked correctly to any such import stmts in documentation of A. To generate external documentation, each ecldoc run generates a tree.json file for each folder in given ecl source tree. Tree.json files provides paths to each file starting from the folder the json file is in. If the corresponding source path is included in eclcc, we can determine target path using this json file. Example - If input_root below is included in -I option of eclcc, then any imports of keys in tree (example_8, intest, intest.example_11, intest.inintest, intest.inintest.example_2) will be linked correctly to documentation in output_root in each format. { "input_root": "/media/sart...
Read more

Ninth Week

In ninth week, we achieved following goals : Generates Documentation for Users in clienttools documentation format. Code Refactoring : Here we reworked the code, so that all output formats are present in separate directories. This will allow easier extension to other formats in future. The only file needed to be modified to add more formats is Formats/generators.py and it will be added to ecldoc. Templates were moved to separate directory which makes it easier to install using setuptools in python. Code was reworked to generate absolute imports rather than relative imports. This makes it easier to move the destination of imports. Code was documented using docstrings and comments wherever required. Technical Documentation was generated to inform overall working of ecldoc code for future.
Read more