UCOSPLogMorganRedshaw
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
Spent quite a bit of time on the automatic converter, and it can now automatically translate everything that I intend on it handling. There are still some things that must be done by hand (like changing the template to not add a newline for the first line of the generated source code), but I don't anticipate them ever being handled.
Once I create the pull request for this change, all I will be doing for the converter/Umple will be refactoring for the converter and documentation.
Managed to finish up shifting from JET templates to Umple templates. Also, uploaded my converter to the Umple organization. It still has quite a bit of work left, but best to have it be stored on more than just my computer.
In the last few days, I was able to add in the Umple templates for Ruby and Sql, as well as a few spaces changes for Ruby code that would allow the tests to work.
However, converting the Java templates appears to be far more difficult. For some reason, I am getting an error where some of the code the JavaSpecGenerator creates is the line "You forgot to include specializationSkip.jet". This appears to be caused by mismatching brackets and if-else statements, since I haven't seen this error with the JET templates.
I will hopefully figure this out today or tomorrow, so I can finish up the switch to templates by tomorrow.
I have been able to get the Umple build to use php Umple templates, rather than JET, and also rebuild them during the compilation process.
This means that I could also remove the generated code for php from version control.
Haven't been able to work on getting the Java templates to be able to be copied directly into the build, so that will probably need to wait until next week.
Note: These two were posted by me a bit later (since I had been really busy, so wanted to work on coding the converter and converting by hand rather than updating the wiki...). Did communicate my progress in the weekly meetings though, so could have been worse.
Now able to get all of the Java and Ruby tests to pass. As well, am now able to replace the JET generated files for Ruby and Php with the files generated by Umple, rather than needing to replace the code inside of them. Java will take a bit longer, due to the JavaClassGenerator and JavaSpecGenerator being far more complicated, and it looks like they will take quite a bit longer to finalize (the reason is how these two templates define multiple functions inside of a single template, so take more work to convert).
There were some space differences (where JET would include extra spaces on what should be blank lines, while Umple would not). While I was able to fix most of them in both JET and Umple, I was unable to determine where some of the extra spaces were created in JET. Luckily, I was able to get Php to be the exact same output for both, so will be able to test integrating it first.
So for the coming week, will try to integrate Php and Ruby into the build, and replace the usage of the JET templates with them. Java will need to wait a bit longer, because other developers are working with Java, so will need to wait until they are finished first.
As well, I will commit my JETToUmple converter as a new repo to the umple organization. It will be really rough right now, but I will commit its code and all of the tests (most of which are just the php templates along with their expected result). I will fix + clean up the code and tests once the switch from JET to Umple templates is mostly completed.
The only difficulty that I will have this week is that I will be unable to work on Umple for the majority of the weekend, due to other commitments.
Worked quite more on the converter this last week. Will now fail only 1 out of the 237 tests that php has, and the test it is failing on has extra spaces on weird lines that I will remove. As for Java, only 164 tests out of the ~500 tests will fail. It looks like most of the ones that fail are caused by it containing a tab, which the Umple templates will convert to spaces, so I will need to edit the tests to fix that.
I will continue to work on the converter for a few more days this week, since it looks like there are a few more special cases that need to be handled (like tabs possibly), but it should be able to convert most templates without problems. I will then start working on making it so files generated by the Umple templates can be copied directly into the build, and will pass the tests.
Have spent more time on the template converter, by trying to convert the php templates. I believe the translation will ultimately be semi-automatic, because of things like JET removing the newline for the first text printed, but most of the translation will be automatic, so should be easy to translate the other templates. Will spend up to one and a half more weeks on the converter, then will need to work on finalizing the translation for all of the Umple templates, adding extra documentation to the converter and improving the tests, and getting the converting into the repository.
Since there had been an overwhelming number of differences, I have been working to get each of the templates that phpClassGenerator includes to work. Currently, it will fail 114 out of the 237 tests that php has, although a few minor changes (like not adding a newline to the first text) must be performed by hand to the template. Of course, many of these tests will fail due to similar issues, so there is not as much work required as they would suggest
I can understand why JET has fallen out of favor, because there are quite a few special cases, especially focused around } and the end of code blocks.
Due to all of these special cases, I have also create a small test suite for the converter. The main tests I have now are for certain special cases (like those around }) that the converter should handle. Since I may mistaken the special cases, I am also checking that none of the previously checked templates have changed when translated as well.
I have run into an error for Umple around comments (issue #763), but there is an easy workaround and so it isn't a high priority right now.
Had posted an update on the issue page, but forgot to update this page.
The two issues I had, #736 and #735 were fixed and #732 was essentially fixed.
Have handled most of the special cases for Umple, although there are still some differences that need to be handled. Most of them look like will need to be handled in the converter
Put a lot of time into the converter. Is able to convert most of the major elements of JET templates to their equivalent in Umple.
After replacing one of the JET templates with a template that was generated from Umple after running the converter, I found that there are some differences after converting everything directly. Will not go into details here, since I plan on reporting on these changes in the issue tomorrow, since it is too late for me to ensure the post makes sense. The converter can handle this, but it would not be pretty.
There is still quite a bit of functionality missing, especially not yet creating any emit statements, and among other things, does not parse the JET directive at the beginning of each template, which has some important information in it.
Also, I have not been very good at updating my log, so will try to focus on updating it after every major work session.
Began work on the JET to Umple converter. Using Umple to write it, although most of the code is just Java anyway. Will hopefully be able to use more of the elements of Umple as time goes on, especially once I have it working, and refactor the converter to make it easier to understand.
Worked quite a bit on the conversion to Umple templates from JET. Found that, by implementing one additional feature in the templates (referencing other templates inside, without using a function call), this conversion would be trivial.
However, I am (albiet biased), against referencing other templates, due to the issues that ahmedvc mentioned, including allowing worse code style/practices, and additional complexity. As well, that would trivialize what was supposed to be the term project, and I think that trying to automate the conversion would be an interesting project to work on.
To proceed, I will look through the Umplificator for code that would simplify the parsing of the limited Java in each template. As well, will also keep my ears open for other, or specific, suggestions for where to look for code to let me parse, from Java, what variable names are used in each template.
As well, I will also begin to write a very simple parser in Java, to allow changing all of the other JET syntax, mainly <% and such, to the syntax that Umple's templates use.
Once I get the template conversion working, I will try to hook in some converted templates as a sanity check. Would only convert one or two, and get the existing JET to call them.
Started working on moving from JET to Umple's code generator mechanism. Most of the mentioned files, if not all, can be found in cruise.umple/src. Started by looking at the conversions done by the Documenter when generating the HTML documentation.
However, it appears to be fairly limited and not quite what we want. Managed to find the state tables that Tim mentioned, and the code in Generator_CodeStateTables.ump, line 468 seem to be exactly what I will need to generate. As well, just found some documentation on Umple templates which help describe what I will need to know. Also looked at https://eclipse.org/articles/Article-JET/jet_tutorial1.html for a basic tutorial for JET, so I can understand how its syntax works better.
After getting a better understanding of JET and Umple's code generation, I definitely feel it is possible to semi-automate, and possibly fully automate, the translation from JET to Umple. Will try to get a feeling for how to do so by first creating a translated version from a JET template by hand, to get a feel for what exactly will need to be done. This should be done on Tuesday.
Then, will start to look at planning how I can write the parser to allow the code to be translated.
Since I just fixed the Java JET template being unsynced with the generated code, was able to fix a minor issue where one of the JET templates would create code that was missing a (). It was pretty simple to determine which template was causing the issue (just added a comment to the start of each), and took a little more work to determine what the fix. In the end, the fix was just to add an else statement, since there was one case that wasn't covered by the line that caused the issue.
Also added a simple test-case, that fails when the change is not implemented due to the code not being runnable.
After a busy week of catching up on my other classes, I was able to work a bit more on syncing the UmpleToJava JET templates with generated code.
I believe to have synced the JET templates with the generated code, although I haven't yet synced the UmpleToTemplate with UmpleToJava.
The good news is that the fixes were very easy, and apart from the commit that I had outlined, involved just a few lines of code, mainly related to some of the changes in a commit in March?, although there were some other error causing changes as well (not checking if a variable was null before using it).
Also, I found the commit that I believe I will be essentially duplicating for PHP, Ruby, and C++ to allow them to handle association properly. This should help with syncing for UmpleToTemplate. Yes, this commit does look like it will, since the test TestHarnessAssociationSpecializations.ump contains some of the associations that are in the issue.
The bad news is that some of these changes occurred quite some time ago, and were either not noticed or overwritten due to the commit that I revered.
Was a very... interesting two day. Continued to work on the PHP class hierarchy association issue, but found quite a few other issues as well. Since php is a dynamically typed language, I first figured I would look at the code generated for Ruby to see if it had any good approaches for it. However, Ruby also suffered from the same issue that PHP did, as does C++.
Then, started to look closer at the code generated by Java, and realized that it would create unsafe code. After some discussion with Vahdat, we agreed that I would continue to work on getting PHP to work like Java does with class hierarchy association, in the same way, so that the fix for Java will easily apply to PHP.
The reason the Java code works, I believe, is because it will specialize the naming of functions using association_set_specialization_reqCommonCode.jet. To test how it does this, I then started to work on compiling the Java JET, so could add identifiers to each of the different templates. However, this caused the full build to crash, and led me to the unapplied Java JET templates changes.
My plan for the next week is to first sync the JavaClassGenerator with the JET template, then I will go back to the PHP issue. After my initial test, it doesn't seem to have completely fixed the issue, since there were other changes to the code generated from the JET templates for Java. It may take some investigating to figure out exactly what is happening, so I would expect the Java will not be finished until the weekend, since I will also need to catch up on other classes this week.
This issue with the Java JET does bring to focus the issue that the Travis CI build isn't able to compile the JET templates. Another concern is that JET hasn't been updated since 2007, and may not be compatible with Eclipse sooner or later, although developers could use an older version of Eclipse to compensate. One task for the rest of this term (or a future term!) could be to begin to switch away from using JET to an alternative, one chunk of the codebase at a time.
One issue I did have was determining that it was required to use the Eclipse plugin to build the JET code. There were some points where I thought that running a full build multiple times would cause the JET to be compiled, but I apparently had the eclipse plugin working in the background during those times. This was mentioned in some spots in the documentation, but it appeared to be old information. I am planning on doing a small documentation update in the next week, so will make sure to make it obvious that they are only compiled with JET.
I primarily worked on Issue #548, which was based around difficulties with shortcuts in UmpleOnline. While I had searched for 30 minutes earlier this week without any success for where the shortcuts were created, I somehow found the code for this in the first file I looked at today (the files are umple_page.js and umple_action.js in the scripts folder).
It turns out that ctrl-t and ctrl-n are reserved in Google Chrome. While adding shortcuts was very easy, there were some difficulties in deciding on good shortcuts to use, with some alternatives working Windows but failing in Ubuntu. Of course, it took quite some testing to determine the actual issue and come up with good shortcuts.
I also added documentation about the shortcuts to the user manual for UmpleOnline, and made sure that the tool-tips were up to date.
The second issue I moved on to is Issue #599, which is about how php will generate invalid code for some associative relationships. Luckily, Java produces correct code, so I know what the expected output is. Vahdat pointed me towards the JET templates in the repository, which I believe will at least partially solve the issue.
Unfortunately, I was looking at the attribute_set based templates, while the generation was using an associative template, so I did waste some time today. Will hopefully make progress tomorrow, and will ask questions
Have been working on getting Umple compiled and working in my Ubuntu VM and Windows machine over the last few days. Switched to working in windows because of how slow the VM can be, although am getting a SSD drive installed, so will probably just use Ubuntu. (Didn't do an update until now since would only have a few minutes at a time).
I was able to get the ant build script to successfully run on both of them the first time, which was very impressive. Haven't yet tried to install the Eclipse plugin yet, but hoping that goes just as well.
However, when I tried to run UmpleOnline, the page would load fine but there would be the error "Couldn't read results from the Umple compiler!". Since this happens on both Windows and Ubuntu, I would assume that I did something wrong with setting it up, and will retry it this coming week, probably after testing the compiler from the command-line and getting the Eclipse plugin working. Update: turns out my Windows build fails some test-cases, and after running another full build (and then ant -DshouldPackageUmpleOnline=true -Dmyenv=local -f build.umple.xml packageUmpleonline) UmpleOnline worked for my Linux machine.
One difficulty I had was how some of the wiki links are out of date, presumably due to the switch from Google Code. For example, in the next steps part of development setup, many of the links are invalid and I was not able to find any equivalent pages for the Build Issues link on the wiki.
Since I do not have my development laptop for most of Sunday, and possibly Monday, I will be reading through the recommended resources, messing around with Umple, and possibly looking at previous UCOSP logs.
- Wiki Home
- FAQ Frequently asked questions
- Examples
- Presentations
- PhilosophyAndVision
- Best practices for using Umple
- Publications and theses
- Tutorials
- Installing Eclipse plugin