Tuesday, June 28, 2016

Week 10

Class methods detector

This week involved devising a system for automatic override key detection.
For that I came with the idea to create javap parser and look inside import modules and see which methods are abstract.It works, but maybe I overcomplicated things slightly. For the future I think  I will insert all the data from javap for a particular class inside a dictionary. It will change the implementation, but the logic about how to detect override methods won't.
It can also be used for the detection of the missing constructors,that need to be generated as well as get Instance methods.

Mandatory methods generator

This weeks also included the creation of the Mandatory methods generator.
Dr. Bergmann gave a valuable insight about devisers attribute['reqd'] key,which facilitated the detection of return value for the method.Here's the link.

Things to do

Go back to constructor generator.
In the case of QualitativeSpecies.java, the current generator creates setCompartment(java.lang.String) method, but during compilation I get an error(QualitativeSpecies.java:36: error: QualitativeSpecies is not abstract and does not override abstract method setCompartment(Compartment) in CompartmentalizedSBase), which is visible during javap output,so that is something that has to be addressed. Also will take care of the generation of Instance methods.

 

Monday, June 20, 2016

Week 9

Hi everyone,

Unfortunately last week not much was done because I had a exam at the university.I passed it and got an idea.

The idea came to fruition when last week Dr. Dräger mentioned about java reflection and  jython, but I thought there should to be an alternative.

As to me the alternative can be pyjnius, which is a Python module to access Java classes as Python classes using JNI. It has an active community that comes from Android development, easy to use and does not depend on many dependencies.
These are the dependencies.
  1. Java JDK(OpenJDK also works)
  2. Cython and six
  3. Setup JAVA_HOME environment
  4. Setup JRE_HOME environment

Just with a couple of lines it's possible to see all the methods of the class(raw),
but again  it turns out that java reflection is not enough for imports.For example, IDEs' such as Eclipse have their own parser to determine what to import. Still this approach can be used to get instance() methods which are not available in the Deviser xml descriptions.

I think it'll be nice to discuss it during TC.

Tuesday, June 14, 2016

Week 8

This week involved a lot of investigation and figuring out how to use Devisers' key attributes to import modules necessary for JSBML.
Here's the summary what was done during this weekend.
  1. Removed mId and mName from variable generation
  2. Removed Id and Name methods generation from SetGetFunctions.py
  3. Added simple constructor for JSBML
My previous idea to create the jsbml class hierarchy was not sufficient to determine the import modules unfortunately. So I examined again if there's any pattern for Deviser 'type'( here is the Speadsheet), but there is none, that could be used.

Looks like the best approach will be hybrid and one idea is to use attributes' 'name' or 'xml_name', for example if it is 'compartment', then import org.sbml.jsbml.Compartment and org.sbml.jsbml.CompartmentalizedSBase or if it is 'reaction' then import org.sbml.jsbml.Reaction and associated modules.
The idea is to create a dictionary with the package name and attribute name and to use previous tree structure to detect if it is an interface or not, but this part needs to be discussed with the mentors.





Tuesday, June 7, 2016

Week 7

This week was very interesting, but also a challenging one.

First, the summary of what was done during this weekend.
  1. Added JSBML license writer
  2. Added write_jsbml_types_doc
  3. Opening and closing brackets were modified,so now it looks like Java code.
  4. Code for writing import statements and class header was written.
  5. In SetGetFunctions.py, unset was fixed, now throws "firePropertyChange".
But the biggest challenge was how is deviser supposed to decide which modules to import based on the attributes.

At first, the idea was to create a method similar to expand_attributes and expands_class, but soon found out it wouldn't suffice and there would a lot of problems on how to import.


Fig.1 JSBML Full Type Hierarchy
Thus I decided to use a tree structure to store the Full type Hierarchy of JSBML. Next step was to decide, whether to create my own tree structure or to use template. In the end I decided to use a template, but how without importing modules that are not available in Python and I found a gist summary that uses pythons' collections module, which includes High-performance container datatypes.

As for the keys, decided to use this ones:
['name'] = name of the Class or Interface
['hasParent']  = True or False
['parentNode'] = key name of the parent node
['hasChildren'] =True or False
['childrenNodes'] =List or None
['isInterface'] =True or False
['parentInterfaces'] = List or None
['childrenInterfaces'] = List or None
['isUniqueJSBML'] =True or False (if True, that means only available in JSBML)
['level'] =integer (to describle on what level)
['libSBML_analogue']  if there's analogue in libSBML

Here's the full implementation of the tree.
Next step is to figure out how to import only necessary modules.