Tuesday, August 16, 2016

Week 17

Hi everyone,

Only one week left. Can't believe that GSoC is almost over.

So what was done during this week:

  1. Important bugs were fixed in readAttributes and toString method generators.
  2. The constructor generator was updated as well as the hashCode generator.
  3. Tests were set up  and run fine both on Windows and Linux.
  4. A prototype README.md version was created.
  5. Updated some parts of the code comments, but still there is work to be done.

The good news is that the parser generator was finalized and that generated code by deviser for qual, dyn,distrib and groups packages  are compilable.

The plan is to spend the next 2-3 days cleaning up the code and updating the comments, since deviser is quite complicated and there are tricky moments. They are available at WIP branch  of the fork repository.

Tuesday, August 9, 2016

Week 16

Hi everyone,

This week the following things were done:

  1. Implemented package-info.java writer
  2. Implemented skeleton for jsbml parser generation.
  3. Updated expand attributes for parser
  4. Added getNamespaceURI() generator
  5. Added getShortLabel() generator
  6. Added isRequired() generator
  7. getPackageName() generator
  8. getPackageNamespaces()
  9. getNamespaces()
  10. getNamespaceFor(int level, int version, int packageVersion)
  11. createPluginFor() method generator.
  12. getListOfSBMLElementsToWrite(Object sbase)
  13. processAttribute() generator
  14. processEndElement() generator
And the good news are that the codes  are generated both under Windows and Linux(430d214).

The only thing left for the parser generation is to finalize processStartElement and writeElement methods.
The unusual order of the "else if" statements generation for processStartElement turned out a little problematic.
The only thing that is challenging is that  package specific features are treated differently in JSBML from libSBML, such is the case for FBCs'     "And" and "Or" treatment.






Wednesday, August 3, 2016

Week 15

Hi everyone,

This week the following things were done:

  1. Implemented enum writer
  2. Devised the JSBML constants writer
  3. Devised the plugins writer
One addition to the tests was creating a new function for comparing the generated files with the test units, the new function uses difflib from python and now it is possible to see the differences and the lines if there are errors.
And the good news are that the codes generated for qual, fbc, dyn, distrib and groups packages are compilable(53dd6b7).

So far from the packages only 'spatial' is left to be adapted, that means the necessary functions need to be adapted for the code generation. And there is also the question for the generation of the parser.

Tuesday, July 19, 2016

Week 13

Still Work in Progress....

Tests

Last week a compilable class goal was achieved.So this week was about setting up tests.
Since deviser generates and select random UUID and prime number, the two methods were adapted for running tests. In the case of prime number, random.seed was set to 0 as for the UUID to a fixed number,as random seed would not affect it.
The foundation of java tests served test_cpp_code files, which were adapted for the java files generation. The path separator was changed to os.sep, so it uses OS specific separator.

javap parser 

jsbml jar was put inside deviser package and javap works under Windows as well.

List of modifications

  1. added lo_element writer
  2. fixed problem with brackets for equals and copy constructor.




Tuesday, July 12, 2016

Week 12

Hello all,

Here's the summary:

Compilable Class

Deviser generates a compilable QualitativeSpecie.java(Fig.1). The class also worked as a replacement in the official jsbml code, but since deviser does not generate not generate   QualitativeSpecies(species) constructor, that part of the code had to be commented in the official jsbml code, after that the compilation was successful(https://gist.github.com/hovo1990/c3ce45eb0d61cefe5c2440d65a45d5be).

Fig.1 Compilable QualitativeSpecies.java

UUID generator

Dr. Bergmann gave valuable help and recommendation for the generation of UUIDs.
Python includes uuid module, that can be used for the generation of uuids, but since Java uses long 64 bit, while python generates 128 bit, the generated uuid had to be masked.
After changing to 56 bit, java compiler would not give more errors for being too long.

hashCode method changes

Generated prime numbers were changed to a global variable, so that the numbers are only generated once.

Implemented Methods

Here's the list of the methods, that were implemented during this week:
  1. prototype writeXMLAttributes
  2. fixed functions with same name generator
  3. prototype toString
  4. prototype readAttribute

Tuesday, July 5, 2016

Week 11

Organize helper functions

Removed duplicate codes and  placed frequent helper functions inside a new module: jsbmlHelperFunctions.py, which includes functions for determining whether a method has to be overriden, javap argument parser, get javadoc comments, finding methods with same name that take different argument and prime number generator.

Constructor generator

Deviser now generates copy constructors.

Method generators

Deviser can generate get_instance, is_set_instance, equals and hashCode methods.

hashCode method

The generator uses algorithm found from stackoverflow.  Right now generates  up to 10 to the 6th power(has to be changed) and than uses pythons random.choice  method for selecting a prime number, but this part needs to be discussed with the mentors. 

Things to do

With the generation of the new methods, previous errors during compilation would vanish, but new ones appeared.Only 3 methods are left to be implemented: readAttribute, writeAttributes and toString.
Finish readAttribute method, which turned out to be a little problematic, write writeAttributes and create the last method generator,which is for toString method.
As for fixing the order of the functions, the idea is to create a dictionary with the function name as key,sort keys and write methods, but that approach would consume more memory, I think it'll be nice to discuss it during TC.