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 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
Worked on constraints, which has been Quinlan's part of the project. So, I basically spent Friday and Saturday playing around with getting the constraints to be more robust, as in only accepting certain things for literals. For example, booleans are the only ones that can be compared to true and false, strings are the only ones that can be compared to "stuff"(I included 'stuff' in the same, code, so you could do String x; == 'blahbadiblahblah' and it should parse as if it were a string. I did this mainly by refactoring constraints from being a list of strings(expressions) in to an list of a new class ConstraintVariables which house some of the methods you would expect, as well as a value, and a type. Besides that I refactored what Quinlan had already done into a new file called UmpleInternalParser_CodeConstraints.ump, which had a bunch anaylze methods, chief among them being analyzeConstraint which at the moment returns a List of constraint variables, when it should really be returning a constraint, maybe someone can do a quick fix for this, in all my wisdom I neglected to.
I have been hard at work on the trace stuff. I may or may not(may) have deleted most of the code in the generators concerning that subject. However, in Java(and easily in the other languages), I'm pretty much back to where Hamoud was. What I did was refactor the things in the Java Generators into the Jet files(as discussed, though this solution was never confirmed to be the one we were pursuing). The other thing I did was basically extend the way that StringTracer is done, and do it for ConsoleTracer, and FileTracer(I didn't find code for Lttng, though if you wanted to implement it, it would mean the addition of that Tracer for each of the generators and about 5 to 10 in the GeneratorHelper. Something that I have been able to add is statemachines can now use any of the tracers(i don't think they could before). Also the associations should be very quick, just takes some grunt work. It is also going to take some grunt work to put the requisite lines into the jet files for the other languages that are not java. However most of the heavy lifting is behind me so I think this solution should be viable by the end of the week. It's going to be a huge update if its accepted, so I'll probably do what I did with constraints, and send it as a patch to umple-dev and specifically Hamoud. I've been slacking in the comments department, but no worries, before I commit/patch anything there will be a plethora of the little devils. If what I've done is not ok, then I'm prepared to restart, no worries, just saying that I'm not too attached to what I've done, but it's highly flexible for modifications(at least in my mind), so hopefully everyone likes it.
yay for long logs
I've been working with Hamoud to improve the tracers. Just wanted to log that I implemented a small grammar change that makes the conditions a lot more compact. Otherwise it's been a lot of thinking and digging, nothing much to report besides the fact that tracers are a little confusing to follow from within the code, which seems to me like it would be hindrance if you wanted to scale it up to do more powerful things.
VICTORY! Sorry for the lack of logs, midterms and life and things, but finally I have it. I have a way to quickly make the implementation files. Unfortunately I'm not sure how user friendly they are, like if someone else wanted to use them it would take a bit of setting up, but if anyone's interested, it's mostly automated which is really nice. I'm a complete newbie at shell so I had to learn it all from scratch which was time consuming. It might have been faster to do this all by hand, but at least now, if there is something that Tim or anyone wants me to change about my implementation of toString's, I can change it quite quickly. So, now all that is left of issue 233 (on Google Code) is for the implementation in ruby and php, which I can do, or I can do the tracing things.
Two things to keep in mind when changing implementation files: 1: comments about the line from which umple file lines of code were generated are discarded in the implementation files
2: remember to change the version number to @UMPLE_VERSION@
just a brief description of how I actually did it. I basically reversed engineered the Test.java files, looking in them for the assertUmpleTemplateFor( as a key word for grep. I had to remove TemplateTest.java of course because that's where the implementation is, but other than that, it was easy enough to extra the umple file that was being used, the java.txt file it was going into and the class name of that was being created. So I just had to match the class name to the generated java file name (because at least the class name and the file name match), and then call it based on the second argument in the assertUmpleTemplateFor method call. Easy as that. The only thing that I found that doesn't meet this description is in the implementation folder, JavaExternalClassText.java which generates things by itself and creates ClassTemplate_BuildPathOutput.ump.txt, ump.txt? what is that? ridiculous, anyway, the point is that there was still that one file that needed to be done by hand.
To long since my last log, midterms and all that. I have updated the statemachines and derived attributes so that they can now be language specific. There were relatively no hurdles to over come, just some minor issues that I caused and then fixed. Nothing really much to say when things are going smoothly/I haven't worked on the annoying implementation tests for toString. But I'll start doing that soon.
Broke the build, that was fun. What I did was revert a file that I thought I hadn't done anything to, which turned out to be something of great importance, stupid. note to self: never commit before doing a full build, I mean, I did a full build, and then reverted, like a genius.
So I gave up on fixing the toString implementation tests, just because it was just too annoying, I'll get back to it, no worries. In the mean time I just wanted to log that I've got the state machines to be language specific, the only thing I think I need is the implementation for language specific derived values for attributes, but that will take me two seconds. Then I just need to do all the tests for them(less annoying than doing the implementation test correction because at least I'll be writing code). Midterms and things should mean that I'll be committing sometime this weekend(including Friday). Seems like after the good hangout I always have a large amount of motivation to do things in Umple, and during the week it slowly drains, good thing it's ever week I suppose.
So, I am ready to commit the toString patch, I just need to fix all the implementation files(71 if Gabe was correct in his count and my memory doesn't fail me). Some changes I've implemented that are of note: I was using just a straight call originally, like when I wanted to access an attribute say "name", I would just say "name = " + name, but I realized that this wouldn't work for derived values, so now it would read "name = " + getName()
Another thing not mentioned in the issue, something I had to figure out the hard way, was that I would not only need to stop overriding the method contained in the class I am currently generating, but also not overriding the toString method a super class. I also needed to do some digging to how to get the parent class, if anyone's interested it's getExtendsClass()
The other problem I was having was with internal, if an attribute is internal it means that no get method is made for that attribute, which means that it shouldn't be visible to the outside world so a toString should not be displaying it. This took a bit of digging too, but I eventually figured it out and realized that it was in the modifier attribute within the Attribute class, so I call "internal".equals(av.getModifier()) to check if the Attribute is indeed internal to the class(same for associations).
Finally committed that patch. It passed, huzzah. I also pretty much completed the part that I wanted to complete for the toString method, the only thing left is to fix the implementation tests so that they don't fail, because they fail. I'm unsure what to do about the List attributes, should I enumerate their elements? probably. Something that took me a while to figure out was that if an attribute is declared internal it doesn't have a get method, same with a const attribute. These things are called modifiers, and you can only detect if they are set by doing "internal".equals(attribute.getModifier()), which is kind of annoying, but anyway, figured it out.
Not many logs recently, sorry. I did get the tests done for issue 356 (on Google Code), the patch I've was creating, and submitted it for review(instead of committing because I'm nervous about it). Today I worked on the toString method a bit, getting some bugs I had thought about out. As well as getting rid of the superString() method. I'm still not sure how I would go about testing it. The next step in issue 233 (on Google Code) is to implement it in PHP and Ruby.
Victory is mine. I have finally got out of the infinite loop I was getting into but still doing the thing I was trying to do(language specific methods). All that is left is to make tests and get rid of the silly implementation tests that are failing(by get rid, I mean, update so that they don't fail). I will probably end up committing tomorrow, but finally some progress. I want to get back into the toString method making i was doing, but the commit i have for this one is big so i didn't want to try and be switching between two patches while working on this error prone area. Just for clarity, the reason it was infinite looping was totally my fault, it was a small bug in the CodeBlock class I talked about in the previous entry. The way I found it actually was by working on the other, interwoven part of this(the sorted fix), just doing some testing and the like and I found the line of code that was not as complete as it needed to be.
Added a new class to aid in language specificity of injected code called CodeBlock. It contains a static String which gets changed to the appropriate language when generate. This greatly simplifies the problem of getting certain code injections to be injected only in a specific language. I also added CodeBlocks to Attributes and Methods, and have implemented Method language specific code blocks within the grammar, I will probably do the same for attributes given permission.
The other change is to the sort method. Instead of having there being (ugly) reflection, I have implemented the sort method in such a way as to take away the generated sort method for each of the Php, Java, and Ruby, and replaced it with a code injection within the add method. Tim asserted(correctly for all I can tell) that there is no need to sort after removing an element from the list, so I removed it at the same time. Just a word of warning when using code injections(before and after), if ever you see that the code injection is set to "internal" then after the first "generate" call that code injection will removed from the class.
These patches are interwoven so it's going to be hard to submit an agile patch, so we'll have to see about that. The problem is that I needed to create language specific attribute injects for the sort methods. So the two issues are kind of overlapping.
(link to blog post goes here) I just wanted to talk about my experience with breaking the build a little. The problem was that I hadn't svn add-ed a .java file that was being called by the compile ant target. This should have been part of the commit because I should have done svn status(though I didn't for some reason, I've done it on my other commits), and I would've noticed '?'s. So this is just a friendly warning to other ucospers to always check svn status, I had checked it but in my other trunk(not the patch trunk that I keep clean). In any case, I just said to myself, what in god's green earth could it be missing and then I remembered. Other than that, I had a great time at the code sprint thanks to the team for being so cool, and to Tim for all your patience.
Long time no entry, I just wanted to summarize what I've done over the past few days because I haven't been making logs because I've been lazy, bad Geoff.
Firstly I worked out how to get issue 271 (on Google Code) done the right way, well, mostly except for error specs that I was unaware of. Which was a good time.
Secondly the patch. So what I did was I did svn status to see all the added files(the generated ones mostly), and I did svn add to them(this is after a build of course). then I did svn commit, and I took out the first line that says everything after this line won't be committed because all the changes were bellow. Then I waited for 4 minutes in nervous anticipation, until the build succeeded, nothing to it.
the only thing that I would advise others to stay away from(if you didn't read tim's email), is the myfile within the dist or the build folder. I should have known because this isn't something that I created purposefully, but I included it out of fear that it was important in some mysterious way.
Some notes: Warnings are the same as errors but the second parameter in the en.error file is greater than 2 (I believe, this was all I could find in the wiki). I've learnt that I should not halt the build(with ctrl+z or the like) from the command prompt because it causes the version to be set wrong which causes some of the tests to fail. So, even if one of the tests fail, I still let it build all the way so that it doesn't get messed with Finally I've learnt the joys of having a sort of dedicated patch trunk and a sort of working progress trunk. This is because the patch trunk(which I don't add files to, only patches), is kept up to date, so when I go to commit a patch, I can do svn and all the files that are changed etc. are shown. Whereas if I did the same in my work in progress one, files that I added and then forgot to remove(etc.) are kept and added to the svn status. Basically I have one trunk that I make my patches in and one that I commit from.
Committing is stressful but if all goes according to plan, quite painless.
seemed like the day of the unfindable bug(issue 271 (on Google Code)). I set myself to the task of find out why there was a difference between umple online and command line umple compilation. Installing umple online was pretty straight forward for me, the only part I had trouble with was the chmod of the path to umple online, it was just my poor interpretation of what that step said that was the problem I think, but it took me a while to figure out none the less.
So I figured out the problem was the setPackageName in the element class(through no easy feat, there must be an easier way to debug, but I was just adding attributes to classes and things like that so that the generated code would display properties that I wanted, like having setPackageName be changed so that instead of actually setting the Package name, the variable passed would append to it(so that I could see that the right namespaces were being added and then overridden). Then the next step was determining that it was indeed the parser's fault, and not some part of umple online(which took about an hour, because I was convinced that umple online must be calling setPackageName). Then when I realized that there were extra tokens being analyzed in umple online verses the command line, I started down the right track(again, having to figure out how to display all the tokens was kinda tricky). So yeah, that was an adventure.
Probably won't do too much tomorrow, too much umple code is bad for the brain, I'm learning.
Well, what to do? I don't want to take any more of the easy issues, because I want the other ucospers to get some practice, I mean, I don't want to hog them. So I tried doing issue 364 (on Google Code). I didn't do any test cases for my solution because I'm not sure if I did it right. It eliminates the problem created by the code given, and I can't see any ways that you can make it fail. But because of the nature of the issue, I'm not sure if there are some cases that would still be broken(I'm not sure if it is a small ice rift or an iceberg, so to speak).
So that's all I've really done today, but I still felt I should log it because of my uneasiness towards what is considered a correct solution. The other reason for the log was the question of why, in java, do we not generate toString() methods(Ruby has similar methods to_s and inspect, I'm not sure about php but, it must as well)? It would seem to me as if they were easy enough to code for, but umple still requires the developer to code one manually. Probably a good reason for it, I was just curious.
Patch creation is awesome :). so I learnt that I was using the command wrong. I thought that it would be putting the patch file within the trunk directory(the patch command found on the cheat sheet), but it puts it in your home directory. I fixed this first by changing the '~' to a '.', and then later changed it to put the patch in a separate directory (to keep things organized). Anyway it's super easy when you know how which is good because I was worried yesterday about this.
Testing is easy for the code generation part. All you need to do is change some test cases in the appropriate Harness(in the testbed directories). The harder thing is to try and do parser testing, which I'm not convinced I did it properly, in my second patch(for issue 363 (on Google Code)). There must be an easier way to get the token output(which apparently you need for the assertParse method), but I just put System.out.println 's in the UmpleInternalParser_CodeClass.ump file and made it print out all the tokens when it received them, seems as bit crude. Anyway, I got a method to be tested properly in the UmpleParserTest after some time, so that was nice.
Patch creation is confusing, only because I don't know how to check if the patch was successful or anything. All I know is that I entered the command to create a patch for issue 362 (on Google Code) and no error messages were given. So, hopefully everything's okay? I'm sure Dr. Lethbridge will let me/us know if I did something wrong :). Sorry to be a newb.
On the plus side, I realized that my fix actually didn't belong in UmpleToJava, its code works in the general UmpleToTemplate project, so I didn't have to do any fiddling with the Ruby and PHP code just yet.
I also started on issue 361 (on Google Code), which is actually just a faulty error message(I think). I'm waiting for feedback on my other patch before I do any more changes to the code, but I'm pretty sure that the test case is just faulty code, which is producing an error message, but not the right error message so that it looks like a bug in the syntax.
I've become more comfortable with ant, and have started building my own makefile to make things a little faster for myself. I don't know if I'm the only one unfamiliar with it, but basically it seems to be like a makefile where there are targets that get executed such as build or codegen, which make it easier to do little things if they are all that's required. For example there is on the cheet sheet page a command: ant -f build.umple.xml -Dmyenv=local umpleSelf compile package. However the important part of the package target is really packageJars(at least in the cases I've come across), so if you replace package with packageJars(a target of package), then you'll get a faster compile(Good times).
Instead of working more on practice problem 1(which I'm done most of I think), I've been trying to work on some issues(key word: trying). I've learnt many things in my travels.
1: don't edit java files. I started out by examining some of the generated java files, and was trying to modify them. My advice is to not do this, because then you can get mixed up between what is the java build file and what is the ump master build file.
2: don't compile any of the umple files in the cruise.example(besides maybe the master). This will generate java files in folders you don't want and give you strange javac errors when you try to build.
3(the solution to 1): in the UmpleToJava project, don't edit the java files, instead, there are .jet files in the templates folder. These are what are calling the shots. If you want to follow along what's going on, start with the .jumpjet files. edit those files and then get them to compile to the .java files. I can do this by adding a character to the .java file, then deleting that character, then saving the file. This causes the .java file to build, and will(magically) contain the changes you made in the .jet files.
With all this .jet file editing I've been talking about, I have to mention that by editing the association_Set_All.jet file in the UmpleToJava project, I was able to eliminate issue 362 (on Google Code)(by having a check, whether the sort method had been added yet or not). Super fun!
My one overarching question I have right now is whether I need to be compiling the whole umple.jar file with ant(using build.umple.xml) or if there is a faster way to get little changes into the umple.jar file. I'm thinking there must be, but I don't know it yet. I'll probably try to implement my fix in the UmpleToRuby and UmpleToPHP files next.
(this may not be how i'm suppose to be fixing the problem, but it is still fun and educational, so there can't be too much harm in it :))
So I'd previously read all the of the user manual, so I did the installing of the eclipse plugin(it has to be the modeling eclipse, I found out an hour into trying to install xtext into the normal eclipse). Had to install java 7, which was fun because I learnt about update-alternatives(when i set them horribly awry, following a manual install tutorial(big mistake)).
I couldn't get ant to work for the longest time, until I set the update-alternative --config to the openjdk(I think it was on the oracle, or the other way around). Getting rid of the "cannot locate tools.jar" made me sigh with nerdy relief.
Then I worked on the 0 practice problem(easy peezy) and did 0b too, with compiling it from the command line. I'm currently working on the the first practice problem, and it's quite a bit harder. The main challenge is using all the generated methods within the umple extra code methods. This is because there are no error messages for the java code I write(there must be a way, but I haven't found it). Anyway, I'll work some more on that tomorrow and then possibly the next one.
Not sure if I've missed anything(I've done everything in that email that said to do stuff).