-
-
Notifications
You must be signed in to change notification settings - Fork 197
UCOSPLogJoshuaMcManus
Josh McManus edited this page Dec 5, 2017
·
89 revisions
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
1173 Command Line debugging fails to trace back to single line if statemtent
- Addresses a small issue I found while testing where the umple run-time traceback is off by one in a corner case, not especially critical to address as it might be challenging to fix.
1174 Command Line debugging fails to trace back external classes
- Addresses another small issues that I found while testing. Likely unfixable, but I created an issue just in case.
1175 Command line debugging tests fail when compiling multiple umple files for one test
- Addresses the fact that some of the tests for compile-time debugging do not compile correctly
1176 Command line debugging tests fail to run on Appveyor and cruise-control
- While deploying yesterday we ran into an issue where the tests I created were failing on a couple of machines, Tim disabled them, but I created this issue so they are not forgotten about.
882 Command line debugging does not work
- Committed the code and fixed a couple of bugs that came up while deploying. There are a few things that are causing errors, but I will create issues in GitHub for those tomorrow.
Type A
-
Abstract methods that are defined in an Umple file create a line comment in the form: // line 6 ../test.ump. This is missing the quotations around the filename like all other comments. This will need to be fixed as the stacktrace skips this line and outputs the wrong offset. (explained in more detail in the GitHub issue) -
Statemachines with an error defined in the "do" statement outputs the wrong umple line because the Java source that is generated never writes a // line ## directive. (explained in more detail in the Github issue) -
Injecting a before statement into custom code, with the custom code containing an error (not the before statement), the wrong output line is produced since there is no way to determine where the before statement ends and the custom code begins. -
I am receiving the same error as I was before where two classes in a single umple file that interact with one another cannot find each other when generated and compiled into Java (Object not found exception). I will investigate this further as it's probably just a config issue, rather than an issue with the debugging code.
Type B
-
- Abstract classes inherited from an external file using the "external" command do not traceback to an umple file.
882 Command line debugging does not work
- Fixed runtime errors in all after statements
- Fixed runtime errors in functions that also have injected code
- There is a corner case which causes the line to be off by one, but it would require a fair bit of refactoring and I need to push this code eventually. I created a test for the error and ignored it, I will create an issue for it so someone else can find and fix it in the future.
882 Command line debugging does not work
- Fixed a few of the scenarios for runtime debugging of code injected into a custom function. Currently working is:
- Error in after statement injected into a function with no return statement
- Error in Before injection
- Error in custom code with an after inject statement and the function is void
- Essentially what is not working right now is errors in after statements that are injected into possibly multiple places (i.e. the function has return statements), and error in the custom function where there is injected code before the error. I have begun working on a solution for the former.
882 Command line debugging does not work
- Fixed the issue with do statements not returning the correct line
882 Command line debugging does not work
- Partially fixed the issue with the inject statements. As I had suspected my changes for the Type A errors broke the line numbers for debugging Type B errors. However, it does not appear that there is a mechanism in place for handling injected code in custom functions. I will continue to debug this.
- Fixed issue 3. There was no new line after an abstract statement and that was throwing off the construction of the run-time debugger line numbers. I have committed the change to the branch.
882 Command line debugging does not work
- Wrote the remaining test required to test Type B errors, there are more bugs that require fixing that I did not find in my initial fixing of the system.
882 Command line debugging does not work
- Spoke with Vahdat about the final issue that I am having with testing Type A errors, he suggested I not worry about it right now and focus on finishing the remaining parts.
- He was also having issues compiling my code on his machine, after quickly investigating I noticed the error has to do with a filepath being invalid on his Windows machine. I must have defined it somewhere and not made it compatible, will return to this when everything else is working on my machine.
- Spent a significant amount of time investigating how to test Type B errors. I was able to successfully add a command to the ant build so all the umple files are automatically compiled with the other testbed files (except for those used in compile-time tests).
- I also investigated a way to test the compiled umple code using junit, but was unable to do so without generating subprocesses for each test. This is because the unhandled exceptions are passed to Junit instead of being handled by the main function.
- I noticed that the traceback does not work for inject statements. This will require a fix and I am not sure how difficult it will be just yet.
882 Command line debugging does not work
- Had some problems merging in the changes to my local git repo, that took a while to resolve but everything looks fine now.
- Modified the traceback to respond to the new comment at the end of injected code. Added one more test to validate code with multiple injections into a custom code block.
I began investigating the 4th issue with the tests mentioned below. The problem is that when umple builds a file and compiles it (with the "-c -" command) from a directory that is not the same one as the umple file, the generated classes claim that they cannot find the other classes in the same directory. For some reason there is no problem when you generate and compile the umple file from the same directory it is in. It's not a configuration issue since I had Runqing run the tests on his computer and he got the same result.
- The code is compiled in the CodeCompiler.java file
- Executing the same umple file from multiple directories produces the same absolute path to pass to the "javac" command (which is what we want)
- The difference must lie in the fetching of the runtime environments, which I haven't been able to figure out how to inspect.
- I may be able to find more information from the build process for umple as a whole, since that obviously fetches files from multiple locations and builds just fine. There is a lot of files involved though so it'll take a while.
I came across a bug in in the after injection code while testing my work (#1144). An inject after statement will inject the code after any line that contains "return", not just the actual return line. I have verified that this issue exists on the master branch and not something that I created while working on my issues.
1143 Add comment to end of inject statements
- Completed this issue and created a PR for the change. This was necessary to do in order to perform a traceback of code injected into a custom function.
1134 No Umple // line traceback for State Machine do statements
- Fixed an issue with the tests where the filepath generated in the // line comment varied between Eclipse and command line builds. This was because there was a specified namespace. I fixed this by modifying an existing test which did not have a namespace specified.
882 Command line debugging does not work
- Added 3 more tests to cover more scenarios. Each test seems to add ~1 second to the build-time, so I think this is enough tests. I might try to remove some and give the existing ones more than one error. This will be handled once everything works, though.
- Fixed issue 1. Not going to bother to create a separate PR for this since it was just 3 lines of code that needed to be modified and it's not really a bug that affects any other part of the system.
- Fixed issue 2. Created a PR: https://github.com/umple/umple/pull/1135 since I was modifying some tests and was adding something to the outputted code.
882 Command line debugging does not work
- Continued creating tests. Made a bunch of corner case tests, found a number of issues that are going to need to be addressed. (Pined to most recent post about this issue)
882 Command line debugging does not work
- Began creating tests for Type A issues. Each test creates a subprocess which then makes a call to the command line to build umple files outside of the main src folder (so they won't be precompiled prior to testing). The tests then intercept the output and checks against a txt file to verify they are correct. These tests use JUnit so they will all be called when the testbed tests are called.
- I am still having the same issue as I was the past couple weeks where I am getting an error saying the file cannot be read. I asked Runqing to test my code and he's receiving the same issue, so I don't think it's an environment issue. The result of this is that I will likely need to modify the way Java files are opened.
882 Command line debugging does not work
- We discussed the issue of testing during our meeting today and concluded that I will in fact need to create a new testing methodology to test the console output. This will certainly take a fair amount of time as I don't have any experience doing this from the ground up.
- I've also noticed that you can inject code into custom functions. This will break the current method since there is no way to determine where the original code starts, and where the injected code ends. I will likely need to enhance the "// line ## " comment made above after statements. I will handle issue 1128 first.
1128 Before / After code injection line numbers differ from user defined methods
- I created this issue today after verifying with Tim and Vahdat that the line number output for code injections is incorrect. This is required to be completed before I can fully complete issue 882.
- I've made the changes and didn't receive any errors when testing. I was expecting to fail at least one or two tests which verify the output is correct.
- After creating some tests to test the output, I realized that there is in fact another bug in the code; if two before/after statements reference the same method, then only one has a line number comment generated. I updated the GitHub issue.
- I created a PR for all the changes that I made today fixing this issue.
882 Command line debugging does not work
- Spent a fair amount of time working on tests for the runtime errors, and I believe that these tests are not possible in Junit either. The reason for this is that Junit handles all thrown exceptions in a function, which means that our custom UncaughtExceptionHandler is ignored, thus the output cannot be tested.
- I'll continue looking into this as well, but I believe a full set of integration tests are required instead. That's the only way we'll be able to test the full procedure of parsing -> compiling handling -> runtime error handling
- Also, while going through some of the tests that I wrote I found an issue with the code that generates the "line ## "FILENAME"" for before/after statements. Normal user defined functions have line numbers defining the first line in an umple file that the function starts, but in before/after statements the line number is the line where the function is defined. I verified that it's not something that I caused.
Here is a demo for issue 882: https://drive.google.com/file/d/0B4hxpyosZh3neDV4NjRsQlJ2MTg/view?usp=sharing
882 Command line debugging does not work
- Configured the testbed tests to use another set of tests for the runtime exceptions. Wrote a few tests that I will verify work tomorrow.
- Investigated how to write tests for the compile time tests. I'm fairly certain that I won't be able to use testbed tests here since the build file for testbed precompiles all of the java before trying to run all of the tets. In large applications these types of errors are normally caught by integration tests, which test the whole process. I think this is what the testbed tests are trying to do, but I can't immediately find a solution.
- I'm going to focus on the runtime errors for now and will ask about the compile-time errors during our meeting since it's not blocking me.
882 Command line debugging does not work
- There were still some issues that I found with the type B error printing that I came across while creating tests. I spent a while fixing those and confirming that everything works.
- I wrote out a bunch of things that I want to test, not actually implementing them yet. I don't know exactly where to put them so I've left a question on the GitHub page.
- The changes that I have made are rebased and pushed to remote so others can look at it if they want. It is still under the branch CL-StackTraceUmple
882 Command line debugging does not work
- UmpleLengths is supposed to be the length of the function (how many LOC), but it was always returning 3. I have fixed this and the traceback appears to be working correctly now.
- I can start writing tests now that I know what needs to be tested and how both types of debugging work.
882 Command line debugging does not work
- Verified that the compilation traceback works for state machines. Will need to conduct more in depth tests later, though.
- Began investigating the issue with the run-time traceback:
- I found the point that was causing the values to be off by one, changed the values
- Not sure what the umpleLengths are supposed to be representing in the UmpleSourceData class, but I know that that is the other issue with outputting the proper Umple lines. I will investigate more this weekend.
1101 Umple json generation fails
- Pulled in the changes made by Vahdat. Verified that his changes allowed my code to work.
- Tested the changes and added two new tests. While creating the tests I noticed that the classes are all created in a vertical line by default in UmpleOnline, making it difficult to see the associations? Is this normal? The sample code in UmpleOnline doesn't do this, but I'm guessing there is something hidden in the backend to control this.
- Created a PR
882 Command line debugging does not work
- Continued investigating the issues with my stack tracing. I spent quite a while trying to figure out how to compile java code that references multiple classes, but I am still getting a symbol not found error. I tried copying one of the online examples and had the same issue with any association. I will bring this up in the meeting on Tuesday.
- I noticed that there are "before" and "after" statements that inject code into Umple generated code. I updated my code to work in these situations, but I noticed in the wiki that there are plans to allow "before" and "after" statements to work on user-defined methods as well. I'm not sure how to handle this is the future.
1101 Umple json generation fails
- I looked over the changes Vahdat reverted to and everything looks good. I will rebase my code as soon as he merges the changes. I should be able to generate the coordinates and json for the associations now that they are part of the model.
- How do I compile multiple classes with associations? I keep getting symbol not found errors.
- Should I try to handle the "before" and "after" statements in user-defined methods for future-compatibility? With the current way it is implemented there is no way to tell where the "before" statement ends and where the original method begins.
882 Command line debugging does not work
- Updated the regex expression to match the "// line ## "FILEPATH"" expressions placed before each custom function made in the java files.
- Made a bunch of other functionality changes to get it to pick up the right umple lines for simple cases.
- I'm having troubles creating an umple file with multiple classes in it, I keep getting unrecognized symbols when trying to reference them in my functions. I assume I'm doing something dumb and it's an easy fix, but I do notice that the auto-generated methods for the umple class that isn't properly linked has incorrect line numbers since the functions aren't defined in the umple file itself. I will have to investigate how to solve this more deeply later.
- To fix this I'm thinking I might want to keep track of the number of opened/closed brackets to see if I've left the function referenced by the line number.
1101 Umple json generation fails
- I went through the code some more, but some changes were made and when I rebased my branch the way the traits are handled is different. I have emailed Vahdat about this and hopefully he can help me understand what was changed.
- I found a way to get it to work with the way I believed the code used to behave, but now it seems that when the traits' associations are applied to the classes, they are not added to the model level and only to a list of associationVariables, not even the list of associations, within the classes.
882 Command line debugging does not work
- I've begun stepping through the program and it appears that the current implementation is iterating through the java file looking for a line matching a certain format. I think this might be outdated and so changing this is what I am going to start with.
882 Command line debugging does not work
- Began my investigation into this issue, checked out the branch needed.
- I am a bit confused as to the scope of this task and will bring it up at tomorrow's meeting. Primarily, I don't get what this ExceptionDumper function is supposed to do. I have never worked on a debugger before so I am going to need to learn how this relates to debugging.
1101 Umple json generation fails
- Began my investigation into why this is failing. I am not familiar with this part of the code so there is a lot for me to try to understand.
- In the generate() method of JsonGenerator there are calls to a function extractClassName() within the part which builds the json for the associations. This is where the error occurs. The function does not handle the case where one side of the association is a Trait and a null pointer exception is thrown.
- I'm guessing that associations involving traits should not exist anymore at this point in the application as they should have been applied to the classes that call upon them already.
- It appears associations from traits are applied to classes in the applyTraits() function, which is called after postTokenAnalysis(). In applyTraits(), my intuition is that the traits' associations should be removed from the model's list of associations after they've been applied to all relevant classes because it no longer makes sense to have an association between the temporary Trait and another class.
- The position of an object is determined in the postTokenAnalysis() function, which is called before applyTraits(), this looks like it'll be an issue since the position is needed to form the json and build the output for the user to see.
1084 infinite loop with key in a subclass with infinite cycle
- Changed my approach to factoring out the analyzeKey code to be executed after the inheritance is handled per Vahdat's request. All tests pass.
- Created a pull request.
1084 infinite loop with key in a subclass with infinite cycle
- I ran 3 builds each using the old code and my new code (2 first/quick, 1 first/quick) and noticed no significant changes in run-times. They all averaged out to be roughly the same time. My tests were not very scientific, but they at least didn't show any immediate increase in compile time.
- I had two tests that were failing (1 of them was repeated 4 times for some reason, which is why I said 5 below):
- The first was expecting the dependency cycle to be detected at the first class, but mine detects it in the second class. I changed this to pass since it has no impact to the user either way (both show that there was a cycle detected).
- The second is involving a duplicated class / trait name where the first declaration also has a self-referencing cycle. I ran the same input on the current running version of UmpleOnline and noticed that only the duplicated name is thrown as an error, and the dependency cycle is left out. My implementation would do the inverse. I'm not sure if this is okay, but I don't feel as if the user is really losing out on any functionality.
1084 infinite loop with key in a subclass with infinite cycle
- I implemented a function that checks to see if a cycle exists each time an inheritance token is parsed. It fixes the issue described in the GitHub issue as well as a couple others I have tested
- 5 tests are failing from this, but they appear to be due to the test expecting the parser to throw the error later than it does now. I will investigate further and begin to create tests.
1084 infinite loop with key in a subclass with infinite cycle
- I have gone through the code, and stepped through a debugger for a known failure case. I have a good understanding of the interactions and the variables being passed around now.
- The unlinkedExtends attribute for the compiler holds the references to each class and the class that it extends. This is what is iterated through by the analyzeKey() method. The function analyzeDependentTokens() (which calls analyzeKey) is only executed after all tokens have been processed.
I believe there are a few of solution to this issue:
- Add a self-reference check when addExtendsTo() is called to preemptively stop cyclical references.
- Not sure if it would be possible to detect a cycle across multiple classes, though it should be
- Check for a cycle when analyzing a key
- I have already added a limit to the number of levels to search for a key
- Though this would fix the issues with the key, I'm not sure if it would fix other possibly existing issues or prevent further issues in the future
- Refactor the code so that keys are stored in the same way as unlinkedExtends, then only add them to the class after extended relationships have been added and cycles have been checked for.
- Not sure if I would want to move all of the analyzeDependentTokens() code there, or just keys
- This would probably be the most work and I'm not sure if it's more effective than the first option, but it would also allow me to rewrite the analyzeKeys() code to be more clear.
- There was an issue with the merge into mainline where one of the tests is failing, but everything works on my local machine after I do a first build + full build. The test that fails relies on the AssociationEnd java class, so my guess is that this is not being regenerated properly to reflect my changes to the equals() function.
- I verified that all of my commits are present and the tests that I added also pass
- UPDATE Timothy has confirmed that the code does work and that the master branch just needed to be recompiled. These issues are complete
- The tests all pass on my machine, but for some reason they are failing on the Travis server. Vahdat ran the tests on his machine and they also pass. I am not sure what is going on and will have to follow up at a later point, I will move onto the next task so I can get that to work.
- The issue appears to be that superclass loops are not detected upon the declaration of an isA relationship, they are only detected after all classes have been analyzed.
- The key searching process runs during the class analysis, so loops are not caught. I can possibly do a cycle check upon each isA relationship declaration, or just check before each key is searched (this might not be the only time an infinite loop is created)
- Committed code to fix both issue 1026 and 1089 as well as added 4 or 5 tests to verify that the outputted Java code is correct (since no testbed tests had existed previously for this code).
- I had to make a specification change to the system due to an existing contradiction in code. When taking the equality between two objects (e.x. obj1.equals(obj2)) we stated that two objects are not the same if a key that was of type String was null for obj1 and "" for obj2. However, since we changed the way the equals function works (that it now calls get methods instead of accessing variables directly), the equals function now returns true. This is because the get methods generated for String attributes will return an empty string if the attribute is null.
- This decision was made because I figured there would be less impact in changing the way the equals function works than changing the functionality of a get method for all attributes.
- I have been assigned issue #1084, I will begin working on that today and continue for the remainder of the Sprint.
UCOSP Meetings started today in Toronto
- While working on writing more tests for this issue, I came across another bug, 1089. I assigned it to myself since it is a blocking issue to get out this issue.
- To the suggestion of the mentors I have made it so only getter methods are called.
- I have created a pull request for my changes after committing the code to my own branch
- Got the debugger working on my Ubuntu machine running Eclipse, for those that want to set it up here is how I did it:
-
In Eclipse, go to Run > Debug Configurations...
-
Double click on Remote Java Application
-
Rename it to Remote (or whatever you want), ensure the project is cruise.umple, connection type is Standard (Socket Attach), Host: localhost, Port: 1044, check allow termination of remote VM
-
When compiling your umple file, use the following command in your terminal:
-
java -agentlib:jdwp=transport=dt_socket,address=localhost:1044,server=y,suspend=y -jar umple.jar [path to umple file] -g Java
- Fixed the issue by outputting a get() method instead of directly accessing the variable, but as stated before I believe the issue has to do with a variable not being set upon the creation of the key object from the token. I am going to look into it further before creating a pull request.
- Found that isDerived should likely be set here, but I'm not sure why it's not being set for key attributes (or if that is really the case). I think I need to run a debugger to really see what's going on as manual tracing has me stuck at this point. I will send an email to see how to go about this.
- Tested using the command line to generate code from an umple source file
- Created a test project in Eclipse and generated code using the same umple source file
New Task 1026 assigned to me
- Identified what the issue is and reproduced it locally (saw errors in my Eclipse environment)
- Not sure what tests I need to write for this. I'm guessing that I'll need a Testbed Test to make sure that the code can now compile and I'll likely have to modify template tests that had expected the output to be incorrect.
- I believe that isDerived is not being set for an inherited key value and that's why the getter is not being called within the subclass. Will keep trying to trace this down (there's a lot of code to sift through, most of my time is being spent on understanding how everything communicates and interacts)
- Need to figure out a way to add the umple compiler to my command line path so I don't have to navigate to the umple folder every time I want to build something.
- Noticed a typo on the architecture page under code generation, not sure if I should just fix it or ask first? Will bring it up at next meeting and see what the protocol for fixing simple typos is.
- Decided against running a VM as it was quite slow, instead I am now dual-booting my computer with Ubuntu.
- Re-set-up my environment in Ubuntu
- Updated the wiki page to remove outdated instructions such as installing a particular version of PHP. I have left a note stating what versions are known to work in case this fails for someone in the future.
- Played around with the UmpleOnline tool some more and tried using more of the features.
- Ran UmpleOnline locally
- Browsed through the open issues in GitHub for something that I can tackle. Nothing really jumped out at me, but there seems to be a reasonable amount to choose from. Hopefully I can find something to work on and create a pull before the sprint next week.
- While using the UmpleOnline tool on my Windows machine + Chrome I noticed that trying to add a class to the UML diagram was quite difficult. I may be using it wrong but a lot of times my clicks were not registering and I had to move the new class around the diagram a fair amount before I could place it.
- I am also curious why the C++ generated code is so much more convoluted than the Java (though I'm guessing that's due to me not using C++ in a while and forgetting just how messy it likes to be)
- I'm not sure if I need to find an issue to work on myself or if one will be assigned to me, I'll reach out tomorrow if I don't get something to work on. I am still familiarizing myself with the project so it's hard for me to gauge what is a good starting point or not.
- Visited http://cruise.eecs.uottawa.ca/umple/ and explored the site, reading into the different features of the software.
- Accessed resources referred to by the wiki's home page: https://github.com/umple/umple/wiki
- Played with the UmpleOnline tool to test my understanding of how the application works
- I am running Windows on my desktop and laptop, but installed Ubuntu 16.04 LTS as a VM
- Referred to https://github.com/umple/umple/wiki/DevelopmentSetUp for completing the environment set-up
- Many of the tools that are suggested to install are outdated and were not available for installation on my machine, I mostly ignored them and installed the versions that were available to my system (this includes a version of rvm newer than 2.2)
- Ran the build commands but had failures in the 'full build'. This was due to the VM not having permissions writing sym links to a shared folder (I am sharing the development folder with my windows environment), this was fixed by referring to this page: https://serverfault.com/questions/345341/cant-create-symlinks-in-virtualbox-shared-folders and then running VirtualBox as an Admin on Windows
- All builds succeeded once those problems were resolved
- Downloaded and installed the latest version of Eclipse with Modelling Tools then added the Umple plug-in
- Created the project and cleaned/built it
- Ran all tests, but ran into many errors. I backtracked my work and executed all of the build commands again then reran the tests with full success.
I had spent a fair amount of time over a few days trying to get this all set up, though most of the issues stemmed from running a VM (setting up shared folders, permissions, etc.). I will see how the project progresses, though I may suggest future students in a similar position to just dual-boot instead as computing power will be limited within the VM. As mentioned above, I did not bother installing outdated versions defined in the instructions, and since everything built successfully and passed tests I am assuming that it should not be a problem, but I will update this section if it becomes an issue when development begins.
- Wiki Home
- FAQ Frequently asked questions
- Examples
- Presentations
- PhilosophyAndVision
- Best practices for using Umple
- Publications and theses
- Tutorials
- Installing Eclipse plugin