UCOSPLogMarcAntoineGosselinLavigne

Kevin Brightwell edited this page Aug 26, 2015 · 1 revision
Clone this wiki locally

Each UCOSP participant is asked to log all their accomplishments as well as the difficulties they have getting set up to understand Umple and other experiences they have. Difficulties might include understanding how to model in Umple, using y 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.

Log entries in reverse chronological order

Dec 15th

I canceled issue 469 (on Google Code). It turns out that public static variables are not supported in PHP interfaces, so const has to be used instead. I still find it somewhat peculiar that we use public const in classes but, that being said, its clear that const should be used in interfaces.

I made tests for issue 428 (on Google Code), issue 467 (on Google Code) and issue 468 (on Google Code) and committed the fixes and the tests. I then committed my fix for issue 441 (on Google Code) and the accompanying test.

Dec 13th

Fixed issue 443 (on Google Code) as or r3282 (on Google Code), where Ruby comments generated by a specific method in UmpleInternalParser_CodeClass.ump ( analyzeException ) was generated with "//" rather than with "#". I believe JC dealt with something similar earlier in the term - either, its obvious from looking at the source file that this problem was found earlier and was fixed for other methods, just not analyzeException. So I just copied the existing fix and applied it to analyzeException.

As noted earlier in my logs and in the hangouts I already had a fix for issue 432 (on Google Code), an error not being thrown when two or more constants in an interface share the same name, but was struggling to create an appropriate test. I created a test for it and applied both the test and the fix as of r3281 (on Google Code). Additionally I added tests for some previous fixes I did - I added a test to make sure a warning is thrown when the keyword constant is used instead of const in an interface ( issue 416 (on Google Code) ) and tests to make sure a warning is thrown when a primitive constant is uninitialized and that an error is thrown when a non-primitive constant is uninitialized in both a class and an interface ( issue 424 (on Google Code) - there was already tests for this issue, just none for the warning / error being triggered).

I am currently working on issue 428 (on Google Code), which has been the bane of my existence this semester. It looks like I finally have a fix for it. It doesn't change how interfaces are dealt with as I had hopped but rather works around how interfaces are currently handled (i.e. works around the fact that interfaces don't use Attribute objects but rather Constant objects). The fix involved changes in the Generator_Codelanguage.ump file and of the languageInterfaceGenerator.java files of each language (I made changes for Java, C++, PHP, Ruby and SQL, though since SQL does not support interfaces the changes for that language don't affect the output at all and where only really done to maintain consistency) - specifically adding two methods in languageInterfaceGenerator.java to allow us to parse constants by sending its type and value as a String rather than having to send them as part of an Attribute. While working on issue 428 (on Google Code) I also discovered issue 467 (on Google Code) (Date and Time where being treated like Strings in interfaces rather than being parsed as Date and Time objects), which I fixed for Java, PHP and Ruby (I also "fixed" it in C++ in such a way that interfaces match the behavior of classes when it comes to parsing Date and Time objects - it doesn't appear that support for Date and Time is a feature in the new C++ implementation yet), issue 468 (on Google Code) (constants declared in interfaces would simply not appear when compiling to Ruby) which I fixed and issue 469 (on Google Code) (inconsistency with how const is parsed in PHP - it becomes "public static" when from a class and "const" when from an interface, which is unlikely to be by design) which I also fixed.

What I have pending: create tests for issue 428 (on Google Code), issue 467 (on Google Code), issue 468 (on Google Code) and issue 469 (on Google Code). Once the fix for issue 428 (on Google Code) is committed I can finally apply my old fix for issue 441 (on Google Code) (type inference for interfaces / throwing a warning when the types don't match). Hopefully all of this should be committed tonight.

Additionally I plan to send documentation for errors 35, 37, 112 and 901 before the end of the week-end.

Nov 27th

Issue 424 (on Google Code) and issue 425 (on Google Code) have boon been fixed as of revision 3239 (on Google Code). The issue with floats is avoided by doing a checking the language of the first generator of the Umple model:

this.getModel().getGenerate(0).getLanguage();

This returns the language the code will be generated in if it has been explicitly specified and throws an exception otherwise. Working under the assumption that Umple generates Java by default I simply set a float to 0.0f if an exception is thrown or if Java is specified as the language and I set a float to 0.0 otherwise. This is admittedly not very elegant but it works.

I also made the decision to throw an error when a constant that is not from a built-in Umple data type is not initialized. I made this decision because, while there are fairly obvious defaults for the built-in data types that we can test for this isn't necessarily the case for an arbitrary object. We could set it to null and warn the user (this would be a trivial adjustment) but I decided not to do this because it could cause uncompilable code and there is absolutely no use case: if a user wants a null object for whatever reason they can explicitly declare it as such themselves.

I had a lot of problems getting tests running for Ruby and PHP. I eventually got the Ruby tests to work properly, but there is a continuing issue with PHP which might very well be a new bug in Umple (or me lacking understanding of PHP - just like my lack of understanding of Ruby made me thing I had discovered a bug in Umple yesterday):

An Umple constant in PHP is defined as:

public static $A = 0;
public static $I = date("h:i:s", strtotime("00:00:00"));

This works fine for numbers, strings and booleans. However, for dates or times is does not and returns the following error:

PHP Parse error: syntax error, unexpected '(', expecting ',' or ';' in [[path]] on line [[line number]]

By comparaison, this is what happens when Time or Date isn't a constant:

private $t;

public function __construct()
{
  $this->t = date("h:i:s", strtotime("00:00:00"));
} 

Upon further investigation, I found that PHP static variables can only be initialized as a constant or a literal. More importantly, PHP static variables cannot be initialized to be an object. ( http://php.net/manual/en/language.oop5.static.php ).

I don't really know enough about PHP to verify what the alternatives are, so far my only idea is a static method.

Nov 17th

Issue 424 (on Google Code) has been fixed as described in the last meeting: constant numbers are set to zero, booleans to false, strings to empty string, times to midnight (00:00:00) and date to the current date. The error message generated now explicitly tells users to what the constant was generated. There is now an error (rather than a warning) when the initialized constant is not a built-in data type. This is because there is no obvious default value and considering that at best it would represented a null instance of the object I don't believe it is worth supporting.

I ran into problems during testing, however. The default types work in PHP, C++ and Ruby but not Java - specifically, public static float A = 0.0 throws a loss of precision error. The proper way to initialize it is to either cast the 0.0 or to use the float literal (0.0f) representation. Neither of those solutions make any sense in PHP or Ruby, however.

Nov 6th

Made a fix for issue 432 (on Google Code), where multiple attributes of the same name could be generated simultaneously in an interface. Issue 424 (on Google Code) is also partially fixed once again - the warning for an uninitiated constant located in an interface now gets thrown. However, it was brought up that the way constants get default variables isn't good. Currently constants that don't get initialized get defaulted to null, which may cause the generated code to fail to compile in some languages (such as Java). There would need to be a smarter set of rules on how to initialize such constants. Once this is figured out 424 can be closed for good.

441 is partially fixed, in that while the issue itself is resolved it doesn't make sense to apply the patch because of issue 428 (on Google Code). Type inference does work, however the default Umple types do not get translated properly into the generated languages. I've spent quite a bit of time looking into issue 428 (on Google Code) without much success. This is actually a fairly major issue and if I don't manage to find a lead soon I'll have to start asking around for help on it.

Beyond creating test cases for issue 432 (on Google Code) and issue 424 (on Google Code) and committing them I intend to work on issue 443 (on Google Code).

Oct 23rd

I ran into issues re-integrating the code I had previously developed to refactorize interface with newer commits. I do believe that the error is on my end, but after spending quite a bit of time on it I still struggled to make it work. I decided to focus on fixing the issues that exist with interface first and to refactorize after.

In that optic, I worked on and fixed issue 452 (on Google Code). That issue actually isn't purely related to interfaces, but rather both interfaces and classes. Essentially the motivation for this issue was realizing that in Ruby a constant is denoted exclusively by having its first letter be upper case. Two new warnings where added: 160 (for a constant that has an invalid name) and 161 (for a constant that does not start with an upper case letter). The code that generates both warnings is based on the code for errors 140 and 141. I also changed the name of the constants in Umple's source code to be in caps to avoid having errors thrown when Umple is compiling itself.

Oct 17th

I have modified UmpleElement to take on much of the variables UmpleClass had earlier. UmpleClass now only contains elements that are uniquely necessary to classes. This makes it possible to use the UmpleClass validation code on UmpleInterface. I am currently toying with a change of the Interface grammar, but I came to the conclusion that it would probably be better to make Interfaces function properly before I modify the grammar to make it work in the same way a Class' grammar does. I still need to implement test cases and do some minor tweaks to UmpleInternalParser_CodeClass.ump before my changes can go live. After that's done I'll work on unifying the grammar for classes and interfaces.

Oct 1st

After getting back to working on Umple I decided to tackle some issues with interfaces. I quickly noticed issue 441 (on Google Code), where variables declared in interfaces didn't have their data type automatically detected by the parser. I worked on implementing a test for it until I realized two things more or less simultaneously: this was a useless fix until issue 428 (on Google Code) was addressed and only constants should be parsed anyway: declaring a value that isn't constant in an interface should throw a warning. I then went on to try to fix issue 424 (on Google Code) but I quickly came to the conclusion that fixing the parsing for extra code in interfaces would need to be done first. Hence I opened issue 442 (on Google Code) and started working on it. Some relatively far reaching changes had to be done to solve this issue: the analyzeExtraCode method in UmpleInternalParser_CodeClass.ump has to be modified to take UmpleElement rather than UmpleClass, the Token class had to be modified so that its getRelativePath method takes an UmpleElement rather than an UmpleClass and the UmpleModel variable carried in UmpleClass was moved up to UmpleElement. While technically speaking I have a working fix for issue 442 (on Google Code) it brings up a bigger, more pressing issue: method declarations in interfaces are treated as extra code, so it would be problematic to push out that patch (it would throw a warning for something that should be a legitimate activity). See issue 444 (on Google Code).

I came to the conclusion that much of UmpleInternalParser_CodeClass.ump has to be re-written to use UmpleElement rather than UmpleClass.

Unrelated, but while looking through UmpleInternalParser_CodeClass.ump I also discovered issue 443 (on Google Code), relating to improperly generated Ruby comments.

Sept 22nd

Just before leaving the code spring on the 21st I had a suspicion that I might have found another bug with how const was being handled inside of interfaces. I added it as a comment to issue 416 (on Google Code). I found it odd initially because I didn't have the problem on my local machine.

I'm still not sure if it is a bug I introduced myself with an earlier patch or if it was a bug I fixed without realizing it and just did not commit, but either way once I stopped looking at my working copy and download a fresh copy of Umple it became clear that only a trivial grammar fix was needed, from

constantDeclaration : cons ([=list:[]] [name] | [type] [=list:[]] [name] | [type,name>1,0]) (= [**value]) ;

to

constantDeclaration : const ([=list:[]] [name] | [type] [=list:[]] [name] | [type,name>1,0]) (= [**value])? ;

Sept 21st

Most of my morning was spent fixing my umple environment and re-creating my fix for issue 416 (on Google Code) after an unfortunate incident with svn. Lesson learned. After that issue was fixed and committed I turned my attention to issue 424 (on Google Code). This issue is can be broken down in three separate pieces: declaring a constant without initializing it does not throw a warning in either classes or interfaces and uninitialized constant in interfaces are not processed properly (instead of initializing as "null" in the target language they are not initialized at all, just declared).

I managed to fix the first part of the problem (throwing a warning when declaring but not initializing a const in classes) by adding the following bit of code in the analyzeConstant and analyzeAttribute in UmpleInternalParser_CodeClass.ump:

if(constantToken.isValidIdentifier("value") == false){

Token nullToken = new Token("value", null); constantToken.addSubToken(nullToken); setFailedPosition(constantToken.getPosition(), 35, constantToken.getValue("name"));

}

I am currently working on fixing this issue for interfaces, but it has been much more difficult than fixing it for classes so far. Additionally, while testing issue 424 (on Google Code) I discovered issue 428 (on Google Code).

Sept 20th

Arrived at the code sprint. I usually work in a Debian virtual environment at home and I had planned to use it remotely from the Mozilla office. Sadly, as the wi-fi was very (very) slow I had to build a development environment on my laptop from scratch. The first issue I worked on was issue 416 (on Google Code). It initially appeared to not be an issue, as per two earlier comments, however upon further investigation it transpired that two different keywords where used for constant variables: const in classes and constant in interfaces. The decision was made to use const for both and to deprecate constant for interfaces. We also discoreved that the keyword is implemented differently in classes and in interfaces (const was a modifier in classes while constant was part of the declaration of interfaces.

It took me a long time to find out how to understand how the grammar files work and how to find which .ump files work. Ultimately I was able to fix the problem by changing the grammar in umple_grammar from

constantDeclaration : constant ([=list:[]] [name] | [type] [=list:[]] [name] | [type,name>1,0]) (= [**value])? ;

to

constantDeclarationDeprecated : constant ([=list:[]] [name] | [type] [=list:[]] [name] | [type,name>1,0]) (= [**value])? ;
constantDeclaration : const ([=list:[]] [name] | [type] [=list:[]] [name] | [type,name>1,0]) (= [**value])? ;

constantDeclaration and constantDeclarationDeprecated are handled exactly the same way with one exception: constantDeclarationDeprecated throws error 901, which is a warning to the users that they are using a deprecated keyword.

I was not able to commit on the 20th as I had some growing pains learning how to use svn.

While investigating the above issue I discovered issue 424 (on Google Code).

September 11th

This week I successfully managed to build the command line version of Umple on a Linux machine. I had quite a few issues initially, including having to change my Java environment (from Open JDK 1.6 to Oracle's JDK 1.7) and initially having some issues using ant but overall it wasn't too bad. The build test was successful and I have been able to use the software to generate source code from Umple code. I have played around with various examples to familiarize myself with Umple and I am currently looking through the code base.

This week I am planing to learn how to run and create tests. I'm also planing to create tests and start working on issue 416 (on Google Code).