UCOSPLogShikibMehri

Shikib Mehri edited this page Apr 10, 2016 · 19 revisions
Clone this wiki locally

UCOSP log entries for Shikib Mehri

Each UCOSP participant is asked to log all the steps they take as they make progress through the semester. This includes difficulties they faced (getting set up, understanding how to model in Umple, using UmpleOnline, code that is difficult to figure out, and development tools that are hard to figure out, or don't seem to work properly). The more log entries added the more we can better get a grip on the usability issues with Umple, and the more we can help future new contributors come up to speed.

Please record entries in reverse chronological order

Log Entries

Apr 10, 2016

I finished dealing with issue #803. I managed to preserve the ability to specify Ruby code injections in the same format as before (as well as the typical Umple camel case format) while making code injections case sensitive.

I also moved the functionality for custom code injections and injection with parameters to work for Ruby/Php as well.

The only thing I have left to do now is to write a few examples for the Umple manual that demonstrate my changes. However if any issues arise with my pull requests, I'm available for the next week to fix them.

Apr 3, 2016

I finished dealing with issue #804. There are is now warning 1013 printed whenever parameters are specified for injections into generated methods.

I'm currently waiting on Tim/Vahdat's comment on issue #803. I'm not sure if making code injections case sensitive is the best decision for Umple. I presented two options in the issue.

Mar 28, 2016

I haven't posted a log entry for a while -- as this has been a busy week. I did work on Umple all day today and got quite a bit done. I have working functionality that allows me to target code injections at specific methods based on their parameters.

I've copy pasted the examples from my pull request below:

class A {
  void foo(String a) {
    [...]
  }

  void foo(int a) {
    [..]
  }
}

You can now specify the parameters in certain ways to target those methods specifically:

If you want to inject into the first method and only the first method:

before custom foo(String) {
  [...]
}

Or if you want to inject only into the second method:

before custom foo(int) {
  [...]
}

Or if you want to inject into both:

before custom foo(...) {
  [...]
}

This also injects into both (if parameters unspecified -- it is presumed that you don't care about them):

before custom foo {
  [...]
}

You can also just use multiple code injections on the same line and specify parameters for all of them:

before custom foo(int),foo(String) {
  [...]
}

In terms of what I did with regards to testing (again copy pasted from PR):

Cleaned up some of the tests that needed to be changed (for minor and justifiable reasons) due to my changes to the grammar. Added in new test files to test this functionality -- covering all of the examples that I mentioned above.

At this point in time what I've finished is only targeted at custom code injections. This was mostly out of choice -- because we definitely want this functionality for custom code injections -- but I'm not sure how useful it would be for injections into generated methods. If, Tim/Vahdat think it is important to include for those two, I'll just have to hunt down every call to getApplicableCodeInjections and change the parameters to it and pass in the method parameters as well as the name.

As long as the PR is accepted (waiting on the CI right now), all I need to do over the remaining two weeks is make my implementation work with other languages (cpp/ruby/php is all I need to do to the best of my knowledge).

I expect cpp to be straightforward given the code for Java. I don't think ruby will be a problem (I'm familiar with Python, and expect ruby to be mostly similar). I'm a bit worried about PHP as I've never used it and I'm not too familiar with the syntax -- but I should be able to figure it out over the course of two weeks.

Mar 19, 2016

Since my last post, I fixed the issue with the codeLang. I did this by explicitly saying in the grammar that the operationSource must be one of "custom"/"all"/"generated". This led to a successful test pass.

I modified tests I had written earlier and added new ones. I've now updated the pull request with the new tests and all of the latest code. If it passes (I think it most likely will), it means the pull request is ready to go through as all of the changes are now working.

Mar 18, 2016

I've fixed the main issue that's been holding me back. When writing the code, I made the assumption that all code injections would go through the process of being parsed (at which point the injections with unspecified source would have their operationSource set to be "generated"), however this isn't the case and there are many CodeInjections created programatically. This was a simple fix and it led to the majority of the failing tests to pass.

Right now, I'm dealing with one more issue. This is an issue that occurs when the codeLang is specified in the injection. I'm not 100% sure what is going on right now -- but my preliminary observations lead me to believe that the operationSource is being set to be the value of the operationName and the operationName is being set to be the codeLang.

I will look more into this tonight, and ask Tim/Vahdat, if I'm unable to figure it out soon.

Mar 17, 2016

I added the grammar code and parsing code to implement the ability to differentiate between code injections into custom/generated/all methods. What I essentially had was a working implementation of code injections into custom/generated/all methods, that worked locally.

Yesterday, I pushed my code to my repo, but noticed that it failed integration tests on my open pull request. Since then, I've been trying to figure out why the build is failing.

I've been trying to backtrack my code until I determine what exactly is making the build fail. It seems like it's most likely an issue with the changes to the grammar. The thing that is making it super difficult to debug is the fact that the /umple/dist/qa/cruise.umple/all-tests.html page isn't showing any failures -- even though the build says that the cruise.patterns.test.CodeInjectionTest FAILED.

Mar 14, 2016

This week, I've fixed the issue I've been dealing with for the past while. The way I did this is by calling a separate method to identify applicable code injections for custom methods. The applicable code injections were initially an empty list. After doing a first build (this is important to get rid of generated code) and then a full build, this fixed the issues I was having.

Now what I've done is change the method so that it will only identify code injection as being applicable to custom defined methods if they have a tilde at the end of them. For example:

void setFoo() {
  // test
}

after setFoo {
  // test2
}

will not inject anything. However the following will inject:

void setFoo() {
  // test
}

after setFoo~ {
  // test2
}

This syntax won't reflect the final syntax, I'm just experimenting with how to do this. I will be discussing the syntax with Tim and Vahdat throughout this week.

Mar 6, 2016

Dealing with this bug has been difficult to say the least. I think there are some fatal flaws in my understanding of how Umple gets built. Unfortunately, I'm still not 100% sure of how it does get built, but I now know the reason my bug occurs.

Vahdat helped me figure this out (although I didn't realize at the time that the bug he pointed out was almost identical to the one I was dealing with). The problem stems from the fact that Umple developers have used code injections with the assumption that no code would be injected into custom defined methods.

However, with my changes this is no longer the case. Meaning that a lot of existing code is going to have issues. The solution, as explained to me by Vahdat, is to finish the parameter specification code for code injections before expecting my code to work. Thus, I will immediately start working on that.

The reason that this bug was so difficult to figure out, was that the build would occasionally pass. My understanding of this is extremely weak, but it seems like you need to do two full builds consecutively to see this issue.

My plan for the upcoming week is to finish implementing the code injection with parameter specification. I've been thinking about this for the past week, so I have a reasonable understanding of how to do this.

Mar 3, 2016

I'm still dealing with the build issue. I have zero clue where the incorrect (referencing variables that are not defined) Java code is coming from. I'm pushing a change that Tim proposed (replacing all "\n"s with System.lineSeparator()). It doesn't seem like this is the issue, because even after I fixed this, the build failure persisted.

Vahdat offered to take a look at the failing build, so I will contact him and see if he can help me figure out what's going on here.

I've also spent some time looking over the code and thinking about how to do the next part of my task -- which is specifying parameters in code injections (i.e., inject into method foo with parameters (int, string) but don't touch the method foo with parameters (int, int)). This seems fairly simple to do. I'll just need to change the parsing a bit to update what an injection token looks like, modify the method that matches a method name to methods to allow it to take in parameters and allow passing in of parameters from the code generator side (i.e., when the requests for the relevant code injections are made).

I will get straight to work on the next feature (and I think my last big one) as soon as I resolve the build issue that's occurring at the moment.

Feb 21, 2016

I haven't updated my log page in a while -- as over the past two weeks I've been in a perpetual cycle of almost finishing the feature that I was working on (meaning I've been wanting to delay my log update until that was done). Since my last log post, I submitted a pull request consisting of my finished implementation of warnings being thrown for attempted code injections into non-existent methods. The pull request was approved and the task was marked to be complete.

Since then I've been working on implementing code-injections into user-defined methods. I initially thought this would be fairly straight-forward. For before injections, it is in fact straight forward, you simply inject the code at the start of the method. However, for after injections, there are a lot of edge cases that needed to be considered.

The way I handled after injections was to place the code before every return. However, this led to problems in the situation where you have code like:

if(test)
  return b;

Because the if-statement is written to only handle a single line in its body. This meant I had to write code to detect the existence of such a situation and deal with it appropriately. But ok, that should be easy enough to do... Or so I thought.

It's a bit more difficult than simply checking one line up to see if it ends in a ), because comments are an issue:

if(test)
  // test
  return b;

The aforementioned strategy would fail on this. But I guess we could ignore all lines that begin with a comment token (// in Java). Nope:

if(test)
  /*
    test
  */
  return b;

This led to me finding some regex to remove all of the comments for me. From there, adding in braces where they needed to be placed was fairly simple.

It was also a challenge to get indentation to work properly, especially for cases like:

if(test) return b;

So, I applied a pre-processing step where I fixed all returns that weren't on their own line. I wrote an Umple file that covered all of the cases I mentioned and generated the corresponding Java file. The generated file looked exactly as I expected it to.

While I haven't updated my log over the past two weeks, I did participate in a lot of discussion on the issue assigned to me and my pull request. A lot of what I discussed in this log was also covered there: https://github.com/umple/umple/pull/731 and https://github.com/umple/umple/issues/710.

I'm currently getting a build failure. I'm not sure how my code could have caused this though. The build is complaining about faulty Java code -- which seems to have been injected. However, I cannot find any corresponding before/after statement that matches this code, and I'm not sure where it comes from. It also doesn't have the typical comment above it indicating the source in Umple. I only experienced this failure after I merged the most recent Umple commits into my local repo.

Feb 7, 2016

I've gotten most of the tests to pass. I encountered a variety of issues while doing so. Firstly, my Eclipse set up started giving me issues, which required me to reclone my repo and go through the set up process again. Second, I got confused about where to look for information about which tests failed, when building through the command line.

For future reference (both for me and if anyone ever reads this), test information is located at dist/qa/cruise.umple/all-tests.html.

At the moment, I've fixed all of the failing tests. Some of the issues were from me not passing a valid position when instantiating an ErrorMessage. There were a number of issues with the tests themselves, including the fact that no UmpleClass was being assigned to AssociationVariables, but one was required to retrieve the singular name of a field. There were a number of issues with my Umple code in the tests, that I resolved.

I contacted Vahdat about the remaining failing test, which is an issue in UmpleTraitTests. The test is failing because 0 code injections are identified in a piece of Umple code. When I stepped through the execution of the test, it seems like the code injections are being identified, but the count is still 0 in the end. I'm not sure where the passing on of injections happens between a trait and a class, which is why I asked for help.

This week has been really busy for me -- with a ton of homework and multiple exams. In a week, I'll have no classes and no work for a week, meaning that I'll be able to contribute significantly to Umple during that time. Until then, I have to suffer through midterms and assignments, but I will find time to work on Umple on Wednesday and Friday of the upcoming week.

My plan is to (after resolving the UmpleTraitsTest issue) work on the issue involving the value for lists not being generated properly and also look into adding injections to user defined methods.

Jan 31, 2016

I put in a solid 6-7 hours of work into working on Umple today and got quite a bit done. I finished solving issue #646, which involved fixing the issues with false-positive warnings. I identified an issue with associations not being identified at the right point. I'm currently at a stage where I'm getting failures that I don't quite understand, and am planning on emailing the mentors about.

To test to my implementation, I've been using the umple.jar on cruise.umple/src/Master.ump to ensure there are no false positives with my current implementation. At the moment, when I do this I don't see any 1012 errors, which is what I was seeing before.

I finished dealing with interfaces today which was fairly trivial after figuring out how to deal with classes. I was still left with a few false-positive warnings though, and upon examination I discovered that the following case was not being handled properly:

class A {
  1 -- * B;
}

class B {
  after setA {
    // TEST
  }
}

Of course, this took me a while to figure out, because it so happened that the false positives all dealt with abstract classes which made me think that those weren't being handled sufficiently. After a while, I realized that that was not the issue and all of the false positives were akin to the class B in the above example.

After some more examination, I realized that the way that the inline association tokens were handled is as follows: (1) they were added as attributes to the class that they were written in, the opposite of the token (ie. the correct token for the other class) was added to a list of unlinked associations, (2) sometime later, the unlinked associations were taken out of the list and added to the appropriate class.

HOWEVER, sometime between (1) and (2) is where the code injection tokens were being analysed. Which meant that my code had no access to the association when it needed them.

I fixed this issue by ensuring that my associations check happened after all of the tokens were loaded and operated on the created code injections rather than the tokens.

After doing a full build, my code stopped causing false errors on the build of the umple project. I merged the latest commits into my fork and added a few tests. However, when I did a full build (even after doing a first build again), I get failures that I can't figure out the root cause of.

template.test:
    [junit] WARNING: multiple versions of ant detected in path for junit 
    [junit]          jar:file:/usr/share/ant/lib/ant.jar!/org/apache/tools/ant/Project.class
    [junit]      and jar:file:/home/shikib/projects/umple/dist/libs/core/ant.jar!/org/apache/tools/ant/Project.class
    [junit] TEST cruise.umple.compiler.UmpleClassTest FAILED
    [junit] TEST cruise.umple.compiler.UmpleParserTracerTest FAILED
    [junit] TEST cruise.umple.tracer.implementation.java.JavaConsoleTracerTest FAILED
    [junit] TEST cruise.umple.tracer.implementation.java.JavaFileTracerTest FAILED
    [junit] TEST cruise.umple.tracer.implementation.java.JavaStringTracerTest FAILED
    [junit] Tests FAILED
compileJava:
     [java] Processing -> testbed/src/TestHarness.ump
     [java] Umple compiler error. Stack trace follows
     [java] To locate the error in the original Umple source, set GeneratedSourcePath to where the generated Java is located:
     [java] e.g. setenv GeneratedSourcePath ~/umple/cruise.umple/src-gen-umple
     [java] Exception java.lang.RuntimeException in
     [java] java.lang.RuntimeException: Unable to create ErrorMessage due to aPosition
     [java]     at cruise.umple.compiler.ErrorMessage.<init>(ErrorMessage.java:42)
     [java]     at cruise.umple.compiler.ErrorMessage.<init>(ErrorMessage.java:134)
     [java]     at cruise.umple.compiler.UmpleInternalParser.checkCodeInjectionValidity(UmpleInternalParser.java:4228)
     [java]     at cruise.umple.compiler.UmpleInternalParser.checkCodeInjections(UmpleInternalParser.java:1978)
     [java]     at cruise.umple.compiler.UmpleInternalParser.postTokenClassAnalysis(UmpleInternalParser.java:1964)
     [java]     at cruise.umple.compiler.UmpleInternalParser.postTokenAnalysis(UmpleInternalParser.java:1271)
     [java]     at cruise.umple.compiler.UmpleInternalParser.analyze(UmpleInternalParser.java:1054)
     [java]     at cruise.umple.compiler.UmpleModel.run(UmpleModel.java:1215)
     [java]     at cruise.umple.UmpleConsoleMain.runConsole(UmpleConsoleMain.java:109)
     [java]     at cruise.umple.UmpleConsoleMain.main(UmpleConsoleMain.java:151)
     [echo] Last Version: 1.23.0-3bd2bc7
BUILD FAILED
/home/shikib/projects/umple/build/build.xml:9: /home/shikib/projects/umple/build/build.xml:29: The following error occurred while executing this line:
/home/shikib/projects/umple/build/build.testbed.xml:251: The following error occurred while executing this line:
/home/shikib/projects/umple/build/build.testbed.xml:68: The following error occurred while executing this line:
/home/shikib/projects/umple/build/build.testbed.xml:77: Java returned: 255

I can't figure out why the tests are failing, and will contact Vahdat for assistance with this. My latest code is available at my fork.

Jan 29, 2016

Over the past few days, I've been working on fixing the issue with after/before code injections on methods extended from a super class or inherited from an interface. I currently have an implementation that works on basic cases, such as:

class A {
  k;
}

class B {
  isA A;
  after setK {
    // put code here
  }
}

While this caused a warning before, this is no longer the case. I'm also using a BFS traversal type of strategy to ensure that I get all of the extended classes (ie. going back up the chain). This means that cases like this are also successful (in not printing a warning):

class A {
  k;
}

class B {
  isA A;
}

class C {
  isA B;
  after setK {
    // put code here
  }
}

I'm currently working on handling interfaces, which shouldn't be much work after having figured out how to deal with extended classes. Once I finish that (hopefully today) and write a few unit tests, I will make a pull request.

Jan 24, 2016

I haven't updated my log page in two weeks now, so this log will include what I did during the 3-day code sprint in Toronto as well as the week after it.

I was assigned issue #410, which seemed simple at first, but ended up being more complicated than I originally anticipated simply due to the various cases that I needed to handle. Essentially, the core difficulty with this issue is that I need to generate the warnings for the after/before statements at the modelling level -- however the methods aren't generated until after this stage in the JET (if we're compiling to Java).

This meant that to determine if an after/before statement specified a valid method, I needed to determine all of the methods that would be generated for a given class. My initial for this issue only dealt with methods that would be generated as a result of attributes (both single-valued attributes and lists).

For example, the following class would generate setA and getA:

class A {
  a;
}

I also needed to handle the various cases of variable modifiers. For example, because of the "internal" modifier, the following class would not have a setA or a getA method.

class A {
  internal a;

Initially the plan was for me to leave the changes in this state, and handle the methods that were created due to associations + state machines after the code sprint. I assigned myself to issue #689 and begun working on it.

I thought that issue #689, might just be due to the code that handled the const modifier being unable to deal with lists and treating a list variable as having the the type of the values it's storing. This was the case, but there seemed to be more with the bug, as removing the const and just assigning a value to a list was leading to issues.

I didn't get a chance to look further into this issue at the code sprint, because my earlier commit was generating false positives for the Umple build of itself. When I forked the associations part of the method generation into a separate issue, I figured that while there might be false positive errors for after statements on association-generated methods for a while this wouldn't happen too often. What I hadn't realized was that the Umple project itself was full of these cases and that the warning would be printed out every time anyone did a build of Umple.

I fixed this (in addition to state machines) and got rid of most of the warnings in my full build. One of the biggest challenges of fixing the code was getting the singular name of a variable. This is because in the case of one to many associations what would happen is that we would have a method with the name add[SingularVariableName] and get[SingularVariableName]. I had to locate a method somewhere that did this for me.

However, even my changes, the warnings in the umpleSelf section of the full build persisted. I looked at the first few and figured that they should be working. I manually compiled similar code which generated no errors. Realizing that I was misunderstanding something about the build process, I decided to experiment a bit.

I manually added the name of the method to my method that identified invalid code injections and threw a warning, in order to have this be ignored. The warning still persisted. I commented out the one location where I was throwing the error, the warning persisted. I completely deleted my warning from the warnings file, yet the error persisted.

At this point, I realized that every single time a build occurred, a jar would be downloaded from the internet and used to build my project. The JUnit tests would the version of my project that was built using the jar from the internet.

I had originally assumed that the last jar that was built would be used to build the next jar, however doing it this way would cause a significant number of problems in the situation where someone gets rid of a bunch of the code (say all of the code that compiles to Java). If they create a jar with this code and then re-add all of the Java-compilation code, they'd be unable compile their project to Java and would thus be unable to create a new jar.

Today, I made a pull request with these changes. Now false-positives warnings are no longer generated for associations and state machines. However, a few of the warnings persisted and upon examination I realized that these were due to umple classes extending other classes. I didn't know that you could call after/before on methods that would be generated by a superclass.

I now need to figure out a way to get all of the methods from a superclass. I thought that this would be fairly simple to do, however there are issues with getting a superclass for a given class at the modelling level. Tim has suggested I look into work done by Aymen (committed in December), as he dealt with a similar issue.

I will look into this issue sometime between Monday - Wednesday and aim to finish this for sure by Wednesday.

To avoid long periods of not working in this project and not updating my log, I am making a personal commitment to work on Umple for a period of at least 1.5 hours (this includes updating my log) every single week on Sunday/Wednesday/Friday.

Date

Jan 10, 2016

Over the past few days, I've been working on setting up Umple on my personal computer. I'm running Ubuntu 14.04 which probably made the process significantly smoother than it might be on Windows. I cloned the Umple repository and followed the development setup guide.

Although I do the majority of my development from the command line with vim, I set up the project in Eclipse anyway as I figured it might come in handy if I run into issues building/running tests from the command line. I ran all of the JUnit tests in cruise.umple and everything passed successfully.

To ensure that my Umple build worked correctly, I set up a local Umple web server by running php -S localhost:8001 from the umpleonline directory. Initially, I was able to load example Umple code into the text box on the left hand side of the screen -- however neither the class diagram on the right hand side nor the code generation worked successfully. Both the class diagram viewer and the generated code displayed the following error: "Diagram is out of synchronization with the text due to selecting Manual Sync or an error in the text that has caused the to compiler produce no output."

Running ant -DshouldPackageUmpleOnline=true -Dmyenv=local -f build.umple.xml packageUmpleonline, which gives UmpleOnline access to the Umple jar files, fixed this issue and I'm able to use my locally hosted UmpleOnline with all of its features.

I also experimented with generating Java code from a .ump file. I wasn't sure what the best way to do this was, what I did was run java -jar dist/umple.jar helloworld.ump from my umple directory. The generated Java file matched the code generated by UmpleOnline and seemed to reflect what was in the .ump file (although there was some extra exception handling Java code that I didn't understand the purpose of).

I tried looking for more documentation on how to generate non-Java code from the command line (as you already can with UmpleOnline), but I was unable to find anything. I will spend more time looking into this later today or tomorrow. I will also try umplifying some of my existing projects to improve my understanding of Umple.