"
Team:Berkeley Software/LesiaNotebook/Notes
From 2009.igem.org
Lbilitchenko (Talk | contribs) (→Week of June 15, 2009) |
Lbilitchenko (Talk | contribs) |
||
| Line 85: | Line 85: | ||
| - | '''Friday''' discussed with Doug | + | '''Friday''' discussed with Doug Plug-In Model: |
| - | [[Image:Clotho Model. | + | [[Image:Clotho Model.png|thumb|left|new Clotho Model]] |
| + | Right now we have five interfaces. In order to create new Plug-Ins one needs to extend one of those interfaces. It would be easier to have one main interface which contains the methods and an abstract class that implements the interface. Therefore if we want to create new Plug-Ins the class just needs to extend the abstract class and override the needed method. | ||
Revision as of 21:29, 21 June 2009
Week of June 8, 2009
Monday was the first day of the SUPERB program. I got introduced to the IGEM team. Doug gave a tutorial on Clotho and on plug ins. Got the Clotho source code from the repository.
Tuesday we had a meeting. I will be working with Adam on the language project. BOL will be a language which is based on the abstract model of parts which form the lowest level of hierarchy and will be the basic data types in this language. Parts can be composed of other parts, but in themselves cannot be decomposed any further into lower level data types. Devices will be at the second level of hierarchy and can consist of multiple devices as well as parts. It will be different from other languages like Antimony, [http://sbml.org/Main_Page SBML], or [http://bionetgen.org/index.php/Main_Page BNGL], as BOL will be a structural human readable language not geared towards modeling. BOL has a direct relationship to [http://openwetware.org/wiki/Endy:Notebook/BioBrick_Open_Graphical_Language BOGL] symbols, the graphical representation and can be used to convert textual designs to graphical representations and vice versa.
Wednesday brainstormed with Adam on the syntax of BOL. It will have defined data structures based on the [http://openwetware.org/wiki/Endy:Notebook/BioBrick_Open_Graphical_Language BOGL] symbols like promoter, RFS. Supportive data types will be string, int, composite. Also, an important feature that we would like BOL to have is the ability to create more user defined data types. I created a preliminary data type table on properties, data types, operators. Also started familiarizing myself with [http://www.gnu.org/software/bison/ GNU Bison], which we will use as our parser for the language.
Researched more on other languages. It seems that BOL will indeed be different from previous languages. The rule based description has been implemented in [http://bionetgen.org/index.php/Main_Page BNGL], which is a modeling language and concentrates on species, molecules rather than standard parts. We still have to go over the syntax for rules and how we will implement them in BOL. The logical "AND", "OR" and complement operators, as well as <, > seem appropriate for right now.
Week of June 15, 2009
Monday had the presentation on Plug-Ins. Got feedback from group and Professor Anderson on the Plug-In xml file generator:
- Have mouse overs on each field that needs to be filled
- Make option to save the xml file under user specified name
- Make restrictions on choice for the interface and package name, since they have to correspond to each other
Started familiarizing myself with [http://www.antlr.org/ ANTLR], a tool for constructing compilers and interpreters from grammar rules. Each grammar rule checks the syntax of the program. One can specify actions for each rule which will be responsible for the semantic context of the program. The program consists of parser rules and lexer rules, where ANTLR constructs the Parser and Lexer files, the Test file and a Test input file after debugging. So far ANTLR seems more user friendly than GNU Bison, but this can be due to the fact that there are more tutorials available.
Tuesday had a meeting with Doug and Adam on the language development:
- Need to specify probabilities with each rule somehow, maybe each rule can have a probability property and when enforcing rules this can be taken into consideration
- Need to provide functions, for example could have:
- isDownstream()
- isUpstream()
- Translate()
- ReverseComplement()
- Need to include input/output capabilities
- Control and iteration statements
- Scope of the variables for right now will be global
Started writing the Context Free Grammar and thinking about the structure of the intermediate language, that is how are we going to implement the semantics. Right now have two classes (they are more like structs):
- Property which has type, variable name and the different fields that will store the values of the property. Type just means if the value of the property that we are going to store is text, integer or list. Variable name refers to what property we are talking about, eg Sequence, ID, etc; it should help later accessing each property.
- Part stores an ArrayList of properties, the part type, eg Promoter, RBS, etc and a HashMap of objects that each Part will have. For example:
Part Promoter(Sequence, BioBrickID);
Promoter p1, p2, p3;
The instance Promoter will store part type: Promoter, the properties that Promoter can have, which are Sequence and BioBrickID, and objects stores the instances p1, p2, p3, where each instance will have its own list of property values.
Wednesday continued working on the grammar, tried to generate the parser and lexer code and ran into lots of errors. The error message that ANTLR gives seem not specific enough, so decided to debug my code by creating a new grammar and copying slowly part by part. The problem turn out to be when one declares a grammar rule, it has to be in such specific way that left recursion will not occur, for example:
expr: declareObj expr | instantObje expr | instantObje | declareObj;
would cause left recursion and errors. One way to solve that problem, is follwing:
program: expr*;
expr: declarObj | instantObje;
The sign * means that multiple statements of declaring Objects and instantiating them will be accepted by the compiler
Thursday met with Professor Hilfinger to get some feedback on the language design, possible useful considerations:
- Creation of modules -> certain areas of code that do the same thing and only the parameters differ can be included in modules
- Ability to import modules into larger structures
- Rule scope -> need to know to which part rules apply
- Conceptual language behind the syntax, what structures, data types should we use?
- Decide on the interpreter/parser, right now it seems we are going to stick with ANTLR
Friday discussed with Doug Plug-In Model:
Right now we have five interfaces. In order to create new Plug-Ins one needs to extend one of those interfaces. It would be easier to have one main interface which contains the methods and an abstract class that implements the interface. Therefore if we want to create new Plug-Ins the class just needs to extend the abstract class and override the needed method.
