Team:Berkeley Software/AdamNotebook
From 2009.igem.org
Adam z liu (Talk | contribs) |
Adam z liu (Talk | contribs) (→Adam z liu 19:12, 7 August 2009 (UTC)) |
||
Line 164: | Line 164: | ||
=[[User:Adam z liu|Adam z liu]] 19:12, 7 August 2009 (UTC)= | =[[User:Adam z liu|Adam z liu]] 19:12, 7 August 2009 (UTC)= | ||
- | Doug, Bing, and I started porting over the old tools to Clotho II. I worked primarily on the Enzyme Library, making sure highlighting is still compatible with the Sequence View. We discussed how communication should work between tools, and decided that tools should generally call the getData and sendData methods in the core, passing a tool class and a keyword. Tools will all subscribe to a universal set of keywords and not implement their own custom enumeration. This way, the vocabulary is more controlled and and data requests will be synchronized with database mappings. Keywords can be relied on for fetching universally relevant information, like sequence. For more tool-specific information, like whether the methylated check-box is checked in the Sequence View, tools will have to get the specific tool from the core and call custom getter methods. This necessity for this kind of communication is limited mostly to the old tools that are highly interdependent. Tool writers in the future hopefully will not need to do this very much. The sendData method is called to ask a tool to perform a function on the sent piece of data. Functions vary from tool to tool and are specified in each | + | Doug, Bing, and I started porting over the old tools to Clotho II. I worked primarily on the Enzyme Library, making sure highlighting is still compatible with the Sequence View. We discussed how communication should work between tools, and decided that tools should generally call the getData and sendData methods in the core, passing a tool class and a keyword. Tools will all subscribe to a universal set of keywords and not implement their own custom enumeration. This way, the vocabulary is more controlled and and data requests will be synchronized with database mappings. Keywords can be relied on for fetching universally relevant information, like sequence. For more tool-specific information, like whether the methylated check-box is checked in the Sequence View, tools will have to get the specific tool from the core and call custom getter methods. This necessity for this kind of communication is limited mostly to the old tools that are highly interdependent. Tool writers in the future hopefully will not need to do this very much. The sendData method is called to ask a tool to perform a function on the sent piece of data. Functions vary from tool to tool and are specified in each tool's operation enumeration. |
I also wrote up a translator that converts Eugene to XML. There are still some details that need to be hammered out regarding the format of the XML, but generation basically works. | I also wrote up a translator that converts Eugene to XML. There are still some details that need to be hammered out regarding the format of the XML, but generation basically works. |
Revision as of 19:12, 7 August 2009
Adam's iGEM 2009 Notebook
ANTLR Tutorials
http://w3.msi.vxu.se/users/tgumsi/antlr/ (http://www.antlr.org/pipermail/antlr-interest/2009-February/032930.html)
http://java.ociweb.com/mark/programming/ANTLR3.html
http://supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/antlr/antlr.html
http://www.alittlemadness.com/2006/06/05/antlr-by-example-part-1-the-language/
Adam z liu 06:26, 4 June 2009 (UTC)
Introduction:
My name is Adam Liu, and I am going to be a 4th year EECS student in the fall. This summer I will be working as a member of Berkeley's computational team. With the success of Clotho last iGEM, we have a great foundation to build off of this year. Although there are still a few bugs to fix, we plan to pursue many new exciting projects to move Clotho forward. The team is much bigger than last year, so hopefully we will not be too overwhelmed. My main focus this summer will be language development.
Short-term project:
I will be making a plug-in that will take a textual description of biological parts in an input file, tentatively named Adam's Language For Synthetic (ALFS), and generate an image with [http://openwetware.org/wiki/Endy:Notebook/BioBrick_Open_Graphical_Language BOGL] symbols.
Long-term project:
- Familiarize myself with [http://groups.csail.mit.edu/stpg/proto.html Proto], [http://www.sys-bio.org/sbwWiki/antimony Antimony], and [http://sbml.org/Main_Page SBML].
- Get an existing language to work with Clotho.
- Design and implement our own language (structural netlist first).
Adam z liu 00:25, 11 June 2009 (UTC)
I finished a simple plugin called Pictoparts. The user inputs a *.p file describing BOGL parts, and my plugin parses the file, stitches together images, and outputs and displays an image of the composite part. I also met my partner Lesia, and we had our first project meeting with Doug. We came up with the following outline of tasks to complete this week:
- Think of a name for our language
- Give Lesia the [http://web.mit.edu/jakebeal/www/Publications/biocompile.pdf Proto paper]
- Look for other languages
- Write up a draft language for the [http://bbf.openwetware.org/RFC.html#BBF_RFC_16:_BioBrick_Open_Graphical_Language_.28BOGL.29 BOGL RFC]
- List of primitive datatypes
- List of properties for primitives
- Rule syntax
Once we have a first draft for syntax, we will test the expressive power of our language on a set of diagrams by a member of the Stanford BOGL effort. We will then submit everything to the BOGL/BOL community for critique. Next week, we plan on giving our language to the wetlab to test, as well. After we settle on acceptable syntax, we will specify the grammar to [http://www.gnu.org/software/bison/ GNU Bison] to parse our language.
Adam z liu 19:22, 19 June 2009 (UTC)
Doug, Lesia, and I got feedback from various different sources about the sample syntax:
- Cesar Rodriguez - contributor to the Stanford BOGL project
- Rename Part to Component and Composite to Device
- Make the language object-oriented with everything inheriting from Sequence
- Paul Hilfinger - compilers professor at Berkeley
- Need a way to define modules
- Use a parser generator
- CS community not really interested in domain-specific languages unless new processing is being done
- J. Chris Anderson - Berkeley iGEM wetlab instructor
- The language cannot be just a tweaked version of others already out there
- Be able to elaborate on the ultimate purpose of the language
Lesia and I are developing a grammar for [http://www.antlr.org/ ANTLR]. We also gave a PowerPoint presentation about our project to the group.
Adam z liu 22:17, 24 June 2009 (UTC)
/* The following example syntax demonstrates how our parser populates our back-end data model, as specified in DataModel.png. Example1.png show each global HashMap in more depth. */ Property Sequence(txt); Property Orientation(txt); Property ID(txt); Component Promoter(Sequence, Orientation, ID); Component RBS(Sequence, Orientation, ID); Component ORF(Sequence, Orientation, ID); Image (Promoter, "C:/My Images/Promoter.jpg"); Image (RBS, "C:/My Images/RibosomeBindingSite.jpg"); Promoter p1("ATCG", "Forward", "BBa_K123456"); Promoter p2("GCTA", "Reverse", "BBa_K654321"); RBS rbs1(.Sequence("CGAT"), .Orientation("Reverse")); num ten = 10; num one = ten - 9; Rule r1(p2 BEFORE p1); Rule r2(rbs WITH p2); Rule r3(p1 NEXTTO rbs1); Assert(r1 OR r2); Assert(NOT r3); Note(NOT(r1 AND r3)); Device c1(p1, rbs1); Device c2(p2, c1);
Adam z liu 00:36, 3 July 2009 (UTC)
Lesia and I worked on fixing as many bugs as possible for our initial release. I packaged our compiler into an executable that can run from the command line or from a GUI. It comes with an extensive README with instructions on how to code and compile with Eugene. Lesia is moving on to work on rules, and I will now be working on integrating with Spectacles, Richard and Joanna's visual piece.
Sourceforge wiki: http://eugene.wiki.sourceforge.net/About+Eugene
Sourceforge download: http://sourceforge.net/projects/eugene/files/eugene/eugene.tar.gz/download
Adam z liu 21:18, 11 July 2009 (UTC)
Lesia finished the pass on rules, and I wrote a Eugene exporter than converts the data model back to Eugene code. I also wrote a syntax highlighting file for Notepad++ to include with the next release. We had a meeting with Cesar and Akshay on Friday, and we agreed that the details about properties and components should be hidden from the user in the form of header files. Next week, we are going to comment and clean the grammar file, and create a Eugene editor for Spectacles. I will also create a thorough test case to find more bugs. The next release will be for Cesar's labmates at Stanford.
Adam z liu 04:11, 19 July 2009 (UTC)
We added header file functionality and integrated Eugene into Spectacles, which now has a code editor, as well. We brought the finished project, which is still a little buggy, to Stanford to show Drew, Cesar, and Akshay on Friday. Drew shared with us his vision of abstraction barriers between sequences, parts, and devices. He explained that tools simply do not exist that help refine sequences and particate them. Though Eugene and Spectacles provide the ability to move downward from the part level to the sequence level, until tools are developed to move upward, the problem is only half solved. We decided to adopt the rapid application development paradigm with our future efforts, and try to release working pieces as we finish them. Next week we will begin developing XML translators to move between our data model and Cesar's XML schema.
Adam z liu 011:33, 24 July 2009 (UTC)
I wrote an XML translator that takes XML in Cesar's below format and converts it into a Eugene header file.
<?xml version="1.0" encoding="UTF-8" ?> <registry> <part> <identifier>BBa_K106019</identifier> <type>ORF</type> <name>Receptor, tar-envZ</name> <description type="string">Coding sequence for Tar-EnvZ fusion protein. Tar is the bacterial chemotaxis receptor for aspartate. EnvZ is an osmosensor kinase, which, through phosphorylation of OmpR, regulates transcription of porin genes.</description> <size>1491</size> <sequence>ccaggcatcaaataaaacgaaaggctcagtcgaaagactgggcctttcgttttatctgttgtttgtcggtgaacgctctc...</sequence> <orientation>+</orientation> </part> </registry>
I also made a few diagrams for Lesia's paper.
Adam z liu 20:57, 31 July 2009 (UTC)
Spectacles and Eugene refactored Component back to Part. I cleaned up the indenting in the grammar file and edited images for Lesia's paper as needed. Doug, Lesia, and I went through the paper and tried to get polished up for [http://www.eecs.berkeley.edu/Programs/ugrad/superb/superb.html SUPERB]. On Thursday, we went to the iGEM barbecue. I posted about it on the [http://blogs.coe.berkeley.edu/igem/ Berkeley Engineering blog]. On Friday, everyone went to Lesia's poster session and looked at all the other SUPERB projects. The month of August is going to be all about migrating everything to Clotho II. On Monday, I will be packaging the Enzyme Library into a tool.
Adam z liu 19:12, 7 August 2009 (UTC)
Doug, Bing, and I started porting over the old tools to Clotho II. I worked primarily on the Enzyme Library, making sure highlighting is still compatible with the Sequence View. We discussed how communication should work between tools, and decided that tools should generally call the getData and sendData methods in the core, passing a tool class and a keyword. Tools will all subscribe to a universal set of keywords and not implement their own custom enumeration. This way, the vocabulary is more controlled and and data requests will be synchronized with database mappings. Keywords can be relied on for fetching universally relevant information, like sequence. For more tool-specific information, like whether the methylated check-box is checked in the Sequence View, tools will have to get the specific tool from the core and call custom getter methods. This necessity for this kind of communication is limited mostly to the old tools that are highly interdependent. Tool writers in the future hopefully will not need to do this very much. The sendData method is called to ask a tool to perform a function on the sent piece of data. Functions vary from tool to tool and are specified in each tool's operation enumeration.
I also wrote up a translator that converts Eugene to XML. There are still some details that need to be hammered out regarding the format of the XML, but generation basically works.
Next week, Doug and I are trying to meet with Sherine from the wet lab to demo Clotho II and to get interesting constructs for the Eugene paper.