I1027 Add Contest Clock To WTI #1034

clevengr · 2025-01-12T00:00:30Z

Description of what the PR does

Adds "Elapsed Time" and "Remaining Time" counters to the WTI header bar whenever a team is logged in.

The counters are initialized with values read from the PC2 Server (via the WTI-API Server and its PC2 API connection) each time a team logs in. The counters respond appropriately to changes in the "PC2 contest clock" state -- that is, when the Admin "Starts" the contest the counters begin counting (up/down respectively), and the counters stop (freeze) whenever the Admin "Stops" (pauses) the contest. The counters also respond correctly to changes in the contest times; for example, if the Admin extends the contest (adds more time), then the "Remaining Time" counter automatically adjusts as appropriate.

Times are displayed in HH:MM:SS format, preceded by a number of days if the total time is greater than 24 hours.

The counters are driven by a JavaScript setInterval() object which ticks at a rate of once per second. To handle potential clock drift, the code automatically "resynchronizes" the on-screen counters with the current PC2 Server time, at a frequency defined by a constant in the WTI-UI constants.ts file (currently every 15 minutes).

A screenshot showing the clocks for a contest that was scheduled to run for 30 hours and has been running for just over an hour is shown here:

Issue which the PR addresses:

Fixes #1027, #1029

Environment in which the PR was developed (OS,IDE, Java version, etc.)

Windows 10 & 11
Eclipse Versions 2021-12 (4.22.0) and 2020-12 (4.18.0)
Java versions 1.8.0_381 and 11.0.16.1
Chrome Version 131.0.6778.109
MS Edge Version 131.0.2903.112

Precise steps for testing the PR :

Download and unzip the PR distribution.
Edit samps/contests/sumithello/config/contest.yaml: change from running:true to running:false,then save the updated file.
Start a PC2 server using --load sumithello.
Start a PC2 Admin; verify that the contest is NOT running and has NEVER BEEN STARTED (check the "Times" tab"; under "Started?" it should say "No").
In the PC2 "projects" folder, unzip the WebTeamInterface .zip file.
Go into the resulting WebTeamInterface folder, open a terminal command prompt, and start the WTI server with the command ./bin/pc2wti.
Open a browser, then hit F12 (or the browser's equivalent) to open the browser devtools; select the "Console" tab.
Enter "http://localhost:8080" in the browser address bar. Verify:
- you are presented with the PC2 Login screen, and
- no ERRORS appear on the browser console (there will be lots of debug/tracing messages, but none should say "Error").
Login as "team1/team1". Verify:
- you are presented with the PC2 "Runs" screen
- the Header displays a field "Elapsed Time: 00:00:00 (no contest time has elapsed because the contest hasn't been started)
- the Header displays a field "Remaining Time: xx:xx:xx", where xx:xx:xx is the number of hours/mins/secs defined as the
  length of the contest (for the default values in the "sumithello" contest, that should be "05:00:00")
  Note: if you change the Contest Length in the contest.yaml file BEFORE STARTING THE SERVER, and the value you set for
  contest length is greater than 24 hours, the "Remaining Time" field should also include a count of the number of DAYS remaining.
- neither the Elapsed Time nor the Remaining Time values are changing (because the contest isn't running).
- there are no ERRORS on the browser console (again, there will be lots of tracing/debug messages, but there should be none marked ERROR)
In the browser, click on the Clarifications menu item; verify there are no ERROR messages in the browser console.
Click on the Runs menu item, then click on the "Select Problem" dropdown in the "Filters" pane. Verify that the contest problems are NOT shown.
On the PC2 Admin, START the contest, then verify:
- the Elapsed Time field on the browser header starts counting up at a rate of once per second;
- the Remaining Time field on the browser header starts counting down at a rate of once per second;
- clicking on the "Select Problem" dropdown in the "Filters" pane now shows the contest problems (Sumit and Hello).
- there are no ERROR messages on the browser console.
On the PC2 Admin, STOP ("pause") the contest, then verify:
- both clock fields on the browser freeze;
- the sum of the Elapsed time plus the Remaining Time on the browser header equals the "Contest Length" shown on the Admin "Length" field.
- clicking on the "Select Problem" dropdown in the "Filters" pane still shows the contest problems.
- there are no ERROR messages on the browser console.
Note the "frozen" times in the browser window header, then on the PC2 Admin, START ("un-pause") the contest, then verify:
- both clock fields start changing again, with Elapsed counting up and Remaining counting down, from the times they were "frozen" at when the contest was stopped.
- there are no ERROR messages on the browser console.
On the PC2 Admin, once again STOP the contest, then note the "Elapsed" and "Remaining" times which are now frozen on the browser header.
Hit F5 in the browser window; verify that
- the Elapsed and Remaining Time clock values still have their same (frozen) values.
- Clicking the "Select Problem" dropdown in the "Filters" pane still shows the contest problems.
On the PC2 Admin, START the contest again; verify that
- the Elapsed and Remaining Time clocks resume counting correctly from their frozen values.
- Clicking the "Select Problem" dropdown in the "Filters" pane still shows the contest problems.
On the browser window, hit the "Logout" menu item; verify that you are returned to the PC2 Login screen.
Login as another team; verify that the Elapsed and Remaining Time counters start at the expected values and are correctly changing (the current "Elapsed" and "Remaining" times can be seen by hitting the "Refresh" button on the Admin "Times" tab).
On the Admin, STOP the contest, then EXTEND the length of the contest by some amount (on the Admin "Times" screen, select Site1, click "Edit", add some time to "Contest Length", and also add a corresponding amount of time to "Current Remaining Time".) Click "Update", then verify that the "Remaining Time" on the team browser is properly updated.
On the Admin, START the contest, then verify that the browser times begin properly changing again (and that "Remaining Time" correctly shows the updated value).
MINIMIZE the team browser, wait a minute, then restore the browser. Watch the "Elapsed Time" field as the browser is restored; it will start by displaying the elapsed time as it was AT THE MOMENT IT WAS MINIMIZED but should then (almost immediately) be updated to the correct elapsed time (which can be determined by hitting the "Refresh" button on the Admin "Times" window). (This is happening because JavaScript timers don't run at the correct rate when the browser is minimized;
a separate issue will be filed for this.)

the abstract and concrete versions)

can be used to transform Date objects into strings displaying day/hours/minutes/seconds.

- a count of the number of elapsed seconds (planned for removal), and - a string showing days plus hh:mm:ss (the real plan).

added documentation

apply renaming of updateContestClock() to updateLocalContestClockFromServer().

Conflicts: projects/WTI-UI/src/app/modules/core/services/contest.service.ts projects/WTI-UI/src/app/modules/login/components/login-page/login-page.component.ts

kkarakas

Did not run it on my machine yet, but these are my opinions. Looks like it would work well!

projects/WTI-UI/src/app/modules/core/services/contest.service.ts

kkarakas · 2025-02-04T02:26:45Z

projects/WTI-UI/src/app/modules/login/components/login-page/login-page.component.ts

+						console.error ("LoginPageComponent.onSubmit() ContestClock subscription callback: unable to get ContestClock from PC2 API via ContestService!");
+					} else {						
+						//copy the data fields received from the PC2 Server (via the WTI-API) into the local ContestClock object
+						this.contestClock.isRunning = data.running ;


There is a lot of nested conditionals here, maybe we can use break to break out of conditions. This would improve readability.

I don't quite follow this comment. As far as I can tell there are no nested conditionals which would allow using break. What there ARE (or at least, WERE) are a lot of "debug if's". I will remove all those debug statements; hopefully the logic will be clearer.

I meant return sorry. Maybe the method can be terminated early if it is not going to lead anywhere?

I've removed the large number of "debug" statements, which makes the nested conditionals pretty easy to follow (as JohnB has noted elsewhere, the traditional JavaScript usage of "lamba functions" does complicate it a little bit). As it now stands I don't really see where there's any place that the addition of "return" statements would be particularly helpful...

Let me know if you have a specific suggestion (short of rewriting the whole thing avoiding lambda expressions :) for improving it further. If not, please mark the conversation "Resolved".

kkarakas · 2025-02-04T02:29:38Z

...ects/WTI-UI/src/app/modules/shared/components/problem-selector/problem-selector.component.ts

+	 * and if wallClockStartTime is greater than zero it fetches the current problem list from the server and displays it in the
+	 * component; otherwise it sets the list of displayed problems to an empty list (array).
+	 */
+	private loadProblems(): void {


woah. Is it possible to simplify this method through having multiple methods breaks etc.

As with the previous comment, I don't see any way to use breaks to address this. As before, I think the problem was the large number of "debug" ifs in the code, making it hard to see the structure. I've eliminated all those debug statements; hopefully that makes the code more readable. I'll welcome any suggestion for how to use breaks to simplify it further.

I think the in-line lambda function is what clutters it up. Folks love doing that in javascript too, and it makes it very hard to follow and read. I guess it's the nature of the beast.

I meant return sorry. Maybe the method can be terminated early if it is not going to lead anywhere?

As noted, I've removed the large number of "debug" statements; hopefully this makes the code clearer. Also, as @johnbrvc noted, the use of JavaScript "lambda functions" makes it a little hard to read. (I didn't write that code originally, and I'm reluctant to change it as part of this PR. If you think it still needs to be changed, I suggest submitting a separate Issue for cleaning that up...)

Again, let me know if you have a specific suggestion (short of rewriting the whole thing avoiding lambda expressions :) for improving it further. If not, please mark the conversation "Resolved".

kkarakas

More opinions!

kkarakas · 2025-02-20T18:41:59Z

projects/WTI-UI/src/app/modules/core/services/contestTimer.service.ts

+	if (this.intervalId) {
+      console.error("ContestTimerService.startTimer():  call to startTimer() when timer is already running");
+      return;


Tabbing doesn't seem to match on my screen here and other places. Is this intentional?

Or is just on my screen?

If you are talking about the way indentation appears when you look at the code in Eclipse, that's a function of your Eclipse settings -- both global settings and the setting for the particular editor you're viewing it with. At one point in time we (the early members of the PC2 project) had agreed upon a common set of indentation settings; perhaps yours don't match?

(If it's NOT in Eclipse that you're talking about, then where is it?)

It appears that there is an actual "TAB" character on the lines in question. As @clevengr pointed out, if your Eclipse settings are "right" (by "right" I mean that they match ours), it will line up properly. What IS interesting is, the code indenting appears to violate the indenting rules that we use in the java code. The particular line in @kkarakas example has a TAB SPACE SPACE. It seems to me, if TAB is 4 spaces, then the next level of indenting should be a total of 8 spaces (however you want to arrive at that: TAB TAB, 8x SPACE, etc.) Not sure where the "+2" spaces comes from, unless that's standard for TS? I attached a screenshot of my general editor properties.

I'm not 100% positive, but I think the "default standard" for TypeScript IS "2 space indents". I say this only because almost all the TS code we inherited from the students who did the original WTI project was indented by 2 spaces (on each indent). I know that has caused some aggravation for me... Not sure how we "fix" this.

Ok, that's fine, but what they did initially, it seems, is they "know" that TAB is 4 spaces, which is 2 "TS" indents, one keypress. Ugh. So, I guess just set your TAB to 4 spaces, and you should be ok. The problem is, adding new code, you have to be aware of this and increase levels by 2 spaces...

kkarakas · 2025-02-20T18:50:24Z

projects/WTI-UI/src/app/modules/shared/components/app-header/app-header.component.scss

+    padding-left: 8px;
+    padding-right: 8px;
+  }
+
+  /* Set the container holding the contest clock value(s) to medium, white font */
+  .clock-container {
+	    color: white;
+    font-size: 1.0rem;
+    padding-left: 8px;
+    padding-right: 8px;


I have some concerns about how these pixel paddings would look in different window sizes. Did you play around with different window size and different pixel counts? Perhaps we could use relative units such as em/ rem, vw, just like you use it for font-size. But this is not necessarily problematic, there are cases where pixels are better.

I did try it using various window sizes, and I didn't spot any problems. Do you have a specific example of a platform and window size which shows a problem?

Regarding the "pixel paddings", I didn't create those; they came from a CSS file I got from @johnbrvc . But I haven't observed any issues with it (I tested it in both Chrome and Edge, using various window sizes). Again, do you have an example of a specific situation where a problem is demonstrated?

projects/WTI-UI/src/app/modules/shared/components/app-header/app-header.component.ts

- use concrete data types rather than "any". - remove debug statements. - use "const" instead of "let" in variable declarations where applicable.

johnc and others added 30 commits December 14, 2024 16:52

i1027: added contest timers to app-header files in "shared" module.

7198a88

i1027: added [email protected] to package.json

28836d8

i1027: added various attempts to get HTML properly displaying clocks.

7df2b21

i1027: added setInterval object to gen timer ticks; added date func.

198fe1c

i1027: added attempts to access new ElapsedTimePipe from core module.

0d612ab

i1027: added attempts to access ElapsedTimePipe from shared module.

ac3ea6c

i1027: added new ElapsedTimePipe for formatting dates into dd:hh:mm:ss.

36ce45f

i1027: copy 'constant.ts' into i1027 branch from PR871 branch.

39786ef

i1027: added method getContestClock() to ContestServices (to both...

9ac819e

the abstract and concrete versions)

i1027: added ContestClockModel to hold the WTI-API rep of ContestTime.

2335da0

i1027: added support for getting contest start time via the PC2 API.

d189a1c

i1027: add support for URL /contestclock to WTI-API server.

912fb68

i1027: fix minor typo in javadoc comment.

9705890

i1027: add elapsedTimePipe to core/services -- an Angular "Pipe" that...

6e386d8

can be used to transform Date objects into strings displaying day/hours/minutes/seconds.

i1027: clean up app-header HTML to display elapsed time in two ways:

443238f

- a count of the number of elapsed seconds (planned for removal), and - a string showing days plus hh:mm:ss (the real plan).

i1027: minor doc (comments) added.

95b5e73

i1027: added newly-required getContestClock() method to mock service.

6ed9b97

i1027: added fetch of PC2 contest clock upon successful login.

2356765

i1027: removed no-longer-needed debugging; reformat code for readability

d55fa7f

i1027: rename time display pipe, rework to accept numSeconds

5111f9c

i1027: add WTI-UI model for contest clock.

41051a5

i1027: added Timer class to enable/disable incr of display times.

a93102a

i1027: remove no-longer-used ngx-countdown.

ea7490a

i1027: include title-setting in all routes, matching PR871.

1645b45

i1027: update for compatibility with PR for i871.

7a71e77

i1027: SharedModule: remove ngx-countdown; add ContestServices.

732b89c

i1027: rename contestClock Subject to contestClockEvent; add debugging

b4a84cc

i1027: make some console debug output conditional on DEBUG_MODE

b06f0cb

i1027: LoginPage: move ContestClock to ContestService; add doc and debug

17053d1

i1027: IWebSocketService: make root-injectable; add debug output.

5291696

johnc and others added 9 commits January 11, 2025 11:29

i1027: Add code to handle time elapsed while browser is minimized; also:

92eefb5

added documentation

i1027: rename method to updateLocalContestClockFromServer()

09163e6

i1027: ContestTimer: always update "mostRecentTimerUpdate"; also:

17a0819

apply renaming of updateContestClock() to updateLocalContestClockFromServer().

i1027: removed multiple no-longer-needed debugging outputs.

f0d9ee3

i1027: added debug output.

bc5bf55

i1027: added documentation (no code changes)

e0ff6d1

i1027: update core.module.ts as part of rebase onto develop.

25a7f21

i1027: fix conflict errors during rebase.

b98c837

i1027: fix merge conflicts:

0996489

Conflicts: projects/WTI-UI/src/app/modules/core/services/contest.service.ts projects/WTI-UI/src/app/modules/login/components/login-page/login-page.component.ts

clevengr requested review from johnbrvc, troy2914, SamanwaySadhu and kkarakas January 12, 2025 00:00

This was referenced Jan 12, 2025

WTI "Submit" buttons are enabled when they shouldn't be. #1035

Open

WTI Contest Clocks don't count correctly when the browser is minimized. #1036

Open

kkarakas suggested changes Feb 4, 2025

View reviewed changes

clevengr added 3 commits February 6, 2025 13:53

i1027: updated data types as requested in PR review.

515bfb2

i1027: change data types, remove debug prints for clarity.

8af6b4c

i1027: fix data types, remove debug prints, minor reformatting.

89e3952

clevengr requested a review from kkarakas February 6, 2025 22:10

kkarakas suggested changes Feb 20, 2025

View reviewed changes

i1027: requested updates per PR review, including:

012426e

- use concrete data types rather than "any". - remove debug statements. - use "const" instead of "let" in variable declarations where applicable.

clevengr mentioned this pull request Feb 20, 2025

I1030 WTI clar announcement filtering #1041

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

I1027 Add Contest Clock To WTI #1034

I1027 Add Contest Clock To WTI #1034

clevengr commented Jan 12, 2025 •

edited

Loading

kkarakas left a comment

kkarakas Feb 4, 2025

clevengr Feb 6, 2025

kkarakas Feb 12, 2025

clevengr Feb 20, 2025 •

edited

Loading

kkarakas Feb 4, 2025

clevengr Feb 6, 2025

johnbrvc Feb 6, 2025 •

edited

Loading

kkarakas Feb 12, 2025

clevengr Feb 20, 2025 •

edited

Loading

kkarakas left a comment

kkarakas Feb 20, 2025

kkarakas Feb 20, 2025

clevengr Feb 20, 2025

johnbrvc Feb 20, 2025

clevengr Feb 20, 2025

johnbrvc Feb 20, 2025

kkarakas Feb 20, 2025

clevengr Feb 20, 2025

I1027 Add Contest Clock To WTI #1034

Are you sure you want to change the base?

I1027 Add Contest Clock To WTI #1034

Conversation

clevengr commented Jan 12, 2025 • edited Loading

Description of what the PR does

Issue which the PR addresses:

Environment in which the PR was developed (OS,IDE, Java version, etc.)

Precise steps for testing the PR :

kkarakas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clevengr Feb 20, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

johnbrvc Feb 6, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clevengr Feb 20, 2025 • edited Loading

Choose a reason for hiding this comment

kkarakas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

clevengr commented Jan 12, 2025 •

edited

Loading

clevengr Feb 20, 2025 •

edited

Loading

johnbrvc Feb 6, 2025 •

edited

Loading

clevengr Feb 20, 2025 •

edited

Loading