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

Log Entries

2019-11-29

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.

2018-11-28

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.

2018-11-25

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).

2018-11-23

Turns out the issue below has to do with explicitly setting the language generated to java.

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).

2018-11-20

Pushed changes to branch issue_751. Restructured the path specifications, but now running into some other issues:

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.

2018-11-16

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.

2018-11-11

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):

2018-11-09

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.

2018-11-06

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-n2 fixed 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-tasks seems to reference unknown tasks and fails to determine classpath for the main console.

2018-10-25

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.

2018-10-22

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.

2018-10-16

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.

2018-10-14

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.

2018-10-09

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.

2018-10-05

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.

2. Nested states for method definitions are proving to be very tricky.

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.

2018-10-03

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).

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.

2018-09-26

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.

2018-09-25

#460 merged! Next up, #1362 and #1351.

As I was running umpleonline from within a VM, I noticed an exception when generating code:

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.

2018-09-24

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.

2018-09-23 (Code Sprint)

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

2018-09-18

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.

2018-09-13

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.

2018-09-08

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:

Installing ruby-2.2.3

# 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