-
-
Notifications
You must be signed in to change notification settings - Fork 197
UCOSPLogPaulWang
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
All the jUnit tests are passing now (note that 2 failing cpp generation tests are excluded for this), and manual examples and testbed tests (partial) are running.
I've been able to reduce the number of failing tests down to 5, though there's some really strange magic happening that's causing the unit tests to break every now and then (which is only discoverable after a full build). Another oddity is that the first run of the unit tests is failing to find the classpath, while subsequent ones work -- these have been a great source of headache thus far.
Getting closer! There seems to be some malformed Java in the example tests for cruise.umplificator which I assume isn't being run at the moment. An example of this is the following
Still a large number of tests failing, but the jar (with correct versioning) is being compiled and can be used to compile subsequent umple files.
TODO: fix these
5131 tests completed, 2891 failed, 826 skipped
Update, added file path rationalize case:
5131 tests completed, 34 failed, 826 skipped
Remaining failures seemed to be related to examples, so I'll look into that.
Also added what hopefully is a fix to get things running on travis CI, though it's only running assemble for now (which does something akin to a quick build).
Turns out the issue below has to do with explicitly setting the language generated to java.
Now it seems like the firstbuild is working:
dev@sky-laptop:/var/zenas/tmp/test/umple-bak-2$ java -jar dist/gradle/libs/umplegradle.jar -h
For more detailed information go to http://manual.umple.org
Usage: java -jar umple.jar [options] <umple_file>
Example: java -jar umple.jar airline.ump
Option Description
------ -----------
-c, --compile Indicate to the entry class to
compile, or with argument - to
compile all outputfiles
-g, --generate Specify the output language: Alloy,Cpp,
Ecore,GvClassDiagram,
GvClassTraitDiagram,
GvEntityRelationshipDiagram,
GvStateDiagram,Java,Json,NuSMV,
NuSMVOptimizer,Papyrus,Php,RTCpp,
Ruby,Scxml,SimpleCpp,SimpleMetrics,
Simulate,Sql,StructureDiagram,Test,
TextUml,USE,Uigu2,Umlet,Umple,
UmpleSelf,Violet,Xmi,Xtext,Yuml
--help Display the help message
-i, --import Indicate to read in XMI model and
generate ump files
--override If a output language <lang> is
specified using option -g, output
will only generate language <lang>
-p, --performance Indicate time taken to parse and
generate code
--path If a output language is specified
using option -g, output source code
will be placed to path
-s, --suboption Indicate to generate files with
suboptions
-v, --version Print out the current Umple version
number
TODO: I run shell commands to access the jar in favour of the plugin for the current change, but this clearly won't work on Windows systems. However, from the errors received below it's clear that the path and language generation options are currently unstable -- so it seems that there are deeper issues with allowing flexibility (of course a trivial fix is to remove inclusion of default arguments to language and path to find the root of the problems, but this "fix" would be temporary as well and I argue that we defer it until it works correctly on unix systems).
Pushed changes to branch issue_751. Restructured the path specifications, but now running into some other issues:
> Task :compile
/mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/dist/gradle/src-gen/UmpleToRTCpp/cruise/umple/cpp/gen/GenHeaderDepend.java:23: error: constructor GenDepend in class GenDepend cannot be applied to given types;
super(aName, aNL, aTEXT_0, aTEXT_1, aTEXT_2);
^
required: String
found: String,String,String,String,String
reason: actual and formal argument lists differ in length
/mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/dist/gradle/src-gen/UmpleToRTCpp/cruise/umple/cpp/gen/GenParentMethodParameter.java:24: error: constructor GenMethodParameter in class GenMethodParameter cannot be applied to given types;
super(aType, aName, aNL, aTEXT_0, aTEXT_1);
^
required: String,String
found: String,String,String,String,String
reason: actual and formal argument lists differ in length
/mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/dist/gradle/src-gen/cruise.umple/cruise/umple/modeling/handlers/cpp/StructurePointsHandler.java:178: error: constructor GenConstructorMethod in class GenConstructorMethod cannot be applied to given types;
GenConstructorMethod method = new GenConstructorMethod();
^
required: Comparator<GenComment>,Comparator<GenBody>,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String
found: no arguments
reason: actual and formal argument lists differ in length
/mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/dist/gradle/src-gen/UmpleToRTCpp/cruise/umple/cpp/gen/GenConstructorMethod.java:22: error: constructor GenBaseConstructorMethod in class GenBaseConstructorMethod cannot be applied to given types;
super(aCommentPriority, aBodyPriority, aNL, aTEXT_0, aTEXT_1, aTEXT_2, aTEXT_3, aTEXT_4, aTEXT_5, aTEXT_6, aTEXT_7, aTEXT_8, aTEXT_9, aTEXT_10, aTEXT_11, aTEXT_12, aTEXT_13, aTEXT_14, aTEXT_15, aTEXT_16, aTEXT_17, aTEXT_18, aTEXT_19);
^
required: no arguments
found: Comparator<GenComment>,Comparator<GenBody>,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String
reason: actual and formal argument lists differ in length
/mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/dist/gradle/src-gen/cruise.umple/cruise/umple/modeling/handlers/ModelingAssociationsGenerationPointsHandler.java:232: error: constructor GenConstructorMethod in class GenConstructorMethod cannot be applied to given types;
GenConstructorMethod method = new GenConstructorMethod();
^
required: Comparator<GenComment>,Comparator<GenBody>,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String
found: no arguments
reason: actual and formal argument lists differ in length
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
5 errors
Need to figure out why this is the case since we're just running the jar at this point.
Edit: turns out I just needed to update the branch. It's working now.
Edit 2: ...and it's back. Need to find a way to reliably fix it; seems like it's also happening on master.
Figured out what is causing NULL statements appearing everywhere in template files. Turns out it's because of the conflicting compile options given by the plugin / cmdline and what is specified in master.ump:
generate Java "../src-gen-UmpleTL";
We should be able to just use the default compile paths and then copy the files over.
Figured it out. Turns out an additional step was needed to get the build running, and that was to download the latest jar file to libs/umple.jar. Quite surprising that it doesn't fail the build immediately from not finding the dependency, but I suppose it's due to it being nested in the buildScript section. Build output below in its full glory (please ignore the peculiar directory structure):
dev@sky-laptop:/var/zenas/tmp/test/umple-bak-2$ gradle build
> Task :cruise.umple:compileUmple
Processing -> /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/cruise.umple/src/Master.ump
Success! Processed /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/cruise.umple/src/Master.ump.
> Task :UmpleParser:compileUmple
Processing -> /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleParser/src/Master.ump
Success! Processed /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleParser/src/Master.ump.
> Task :UmpleToJava:compileUmple
Processing -> /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToJava/UmpleTLTemplates/Master.ump
Success! Processed /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToJava/UmpleTLTemplates/Master.ump.
> Task :UmpleToPhp:compileUmple
Processing -> /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToPhp/UmpleTLTemplates/Master.ump
Success! Processed /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToPhp/UmpleTLTemplates/Master.ump.
> Task :UmpleToRTCpp:compileUmple
Processing -> /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToRTCpp/UmpleTLTemplates/Master.ump
Warning 170 on line 121 of file 'Attributes.ump':
Custom constructors should normally not be provided in Umple. Consider using before or after keywords to adjust what the constructor does, or adjusting constructor parameters using keywords like lazy.
Success! Processed /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToRTCpp/UmpleTLTemplates/Master.ump.
> Task :UmpleToRuby:compileUmple
Processing -> /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToRuby/UmpleTLTemplates/Master.ump
Success! Processed /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToRuby/UmpleTLTemplates/Master.ump.
> Task :UmpleToSql:compileUmple
Processing -> /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToSql/UmpleTLTemplates/Master.ump
Success! Processed /mnt/c/Users/Paul/Desktop/zenas/tmp/test/umple-bak-2/UmpleToSql/UmpleTLTemplates/Master.ump.
Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/4.10.2/userguide/command_line_interface.html#sec:command_line_warnings
BUILD SUCCESSFUL in 1m 3s
9 actionable tasks: 8 executed, 1 up-to-date
Next step: figure out why certain compiled Java has null TEXT strings. This is blocking Java compilation.
I've reached out to a previous UCOSP student (Adam) regarding tips for getting started on #751, as I've been running into some issues with running the plugin.
Tabbing hopefully good to go now, added file locks to make sure that operations are roughly atomic.
I've also begun work on #751. I've pulled the plugin repo and running gradle build seems to work. Though the subsequent gradle build in the main project seems to have the following error message:
> Could not create plugin of type 'UmpleGradlePlugin'.
Could possibly be a version issue, but I'll have to investigate this further.
UPDATE:
- Seems like the master branch of the umple.gradle project was behind. Swapping to
ss-config-n2fixed the issue. - Looks like there are a lot of changes that are in the "ambiguous PR zone". I'll take the advice in #751 to work with it as a black box first before trying to delve into it.
UPDATE 2:
- I read through many of the issues and pull request comments--now, if only I knew how to run the plugin. It's been described on numerous occasions to already have a "quick build" working, but running the one in the README
gradle cleanUp generateAndCompileParser generateCoupledSource compileCoupledSourceJava packageSource packageUmpleCompilerJar -rerun-tasksseems to reference unknown tasks and fails to determine classpath for the main console. - TODO: will read the official walkthrough
Set up a PR for #225 with some various points of discussion. My biggest concerns for the change at the moment are how to deal with consistency issues arising from latency. I've also added a PHP dependency for zip utilities.
Set up a PR with manual example and made some minor tweaks again for #1351. Started a bit of work on #225 - so far I only have basic tabbing - adding, removing, etc. without state logic.
Following today's meeting, the following are work items for me:
- Add an entry for state-dependent methods. I should add it under the method section, with about two interesting examples. There also is some macro to list the rule names below on the same page, so I'll look into that.
- Begin work on #225. Should still use model.ump but have separate files to serve the different tabs. I may also need to do something about the editor selections; ie. it would be good if states were made per-tab as well.
- Investigate #751. Baby step would be to have a basic build working.
PR merged! Looks like the warning page is working fine too.
For my next task, I'm currently considering any of the following:
- https://github.com/umple/umple/issues/751 (I do see that progress has been made here, though I'll need to figure out what the main blockers were and why it took so long)
- https://github.com/umple/umple/issues/1098
- https://github.com/umple/umple/issues/343
- https://github.com/umple/umple/issues/1207
- https://github.com/umple/umple/issues/225
A number of items to discuss for my upcoming PR which will complete 1351:
- Multiple top level state machines. Perhaps the simplest way to deal with this is to simply nest the switch statements of more than one top level. To add a test for this. There doesn't seem like there is a good way to condition on more than one statemachine state syntactically, but it could be something explored in the future. For now, the states across statemachines are assumed to be disjoint.
- Complicated (in terms of nesting) state machines seems to be working fine, to add a test for this.
- Code injections should still be available. It seems like the code related to injections are simply string replacements, so I'll be replicating that behaviour. However, I'm a bit concerned with the code duplication at this point so I am considering moving method helpers into a separate file. Will add a test for this.
- Different modifiers should produce a warning, will add a new warning message and a test for this.
Set up my PR for #1351. Seems like the only build that is failing is the (Mac) travis PR - test case being MultipleQueuedStateMachinesTest_nestedStates_EventlessStateMachine. This is most likely because I haven't pulled yet since my previous merge, so I'll need to do that to further investigate (though it is strange that it is passing for Linux).
After tests pass, I'll do a bit more minor spacing cleanup and test various fringe-cases listed in my request.
In terms of the core functionality introduced, it seems that the change is largely working as intended.
After some more thought, it seems that my current approach fails to address the following scenarios:
1. If a method is already defined, and then state-dependent definitions are provided then the methods should be merged.
- Perhaps this should be treated as the default case, and otherwise we return the default value for data type.
- Instead of keeping the two method categories disjoint, my current plan is to check on regular method creation whether or not the method signature exists within some data structure for state-dependent methods and if so, treat it as a special case (don't add it to the UmpleClass). This seems to be the cleanest approach and it will allow me to keep the output aspect of the behaviour separate from the more complicated method ouput area as well.
- To traverse efficiently and to not make a mess of things, I need to build a tree where intermediate nodes are StateMachines (edges being States along path to leaf) and the leaves are States + MethodBody's.
- This effectively allows us to traverse and output Switch statements on the intermediate nodes, Case statements on the State edges, and the method bodies on leaves. Spacing can be handled with a depth variable.
- A slight annoyance so far is Java's lack of local method definitions, and poor lambda support to define a recursive method. Alternatively, I could also introduce a (Node, depth) struct though that also needs a class definition.
- The question now is where should this tree be stored? The UmpleClass seems like a fairly good candidate for now, as it is responsible for managing methods as well.
Started some work on #1351. My idea of creating "stateful method" (that is, a method that depends on state) so far is to categorize the methods and then store the State-Method pairings within a StateMachine. To categorize a method is simply to compute a hash using properties that require uniqueness--ie. the name, parameter list, as well as return type. For now I've been successful in outputting switch cases for non-nested state machines. Nested may be a bit trickier, given that the hierarchical information would need to be captured within the map that stores the methods themselves but should be pretty doable.
I took a look at Umple templating as it is used pretty heavily in code generation (for state machines at least), but it seemed like for the current task a bit more logic is necessary (which is a bummer, since the syntax seemed pretty nice and straightforward to use).
Current changes are visible here.
TODO:
- Make sure that the migration to Umple code from Java works as before
- Make sure that nested generation works as intended
- Make sure that the test files are accurate and are passing
#1362 merged, so did a bit of investigation into #1351. The general plan of approach for now is as follows:
- Update the state machine grammar file to accept method syntax
- Update the mixset files defining state machine behaviour to handle the method syntax
- Update the UmpleTLTemplates to produce language-specific code generation
- Write implementation tests and verify that new mechanism works as intended across languages
I was originally hoping to be able to test this directly in UmpleOnline, but it looks like a build is required for each change. Will most likely stick with eclipse debugging for this.
Set up a new PR for #1362. It seems that #messageArea is not a valid place to dump diagrams; rather, it should only be used for error messages. Upon closer inspection, generated code that doesn't have a particular delimiter is treated as error code due to the control flow setup. I presume that this isn't by design and have addressed this, though an alternate solution would be to modify the ER diagram generator to output the delimiter.
#460 merged! Next up, #1362 and #1351.
As I was running umpleonline from within a VM, I noticed an exception when generating code:
/ump/tmp158961/index.php - require_once(): Failed opening required 'app/kissmvc_uigu2.php' (include_path='.:/usr/local/lib/php') in /mnt/zenas/tmp/test/umple-bak/umpleonline/ump/tmp158961/index.php on line 8
A bit higher up was this message:
ln: failed to create symbolic link './app': Read-only file system
Interestingly, there is a security mechanism for VBox VMs to disable symlinks by default. There's a setting for it here. I ended up just swapping back to WSL (where it is enabled by default) since was already set up anyways.
After tracing through executions within the UmpleGenerator module, I realized that the type token was indeed being passed around with the attribute container context; except that it is now no longer a direct child of an attribute (rather, it is an "otherrule" that is processed independently). Changing the rules in this case simply modified the execution time and location in code for the type token.
My workaround for now is to special-case the type token so that when it is processed, it again attaches the type property to the associated container entity.
Tests are passing and it seems like this is a sufficient fix for now.
This marks the end of the code sprint at Toronto this year. I had a great time meeting with the team and touring the city. A bit disappointed that I couldn't resolve all the cases for #460 during the code sprint, but overall I've found this task to be extremely helpful as a ramp-up task to familiarize myself with the compiling/parsing/generation modules.
A number of Umple matters that I personally found helpful this weekend:
- When developing the compiler itself, it may be a good idea to keep a separate repo cache with files generated by a stable Umple compiler: this means that you will always have generated files that can be used for unit testing
- Full builds should be deferred as much as possible (my machine isn't very high-end, unfortunately). Grammar files can be modified directly in cruise.umple/bin before running unit tests, and similarly, the compiled Java files can be modified directly and debugged in Eclipse before transferring the changes over to the corresponding .ump files
- So that the translation to .ump from Java is clean, use a difftool (e.g. Linux diff) to compare the modified file with a corresponding unmodified file backup
- It's easier said than done, but do try to understand what can be done before making assumptions about this. I learned this the hard way. As I had made some assumptions of the EBNF interpretation, I ended up implementing recursive regex patterns in Java and this wasn't necessary at all (rules themselves could be made recursive). But it was neat to see it working at least.
Progress report:
#460
- After much exploration of various solutions, it was decided to split type into multiple subtokens through a recursive definition and aggregate these to reproduce the original type
- Resolved a number of edge cases, such as with variadic types and handling of lists
- One last case: Umple generator no longer treats the type token as a child of attribute since it is declared as a top-level rule. I suspect that new syntax may be necessary to allow it to be a named token while being omitted from being treated as a standalone rule.
#1362
- CRUD is generated in the "innerGeneratedCodeRow" div and the ER diagram is generated in "messageArea". Looking at the file umpleonline/scripts/umple_page.js it seems that the showing and hiding of these are handled independently, while there may need to be some sort of check to hide one when the other is shown.
- To investigate more on this
Set up my first PR for #460! My first task was to implement nested generic types (these were previously marked as extra code and not handled in Umple).
It seems that there are still a few test cases failing, and I'll likely have to resolve these over the weekend.
Turns out running Eclipse on Windows on the mounted Umple directory provisioned in WSL Ubuntu wasn't the best idea, since it left the repo in an unbuildable state. After swapping to Ubuntu Eclipse, the project started building again. My suspicion is that the ivycache location is modified by Eclipse, or possibly something related to the Java versions being different.
To run GUI apps in WSL, make sure you have XMing Server installed. If you're working in a box, you'll need to run SSH with the -X option and make a few config changes on both the client and server side.
There's a guide for this here.
Whew. Finished all the setup steps for Umple, including the plugin and web app. Eclipse tests all pass now too; I was able to fix thousands of failing tests with another ant -Dmyenv=local as suggested in the setup page.
Below are some special steps I took to install specific versions of PHP and Ruby in WSL:
# Add RVM to PATH
echo 'export PATH=$PATH:/usr/share/rvm/bin/rvm' >> ~/.bashrc
# If you aren't always running in login shell (my version of WSL doesn't), a workaround is to source the script file
echo 'source /usr/share/rvm/scripts/rvm' >> ~/.bashrc
# Set bash profile
source ~/.bashrc
# Install ruby-2.2.3 and set it to the default version
rvm install ruby-2.2.3
rvm --default use 2.2.3
# This should tell you that you have version 2.2.3
ruby -v
# Install dependencies for compilation
sudo apt-get install build-essential libxml2-dev
# Download and extract php release tarball
wget -O /tmp/php-5.6.17.tar.gz http://ca1.php.net/get/php-5.6.17.tar.gz/from/this/mirror
tar -xvzf /tmp/php-5.6.17.tar.gz -C /tmp/
# Compile and install from the source
pushd /tmp/php-5.6.17
./configure --enable-sockets # this option is needed for socket methods
make
sudo make install
popd
# Cleanup
rm /tmp/php-5.6.17.tar.gz
# This should tell you that you have version 5.6.17
php -v
- Took a brief look at the design philosophy and user manual. Will still need to run through some Umple examples.
- Wiki Home
- FAQ Frequently asked questions
- Examples
- Presentations
- PhilosophyAndVision
- Best practices for using Umple
- Publications and theses
- Tutorials
- Installing Eclipse plugin